基于 AWS Verified Access 构建零信任访问：安全访问私网 Web 与 TCP 应用

摘要：企业常常需要让员工、外包或外部合作伙伴访问部署在 VPC 私网中的系统。传统基于网络边界的访问控制一旦放行，就给出了整段网络的可达性，难以做到按应用、按请求的细粒度授权。本文介绍如何使用 AWS Verified Access 按照零信任原则构建访问方案：每个请求都基于身份实时评估，只发布被显式授权的应用；浏览器访问私网 Web 应用无需安装任何客户端；SSH、数据库等 TCP 应用通过 Connectivity Client 接入。文中以 Amazon Cognito 作为 OIDC 身份源，给出从网络、身份、策略到端点的完整搭建步骤，并总结会话时长控制、TCP 隧道 MTU 等实践中容易踩到的问题。

01 一、背景：从网络边界到零信任

02 二、AWS Verified Access 核心概念

03 三、方案架构

04 四、实施步骤：Web 应用（无客户端）

05 五、实施步骤：TCP 应用（Connectivity Client）

06 六、实践要点与常见问题

07 七、总结

08 八、参考链接

一、背景：从网络边界到零信任

企业内部的运营后台、BI 报表、工单系统、运维跳板机通常部署在 VPC 私有子网，不对公网开放。传统的访问控制建立在网络边界之上：用户一旦进入内网，就被默认视为可信。这种模型在以下几个方面越来越难满足安全要求：

访问范围难以收敛：基于网络的授权粒度通常是网段，而不是具体应用，用户能触达的资源远多于实际需要；凭证一旦泄露，攻击者可以在内网横向移动。
认证与授权只发生一次：身份只在建立连接时校验一次，之后的每个请求都不再重新评估身份和权限。
访问者越来越多样：外包人员、外部合作伙伴的设备不受企业管控，仅凭“来自哪个网络”已无法判断请求是否可信。

零信任（Zero Trust）的核心原则是“从不默认信任，始终验证”：不因请求来自某个网络位置而信任它，每个请求都基于身份（以及可选的设备状态）实时评估，只发布被显式授权的应用，并为每次访问留下审计记录。AWS Verified Access 是亚马逊云科技提供的托管零信任访问服务，按照这一原则为 VPC 内的应用提供访问控制，用户无需 VPN 即可安全访问被授权的应用。

二、AWS Verified Access 核心概念

在动手之前，先了解 Verified Access 的几个资源对象及其层级关系：

对象	作用
Verified Access instance	顶层资源，负责评估访问请求；信任提供商挂在 instance 上
Trust provider（信任提供商）	提供用户身份或设备状态等信任数据。每个 instance 只能关联一个用户身份信任提供商（如 IAM Identity Center 或任意标准 OIDC 提供商），可关联多个设备信任提供商
Verified Access group	一组安全要求相近的端点集合，组策略被组内所有端点继承；也是跨账号通过 AWS RAM 共享的粒度
Verified Access endpoint	代表一个应用。HTTP(S) 端点可指向内部 ALB/NLB 或网卡；TCP 端点可指向 NLB、网卡、Network CIDR 或 Amazon RDS
Access policy（访问策略）	用 Cedar 语言编写，基于信任数据决定允许或拒绝；可在 group 级和 endpoint 级分别定义，endpoint 策略在 group 基线之上进一步收紧

两类协议的接入方式不同，这是做方案时必须先分清的：

HTTP(S) 应用：浏览器直接访问，无需安装客户端。Verified Access 通过浏览器重定向完成 OIDC 登录，之后用会话 cookie 对每个请求做策略评估。
TCP 应用（SSH、RDP、数据库等）：需要在用户设备上安装 AWS Verified Access Connectivity Client，由客户端建立加密隧道、携带身份信息，并负责 TCP 端点的 DNS 解析和路由。

三、方案架构

[图 1：方案架构]

Web 应用的访问链路如下：

用户在浏览器访问业务域名（如 app.example.com），Amazon Route 53 将其 CNAME 到 Verified Access endpoint 的域名。
请求不带身份 cookie 时，Verified Access 返回 303，将浏览器重定向到 Amazon Cognito 托管登录页。
用户登录成功后回跳业务域名，Verified Access 从 OIDC 提供商的 UserInfo 端点获取信任数据。2025 年 2 月 24 日及之后创建的信任提供商，还会把 ID token 的 claim 放进 additional_user_context，一起参与 Cedar 策略评估。
策略允许时，请求被转发到私有子网中的 internal ALB 和应用服务器，同时在请求头 x-amzn-ava-user-context 中注入签名 JWT。应用应先校验该 JWT 的签名，拒绝缺少此请求头或签名无效的请求，再从中读取用户身份。这样即使 Verified Access 被误关、或有流量绕过它，应用仍能兜底。

