开启云端零信任架构之旅之无 VPN 安全连接部署实践

AWS Verified Access 是亚马逊云科技原生的零信任安全服务，提供了无需 VPN 的互联网安全访问能力，支持为企业应用系统提供精细访问权限的配置能力，确保只有在满足安全的情况下才授予应用程序访问权。本文将详细介绍在零信任架构下，构建基于 AWS Verified Access 服务的端到端无 VPN 安全通讯的步骤过程。帮助企业用户理解云端零信任架构的具体技术实现。

背景介绍

在开启云端零信任架构之旅的概述一文中，我们介绍了零信任架构的基础概念，技术特征和关键能力，以及围绕云端零信念架构的构建，亚马逊云科技所能够提供的一系列云服务。但如何开启企业云端零信任安全框架的改造与适用，是一个颇有挑战的问题，企业需要从更高的层面上启动架构适用的决策，组织研发、安全、合规、运维等力量，协同规划、合作推进。

单从技术手段上看，在现有的边界安全网络架构中，VPN 技术是基于互联网安全通讯的首选方式，但 VPN 技术提供的是相对静态的安全通道，通道线程数量也受限于安全设备的物理性能，对于大用户量的移动接入需求，所带来的用户体验和性价比不是很好。利用亚马逊云科技的原生 Verified Access 服务和 Cedar 策略描述语言，建立 VPN-less 的端到端远程安全连接，是符合零信任架构中网络安全接入的重要实现，可以很好地改善 VPN 技术的不足，也是对企业应用负载影响最小，技术挑战难度最小的架构改造。接下来将详细介绍在亚马逊云科技 us-east-1 区域的跨账号环境下，如何在互联网环境内，基于 AWS Verified Access 服务，构建无 VPN 的端到端安全接入通道，实现从客户端浏览器到云端应用系统的安全访问与控制。

AWS Verified Access 服务

通过 AWS Verified Access 服务，我们可以无需使用虚拟专用网络（VPN）技术或安全设备，即可安全地访问企业部署在云端的应用系统。Verified Access 能够评估每个应用程序的访问请求，帮助确保用户只有在满足指定的安全要求时，才能访问这个应用程序。作为原生的零信任安全服务，AWS Verified Access 服务给企业客户带来的受益包括：

改善安全态势

传统的安全模型对访问权限提供的是相对静态的评估，即一次评估后，授予用户对所有应用程序的访问权限。Verified Access 提供的是实时评估每个应用程序的访问请求。这可以有效防御不良用户从一个应用程序跳转入侵其他的应用程序。

安全服务集成

AWS Verified Access 服务支持与多种身份和设备管理服务（包括 AWS 和第三方服务）集成。使用来自这些可信服务的数据，并根据用户定义的安全要求，验证用户和设备的可信度，实时判断用户是否应该有权访问服务端的应用程序。

改善用户体验

具备“已验证访问权限” 的用户，可以无需使用 VPN 安全通道，即可访问企业的应用程序。这有助于减少因与 VPN 相关的问题而产生的用户体验和性价比问题。提供更好的用户体验和办公效率。

简化故障排除和审计

AWS Verified Access 能够记录所有访问尝试，与更多的亚马逊云科技的运维和安全服务相集成，提供访问日志的集中可见，帮助用户快速响应安全事件和满足审计合规需求。

部署架构

本文设计的演示环境是设计运行在亚马逊云科技的 us-east-1（美东）区域，用户部署了一套 B/S 的 Web 应用（在线书店），并基于 AWS Verified Access 服务，构建一套完整的 VPN-less 安全访问连接。远端用户能够采用 HTTPS 协议，远程访问处于云端内网环境的 Web 应用。

部署架构设计采用 2 个独立的账号来实现零信任架构的控制平面与数据平面隔离。其中，account # 1 账号承担控制平面的能力，启用 AMS Verified Access 服务，部署 Verified Access Instance、Verified Access Trust provider、Verified Access Group、Cdear 控制策略等，支持构建无 VPN 的安全连接，并提供安全监控与访问权限控制。

account # 2 账号承担数据平面的能力，部署 VPC 及相关网络服务，并在内网子网部署 ALB 负载均衡器、B/S Web 应用（在线书店前端）、RDS 数据库服务等。提供 Web 应用请求的处理和结果返回。account # 1 和 account # 2 通过 AWS Resource Access Manager 服务实现跨账号的资源共享和权限控制。

