零信任架构是什么？听听亚马逊云科技大咖怎么说！

在亚马逊云科技 (Amazon Web Services)，我们始终坚持着代表客户推动创新的使命，致力于帮助他们在安全可靠的系统上轻松实现构建、部署以及快速迭代等日常工作。从安全角度着眼，我们一直努力为客户提供更稳固的保障性解决方案，确保他们始终享有具备良好机密性、完整性与可用性的Amazon系统与数据服务，同时不断提升业务流程的运行速度与敏捷性。为此，客户们开始积极咨询零信任架构、或者称零信任网络，能够在安全领域发挥怎样的作用。为了回应这种呼声，我们自然要给出明确的答案。

鉴于客户对于“零信任”这一新兴概念的日益关注，结合“零信任”框架下各类概念与模型的迅速普及，我们希望整理出自己的一点见解。在本文中，我们将分享关于零信任的基本定义与指导原则，并据此探讨这一领域下出现的更多核心子域。我们也将介绍自亚马逊云科技成立以来，我们如何将这些原则融入至Amazon云架构乃至更多新兴开发趋势当中。最后，我们将回顾Amazon Web Services如何在您自己的“零信任”探索之旅中提供协助，持续关注对于客户最重要的各项基本安全目标。技术方法总会经历一波波迭起兴衰，但安全目标却往往相对恒定。此外，我们也建议您参考亚马逊云科技良好架构框架设计原则中提到的经验与总结。

零信任的定义与指导原则

让我们先从笼统的定义出发。零信任是指一种概念模型以及与之匹配的相关机制，着重于围绕数字化资产提供安全控制，而且这里的数字化资产已经不再完全、或者在根本上不再依赖于传统的网络控制或网络边界。零信任中的“零”，强调的是削减以往根据参与者在传统网络中的定位而建立的默许信任，这里的参与者包括人员、也包括软件组件。在“零信任”的世界中，以网络为中心的传统信任模型将被更多新兴方案所增强或替代（由此构成所谓「以身份为中心」的控制机制），借此提供等同甚至超越以往效能的安全保障机制。需要强调的是，即使总体安全状况保持不变，这种新型安全机制也能在可用性与灵活性等层面做出突破。下面，我们将具体介绍关于这两大维度的更多细节与可行实现方法。

其中一大维度体现在网络层面。即我们是不是允许所有网络数据包能够在全部主机或端点间流动，同时在网络层上方建立总体安全控制以实现零信任？或者是将原有系统拆分成多个较小的逻辑组件，并建立起更为紧密的网段或数据包层级控制（即所谓微段或微边界）？我们是否添加了某种网关或代理技术，借此实现一种新的信任边界？我们是否仍然使用VPN技术以保证网络隔离，但进一步提升了VPN的动态性并将其隐藏在用户体验之内，借此保证用户几乎感受不到网络边界的按需建立与撤销过程？又或者，我们能不能将这些技术整合起来，创造出更统一的全面服务方案？

另一个维度则是身份与访问管理。我们关注的是人员如何通过PC、平板电脑以及智能手机访问Web应用？还是同时也关注机器对机器、软件对软件间的通信，其中所有请求都需要使用各类技术进行身份验证与授权？也许真正的现实，要求我们将这两种场景结合起来。例如，用户状态当中与安全相关的某些属性或特征（例如身份验证强度、设备类型、所有权、状态评估、健康状况、网络位置等）会传播至与用户交互的软件系统当中，而我们需要在传播期间动态变更其访问权限。

因此，要想深入探索“零信任”世界，我们必须得掌握上述主题与概念，并厘清这各种复杂因素带来的混乱关系。虽然前路坎坷，但其间我们也将逐渐找到提升软件系统质量、灵活性与安全性的重大机遇。那么，有没有什么原则能帮助我们破除迷雾、抓住机遇？

零信任的头号指导原则，在于虽然这种新架构在概念上减少了对网络位置的依赖，但网络控制与边界设备在整个安全体系中仍然扮演重要角色。换句话说，最佳安全性不可能源自对“以身份为中心”或者“以网络为中心”的单方面选择，而必须将二者有效加以结合。以身份为中心的控制机制（例如Amazon SigV4请求签名过程）用于同Amazon API端点进行交互，并对每项经过签名的API请求进行唯一身份验证与授权，同时提供细粒度访问控制。在另一方面，以网络为中心的工具，例如Amazon Virtual Private Cloud （Amazon VPC）、安全组、Amazon PrivateLink以及VPC端点等，能够以易于理解与使用的方式高效过滤干扰因素，在以身份为中心的环境中提供出色的可操作护栏功能。在理想情况下，这两类控制方法不仅应该共存，也应彼此理解并相互补充。例如，VPC端点提供附加策略功能，允许大家在逻辑网络边界位置编写并实施以身份为中心的规则。以此为基础，私有网络将由Amazon VPC顺利接入附近的Amazon服务端点。

