在 AWS 的视角下，正确打开零信任安全模型

上海华讯网络系统有限公司作为大中华区首家 AWS 安全能力（AWS Security Competency）认证合作伙伴，我们在本次亚马逊 re:Invent 上格外关注安全主题，其中“AWS 视角下的零信任”，这个分享是颇为引起共鸣的一个。在实际的安全咨询和公有云项目中，我们不断地思考如何构建适合于公有云的安全模型，如何组合、平衡纷繁复杂的安全产品和服务，以合理的成本为我们在云中的数字资产提供较为全面完整的安全保护。

目前，较为流行的安全模型或理念是零信任安全模型。零信任安全模型不是单一地以网络相关的控制为基础，既“虽然访问来自可信的网络域，但仍不信任访问者的身份或所使用的设备，需要满足更多的安全防护机制”，其核心在于全面分析和适度完整。当前安全领域的产品与解决方案普遍都是基于零信任安全模型发展演进的。无论数字化工作空间、无边界网络，还是下一代防火墙，其本质都是在网络中心安全模型（既基于物理或逻辑的位置寻址进行安全控制的模型）的基础上，增加对人和设备的识别和控制，构建以身份为中心的安全模型。

为什么零信任安全模型对于公有云环境如此重要？参看下图可看出，公有云环境所面临的安全风险结构与传统数据中心有较大不同。

好在 AWS 提供了从方法到工具一整套安全体系以帮助用户应对这些安全风险。AWS 安全专家 Quint 在亚马逊 re:Invent 的分享中指出，AWS 是倾向于将网络中心安全模型与身份中心安全模型合二为一的。用通俗的话说，就是既关心从哪里来到哪里去，也关心是谁，用什么方式。在过去，由于软硬件及网络的边界的存在，网络中心安全模型和身份中心安全模型往往是割裂的，通常由不同的安全产品和解决方案防护，甚至是由不同的团队负责，这给实现零信任安全模型带来了很大挑战。云计算技术将软硬件打包抽象为服务，使这种安全模型的融合成为可能。

云原生和应用架构现代化等新发展趋势给安全架构的全面完整提出了更高的要求，需要考虑的层面更多。亚马逊 re:Invent 在分享中以 Endpoint 为例，向我们展示了 AWS 如何通过创新式的设计，来应对这种挑战，帮助用户构建零信任安全模型。

一个典型的服务就是终端节点（Endpoint）。在示例中，附加到 Endpoint 的 Policy 定义了两个 Condition。其中， aws:SourceVpce 指定了访问服务的 Endpoint 来源，aws:PrincipalARN 指定了可访问服务的 IAM Role，即网络中心安全模型和身份中心安全模型同时出现在终端节点策略中。对于传统网络工程师来说，Endpoint 是一个全新的网络概念。Amazon VPC 终端节点有三种类型，分别是接口终端节点（Interface Endpoint）、网关终端节点（Gateway Endpoint）和网关负载均衡终端节点（Gateway Load Balancer Endpoint）。

事实上，Endpoint 大致可以看作将网络接口、网关、负载均衡和应用防火墙四类传统网络组件融合抽象成的网络云服务，这种功能上的整合无疑大幅降低了网络的复杂度和构建成本，帮助用户更容易地实现零信任安全模型。更重要的是，终端节点策略的逻辑和编写方式，与基于身份的策略（Identity-based policy）、基于资源的策略（resource-based policy），以及 Organization 的服务控制策略（Service Control Policy，SCP）是高度一致的，从而在整个 AWS 环境形成了一套多层次的安全策略体系。

除了亚马逊 re:Invent 分享中提到的例子，Amazon Elastic Kubernetes Service (Amazon EKS) 也是一个很好实现身份中心安全模型的服务。在容器架构下，我们可以通过 IAM roles for service account 或 Pod execution role、Service-Linked role、Cluster IAM role 以及 Node IAM role 将 AWS 身份中心的安全模型扩展到容器环境中，实现容器的管理平面和计算平面到其他云服务和资源的零信任控制。

