Best Buy 扩展 Google Cloud AI，但共享凭证必须退出

Best Buy 正在替换一种高度依赖凭证的访问模式，为数万名用户接入更大规模的 Google Cloud AI 和分析业务版图做准备。此前，部分访问依赖服务账号、同步身份以及手动轮换的密钥。随着使用规模扩大，这种架构愈发难以维持安全性。

这家零售商如今通过 Workforce Identity Federation，将 Microsoft Entra ID 直接连接至 Google Cloud。系统会在发生访问时验证开发者现有的企业身份，无需 Google 维护每条员工记录的同步副本。

这项变化看似是一个身份现代化项目，但其更重要的意义在于：Best Buy 能否在不增加凭证、管理工作和模糊审计记录的情况下扩展云端 AI。旧路径将访问视为由团队配置和维护的事项；新路径则将身份视为一种实时信任关系。

这一差异正令既有的服务账号模式承压，也反映出同步云目录与直接身份联合之间更广泛的竞争。Best Buy 正押注于：员工使用另一家供应商的数据和 AI 服务时，其 Microsoft 身份系统仍可作为控制点。

Best Buy 移除了阻碍扩展的凭证层

Best Buy 最直接的改变简单却影响深远：开发者如今以可识别的员工身份进入 Google Cloud，而非隐藏在共享服务账号凭证之后。

Best Buy 在 7 月 28 日的公告中介绍了该项目。这家零售商表示，其不断扩展的分析和 AI 活动带来了两个相关问题：既要降低凭证风险，也要避免同步数千名后端用户带来的管理摩擦。

该公司过去运行同步管道，将后端身份从 Microsoft Entra ID 复制到 Google Cloud。Entra ID 是 Best Buy 现有的企业身份提供商，负责验证员工身份并应用企业访问策略。

Best Buy 在未部署 Google Workspace 的情况下使用 Cloud Identity。这种配置使其技术组织需要在由 Microsoft 管理的员工体系与不断增加的云资源之间建立一座实用的桥梁。

通过 Power BI 访问 BigQuery，暴露了早期架构的局限。BigQuery 是 Google 面向分析和 AI 工作负载的托管数据平台。用户此前通过 Power BI 使用它时，连接依赖服务账号凭证。

服务账号代表的是应用程序或流程，而非具名员工。它可能适用于软件工作负载，但当多人使用其密钥进行交互式访问时，问责性会被削弱。

每个长期密钥也都会成为必须由某人签发、存储、跟踪、轮换并最终撤销的对象。Best Buy 表示，其安全和平台团队必须了解每个团队持有哪些凭证，还必须考虑密钥可能出现在聊天消息或其他不受控制位置的风险。

这些并非孤立的管理烦恼。每增加一个凭证，就会增加一条必须在其整个生命周期内受到保护的路径。规模增长既会增加路径数量，也会提高遗漏其中一条路径的后果。

Best Buy 的新架构从员工访问流程中移除了这把中间密钥。开发者使用既有 Entra ID 身份登录，随后 Workforce Identity Federation 在 Microsoft 的身份系统与 Google 的资源控制之间建立信任代理。

开发者可通过 Power BI 访问 BigQuery，也可直接调用 API。Google Cloud 会以个人身份记录活动，而不是以共享服务账号记录。这让安全团队在审计询问谁访问了数据集或变更了资源时，能够给出更清晰的答案。

Best Buy 表示，该设计可支持数万名用户。随着云服务对零售运营愈发重要，公司现正将这一模式扩展至更广泛的员工群体。

这一扩展主张仍需通过实测结果验证。Best Buy 尚未公布采用率、迁移周期、事件减少情况或管理成本节省数据。不过，这项架构调整在这些用户到来前移除了一个显而易见的限制因素。

对技术领导者而言，这一先后顺序很重要。Best Buy 没有等到身份管理成为更大的瓶颈，才采取行动；它在引入又一大批用户和工作负载之前就改变了访问模式。

为什么 Google Cloud AI 让身份债务更难忽视

AI 扩张并未造成 Best Buy 的身份债务，但它让承担这笔债务的成本大幅上升。

高级分析依赖对数据、开发环境、模型和支撑 API 的广泛访问。AI 项目则会为这一环境引入更多团队、实验和自动化。适用于小型数据团队的凭证流程，在参与规模达到企业级时可能失效。

