前言

在上一篇文章中我们介绍了零信任概念的发展历程，梳理了常见的零信任架构组成部分，本次来分析下比较成熟的Google BeyondCorp零信任架构建设方案和实施效果。

Google BeyondCorp/BeyondProd

Google在经历了Aurora事件后就开始着手内部的零信任架构建设。

2014 年，谷歌基于内部项目 BeyondCorp 的研究成果陆续发布 6 篇相关论文，介绍零信任落地实践。

BeyondCorp 的目标是：摒弃企业特权网络并开创一种全新访问模式

在这种全新的无特权网络访问模式下，访问只依赖于设备和用户凭证，而与用户所处的网络位置无关，无论用户是在公司“内网”、家庭网络、酒店还是咖啡店的公共网络，所有对企业资源的访问都要基于设备状态和用户凭证进行认证、授权和加密。

这种新模式可以针对不同的企业资源进行细粒度的访问控制，所有谷歌员工都可以从任何网络成功发起访问，无需通过传统的 VPN 连接进入特权网络，除了可能存在延迟差异外，对企业资源的本地和远程访问用户体验基本一致。

2015年，Google公开了他们的架构Borg容器化（论文地址：https://research.google/pubs/pub43438/），Borg 是 Google 的集群管理系统，用于大规模调度和运行工作负载。Borg 是 Google 的首个统一容器管理系统，也是 Kubernetes 的灵感来源。Google 的基础架构将工作负载作为单独的微服务部署在容器中，并使用 Borg（容器编排系统）管理这些工作负载。这就是如今众所周知的“云原生”架构的灵感和模板。

Google 的基础架构在设计时就充分考虑了安全性，而不是后来才想起要添加安全功能。Google的基础架构假定其服务之间不应互相信任，也就是在Borg的过程中涉及了ALTS（在容器层上构建了一套基础设施安全层）， 默认开启加密mTLS、默认针对gRPC进行鉴权和授权以及默认身份绑定实体（人、机器、容器）等，同时Google为了提升安全性，把可信计算也加入了其中，为达到的目的就是保证整个身份体系中整个ALTS根证书的安全性。

2019年,Google发布白皮书BeyondProd: A new approach to cloud-native security,介绍了其最新的云原生安全模型。

BeyondProd 有意收回了 BeyondCorp 的概念。正如边界安全模型不再适合最终用户一样，BeyondCorp 也不再适用于微服务。对原始 BeyondCorp 论文的修改：“此模型的关键假设已不再成立：边界不再仅仅是企业 [数据中心] 的实际位置，并且边界内的领域不再是托管个人计算设备和企业应用 [微服务] 的安全可靠之处”。

于是正如 BeyondCorp 帮助google超越了基于边界的安全模型一样，BeyondProd 在生产环境安全性方面实现了类似的飞跃。BeyondProd 方法描述了一种云原生安全架构，该架构假定服务之间没有信任、隔离工作负载、验证是否仅部署了集中构建的应用、自动执行漏洞管理以及对重要数据强制执行有力的访问权限控制。基于 BeyondProd 架构，Google 开发了多个新的系统，以满足这些要求。

在用BeyondCorp实现开发环境（Corp Environment）的零信任时，Google 对员工进行身份管理和多因子认证。与此同时，建立了一套管理公司设备的流程，每个公司设备都配备TPM模块和操作系统完整性验证。这两项工作确保了正确的人用正确的设备提供可信的认证信息。最后，再利用这些认证信息对员工访问开发环境进行持续访问控制。

在用BeyondProd实现生产环境（Prod Environment）的零信任时，BeyondProd面对的问题是，生产环境并不存在与人的直接交互，于是建立了一套把生产环境中的软件溯源到这些软件的开发者（Software Provenance)，从对开发者的认证和开发流程的加固开始，确保没有任何单人能够改变生产环境中的软件的行为（No Unilateral Change)。

接下来从2个Google零信任部署实例(BeyondProd)来看其建设逻辑：第一个是用户如何获取自己的数据，第二个是开发者如何通过修改源代码来改变生产环境中的数据访问行为。谷歌对这两个案例的数据访问控制都遵循零信任的原则。

用户访问自己的数据

当用户通过谷歌的服务访问自己的数据时，请求会通过用户和Google Front End(GFE)之间的加密连接（TLS）首先到达GFE。GFE转用更加高效和安全的协议和数据结构将用户请求分发到各个后端服务共同完成用户请求。例如TLS会被换为Application Layer TLS(ATLS)。面向用户的口令会被转换为更加安全的End User Context Ticket(EUC)。这些置换旨在根据实际请求降低内部连接和令牌的权限，使得特定的ATLS和EUC只能访问局限于此次请求的数据和权限。

开发者改变软件数据访问行为

