零信任架构：AWS的角度

我们在Amazon Web Services（AWS）的使命是代表客户进行创新，以使他们在安全系统上构建，部署和快速迭代时要做的工作越来越少。从安全角度来看，我们的客户寻求解决这个持续不断的问题的最佳方式是什么，以确保我的系统和数据的机密性，完整性和可用性达到正确的水平，同时提高速度和敏捷性？越来越多的客户开始特别询问零信任架构或零信任网络的安全架构模式如何帮助回答这个问题。

鉴于对使用“零信任”标签的技术的兴趣激增，以及在“零信任”框架下的各种概念和模型，我们谨提供我们的观点。我们将分享零信任的定义和指导原则，然后探讨在该旗帜下出现的更大的子域。我们还将讨论自最早以来，AWS如何将这些原理整合到AWS云的架构中，以及如何融入到许多最新开发中。最后，我们将回顾AWS如何在您自己的零信任旅程中为您提供帮助，重点关注对客户最重要的基础安全目标。技术方法兴衰，但随着时间的推移，基本的安全目标往往相对稳定。（其中的一些摘要可以在设计原则中的AWS良好架构的框架。）

零信任的定义和指导原则

让我们从一个通用定义开始。零信任是一个概念模型和一组相关的机制，着重于围绕数字资产提供安全控制，而数字资产并不完全或根本上不依赖于传统的网络控制或网络边界。在零的零信任从根本上是指减少，可能到零！历史上由一个演员的位置，传统的网络中创建的，我们是否想到的-the信任的演员作为一个人或一个软件组件。在零信任的世界中，以网络为中心的信任模型被其他技术（我们通常可以将其描述为以身份为中心的控件）增强或替代，以提供与以前相同或更好的安全机制。更好的安全机制应该被广泛地理解为包括诸如更高的可用性和灵活性之类的属性，即使总体安全状况保持不变。让我们考虑这两个维度的更多细节和可能的方法。

一维是网络。我们是否通过允许所有网络数据包在所有主机或端点之间流动但实现网络层之上的所有安全控制来实现零信任？还是我们将系统分解为较小的逻辑组件，并实施更紧密的网络段或数据包级别的控制（所谓的微段或微边界）？我们是否添加了某种网关或代理技术来实施一种新型的信任边界？我们是否仍将VPN技术用于网络隔离，但使其更具动态性并在用户体验中隐藏起来，使用户甚至不会注意到网络边界正在根据需要创建和拆除？还是这些技术的某种组合？

另一个方面是身份和访问管理。我们是否在谈论人类演员通过其PC，平板电脑和电话尝试访问Web应用程序？还是我们在谈论机器对机器，软件对软件的通信，其中所有请求都使用其他类型的技术进行身份验证和授权？也许我们正在考虑两者的某种组合。例如，用户情况的某些与安全性相关的属性或属性（身份验证强度，设备类型，所有权，状态评估，健康状况，网络位置等）会传播到与用户交互的软件系统中，并通过它们进行传播，并动态更改其访问权限。

因此，当我们开始更仔细地研究“零信任”时，由于涉及许多不同的主题和概念，我们可以立即看到混乱的可能性，同时也清楚地表明了构建更好，更灵活，更安全的软件系统的机会。 。有哪些原则可以帮助我们度过困惑和机遇？

零信任的第一个指导原则是，虽然概念模型减少了对网络位置的依赖，但网络控件和外围设备的作用对于整个安全体系结构仍然很重要。换句话说，最好的安全性不是来自以身份为中心的工具和以网络为中心的工具之间的二元选择，而是有效地将两者结合使用。以身份为中心的控件（例如AWS SigV4请求签名过程），用于与AWS API端点进行交互，对每个签名的API请求进行唯一身份验证和授权，并提供非常细粒度的访问控制。但是，以网络为中心的工具，例如Amazon Virtual Private Cloud（Amazon VPC），安全组，AWS PrivateLink和VPC终端节点易于理解和使用，可以过滤掉系统中不必要的噪音，并提供出色的防护栏，以身份为中心的控件可以在其中运行。理想情况下，这两种控件不仅应共存，而且应彼此了解并相互补充。例如，VPC终结点提供了附加策略的能力，该策略允许您在逻辑网络边界处编写和实施以身份为中心的规则，在这种情况下，私有网络从您的Amazon VPC退出，并通往附近的AWS服务终结点。