压力首先落在 Best Buy 的安全和平台团队身上。他们必须让开发者高效工作，同时不失去对敏感零售数据的控制；还必须保留能够显示每项操作由谁执行的证据。

共享服务账号会在这些要求之间制造张力。它们可能简化初始连接，因为团队只需获得一个技术身份；但同样的捷径会减少对个人的归属追溯，并引入一个必须持续保护的长期密钥。

轮换并不能消除这个问题，只是将其转化为周期性的运营流程。团队必须分发替代密钥、更新依赖工具、移除旧副本，并确认生产工作流仍能正常运行。

过期凭证可能中断工作，泄露凭证可能暴露资源，被遗忘的凭证则可能在原始业务需求消失后仍然有效。

Google 建议组织在可能的情况下选择更安全的替代方案，因为服务账号密钥需要得到谨慎保护。其工作负载身份指南将联合视为外部软件工作负载的首选模式。

Best Buy 的使用场景涉及员工身份，而非机器工作负载，但安全原则相似。长期密钥将责任转移至存储和轮换；联合访问则依赖短期令牌和明确的信任关系。

随着数据访问范围超出核心云团队，这一转变会变得更为重要。分析人员可以通过熟悉的商业智能工具查询 BigQuery，开发者可直接访问 API，未来的 AI 应用还可能将更多运营团队带入同一环境。

因此，身份层成为 AI 容量规划的一部分。如果每位新用户都需要一条并行记录、一份手动管理的凭证，以及审计流程中的另一项例外，那么更多算力和更好的模型也难以发挥作用。

Best Buy 的决定也保留了以 Microsoft 为中心的员工使用体验。员工继续使用熟悉的企业凭证进行身份验证，零售商无需让第二个身份存储库成为这些用户日常的事实来源。

这也是 Google Cloud 面临自身压力之处。企业客户经常运行混合技术环境。零售商可能使用 Microsoft 管理员工身份和商业智能，同时选择 Google 进行数据处理或 AI。

云服务商不能假设，赢得一个 AI 工作负载就意味着取代客户的身份提供商。它们需要接受外部身份，同时不削弱自身的授权和审计系统。

Google 将员工身份联合定位为这座桥梁。它支持 SAML 和 OpenID Connect，这两项标准用于在提供商之间交换身份信息；还可将外部属性映射至资源访问策略。

其结果不只是单点登录。单点登录让登录体验更为熟悉；联合还必须将受信任的身份转换为 Google Cloud 能够针对特定资源评估的权限。

对 Best Buy 而言，实际考验在于该模式能否跟上 AI 的采用速度。每个新增数据集、项目和应用都会引入新的授权决策。联合消除了重复凭证，但并未消除谨慎作出这些决策的必要性。

Google Cloud 联合以实时信任取代同步

其核心机制是无状态验证：Google 会在发生访问时检查 Entra ID 令牌，而不是维护一个重复的员工目录。

Workforce Identity Federation 在 Google Cloud 组织与外部身份提供商之间建立信任关系。Entra ID 负责验证员工身份，随后 Google 评估生成的令牌，并将其中的声明映射为其访问策略可识别的身份。

令牌是一种已签名的数字声明，包含身份信息和有限的有效期。Google 会在访问发生时验证该声明。Best Buy 不再需要为每名联合员工维护同步到 Google 一侧的用户记录。

这是该项目的关键逆转。旧系统将身份复制到另一环境中，之后再设法让这些副本保持最新；新系统则在人员请求访问时，向权威提供商索取证明。

同步会引入多个时序问题。新员工可能要等待一次配置周期才能获得访问权限；角色变更可能无法立即反映；离职员工的复制记录也可能持续存在，直到另一系统将其移除。

直接联合减少了这些特定缺口，因为 Entra ID 仍负责身份验证和用户生命周期。如果 Best Buy 在其中撤销一名员工的访问权限，公司无需再去定位并轮换 Google Cloud 中另一把独立的个人密钥。

Google 仍在其平台内部管理授权。身份验证回答“此人是谁”；授权则决定 Google 接受该身份后，此人可以执行什么操作。

Best Buy 可将 Entra ID 属性和群组映射到 Google Cloud 访问规则中。这种方式可基于企业上下文制定策略，而不是为每一项连接签发独立凭证。

