第4章身份与权限管理

4、身份与权限管理：统一身份认证（SSO）、角色权限控制（RBAC）、跨云资源访问控制

聊到混合云，很多人第一反应是网络怎么通、数据怎么迁。但说实话，我踩过最大的坑，往往出在「身份」上。

你想想看，一个公司既有阿里云，又有 AWS，可能还有自建机房。员工要登录三个控制台，记三套密码，权限还经常对不上。这哪是上云，简直是上刑。所以这一章，咱们就聊聊怎么把「身份」这件事管明白。

4.1 统一身份认证（SSO）：一个入口，走遍所有云

SSO 说白了，就是让用户只登录一次，就能访问所有资源。我在项目中遇到过一家金融客户，他们内部有 8 套系统，每套系统都要单独登录。员工每天光登录就要花十几分钟，而且密码记混了就得找 IT 重置。

后来我们做了 SSO，效果立竿见影。核心思路就一个：找一个信任的「身份源」。

核心架构：

身份源（IdP）：通常是企业的 AD 或 LDAP，也可以是 Okta、Azure AD 这类云 IdP。
服务提供商（SP）：各个云平台、内部系统。
协议：主流是 SAML 2.0 和 OIDC（OpenID Connect）。

我个人习惯用 OIDC，因为它基于 OAuth 2.0，更轻量，也适合现代应用。SAML 虽然成熟，但配置起来比较重，尤其是 XML 那套东西，看着就头疼。

避坑指南：

我曾经在配置 AWS SSO 时，忘了把 SAML 断言里的「NameID」格式设成 email。结果用户登录后，AWS 不认识这个用户，一直报 403。折腾了两小时才发现是格式问题。嗯，这里要注意：IdP 和 SP 之间的属性映射一定要提前对齐。

4.2 角色权限控制（RBAC）：谁该干什么，得说清楚

SSO 解决了「你是谁」的问题，但「你能干什么」还得靠 RBAC。说白了，就是给不同的人分配不同的角色，每个角色有固定的权限集。

我在做混合云项目时，发现很多团队喜欢直接给用户绑定策略。比如张三要读 S3，就给他一个 S3 只读策略；李四要写 RDS，就给他一个 RDS 写策略。结果搞了半年，权限列表乱成一锅粥，根本没法审计。

正确的做法是：

定义角色：比如「运维工程师」、「开发工程师」、「审计员」。
角色绑定权限：每个角色对应一组最小权限集。
用户绑定角色：用户只跟角色关联，不直接跟权限关联。

举个例子，在 AWS 里，我会这样定义一个「只读运维」角色：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "cloudwatch:Describe*",
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": "*"
    }
  ]
}

你看，这个角色只能看，不能改。就算有人误操作，也删不了东西。我建议你从一开始就设计好角色体系，别等出事了再补。

注意：

跨云环境下，角色名可能冲突。比如阿里云的「Admin」和 AWS 的「Admin」含义可能不同。我建议统一命名规范，比如用「cloud-role-{云厂商}-{职责}」这种格式。

4.3 跨云资源访问控制：让云与云之间互相信任

这是混合云里最头疼的部分。你想想，阿里云上的应用要读取 AWS S3 里的数据，怎么授权？

传统做法是在 AWS 里创建一个 IAM 用户，把密钥发给阿里云。但密钥会泄露，轮转也麻烦。我个人更推荐用角色扮演（Assume Role）的方式。

具体流程是这样的：

在 AWS 里创建一个角色，并指定信任策略——允许阿里云的一个特定身份来扮演它。
阿里云的应用先用自己的身份认证，拿到一个临时凭证。
用这个临时凭证去调用 AWS STS（Security Token Service），换取 AWS 角色的临时密钥。
用临时密钥访问 S3。

这样做的好处是：没有长期密钥，所有凭证都是临时的，过期自动失效。我在一个电商项目中用过这套方案，稳定运行了一年多，没出过安全问题。

跨云访问控制的核心原则：

最小权限：只给必要的操作权限，别图省事给「*」。
临时凭证：能用 STS 就别用长期密钥。
审计日志：所有跨云访问都要记录，方便事后追溯。

4.4 实战：一个完整的跨云 SSO + RBAC 配置示例

咱们来个完整的例子。假设公司用 Azure AD 作为身份源，员工需要访问 AWS 和阿里云。

第一步：在 Azure AD 里配置企业应用

为 AWS 和阿里云各注册一个应用，配置 SAML 或 OIDC 登录。注意把用户属性映射好，比如把 Azure AD 里的「userPrincipalName」映射成云平台里的「用户名」。

第二步：在云平台里创建角色

在 AWS 里创建 IAM 角色，信任方设为 Azure AD。在阿里云里创建 RAM 角色，同样信任 Azure AD。

第三步：分配权限

比如「开发工程师」角色在 AWS 里有 EC2 只读权限，在阿里云里有 ECS 只读权限。这些权限都绑定到角色上，而不是直接绑给用户。

第四步：用户登录

员工打开公司门户，用 Azure AD 账号登录。门户里列出所有可访问的云资源，点击即可跳转，无需再次输入密码。

小技巧：

我曾经用 Terraform 管理这些跨云角色配置。把角色定义、信任策略、权限策略都写成代码，版本化管理。这样谁改了什么，一目了然，回滚也方便。

4.5 总结与避坑清单

身份与权限管理，说白了就是三件事：统一入口、明确角色、控制跨云访问。我见过太多项目因为权限混乱导致的安全事故，轻则数据泄露，重则业务停摆。

最后列个避坑清单，你对照着检查：

❌ 不要用共享账号，每个人都要有独立身份。
❌ 不要直接给用户绑定策略，用角色做中间层。
❌ 不要用长期密钥做跨云访问，用 STS 临时凭证。
✅ 定期审计权限，清理僵尸账号。
✅ 所有跨云操作都要记录日志。

嗯，这一章就聊到这儿。下一章咱们聊聊网络连通，那又是另一个大坑。