其他的关联服务还包括采用 AWS Identify Center 提供可信的用户认证，Amazon Certificate manager 提供域名公有证书的签发和托管，Route 53 提供公有域名解析，S3 对象服务提供日志存储等。

环境准备

本文设计构建的基于 AWS Verified Access 服务的用户端（浏览器）到服务端（Web 应用）的无 VPN 安全通信实验环境。所需要的关联资源包括：

资源名称	数量	用途说明
AWS 账号	2	一个账号充当控制平面，启动 Verified Access 服务。一个账号充当数据平面，部署 Web 应用及相关的配置。
公有域名	1	通过 Route 53 提供访问端点的域名解析，CNAME 到用户的 Verified Access Endpoint DNS 域名记录。
域名证书	1	提供用户到内网 ALB 负载均衡 DNS 记录的公网 HTTPS 通信加解密。
B/S Web 应用	1	一套典型 B/S 架构的 3 层架构应用，包括内网 ALB 负载均衡器，应用服务器和 RDS 数据库。以及安全组，监控等。

AWS Identity Center 服务激活

用户需要在AWS Identity Center 控制台，激活这个服务。具备步骤请参考这里。

公有证书申请

建议用户通过 AWS Certificate Manager 服务，为公网域名请求公有证书，用于后续 HTTPS 通讯的加解密支持。

B/S 应用部署

其中 Web 应用的资源准备，可以参考亚马逊云科技的入门教程《基于 EC2 部署动态网站》完成在 VPC 内网子网的应用部署。其中 ALB 部署类型选项，选择内网。

部署步骤

实验环境部署按照资源准备，应用部署，AWS Verified Access 配置等过程，依次开展部署。步骤过程中，可分阶段开展 Web 应用的服务和网络可达性测试。确保应用运行正常的情况下，开展 AWS Verified Access 的服务配置。

1.创建验证访问实例

在控制平面的账号内，即 account #1 （尾号 4872，简称：4872 账号）启动 Verified Access 实例。AWS Verified Access 服务的配置界面在 VPC 服务的控制台，我们通过 VPC 控制台的导航栏，选择 AWS Verified Access 下面的 Verified Access instances。选择创建实例，输入 name 标签（取值：verified-access-instance-01）和描述（取值：For workshop），完成实例创建。

2.配置 Verified Access 信任提供商

通过 VPC 控制台的导航栏，选择 AWS Verified Access 下面的 Verified Access trust providers ，创建 Verified Access 信任提供商。AWS Verified Access 服务目前支持用户信任提供商和设备信任提供商 2 种类型，本实验创建基于 IAM Identity Center 的用户信任提供商，实现客户端访问请求的身份管理功能。用户也可以添加设备信任提供商，带来更高的客户端安全评估能力。

在创建界面输入命名标签（取值：verified-access-trust-provider-01），描述（取值：For workshop），策略引用名称（取值：idc），选择信任提供商类型，创建用户信任提供商。

3.将信任提供商附加到实例

通过 VPC 控制台的导航栏，选择 AWS Verified Access 服务，点击已经完成创建的 Verified Access 实例，选择操作，附加已验证访问信任提供商。选择步骤 2 中创建的信任提供商，完成附加关联。

4.创建验证访问组

通过 VPC 控制台的导航栏，选择 AWS Verified Access 服务内的已验证访问组，点击创建已验证访问组。输入命名标签（取值：verified-access-group-01），描述（取值：For workshop），选择步骤 1 创建的验证实例，策略（默认，空值），完成验证访问组的创建。

5.跨账号共享验证访问组

通过 AWS Resource Access Manager 服务，在控制平面 4872 账号与数据平面账号（尾号 1334 账号，简称 1334 账号）之间，实现验证访问组的资源共享。服务默认支持 AWS Organizations 启用共享和通过 Resource Access Manager 邀请分享。本实验过程采用第 2 种方式。按照 AWS RAM 创建资源共享的步骤操作。创建资源共享，选中验证访问组，输入 1334 账号的 12 位账号，继续资源共享创建。

配置 AWS 托管权限 arn:aws:ram::aws:permission/AWSRAMPermissionVerifiedAccessGroup，授权 1334 数据平面账号内的用户，可以执行已信任访问端点创建，读取访问组描述和访问组策略的权限。并确保其他的权限仍然控制在 4872 账户内。

登陆被分享账号，即 1334 数据平面账号，通过 AWS Resource Access Manager 服务的与我分享目录，选择邀请，接受来自于 4872 账号的资源共享邀请。实现跨账号的访问请求控制与通讯。