该公司还获得了更有用的审计记录。管理员不再看到操作归属于共享服务身份，而是可以将其关联到发起操作的员工。这一区别有助于调查、访问审查和合规报告。

无状态并不意味着无需配置。Best Buy 仍须建立身份池、提供商、属性映射和访问策略。员工身份池会对外部身份进行分组，以便管理员控制其对云资源的访问。

这家零售商还作出了两项实施选择，体现出该项目的运营复杂性。它将配置与单点登录拆分为不同的 Entra ID 企业应用程序，从而避免一个功能的变更意外影响另一个功能。

百思买还将 Entra ID 预配服务帐户置于单独的组织单位，并为该单位禁用了单点登录。若无这一例外，在全局范围内强制实施单点登录可能会阻止配置预配所需的帐户。

这种引导式配置问题很容易被忽视。身份策略可能会阻碍建立其支撑环境所必需的自动化。百思买通过隔离自动化身份避免了这一循环。

开发者接触到的这类机制要少得多。他们使用 Microsoft 凭据完成一次身份验证，然后使用 Power BI 或直接调用 API。该系统的价值部分在于，它将额外的云边界隐藏在日常工作流程之外。

这种无感体验不应被误认为控制力有所降低。Google 的访问层仍会决定该联邦主体能否使用 BigQuery 或其他受支持服务。云审计日志可以在该主体名下记录用户的活动。

这一设计还将用户访问与软件身份分离开来。只要可行，人类开发者就应以自己的身份访问。应用程序和自动化工作负载仍需要各自的身份、权限和生命周期控制机制。

随着百思买部署更多 AI 系统，这一区分将变得愈发重要。通过 Power BI 查询数据的员工，与调用 API 的自主流程并不是同一类行为主体。两者都需要可追责的身份，但其访问模式和防护措施不同。

让员工队伍采用联邦身份验证，解决了这一治理问题的一部分。在自动化访问进一步扩展之前，它为零售商分配人类责任提供了更清晰的基础。

真正的较量是联邦身份验证与复制目录

百思买选择直接联邦身份验证，而非重复的身份记录；但更广泛的云市场仍同时支持这两种模式。

目录同步会将用户和群组从权威系统复制到目标目录。它会在目标系统中为每个身份提供本地表示。许多企业平台采用这种模式，因为本地记录可简化权限分配和应用程序集成。

其弱点会在大规模部署和变更期间显现。副本必须与来源保持一致。预配延迟、更新失败、属性变更以及陈旧帐户，都会带来与 AI 应用业务价值关联甚微的工作。

百思买此前已经经历过这种管理摩擦。该公司的技术团队维护着将后端身份从 Entra ID 迁移到 Google Cloud 的管道。其新模式无需在 Cloud Identity 中维护联邦用户的这些记录。

直接联邦身份验证转移了依赖关系。访问不再依赖同步管道，而是依赖 Entra ID、令牌交换、提供商配置以及 Google 的验证路径。

这并非消除了复杂性，而是决定复杂性应位于何处。百思买更倾向于实时信任边界，而不是数以千计的重复身份记录和面向员工的服务帐户密钥。

其他云服务提供商也在做出类似取舍。AWS 建议将联邦身份验证用于人工访问，但其 IAM Identity Center 文档指出，管理员进行权限分配前，通常必须先预配外部用户和群组。

AWS 可通过 SAML 连接到 Microsoft Entra ID，并通过跨域身份管理系统处理预配。其外部身份模型允许员工使用企业凭据，但仍在 IAM Identity Center 内保留同步的用户和群组信息。

这与百思买的 Google 实施方案形成了有益对照。两种方法都避免为每位员工提供永久性的云原生密码，但它们在云平台维护多少身份状态方面有所不同。

Microsoft 将同样的减少机密原则应用于机器身份。其联邦凭据指南建议，外部工作负载应优先使用联邦身份验证或证书，而非客户端机密。

这些案例表明，尽管实施方式不同，行业方向是一致的。云服务提供商越来越鼓励使用临时联邦凭据，但它们在预配、本地目录、属性映射和服务覆盖范围上仍有不同选择。

对企业买家而言，相关的比较并非哪家提供商具备联邦身份验证功能。所有主要提供商都提供多种形式。重要的问题在于身份状态如何流转、策略位于何处，以及依赖项发生故障时会怎样。