零信任的第二个指导原则是，它可以在不同的上下文中表示不同的含义。可以说，围绕零信任的模棱两可的主要原因之一是，该术语包含许多不同的用例，这些用例仅共享减少网络位置或边界的安全相关性的基本技术概念。但是，这些用例在为组织所要实现的目标上有很大的不同。如上文所述，零信任目标的常见示例包括确保员工敏捷性和移动性（使用浏览器和移动应用程序以及互联网访问业务系统和应用程序）到在基于云的新云中创建经过仔细细分的微服务架构应用程序。通过专注于我们要解决的特定问题，

我们的第三个指导原则是，必须根据系统和受保护数据的组织价值来应用零信任概念。随着时间的流逝，零信任概念模型和相关机制的应用将继续改善深度防御，并通过提高云的可见性和软件定义的性质，继续使我们已经能够更好地进行安全控制。如果应用得当，零信任的原则可以大大提高安全性标准，尤其是对于关键工作负载。但是，如果在严格的正统观念中应用零信任方法，则可能会限制将更多传统技术纳入升级或新系统中，并通过对收益与工作量不相称的组织过度征税来扼杀创新。对于许多业务系统，网络控制和网络边界将继续很重要，并且通常在很长一段时间内（也许永远）都是足够的控制。我们认为，最好将零信任概念视为现有安全控制和概念的补充，而不是替代。

如今，AWS云中的零信任原则和功能示例

AWS零信任最突出的例子是，数百万的客户通常每天如何使用AWS管理控制台或通过各种公共和私有网络安全地调用AWS API来与AWS进行交互。无论是通过控制台，AWS命令行界面（AWS CLI）还是编写到AWS API的软件调用，最终所有这些交互方法都可以到达一组Web服务，这些Web服务的端点可以从Internet访问。取决于网络可访问性的AWS API基础设施的安全性绝对没有。这些签名的API请求中的每一个每次都经过认证和授权全球每秒有数百万个请求。我们的客户对此充满信心；知道基础传输层安全性（TLS）协议的加密强度（由AWS Signature v4签名过程增强）可以适当地保护这些请求，而无需考虑基础网络的可信赖性。有趣的是，在零信任讨论中很少提到基于云的API的使用。也许是因为AWS从一开始就采用这种方法来保护API，因此现在假定它已成为每个云安全故事的基本组成部分。

同样，但可能不是很了解，当单个AWS服务需要彼此调用以运行和交付其服务功能时，它们依赖于您作为客户使用的相同机制。您可以通过与服务相关联的角色的形式来实际操作。例如，当AWS Auto Scaling确定需要调用Amazon Elastic Compute Cloud（Amazon EC2） API来创建或终止您帐户中的EC2实例时，AWS Auto Scaling服务将承担您在其中提供的服务链接角色。您的帐户，接收生成的AWS短期凭证，并使用这些凭证通过SigV4流程签署对相应EC2 API的请求。在接收端，AWS身份和访问管理（IAM）对EC2的传入呼叫进行身份验证和授权。换句话说，即使它们都是AWS服务，AWS Auto Scaling和EC2也彼此之间没有固有的信任关系（网络或其他），并且使用强大的以身份为中心的控件作为这两个服务之间安全模型的基础代表您进行操作。您（客户）可以完全了解您授予一项服务的特权以及这些特权的使用情况的AWS CloudTrail记录。

IoT服务中提供了AWS产品组合中零信任功能的其他出色示例。当我们启动AWS IoT Core时，我们做出了一项战略决策-当时违反了当时的行业规范-在将IoT设备连接到服务终端时始终要求TLS网络加密和现代客户端身份验证，包括基于证书的双向TLS。随后，我们在FreeRTOS中添加了TLS支持，从而实现了与以前假设无法实现的整个小型CPU和小型存储设备的现代化安全通信。借助AWS IoT Greengrass，我们开创了一种方法，该方法使用依赖于本地网络存在但也能够运行的远程网关来使用现有的无安全性设备AWS Lambda用于验证安全性并提供到云的安全代理。这些示例突出说明了对AWS安全标准的遵守将零信任的关键基础组件带入了一个技术领域，以前在开放互联网上，大量未经身份验证，未加密的网络消息传递是以前的规范。