零信任的第二项指导原则，是在不同上下文中表达出不同的含义。这一原则也是造成零信任概念模糊不清的重要原因——零信任术语涵盖多种不同用例，各类用例间只存在网络位置或边界等少量与安全相关的共通技术概念，而在实际能够达成的目标方面存在巨大差异。如前文所述，零信任目标的常见示例包括保证员工敏捷性与移动性（即使用浏览器、移动应用以及互联网服务访问业务系统与应用程序），以及在基于云端的新环境下开发出设计严密、高度细分的微服务架构应用程序等。只有专注于我们需要解决的特定问题，并以新的视角与工具加以解决，我们才能避免陷入“安全挑战是否真实存在”或者“零信任的价值回报该如何体现”这种无甚现实意义的讨论当中。

我们的第三项指导原则是，必须根据系统以及受保护数据的组织价值来应用零信任概念。随着时间推移，零信任概念模型与相关机制的应用将持续改善纵深防御能力，并通过增强云可见性与软件定义特性等方式改善安全控制措施。只要应用得当，零信任原则将能够显著提高安全标准，特别是极大强化对关键工作负载的保护能力。但如果硬要把零信任方法套进传统安全观念体系之内，反而会限制传统技术在升级或新型系统中的应用，最终导致付出与回报不成正比、将零信任革新扼杀在起步阶段。对于大部分业务系统而言，网络控制与网络边界仍然非常重要，而且在可预见的未来将继续提供良好的控制能力。在我们看来，最好能将零信任概念视为对现有安全控制与定义体系的补充、而非替代方案。

Amazon云中的

现有零信任原则与功能应用实例

最突出的Amazon零信任实例，自然是数百万客户每天如何通过Amazon管理控制台或各类公共/私有网络安全调用Amazon API，借此与Amazon服务实现交互。无论是通过控制台、Amazon命令行界面（Amazon CLI）还是编写并指向Amazon API的软件调用，所有这些交互方式最终都将抵达一组Web服务，其服务端点面向互联网接受访问。Amazon API基础设施的安全保障当然不可能单纯依赖于公共网络。每一秒钟，Amazon基础设施都需要对来自全球的数百万项请求进行快速认证与授权。我们的客户对此充满信心，他们相信底层传输层安全（TLS）协议的良好加密强度（由Amazon Signature v4签名过程进行增强）能够适当保护这些请求，确保他们无需分神于底层网络的可靠性问题。有趣的是，关于零信任架构的讨论中很少涉及基于云的API。这可能是因为Amazon从起步阶段就已经采用这种方法进行API保护，因此讨论各方已经默认将此视为云安全体系中的必要组成部分。

再聊聊下一个理解难度略高的问题：当各项Amazon服务需要彼此调用以实现服务功能操作与交付时，整个认证与交付过程与之前提到的客户操作也完全一致。您可以查看服务所关联的权限角色，借此理解其中的交互过程。例如，当Amazon Auto Scaling确定需要调用Amazon Elastic Compute Cloud (Amazon EC2) API以创建或终止账户内的EC2实例时，Amazon Auto Scaling将立即获得您在账户中提供的服务相关角色。您的账户将接收系统生成的Amazon临时凭证，并使用这些凭证通过SigV4过程对EC2 API请求进行签名。在接收端，Amazon身份与访问管理（IAM）则对Ec2的传入调用进行身份验证与授权。换句话说，即使全部属于Amazon的内部服务，Amazon Auto Scaling与EC2之间也不存在任何默认的固有信任关系，而是坚持使用强大的身份中心式控制机制代表您对这两项服务进行安全操作。客户可以随时查看您为特定服务授予的相应权限，Amazon CloudTrail会持续记录这些权限的使用情况。

在IoT Service等其他Amazon产品组合中，您也能找到关于零信任功能的出色示例。在最初推出Amazon IoT Core时，我们做出一项重要的战略性决策（在当时甚至有违行业规范），即要求物联网设备在接入服务端点时始终需要接受TLS网络加密与现代客户端身份验证——包括基于证书的双向TLS。在此之后，我们又在FreeRTOS中添加了TLS支持能力，借此实现了以往在小型CPU与存储设备上根本无法想象的现代化安全通信机制。借助Amazon IoT Greengrass，我们开创了一种使用远程网关使用现有非安全设备的方式。这套网关以本地网络为基础，同时能够运行Amazon Lambda函数以验证安全性并提供云安全代理。这些示例再次证明，Amazon遵循的安全标准已经将零信任关键基础组件引入成熟的生产级技术领域，彻底破除了以往以大量未经身份验证、未加密网络消息进行互联网通信的陈旧惯例。