当开发者希望通过改变服务的代码来改变一个服务的数据和权限访问行为时（开发者无法获取生产主机的任意指令运行权限，如SSH）,该代码修改会经过一系列的流程来将对开发者及其团队的信任转化为对新的服务的信任：流程中所有涉及的人员均通过多因子认证来确立身份，代码修改会被一个或以上有审批权限的人评估，只有获得足够多的授权的代码才会被合并入中央代码库，中央代码库的代码会被一个同样受BAB保护的可信构建服务集中构建，测试和签名，构建后的软件会在部署环节通过目标服务的BAB策略认证（比如GMail的服务只能运行代码库特定位置的经过充分代码评估和测试的代码），软件运行时也会根据相应的BAB安全策略进行运行时隔离：不同BAB服务策略管辖的服务会被运行在不同的隔离区。

为了实现整套流程，google实现了以下几项内部安全工具/服务

在边缘保护网络，Google Front End (GFE) ，用于管理传输层安全协议 (TLS) 终止和传入流量政策

• Google Front End (GFE) ：终止与最终用户的连接，并为强制执行传输层安全协议 (TLS) 最佳做法提供一个中心点。即使重点已不再是基于边界的安全性，但 GFE 仍是保护内部服务免受拒绝服务攻击的重要策略部分。GFE 是用户连接到 Google 的第一个入口点；在基础架构中，GFE 还负责根据需要在区域之间平衡负载和重新路由流量,同时是将流量路由到适当微服务的边缘代理。

流量传输方面，自行开发了 应用层传输安全 (ALTS) ，用于远程过程调用 (RPC) 身份验证、完整性、加密和服务身份

• 应用层传输安全 (ALTS) ：用于远程过程调用 (RPC) 身份验证、完整性和加密。ALTS 是一种用于 Google 基础架构服务的相互身份验证和传输加密系统。身份通常绑定到服务，而不是绑定到特定的服务器名称或主机。这有助于实现跨主机的无缝微服务复制、负载平衡和重新调度。

在代码可信方面，使用适用于 Borg 的 Binary Authorization (BAB) ，用于代码出处验证,主机完整性 (HINT) ，用于机器完整性验证

• 适用于 Borg 的 Binary Authorization (BAB) ：一种部署时强制执行检查，用于确保代码在部署之前满足内部的安全性要求。BAB 检查包括由另一位工程师审核更改的内容、将代码提交到源代码库，以及在专用基础架构上以可验证的方式构建二进制文件。在基础架构中，BAB 会限制未经授权的微服务的部署。
• 主机完整性 (HINT) ：通过安全启动过程验证主机系统软件的完整性，并基于受支持的安全微控制器硬件运行。HINT 检查包括 BIOS、BMC、引导加载程序和操作系统内核上的数字签名验证。

用于跨服务强制执行一致政策的关卡，服务访问政策 ，用于限制服务之间的数据访问方式，最终用户上下文 (EUC) 标签，用于证明原始请求者的身份

• 服务访问政策 ：限制服务之间的数据访问方式。当远程过程调用 (RPC) 从一项服务发送到另一项服务时，服务访问政策会定义访问接收服务数据所需的身份验证、授权和审核政策。这样会限制数据的访问方式、授予所需的最低访问权限级别，以及指定如何审核该访问权限。在 Google 的基础架构中，服务访问政策会限制一项微服务对另一项微服务数据的访问，并允许从全局级别分析访问控制措施。
• 最终用户上下文 (EUC) 标签 ：这些标签由最终用户身份验证服务发出，并为服务提供用户身份（独立于其服务身份）。这些是受到完整性保护、集中发放、可转发的凭据，用于证明发出服务请求的最终用户的身份。这样可以减少服务之间的信任需求，因为通过 ALTS 的对等方身份通常不足以授予访问权限，此类授权决策通常也基于最终用户的身份。

简单、自动化、标准化的更改发布，Borg 工具 ，用于蓝绿部署

• 用于蓝绿部署的 Borg 工具 ：此工具负责在执行维护任务时迁移正在运行的工作负载。除了现有的 Borg 作业之外，系统还会部署新的 Borg 作业，负载平衡器会逐渐将流量从一项作业转移到另一项作业。这样，在用户不知不觉中，系统就可以在不停机的情况下更新微服务。此工具用于在添加新功能时应用服务升级，以及在不停机的情况下应用重要的安全更新（例如，针对“心脏出血”Bug 和 Spectre/Meltdown 漏洞的安全更新）。对于影响 Google Cloud 基础架构的更改，会使用实时迁移来确保虚拟机工作负载不受影响。

工作负载之间进行隔离，gVisor，用于工作负载隔离

• gVisor :用于工作负载隔离。gVisor 使用用户空间内核来拦截和处理系统调用，从而减少与主机和潜在攻击面的交互。此内核提供了运行应用所需的大部分功能，并限制应用可访问的主机内核表面。在 Google 的基础架构中，gVisor 是用于隔离同一主机上运行的内部工作负载和 Google Cloud 客户工作负载的几种重要工具之一。

总结

从安全建设的角度出发，零信任架构的发展将是一个长期持续的过程，后续我们会持续提供具有实际参考价值的方案与论点共业界学习。