整个架构中，ALB 为 internal 类型，私有子网没有到 Internet Gateway 的路由，应用服务器没有公网 IP——Verified Access endpoint 是唯一的公网入口，而它首先要求身份。应用本身不需要编写任何认证代码。

选择 Amazon Cognito 作为身份源有一个额外好处：由于每个 instance 只能挂一个用户身份信任提供商，当需要接入多个外部合作伙伴各自的 IdP 时，可以把这些 SAML/OIDC IdP 以及社交身份联邦到 Cognito User Pool，由 Cognito 作为对 Verified Access 唯一的 OIDC issuer。

四、实施步骤：Web 应用（无客户端）

以下命令、策略和参数均为示例（sample），用于说明配置方法；实际部署时请按你的身份源、网络和安全要求替换和配置。

4.1 准备网络与应用

在 VPC 中准备私有子网，部署应用服务器（无公网 IP）。
创建 internal 类型的 ALB 并注册应用为 target。注意：Verified Access 只支持内部负载均衡器，如果现网应用挂在公网 ALB 上，需要单独新建一个 internal ALB。
规划三层安全组单向放行：Verified Access endpoint 安全组 → ALB 安全组 → 应用安全组，ALB 只允许来自 endpoint 安全组的流量。
在 AWS Certificate Manager（ACM）中为业务域名申请公网证书（支持通配证书）。

4.2 配置 Amazon Cognito 作为 OIDC 身份源

创建 Cognito User Pool，配置托管登录域名。
创建 App client（机密客户端，生成 client secret），OAuth 流程选择 Authorization code grant，scope 至少包含 openid、email、profile。
回调 URL 填写 https://<业务域名>/oauth2/idpresponse。

4.3 创建信任提供商、instance 与 group

# 1. 创建 OIDC 用户身份信任提供商
aws ec2 create-verified-access-trust-provider \
  --trust-provider-type user \
  --user-trust-provider-type oidc \
  --policy-reference-name oidc \
  --oidc-options '{
    "Issuer": "https://cognito-idp.<region>.amazonaws.com/<user-pool-id>",
    "AuthorizationEndpoint": "https://<cognito-domain>/oauth2/authorize",
    "TokenEndpoint": "https://<cognito-domain>/oauth2/token",
    "UserInfoEndpoint": "https://<cognito-domain>/oauth2/userInfo",
    "ClientId": "<client-id>",
    "ClientSecret": "<client-secret>",
    "Scope": "openid email profile"
  }'

# 2. 创建 instance 并关联信任提供商
aws ec2 create-verified-access-instance
aws ec2 attach-verified-access-trust-provider \
  --verified-access-instance-id <vai-id> \
  --verified-access-trust-provider-id <vatp-id>

# 3. 创建 group
aws ec2 create-verified-access-group --verified-access-instance-id <vai-id>

policy-reference-name 是在 Cedar 策略中引用该信任提供商数据时使用的名字，下文策略中的 context.oidc 即对应这里的 oidc。

示例中 client secret 直接写在命令行里，会留在 shell 历史中。实际操作时建议写入文件，用 --oidc-options file://oidc.json 传入，或从 AWS Secrets Manager 读取。

4.4 编写 Cedar 访问策略

以下策略改编自官方文档 Verified Access example policies 中的 Example 2（去掉了设备信任条件），仅演示写法：只允许属于指定用户组、且邮箱已验证的用户访问。

permit(principal, action, resource)
when {
    context.oidc.groups.contains("finance")
    && context.oidc.email_verified == true
};

字段名和类型取决于所用 IdP 返回的 claim。例如 Cognito UserInfo 返回的 email_verified 为字符串，用户组位于 ID token 的 cognito:groups 中（对应 context.oidc.additional_user_context）。请以访问日志中的实际 trust data 为准编写条件。

使用 Cognito 时还需注意：

建议关闭自助注册或强制验证邮箱，否则任何人都能注册一个属于企业邮箱域的账号。
如果在 Cognito 中联邦了多个外部 IdP，任何一个 IdP 都可以声明任意邮箱域，邮箱域就不能作为授权依据，应改用用户组等条件区分来源。

