本文包含的内容截至 2017 年 1 月是正确无误的，代表截至本文撰写之时的状况。Google 始终持续加强对客户的保护力度，因此安全政策和系统可能会随着时间的推移而发生变化。
下载 PDF 版本
面向首席信息官级别领导人的摘要
- Google 拥有全球规模的技术基础架构，该基础架构旨在让 Google 能够在整个信息处理周期提供安全保障。该基础架构可实现以下用途：安全地部署服务；在保护最终用户隐私的情况下安全地存储数据；在服务之间安全通信；通过互联网安全而私密地与客户进行沟通；使管理员能安全地进行操作。
- Google 利用该基础架构来构建其互联网服务，包括 Google 搜索、Gmail 和 Google 相册等个人用户服务以及 G Suite 和 Google Cloud 等企业服务。
- 基础架构的安全性是分层级逐步实现的，先从数据中心的物理安全性开始，接着是构成基础架构基础的硬件和软件的安全性，最后是通过技术限制和流程实现运营安全性。
- 为了确保基础架构的安全，Google 投入了巨大的成本，雇用了数百名致力于安全与隐私保护的工程师，他们分布在各个 Google 公司，其中许多人是公认的业界权威。
简介
本文档概述了如何将安全性植入 Google 的技术基础架构中。这一全球规模的基础架构旨在让 Google 能够在整个信息处理周期中提供安全保障。该基础架构可实现以下用途：安全地部署服务；在保护最终用户隐私的情况下安全地存储数据；在服务之间安全通信；通过互联网安全而私密地与客户进行沟通；使管理员能安全地进行操作。
Google 利用该基础架构来构建其互联网服务，包括 Google 搜索、Gmail 和 Google 相册等个人用户服务以及 G Suite 和 Google Cloud 等企业服务。
我们将分层级逐步介绍该基础架构的安全性，先从数据中心的物理安全性开始，接着介绍如何确保构成基础架构基础的硬件和软件的安全，最后介绍如何通过技术限制和流程实现运营安全性。
Google 基础架构安全层：各个安全层，从位于底层的硬件基础架构安全性开始，到位于顶层的运营安全性。本文详细介绍了各个安全层的内容。
安全的底层基础架构
在这个部分，我们将介绍如何确保基础架构最底层的安全，从实体场所到数据中心内的特制硬件，再到每台机器上运行的底层软件堆栈。
实体场所的安全性
Google 设计和建造了自己的数据中心，其中加入了多层物理安全保护。只有极少数 Google 员工可以出入这些数据中心。我们使用多个物理安全层来保护我们的数据中心场地，并使用了生物识别、金属检测、摄像头、车辆路障和基于激光的入侵检测系统等技术。此外，Google 还在第三方数据中心托管了一些服务器，除了数据中心运营商提供的安全层之外，我们还确保落实 Google 管控的物理安全措施。例如，我们可能会在此类场所运行独立的生物识别系统、摄像头和金属探测器。
硬件的设计和来源
Google 的每个数据中心都有数千台服务器与本地网络相连。服务器主板和网络设备均由 Google 专门设计。我们会对合作的组件供应商进行审核，并会谨慎选择组件，同时还会与供应商一起对组件提供的安全属性进行审核和验证。我们还设计专门的芯片，包括目前部署到服务器和外围设备上的硬件安全芯片。这些芯片可使我们在硬件级别安全地对正规 Google 设备进行识别和身份验证。
安全的启动堆栈和机器身份标识
Google 服务器利用各种技术来确保其启动正确的软件堆栈。我们对 BIOS、引导加载程序、内核和基本操作系统映像等底层组件使用加密签名，可以在每次启动或更新期间对这些签名进行验证。这些组件全部由 Google 进行控制、构建和强化。对于每一代新硬件，我们都致力于不断提升其安全性：例如，我们会根据各代服务器在设计上的不同，将启动链的信任根植于可锁定的固件芯片，或者根植于运行 Google 所编写的安全代码的微控制器，亦或根植于上文提到的 Google 设计的安全芯片。
数据中心的每台服务器都有自己的具体身份标识，可以将这一身份标识与硬件信任根以及启动机器所用的软件相关联。此身份标识用于验证与机器上的底层管理服务之间的 API 调用。
Google 已开发自动化系统来确保服务器运行最新版本的软件堆栈（包括安全补丁程序），以便检测和诊断硬件和软件问题，并在必要时将机器从服务中移除。
安全的服务部署
在介绍完基础硬件和软件的安全性之后，现在我们将继续介绍如何确保在基础架构上安全地部署服务。“服务”是指开发者编写并希望在我们的基础架构上运行的应用二进制文件，例如 Gmail SMTP 服务器、Bigtable 存储服务器、YouTube 视频转码器或运行客户应用的 App Engine 沙盒。为了处理必要规模的工作负载，可能会有数千台机器运行同一项服务的副本。在基础架构上运行的服务由名为 Borg 的集群编排服务控制。
我们将在本部分看到，基础架构不会假定在基础架构上运行的服务之间存在信任。换句话说，基础架构从根本上采取了多租户设计。
服务身份标识、完整性和隔离
我们在应用层使用加密验证和授权来进行服务间通信。这在抽象层提供了强大的访问控制，并实现了精细化，而管理员和服务可以轻松理解这种控制和精细化。
我们不依赖内部网络分段或防火墙作为主要安全机制，不过，我们确实在网络的各点使用了入站和出站过滤来防止 IP 欺骗，并因此多了一层防护。这种方法还有助于我们最大限度地提高网络的性能和可用性。
在基础架构上运行的每项服务都具有关联的服务帐号身份标识。服务具有加密凭据，可在向其他服务发送或从其他服务处接收远程过程调用 (RPC) 时用于证明自己的身份。客户端利用这些身份标识来确保其与正确的目标服务器通信，而服务器则利用这些身份标识将方法与数据的访问权限限定给特定的客户端。
Google 的源代码存储在中央代码库中，在该代码库中，当前版本及过去版本的服务均可审核。此外，基础架构可配置为：要求服务的二进制文件由经过具体审核、登记和测试的源代码构建而成。此类代码审核需要开发者以外的至少一位工程师进行检查和批准，而对任何系统执行代码修改都必须得到该系统所有者的批准。这些要求可以防止内部人员或攻击者恶意修改源代码，还可实现从服务回溯到其源代码的取证跟踪。
我们采取各种隔离和沙盒技术来保护服务免受同一台机器上运行的其他服务的影响。这些技术包括普通的 Linux 用户分离、基于语言和内核的沙盒以及硬件虚拟化。总之，我们会为风险较高的工作负载使用更多的隔离层；例如，当针对用户提供的数据运行复杂的文件格式转换器时，或者当针对 Google App Engine 或 Google Compute Engine 等产品运行用户提供的代码时。作为额外的安全防线，极其敏感的服务（例如集群编排服务和部分密钥管理服务）只在专用机器上运行。
服务间访问管理
服务的所有者可以利用基础架构提供的访问管理功能来精确指定其服务可以与其他哪些服务之间进行通信。例如，一项服务可能需要仅向列入白名单的其他具体服务提供一些 API。在这种情况下，可以使用列了允许的服务帐号身份标识的白名单配置该服务，然后由基础架构自动执行这一访问限制。
访问服务的 Google 工程师也会获得个人身份标识，因此您可以对服务进行类似的配置，以允许或拒绝其访问。所有这些类型的身份标识（机器、服务和员工）都位于基础架构维护的全局名称空间中。正如本文后面将介绍的一样，最终用户身份标识是分开处理的。
基础架构针对这些内部身份标识提供了丰富的身份管理工作流程体系，包括审批链、日志记录和通知。例如，可以通过双方控制体系（其中，一名工程师可以提议对某个组进行更改，但这种提议必须得到另一名工程师兼该组管理员的批准）将这些身份标识分配到访问控制组。这一体系可让安全访问管理流程扩展到基础架构上运行的数千项服务。
除 API 层面的自动访问控制机制外，基础架构还允许服务从中央 ACL 和组数据库中读取数据，以便其可以在必要时执行精细的定制化访问控制。
服务间通信的加密
除上文讨论的 RPC 身份验证和授权功能外，基础架构还会通过加密处理确保网络上 RPC 数据的隐私性和完整性。为了向 HTTP 等其他应用层协议提供这些安全优势，我们将这些安全优势封装到了我们的基础架构 RPC 机制中。实际上，这实现了应用层隔离，并避免了对网络路径安全性的依赖。即使网络被窃听或网络设备被破解，经加密的服务间通信仍可保持安全。
服务可以为每个基础架构 RPC 配置所需级别的加密保护（例如，对于数据中心里价值不高的数据，可以仅配置完整性级别的保护）。为防止高级攻击者窃听我们的私有广域网链路，基础架构会自动加密流经数据中心之间广域网的所有基础架构 RPC 流量，而无需服务进行任何具体配置。我们已开始部署硬件加密加速器，这可使我们将这种默认加密扩展到我们数据中心内部的所有基础架构 RPC 流量。
最终用户数据访问管理
有一种典型的 Google 服务是出于为最终用户执行某些操作而编写的服务。例如，最终用户可能将其电子邮件存储在 Gmail 上。最终用户与 Gmail 等应用的互动会涉及到基础架构内的其他服务。例如，Gmail 服务可能调用“联系人”服务提供的 API 来访问最终用户的通讯录。
如前文所述，我们可以对“联系人”服务进行配置，以便只允许来自 Gmail 服务（或“联系人”服务允许的任何其他特定服务）的 RPC 请求。
不过，这仍然是一组非常宽泛的权限。在此权限范围内，Gmail 服务可以随时请求访问任何用户的联系人。
由于 Gmail 服务代表某特定的最终用户向“联系人”服务发送远程过程调用 (RPC) 请求，因此基础架构赋予了 Gmail 服务一项功能，使其可以提交“最终用户权限工单”并将该工单作为远程过程调用 (RPC) 的一部分。此工单可证明 Gmail 服务目前正在代表该特定的最终用户发出请求。这样，“联系人”服务便可实施相关安全措施，只为工单中指定的最终用户返回数据。
基础架构提供了一项中央用户身份识别服务，该服务可以签发上述“最终用户权限工单”。中央身份识别服务会对最终用户的登录信息进行验证，然后向该用户的客户端设备签发用户凭据，例如 Cookie 或 OAuth 令牌。从该客户端设备向 Google 发出的任何后续请求都需要提交此用户凭据。
当一项服务收到最终用户凭据时，就会将该凭据传递给中央身份识别服务进行验证。如果最终用户凭据经验证正确无误，中央身份识别服务就会返回短期有效的“最终用户权限工单”，该工单可用于与请求相关的远程过程调用 (RPC)。在我们的示例中，获得“最终用户权限工单”的服务是 Gmail 服务，该服务会将工单传递给“联系人”服务。之后，对于任何级联调用，调用服务都可以将“最终用户权限工单”作为远程过程调用 (RPC) 调用的一部分传递给被调用服务。
服务身份和访问权限管理：基础架构可提供服务身份、自动身份互验、加密的服务间通信，并可执行服务所有者定义的访问政策。
安全的数据存储
到目前为止，我们介绍了如何安全地部署服务。接下来，我们开始讨论如何在基础架构上实现安全的数据存储。
静态加密
Google 的基础架构提供各种存储服务（例如 Bigtable 和 Spanner）以及中央密钥管理服务。Google 的大多数应用均通过这些存储服务间接访问物理存储。可以将存储服务配置为：使用中央密钥管理服务中的密钥对数据进行加密，然后再将数据写入物理存储。此密钥管理服务支持自动密钥轮替；提供大量审核日志；并与前面提到的最终用户权限工单相集成，以将密钥与特定的最终用户进行关联。
在应用层执行加密可使基础架构将其自身与底层存储上的潜在威胁（例如恶意磁盘固件）隔离开来。也就是说，基础架构还可以实施额外的保护层。Google 在我们的硬盘和 SSD 中启用了硬件加密支持，并会在每个硬盘的整个生命周期内细心跟踪这些硬盘。对于退役的加密存储设备，我们先通过多步骤流程（包括两次独立验证）清空其内容，然后才会将其撤离我们的管控范围。对于未经历此类擦除程序的设备，我们会在现场进行物理销毁（例如粉碎）。
删除数据
Google 的数据删除流程通常是从将具体数据标记为“已安排删除”(scheduled for deletion) 开始，而不是真的彻底移除。这使得我们可以恢复无意间删除的数据（无论是由客户发起的删除操作，还是因内部漏洞或流程错误而造成的删除）。在将数据标记为“已安排删除”后，Google 会根据服务专用政策来删除数据。
当最终用户删除其整个帐号时，基础架构会通知处理最终用户数据的服务该帐号已被删除。然后，这些服务便会安排删除与被删除的最终用户帐号相关联的数据。此功能可使服务开发者轻松实现最终用户控制。
安全的互联网通信
前面，我们介绍了如何在基础架构上确保服务的安全。在本部分，我们开始介绍如何确保互联网与这些服务之间的通信安全。
如前所述，基础架构由大量物理机器构成，这些机器通过局域网和广域网相互连接，并且服务间的通信安全不依赖于网络安全。不过，我们确实将我们的基础架构从互联网隔离到了私有 IP 空间，而只将一小部分机器直接暴露于外部互联网流量中，从而可以更轻松地实现额外的保护，例如防御拒绝服务 (DoS) 攻击。
Google 前端服务
当一项服务希望其在互联网上可用时，便可向名为 Google 前端 (GFE) 的基础架构服务进行注册。通过使用正确的证书并实施最佳做法（例如支持完全正向加密），GFE 可确保终止全部 TLS 连接。此外，GFE 会应用保护措施来防御拒绝服务攻击（稍后我们将详细讨论）。然后，GFE 利用前面讨论的 RPC 安全协议转发对该服务的请求。
实际上，选择向外发布的任何内部服务都使用 GFE 作为智能反向代理前端。该前端可以：通过公开 IP 托管公开的 DNS 名称；防御拒绝服务 (DoS) 攻击；以及终止 TLS 连接。请注意，GFE 与其他任何服务一样在基础架构上运行，因此能够根据入站请求量进行调节。
防御拒绝服务 (DoS) 攻击
规模庞大的 Google 基础架构可以轻而易举地抵御许多 DoS 攻击。也就是说，我们具备多层级 DoS 防护，可进一步降低使用 GFE 的服务受到任何 DoS 影响的风险。
在我们的骨干网向我们的其中一个数据中心提供外部连接之后，该连接会经过多层硬件和软件负载平衡。这些负载平衡器会将有关入站流量的信息报告给在基础架构上运行的中央 DoS 服务。当中央 DoS 服务检测到 DoS 攻击时，便会配置负载平衡器，以降低或限制与攻击相关的流量。
在下一层，GFE 实例还会将与它们正在接收的请求有关的信息报告给中央 DoS 服务，包括负载平衡器没有的应用层信息。然后，中央 DoS 服务还会配置 GFE 实例，以降低或限制攻击流量。
用户身份验证
在 DoS 防护之后，下一层防御来自我们的中央身份识别服务。此服务通常作为 Google 登录页面显示给最终用户。除要求提供简单的用户名和密码外，该服务还会根据风险因素智能地要求用户提供其他信息，例如询问他们过去是否从同一设备或类似位置登录过。在对用户进行身份验证之后，身份识别服务会签发 Cookie 和 OAuth 令牌等凭据，供后续调用时使用。
用户还可选择在登录时使用第二因素身份验证，例如动态密码或防网上诱骗安全密钥。为确保除 Google 以外的其他方也能享受这些优势，我们通过 FIDO Alliance 与多家设备供应商合作，以便开发通用第二因素 (U2F) 开放标准。这些设备现已上市，其他主要网络服务也紧随我们之后，开始实施 U2F 支持。
运营安全
在前文中，我们介绍了如何将安全性植入基础架构中，还介绍了一些安全运营机制，例如针对 RPC 的访问控制。
现在，我们开始介绍如何安全地运营基础架构：安全地创建基础架构软件；保护员工的机器和凭据；防御来自内部和外部操作者的基础架构威胁。
安全的软件开发
除前面介绍的中央源代码控制和双方审核功能外，我们还提供了可阻止开发者引入某些安全错误的库。例如，我们拥有可让网页应用避免 XSS 漏洞的库和框架，还拥有可自动检测安全错误的自动化工具，包括模糊测试工具、静态分析工具和网络安全扫描工具。
我们会进行人工安全审核以作为最终检查，审核范围从对较低风险的功能进行快速分类，到对最高风险的功能在设计和实施上进行深入审核。执行这些审核的团队由网络安全、加密和操作系统安全领域的专家组成。此外，此类审核还可能催生新的安全库功能和新的模糊测试工具，以用于未来的其他产品。
此外，我们还实施了漏洞奖励计划 (Vulnerability Rewards Program)：对于在我们的基础架构或应用中发现错误并告知我们的人员，我们会予以奖励。在该计划中，我们已发放了数百万美元的奖励。
Google 还投入大量精力查找我们使用的所有开源软件中的零日漏洞及其他安全问题，并上报这些问题。例如，Google 发现了 OpenSSL Heartbleed 错误，并且我们是为 Linux KVM 管理程序提交 CVE 和安全问题修复解决方案最多的一家公司。
确保员工设备及凭据的安全性
我们投入大量成本来保护员工的设备和凭据免遭破解，并会监控相关活动以便发现潜在的破解行为或内部人员非法行为。这方面的投资是我们为确保基础架构安全运行所进行的投资中的关键部分。
我们的员工始终面临着高级网上诱骗威胁。为了防范这种威胁，我们为员工帐号强制使用了兼容 U2F 的安全密钥，取代了可能会受到网上诱骗攻击的动态密码第二因素身份验证。
我们投入大量成本来监控员工用来运行基础架构的客户端设备。我们确保这些客户端设备的操作系统映像具有最新的安全补丁程序，我们还会控制哪些应用可以安装。此外，我们配备了相关系统来扫描用户安装的应用、下载内容、浏览器扩展程序和网络浏览内容，以确保其适合企业客户端。
是否在企业局域网上不是我们用来判断是否授予访问权限的主要机制。我们使用的是应用级访问管理控制，这使得我们可以仅向来自正确管理的设备以及来自预期网络和地理位置的特定用户公开内部应用。（要了解详情，请参阅有关“BeyondCorp”的附加阅读材料。）
降低来自内部人员的风险
我们积极限制并主动监控拥有基础架构管理员权限的员工的活动，并且在不断地努力以期取消针对特殊任务授予特别访问权限的必要性，改为以安全可控的方式自动完成同样的任务。我们的限制措施包括：要求某些操作需要获得双方批准方可执行，以及引入有限的 API（在不暴露敏感信息的情况下进行调试）等。
Google 员工对最终用户信息的访问情况可通过底层基础架构钩子进行记录。Google 的安全团队会主动监控访问模式并调查异常事件。
入侵检测
Google 拥有先进的数据处理管道，这些管道汇聚了各个设备上的基于主机的信号、来自基础架构中各个监控点的基于网络的信号，以及来自基础架构服务的信号。构建于这些管道之上的规则和机器智能会向运营安全工程师发出潜在事件警告。我们的调查和事件响应团队会一年 365 天、一天 24 小时全天候地对这些潜在事件进行分类、调查和响应。我们效仿 Red Team 的做法来衡量和改善我们的检测与响应机制的有效性。
保护 Google Cloud 的安全
在本部分，我们重点介绍公开的云基础架构 Google Cloud 如何从底层基础架构的安全性中受益。我们将以 Google Compute Engine 作为示例服务，并将详细介绍在基础架构之上构建的、专门针对特定服务的安全性改进。
Compute Engine 使客户能在 Google 的基础架构上运行自己的虚拟机。Compute Engine 实现涉及到若干逻辑组件，最显著的是管理控制平面和虚拟机本身。
管理控制平面可显示外部 API 的出现并编排虚拟机创建和迁移等任务。它与各种服务一样在基础架构上运行，因此可以自动获得基础的完整性功能，例如安全启动链。各项服务在不同的内部服务帐号下运行，以便每项服务仅被授予在向控制平面的其余部分发出远程过程调用 (RPC) 时所需的权限。如前文所述，所有这些服务的代码都存储在中央 Google 源代码库中，并且此代码与其最终部署而成的二进制文件之间存在审核跟踪。
Compute Engine 控制平面通过 GFE 公开其 API，因此可以充分利用拒绝服务 (DoS) 防护和集中管理的 SSL/TLS 支持等基础架构安全功能。客户可以为其 Compute Engine 虚拟机上运行的应用获取类似的保护，具体方法是，选择使用 Google Cloud Load Balancer 服务（可选），该服务构建于 GFE 之上并可消弱多种 DoS 攻击。
Compute Engine 控制平面的最终用户身份验证通过 Google 的集中式身份识别服务来完成，该服务具有黑客攻击检测等安全功能。授权通过中央 Identity and Access Management 服务完成。
基础架构会自动对控制平面的网络流量（无论是从 GFE 到其后面第一项服务之间的流量，还是其他控制平面服务之间的流量）进行身份验证，这些网络流量在从一个数据中心传输到另一个数据中心时还会被加密。此外，基础架构还被配置为加密数据中心内部的某些控制平面流量。
每个虚拟机 (VM) 都与关联的虚拟机监控器 (VMM) 服务实例一起运行。基础架构为这些服务提供两种身份。一种身份供 VMM 服务实例进行自己的调用，另一种身份供 VMM 代表客户的虚拟机进行调用。这使我们能够进一步细分来自 VMM 的调用中所植入的信任。这使我们能够进一步细分来自 VMM 的调用中所植入的信任。
Compute Engine 永久性磁盘通过受中央基础架构密钥管理系统保护的密钥进行了静态加密。这样便可实现自动轮替，并对这些密钥的访问权限进行集中审核。
如今，客户可以选择在不加密的情况下从其虚拟机向其他虚拟机或互联网发送流量，也可以选择对该流量进行所需加密。我们已开始针对客户虚拟机到虚拟机流量的广域网遍历跃点推出自动加密功能。如前文所述，基础架构内部的所有控制平面广域网流量都已经过加密。未来，我们计划利用前面讨论的硬件加速网络加密技术来加密数据中心内部虚拟机之间的局域网流量。
向虚拟机提供的隔离功能基于使用开源 KVM 堆栈的硬件虚拟化。通过将一些控制和硬件模拟堆栈移入内核之外的非特权进程，我们进一步强化了特定的 KVM 实现。我们还利用模糊测试、静态分析和人工代码审核等方法对 KVM 的核心进行了广泛测试。如前文所述，在最近公开披露的、已上报 KVM 的漏洞中，绝大多数都来自 Google。
最后，我们的运营安全控制在确保依照政策进行数据访问方面发挥着关键作用。作为 Google Cloud 的一部分，Compute Engine 按照 Google Cloud 客户数据使用政策使用客户数据，也就是说，除非为了向客户提供服务而有必要，否则 Google 不会访问或使用客户数据。
总结
我们介绍了 Google 基础架构如何设计为在互联网层面安全地构建、部署和运行服务。这包括 Gmail 等个人用户服务以及企业服务。此外，我们的 Google Cloud 产品构建于同一个基础架构之上。
我们在确保基础架构安全方面投入了巨大的成本。有数百名致力于安全与隐私领域的工程师分布在各个 Google 公司，其中许多人是公认的业界权威。
正如我们所看到的一样，基础架构的安全性是分层级设计的，从物理组件和数据中心开始，到硬件来源，然后再到安全启动、服务间通信的安全、静态数据的安全、对从互联网访问服务的保护，最后再到我们为运营安全部署的技术和人员流程。
附加阅读材料
要了解有关具体领域的更多信息，请参阅以下文章：