Google 基础架构安全设计概述 | 解决方案 | Google Cloud 2021/2/23 Google 基础架构安全设计概述 本文包含的内容截至 2017 年 1 月是正确无误的，代表截至本文撰写之时的状况。Google 始 终持续加强对客户的保护力度，因此安全政策和系统可能会随着时间的推移而发生变化。 面向首席信息官级别领导人的摘要 Google 拥有全球规模的技术基础架构，该基础架构旨在让 Google 能够在整个信息处理 周期提供安全保障。该基础架构可实现以下用途：安全地部署服务；在保护最终用户隐 私的情况下安全地存储数据；在服务之间安全通信；通过互联网安全而私密地与客户进 行沟通；使管理员能安全地进行操作。 Google 利用该基础架构来构建其互联网服务，包括 Google 搜索、Gmail 和 Google 相 册等个人用户服务以及 G Suite 和 Google Cloud 等企业服务。 基础架构的安全性是分层级逐步实现的，先从数据中心的物理安全性开始，接着是构成 基础架构基础的硬件和软件的安全性，最后是通过技术限制和流程实现运营安全性。 为了确保基础架构的安全，Google 投入了巨大的成本，雇用了数百名致力于安全与隐 私保护的工程师，他们分布在各个 Google 公司，其中许多人是公认的业界权威。 简介 本文档概述了如何将安全性植入 Google 的技术基础架构中。这一全球规模的基础架构旨在 让 Google 能够在整个信息处理周期中提供安全保障。该基础架构可实现以下用途：安全地 部署服务；在保护最终用户隐私的情况下安全地存储数据；在服务之间安全通信；通过互联 网安全而私密地与客户进行沟通；使管理员能安全地进行操作。 Google 利用该基础架构来构建其互联网服务，包括 Google 搜索、Gmail 和 Google 相册等个 人用户服务以及 G Suite 和 Google Cloud 等企业服务。 我们将分层级逐步介绍该基础架构的安全性，先从数据中心的物理安全性开始，接着介绍如 何确保构成基础架构基础的硬件和软件的安全，最后介绍如何通过技术限制和流程实现运营 安全性。 https://cloud.google.com/security/infrastructure/design/ 1/12 2021/2/23 Google 基础架构安全设计概述 | 解决方案 | Google Cloud Google 基础架构安全层：各个安全层，从位于底层的硬件基础架构安全性开始，到位于顶层 的运营安全性。本文详细介绍了各个安全层的内容。 安全的底层基础架构 在这个部分，我们将介绍如何确保基础架构最底层的安全，从实体场所到数据中心内的特制 硬件，再到每台机器上运行的底层软件堆栈。 实体场所的安全性 Google 设计和建造了自己的数据中心，其中加入了多层物理安全保护。只有极少数 Google 员工可以出入这些数据中心。我们使用多个物理安全层来保护我们的数据中心场地，并使用 了生物识别、金属检测、摄像头、车辆路障和基于激光的入侵检测系统等技术。此外， Google 还在第三方数据中心托管了一些服务器，除了数据中心运营商提供的安全层之外，我 们还确保落实 Google 管控的物理安全措施。例如，我们可能会在此类场所运行独立的生物 识别系统、摄像头和金属探测器。 https://cloud.google.com/security/infrastructure/design/ 2/12 2021/2/23 Google 基础架构安全设计概述 | 解决方案 | Google Cloud 硬件的设计和来源 Google 的每个数据中心都有数千台服务器与本地网络相连。服务器主板和网络设备均由 Google 专门设计。我们会对合作的组件供应商进行审核，并会谨慎选择组件，同时还会与供 应商一起对组件提供的安全属性进行审核和验证。我们还设计专门的芯片，包括目前部署到 服务器和外围设备上的硬件安全芯片。这些芯片可使我们在硬件级别安全地对正规 Google 设备进行识别和身份验证。 安全的启动堆栈和机器身份标识 Google 服务器利用各种技术来确保其启动正确的软件堆栈。我们对 BIOS、引导加载程序、 内核和基本操作系统映像等底层组件使用加密签名，可以在每次启动或更新期间对这些签名 进行验证。这些组件全部由 Google 进行控制、构建和强化。对于每一代新硬件，我们都致 力于不断提升其安全性：例如，我们会根据各代服务器在设计上的不同，将启动链的信任根 植于可锁定的固件芯片，或者根植于运行 Google 所编写的安全代码的微控制器，亦或根植 于上文提到的 Google 设计的安全芯片。 数据中心的每台服务器都有自己的具体身份标识，可以将这一身份标识与硬件信任根以及启 动机器所用的软件相关联。此身份标识用于验证与机器上的底层管理服务之间的 API 调用。 Google 已开发自动化系统来确保服务器运行最新版本的软件堆栈（包括安全补丁程序），以 便检测和诊断硬件和软件问题，并在必要时将机器从服务中移除。 安全的服务部署 在介绍完基础硬件和软件的安全性之后，现在我们将继续介绍如何确保在基础架构上安全地 部署服务。“服务”是指开发者编写并希望在我们的基础架构上运行的应用二进制文件，例如 Gmail SMTP 服务器、Bigtable 存储服务器、YouTube 视频转码器或运行客户应用的 App Engine 沙盒。为了处理必要规模的工作负载，可能会有数千台机器运行同一项服务的副本。 在基础架构上运行的服务由名为 Borg 的集群编排服务控制。 我们将在本部分看到，基础架构不会假定在基础架构上运行的服务之间存在信任。换句话 说，基础架构从根本上采取了多租户设计。 服务身份标识、完整性和隔离 我们在应用层使用加密验证和授权来进行服务间通信。这在抽象层提供了强大的访问控制， 并实现了精细化，而管理员和服务可以轻松理解这种控制和精细化。 https://cloud.google.com/security/infrastructure/design/ 3/12 2021/2/23 Google 基础架构安全设计概述 | 解决方案 | Google Cloud 我们不依赖内部网络分段或防火墙作为主要安全机制，不过，我们确实在网络的各点使用了 入站和出站过滤来防止 IP 欺骗，并因此多了一层防护。这种方法还有助于我们最大限度地提 高网络的性能和可用性。 在基础架构上运行的每项服务都具有关联的服务帐号身份标识。服务具有加密凭据，可在向 其他服务发送或从其他服务处接收远程过程调用 (RPC) 时用于证明自己的身份。客户端利用 这些身份标识来确保其与正确的目标服务器通信，而服务器则利用这些身份标识将方法与数 据的访问权限限定给特定的客户端。 Google 的源代码存储在中央代码库中，在该代码库中，当前版本及过去版本的服务均可审 核。此外，基础架构可配置为：要求服务的二进制文件由经过具体审核、登记和测试的源代 码构建而成。此类代码审核需要开发者以外的至少一位工程师进行检查和批准，而对任何系 统执行代码修改都必须得到该系统所有者的批准。这些要求可以防止内部人员或攻击者恶意 修改源代码，还可实现从服务回溯到其源代码的取证跟踪。 我们采取各种隔离和沙盒技术来保护服务免受同一台机器上运行的其他服务的影响。这些技 术包括普通的 Linux 用户分离、基于语言和内核的沙盒以及硬件虚拟化。总之，我们会为风 险较高的工作负载使用更多的隔离层；例如，当针对用户提供的数据运行复杂的文件格式转 换器时，或者当针对 Google App Engine 或 Google Compute Engine 等产品运行用户提供的 代码时。作为额外的安全防线，极其敏感的服务（例如集群编排服务和部分密钥管理服务） 只在专用机器上运行。 服务间访问管理 服务的所有者可以利用基础架构提供的访问管理功能来精确指定其服务可以与其他哪些服务 之间进行通信。例如，一项服务可能需要仅向列入白名单的其他具体服务提供一些 API。在 这种情况下，可以使用列了允许的服务帐号身份标识的白名单配置该服务，然后由基础架构 自动执行这一访问限制。 访问服务的 Google 工程师也会获得个人身份标识，因此您可以对服务进行类似的配置，以 允许或拒绝其访问。所有这些类型的身份标识（机器、服务和员工）都位于基础架构维护的 全局名称空间中。正如本文后面将介绍的一样，最终用户身份标识是分开处理的。 基础架构针对这些内部身份标识提供了丰富的身份管理工作流程体系，包括审批链、日志记 录和通知。例如，可以通过双方控制体系（其中，一名工程师可以提议对某个组进行更改， 但这种提议必须得到另一名工程师兼该组管理员的批准）将这些身份标识分配到访问控制 组。这一体系可让安全访问管理流程扩展到基础架构上运行的数千项服务。 除 API 层面的自动访问控制机制外，基础架构还允许服务从中央 ACL 和组数据库中读取数 据，以便其可以在必要时执行精细的定制化访问控制。 服务间通信的加密 https://cloud.google.com/security/infrastructure/design/ 4/12 2021/2/23 Google 基础架构安全设计概述 | 解决方案 | Google Cloud 除上文讨论的 RPC 身份验证和授权功能外，基础架构还会通过加密处理确保网络上 RPC 数 据的隐私性和完整性。为了向 HTTP 等其他应用层协议提供这些安全优势，我们将这些安全 优势封装到了我们的基础架构 RPC 机制中。实际上，这实现了应用层隔离，并避免了对网络 路径安全性的依赖。即使网络被窃听或网络设备被破解，经加密的服务间通信仍可保持安 全。 服务可以为每个基础架构 RPC 配置所需级别的加密保护（例如，对于数据中心里价值不高的 数据，可以仅配置完整性级别的保护）。为防止高级攻击者窃听我们的私有广域网链路，基 础架构会自动加密流经数据中心之间广域网的所有基础架构 RPC 流量，而无需服务进行任何 具体配置。我们已开始部署硬件加密加速器，这可使我们将这种默认加密扩展到我们数据中 心内部的所有基础架构 RPC 流量。 最终用户数据访问管理 有一种典型的 Google 服务是出于为最终用户执行某些操作而编写的服务。例如，最终用户 可能将其电子邮件存储在 Gmail 上。最终用户与 Gmail 等应用的互动会涉及到基础架构内的 其他服务。例如，Gmail 服务可能调用“联系人”服务提供的 API 来访问最终用户的通讯录。 如前文所述，我们可以对“联系人”服务进行配置，以便只允许来自 Gmai