Google 发布云原生安全模型 BeyondProd，以实现云本地安全性

最近发布的Google BeyondProd白皮书，详细介绍了这个容器化的云原生安全模型。Google 的模型超越了传统的基于边界的安全模型，而是利用代码来源和服务身份标识作为安全基石。同时，Google 还提供了一份可用于实现其安全模型的开源软件列表。

Google容器安全项目经理（PM）Maya Kaczorowski写到，“BeyondProd 可以确保数十亿个容器的安全性，这些容器每周都会部署”。与用于企业安全的Google BeyondCorp模型类似，BeyondProd 的核心思想是，组织不应该信任任何实体，无论该实体是在边界内还是在边界外，应该遵循“永不信任，始终验证”的原则。与企业安全相比，云原生安全考虑了容器的使用，Kaczorowski解释道：

使用容器的第一个主要区别是调度。我们不能依靠 IP 地址或主机名来确保安全性，而是需要服务身份标识。

在过去的几年里，在“零信任”网络的名义下，这个理念得到了越来越多的关注。正如独立网络安全顾问Michael Brunton-Spall 所说：

“我们不能因为你在网络上就可以完全信任你”，我认为，事实上，在很多情况下，这可能意味着我们不应该那么信任你。我看到大多数政府部门的网络都曾遭到攻击。“在网络上”并不是一个好的信任指标。

在零信任网络中，保护其外围网络仍然至关重要。然而，要将其发展为完全的零信任网络还需要一些额外的规定。但这绝非易事，因为目前要做到这一点尚缺乏标准的方法，Brunton-Spall 补充道：

我们可以从做过这件事的人那里了解到，“它”需要定制。如果要定制我们自己的，需要吸取前人的经验，去参加会议，向做过这件事的人学习。

为了填补这一空白，Google 的白皮书制定了一系列的基本原则，补充了“服务之间互不信任”的基本理念。其中包括在受信任的机器上运行已知来源的代码、创建“扼要点”（choke points）来跨服务实施安全策略、定义实施变更的标准方法以及隔离工作负载。最重要的是，

这些控件意味着容器及运行在容器内的微服务可以安全地部署，它们可以彼此通信，并彼此相邻运行，而不会给单个微服务开发人员带来底层基础设施安全性和实现细节的负担。

这些原则的应用需要组织改变其基础设施和研发过程，以便尽早地在其产品中构建安全性，同时又不会给单个开发人员带来安全隐患，从而可以有效地从DevOps过渡到DevSecOps模式。

对于感兴趣的组织来说，这不是一件简单的事情，也不是没有成本的，而且 Google 多年来一直在构建内部工具，并致力于研发流程。一个很好的起点是，可以利用 Google 提供的开源软件和其他工具的列表，包括Envoy、Traffic Director、Kubernetes admission controllers等等。

原文链接：

Google Publishes Its BeyondProd Cloud-native Security Model