Amazon如何帮助您推进零信任探索之旅

为了帮助大家顺利完成自己的零信任探索之旅，Amazon推出了多种专供云环境使用的身份与网络功能，而零信任构建单元已经成为其中普遍存在的标准要素。通过简单的API调用，您无需构建、维护或运营任何基础设施或其他软件组件，即可充分享受Amazon服务中的默认安全保障设计。为了更易于理解，我们接下来将通过三个不同用例，结合实际场景讨论这些功能：

1. 对各组件间的特定流进行授权，因此消除意外发生的横向网络移动问题。

2. 保证员工以无摩擦方式访问内部应用程序。

3. 保障数字化转型项目（例如物联网）安全。

这里的第一个用例主要集中在机器对机器通信场景当中——对组件之间的特定通信流进行授权，有助于消除横向网络移动风险。如果两个组件之间本不需要保持网络通信，那么即使二者恰好存在于同一网络或网段之内，也不应具备相互通信能力。这不仅大大减少了系统连接的攻击面，同时也消除了不必要的路径、特别是指向敏感数据的非必要路径。在这一用例中，我们的讨论需要从安全组机制起步。安全组是Amazon EC2服务发布之初即同步亮相的护航级功能。安全组能够为南北向与东西向流量提供高度动态且软件定义式的网络微边界。安全组的分配随着资源使用活动的发生而自动执行，且同一安全组内的规则也可以供同一Amazon VPC之内、同一区域之内甚至不同区域之间的大型对等网络通过ID进行互相引用。这些天然性质，令安全组足以成为一种强大的身份管理系统，其中各组成员身份分别对应不同的网络流量收发规则。以此为基础，大家可以编写出精细的管理条款，且规则本身不会受到成员添加/撤销等日常操作的频繁影响。同样的，PrivateLink则是微边界与微网段空间内的一种重要构建单元。使用PrivateLink，您可以将负载均衡端点公开为两个VPC之间的专用单向网关，并使用基于身份的严格控制机制确定谁能访问网关、传入数据可以抵达哪些位置等。在默认情况下，流量不可反向传输，VPC之间甚至无法相互路由。目前，成千上万的客户使用PrivateLink作为安全微服务架构中的基础构建单元，供应商们也借此保证PaaS与SaaS服务的安全访问。

再回到关于Amazon API的讨论中来。事实上，用于提供API请求身份验证与授权功能的Amazon SigV4签名过程不仅适用于Amazon服务自身——大家还可以使用Amazon API Gateway服务以同样的方式强化通信接口，借此在开放互联网上安全使用软件接口。API Gateway还提供分布式拒绝服务（DDoS）保护、速率限制与Amazon IAM支持功能。在使用Amazon IAM进行授权时，大家需要编写标准IAM策略，使用专门的策略语言表达式以定义谁有权调用API、可以通过哪些位置执行调用等。调用方需要使用自己的Amazon凭证对请求进行签名，而这部分凭证通常体现为附加至计算资源的IAM角色。IAM将根据策略中的唯一身份验证与授权管理每一次API调用。只需一步，大家的API即可受到大规模、高性能、全球可用IAM服务的严密保护，且无需承担任何额外的管理或维护成本。由API Gateway前端到后端实现的调用操作，将受到双向TLS协议的保护，确保只有API Gateway才能实际调用后端实现。配合这种强大的身份中心式控制机制，您可以进一步做出两种安全选择：将后端实现安全放置在公共网络上；也可以添加VPC集成模型，保证指向VPC内后端实现的API Gateway调用活动始终受到以身份为中心的控制机制（双向TLS）以及以网络为中心的的控制机制（从API Gateway到代码的专用连接）的双重保护。这些功能组合带来的全面安全保障也许只能在云端实现，同时彻底打破了“身份与网络谁才是中心”的无聊争论，一举摆脱了固有安全思路的局限性。