6.创建 Verified Access 端点

登陆 1334 数据平面账号，通过 VPC 控制台的导航栏，选择 AWS Verified Access 服务内的 Verified Access 端点，点击创建 Verified Access 端点，并添加应用程序的自定义域名，ALB 的 DNS 域名。建立客户端到应用端的无 VPN 访问路由。填写的信息项包括如下：

命名标签：Verified-access-endpoint-01
描述：For workshop
应用域名：www.sample.com
域名证书 ARN：8d392bec-abcd-1234-5678-852abce12345
附加类型：VPC
安全组：ELB-SG
端点域名前缀：my-ava-app
端点类型：Load balancer
协议：HTTPS
端口：443

7.Route53 域名解析配置

登陆 AWS Route 53 服务或第 3 方的域名服务提供商，配置 Web 应用的公网域名，添加 Verified access 端点的 CName 记录。建立域名到 Verified access 端点的解析路径。

8.创建访问用户

登陆 1334 账户的 IAM Identity Center 服务，创建一个应用登陆的用户身份。

9.验证域名访问

实验到此，我们已经完成了除策略配置外的所有步骤。现在用户可以通过应用程序的公网域名，验证应用的可访问情况。在浏览器打开 HTTPS URL 之后，应用自动跳转到 IAM Identity Center 界面，执行用户身份认证，完成验证后，跳转到 Web 应用。

由于我们在前面的验证访问组和验证访问端点的配置中，都采用了默认空值策略，AWS Verified Access 自动阻断了所有的请求访问。反馈“403 Unauthorized”错误。需要配置允许策略，才可以提供应用访问。

10 配置应用的访问权限

登陆 4872 账号的 Verified Access 服务，在验证访问组，选择策略，编辑策略，按照 Cedar 语言规范，配置完成了邮箱验证的用户，可以访问应用。Verified Access 服务的样例规范请参考访问政策。本实验配置为完成邮件身份验证的用户才可以访问。

permit(principal,action,resource)
when {
context.idc.user.email.verified == true
};

补充说明：

在零信任安全架构中，为确保控制平面对权限的控制能力，部署中没有给数据平面的用户提供 Verified Access 访问组的策略修改权限。所以即便在 1334 账号内，可以管理上述资源，但并不能配置权限策略。

至此，我们已经完成了本实践的所有部署步骤，用户应该可在互联网环境下，通过 Https://域名的方式，正常地实现对云端 Web 应用的安全访问。

附加：安全增强

AWS Verified Access 服务具备丰富的安全服务集成能力。包括用户端设备可信提供商和亚马逊云科技的安全服务集成。比较简单实用的一种安全实践就是为 Verified Access 端点关联 WAF 服务，增加 7 层的端点安全防护能力。用户可以在 WAF 服务控制台关联 Verified Access 端点资源即可。

同时，还可以将 WAF 日志写入 S3 对象存储桶，通过 Athena 服务执行日志查询与分析，帮助企业建立安全日志事件管理应用，提供更完备的安全管理与控制能力。

结论

企业信息安全与企业的发展战略和业务运营紧密相连，安全也将逐步演变成企业的核心价值。零信任架构的适用无疑将成为越来越多企业的重要选项，但零信任架构的改造适用并不是一蹴而就的事情，企业需要结合自己的发展规划，逐步推进和演化实践。本文从一个具体的应用场景出发，介绍了基于云服务快速构建无 VPN 安全通信的实现过程，这也从另外一个角度展现了在云端实现零信任架构的便捷性和扩展性，帮助用户在无需大量投入和长期技术准备的情况下，达到用户所期望的安全能力。亚马逊云科技也将一如既往地与客户站在一起，持续支持用户构建属于自己的安全防护。敬请期待后续云端零信任架构的其他实践介绍。

参考资料

https://docs.thinkwithwp.com/zh_cn/verified-access/latest/ug/getting-started.html

https://docs.thinkwithwp.com/verified-access/latest/ug/access-logs-enable.html

https://docs.thinkwithwp.com/verified-access/latest/ug/trust-data-iam.html

https://thinkwithwp.com/cn/blogs/china/aws-waf-deployment-guide-1-waf-principle-default-deployment-and-log-storage/

https://thinkwithwp.com/cn/getting-started/hands-on/how-to-deploy-dynamic-website-on-cloud/?TRK=gs_card

亚马逊AWS官方博客