写在前面

在谷歌近期公开的BeyondProd项目白皮书（《谷歌BeyondProd：一种新的云原生安全方法》）中，详细介绍了谷歌的众多基础架构是如何在云原生（cloud-native）架构中进行协同工作来保护工作负载（workload）的。作为全球最大的网络服务商之一，谷歌基础架构的重要性及对其安全性保障的必要性不言而喻。谷歌一直致力于提升其基础架构全方面的安全能力，在BeyondProd白皮书中，谷歌也特别提到可参考其在2017年发布的这篇安全基础架构设计白皮书来了解其在基础架构中是如何设计基础架构安全的。在此我们也特别翻译了本篇谷歌云白皮书，供业界同仁参考、交流。

关于译者：奇安信身份安全实验室，奇安信集团下属专注“零信任身份安全架构”研究的专业实验室，是业界首部零信任安全技术图书《零信任网络：在不可信网络中构建安全系统》译者。该团队以“零信任安全，新身份边界”为技术思想，推出“以身份为基石、业务安全访问、持续信任评估、动态访问控制”为核心的奇安信零信任身份安全解决方案。该团队结合行业现状，大力投入对零信任安全架构的研究和产品标准化，积极推动“零信任身份安全架构”在业界的落地实践，其方案已经在部委、央企、金融等行业进行广泛落地实施，得到市场、业界的高度认可。

谷歌基础架构安全设计概述

——谷歌云白皮书

本文所包含的内容截止至2017年1月是正确的，代表了截止至本文撰写时的现状。随着谷歌不断提高对用户的安全防护，安全策略和系统可能会发生变化。

面向CIO的概要

  • 谷歌的技术基础架构覆盖全球，可为谷歌信息处理的整个生命周期提供安全保障。该基础架构提供服务安全部署、在保护最终用户隐私的前提下进行数据安全存储、保障服务之间安全通信、确保客户通过互联网进行安全和私密的进行通信，以及使管理员能够安全地进行操作。

  • 谷歌利用这一基础架构来构建其互联网服务，包括个人用户服务如搜索、Gmail和谷歌相册等，以及企业服务如G Suite和谷歌云平台等。

  • 基础架构的安全性是分层逐步设计实现，从数据中心的物理安全开始，再到构成基础架构基础的硬件和软件的安全，最后到支持运营安全的技术约束和流程。

  • 谷歌为保护其基础架构安全性投入巨大，拥有数百名致力于安全和隐私的工程师，其中不乏许多公认的行业权威人士。

简介

本文概述了如何将安全性设计到谷歌的技术基础架构中。这一全球规模的基础架构旨在为谷歌的整个信息处理生命周期提供安全保障。该基础架构提供安全的服务安全部署、在保护最终用户隐私的前提下进行数据安全存储、保障服务之间的安全通信、确保客户通过互联网进行安全和私密的进行通信，以及使管理员能够安全地的进行操作。

谷歌通过这一基础架构来构建其互联网服务，包括个人用户服务如搜索、Gmail和谷歌相册等，和企业服务如G Suite和谷歌云平台。

本文将分层级逐步描述该基础架构的安全设计，首先是数据中心的物理安全，然后是构成基础架构基础的硬件和软件安全，最后将描述支持运营安全的技术约束和流程。

图1. 谷歌基础架构安全层：从位于底层的硬件基础架构到位于顶层的运营安全的各个安全层。文中详细介绍了每层的内容。

底层基础架构安全

本节将描述如何保护基础架构的最底层安全，从物理位置到数据中心的专用硬件，再到运行在每台机器上底层软件堆栈。

物理位置安全

谷歌设计并建立了自己的数据中心，其中包括多层物理安全保护。仅有极少数谷歌员工具有访问这些数据中心的权限。我们使用多个物理安全层来保护数据中心所在位置，并使用生物识别、金属检测、摄像头、车辆屏障和基于激光的入侵检测系统等技术。此外，谷歌还在第三方数据中心托管了一些服务器，除了数据中心运营商提供的安全层之外，我们确保有受谷歌控制的物理安全措施。例如，在这些地点，我们可以运行独立的生物识别系统、摄像机和金属探测器。

硬件设计与供应