aws ec2 modify-verified-access-group-policy \
  --verified-access-group-id <vagr-id> \
  --policy-enabled \
  --policy-document file://group-policy.cedar

策略是数据而不是代码，修改后即时生效，不需要重启或重新部署应用。

4.5 创建 endpoint 并配置 DNS

aws ec2 create-verified-access-endpoint \
  --verified-access-group-id <vagr-id> \
  --endpoint-type load-balancer \
  --attachment-type vpc \
  --domain-certificate-arn <acm-cert-arn> \
  --application-domain app.example.com \
  --endpoint-domain-prefix app \
  --security-group-ids <sg-vae> \
  --load-balancer-options '{
    "LoadBalancerArn": "<internal-alb-arn>",
    "Port": 80, "Protocol": "http",
    "SubnetIds": ["<subnet-a>", "<subnet-b>"]
  }'

以上示例中 Verified Access 到 ALB 使用 HTTP 80 端口，仅用于演示；生产环境建议 internal ALB 配置 HTTPS 监听，实现端到端加密。endpoint 变为 active 后，在 Route 53 中将业务域名 CNAME 到 endpoint 返回的 EndpointDomain。注意一个 endpoint 只对应一个应用域名（证书可以是通配证书，但端点不支持通配），应用数量较多时需要提前评估端点数量与配额。

[图 2]

4.6 开启访问日志与验证

在 instance 上开启访问日志写入 CloudWatch Logs，日志中可以看到每个请求的身份、策略判定过程和结果。验证时：

[图 3]

未登录直接访问业务域名，应返回 303 并重定向到 Cognito 登录页，日志中可见 Authenticating 状态——拦截发生在 Verified Access，而不是应用自身。
使用满足策略条件的用户登录后返回 200，应用收到 x-amzn-ava-user-context 请求头，内容为签名 JWT，校验签名后可读取 email、sub 等 claim。
使用不满足策略条件的用户登录，Cognito 认证成功，但会被 Verified Access 策略拒绝在应用之前。

五、实施步骤：TCP 应用（Connectivity Client）

对于 SSH、数据库等非 HTTP 应用，Verified Access 提供 TCP 端点。以下配置同样为示例（sample），实际部署时请按你的环境替换和配置。与 Web 端点相比，有三点关键差异：

信任提供商需配置 native application OIDC（NativeApplicationOidcOptions），不能直接沿用 Web 应用的 OIDC 配置，在 IdP 侧也需要为客户端单独配置回调。
用户设备需安装 AWS Verified Access Connectivity Client（提供 macOS 和 Windows 版本）。安装前需断开其他 VPN 客户端；在本机启用 IPv6 协议栈（不需要有 IPv6 公网连接，但纯 IPv4 网络下未启用 IPv6 协议栈时会连不上）；Windows 设备还需支持 TPM 并安装 WebView2 运行时。客户端配置文件从 instance 导出（只有存在 active 状态的 TCP 端点时才能导出），文件名须以 ClientConfig- 开头，macOS 上放在 /Library/Application Support/Connectivity Client，Windows 上放在 C:\ProgramData\Connectivity Client，文件属主须为 root（macOS）或 Admin（Windows）。
TCP 端点不对外暴露 A 记录，DNS 解析和路由由 Connectivity Client 在设备上完成；客户端未连接时无法访问端点。

5.1 创建 Network CIDR 端点

Network CIDR 端点适合“按网段 + 端口”发布一批私网资源，例如某个子网内所有实例的 22 端口：

Protocol 选择 TCP，Endpoint type 选择 Network CIDR。
填写目标 CIDR 与端口范围（如 22、3306），选择子网与安全组。
可选配置 custom subdomain：这是委派给 Verified Access 自动维护的 TCP 目标主机名命名空间，Verified Access 会为 CIDR 内正在使用的每个 IP 维护 DNS 记录，并提供其 DNS 服务器地址供你配置转发规则。它不是跳板机，也不是浏览器访问的业务域名。

Network CIDR 端点按网段覆盖后端资源，无需为每台主机单独创建端点。如果目标是单个数据库，也可以使用 RDS 端点类型，直接关联 RDS 实例、集群或 RDS Proxy。

5.2 安装客户端并连接

