本页内容的上次更新时间为 2024 年 6 月，代表截至本文撰写之时的状况。由于我们会不断改善对客户的保护机制，Google 的安全政策和系统今后可能会发生变化。
Google 运行着一个全球规模的多租户分布式计算基础设施，可为全球数十亿用户提供产品和服务。此基础设施必须平衡安全性、可靠性、弹性、效率、开发速度、可调试性等相互竞争的优先级。
本文档介绍了我们为在 Google 生产环境中运行的服务维护业界领先的安全状况所采用的一些机制。这些服务涵盖了安全敏感度的各个方面，从无法访问任何敏感数据的开发实验到关键身份基础设施。这些服务可完成处理用户数据、管理软件发布以及个别物理机器的预配和生命周期管理等任务。
本文档介绍了有助于保护我们基础设施的以下三个关键层的安全控制措施：
- 生产服务，包括最注重安全性的服务（也称为基础服务）
- 生产机器
- 生产工作负载
我们应用这些控制措施，使 Google 员工只能出于合法业务目的（例如维护访问）访问服务、机器和工作负载，并防范内部风险和人员账号盗用。这些控制措施提供进一步的深度防御保护，对现有的基础设施安全控制措施进行补充，有助于防止账号泄露。
持续改进
本文中介绍的控制措施将在 Google 的整个生产环境中使用。许多服务（包括基础服务）都使用我们提供的最新级别的控制措施。不过，由于 Google 基础设施的范围和复杂性，各个生产服务通常具有独特的要求，并且可能需要额外的时间来实现最新的建议。秉承持续改进的文化，Google 的站点可靠性工程 (SRE) 团队和安全团队会不断调整安全控制措施，以应对不断变化的威胁形势。
保护生产服务
Google 帮助保护生产服务的完整性，以便 Google 员工只能出于合法业务目的（例如维护目的）访问这些服务。获取对生产环境中运行的服务的访问权限有两种主要方法：通过管理员权限和通过软件供应链。
以下列表介绍了有助于保护每个访问路径的控制措施。
管理员权限控制：生产服务需要定期维护（例如，二进制文件或配置发布）。Google 的目标是，遵循零触摸生产理念，通过自动化、安全代理或经过审核的紧急访问来执行此类操作。禁止人类访问生产资源的一套控制措施称为无人访问 (NoPe)。借助 NoPe，Google 可以灵活地部署访问权限控制，这些控制基于生产服务的敏感度以及通过持续改进，实现更强大态势的准备情况。
例如，Google 不允许单方面访问基础服务，即使是紧急访问需要其他 Google 员工的批准。如果某人无需获得其他获授权个人的任何批准即可执行访问操作，则该访问操作为单方面访问。
软件供应链控制：Google 的大多数生产工作负载（包括基础服务）运行的二进制文件和作业配置都是通过可验证的方式进行构建，其源代码来自可信来源并经过同行评审。我们使用 Binary Authorization for Borg (BAB) 强制执行此流程。
下图显示了有助于保护生产服务的控制措施。
在应用最高级别的 NoPe 和 BAB 时，我们会帮助确保任何人员（即使在紧急情况下）都无法单方面访问基础服务，并且他们获得的任何特权访问权限都具有明确定义的范围和时长。特许访问权限是一种高级访问权限，可授予人员在自动化无法解决的特殊情况下管理关键生产服务。我们对此规则进行了例外处理，以确保 Google 能够顺利摆脱锁定情况。
许多其他生产服务（包括 Firestore 或 Cloud SQL 等产品以及 Borg 和 Spanner 等内部基础设施产品）都配置为使用最高级别的 NoPe 和 BAB，我们会不断努力，让生产服务所有者能够随着时间的推移更轻松地采用 NoPe 和 BAB。
管理员权限控制
在 Borg 上，生产角色的成员可以读取、写入或删除生产角色拥有的数据，并且可以使用角色的权限执行代码。生产角色是一种身份，可在 Google 的生产环境中运行工作负载。
生产角色中的永久成员资格会带来生产的意外后果，以及这些权限被滥用的风险。不过，SRE 的使命要求各团队有权维护其负责的服务，因此完全移除访问权限可能不是一种可行的策略。
NoPe 套件提供了一种配置访问权限的方法，可以平衡授权团队和保证生产系统安全之间的相互竞争的需求。启用 NoPe 后，Google 员工在尝试访问生产服务时会遇到账号权限限制。NoPe 允许以下限制条件：
- 访问请求需要审批人和理由：名为多方授权 (MPA) 的控制措施有助于确保 Google 员工在没有业务理由和未经有权验证访问请求的另一个人的批准的情况下无法访问生产服务。
- 无权直接访问生产服务角色：人员只能通过 NoPe 的安全代理访问生产服务。安全代理的设计使得只能执行一组明确定义的命令。Google 安全和 SRE 组织认为任何有风险的命令（例如，关闭服务或者访问或删除数据）也要求使用 MPA。
- 无永久性生产环境角色成员资格：名为按需访问 (AoD) 的控制措施要求人员申请临时成员资格，而不是允许人员账号始终拥有访问权限。此控制有助于确保系统仅出于特定原因临时授予提升的权限。
- 监控员工对生产服务的访问请求：Google 要求定期审核运行生产服务的生产角色的访问模式。此审核旨在通过不断改进管理 API，让您日后无需再提出此类请求。应仅在紧急响应情况下保留对生产服务的访问权限。对于基础服务，授予访问权限的情况非常少，因此安全团队会对每个授予的访问权限进行审核，以确认其有效性。
以下各部分详细介绍了每种控制措施。
NoPe 多方授权
MPA 要求其他获授权的 Google 员工批准访问请求。
对于访问足够敏感的服务的请求，MPA 还要求人员提供业务理由，并在每个请求中引用正在进行的生产紧急事件。
这两种条件都是防范滥用访问权限。
NoPe 的安全代理
安全代理是公开一组预定义命令的工具，安全代理可以代表调用者执行这些命令。安全代理会实现基于规则的精细授权政策，以限制对生产服务的访问。例如，这些政策可能会要求获得另一位获授权人员的批准，才能执行可能会对安全性或可靠性产生不利影响的命令（例如删除文件的命令）。政策还可以让某些安全命令（例如，列出资源利用率的命令）无需批准即可执行。这种灵活性对于最大限度地减少运维工作至关重要。
在发生访问权限滥用行为时，账号仍会受到安全代理允许的操作的限制。该账号只能单方面执行安全命令，而特权操作需要获得其他获授权个人的批准。所有操作都会留下明确的审核跟踪记录。
如需详细了解安全代理，请参阅有关“零触摸生产”的 SREcon 演示文稿。零触摸生产是一套原则和工具，强制要求生产中的每项变更都由自动化（无需人工参与）执行、通过软件预先验证或使用经过审核的应急机制进行。
按需访问
借助按需访问 (AoD)，Google 可以将永久会员资格替换为符合条件的会员资格，从而减少人员权限。
角色中符合条件的成员无权访问其权限。相反，如果符合条件的角色成员需要访问权限，则可以申请临时成员资格，称为“AoD 授权”。如果其他授权个人批准，AoD 授权将使请求者在有限的时间内成为角色成员，通常不超过一天。
借助符合条件的成员资格模型，人员只需在需要时请求所需的访问权限子集。从概念上讲，您可以将 AoD 视为有时限的生产 sudo，类似于 Unix 中的 sudo -u 命令，可让您使用与指定用户关联的提升权限执行某些命令。但是，与 Unix sudo 不同，接收 AoD 授权需要业务理由和 MPA，并留下审核跟踪记录。AoD 授权也有时间限制。
保护符合条件的成员资格背后的敏感权限意味着，即使在不太可能滥用访问权限的情况下，账号也只能在存在有效授权时访问这些权限。采用安全代理在很大程度上消除了此类授权的需求。
访问请求监控
虽然 Google 生产的许多领域使用 NoPe 作为访问权限缩减做法，但对于我们最敏感的生产角色而言，AoD 授权非常罕见，并且仅预留给紧急响应。此外，每个事件都会触发事后手动审核。审核的目标是降低日后 AoD 授权的频率（例如，通过这些事件来激励改进管理 API）。
Google 会持续监控整个公司范围内的 AoD 授权以及在持有这些授权期间采取的措施。我们会使用实时监控数据来检测潜在的渗透情况，并确定可以进一步减少访问的区域。如果出现突发事件，审核跟踪记录支持快速响应。
Binary Authorization for Borg
正如 NoPe 有助于保护特权访问路径一样，Binary Authorization for Borg (BAB) 有助于保护 Google 软件供应链。BAB 有助于确保生产软件和作业配置在部署之前得到审核和批准，尤其是在它们可以访问敏感数据时。BAB 最初是为 Google 的生产基础设施设计的，现在，BAB 的关键概念已纳入到名为软件工件的供应链级别 (SLSA) 的开放式规范中。
BAB 有助于确保人员不能在未经同行评审的情况下修改源代码、运行二进制文件或配置作业，并且任何二进制工件或软件配置都是从签入的、经过同行评审的源代码构建而成，并且可验证。
如需了解详情，请参阅 Binary Authorization for Borg。
保护生产机器
除了加固特权访问路径和保持软件供应链的完整性外，Google 还会保护运行生产服务的机器。具体而言，我们会实现以下各项：
Shell 访问权限控制：大多数 Google 员工都没有对生产机器或在 Google 集群管理系统 Borg 上运行的工作负载的 Shell 访问权限（例如通过 SSH）。相反，个人必须使用安全代理，要求其他授权人员在执行命令之前审核和批准每个命令。
只有少数在低级层基础设施上工作的团队保留了非单方面 Shell 访问权限，以便他们可以调试安全代理不实用的最复杂的问题。如果访问需要一个或多个其他授权人员的授权，则访问为非单方面。Google 允许单方面 Shell 访问的例外情况：以确保 Google 有办法摆脱锁定情况。
物理访问权限控制：机器需要定期进行物理维护，以确保其正常运行。为确保数据中心技术人员仅出于正当业务原因访问实体机器，Google 使用物理到逻辑控制。
固件和系统软件控制：Google 实施了基于硬件信任根的测量启动安全流程。硬件信任根有助于确保每台机器的启动固件和系统软件的完整性。
下图显示了有助于保护数据中心机器的控制措施。
Shell 访问权限控制
SSH 是一种开源管理工具，允许对基于 Linux 的服务器进行广泛访问。如果没有对 SSH 访问的控制，则具有正确凭据的账号可以获得一个 Shell，从而能够以难以审核的方式执行任意代码。
通过对生产服务的 Shell 访问，该账号可以更改正在运行的任务的行为、渗漏凭据，或使用凭据在环境中实现持久的基础。
为缓解这种风险，我们使用以下一组控制措施，用安全的替代方法取代对生产机器的 SSH 访问：
- 精简 API：对于之前需要使用 SSH 且工作流已明确定义的团队，我们会将 SSH 替换为定义精确且可审核的 API。
- SSH 的安全代理：对于需要更灵活访问权限的团队，安全代理允许单独对命令进行授权和审核。
- MPA：当 SRE 需要对机器进行紧急 SSH 访问时，Google 要求提供业务理由，并由授权个人批准访问权限。系统会记录完整的 Shell 会话转录内容。
- 锁定场景：允许单方面 SSH 访问时的例外情况。系统会记录完整的 Shell 会话转录内容。
这些控制措施可以平衡对合法 Shell 访问的需求与过于宽泛的 Shell 访问相关的风险。
背景：Google 中的 SSH
过去，Google 使用 SSH 来管理其机器。随着 Borg 的开发，大多数 Google 员工不再需要直接访问运行其二进制文件的 Linux 机器，但出于以下几个原因，Shell 访问仍然存在：
- 人员有时需要直接访问计算机以进行调试。
- SSH 访问是一项有价值的教学工具，可帮助您了解各种抽象层。
- 在意外的灾难恢复场景中，可能无法使用更高级别的工具。
为了平衡这些原因与它们产生的安全风险，Google 研究了一系列里程碑，以逐步消除 SSH 风险，然后加以使用。
集中监控和访问权限控制里程碑
Google 投资了一套名为基于主机身份的监控授权 (HIBA) 的集中 SSH 监控和授权系统。HIBA 可帮助您了解任何 SSH 使用情况，并强制执行严格的授权政策。不仅目标机器会记录 SSH 尝试，集中式 BeyondCorp 代理也会记录。Shell 执行的命令会记录下来，并馈送到恶意行为检测流水线。但是，检测本质上是被动式的，容易受到规避和混淆的影响。
消除单方面准入里程碑
对于大多数人员，Google 已移除对生产机器或在 Borg 上运行的工作负载的 Shell 访问权限（例如通过 SSH）。但是，开发团队仍然可以在测试机器（例如，用于认证新硬件或新的低级别软件但不运行生产服务的机器）上使用该密钥。
精简 API
一些 Google 团队过去依赖 SSH 来运行有限数量的精确定义的命令（例如，在 Playbook 中），或者获取结构可预测的数据，现在使用范围较窄的 API 来提供应用场景，并提供结构化数据。
精简 API 包含与常见用户体验历程相符的少量方法，并抽象化了低级访问详细信息。因此，它们是 Google 的首选解决方案，因为它们可提供最佳安全性和可审核性。通过在 Google 的远程过程调用 (RPC) 基础架构上构建这些服务，我们可以受益于数十年来在安全和审核方面的投资。
SSH 的安全代理
某些 Google 团队无法提前确定他们可能需要的命令。在这种情况下，Google 使用命令运行守护程序，该守护程序仅接受来自安全团队运行的可信代理的任意命令执行请求。该技术类似于 NoPe 的安全代理中使用的技术。
SSH 的安全代理负责对命令执行进行精细授权和审核。授权基于命令的参数和环境、速率限制参数、业务理由以及 MPA。此授权过程可以任意精确地限制哪些命令可以运行以下团队 Playbook 和最佳做法。如果出现现有 Playbook 中未捕获的意外失败情况，在其他获授权的个人批准后，人员仍可以运行必要的调试命令。
SSH 的 MPA
在低层级基础设施上工作的其余几个团队会保留非单方面形式的 Shell 访问权限，以调试最复杂的问题。
锁定场景中的 SSH
Google 会破例允许单方面 Shell 访问，以确保 Google 能够解决锁定情况。用于此用途的 SSH 密钥通过独特的可审核流程生成，并离线存储在防篡改硬件上。使用这些密钥时，系统会记录完整的 Shell 会话转录内容。
物理访问权限控制
Google 数据中心由服务器、网络设备和控制系统组成的复杂环境，需要各种角色和技能来管理、维护和运维。
Google 在机器本身上实现了六层物理控制和许多逻辑控制，以帮助保护数据中心的工作负载。我们还保护机器之间的空间，称为物理到逻辑空间。
物理到逻辑控制通过称为“机器安全加固”“基于任务的访问权限控制”和“系统自防御”来提供额外的防御层。物理到逻辑控制措施可防范企图利用对机器的物理访问权限并升级为对机器工作负载进行逻辑攻击的对手。
如需了解详情，请参阅 Google 如何保护数据中心内的物理到逻辑空间。
固件和系统软件控制
数据中心机器的安全状况在启动时确定。机器的启动过程会配置机器的硬件并初始化其操作系统，同时确保机器能够在 Google 的生产环境中安全运行。
在启动过程的每个步骤中，Google 都会实施业界领先的控制措施，以强制实施我们预期的启动状态并帮助确保客户数据安全。这些控制措施有助于确保我们的机器能够启动其预期软件，从而使我们能够移除可能会损害机器初始安全状况的漏洞。
如需了解详情，请参阅 Google 如何在生产机器上强制执行启动完整性。
保护工作负载
为了遵循我们的零信任理念，Google 还推出了一些控制措施，有助于防范具有不同安全要求的工作负载之间发生的横向移动威胁。Google 基础设施使用称为工作负载安全环 (WSR) 的工作负载层次结构。WSR 有助于确保关键工作负载不会与安全性较低的工作负载调度到相同的机器上，同时避免对资源利用率产生负面影响。WSR 会将工作负载分为四个敏感性类别（基础、敏感、安全加固型和非安全加固型），并尝试将它们调度到不同的机器池中。
下图展示了 WSR 如何在基础、生产和开发机器上进行工作负载分组和调度。
WSR 使用内核漏洞攻击或 CPU 边信道攻击为本地提权提供额外一层防御。WSR 有助于确保只有具有类似安全要求的工作负载才能共同调度到相同的机器。如需实现 WSR，我们需要执行以下操作：
- 根据工作负载的安全要求对工作负载进行分类。每个类都称为工作负载环。
- 将物理机器分布到多个彼此隔离的机器池中。也就是说，我们会消除池之间横向移动的路径。
- 应用调度限制条件以防止具有不同安全要求的工作负载在同一机器上运行。这些调度限制条件可通过本地权限提升来降低危害的风险。
例如，WSR 要求基础工作负载在专用机器上运行，并且绝不与非基础工作负载共同调度。此约束条件可与不太安全的工作负载实现强隔离。
隔离工作负载的方法
现代系统软件非常复杂，安全研究人员会定期发现本地权限提升漏洞，例如内核零日漏洞或新的 CPU 边信道攻击。WSR 最早在 USENIX ;login: 中引入，可让 Google 降低与工作负载共置相关的风险，同时保持较高的资源利用率。
默认情况下，Borg 使用操作系统级进程边界来隔离容器。与使用基于硬件的虚拟化的虚拟机相比，这些进程提供的隔离边界更弱。对于运行可信工作负载的多租户环境，这种较弱的隔离通常是效率与安全性之间的良好权衡。可信工作负载是指二进制文件和配置均通过经过同行评审且来源可靠的代码以可验证的方式构建的工作负载。可信工作负载不会处理任意不可信数据。处理不可信数据的示例包括托管第三方代码或编码视频。
Google 使用 BAB 建立对二进制文件的信任。不过，BAB 不足以确保处理不可信数据的工作负载的完整性。除了 BAB 之外，此类工作负载还必须在沙盒中运行。沙盒是一个受限的环境（如 gVisor），可让二进制文件安全运行。BAB 和沙盒都有局限性。
对于成熟的产品，BAB 是一种强大的控制措施，但可能会在新系统开发的早期阶段以及运行没有敏感数据的实验时降低速度（例如，优化已经公开的数据的编码）。此限制意味着某些工作负载必须始终在没有 BAB 的情况下运行。此类工作负载本质上存在更高的本地特权提升风险（例如，利用内核漏洞获取机器的本地根权限）。
将不可信的工作负载进行沙盒化也可以降低安全风险，但代价是计算和内存使用量会增加。效率可能会下降两位数百分比，具体取决于工作负载和沙盒类型。如需了解沙盒化工作负载的性能影响示例，请参阅 gVisor 性能指南中的详细基准测试。借助 WSR，我们可以解决因隔离工作负载而导致的效率限制。
工作负载环
Google 根据安全要求定义了四种工作负载类别：基础、敏感、安全加固型和非安全加固型。下表更详细地介绍了它们。
| 工作负载环 | 说明 |
|---|---|
| 基础级 | 对 Google 的安全至关重要的工作负载，例如身份和访问管理服务。基础工作负载具有最高的安全性要求，并且通常以效率换取更高的安全性和可靠性。 |
| 敏感 | 可能会导致大规模服务中断或有权访问特定产品的敏感数据（例如用户数据或客户数据）的工作负载。 |
| 安全强化 | 支持安全性要求不高但采用了 BAB 或处于沙盒化状态的工作负载，以便它们对相邻工作负载构成的风险很小。 |
| 非安全加固型 | 所有其他工作负载，包括运行不可信代码的工作负载。 |
在 Google，我们将支持特定产品的关键工作负载归类为敏感工作负载，而基础工作负载是可能影响所有产品的工作负载。
与基础工作负载和敏感工作负载不同，我们可以仅根据任何工作负载采用的控制措施及其处理的输入类型，将任何工作负载归类为“安全加固型工作负载”。对于安全加固型工作负载，我们主要关注它们对其他工作负载的影响，因此加固解决方案安全性可以包括沙盒化。
机器池
为避免将敏感服务与信任度较低的工作负载（例如，在没有沙盒的情况下处理不可信数据的工作负载）共同调度，我们必须在隔离的机器池中运行这些服务。机器隔离可让您更轻松地理解安全不变量，但每增加一个机器池都会在资源利用率和可维护性方面带来权衡取舍。
机器隔离会导致物理资源利用率降低，因为随着我们添加更多池，确保机器池得到充分利用变得越来越困难。如果存在多个大型隔离机器池，效率成本可能会显著增加。
随着每个池中的工作负载的资源量波动，严格隔离会增加管理开销，需要定期重新平衡各池之间的机器并重新利用它们。这种再平衡功能需要从机器中排空所有工作负载、重新启动机器，以及执行我们最繁重的机器清理过程，帮助确保固件真实性和完整性。
这些注意事项意味着，Google 对机器隔离的实现必须提供优化物理资源利用率的方法，同时还要防范攻击者对基础和敏感工作负载的攻击。
在 Kubernetes 中，这种方法称为节点隔离。Kubernetes 节点可以映射到物理机或虚拟机。在本文中，我们将重点介绍物理机器。此外，Compute Engine 等 Google Cloud 产品提供单租户以实现物理机器隔离。
工作负载调度限制
Google 将机器预配到三种类型的隔离池中：基础机器、生产机器和开发机器。Google 运维着多个隔离的池，用于托管基础和敏感工作负载，但本文档为了简单起见，将每个池都视为一个池。
为了提供最有效的保护，我们为 WSR 部署以下调度限制条件：
- 基础工作负载只能在基础机器上运行。
- 敏感工作负载只能在生产机器上运行。
- 非安全加固型工作负载只能在开发机器上运行。
- 安全加固型工作负载可以在生产机器或开发机器上运行，首选生产机器。
下图展示了调度限制条件。
在此图中，隔离边界分隔机器池之间和内部的不同类别的工作负载。基础工作负载是专用基础机器的唯一租户。为生产机器上运行的工作负载提供 Binary Authorization 或沙盒有助于防止本地提权攻击。在开发机器上，非安全加固型作业可能会破坏其他作业，但破坏行为仅限于开发机器，因为安全加固型作业无法创建新作业。
系统会根据可用性在生产机器或开发机器上调度安全加固型工作负载。允许在多个池中进行调度可能看起来违反直觉，但对于缓解调度限制条件导致的利用率下降至关重要。安全加固型工作负载填补了隔离敏感作业和非安全加固型作业所导致的缺口。此外，安全加固型资源占用量越大，其他两个类别的资源使用量波动就越大，而无需在环之间进行昂贵的机器移动。
下图显示了对不同类别的工作负载施加的调度限制条件。安全加固型工作负载可位于生产机器或开发机器上。
通过在多个基础池中隔离基础工作负载，Google 以资源效率换取更高的安全性。幸运的是，基础工作负载的资源占用量往往相对较小，而小型隔离专用机器池对整体利用率的影响可以忽略不计。不过，即使实现了广泛的自动化，维护多个机器池也并非没有代价，因此我们会不断改进机器设计，以提高隔离性。
WSR 可强力保证，绝不允许在基础机器上运行非基础工作负载。基础机器受到保护，不会发生横向移动，因为只有基础工作负载才能在这些机器上运行。
控制摘要
Google 在其基础设施中使用了多种控制措施，以帮助保护生产服务、生产机器和工作负载。控制措施包括：
- 适用于生产服务的管理员权限控制和 BAB
- 适用于生产机器的 Shell 访问控制、物理访问控制以及固件和系统软件控制
- 适用于不同类别工作负载的 WSR
这些控制措施协同工作，强制执行限制，有助于保护 Google 的用户和客户及其数据。下图说明了这些控制措施如何协同工作来支持 Google 的安全状况。
后续步骤
- 如需详细了解 Google 基础设施的安全控制措施，请参阅 Google 基础设施安全设计概览。
- 如需了解 Google 的安全文化，请阅读《构建安全可靠的系统》（O'Reilly 图书）。
- 如需详细了解零触摸生产，请参阅《SREcon 演示文稿》。
作者：Michael Czapiński 和 Kevin Plybon