谷歌数据中心由数千台连接到本地网络的服务器组成。服务器主板和网络设备都由谷歌定制设计。我们会对合作的组件供应商进行审查，并谨慎选择组件，同时与供应商一起审核和验证组件提供的安全属性。我们还设计定制了目前部署在服务器和外设上的硬件安全芯片。这些芯片允许我们在硬件层面安全地识别和验证过合法的谷歌设备。

堆栈启动和机器身份标识安全

谷歌服务器使用各种技术来确保其正在启动正确的软件堆栈。我们对BIOS、引导加载程序、内核和基本操作系统映像等底层组件使用加密签名。可以在每次启动或更新期间验证这些签名。这些组件全部由谷歌控制、构建和加固。对于每一代新硬件，我们都在不断提高安全性：例如，根据各代服务器设计的不同，我们将启动链的信任建立在可锁定的固件芯片、运行谷歌编写的安全代码的微控制器或上述谷歌设计的安全芯片上。

数据中心中的每台服务器上都有自己的特定身份标识，该标识可以与硬件信任根和机器启动时使用的软件绑定。该身份标识用于验证与机器上底层管理服务之间的API调用。

谷歌还开发了自动化系统，以确保服务器上运行最新版本的软件堆栈（包括安全补丁），来检测和诊断硬件和软件问题，并在必要时将机器从服务中删除。

服务部署安全

在介绍完基础硬件和软件的安全性后，现在我们将继续介绍如何确保在基础架构上安全地部署服务。“服务”是指开发人员编写并希望在基础架构上运行的应用二进制文件，例如，Gmail SMTP服务器、Bigtable存储服务器、YouTube视频转码器或运行客户应用上的应用引擎沙箱。为了处理所需规模的工作负载，可能有数千台机器运行同一服务的副本。运行在基础架构上的服务由名为Borg的群集编排服务控制。

下面将会讲到，基础架构不会假定在基础架构上运行的服务之间存在信任。换句话说，本质上基础架构就是为了适用多租户模式而设计。

服务身份标识、完整性与隔离

谷歌在应用层使用加密身份认证和授权进行服务间通信。这就提供了高度抽象且细粒度的访问控制机制，无论是管理员还是服务都可以理解。

我们不依赖内部网络分段或防火墙作为主要安全机制，不过在网络的各点还是使用了入站和出站过滤作为一层额外的安全防护，用以防止IP欺骗。这种方法也有助于最大限度地提高网络性能和可用性。

在基础架构上运行的每项服务都有一个关联的服务帐户身份标识。为服务提供加密凭据，在服务向其他服务发送或从其他服务接收远程过程调用（RPC）时，可以用这些凭据来证明其身份。客户端使用这些身份标识来确保其正在与正确的目标服务器通信，服务器使用这些身份标识将方法和数据访问限定给指定客户端。

谷歌的源代码存储在中央代码库中，在其中服务的当前和过去版本都可被审计。该基础架构还可以配置为：要求服务的二进制文件由经过特定审查、登记和测试的源代码构建。此类代码审查需要开发者之外的至少一名工程师进行检查和批准，并且系统强制要求对任何系统的代码修改必须得到该系统所有者的批准。这些要求限制了内部人员或攻击者恶意修改源代码的能力，还提供了从服务回溯 到源代码的取证跟踪。

谷歌有多种隔离和沙箱技术，用于保护服务免受运行在同一台机器上的其他服务影响。这些技术包括正常的Linux用户分离、基于语言和内核的沙箱以及硬件虚拟化。总之，我们会为高风险的工作负载使用更多的隔离层；例如，当对用户提供的数据运行复杂的文件格式转换器时，或者当为谷歌应用引擎（Google App Engine）或谷歌计算引擎（Google Compute Engine）等产品运行用户提供的代码时。作为额外的安全防线，特别敏感的服务（如集群编排服务和一些密钥管理服务）将只在专用机器上运行。

服务间访问管理

服务的所有者可以使用基础架构提供的访问管理功能来确切地指定哪些服务可以与其通信。例如，一项服务可能希望仅向列入白名单的其他服务提供一些API。可以使用列了允许的服务账号身份标识的白名单配置该服务，然后基础架构会自动强制执行此访问限制。

访问服务的谷歌工程师也会被授予个人身份标识，因此可以对服务进行类似的配置，以允许或拒绝他们的访问。所有这些类型的身份标识（机器、服务和员工）都位于基础架构维护的全局名称空间中。最终用户的身份标识将分开处理（后文将详细展开）。