用户把配置文件放到上述目录后启动 Connectivity Client，客户端会拉起浏览器完成 OIDC 登录。连接成功后，使用 Verified Access 提供的 DNS 名称访问目标：对 Network CIDR 端点，每个 IP 对应的主机名是“IP 中的点换成横杠”加上 endpoint 域名，例如：

H=10-0-1-10.<vae-id>.<vai-id>.prod.verified-access.<region>.amazonaws.com
ssh ec2-user@$H

注意不能直接用私网 IP 访问，客户端只接管 Verified Access 分配的地址。Verified Access 同样按 Cedar 策略逐个连接做鉴权。

[图 4]

六、实践要点与常见问题

6.1 会话时长如何控制

对于 OIDC 信任提供商，Verified Access 的会话时长等于 OIDC refresh token 的有效期；未返回 refresh token 时使用默认会话时长（2025 年 2 月 24 日及之后创建的信任提供商默认 1 天，之前创建的默认 7 天）。因此要缩短会话，应在 IdP 侧（如 Cognito App client 的 Refresh token expiration）调整，而不是在 Verified Access 侧寻找参数。非 Cognito 的 IdP 通常需要在 scope 里加上 offline_access 才会返回 refresh token，官方也建议 Connectivity Client 场景加上这个 scope。

几个容易误解的点：

这条规则只适用于 OIDC 信任提供商。使用 IAM Identity Center 作为信任提供商时，调整 Identity Center 的会话时长并不会改变 Verified Access 的会话时长。
refresh token 提供的是绝对超时（从签发起固定时长），而不是空闲超时（无操作或关闭浏览器后失效）。Verified Access 本身没有空闲超时和登出端点。如果业务要求空闲超时，需要在链路中真正持有会话状态的那一层（应用或跳板机）实现。
在共享电脑上，仅清除 Verified Access 的 cookie 或仅清除 IdP 的 cookie 都不足以强制重新登录，需要两侧 cookie 一并清除。

6.2 排障：TCP 隧道大响应卡住

在 macOS 上测试 TCP 端点时，可能出现小响应（如健康检查）正常、大响应卡住的情况。抓包可以看到下行大包没有被确认。将 Connectivity Client 创建的 utun 网卡 MTU 调低到 1280（IPv6 的最小 MTU）后，大响应恢复正常：

sudo ifconfig <utunX> mtu 1280

这是在测试环境中验证过的临时绕过方案，不是官方推荐配置：ifconfig 的修改在客户端重连或设备重启后会失效。如果问题持续出现，建议提交 AWS Support case。

6.3 适用边界

Verified Access 适合人的交互式访问：Web 应用通过浏览器直接访问，SSH、数据库等 TCP 应用通过 Connectivity Client 访问。系统对系统的程序化 API 调用无法完成交互式 OIDC 登录，应使用 API Gateway、ALB mTLS 或 OAuth client credentials 等方式。
如果服务器运维以内部人员为主，且不需要暴露 22 端口，也可以使用 AWS Systems Manager Session Manager；需要让外部人员按身份访问 SSH 或数据库时，使用 Verified Access TCP 端点。AWS 控制台和 API 访问使用 IAM Identity Center 与最小权限 IAM 管理。
负载均衡器端点不支持 WebSocket 等长连接 HTTPS，这类应用需要通过 TCP 端点接入。
设备信任需要在终端部署 MDM/EDR 代理。对外部合作伙伴的不受控设备，通常只能依赖用户身份 + 策略。
目前不支持 IPv6 流量；数据库等应用的数据隔离仍需在应用层按用户身份实现，Verified Access 只负责“能否进入应用”。

6.4 计费

Verified Access 的费用与端点数量、使用时长和处理的数据量相关，不同端点类型的计费维度请以 Verified Access 定价页面为准。

七、总结

AWS Verified Access 将零信任原则落到了每一次访问上：用户只能访问被显式发布的应用，每个请求都基于身份实时鉴权，应用本身无需改造，访问日志可完整审计。对于浏览器访问的私网 Web 应用，用户无需安装任何客户端；对于 SSH、数据库等 TCP 应用，通过 Connectivity Client 也可纳入同一套身份与策略体系。

落地时建议先明确三件事：访问对象是人还是系统、协议是 HTTP(S) 还是 TCP、身份源是否需要汇聚多个 IdP。这三点决定了端点类型、是否需要客户端以及信任提供商的设计。

➡️ 下一步行动：

相关产品：