我们的第二个用例，是为组织员工提供无摩擦的内部应用程序访问途径，保证在不损害安全性的前提下提高员工的移动性水平。在传统上，这类应用必须位于强有力的VPN保护之后。但是，VPN的扩展成本往往相当高昂，而且不一定能与现代员工所使用的各类移动设备全面兼容。考虑到这些现实问题，我们必须确保各应用程序之间的严密隔离，借此彻底消除VPN前门。为了实现这个目标，客户们希望根据自己所处行业、风险承受能力、开发者技术水平等现实因素选择一系列技术解决方案。结合实际情况，一部分Amazon客户希望使用桌面即服务（Amazon WorkSpaces）或者应用程序即服务（Amazon AppStream 2.0）模型为零信任架构提供强大而灵活的像素画面代理方法，保证内部员工可以通过PC、平板电脑或者HTML 5等客户端类型轻松经由互联网（如果必要，也可以配合其他网络控制机制及边界设备）访问这些虚拟化桌面或应用程序，由此实现良好体验与业务安全性的完美平衡。另一部分客户则希望找到更好的方法，在无需部署移动设备管理或其他类似技术方案的前提下，通过智能手机安全访问企业生产应用。为了满足这些要求，我们发布了Amazon WorkLink服务，由其提供安全代理以立足Amazon云端呈现复杂的Web应用程序。Amazon WorkLink仅负责将像素画面（以及极少量用于交互的JavaScript代码）流式传输至手机端，并保证绝不在移动设备上存储或缓存任何企业敏感数据。

此外，也有一部分客户希望将内部Web应用程序直接接入互联网。为了满足他们的要求，我们将Amazon Shield、Amazon WAF以及Application Load Balancer with OpenID Connect (OIDC)身份验证服务结合起来，提供一整套完全托管的身份识别网络保护堆栈。Shield提供可轻松管理的DDoS保护服务，能够持续带来在线检测功能与自动内联缓解功能，最大程度减少应用程序的停机时间与延迟。Amazon WAF则是一款Web应用程序防火墙，您可以借此使用Amazon、Amazon Marketplace或者您自主定义的规则组，在Web请求抵达基础设施之前实现监控与保护。除了常规负载均衡功能之外，我们还在Application Load Balancer中启用身份验证功能，帮助大家直接与原有身份服务方（IdP）相集成，在减轻身份验证负担的同时，充分发挥IdP提供的现有功能（例如强身份验证、设备状态评估、有条件访问与策略执行等）。凭借这一强大的组合，您的内部自定义应用程序将获得可以与SaaS应用程序相比肩的出色灵活性，保证工作人员能够身处任何位置享受到SaaS的便捷体验，并在由现代身份标准支持的通用安全模型之下完成业务体系的融合统一。

第三个用例（即对物联网等数字化转型项目的安全保护）与前两个用例存在显著区别。以联网汽车为例，车载传感器将通过移动网络与互联网连接持续将数据发送至云端分析环境之内，借此进行信息处理与洞见提取。这类工作负载将始终游离于传统企业网络之外，因此必须配合一套能够充分反映其基本特征的安全模型。Amazon IoT服务家族为此设计出可扩展性良好的解决方案，可用于向机群内的各设备发布唯一设备ID，而后使用此ID及相关访问控制策略安全控制传感器与云端的通信及交互方式。更重要的是，这套安全体系可以通过Amazon IoT Device Defender、无线软件更新乃至FreeRTOS内置的操作系统升级轻松实现监控与维护，保证设备随时间推移始终拥有良好的安全表现。展望未来，随着越来越多的IT工作负载逐步转向边缘以降低延迟并改善用户体验，相信这第三类用例的普及范围也将迎来持续扩张。

我们仍在路上

希望这篇文章能让大家体会到我们在零信任领域的发展愿景，并表达出Amazon云立足自身基础设施帮助客户构建顶尖安全保护模型、积极引入基础安全原则及先进功能的决心与能力。

在Amazon，我们永远关注客户的声音与需求，我们前进的脚步将永不停歇。着眼于未来，我们期待着更多反馈，也将把这一切视为对Amazon自身的鞭策与驱动力。正如Amazon创始人Jeff Bezos所言，“It’s still Day 1。”

如果您对这篇文章还有其他建议或意见，请在下方评论区中与我们交流。

关于Amazon安全运营方法的更多内容、新闻与公告，请在Twitter上关注我们。

本篇作者：Mark Ryland

身为亚马逊云科技 CISO办公室主管，Mark在技术行业拥有超过29年的从业经验，先后在网络安全、软件工程、分布式系统、技术标准化以及公共政策等多个领域提醒过领导职务。

此前，他曾担任Amazon Web Services全球公共部门解决方案架构与专业服务团队负责人。

原文链接：

https://aws.amazon.com/cn/blogs/security/zero-trust-architectures-an-aws-perspective/

听说，点完下面4个按钮

就不会碰到bug了！