谷歌基础架构为这些内部身份标识提供了丰富的身份管理工作流系统，包括审批链、日志记录和通知。例如，可以通过允许两方控制的系统将这些身份标识分配给访问控制组，其中一名工程师可以提议对一个组进行更改，而提议必须得到另一名工程师（同时也是该组的管理员）的批准。此系统允许安全的访问管理进程扩展到基础架构上运行的数千项服务。

除了自动化的API级的访问控制机制外，基础架构还允许服务从中心ACL和组数据库中读取数据，以便其可以在必要时执行自定义的细粒度访问控制。

服务间通信加密

在前面部分讨论的RPC身份验证和授权功能之外，基础架构还通过加密为网络上的RPC数据提供隐私性和完整性。为了向HTTP等其他应用层协议提供这些安全收益，将它们封装在基础架构RPC机制中。这实际上会提供应用层隔离，并消除对网络路径安全性的依赖。即使网络被窃听或网络设备被破坏，经加密的服务间通信仍可保持安全。

服务可以为每个基础架构RPC配置所需的加密保护级别（例如，对数据中心内的低价值数据，可仅配置完整性级别保护）。为了防止高级攻击者窃听我们私有广域网链路，基础架构会自动加密流经数据中心之间广域网的所有基础架构RPC流量，而无需服务本身进行任何具体配置。通过硬件加密加速器的部署，可以将此默认加密扩展到数据中心内的所有基础架构RPC流量。

最终用户数据的访问管理

谷歌服务一般来说就是为服务最终用户而编写。例如，最终用户可以将他们的电子邮件存储在Gmail上。最终用户与Gmail等应用的交互会调用基础架构中的其他服务。例如，Gmail服务可以调用“联系人”这项服务的API来访问最终用户的通讯录。

在前一节中可以看到“联系人”服务可以配置为只允许来自Gmail服务（或“联系人”服务允许的任何其他特定服务）的RPC请求。

不过，这仍然是一组非常宽泛的权限。在该权限范围内，Gmail服务可以随时请求任何用户的联系人。

由于Gmail服务代表特定的最终用户向“联系人”服务发出RPC请求，因此基础架构赋予Gmail服务一项功能，使其可以将“最终用户权限票据”作为RPC的一部分提交。此票据可证明Gmail服务当前正在代表该特定最终用户的发起请求。这使“联系人”服务确保只返回票据中指定的最终用户的数据。

基础架构提供一项中央用户身份识别服务来签发“最终用户许可票据”。最终用户登录时由中央身份服务验证用户身份并为用户的客户端设备颁发用户凭据，如cookie或OAuth令牌。从客户端设备到谷歌发出的任何后续请求都需要提供该用户凭据。

当服务接收到最终用户凭据时，它会将凭据传递给中央身份识别服务进行验证。如果最终用户凭据验证正确无误，则中央身份识别服务会返回短期有效的“最终用户许可票据”用于与请求相关的RPC。在这个例子中，获得“最终用户许可票据”的服务是Gmail服务，它将把票据传递给“联系人”服务。之后，对于任何级联调用，调用服务都可以将“最终用户权限票证”作为RPC调用的一部分传递给被调用服务。

图2. 服务身份标识和访问管理：基础架构提供服务身份标识、自动化的双向身份验证、加密的服务间通信以及执行由服务所有者定义的访问策略。

数据存储安全

前文已经介绍了如何安全地部署服务。接下来开始讨论如何在基础架构上实现安全的数据存储。

静态加密

谷歌的基础架构提供多种存储服务，如Bigtable和Spanner，以及中央密钥管理服务。谷歌的大多数应用通过这些存储服务间接访问物理存储。存储服务可以配置为在数据写入物理存储之前使用中央密钥管理服务中的密钥对数据进行加密。此密钥管理服务支持自动密钥轮换，提供大量审计日志，并与前面提到的最终用户许可票据集成，以将密钥与特定的最终用户关联。

在应用层执行加密可使基础架构将自身与底层存储的潜在威胁（如恶意磁盘固件）隔离开。也就是说，基础架构还可以实施额外的保护层。我们在硬盘和固态硬盘中启用硬件加密支持，并在每个硬盘的生命周期中仔细跟踪每个硬盘。对于停用的加密存储设备，先通过多步骤流程（包括两次独立验证）清空其内容，再撤离我们的管控范围。未通过此擦除过程的设备会在本地进行物理销毁（如粉碎）。

