基于 AWS Verified Access 构建零信任访问：安全访问私网 Web 与 TCP 应用
内容提要
本文介绍如何使用 AWS Verified Access 按零信任原则访问 VPC 私网应用：每个请求都基于身份实时评估，仅发布显式授权的应用。浏览器访问 Web 应用无需客户端，通过 Cognito OIDC 登录；SSH、数据库等 TCP 应用需安装 Connectivity Client。文中给出网络、身份、Cedar 策略与端点的搭建步骤，并提示会话时长由 refresh token 有效期决定、TCP 隧道 MTU 等常见问题。
延伸解读
应用侧兜底校验：别把安全全押在网关
文章强调，Verified Access 在转发请求时会注入签名 JWT 请求头 x-amzn-ava-user-context。应用应先校验该 JWT 签名，拒绝缺少请求头或签名无效的请求，再读取用户身份。这样即使 Verified Access 被误关或有流量绕过，应用仍能兜底。这意味着接入零信任网关不等于应用可以完全不做身份校验，尤其对已有应用改造时，需评估其是否具备校验 JWT 的能力。
会话时长与登出：控制点在 IdP 而非网关
使用 OIDC 信任提供商时，Verified Access 会话时长等于 refresh token 有效期，未返回 refresh token 则用默认值。要缩短会话需在 IdP 侧调整，而非在 Verified Access 找参数。且 refresh token 是绝对超时，不是空闲超时；Verified Access 本身没有空闲超时和登出端点。若业务要求空闲超时，需在真正持有会话状态的应用或跳板机层实现。共享电脑上还需同时清除两侧 cookie 才能强制重新登录。
TCP 接入的隐性门槛与临时绕过
TCP 应用需安装 Connectivity Client，且对终端有额外要求：安装前断开其他 VPN、启用 IPv6 协议栈（纯 IPv4 未启用会连不上）、Windows 需 TPM 和 WebView2。配置文件须按指定目录和属主放置。文章还记录 macOS 上大响应卡住的问题，将 utun 网卡 MTU 调低到 1280 可临时恢复，但该修改在重连或重启后失效，并非官方推荐配置，持续出现应提交 Support case。
适用边界：先分清人还是系统、HTTP 还是 TCP
文章明确 Verified Access 适合人的交互式访问，系统对系统的程序化 API 调用无法完成交互式 OIDC 登录，应改用 API Gateway、ALB mTLS 或 OAuth client credentials。负载均衡器端点不支持 WebSocket 等长连接 HTTPS，需走 TCP 端点。目前不支持 IPv6 流量，且数据隔离仍需应用层按用户身份实现，Verified Access 只负责能否进入应用。落地前应先明确访问对象、协议和身份源三点。
Q&A
AWS Verified Access 的零信任访问和传统 VPN 有什么区别？
传统 VPN 基于网络边界，用户进入内网后默认可信，授权粒度通常是网段，且身份只在建立连接时校验一次。AWS Verified Access 遵循零信任原则，不因请求来自某个网络位置而信任它，每个请求都基于身份（及可选设备状态）实时评估，只发布被显式授权的应用，并为每次访问留下审计记录，用户无需 VPN 即可安全访问被授权的应用。
用浏览器访问私网 Web 应用需要安装客户端吗？登录流程是怎样的？
不需要安装任何客户端。用户在浏览器访问业务域名，Route 53 将其 CNAME 到 Verified Access endpoint 域名；请求不带身份 cookie 时，Verified Access 返回 303 重定向到 Amazon Cognito 托管登录页。登录成功后回跳业务域名，Verified Access 从 OIDC 提供商的 UserInfo 端点获取信任数据，策略允许时转发到私有子网中的 internal ALB 和应用服务器。
SSH、数据库这类 TCP 应用怎么通过 Verified Access 访问？
需要创建 TCP 端点（如 Network CIDR 端点或 RDS 端点），并在用户设备上安装 AWS Verified Access Connectivity Client（支持 macOS 和 Windows）。客户端从 instance 导出配置文件并放到指定目录，启动后拉起浏览器完成 OIDC 登录，建立加密隧道。连接成功后使用 Verified Access 提供的 DNS 名称访问目标，不能直接用私网 IP，因为客户端只接管 Verified Access 分配的地址。
Verified Access 的会话时长怎么控制？在 Cognito 里改还是 Verified Access 里改？
对于 OIDC 信任提供商，会话时长等于 OIDC refresh token 的有效期；未返回 refresh token 时使用默认会话时长（2025 年 2 月 24 日及之后创建的信任提供商默认 1 天，之前创建的默认 7 天）。因此要缩短会话，应在 IdP 侧（如 Cognito App client 的 Refresh token expiration）调整，而不是在 Verified Access 侧找参数。注意该规则只适用于 OIDC 信任提供商，使用 IAM Identity Center 时调整其会话时长不会改变 Verified Access 的会话时长。
Verified Access 适合系统对系统的 API 调用吗？有哪些适用边界？
不适合。Verified Access 适合人的交互式访问：Web 应用通过浏览器直接访问，SSH、数据库等 TCP 应用通过 Connectivity Client 访问。系统对系统的程序化 API 调用无法完成交互式 OIDC 登录，应使用 API Gateway、ALB mTLS 或 OAuth client credentials 等方式。此外，负载均衡器端点不支持 WebSocket 等长连接 HTTPS，这类应用需通过 TCP 端点接入；目前也不支持 IPv6 流量。
为什么需要把多个外部合作伙伴的 IdP 联邦到 Cognito？
因为每个 Verified Access instance 只能关联一个用户身份信任提供商。当需要接入多个外部合作伙伴各自的 IdP 时，可以把这些 SAML/OIDC IdP 以及社交身份联邦到 Cognito User Pool，由 Cognito 作为对 Verified Access 唯一的 OIDC issuer，从而汇聚多个身份源。
应用如何确认请求确实经过了 Verified Access？
Verified Access 在转发请求时会在请求头 x-amzn-ava-user-context 中注入签名 JWT。应用应先校验该 JWT 的签名，拒绝缺少此请求头或签名无效的请求，再从中读取用户身份（如 email、sub 等 claim）。这样即使 Verified Access 被误关或有流量绕过它，应用仍能兜底。
macOS 上测试 TCP 端点时大响应卡住怎么办？
抓包可以看到下行大包没有被确认。可将 Connectivity Client 创建的 utun 网卡 MTU 调低到 1280（IPv6 的最小 MTU），命令为 sudo ifconfig <utunX> mtu 1280，大响应即可恢复正常。这是测试环境中验证过的临时绕过方案，不是官方推荐配置，ifconfig 的修改在客户端重连或设备重启后会失效；如果问题持续出现，建议提交 AWS Support case。
