Google Cloud Platform 上的基础架构持续合规性

在不久之前，乃至当下的 2022 年，安全通常被视为“快速发展”和“保持合规”之间非此即彼的零和博弈。分享今天这篇博客的初衷，便是想扭转这一观念。下文，我将介绍一个保障安全合规的基础框架，将“零和博弈”转变为“双赢游戏”，让我们“走得快”的同时，又“走得稳”。

该框架的一个重要原则是从“出入口拦截”到“整体性引导”的转变。请允许我使用下面的照片详细说明。

在左侧展示的，是一张停车场的照片；而在右侧，我们放置的是一张高速公路的照片

如左图所示，停车场在边界处，一般都会设有出入闸门。闸门每一次只允许一辆车通过，在繁忙时车辆也会因为这一限制，在闸门处堵塞。当然，如果我们骑的是自行车，绕过吊杆闸门其实也并不难。一旦我们进入停车场内部，一般就不会遇到其他拦截了。我们可以自由地从一层到另一层，在不同车位间切换位置，甚至畅通无阻地通过停车场进入办公楼。

相信上述场景，大家都很熟悉。 好的，现在我们再回忆一下在高速公路上开车的经历。高速公路上，没有闸门，没有红绿灯，没有急转弯，没有交通拥堵。这一场景下，我们不但可以在满足交通法规的条件下，比普通道路行驶得更快，而且高速公路的事故率也比普通道路更低。

相比停车场，高速公路设置的控制更少，那又是如何实现更高的速度和更可靠的安全性的呢？

下面，让我们来揭开谜题。

事实上，高速公路对所有司机都提供指导性规则。例如限速、单行方向、设置出口前减速带等引导。根据这些指导性规则，高速公路的基础设施也设有一系列的预防措施，例如将相反的交通动线用中间的隔离护栏分隔开，在道路两侧搭建保护护栏以减少交通事故。遵循同一套指导性规则，高速公路还设有监测和响应控制装置，例如测速仪、摄像头，来提醒司机他们的行驶方向以及他们行驶速度等。此外，高速公路的路面还安装有震荡减速标线，提醒打瞌睡的司机，或者提醒司机在接近收费站前减速。

事实上，我们从高速公路这一基础设施上学到的知识，同样适用于数字基础设施，可以应用到云上。

首先，我们来看一个典型的合规周期规律。

如上图所示，合规定义的是一个期望的状态。简单来说，就是定义“理想的合规，应该是什么样子”。需要强调的是，理想状态与实际状态之间的差距代表的不仅是缺失的安全机制，也是下一次审计和整改的所需成本。

相反，下面这张图才是我们所需要的安全合规图景。

这便是让实际状态持续地追齐理想状态。简而言之，就是“让现实不断和理想重合”。针对外部安全隐患，我们需要设置具有可持续性的预防控制措施，来拦截不安全的资源被引入环境中。针对内部运行状况，我们需要设置具有可持续性的检测控制来及时发现不合规的资源。针对已被破坏的安全资源，我们也需要设置具有可持续性的响应控制来自动修复不合规的资源。换句话说，我们需要的是具有可持续性的长效合规机制。

为便于小伙伴们理解，接下来让我向大家展示 Google Cloud 是如何在云上做到基础设施长效合规架构的。

基础设施长效合规性参考架构

下图展示的是一个开放、可扩展的持续合规参考架构。

这一参考架构的核心是构建指导、预防、检测和响应控制的闭环机制，同时架构本身保持开放性和可扩展性。在本篇博文中，我将用 Google Cloud 作为参考示例展示。事实上，你将很快意识到，你也可以应用该架构，服务于其他云服务平台甚至本地基础设施。

指导控制

该闭环机制的起点是构建指导控制，其核心是技术控制库。技术控制库可以理解为链接合规性要求和技术控制落地之间的桥梁。操作上，我们可以利用控制映射，来构建技术控制库。

打个比方，我们可以想象技术控制库是一张电子数据表格。表格的左边有合规的要求，例如“必须使用加密”、“不得把虚拟机暴露于外网”等等。表格的右边有可以在 Google Cloud 上配置的对应解决方案，例如“使用客户管理密匙”，“使用 Organisation Policies”等等。这一从左到右的对应结构，就类似于一个从合规语言到技术语言的“翻译”过程。从右到左看的逻辑，则可以证明安全解决方案的合规必要性。这一映射关系，不但可以帮我们将云的安全性与合规性建立联系，还可以降低长期性的合规审计成本。 动态的合规性要求，可能来自各种来源渠道，例如参考架构里提到的需求，如行业竞对威胁、内部安全策略和标准、遵守外部法规以及行业最佳实践框架等。