同步目录能够在某些外部中断期间保留本地用户信息，但也可能遗留陈旧信息。无状态联邦设计避免了这些副本，却在身份验证期间更直接地依赖源提供商。

两种架构都无法消除对应急访问的需求。管理员仍需要一条受到严格控制的路径，以应对身份提供商不可用、联邦配置受损或策略误改等事件。

因此，百思买的案例并非 Google 击败 Microsoft。Microsoft 仍是负责验证该零售商员工队伍身份的权威系统。Google 因为接受这一权威身份、而不要求建立另一套用户存储，变得更易于使用。

这一安排反映了大型组织实际采购技术的方式。它们从多家供应商处组合云、身份、分析和生产力服务。若访问设计要求一家提供商拥有每一层，便会引入迁移工作和阻力。

当由 Microsoft 管理的员工无需采用另一种日常身份即可访问 BigQuery 时，Google 将从中受益。Microsoft 保留其在员工生命周期中的位置。百思买则减少了其团队必须治理的凭据数量。

服务帐户不再被不恰当地用作具名人工访问的替代品。这才是本篇故事的主要对手，而不是另一家云服务供应商。

对开发者而言，这一边界也能改善运营文档。当事件记录能够标明人员、项目和受影响资源时，团队就能构建更有价值的技术知识库。共享身份会使这类历史记录更难解读。

密钥减少不等于自动获得安全

联邦身份验证消除了一个凭据管理风险，但其信任配置会成为高价值控制平面，百思买必须持续测试。

Google 和百思买将新模式描述为减少了与密钥相关的攻击面。这一说法在架构层面是合理的。不存在的凭据无法从笔记本电脑复制、粘贴到聊天工具中，或被遗忘在代码仓库里。

不过，公开案例研究并未证明安全事件出现了可量化的减少。其中没有提供暴露密钥、未经授权请求、审计失败或恢复时间的前后对比数据。

该文章也未披露已迁移的用户数量。文章称该架构面向数万名用户，并且百思买正将访问范围扩展至更广泛的员工队伍。这些表述说明的是容量和方向，而非已完成的采用情况。

联邦身份验证将关注点集中到令牌验证和策略映射上。如果管理员信任了范围过宽的声明、错误配置受众，或错误映射群组，那么有效的员工身份可能会获得超出预期的访问权限。

基于属性的访问控制可让策略随员工特征变化，从而减少管理工作。它也会将风险分散到这些属性的质量中。Entra ID 中错误的群组成员资格，可能在 Google Cloud 中变成授权错误。

因此，安全团队必须测试关系的两端。他们需要确认 Entra ID 签发了预期声明，也需要确认 Google 会完全按预期解释这些声明。

最小权限仍然至关重要。这一原则只向每个身份授予其工作所需的权限。联邦身份验证本身并不能决定正确的权限级别。

百思买还必须将员工与自动化工作负载分开。该公司从所述的开发者访问流程中移除了服务帐户密钥，但并未声称服务帐户已从所有应用程序或后端流程中消失。

AI 系统使这条边界更加复杂。开发者可以发起实验，而定时管道和代理会在该人员未保持活跃会话的情况下继续工作。这些流程需要权限范围有限且所有权可追溯的机器身份。

Google 的文档列出了支持联邦身份的产品，并说明了服务特定的限制。百思买必须在将该设计扩展到其零售业务涉及的所有云服务之前确认兼容性。

可用性带来了另一项取舍。联邦登录依赖多个正常运行的组件，包括 Entra ID、网络连接、Google 的令牌交换以及正确的提供商配置。

该链路中断可能会阻止新会话建立。组织需要受到严格限制的紧急帐户或其他恢复机制。由于这些例外位于正常身份路径之外，因此需要异常严格的监控。

会话行为也值得审查。在源目录中撤销某人的身份应阻止后续身份验证，但现有令牌或会话可能会在其配置的有效期结束前仍可使用。较短的会话可减少暴露，但需要更频繁地续期。

当操作携带具名身份时，可审计性会得到提升。但只有在团队保留、监控并调查日志时，日志才会发挥作用。百思买仍需要能够区分正常分析活动与异常导出、权限变更或访问模式的告警机制。