删除数据

谷歌数据删除流程的第一步通常是将特定数据标记为“已安排删除”，而不是一开始就做彻底移除。这使得我们可以恢复无意删除的数据（无论是由客户发起，还是因内部缺陷或处理错误而造成的删除）。在被标记为“已安排删除”后，将根据服务的专用策略来删除数据。

当最终用户删除其整个帐户时，基础架构将通知处理最终用户数据的服务该帐户已被删除。然后，服务可以安排对与已删除的最终用户帐户关联的数据进行删除。此功能使服务的开发人员能够轻松实现最终用户控制。

互联网通信安全

前文介绍了如何在基础架构上保护服务。本节将介绍如何保护互联网和这些服务之间的通信安全。

如前所述，基础架构由大量物理机组成，这些物理机通过局域网和广域网互连，服务间通信的安全性不依赖于网络的安全性。不过，我们还是将基础架构从互联网隔离到私有IP空间，而只将一小部分机器直接暴露于外部互联网流量中，这样就可以更容易实现额外的保护，例如防止拒绝服务（DoS）攻击。

谷歌前端服务

当一项服务想要在互联网上可用时，它可以向名为谷歌前端（Google Front End, GFE）的基础架构服务进行注册。通过使用正确的证书并遵循最佳实践（例如支持完美的前向安全性），谷歌前端服务（GFE）可确保终止所有TLS连接。此外，GFE还应用了拒绝服务攻击（DoS）防护（稍后我们将详细讨论）。然后，GFE使用前面讨论的RPC安全协议转发服务请求。

实际上，任何选择对外发布的内部服务都使用GFE作为智能反向代理前端。该前端提供公开IP托管公开的DNS名称、防护拒绝服务（DoS）攻击以及终止TLS连接。请注意，GFE与任何其他服务一样在基础架构上运行，因此能够根据入站请求量进行调节。

拒绝服务（DoS）防护

规模庞大的谷歌基础架构可以轻而易举地抵抗许多拒绝服务DoS攻击。我们有多层级DoS防护，可进一步降低使用GFE的服务受到DoS攻击影响的风险。

在骨干网向其中一个数据中心提供外部连接后，它将经过几层软硬件负载平衡。这些负载均衡向运行在基础架构上的中央DoS服务报告有关入站流量的信息。当中央DoS服务检测到DoS攻击时，可以配置负载均衡，丢弃或限制与该攻击相关的流量。

在下一层，GFE实例还向中央DoS服务报告它们正在接收的请求的信息，包括负载平衡没有的应用层信息。然后，中央DoS服务还可以配置GFE实例以降低或限制攻击流量。

用户身份认证

在DoS防护后，下一层防御来自我们的中央身份识别服务。此服务通常以谷歌登录页面的形式显示给最终用户。除了要求提供简单的用户名和密码外，该服务还根据风险因素智能地要求用户提供其他信息，例如用户过去是否使用同一设备或在相同位置登录过。在对用户进行身份认证后，身份识别服务会签发可用于后续调用的凭据，如cookies和OAuth令牌。

用户还可以选择在登录时使用第二因素身份认证，如OTP或防钓鱼安全密钥。为了使谷歌以外的其他组织机构也能使用这些服务，我们通过FIDO联盟与多家设备供应商合作开发了通用第二因素（U2F）开放标准。这些设备现已上市，其他主流Web服务也同步实现了U2F支持。

运营安全

到目前为止，我们已经介绍了如何将安全性设计到基础架构中，并且还介绍了一些安全运营机制，例如对RPC的访问控制。

接下来将介绍如何安全地运营基础架构：安全地创建基础架构软件，保护员工的机器和凭证，防御来自内部和外部操作者对基础架构的威胁。

安全的软件开发

除了前面介绍的中央源代码控制和双方审核功能外，我们还提供了一些可阻止开发人员引入某些特定类别的安全错误库。例如，我们有消除Web应用中XSS漏洞的库和框架。我们还拥有自动检测安全错误的自动化工具，包括模糊测试工具、静态分析工具和Web安全扫描器。

