[解决方案] 使用 AWS Verified Access 通过互联网安全访问 SaaS PrivateLink 端点

<!-- AI_TASK_START: AI标题翻译 --> [解决方案] 使用 AWS Verified Access 通过互联网安全访问 SaaS PrivateLink 端点 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该解决方案的核心是结合使用 **AWS Verified Access** 与 **AWS PrivateLink**，为通过 PrivateLink 接入的 **SaaS (软件即服务)** 应用提供安全的、基于互联网的访问能力。它旨在解决一个关键挑战：SaaS 消费者通常使用 PrivateLink 在其 VPC 和 SaaS 提供商之间建立私有、安全的连接，但这使得远程员工或外部合作伙伴无法从公共互联网访问这些内部集成的服务。 此方案通过引入 AWS Verified Access 作为安全访问代理，构建了一个 **零信任 (Zero Trust)** 架构。用户请求首先被 Verified Access 拦截，经过严格的身份验证和策略授权后，才被允许通过 PrivateLink 安全地转发至后端的 SaaS 应用。这样既扩展了服务的可访问性，又无需将应用或 VPC 暴露在公网上，确保了高级别的安全性。 - **适用场景:** - 企业用户需要从公司网络外部（如家庭、分支机构）访问已通过 PrivateLink 集成到公司 AWS 环境中的 SaaS 服务。 - 需要对所有访问请求实施基于用户身份的精细化访问控制，而非传统的网络边界信任模型。 - **技术原理:** 1. 远程用户通过安装在设备上的 **Connectivity Client** 客户端发起对应用公共 URL 的访问。 2. **Amazon Route 53** 将请求负载均衡至一个或多个 AWS Verified Access 终端节点。 3. **AWS Verified Access** 实例利用集成的身份提供商（如 **AWS IAM Identity Center**）对用户进行身份验证。 4. 验证通过后，Verified Access 根据预设策略评估请求，决定是否授权访问。 5. 授权的流量被转发到消费者 VPC 内的 **接口 VPC 终端节点 (Interface VPC Endpoint)** 的网络接口 (ENI)。 6. 流量通过 **AWS PrivateLink** 连接，跨越账户和 VPC 边界，安全地到达 SaaS 提供商侧的 **网络负载均衡器 (NLB)**。 7. NLB 最终将流量路由至托管应用的后端服务器（如 **Amazon EC2**）。 ## 实施步骤 1. **SaaS 提供商：设置 PrivateLink 服务** - 在 SaaS 提供商的 VPC 中，创建一个 **终端节点服务 (Endpoint Service)**。 - 该服务的前端是一个 **网络负载均衡器 (NLB)**，后端连接到托管 SaaS 应用的 EC2 实例。 - 将此终端节点服务授权给消费者 AWS 账户使用。 2. **SaaS 消费者：创建接口 VPC 终端节点** - 在消费者的 VPC 中，使用上一步中 SaaS 提供商提供的服务名称，创建一个 **接口 VPC 终端节点**。 - 为了实现高可用性，应确保该终端节点在至少两个可用区 (AZ) 中创建了弹性网络接口 (ENI)。 3. **SaaS 消费者：配置 AWS Verified Access** - **创建信任提供商：** 创建一个用户身份信任提供商，并与 **IAM Identity Center** 等身份源集成。 - **创建 Verified Access 实例：** 创建一个实例，并关联上一步创建的信任提供商。 - **创建 Verified Access 组：** 创建一个组并关联到 Verified Access 实例。在此组中定义访问策略，例如，只允许来自特定域名（如 `@amazon.com`）的已验证邮箱用户访问。 - **创建 Verified Access 终端节点：** - 为每一个接口 VPC 终端节点的 ENI 创建一个对应的 **网络接口类型** 的 Verified Access 终端节点。 - 协议选择 `TCP`，并指定应用端口（如 `443`）。 4. **SaaS 消费者：配置公共 DNS** - 在 **Amazon Route 53** 中，为应用创建一个公共 DNS 记录（如 CNAME）。 - 使用 **加权路由策略 (Weighted Routing)**，将流量负载均衡到多个 Verified Access 终端节点自动生成的唯一 DNS 名称上。 5. **终端用户：连接与访问** - 用户在其设备（Windows 或 macOS）上下载、安装并配置 **Connectivity Client** 客户端软件。 - 启动客户端，通过浏览器弹窗完成身份验证流程。 - 认证成功后，客户端状态变为“已连接”，此时用户即可通过在 Route 53 中配置的公共 URL 访问 SaaS 应用。 ## 方案客户价值 - **扩展安全访问边界:** 无需部署传统的 VPN 或将内部资源暴露于公网，即可将 PrivateLink 提供的私有、安全连接能力安全地延伸至互联网上的任意授权用户。 - **贯彻零信任安全模型:** 在应用访问的入口强制执行用户身份验证和策略评估，确保每一次访问都经过严格审查，显著提升了安全性，防止未经授权的访问。 - **简化运维管理:** 方案采用全托管服务，替代了复杂的 VPN 网关或虚拟桌面基础设施 (VDI) 的部署和维护工作，*降低了运营开销*。 - **提升用户体验:** 终端用户通过轻量级客户端即可无缝、直接地访问所需应用，避免了繁琐的网络配置和连接步骤。 - **内置高可用性:** 通过在多个可用区部署接口终端节点，并利用 Route 53 进行流量的加权负载均衡，天然地构建了高可用的访问架构。 ## 涉及的相关产品 - **AWS Verified Access:** 作为核心组件，充当零信任访问代理，负责用户认证、策略执行和流量转发。 - **AWS PrivateLink:** 提供跨 VPC 和账户的私有、安全的底层网络连接。 - **Amazon VPC:** 包括接口 VPC 终端节点及其关联的弹性网络接口 (ENI)，是连接 PrivateLink 和 Verified Access 的桥梁。 - **Network Load Balancer (NLB):** 在 SaaS 提供商侧接收 PrivateLink 流量并分发至后端应用。 - **Amazon EC2:** 托管 SaaS 应用的计算资源。 - **AWS IAM Identity Center:** 用作身份提供商，对访问用户进行身份验证。 - **Amazon Route 53:** 用于配置应用的公共 DNS 名称，并实现到多个 Verified Access 终端节点的负载均衡。 - **Connectivity Client:** 终端用户设备上必须安装的客户端软件，用于建立与 Verified Access 的安全连接。 ## 技术评估 - **优势:** - **极高的安全性:** 方案实现了端到端的安全隔离。应用本身不暴露于公网，所有访问请求都必须通过 Verified Access 的身份验证和授权，极大地缩小了攻击面。 - **清晰的架构解耦:** 将访问控制逻辑（Verified Access）与网络连接（PrivateLink）的职责明确分离，使得架构更清晰，易于管理和排错。 - **灵活的策略控制:** 支持与多种身份提供商集成，并可利用 Cedar 策略语言定义精细化的、基于上下文的访问规则。 - **可能的限制:** - **客户端依赖:** 方案要求终端用户必须安装和配置 `Connectivity Client` 软件，这可能为企业在设备管理和用户培训方面带来额外的管理成本。 - **区域性限制:** 文中明确指出该解决方案聚焦于同区域 (Same-Region) 的连接场景，并未覆盖跨区域 PrivateLink 的复杂情况。 - **协议特定配置:** 虽然方案支持非 HTTP(S) 协议，但需要为特定应用协议和端口进行精确配置，要求实施者对应用的网络需求有深入了解。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 使用 AWS Verified Access 安全地通过互联网访问 SaaS PrivateLink 终端节点 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/secure-internet-based-access-to-saas-privatelink-endpoints-using-aws-verified-access/](https://aws.amazon.com/blogs/networking-and-content-delivery/secure-internet-based-access-to-saas-privatelink-endpoints-using-aws-verified-access/) **发布时间:** 2025-08-21 **厂商:** AWS **类型:** BLOG --- ## 引言 随着云采用率的增长，AWS 上的 [软件即服务 (SaaS)](https://aws.amazon.com/saas/) 提供商越来越多地使用 Amazon Web Services [(AWS) PrivateLink](https://aws.amazon.com/privatelink/) 来向其客户安全地交付服务。PrivateLink 能够在 VPC 之间实现无缝的私有连接，而无需将应用程序暴露到公共互联网，从而确保了强大的安全性和一致的网络性能。 然而，如果您想为 AWS 之外的用户 (例如远程工作的员工或通过互联网连接的合作伙伴) 提供同样的安全访问，该怎么办呢？[AWS Verified Access](https://aws.amazon.com/verified-access/) 使得将由 PrivateLink 支持的服务扩展到互联网上的授权用户成为可能——同时保持强大的安全边界和 [零信任 (zero trust)](https://aws.amazon.com/security/zero-trust/) 架构。 在本文中，我们将探讨如何使用 Verified Access 为 PrivateLink 终端节点启用安全、可扩展且基于互联网的访问。这使得组织能够将其 SaaS 集成扩展到任何地方的用户，而不会影响安全性。 本文假设您已熟悉 AWS Verified Access 的基本原理，因此我们不涵盖基础知识。 ## 解决方案概述 我们首先研究一个涉及安全访问 SaaS 应用程序的场景。在这种情况下，SaaS 提供商通过 PrivateLink 终端节点服务 (endpoint service) 提供其应用程序，而消费者则在其 VPC 内建立一个接口 VPC 终端节点 (interface VPC endpoint) 来连接到该服务。这在下面的架构图中有所展示。当消费者组织内的用户需要从 AWS 外部 (例如通过互联网) 访问此服务时，挑战就出现了。我们采用 Verified Access 作为解决方案来安全地建立这种连接，因为接口终端节点只能从 VPC 内部或连接的网络 (例如通过 [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) 或 [AWS Direct Connect](https://aws.amazon.com/directconnect/) 的混合连接) 访问。此解决方案不涵盖跨区域的 PrivateLink。相反，我们专注于同一区域内的连接。  **图 1: 架构图，展示用户通过 Verified Access 终端节点向托管在 SaaS 账户中的 SaaS 服务发出请求** 使用 Verified Access 意味着流量按以下方式流动： 1. 安装了 Verified Access ([Connectivity Client](https://aws.amazon.com/verified-access/connectivity-client-download/)) 的远程用户向消费者 VPC 所有者提供的指向 AWS Verified Access 终端节点的公共 URL 发出请求。Verified Access Connectivity Client 实现了用户设备与非 HTTP(s) 应用程序之间的连接。 2. 在消费者账户中，有一个 [Amazon Route 53](https://aws.amazon.com/route53/) 公有托管区，其中包含一条加权路由记录，用于在两个 AWS Verified Access 终端节点之间进行流量负载均衡。每个 Verified Access 终端节点都指向一个特定的接口 VPC 终端节点。 3. 用户使用 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 进行身份验证。 4. 来自接口 VPC 终端节点的请求通过 PrivateLink 转发到 SaaS VPC 中的 [网络负载均衡器 (Network Load Balancer)](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) (NLB)。 5. NLB 将流量路由到托管应用程序的后端 [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) 实例。 ## 解决方案实施 以下步骤将引导您完成此解决方案。 **步骤 1: SaaS 提供商 VPC——设置 PrivateLink 服务** 1. [创建一个由 PrivateLink 提供支持的服务](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) ，即终端节点服务，如下图所示。 - 在我们的示例中，此服务托管在由 NLB 提供前端的 EC2 实例上。 2. [向服务消费者提供该终端节点服务](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html#share-endpoint-service) 。  *图 2: 显示已注册 NLB 的 VPC 终端节点服务* **步骤 2: 消费者 VPC——创建接口 VPC 终端节点** 1. 在消费者 VPC 中，为步骤 1 中创建的服务名称 [创建一个](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html#connect-to-endpoint-service) 接口 VPC 终端节点，如下图所示。 - 为实现高可用性，请在至少两个 [可用区 (Availability Zones)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) (AZ) 中创建该终端节点。 - 记下此终端节点创建的弹性网络接口 (Elastic Network Interface) (ENI) ID，因为在后续步骤中需要用到它们。  *图 3: 消费者 VPC 中的 VPC 终端节点及其部署所在的子网* **步骤 3: 消费者账户——创建 AWS Verified Access** 1. 为 Verified Access [创建一个](https://docs.aws.amazon.com/verified-access/latest/ug/user-trust.html) 用户身份信任提供程序。 - 在我们的示例中，我们使用 IAM Identity Center，如下图所示。  *图 4: Verified Access 信任提供程序类型为 IAM Identity Center* 2. [创建一个](https://docs.aws.amazon.com/verified-access/latest/ug/create-verified-access-instance.html) Verified Access 实例，如下图所示。 - 创建 Verified Access 实例时，您可以将其与上一步中创建的信任提供程序关联。  *图 5: Verified Access 实例使用 iam-identity-center 作为用户类型* 3. [创建一个](https://docs.aws.amazon.com/verified-access/latest/ug/create-verified-access-group.html) Verified Access 组，如下图所示。 - 将此组分配给先前创建的 Verified Access 实例。 - 定义一个 Verified Access 组策略来管理访问。在我们的示例中，我们允许来自 *@amazon.com* 的已验证电子邮件地址访问。  *图 6: Verified Access 组策略* 4. 为 Verified Access [创建一个](https://docs.aws.amazon.com/verified-access/latest/ug/create-network-interface-endpoint.html) 网络接口终端节点： - 选择您先前创建的 Verified Access 组。 - 对于协议 (Protocol)，选择 **TCP**。 - 对于端口范围 (Port ranges)，输入 “443-443”。 - 对于**网络接口 (Network interface)**，选择您在步骤 2 中创建的接口 VPC 终端节点的 ENI ID。您需要为每个 ENI 创建一个 Verified Access 终端节点。完成后，您应该有两个 Verified Access 终端节点，如下图所示。  *图 7: Verified Access 终端节点详细信息* 完成这些步骤后，每个 Verified Access 终端节点都有其唯一的 DNS 名称。记下这些名称，因为我们将使用它们来配置 Route 53 中的公有托管区。下图显示了如何找到生成的终端节点域名。  *图 8: Verified Access 终端节点域名* **步骤 4: 为您的应用程序创建 DNS** 1. 在 Route 53 [公有托管区 (public hosted zone)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html) 中 [创建一个](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html) [加权记录 (weighted record)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-weighted.html) 。 - 每个 Verified Access 终端节点都有其自己的 [CNAME](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) 记录，如下图所示。  *图 9: 带有 CNAME 记录的 Route 53 托管区* ## 使用 AWS Verified Access 访问应用程序 当 Verified Access 终端节点可用后，您可以使用 Connectivity Client 访问应用程序。用户必须首先在其首选的操作系统 (Windows 或 macOS) 上 [下载](https://docs.aws.amazon.com/verified-access/latest/ug/connectivity-client.html#connectivity-client-download) 并安装最新版本的 Connectivity Client。在继续之前，请卸载任何旧版本的客户端。在登录之前，用户必须 [导出](https://docs.aws.amazon.com/verified-access/latest/ug/connectivity-client.html#connectivity-client-export-configuration) 客户端配置文件，这可以通过 [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/) 控制台或 [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/) 来完成。然后，必须将 [配置文件](https://docs.aws.amazon.com/verified-access/latest/ug/connectivity-client.html#connectivity-client-connect) 部署到特定位置： - 对于 Windows: `C:\ProgramData\Connectivity Client` - 对于 macOS: `/Library/Application\ Support/Connectivity\Client` 完成这些步骤后，用户可以启动 Connectivity Client 并通过提供的界面进行身份验证，如下图所示。  *图 10: Connectivity Client 登录屏幕* 当您选择**登录 (Sign In)**后，一个浏览器窗口会提示您输入用户名和密码。然后，您会看到一个权限请求，询问**“允许 Connectivity Client 访问您的数据吗？ (Allow Connectivity Client to access your data?)”**，需要您确认才能继续。  *图 11: 允许 Connectivity Client 访问您的数据* 选择**允许访问 (Allow access)**后，您的身份验证就完成了，如下图所示。  *图 12: 成功登录后的 Connectivity Client* **Connectivity Client** 窗口会更新并显示**已连接 (Connected)**状态，表示身份验证成功，如下图所示。  *图 13: Connectivity Client 连接时的状态* 此过程可实现对应用程序的安全和经过验证的访问。身份验证后，客户端会与 Verified Access 终端节点建立一个安全通道。随后，所有流量都通过 ENI 路由，该 ENI 通过 PrivateLink 连接到 SaaS 提供商。这个简化的工作流程利用 AWS 服务和安全功能，确保了用户与应用程序之间的安全高效连接。 要从浏览器访问应用程序，请导航到您在 Route 53 公有托管区中创建的 URL 记录。下图显示用户现在可以访问托管在 SaaS 提供商 VPC 中、位于私有 NLB 后面的 EC2 实例上的应用程序。  *图 14: 通过 Verified Access 经由 PrivateLink 交付的 SaaS 服务的欢迎屏幕* ## 结论 AWS Verified Access 提供了一种新的方式，可以为内部 AWS 资源 (例如基于 PrivateLink 的 SaaS 终端节点) 建立安全、可扩展且可通过互联网访问的连接。结合 PrivateLink 和 Verified Access 的功能，企业可以创建既直接又合规的端到端安全应用程序访问工作流。 如果您是寻求为 PrivateLink 服务启用安全外部访问的 SaaS 提供商或消费者，那么 Verified Access 提供了一个强大的解决方案，且运营开销极小。立即 [开始](https://aws.amazon.com/about-aws/whats-new/2025/02/aws-verified-access-zero-trust-resources-non-https-protocols/) 使用 Verified Access 的功能，这些功能支持通过非 HTTP(S) 协议访问资源。 - [通过 AWS PrivateLink 访问 AWS 服务](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) - [什么是 AWS Verified Access?](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html) ## 关于作者  ### Salman Ahmed Salman Ahmed 是 AWS 企业支持部门的高级技术客户经理。他专注于指导客户设计、实施和支持 AWS 解决方案。他将自己的网络专业知识与探索新技术的动力相结合，帮助组织成功地驾驭其云之旅。工作之余，他喜欢摄影、旅行和观看他最喜欢的运动队比赛。  ### Ankush Goyal Ankush Goyal 是 AWS 企业支持部门的高级技术客户经理，专注于帮助旅游和酒店行业的客户优化其云基础设施。凭借超过 20 年的 IT 经验，他专注于利用 AWS 网络服务来提高运营效率和云采用率。Ankush 热衷于提供有影响力的解决方案，并帮助客户简化其云运营。 <!-- AI_TASK_END: AI全文翻译 -->