AWS如何为您的零信任之旅提供帮助

为了帮助您完成自己的零信任旅程，有许多AWS特定于云的身份和网络功能提供了核心的零信任构件作为标准功能。AWS服务通过简单的API调用提供了此功能，而您无需构建，维护或操作任何基础架构或其他软件组件。为了帮助更好地构建对话，我们将在三个不同的用例的背景下考虑这些功能：

1. 授权组件之间的特定流以消除不必要的横向网络移动性。

2. 使您的员工能够无摩擦地访问内部应用程序。

3. 保护物联网等数字化转型项目。

我们的第一个用例主要关注机器对机器的通信-授权组件之间的特定流以帮助消除横向网络移动性风险。否则，如果两个组件不需要通过网络相互通信，那么即使这些系统恰好存在于同一网络或网段中，它们也不应该能够通信。这大大减少了连接系统的总表面积，并消除了不必要的路径，特别是那些导致敏感数据的路径。在此用例中，我们的讨论应从安全组开始，安全组自Amazon EC2成立以来就已成为其组成部分。安全组为南北和东西向流量提供高度动态的，软件定义的网络微边界。安全组分配随资源的使用而自动发生，并且一个安全组中的规则可以通过ID在同一Amazon VPC中或在相同或不同区域中的较大对等网络中相互引用。这些属性允许安全组充当一种身份系统，在该系统中，组成员身份成为确定是否允许特定网络流的相关属性。这有助于使您编写极其精细的规则，而不会产生使它们随着组成员潮起潮落而保持最新状态的相关操作负担。同样，PrivateLink在微边界和微分段的一般空间中提供了极其有用的构造块。使用PrivateLink，可以将负载平衡的端点公开为两个VPC之间狭窄的单向网关，通过基于身份的严格控制，确定谁可以访问网关以及传入数据包可以到达的位置。根本不允许在另一个方向上启动网络连接，并且VPC甚至不需要相互之间的路由。今天，成千上万的客户将PrivateLink用作安全微服务架构的基本构建块，以及供应商对PaaS和SaaS服务的安全和私有访问。

回到我们关于AWS API的讨论，用于身份验证和授权API请求的AWS SigV4签名过程不再仅仅适用于AWS服务。您可以使用Amazon API Gateway实现相同类型的强化接口方法服务，可以在开放的Internet上安全地使用软件接口。API Gateway提供了分布式拒绝服务（DDoS）保护，速率限制和AWS IAM支持，作为几种授权选项之一。当您选择AWS IAM授权时，您将编写标准IAM策略，这些策略使用IAM策略语言的完整表达方式定义谁可以调用您的API以及他们可以从何处调用它。调用方使用其AWS凭证对请求进行签名，该凭证通常以附加到计算资源的IAM角色的形式提供，并且IAM根据这些策略唯一身份验证和授权对API的每次调用。只需一步，即可在大规模，超高性能，全球可用的IAM服务后面保护您的API，该服务可保护AWS API，无需您管理或维护。从API Gateway前端到后端实现的调用通过相互TLS进行保护，因此可以确保只有API Gateway能够调用后端实现。通过这种强大的以身份为中心的控制，您有两种选择。您可以将后端实现安全地放置在公共网络上，也可以添加VPC集成模型，以便对以VPC内部运行的后端实现的API网关调用受到以身份为中心的控件（相互TLS）的保护和以网络为中心的控件（从API网关到您的代码的专用连接）。这些功能组合所实现的安全性（可能只有在云中才有可能实现）使得对东西方问题的讨论似乎不那么激烈，并且植根于过去的局限性。

