亚马逊AWS官方博客
AWS Verified Access 预览版 — 对企业应用程序的无 VPN 安全网络访问
今天，我们发布了 AWS Verified Access 预览版，这是一种新的安全连接服务，允许企业在不需要 VPN 的情况下为企业应用程序启用本地或远程安全访问。
传统上，在路上或在家工作时远程访问应用程序是由 VPN 授权的。一旦远程工作人员在 VPN 上通过身份验证，他们就可以访问各种应用程序，具体取决于孤立系统中定义的多个策略，例如 VPN 网关、防火墙、身份提供程序、企业设备管理解决方案等。这些策略通常由不同的团队管理，可能会造成重叠，从而难以诊断应用程序访问问题。内部应用程序通常依赖于较早的身份验证协议，如 Kerberos，这些协议是在考虑局域网的情况下构建的，而不是更适合现代企业模式的现代协议，如 OIDC。客户告诉我们，政策更新可能需要几个月的时间才能推出。
Verified Access 是使用 AWS 零信任安全原则构建的。零信任（Zero Trust）是一种概念模型和一组相关的机制，侧重于为数字资产提供安全控制，而这些数字资产不完全或不主要依赖于传统的网络控制或网络边界。
Verified Access 利用多个安全输入来授予对应用程序的访问权限，从而改善组织的安全态势。只有用户及其设备满足指定的安全要求时，它才授予对应用程序的访问权限。输入的示例包括用户身份和角色或设备安全态势等。Verified Access 在授予访问权限之前会验证每个应用程序请求，无论用户或网络如何。评估每个应用程序访问请求后，Verified Access 可以根据不断变化的条件调整安全态势。例如，如果设备安全信号表明您的设备状态不合规，则 Verified Access 将不再允许您访问该应用程序。
我认为，采用 Verified Access 有三个主要好处：
它便于 IT 管理员使用。作为 IT 管理员，您现在可以轻松设置应用程序以实现安全的远程访问。它提供单一配置点来管理和实施多系统安全策略，以允许或拒绝对企业应用程序的访问。
它提供了一个开放的生态系统，允许您保留现有的身份提供程序和设备管理系统。我在这篇文章的末尾列出了我们所有的合作伙伴。
它便于最终用户使用。这是我的首选。您的员工不再需要使用 VPN 客户端。在识别和验证用户和设备时，一个简单的浏览器插件足以安全地授予访问权限。截至目前，我们支持 Chrome 和 Firefox Web 浏览器。我可以就此分享我的个人经历。几年前，亚马逊采用了无 VPN 策略。能够访问我们的大部分内部 Web 应用程序，而无需启动 VPN 客户端并整天保持连接，这让我和同事们如释重负。
我们来看看实际操作
我在私有 VPC 中部署了一个 Web 服务器，并通过私有应用程序负载均衡器将其公开给我的最终用户 （https://demo.seb.go-aws.com）。我为应用程序外部端点创建了一个 TLS 证书（secured.seb.go-aws.com）。我还建立了 AWS Identity Center（以前称为 AWS SSO）。在这个演示中，我将使用它作为用户身份的来源。现在我已经准备好向我的远程工作人员公开这个应用程序了。
创建 Verified Access 端点的过程分为四个步骤。首先，我导航到 AWS 管理控制台的 VPC 页面。我先创建信任提供程序。信任提供程序用于维护和管理用户和设备的身份信息。接到一个应用程序请求后，在允许或拒绝该应用程序请求之前，Verified Access 会对信任提供程序发送的身份信息进行评估。我在左侧导航窗格中选择 Verified Access trust provider（Verified Access 信任提供程序）。
在 Create Verified Access trust provider（创建 Verified Access 信任提供程序）页面上，我输入 Name（名称）和可选的 Description（描述）。我输入 Policy reference name（策略参考名称），这是一个在使用策略规则时使用的标识符。我选择信任来源：User trust provider（用户信任提供程序）。在这个演示中，我选择 IAM Identity Center 作为用户身份的信任来源。Verified Access 还可与其他符合 OpenID Connect 标准的提供程序协同工作。最后，我选择 Create Verified Access trust provider（创建 Verified Access 信任提供程序）。
当我有多个信任提供程序时，我可能会重复此操作。例如，我可能有一个基于身份的信任提供程序来验证最终用户的身份，还有一个基于设备的信任提供程序来验证其设备的安全态势。
然后，我创建 Verified Identity 实例。Verified Access 实例是一个区域性 AWS 实体，用于评估应用程序请求，并且仅在满足您的安全要求时才授予访问权限。
在 Create Verified Access instance（创建 Verified Access 实例）页面上，我输入 Name（名称）和可选的 Description（描述）。我选择刚刚创建的信任提供程序。在创建 Verified Access 实例后，我可以添加其他信任提供程序类型。
第三步，我创建 Verified Access 组。
Verified Access 组是具有类似安全要求的应用程序的集合。Verified Access 组中的每个应用程序共享一个组级别策略。例如，您可以将面向“财务”用户的所有应用程序分到一组中，并使用一个通用策略。这将简化您的策略管理。您可以对一组具有类似访问需求的应用程序使用单个策略。
在 Create Verified Access group（创建 Verified Access 组）页面上，我仅输入 Name（名称）。我将在后续步骤输入策略。
在测试我的设置之前，第四步（也是最后一步）是创建端点。
Verified Access 端点是一种区域资源，用于指定要提供 Verified Access 访问的应用程序。这是您的最终用户连接到的位置。每个端点都有自己的 DNS 名称和 TLS 证书。评估传入请求后，端点会将授权请求转发到您的内部应用程序，即内部负载均衡器或网络接口。Verified Access 支持网络级别和应用程序级别的负载均衡器。
在 Create Verified Access endpoint（创建 Verified Access 端点）页面上，我输入 Name（名称）和 Description（描述）。我参考刚刚创建的 Verified Access group（Verified Access 组）。
在 Application details（应用程序详细信息）部分中的 Application domain（应用程序域）下，我输入最终用户将用于访问应用程序的 DNS 名称。在此演示中，我使用 secured.seb.go-aws.com。在 Domain certificate ARN（域证书 ARN）下，我选择与 DNS 名称匹配的 TLS 证书。我使用 AWS Certificate Manager 创建了证书。
在 Endpoint details（端点详细信息）部分，我选择 VPC 作为 Attachment type（附件类型）。我选择要附加到此端点的一个或多个 Security groups（安全组）。我输入 awsnewsblog 作为 Endpoint domain prefix（端点域前缀）。我选择负载均衡器作为 Endpoint type（端点类型）。我选择 Protocol（协议）（HTTP），然后输入 Port（端口）（80）。我选择 Load balancer ARN（负载均衡器 ARN）和部署负载均衡器的私有 Subnets（子网）。
我再次将 Policy details（策略详细信息）部分留空。转而在组中定义策略。完成后，我选择 Create Verified Access endpoint（创建 Verified Access 端点）。创建可能需要几分钟。
现在是时候喝杯咖啡和伸伸双腿了。当我返回时，我看到 Verified Access 端点处于 ✅ Active（活动）状态。我复制 Endpoint domain（端点域）并将其作为 CNAME 记录添加到我的应用程序 DNS 名称（secured.seb.go-aws.com）中。我为此使用 Amazon Route 53，但您也可以使用现有的 DNS 服务器。
然后，我将最喜欢的浏览器指向 https://secured.seb.go-aws.com。浏览器被重定向到 IAM Identity Center（以前称为 AWS SSO）。我输入测试用户的用户名和密码。我没有为此添加屏幕截图。重定向后，我收到错误消息：Unauthorized（未授权）。这在意料之中，因为 Verified Access 端点上没有定义任何策略。默认情况下，它会拒绝所有请求。
在 Verified Access groups（Verified Access 组）页面上，我选择 Policy（策略）选项卡。然后，我选择 Modify Verified Access endpoint policy（修改 Verified Access 端点策略）按钮创建访问策略。
我输入的政策允许任何人通过身份验证并具有以 @amazon.com 结尾的电子邮件地址。这是我为 AWS Identity Center 中定义的用户使用的电子邮件地址。请注意，context（上下文）后的名称是我在创建 Verified Access trust provider（Verified Access 信任提供程序）时作为 Policy reference name（策略参考名称）输入的名称。文档页面详细介绍了我可以使用的策略语法、属性和运算符。
permit(principal, action, resource)
when {
context.awsnewsblog.user.email.address like "*@amazon.com"
};
几分钟后，Verified Access 会更新策略，再次变为 Active（活动）状态。我强制刷新浏览器，看到内部应用程序现在可供通过身份验证的用户使用。
定价和可用性
AWS Verified Access 现已在 10 个 AWS 区域提供预览版：美国东部（俄亥俄州、弗吉尼亚州北部）、美国西部（北加利福尼亚、俄勒冈州）、亚太地区（悉尼）、加拿大（中部）、欧洲（爱尔兰、伦敦、巴黎）和南美洲（圣保罗）。
通常，定价基于您的使用情况。没有预付或固定价格。我们按照每小时每个应用程序（Verified Access 端点）收费，提供基于应用程序数量的套餐。美国东部（弗吉尼亚州北部）区域的起步价为每小时每个 Verified Access 端点 0.27 美元。当您的应用程序数量超过 200 个时，此价格将降至每小时每个端点 0.20 美元。
除此之外，由 Verified Access 处理的数据每 GB 收取 0.02 美元的费用。对于使用 Verified Access 传输的所有数据，您还需要支付标准 AWS 数据传输费用。
此计费模式便于从小规模开始，然后按需扩展。