AI 数据访问还存在治理问题。身份可以证明哪名员工访问了某个数据集，却无法决定该数据集是否适用于特定模型、提示词或实验。

数据分类、模型治理和隐私控制仍是独立责任。联邦身份验证使执行更具可追责性，但并不会制定底层规则。

该案例研究来自 Google Cloud 和百思买的一位云工程负责人。应将其视为官方客户叙述，而非独立安全评估。

因此，最有力的结论比营销信息更为有限。百思买从一种重要访问模式中移除了长期共享凭据。这让其安全团队需要管理的机密更少，用户归因也更清晰。

在全面扩展时，结果能否继续保持可控，将取决于访问审查、策略质量、服务覆盖范围和事件处理表现。这些结果尚未公布。

三个信号将显示该模式能否扩展

下一项考验是运营证据：更广泛的采用必须在不于其他地方重建管理负担的前提下，保持个人可追责性。

第一个信号是百思买目标员工队伍中使用联邦身份验证进行活跃云访问的比例。该公司表示正在扩展这一架构，但尚未提供迁移时间表或完成指标。

如果大规模推广且例外有限，将增强无状态员工身份能够在零售规模下应用的论据。若服务帐户例外不断增加，则表明工具兼容性或工作流设计仍然受到约束。

真正有用的指标并不只是已接入用户的数量。Best Buy 应评估还有多少交互式连接依赖长期有效凭据，同时追踪新员工、岗位调动人员和离职人员获得正确访问权限的速度。

第二个信号是授权与审计结果的质量。具名访问应能减少含糊不清的日志记录，并加快调查速度。Best Buy 尚未公开证据表明这些改进是否已经实现。

安全团队应关注错误的属性映射、意外权限、令牌交换失败，以及员工状态变化后访问权限仍然保留的情况。手动轮换密钥工作的减少，将证明联邦机制消除了运营债务，而非只是将其转移。

授权错误增加会削弱此次部署的核心承诺。这一结果可能表明，身份同步被同样棘手的策略维护所取代。

第三个信号是该零售商如何处理非人类 AI 访问。员工联邦机制面向员工及其他人类用户。AI 代理、流水线、笔记本和定时任务仍需要独立的机器身份。

成熟的扩展方案会让这些机器身份与员工身份保持分离，同时将每一个身份关联到负责人、用途和权限范围。它不应仅因为自动化系统需要无人值守访问，就重新依赖可下载的密钥。

这正是 Best Buy 的项目可能影响其他企业的地方。重要的先例并不是员工获得单点登录——企业多年来一直在提供这种体验。

真正的先例是，一家公司可以在保留现有 Microsoft 身份授权体系的同时，在 Google 平台上扩展分析与 AI。它可以做到这一点，而无需在员工与云资源之间再加入另一项长期有效凭据。

如果此次部署成功，身份联邦将成为多云 AI 采用的赋能层。技术负责人可以选择数据和模型服务，而无需为每个平台再创建一个员工目录。

如果进展不顺，问题很可能会出现在例外处理、策略映射、服务限制和恢复流程中。这些细节决定了该架构能否超越经过精心挑选的 BigQuery 用例而真正发挥作用。

对开发者而言，直接结果更容易看见。他们可以继续使用既有的企业登录方式，同时审计记录能够识别其操作。他们不再需要将共享密钥视为访问云端数据的代价。

对安全团队而言，工作发生了变化，而非消失。他们需要管理信任关系、访问属性、会话规则、紧急通道和机器身份。这些控制更加集中，但错误也可能影响更广泛的人群。

对企业采购方而言，Best Buy 的决定提出了一个实用的评估问题：云平台是否接受已管理你们员工队伍的身份体系，还是要求另建一个身份存储和生命周期流程？

Best Buy 为其 Google Cloud 扩展选择了第一条路径。该架构在分析和 AI 使用扩展至更大规模员工队伍之前，消除了一个已知障碍。未来几个月应能揭示，采用情况、审计质量和机器身份控制是否足以支撑这种信心。

考虑进行同样转变的组织，应从自身的访问证据开始。识别哪些环节的人类用户仍在使用服务账号密钥，确定哪些云服务接受联邦身份，并衡量撤销权限传达到活跃会话的速度。Google Cloud 联邦机制的价值体现在这些结果得到改善，而不只是登录界面发生变化。