需要强调的是，技术控制库是一个动态文档。如果是刚刚开始，我不建议花太多时间开发一个大而全的控制库。相反，我建议大家从 CIS GCP Foundation 基准开始。这是出于两点原因。首先，该基准是轻量级的，它包含了任何使用 Google Cloud 的客户都应具有的基础安全配置。以二八原则来解释的话，正确的配置以上 CIS 的安全基准，就如同部署能产生80%的收益的20%投入。其次，安全指挥中心（Security Command Center）升级版有一项“安全健康分析”功能。这一开箱即用的功能，可根据 41 条 CIS 的规则，持续监控 Google Cloud 平台环境，并针对不合规的现象，发起警报和提供整改建议。

整体来看，技术控制库还将指导闭环其余部分的构建。对于每一个控制指令，你都将有相应的预防控制，来防止不合规的资源被部署；你也将有对应的检测控制指令，来监测整个环境以定位不合规的资源；同时，你还将有对应检测控制的响应控制，来自动修复不合规资源或触发其他响应工作流程。最后，每个节点也都将会给工程师提供反馈机制。这是因为，及时的反馈可提供更好的工程师体验，并在短期内提高开发速度。从长远来看，这些反馈机制会帮助工程师培养良好的开发习惯，去编写更可靠、更安全的代码。

预防控制

操作模式上，Google Cloud 上的几乎每个操作都是 API 的调用。例如，创建、配置、删除资源等。由此，预防控制其实都与 API 调用限制相关。这些 API 调用有不同的方式，可以是基础设施即代码 (IaC) 解决方案，例如 Terraform、Google Cloud Deployment Manager；也可以是云控制台 UI；例如 Cloud Shell SDK、Python 或 GO SDK 等。

对于 IaC 解决方案，就像任何其他应用程序代码开发一样，我们可以使用持续集成 (CI) 解决方案，在 CI 上加上 IaC 的安全测试，类似于为应用程序代码编写的单元测试。由于 IaC 都可以转换为 JSON 格式，因此我们可以使用 Open Policy Agent (OPA) 作为 IaC 安全单元测试的工具。鉴于 OPA 的 Rego 策略语言的扩展性和灵活性，我们可以用 Rego 构建几乎所有应用场景。当然，也可以选择自带策略的商业或开源解决方案，例如 Prisma Cloud、Checkmarx KICS、Aquasec Tfsec 等。其中，Checkmarx KICS 是基于 OPA Rego 的开源项目，并且拥有 CIS 基准映射；而集成在 CI 上的 KICS，则可以让我们快速地构建 IaC 的预防控制，并基于 KICS 的代码库，去进一步实现自定义或者扩展。

对于非 IaC 输入源，我们则需要利用 Organisation Policies 和 IAM，因为这是两个更接近 Google Cloud 平台 API 控制的解决方案。在这里，需要注意的是 Organisation Policies 的设计应该是粗颗粒度的，而 IAM 策略应该是细粒度的。基于这种设计，Organisation Policies 和 IAM 同样会对 IaC 的输入源进行控制。理想情况下，我们应该让 IaC 作为生产环境唯一的输入源，并限制云控制台和其他 SDK，由此就可以实现对云基础设施变更管理的统一管控。

检测和响应控制

假设我们已经进行了完善的预防控制部署，云基础设施环境从理论上来说应该就是安全的。那么，为什么我们仍然需要检测和响应控制呢？一般而言，会有以下几个原因。

一方面，在实际情况中，并非所有预防控制都可以被妥善执行。例如在 CI 上，我们可能不会让所有拥有外部 IP 地址的虚拟机（VMs）在 Google Compute Engine 都部署失败，因为一些特定软件或场景，确实可能需要外部 IP 地址。

另一方面原因，是我们出于审计的目的，希望利用检测控制生成带有时间戳的合规状态。以 CIS 合规为例，我们的确可以让 CI 强制执行所有 CIS 检查，并将 IaC 设置为部署云基础设施的唯一部署源。但是，我们仍然需要使用 Security Command Centre 安全健康分析或 Prisma Cloud 合规性解决方案，来提供 CIS 正在运行时的合规性报告。

