BeyondProd：云原生安全性的新方法 | 文档 | Google Cloud 2021/2/23 BeyondProd：云原生安全性的新方法 Google 撰写了多份白皮书，介绍我们内部开发的帮助改进安全性的一些项目。BeyondProd 有意收回了 BeyondCorp 的概念。正如边界安全模型不再适合最终用户一样，BeyondCorp 也 不再适用于微服务。对原始 BeyondCorp (http://cloud.google.com/beyondcorp) 论文的修改：“此 模型的关键假设已不再成立：边界不再仅仅是企业 [数据中心] 的实际位置，并且边界内的领 域不再是托管个人计算设备和企业应用 [微服务] 的安全可靠之处”。 在本白皮书中，我们详细介绍了 Google 的多个基础架构如何在一个现在称为“云原生”的架构 中共同保护工作负载。如需大致了解 Google 的安全性，请参阅安全性基础架构设计白皮书  (https://cloud.google.com/security/infrastructure/design/)。 本文包含的内容截至 2019 年 12 月是正确无误的。本白皮书介绍的是撰文之时的现状。随着 我们持续改善对用户的保护机制，Google Cloud 的安全政策和系统未来可能会发生变化。 术语库 本文档中使用了以下定义： 微服务将应用需要执行的各个任务分离成单独的服务，每项服务都可独立进行开发和管 理，并且具有自己的 API、发布、扩缩和配额管理。在更现代化的架构中，诸如网站之 类的应用可作为一组微服务运行，而不是作为单一的服务运行。微服务是独立的、模块 化的、动态的、短暂的。它们可以分布在许多主机、集群甚至云端上。 工作负载是应用完成的独特任务。在微服务架构中，工作负载可能是一项或多项微服 务。 作业是运行一个应用某个部分的单个微服务实例。 微服务使用服务身份向基础架构中运行的其他服务验证自己的身份。 服务网格是用于服务到服务通信的基础架构层，可控制流量、应用政策以及集中监控服 务调用。使用微服务架构时，服务网格可以消除各项服务实施这些控制的负担，并允许 跨许多微服务进行更简单的集中式管理。 面向首席信息官级别领导者的摘要 https://cloud.google.com/security/beyondprod/ 1/14 BeyondProd：云原生安全性的新方法 | 文档 | Google Cloud 2021/2/23 Google 的基础架构将工作负载作为单独的微服务部署在容器中，并使用 Borg（我们的 容器编排系统）管理这些工作负载。这就是如今众所周知的“云原生”架构的灵感和模 板。 Google 的基础架构在设计时就充分考虑了安全性，而不是后来才想起要添加安全功 能。我们的基础架构假定其服务之间不应互相信任。 Google 通过一项名为 BeyondProd 的计划保护其微服务。这一保护措施的范围包括如 何更改代码以及如何访问微服务中的用户数据。BeyondProd 应用的概念包括：互相进 行身份验证的服务端点、传输安全性、具有全局负载平衡和拒绝服务攻击保护的边缘终 止、端到端代码出处以及运行时沙盒。 从传统的安全模型迁移到云原生安全模型要求我们对基础架构和开发过程这两个主要方 面进行更改。在包含和连接所有微服务的共享结构（也称为服务网格）中构建共享组 件，可以更轻松地推出更改的内容并实现跨服务的一致安全性。 动机 为了提高资源利用率、构建可用性高的应用并简化 Google 开发者的工作，Google 采用了容 器和容器编排技术。促使我们采用容器化基础架构的另一个动机是为了让我们的安全控制措 施与我们的架构保持一致。我们早就知道，基于边界的安全模型不够安全。一旦攻击者突破 了边界，就可以在边界内的网络中畅行无阻。虽然我们意识到我们需要加强整个基础架构的 安全控制措施，但我们也希望 Google 开发者能够轻松编写和部署安全应用，而不必自行实 现安全功能。 从单体式应用迁移到使用编排系统从容器部署的分布式微服务，具有明显的操作优势：更简 单的管理和可扩缩性。这种云原生架构需要使用不同的安全模型和不同的工具来保护与微服 务的管理和可扩缩性优势协调一致的部署。 本文档介绍了 Google 如何实施云原生安全性（本文档称为 BeyondProd）：更改至云原生对 安全性的意义、云原生安全性原则、为满足这些要求而构建的系统，以及有关如何自行应对 类似更改的一些指导。 Google 的云原生安全性 容器化的微服务 https://cloud.google.com/security/beyondprod/ 2/14 2021/2/23 BeyondProd：云原生安全性的新方法 | 文档 | Google Cloud 从早期开始，Google 便有意识地决定利用低成本商用服务器扩大数据中心容量，而不是投资 购买更昂贵的高可用性硬件。我们以前、现在和将来的可靠性指导原则是，系统的任何单一 部分发生故障，都不会影响用户服务的可用性。为了实现这种可用性，需要运行冗余的服务 实例，以便单一故障不会导致服务中断。基于这种原则，我们开发了容器、微服务和容器编 排技术，从而能够以可扩缩的方式管理这些高度冗余和分布式系统的部署。 容器化基础架构意味着每个工作负载都作为自己的一组不可变、可移动、可调度的容器进行 部署。为了在内部管理这些容器，我们开发了一套名为 Borg  (https://research.google.com/pubs/pub43438.html?hl=es)1 (#footnote-1) 的容器编排系统，目前我 们每周仍使用该系统部署数十亿个容器。 容器使工作负载更易于跨机器封装和重新调度。借助微服务，开发者可以更轻松地开发和调 试应用的不同部分。如果将微服务和容器搭配使用，可以将工作负载拆分成更易于管理的较 小单元，方便维护和发现问题。采用具有微服务架构的容器化基础架构被称为采用“云原生  (https://github.com/cncf/toc/blob/master/DEFINITION.md)”架构。服务在 Borg 部署的容器内运 行。此架构会根据需要扩缩工作负载 - 如果对特定工作负载有较高需求，则可能有多台机器 运行相同服务的副本以处理所需的工作负载规模。 Google 的与众不同之处在于：在我们架构的每一次演变中，我们都考虑了安全性。最近的云 原生安全性概念与 Google 多年来用于保护我们基础架构的概念相当接近。我们采用这种微 服务架构和开发过程的目标，是在开发和部署生命周期中尽早解决安全问题（这一阶段解决 问题的花费较低），并通过标准化和一致的方式加以解决。最终的结果是，开发者在确保安 全性方面花费的时间更少，同时仍能获得更安全的效果。 迁移到云原生架构 现代的安全架构已经超越了基于边界的传统安全模型，传统模型通过防火墙保护边界，而内 部的任何用户或服务受到完全的信任。BeyondCorp 旨在顺应现代公司用户的工作方式变 化。如今，用户采用移动工作方式，常常会在组织的传统安全边界之外（例如咖啡馆、飞机 或者这两者之间的任何地方）工作。在 BeyondCorp 中，我们摈弃了特权公司网络的概念， 完全根据设备和用户凭据及特性授予访问权限，而不考虑用户的网络位置。 云原生安全性解决了服务与用户所面临的共同问题 - 在云原生环境中，我们不能单纯依靠防 火墙来保护生产网络，正如我们不能依靠防火墙来保护公司网络一样。用户并非总是使用同 一物理位置或设备，同样地，开发者并非总会将代码部署到同一环境。借助 BeyondProd， https://cloud.google.com/security/beyondprod/ 3/14 2021/2/23 BeyondProd：云原生安全性的新方法 | 文档 | Google Cloud 微服务不仅可以在受到防火墙保护的数据中心内运行，还可以在公有云、私有云或第三方托 管的服务中运行；在所有地方，它们都必须是安全的。 就像用户会移动、使用不同的设备以及从不同的位置建立连接一样，微服务也会移动并且会 跨异构主机部署在不同的环境中。BeyondCorp 认为“用户信任应该取决于设备的上下文感知 状态等特征，而不是连接到公司网络的权限”；BeyondProd 认为“服务信任应该取决于代码出 处和服务身份等特征，而不是生产网络中的位置（例如 IP 地址或主机名身份）”。 云原生架构和应用开发 较传统的安全模型专注于基于边界的安全性，无法独力保护云原生架构。假设有这样一个示 例：采用三层架构的单体式应用部署到私有公司数据中心，该中心有足够的容量来处理重要 事件的峰值负载。具有特定硬件或网络要求的应用被特意部署到通常保留固定 IP 地址的特定 机器上。更新的发布频率较低、规模较大、难以协调，因为更新所带来的更改会同时影响应 用的许多部分。这会导致应用的生命周期极长，而且更新频率较低，其安全补丁程序的应用 频率通常也较低。 然而，在云原生模型中，容器会将应用所需的二进制文件与底层主机操作系统分离，使应用 更具可移植性。容器是不可改变的，意味着容器在部署后不会更改，因此会频繁重新构建和 重新部署。作业将扩缩以处理负载：在负载增加时部署新作业，在负载减少时终止现有作 业。由于容器会频繁重启、终止或重新调度，因此硬件和网络会得到更加频繁的重复使用和 共享。借助通用的标准化构建和分发流程，团队之间的开发流程更加一致、统一，即使团队 独立管理其微服务的开发也是如此。因此，安全性相关事务（例如安全性审核、代码扫描和 漏洞管理）可以在开发周期的早期阶段进行。 对安全性的影响 我们已经介绍过很多关于不可信内部（BeyondCorp 中的用户）模型如何应用到 BeyondProd 中的微服务的内容，但这种变化是怎样的呢？表 1 对比了传统基础架构安全性方面与云原生 架构中的安全性方面。此表还显示了从一种架构迁移到另一种架构所需要满足的要求。本部 分的其余内容详细介绍了此表中的每一行。 传统基础架构安全性 云原生安全性 针对云原生安全性的隐含要 求 基于边界的安全性（例如防火墙），其内 零信任安全性，对服务之间的通信进 对边缘网络的保护仍然适 部通信被认为是受到信任的。 行验证，环境中的服务没有隐式信 用，服务之间没有固有的相 任。 互信任。 https://cloud.google.com/security/beyondprod/ 4/14 2021/2/23 BeyondProd：云原生安全性的新方法 | 文档 | Google Cloud 用于特定应用的固定 IP 地址和硬件。 更高的资源