4. 身份与访问管理基线

在企业云项目交付中，身份与访问管理（IAM）基线不是“开通账号”这么简单，而是决定整个云上安全边界、审计可追溯性和自动化能力的地基。本节围绕四个核心对象展开：Cloud Identity 作为人员身份源，IAM 角色作为权限授予单元，服务账号作为工作负载身份，Workload Identity Federation 作为外部身份免密钥接入机制。交付目标可以概括为一句话：人员用联合身份登录、工作负载用服务账号或联邦身份运行、权限通过角色最小化授予、所有关键操作可审计。

一、Cloud Identity：人员身份的权威源

Cloud Identity 是 Google 的人员身份目录，提供用户、群组、组织单位和设备管理能力。交付时通常不直接手工建用户，而是与现有 IdP（如 Azure AD、Okta、AD FS）通过 SAML 或 OIDC 做联合登录，再用 Directory Sync 或 SCIM 同步用户与群组。这样做的价值在于：人员生命周期由 HR/IdP 驱动，离职即失效，避免“幽灵账号”。

关键配置点包括：验证域名所有权、配置 SSO 配置文件、启用多因素认证（MFA）、建立群组命名规范。例如群组命名建议采用 gcp-<env>-<role>-<team>，如 gcp-prod-viewer-finance。权限授予对象优先是群组而非个人，这样人员变动只需调整群组成员关系，不必逐个修改 IAM 策略。

二、IAM 角色：权限授予的最小单元

GCP 的 IAM 角色分为基本角色、预定义角色和自定义角色。基本角色（Owner/Editor/Viewer）粒度太粗，生产环境应避免使用 Owner/Editor。交付基线建议：

• 组织层：仅授予安全管理员、组织管理员等少数角色给平台团队群组；
• 文件夹层：按环境（prod/staging/dev）或业务域划分，授予环境级管理角色；
• 项目层：授予具体服务角色，如 roles/compute.instanceAdmin.v1、roles/storage.objectViewer；
• 资源层：对敏感 Bucket、KMS 密钥做条件绑定。

IAM Conditions 是交付中容易被忽略但很关键的能力。例如限制访问来源 IP、限制仅允许特定时间段、或要求请求携带特定资源标签。下面是一个把 roles/storage.objectViewer 限制在指定 IP 段的策略片段示例：

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["group:gcp-prod-viewer-finance@example.com"],
      "condition": {
        "title": "corp_ip_only",
        "expression": "request.auth.access_levels.exists(a, a == 'accessPolicies/123/accessLevels/corp_ip')"
      }
    }
  ]
}

交付时应形成一份“角色—群组—范围”对照表，作为权限评审和审计的依据。判断权限是否合理，可以问三个问题：这个角色是否包含未使用的权限？授予范围是否比实际需要更大？是否可以用群组替代个人？

三、服务账号：工作负载的身份

服务账号是给应用、CI/CD、批处理任务使用的非人类身份。交付基线要求：每个工作负载使用独立服务账号，禁止多个应用共用一个服务账号；服务账号密钥尽量不创建，优先使用附加到计算资源的服务账号或 Workload Identity Federation。

服务账号的典型配置流程：创建服务账号 → 授予最小角色 → 绑定到资源（如 GCE 实例、GKE ServiceAccount、Cloud Run 服务）→ 关闭密钥创建权限。对于 GKE，推荐启用 Workload Identity，把 Kubernetes ServiceAccount 映射到 GCP 服务账号，Pod 通过元数据服务获取短期凭证，无需在集群中存放 JSON 密钥。

四、Workload Identity Federation：免密钥的外部身份接入

当工作负载运行在 AWS、Azure、GitHub Actions 或本地 IDP 时，Workload Identity Federation（WIF）允许外部身份直接换取 GCP 短期访问令牌，避免下载服务账号密钥。交付配置通常包括：创建工作负载身份池、添加外部身份提供方、配置属性映射与条件、授予外部身份模拟服务账号的权限。

以 GitHub Actions 为例，典型配置步骤为：创建池 github-pool，添加 OIDC 提供方，设置属性映射 google.subject=assertion.sub、attribute.repository=assertion.repository，条件限制 assertion.repository=='my-org/my-repo'，然后授予该外部身份 roles/iam.workloadIdentityUser 以模拟目标服务账号。工作流中通过 google-github-actions/auth 获取短期凭证，无需在 Secrets 中保存 JSON 密钥。

五、交付基线的落地检查

把上述四类对象串起来，交付时建议按以下顺序推进：先完成 Cloud Identity 与 IdP 联合、建立群组规范；再设计组织/文件夹/项目三级 IAM 策略，明确哪些角色授予哪些群组；然后为每个工作负载创建独立服务账号并绑定资源；最后对跨云、CI/CD 场景启用 WIF，逐步下线服务账号密钥。

验证是否达标，可以观察几个信号：Cloud Audit Logs 中是否能看到人员登录、权限变更、服务账号使用记录；IAM Recommender 是否提示存在未使用权限；是否存在用户管理的服务账号密钥；外部工作负载是否仍在使用 JSON 密钥。若这些信号都指向“无长期密钥、无过度授权、操作可追溯”，说明 IAM 基线已经具备企业级交付的基本条件。