作为检查的最后一项，通过人工安全审核的方式，审核范围覆盖从对较低风险的功能进行快速分类，到对最高风险的功能在设计和实施上进行深入审核。执行这些审核的团队由Web安全、加密和操作系统安全领域的专家组成。此外，此类审核还可能催生出新的安全库功能和新的模糊测试工具，可用于未来的其他产品。

此外，谷歌还实施了漏洞奖励计划，为任何能发现我们基础架构或应用漏洞并告知我们的人员提供奖励。目前谷歌已经发放了数百万美元的奖励。

谷歌还投入大量精力查找我们使用的所有开源软件中的零日漏洞和其他安全问题，并上报这些问题。例如，谷歌发现了OpenSSL心脏滴血漏洞，并且针对Linux KVM hypervisor，谷歌是提交CVE和安全漏洞修复解决方案最多的一家公司。

确保员工设备和凭据的安全

谷歌投入大量成本用于保护员工的设备和凭据免遭破解，并会监控相关活动以发现潜在的损害或内部人员的非法行为。这部分投资是我们用于确保基础架构安全运行的投资中的关键部分。

谷歌员工一直饱受高级网络钓鱼攻击的威胁。为了防范这种威胁，我们要求员工账号强制使用兼容U2F的安全密钥，替换了可能被钓鱼攻击的OTP第二因素进行身份认证。

我们投入大量成本来管控员工用来运行基础架构的客户端设备。谷歌需确保这些客户端设备的操作系统镜像具有最新的安全补丁，并控制可安装的应用。此外，我们配备了相应系统来扫描用户安装的应用、下载内容、浏览器扩展和从web上浏览内容，以确保其适合企业客户端。

是否在公司局域网上不是我们用来判断是否授予访问权限的主要机制。我们使用的是应用级访问管理控制机制，这使我们可以仅向来自正确的受控设备、预期的网络和地理位置的特定用户公开内部应用。（要了解详情，请参阅“BeyondCorp”相关阅读材料。）

降低内部风险

针对拥有基础架构管理员权限的员工行为，我们采取了积极主动地限制和监控，并通过自动化手段使得这些限制与监控更安全、更可控，不断努力消除特定任务对于特权访问的需求。这包括要求某些操作得到双方批准方可执行，并引入有限的API，允许在不公开敏感信息的情况下进行调试。

谷歌员工对最终用户信息的访问通过底层基础架构钩子进行记录。谷歌的安全团队会主动监控访问模式并调查异常事件。

入侵检测

谷歌拥有先进的数据处理管道，这些管道集成了各个设备上基于主机的信号、来自基础架构中各个监控点的基于网络的信号以及基础架构服务的信号。在管道上建立的规则和机器智能为运营安全工程师提供可能发生的事故的告警。我们的调查和事件响应团队一年365天，每天24小时对这些潜在事件进行分类、调查和响应。我们还会进行红队演习，用以衡量和改善我们检测和响应机制的有效性。

Google云平台（GCP）安全

本节将重点介绍谷歌的公有云基础架构谷歌云平台（Google Cloud Platform, GCP）如何从底层基础架构的安全性中获益。在本节中，我们将以谷歌计算引擎（Google Compute Engine, GCE）为例，详细描述我们在基础架构之上构建的、针对特定服务的安全性改进。

GCE使客户能够在谷歌的基础架构上运行自己的虚拟机。GCE的实现涉及到若干逻辑组件，最显著的是管理控制平面和虚拟机本身。

管理控制平面暴露外部API和编排虚拟机创建和迁移等任务。和其他各种服务一样它运行在基础架构上，因此自动获得基础的完整性功能，例如安全启动链。各个服务在不同的内部服务帐户下运行，因此每个服务只能被授予它与控制平面的其他服务进行远程过程调用（RPC）所需的权限。如前所述，所有这些服务的代码都存储在谷歌的中央源代码存储库中，并且在这些代码和最终部署的二进制文件之间有审计跟踪。

GCE控制平面通过GFE公开其API，因此它可以利用了基础架构提供的安全特性，如拒绝服务（DoS）保护和集中管理的SSL/TLS支持。通过选择使用构建在GFE上的可选的谷歌云负载均衡器服务，客户可以为运行在GCE的虚拟机（VM）上的应用获得类似的保护，也可以减轻许多类型的DoS攻击。

GCE控制平面API的最终用户身份认证是通过谷歌的集中式身份服务完成的，该服务提供了诸如劫持检测等安全功能。授权是使用中央Cloud IAM服务完成的。