零信任安全模型其实并不局限于身份维度。在实际项目中，我们其实可以通过 Policy condition key 将其他维度增加到安全模型中。例如，aws:CurrentTime 和 aws:EpochTime 可以在时间维度增加控制，aws:UserAgent 可以在客户端维度增加控制。另外，web identity federation 和 SAML-based AWS STS federation 可以将身份中心安全模型扩展到 IAM 身份以外，增加更多可控维度，如根据用户的部门或职级进行控制等。

Quint 举的另一个例子是 Amazon WorkSpaces 的应用。虚拟桌面是构建新型安全边界的另一种手段，其本质是将高度可控的访问终端设备限定在 AWS 环境范围内，为应用访问增加了身份和其他安全控制维度，适合于一些应用类型复杂，不易实现零信任安全模型的场景。除了 Amazon WorkSpaces，像 AWS System Manager 和 Amazon Cognito 这样的服务，也都可以帮助用户将 AWS 的身份中心安全模型扩展到非 AWS 的系统和应用中。

零信任安全模型的建立，主要是通过多维度安全策略进行实现，而以 AWS 为代表的公有云服务，已经在一定程度上实现了对多维度安全策略的支持，是一个“相对完美的解决方案”。但这并不是一个开箱即用的过程，需要从架构角度进行精细化的分析。通常来说，可以将云服务进一步抽象为平台服务和承载服务两类。对于承载服务，又通常划分为管理平面（如 Amazon EKS 中用户不可见的管理节点、Amazon EMR 中用户可见的 Master 节点）、计算平面（如 Amazon EKS 中的 Node Group）和数据平面（如 Amazon Elastic Block Store (Amazon EBS)、Amazon Simple Storage Service (Amazon S3)、Amazon RDS）三部分。

对于不同的服务和组成部分，往往需要使用不同的手段来进行网络、身份和其他维度的控制。对于身份，往往又区分为平台用户、系统及环境用户、终端应用用户、设备及服务等几类身份。零信任安全模型需要对这些不同架构边界之间的访问关系进行详细的分析，将安全融入到架构中，这也是 AWS 强调的 Security By Design 的意义所在。

限于篇幅，这里无法进行更多的举例展开和代码分析，但更重要的是，零信任安全模型是一个思考框架而不是一个技术或方法。希望通过本文的拆解举例，能够帮助您更好地理解 AWS 云服务的设计理念和运作逻辑，设计出更符合自己需求的零信任安全模型。

最后，我们总结了在构建公有云零信任安全模型实践中的一些经验与建议，供大家参考：

1、将身份和设备管理纳入云架构中统一考虑，充分利用 AWS IAM 的 Federation 特性，以及云服务对 IAM Role 的支持，考虑设备安全和管理解决方案。

2、设定权限边界和使用 IAM 访问分析，以及借助 AWS Marketplace 中的 Cloud Workload Protection（CWP）等第三方安全产品，帮助构建身份中心安全体系。

3、从架构角度，而不是根据经验和单一方案来进行安全设计，尤其是从未使用过的云服务。安全产品的功能往往存在交叠的情况，只有从架构角度而不是产品角度进行考虑才能做到合理取舍。

4、除了架构层面的维度，还要从云资源的生命周期角度考虑安全。也就是说，除了运行外，构建、交付和销毁的过程也需要考虑安全。

5、在混合云环境中，可以考虑使用统一的安全解决方案构建零信任安全模型，但要注意第三方方案无法覆盖的盲点。

6、除了防护体系，以下安全支撑体系也需要着重考虑：安全信息管理（包括收集、存储、查询、可视化、分析支持、智能分析等）、DevSecOps、安全自动化运维。

7、风险识别与评估体系，平衡安全成本与风险，通常使用公有云原生的安全特性与安全服务可以帮助用户简化安全架构和降低安全成本。

原文链接：在 AWS 的视角下，正确打开零信任安全模型