Best Buy 如何用 Workforce Identity Federation 扩展 AI 数据访问并摆脱服务账号密钥

预计阅读时间：9 分钟

随着高级分析和 AI 工作负载在 Google Cloud 上扩大，身份系统也会遇到扩展瓶颈。Best Buy 面临的核心问题并不是登录页面怎么做，而是如何让数万名员工使用现有 Microsoft Entra ID 身份访问 BigQuery 等资源，同时避免同步大量用户记录、分发服务账号密钥和维护复杂的轮换流程。

Best Buy 采用 Google Cloud Workforce Identity Federation，将 Entra ID 与 Google Cloud 建立直接信任。开发者仍然使用企业 Microsoft 凭据登录，但访问日志开始记录真实用户，平台团队也不再需要在两个身份存储之间复制人员数据。

旧架构为何会随着团队增长失控

Best Buy 此前维护同步管道，将 Entra ID 中的后端用户复制到 Google Cloud。由于公司使用 Cloud Identity，但没有部署 Google Workspace，这种模式需要额外的用户同步和生命周期管理机制。

Power BI 访问 BigQuery 时还曾依赖服务账号凭据。服务账号适合代表应用程序运行，但当它被用于员工交互式访问时，会带来几个明显问题：

每把私钥都需要分发、保存、盘点和定期轮换。
密钥可能出现在聊天记录、脚本、开发机或 CI 日志中。
多人共用一个服务账号后，审计日志只能显示共享身份，难以定位实际操作者。
员工离职或岗位变化后，撤销企业账号并不一定会让已分发的密钥立即失效。

这些问题在几十名用户时可能只是运维负担，扩大到数千或数万名用户后，就会变成持续增长的攻击面和技术债务。

联邦身份把认证与授权拆开

新架构中，Entra ID 负责认证用户，Workforce Identity Federation 负责验证令牌并把外部身份映射成 Google Cloud 可以授权的主体。典型访问链路可以概括为：

开发者或 Power BI
        |
        v
Microsoft Entra ID 认证
        |
        v
Workforce Identity Federation 验证令牌与映射声明
        |
        v
Google Cloud IAM 判断权限
        |
        v
BigQuery 等目标服务

关键变化是中间不再存在供员工共享或保管的服务账号私钥。Google Cloud 在访问发生时验证令牌，而不是为每位联邦用户在 Cloud Identity 中创建并长期维护一条记录。

这里的 syncless 更准确地说，是 Google 侧对员工记录保持无状态。它减少了同步延迟、过期账号清理和同步管道故障，但并不意味着完全没有配置工作。团队仍需维护身份提供商、声明映射、群组成员关系和 IAM 策略。

三个容易被忽略的实施决定

将预配应用与 SSO 应用分开

Best Buy 在 Entra ID 中使用两个独立的企业应用分别承载预配和单点登录。这样修改预配配置时不会影响 SSO，调整登录策略时也不会破坏预配任务。即便最终目标是减少用户同步，这种职责隔离仍能降低配置变更的影响范围。

为自动化账号保留独立 OU

用于 Entra ID 预配的服务账号应放入单独的组织单位，并对该 OU 显式关闭 SSO。否则，全局强制 SSO 可能制造引导死锁：预配账号需要先完成认证才能建立预配，但认证本身又依赖尚未完成的配置。

用群组授权，不要逐人绑定角色

联邦解决的是身份进入 Google Cloud 的方式，最小权限仍要依靠 IAM。大规模环境应把 Entra ID 群组映射到 Google Cloud 属性，再以群组为单位授予角色。逐个用户维护绑定会重新引入人工操作和离职账号残留问题。

可以这样实践：用群组给 BigQuery 授权

下面是一个可改造的命令示例。它假设管理员已经创建 Workforce Identity Pool，并把 Entra ID 的群组声明映射为 google.groups。请替换项目、池、群组和数据集变量；角色范围也要根据查询与数据读取需求重新评估。

#!/usr/bin/env bash
set -euo pipefail

PROJECT_ID="my-data-project"
POOL_ID="entra-workforce"
ENTRA_GROUP_ID="00000000-0000-0000-0000-000000000000"
DATASET="retail_analytics"

MEMBER="principalSet://iam.googleapis.com/locations/global/workforcePools/${POOL_ID}/group/${ENTRA_GROUP_ID}"

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
  --member="${MEMBER}" \
  --role="roles/bigquery.jobUser"

bq add-iam-policy-binding \
  --member="${MEMBER}" \
  --role="roles/bigquery.dataViewer" \
  "${PROJECT_ID}:${DATASET}"

这里刻意拆成两种权限：roles/bigquery.jobUser 允许在项目中运行查询任务，roles/bigquery.dataViewer 只授予指定数据集的读取能力。不要为了省事直接授予项目级 BigQuery 管理员角色。

上线后，可以用 Cloud Audit Logs 检查最近访问 BigQuery 的主体。以下查询可以直接运行，只需替换项目 ID：

gcloud logging read \
  'resource.type="bigquery_resource" AND protoPayload.authenticationInfo.principalSubject:*' \
  --project="my-data-project" \
  --freshness="24h" \
  --limit="50" \
  --format='table(timestamp,protoPayload.authenticationInfo.principalSubject,protoPayload.methodName)'

不同服务和日志类型暴露的字段可能不同，正式验收时应同时测试交互式登录、Power BI 查询、直接 API 调用、权限撤销和异常令牌场景。

推广前的检查清单

Workforce Identity Federation 的价值会随用户数量增长而放大，但迁移不应只以登录成功作为完成标准。上线前至少确认以下事项：

Entra ID 条件访问、多因素认证和账号生命周期策略已经覆盖联邦应用。
SSO 与预配使用独立企业应用，自动化账号所在 OU 不受强制 SSO 阻断。
属性映射只信任稳定、不可随意修改的标识符，群组声明不会因令牌过大而丢失。
IAM 以群组和最小权限为基础，项目级角色与数据集级角色分开评审。
审计日志能定位到个人，并已接入告警、调查和留存流程。
旧服务账号密钥在验证完成后被盘点、禁用并删除，而不是无限期保留为备用通道。
为身份提供商故障准备受控的紧急访问机制，并定期演练。

Best Buy 的实践说明，身份联邦并不只是改善 SSO 体验。它把员工访问从长期密钥和用户同步管道，转变为即时令牌验证、企业身份生命周期和可审计的个人操作记录。Google Cloud 还扩展了 Ping Identity 的配置支持，并允许在线结算账号使用 Workforce Identity Federation，使这种无同步访问模式适用于更广泛的组织。