控制平面的网络流量，无论是从GFE到它后面的第一个服务，还是其他控制平面服务之间的网络流量，都由基础架构自动认证，并在它从一个数据中心传输到另一个数据中心时加密。此外，该基础架构还配置为对数据中心内部的一些控制平面流量进行加密。

每个虚拟机（VM）都与关联的虚拟机管理器（VMM）服务实例一起运行。基础架构为这些服务提供了两个标识。一个标识由VMM服务实例用于自己的调用，一个标识用于VMM代表客户的VM进行的调用。这样我们就可以进一步细分对来自VMM调用中的植入的信任。

GCE永久磁盘存储时采用受中央基础架构密钥管理系统保护的密钥进行过加密，因此密钥就可以自动轮转并对密钥访问集中审计。

如今客户有了更多选择，可以选择在不加密的情况下从其VM向其他VM或互联网发送流量，也可以选择对该流量进行所需加密。我们已经为客户的VM到VM流量在广域网中遍历的每一跳提供自动加密。目前，基础架构内所有的控制平台广域网流量已经被加密。未来，我们计划利用前面讨论的硬件加速网络加密来同样加密数据中心内的VM之间的局域网流量。

提供给VM的隔离是在硬件虚拟化的基础上使用开源KVM堆栈实现。通过将一些控制措施和硬件仿真堆栈移动到内核外的非特权进程中，我们进一步加固了KVM的特定实现。我们还使用模糊化、静态分析和人工代码审查等技术对KVM的核心进行了广泛的测试。如前所述，最近公开并已上传至KVM的大部分漏洞是由谷歌披露的。

最后，我们的运营安全控制是确保数据访问遵循我们策略的关键部分。作为谷歌云平台的一部分，GCE对客户数据的使用遵循GCP对客户数据的使用策略，即除非为客户提供的相关服务需要，谷歌不会访问或使用客户数据。

结论

我们已经描述了谷歌的基础架构是如何在互联网范围安全地构建、部署和操作服务的。这包括Gmail等个人用户服务和企业服务。此外，我们的谷歌云服务也建立在同样的基础架构之上。

我们为保护谷歌基础架构的安全性投入巨大，包括数百名致力于安全和隐私的工程师致力于此，其中不乏许多公认的行业权威人士。

正如我们所看到的，基础架构的安全性是分层级设计的，从物理组件和数据中心开始，到硬件来源，然后到安全启动，服务间通信安全，数据存储安全，从因特网访问服务的保护和最后我们为运营安全部署的技术和人员流程。

补充阅读

有关领域的详细信息，请参阅以下材料：

  1. 数据中心的物理安全(https://goo.gl/WYlKGG )

  2. 集群管理和编排设计(https://research.google.com/pubs/pub43438.html)

  3. 存储加密和面向客户的GCP加密功能(https://cloud.google.com/security/encryption-at-rest/)

  4. BigTable存储服务(https://research.google.com/archive/bigtable.html)

  5. Spanner存储服务 (https://research.google.com/archive/spanner.html)

  6. 网络负载均衡体系结构(https://research.google.com/pubs/pub44824.html)

  7. 企业安全方法BeyondCorp(https://research.google.com/pubs/pub43231.html)

  8. 用安全密钥和通用U2F标准对抗网络钓鱼(https://research.google.com/pubs/pub45409.html)

  9. 关于谷歌漏洞奖励计划的更多信息(https://bughunter.withgoogle.com/)

  10. 有关HTTPs和GCP上其他负载均衡产品的更多信息(https://cloud.google.com/compute/docs/load-balancing/)

  11. 有关DoS保护最佳实践的详细信息(https://cloud.google.com/>les/GCPDDoSprotection-04122016.pdf)

  12. 谷歌云平台客户数据使用政策(https://cloud.google.com/terms/)

  13. 有关G Suite中应用安全性和合规性的更多信息（Gmail、驱动器等(https://static.googleusercontent.com/media/gsuite.google.com/en//>les/google-apps-security-and-compliance-whitepaper.pdf)

【需要获得《谷歌基础架构安全设计概述——谷歌云白皮书》英文原文的朋友，请关注本公众号零信任安全社区（izerotrust）并在后台留言"谷歌云"。】

声明：本文来自零信任安全社区，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。