本页内容的上次更新时间为 2024 年 5 月，代表截至本文撰写之时的状况。由于我们会不断改善对客户的保护机制，Google 的安全政策和系统今后可能会发生变化。
本文档介绍了我们如何使用代码审核、安全基础架构以及名为 Binary Authorization for Borg (BAB) 的强制执行检查来帮助保护 Google 的软件供应链免受来自内部人员的风险。BAB 有助于降低来自内部人员的风险，因为它可确保在部署生产软件之前对其进行审核和批准，尤其是在代码可以访问敏感数据时。BAB 适用于在 Borg 上运行的所有服务。自本文档原始发布以来，我们将 BAB 的主要概念添加到了名为软件制品的供应链等级 (SLSA) 的开放式规范中。
本文档是技术白皮书系列中的一篇，该系列介绍了 Google 安全团队为帮助提升安全性而开发的一些项目（包括 BeyondCorp 和 BeyondProd）。如需大致了解我们的基础架构的安全性，请参阅 Google 基础架构安全设计概览。
简介
来自内部人员的风险 代表对用户数据安全的威胁，该数据可能包括雇佣数据、财务数据或其他专有数据或商家数据。 来自内部人员的风险是员工利用其组织知识或访问权限来执行恶意操作的可能性，或者是外部攻击者利用员工被盗用的凭据来执行相同操作的可能性。
为了最大限度地降低软件供应链中来自内部人员的风险，我们使用 BAB。BAB 是部署软件时进行的内部强制执行检查。BAB 可确保代码和配置部署满足特定的最低标准并支持生产系统中的统一性。
我们可阻止员工单方面访问 ，从而帮助保护生产系统中的用户数据。BAB 有助于确保员工独自操作时无法在没有适当授权和理由的情况下直接或间接访问或以其他方式影响用户数据。BAB 及其相关控制措施有助于我们强制执行最小权限，从而改善安全状况，这与特定威胁执行者无关。换句话说，无论执行者是怀有恶意、其账号遭到盗用，还是意外获得授权，BAB 都会阻止单方面访问。
BAB 的优势
采用 BAB 和容器化部署模型可为 Google 基础架构提供许多安全优势。这些优势包括：
- BAB 有助于降低来自内部人员的整体风险：BAB 要求代码先符合某些标准和变更管理做法，然后代码才能访问用户数据。此要求可以降低独立操作的员工（或被盗用的员工账号）以编程方式访问用户数据的可能性。
- BAB 支持生产系统的统一性：通过使用容器化系统并在部署之前验证其 BAB 要求，我们的系统更易于调试、更可靠，并且具有明确定义的变更管理流程。BAB 要求提供了生产系统需要的通用语言。
- BAB 规定了数据保护的通用语言：BAB 会跟踪 Google 各个系统的一致性。有关此一致性的数据已在内部发布，可供其他团队使用。发布 BAB 数据可让团队在相互交流数据访问保护时使用通用术语。这种通用语言可以减少跨团队处理数据时所需的往返工作。
- BAB 允许以编程方式跟踪合规性要求：BAB 简化了之前的手动合规性任务。Google 的某些流程要求更严格地控制数据的处理方式。例如，我们的财务报告系统必须遵守《萨班斯-奥克斯利法案》(SOX)。在使用 BAB 之前，我们有一套系统，可帮助我们手动执行验证以确保合规性。在引入 BAB 后，许多此类检查都是根据服务的 BAB 政策自动执行的。通过自动执行这些检查，合规性团队可以扩大服务范围并对这些服务采取适当的控制措施。
BAB 是大型 BeyondProd 框架的一部分，用于降低来自内部人员的风险。
我们的开发和生产流程
默认情况下，Google 的开发和生产流程包括四个强制执行的步骤：代码审核、可验证的构建、容器化部署和基于服务的身份。下面几个部分将详细介绍这些步骤。
第 1 步：代码审核
大部分源代码都存储在中央单体式代码库 中，并且需要除开发者以外的至少一位工程师的审核和批准 。单体式代码库使得强制执行代码审核的单一关卡成为可能。
代码审核流程至少要求对系统的代码修改必须得到该系统所有者的批准。
从第三方 或开放源代码导入更改时，我们会验证更改是否合适（例如，最新版本）。 但是，对于外部开发者对我们所使用的第三方或开放源代码所做的每一项更改，我们通常不实施相同的审核控制措施。
第 2 步：可验证的构建
构建系统 类似于 Bazel，该系统会构建和编译源代码，以创建用于部署的二进制文件。构建系统在隔离且锁定的环境中运行 ，该环境与执行构建的员工是分开的。对于每个构建，系统都会产生由可验证的构建生成的出处 。此出处是一个签名证书，描述了构建涉及的源代码和依赖项、任何二进制文件或其他构建工件的加密哈希以及所有构建参数。此出处可实现以下各项：
- 能够将二进制文件追溯到在其创建过程中使用的源代码。扩展后，出处还可以追溯其描述的源代码的创建和提交流程。
- 能够验证二进制文件是否未被修改，因为对该文件的任何更改都会自动使其签名失效。
由于构建操作可以是任意代码，因此构建系统已针对多租户进行了安全强化。换句话说，构建系统的设计可以防止一项构建影响任何其他构建。如果构建进行的更改可能会危害构建出处的完整性或系统本身的完整性，则系统会加以阻止。构建完成后，系统会使用 Borg 部署更改的内容。
第 3 步：容器化部署
构建系统创建二进制文件后，该文件会被封装到容器映像中 ，并作为 Borg 作业 部署到集群编排系统 Borg 上。 我们在多个集群中运行来自许多不同应用的数十万个作业，每个集群包含多达数万台机器。尽管规模非常庞大，但我们的生产环境具有相当高的同构性。因此，我们可以更轻松地控制和审核访问用户数据的接触点。
容器 具有显著的安全优势。容器是不可变的，需要通过重新构建完整的映像来频繁地重新部署。容器化使我们能够在上下文中查看代码更改情况，并为部署到基础设施中的更改提供单一的关卡。
Borg 作业的配置 指定要部署的作业的要求：容器映像、运行时参数、参数和标志。Borg 会根据作业的限制条件、优先级、配额以及配置中列出的任何其他要求来安排作业。部署作业后，Borg 作业可以与生产环境中的其他作业进行交互。
第 4 步：基于服务的身份
Borg 作业以服务身份运行。 此身份用于访问其他服务的数据存储区或远程过程调用 (RPC) 方法 。多项作业可以使用同一身份运行。只有负责运行服务的员工 （通常是站点可靠性工程师 [SRE]）可以使用特定身份部署或修改作业。
Borg 启动作业时，会为作业预配加密凭据。 作业在使用应用层传输安全 (ALTS) 发出其他服务的请求时，会使用这些凭据来证明其身份。 如需让某项服务访问特定数据或其他服务，其身份必须具有必要的权限。
我们的政策要求对有权访问用户数据或任何其他敏感信息的服务身份进行 BAB 保护。 无权访问敏感数据的质量保证和开发作业可以在受到较少控制的情况下运行。
BAB 的工作原理
BAB 与 Borg 集成 ，确保只有已获授权的作业可以使用每项服务的身份运行。BAB 还会创建启用了 BAB 的作业中使用的代码和配置的审核跟踪记录 ，从而允许监控和突发事件响应。
BAB 旨在确保所有生产软件和配置都经过适当审核、签入、以可验证的方式构建、授权，尤其是在该代码可以访问用户数据时。
服务专用政策
服务所有者将其服务加入 Borg 后 ，他们会创建一项 BAB 政策来定义其服务的安全要求。此政策即为“服务专用政策”。定义或修改政策本身是一种更改代码的操作，必须经过审核。
服务专用政策定义了允许以服务的身份运行的代码和配置，以及该代码和配置的必需属性。以服务身份运行的所有作业都必须符合服务专用政策。
Google 的所有 Borg 服务都必须配置服务专用政策。
默认情况下，此做法会强制满足以下要求：
- 代码必须可审核： 我们可以通过可验证的构建生成的出处将容器映像追溯回易于用户理解的来源。保留政策会将易于用户理解的代码来源保留至少 18 个月，即使代码未提交也是如此。
- 必须提交代码： 代码是从源代码库中指定的定义位置构建的。提交通常意味着代码已经过审核。
- 必须提交配置： 在部署期间提供的任何配置都会经过与常规代码一样的审核和提交流程。因此，如果没有进行审核，则无法修改命令行标志值、实参 (Argument) 和形参 (Parameter)。
无权访问敏感数据的服务（或者在极少数情况下，具有有效且已获批准的例外情况的服务）可能具有更宽松的政策，例如仅要求代码可审核性的服务，甚至是完全关闭 BAB 的服务。
强制执行 BAB 的系统和组件必须通过严格的自动化要求和额外的手动控制措施进行严格控制。
强制执行模式
BAB 使用两种强制执行模式，以确保作业符合服务专用政策：
- 部署时强制执行，用于阻止部署不合规的作业。
- 持续验证，用于监控已部署的不合规作业并发出提醒。
此外，在紧急情况下，紧急响应过程可以绕过部署时强制执行。
部署时强制执行模式
Borg Prime 是 Borg 的集中式控制器，充当 ALTS 的证书授权机构。提交新作业后，Borg Prime 会在自己向作业授予 ALTS 证书之前“咨询”BAB，以验证作业是否符合服务专用政策中规定的要求。这项检查充当准许控制器：Borg 仅在作业满足服务专用政策的情况下启动作业。即使发出部署请求的员工或服务以其他方式获得授权，系统也会执行此检查。
在极少数情况下，服务可以选择部署时不强制执行，并且有充分的理由。
持续验证模式
部署作业后，无论其在部署时是否处于强制执行模式，它都会在生命周期内进行持续验证。BAB 进程每天至少运行一次，以检查已启动（并且可能仍在运行）的作业是否符合其政策的任何更新内容。 例如，持续验证模式会不断检查使用过期政策运行的作业或使用紧急响应过程部署的作业。如果发现作业不符合最新政策，则 BAB 会通知服务所有者，以便他们缓解风险。
紧急响应过程
如果发生突发事件或服务中断，我们的首要任务是尽快恢复受影响的服务。在紧急情况下，可能需要运行尚未审核或以可验证的方式构建的代码。因此，可以使用紧急响应标志替换强制执行模式。 如果本来应该阻止部署的 BAB 出现故障，则紧急响应过程也会充当备用过程。开发者使用紧急响应过程部署作业时，必须在其请求中提交理由。
在紧急响应期间，BAB 会记录关联的 Borg 作业的详细信息，向 Google 的集中式安全团队 和拥有服务身份的团队发送通知。 该日志条目包含对已部署代码以及用户提供的理由的快照引用。紧急响应过程只应作为最后的办法来使用。
将 BAB 扩展到其他环境
最初，BAB 仅支持保护 Borg 作业，并要求使用 Google 的传统源代码控制、构建和封装流水线来开发软件。现在，BAB 增加了对保护其他软件交付和部署环境的支持，以及对替代源代码控制、构建和封装系统的支持。各种环境的实现细节不同，但 BAB 的优势仍然存在。
在少数情况下，不适合在部署之前进行人工代码审核，特别是机器学习代码和高频数据分析的迭代开发。在这些情况下，我们有替代控制措施来补偿人工审核。
在您的组织中采用类似的控制措施
本部分介绍了我们实施 BAB 时学习的最佳实践，以便您可以在您的组织中采用类似的控制措施。
创建同构容器化 CI/CD 流水线
采用 BAB 更轻松，因为大多数团队使用单一源代码控制系统、代码审核流程、构建系统和部署系统。代码审核已经成为我们的文化的一部分，因此我们能够在不进行太多用户可见更改的情况下进行更改。如需采用 BAB，我们专注于代码审核、可验证的构建、容器化部署以及用于访问权限控制的基于服务的身份。这种方法简化了 BAB 的采用，并加强了 BAB 等解决方案能够提供的保证。
我们广泛使用微服务和基于服务的身份（例如服务账号），而不是基于主机的身份（例如 IP 地址），让我们能够对允许运行每项服务的软件进行精细控制。
如果您的组织无法直接采用服务身份，您可以尝试使用其他措施保护身份令牌，作为临时步骤。
确定您的目标，并根据您的要求定义政策。
逐步构建政策驱动型发布流程。在 CI/CD 流水线中，某些更改可能需要比其他更改更早地实施。例如，您可能需要开始进行正式的代码审核，然后才能在部署时强制执行审核。
政策驱动型发布流程的一个强大推动因素是合规性。如果您可以在政策中至少对某些合规性要求进行编码，则有助于自动执行测试并确保它们可靠有效。您可以从一组基本要求开始，然后再逐步编写更高级的要求。
在开发初期强制执行政策
如果事先没有了解某一款软件的预期运行位置以及该软件将会访问哪些数据，则很难针对该软件定义全面的政策。因此，服务专用政策强制执行是在部署代码时以及访问数据时（而不是构建代码时）完成的。政策是根据运行时身份定义的，因此相同的代码可以在不同的环境中运行，并受不同政策的约束。
除了其他访问机制以外，我们还使用 BAB 限制对用户数据的访问。服务所有者可以进一步确保只有满足特定 BAB 要求的作业才能访问数据。
跨团队招募更改代理
我们在整个 Google 范围要求强制实施 BAB 部署时 ，影响成功率的最大因素是寻找所有者来推动每个产品组的变化。找出一些能立即体会到强制执行的优势并愿意提供反馈的服务所有者。在进行任何强制性更改之前请这些所有者自愿参与。我们得到他们的帮助后，成立了一个正式的变更管理团队来跟踪正在发生的变化。随后，我们确定了每个产品团队中负责的所有者，以实施更改的内容。
确定如何管理第三方代码
如果必须管理第三方代码，请考虑如何将政策要求引入第三方代码库。例如，您可以先保留一个包含使用的所有第三方代码的代码库。我们建议您定期根据您的安全要求检查该代码。
如需详细了解如何管理第三方代码，请参阅分享在构建更安全的开源社区时取得的成功。
后续步骤
- 了解用于为微服务构建安全边界的 BeyondProd。
- 如需采用安全的 CI/CD 流水线，请参阅软件工件的供应链级别 (SLSA)。