实际部署中，检测控制会发现不合规的云基础设施，并将这些发现生成事件，进而依据这些事件，我们就可以使用 Pub/Sub 和 Cloud Function 的组合，来触发响应控制。谈及响应控制，它不限于自动修复，也可以是通过电子邮件、即时聊天工具的报警，或者与 ITSM 系统的集成。需要强调的是，如果我们使用 Terraform 部署云基础设施并使用 Cloud Function 来进行自动修复，就需要格外关注 Terraform 的状态。由于 Cloud Function 执行的自动修复操作，不会被记录在 Terraform 状态文件中，所以我们需要去调整相应的工作流程，让工程师更新 Terraform 源代码。

关于构建检测和响应控制，使用原生云平台解决方案更具优势。第一个原因，是易于集成。开箱即用的 Security Command Centre 便是一个好例子。运行机制上，Security Command Centre 会执行检测，并推送检测结果到 Pub/Sub，从而触发 Cloud Function。以上所有的集成都由 Cloud IAM 控制，且不存在任何长期性机密。第二个原因，则是性能。作为 Google Cloud 平台的一部分，Security Command Centre 更接近于它所监控的服务。从 Security Command Centre、Pub/Sub、Cloud Function 到目标修复资源 API 的流量，都能够畅行于 Google Cloud 的高性能网络内。例如，我一直使用 Security Command Centre、Pub/Sub、Cloud Function + Python SDK，运行“不安全的 SSH 防火墙规则检测和自动修复”这一演示。一直以来，我都会要求参与者去记录 Security Command Centre 检测和删除不安全的 SSH 防火墙规则的耗时，测试结果都在 5 到 10 秒之间！

参考架构应用展示

为了让参考架构更加容易理解，我在这里插入一个应用该架构的示例。

在这个示例中，我选择了如下开源和 Google Cloud 解决方案。

如前文所示，我将从指导控制开始构建架构闭环。

首先，我遵循了 CIS GCP Foundation 基准要求 3.6 - “确保 SSH 访问受限于 Internet”。其后，针对该要求，我在 Google Cloud 上用 Organisation Policies、Checkmarx KICS 和 Security Command Centre 上执行了简单控制映射。例如，我会用Checkmarx KICS 来控制 Terraform 代码输入，我会用 Organisation Policies 来确保具有外部 IP 地址的虚拟机无法部署。最后，在监测开放 SSH 防火墙规则时，我会想用 Security Command Centre 进行及时预警。

一旦完成了控制映射之后，我们将开始设计相应的预防控制。

首先，我会使用 Cloud Build 去编排 Checkmarx KICS 开启扫描，并将扫描结果上传到 Cloud Storage 存储桶。然后，我同样会在 Cloud Build 上编写作业脚本，这一自动化脚本会根据 Checkmarx KICS 的中、高等扫描结果，去阻断运行。通过运行 KICS 扫描操作，Cloud Build 会向 Pub/Sub 主题推送消息，从而触发另一个 Cloud Build 作业去部署 Terraform 代码。同时，Organisation Policies 将作为最后一重防护，来阻截所有来自外部的 IP 虚拟机部署。

为实现检测和响应控制，我会在 Security Command Centre 进行配置，来查找“0.0.0.0/0”源 IP 地址和目标端口为“TCP:22”防火墙规则的检测项。一旦 Security Command Center 发现不合规的防火墙规则，它将通过 Pub/Sub 去触发两个 Cloud Functions，一个删除防火墙规则，另一个向 Slack SecOps 通道发送消息。

现在便大功告成了！没错，我们使用上文讲述的基础设施长效合规参考架构，搭建完成了一个简单的闭环示例！

有关参考架构的深入思考

目前，我们已经在这篇博文讨论了安全性和合规性。接下来，我想给大家分享一些值得深思的内容。首先，我们已经谈论了这一参考架构兼具开放性和可扩展性。事实上，它可以应用到安全之外的更多场景。

下图是同一个参考架构的另一个应用。保障安全性和合规性之余，我们能在不同方面扩展指导控制策略的应用定义。借助 Open Policy Agent、Cloud Function 和其他市场检测解决方案的灵活应用，根据同一套工作流程，我们可以在可用性、成本优化、可见性等方面构建闭环示例。

下一步行动

我建议应用、更新、调试该基础架构作为云安全策略的一部分。如果你使用的是 Google Cloud 平台，请从 CIS GCP Foundation 起步，使用安全指挥中心获取你的环境基准，后续使用预防性控制和响应性控制。