我们的第二个用例是为您的工作人员提供对内部应用程序的无障碍访问，其目的是在不损害安全性的前提下提高工作人员的流动性。传统上，这些应用程序存在于强大的VPN前门后面。但是，VPN的扩展成本可能很高，并且不一定与现代员工所需的全部移动设备兼容。在这种情况下，目标是使各个应用程序锁定得很好，以便您可以消除基于VPN的前门。为了实现这一目标，我们的客户告诉我们，他们希望根据自己的行业，风险承受能力，开发人员成熟度和其他因素来选择一系列技术解决方案。一方面，我们有许多客户希望使用桌面即服务-亚马逊工作区-或作为服务应用-亚马逊AppStream 2.0 -models提供强大和灵活的像素代理零信任的方法。将传统的安全控件应用于这些中间虚拟设备，然后，具有PC，平板电脑或HTML5客户端的任何用户都可以通过Internet（如果需要，可以在其他网络控件和外围设备之后）访问这些虚拟桌面或应用程序，以提供丰富的类似于桌面的体验，而不必担心最终设备在用户手中的安全性。同样，客户要求一种更好的方法来从移动电话安全地访问其企业应用程序，而无需部署移动设备管理或其他此类通常繁琐且昂贵的技术。为了满足该要求，我们启动了Amazon WorkLink，提供可在AWS云中呈现复杂Web应用程序的安全代理服务。Amazon WorkLink仅将像素（以及非常少量的JavaScript用于交互）流式传输到手机。绝不会在移动设备上存储或缓存任何敏感的企业数据。

另一方面，我们的客户希望将其内部Web应用程序直接连接到Internet。对于这些客户，AWS Shield，AWS WAF和Application Load Balancer与OpenID Connect（OIDC）身份验证的结合提供了完全托管的身份识别网络保护堆栈。Shield提供可管理的DDoS保护服务，该服务提供始终在线的检测功能和自动内联缓解功能，以最大限度地减少应用程序停机时间和延迟。AWS WAF是一种Web应用程序防火墙，通过它您可以使用由AWS Marketplace提供的AWS所需的规则组组合，在Web请求到达基础架构之前对其进行监视和保护，或您自己的自定义标签。通过在Application Load Balancer中启用身份验证（除了常规的负载平衡功能之外），您可以直接与现有的身份提供商（IdP）集成，以减轻身份验证用户的工作负担，并利用IdP中的现有功能（例如强身份验证），设备状态评估，条件访问和策略实施。使用这种组合，您的内部自定义应用程序将很快变得与SaaS应用程序一样灵活，从而使您的工作人员可以在任何位置享受与SaaS相同的灵活性，同时在由现代身份标准支持的通用安全模型下统一您的应用程序组合。

我们的第三个用例（确保物联网等数字化转型项目的安全性）与前两个用例明显不同。考虑连接的车辆，将通过移动网络和互联网的关键仪器流中继到基于云的分析环境中以进行处理和洞察。这些工作负载始终完全存在于传统企业网络之外，并且需要一种能够说明这种情况的安全模型。AWS IoT服务家族提供可扩展的解决方案，用于向您的机队中的每个设备发布唯一的设备身份，然后使用这些身份及其关联的访问控制策略来安全地控制它们与云的通信和交互方式。这些设备的安全性可以通过以下方式轻松监控和维护AWS IoT Device Defender，空中软件更新，甚至是整个操作系统升级（现已内置到FreeRTOS中），可确保设备随着时间的推移变得安全可靠。展望未来，随着越来越多的IT工作负载移向边缘以最小化延迟并改善用户体验，即使当前不适用于您的业务，此用例的普及率也将继续扩大。

仍然是第一天

我们希望这篇文章有助于传达我们对零信任的愿景，并强调我们如何相信我们的基本安全原则和先进的功能代表着AWS云以及客户在我们的基础上构建的环境的提高安全性模型服务。

在亚马逊，我们着迷于客户及其需求，因此我们的工作从未完成。我们还有很多我们想构建的功能，还有更多的指导要提供。我们期待您的反馈，并一起继续旅程-反映我们创始人Jeff Bezos的话和核心愿景：“今天仍然是第一天。”

如果您对此信息有任何反馈，请在下面的“评论”部分中提交评论。

是否需要更多的AWS Security操作方法内容，新闻和功能公告？在Twitter上关注我们。