[解决方案] 保护服务通信：结合 VPC Lattice 与 Network Firewall

<!-- AI_TASK_START: AI标题翻译 --> [解决方案] 保护服务通信：结合 VPC Lattice 与 Network Firewall <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 基于 AWS 解决方案的竞争分析 ## 解决方案概述 本文档描述了 AWS 针对服务通信安全的解决方案，核心内容是结合 **Amazon VPC Lattice** 和 **AWS Network Firewall**，以解决传统集中式检查（如使用 Transit Gateway）在规模化应用中的挑战。 该方案针对现代应用的安全需求，提供： - 适用于需要深度数据包检查的流量（如恶意软件检测和 IPS/IDS）的集中式检查。 - 针对 HTTP/HTTPS 和 TCP 服务间通信的身份-based 访问控制和简化连接管理。 背景：随着应用规模扩大，传统防火墙规则管理复杂，增加延迟和成本。该方案通过分层策略优化安全架构，适用于多环境（如生产、开发和共享服务）的企业网络，行业需求包括金融、医疗等领域的技术原理基于 AWS 服务网络和身份验证（如 IAM），实现零信任模型和高效路由。 ## 实施步骤 1. **创建 VPC Lattice 服务网络** - 创建服务网络并关联相关 VPC（如生产、开发和共享服务 VPC）。 - 配置安全组控制入站流量，选择 AWS IAM 作为访问认证类型，并启用访问日志以监控请求。 - 理由：此步建立服务间连接基础，确保身份-based 控制，减少传统路由复杂性。 2. **创建 VPC Lattice 目标组和服务** - 为目标实例（如共享服务中的日志服务）创建目标组，配置协议（如 HTTP）和端口（如 5044）。 - 创建服务并设置监听器和规则，实现流量转发。 - 理由：此步定义流量路由逻辑，基于 Layer 7 处理 HTTP 通信，提高连接效率。 3. **设置 VPC 资源网关和资源配置** - 在共享服务 VPC 中创建资源网关，并配置资源（如 Redis Cache 的 IP 和端口 6379）。 - 关联资源配置与服务网络。 - 理由：支持 Layer 4 TCP 通信，提供安全组过滤，衔接上一步的 Layer 7 配置。 4. **配置 IAM 认证策略和 DNS（可选）** - 创建 IAM 策略以强制签名请求，实现零信任授权。 - 如果需要，配置自定义 DNS 名（如 logging.example.com）。 - 理由：确保细粒度访问控制和全球 DNS 管理，逻辑上衔接前述步骤以验证连接。 5. **验证连接性** - 使用工具（如 curl 或 netcat）测试服务访问，并应用 IAM 策略检查访问拒绝情况。 - 理由：此步确认整体架构可行性，识别潜在问题。 ## 方案客户价值 - **优化安全和性能**：通过 VPC Lattice 实现身份-based 访问控制，减少网络跳跃，相比传统集中式检查降低延迟；量化收益包括显著减少网络瓶颈和操作复杂性。 - **成本降低**：组合架构可减少 Network Firewall 和 Transit Gateway 的数据处理费用，随着流量增长，潜在节省比例增加（文档未指定确切百分比，但强调规模效应）。 - **与传统方案差异**：相较于仅依赖集中式防火墙的竞品（如其他云提供商的虚拟网络防火墙），该方案提供更灵活的 Layer 7 和 Layer 4 处理，避免不必要的路由，提高资源利用率，实现机制基于 AWS 专有服务网络。 ## 涉及的相关产品 - **Amazon VPC Lattice**：简化服务间 HTTP/HTTPS 和 TCP 通信，提供身份-based 访问控制和日志监控，在方案中负责优化连接管理。 - **AWS Network Firewall**：处理深度数据包检查和 IPS/IDS，用于关键流量安全，在方案中补充集中式检查功能。 - **AWS Transit Gateway**：管理 VPC 间路由，在组合架构中用于非 Lattice 流量的检查路径。 ## 技术评估 - **先进性**：方案采用零信任模型和 Layer 7 身份控制，领先于传统静态防火墙规则，提供可扩展的现代网络架构，适用于复杂多云环境。 - **可行性**：通过文档中的步骤实现简单，依赖 AWS 控制台和 IAM，适用于中等规模企业，但需确保 VPC 关联和策略配置正确。 - **适用范围**：适合需要混合安全策略的场景，如 HTTP 流量优先用 Lattice，非关键 TCP 流量分流，但可能限制于 AWS 生态，无法无缝迁移到其他云平台；优势在于成本优化和简化管理，局限性包括潜在依赖性（如 IAM 策略错误导致访问问题）。 ## 其他信息 - **结论与行动**：该方案强调根据流量类型选择安全控制，平衡性能和成本；建议用户参考 AWS 文档实施，并通过 re:Post 寻求支持，以适应行业趋势如零信任安全。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 保护服务通信：结合 VPC Lattice 与 Network Firewall **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/securing-service-communications-combining-vpc-lattice-with-network-firewall/](https://aws.amazon.com/blogs/networking-and-content-delivery/securing-service-communications-combining-vpc-lattice-with-network-firewall/) **发布时间:** 2025-06-23 **厂商:** AWS **类型:** BLOG --- ## **引言：** 在 AWS 上构建现代应用程序的组织常常需要针对不同类型服务通信应用不同的安全控制。虽然使用 AWS Network Firewall (Network Firewall) 进行集中式检查一直是保护服务间流量的传统方法，但随着应用程序规模扩大，这种方法会带来挑战。管理静态防火墙规则在操作上很复杂，尤其是在第 7 层 (Layer 7) 流量中，而故障排除也会变得越来越耗时。 [Amazon VPC Lattice](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-vpc-vattice-modernize-and-simplify-your-enterprise-network-architectures/) 为 HTTP/S 通信提供了一种防火墙替代方案，它提供了基于身份的访问控制和简化的连接管理。这可以补充现有的 Network Firewall 部署，让组织能够为不同流量类型使用最合适的安全控制。 - 使用 Network Firewall 对需要深度数据包检查的工作负载进行集中式流量检查。 - 为 HTTP/HTTPS 和 TCP 服务间通信实现 VPC Lattice。 - 在综合安全架构中结合这两种方法。 ## **解决方案概述：** 本解决方案展示了如何使用 VPC Lattice 和 Network Firewall 来保护服务通信。该架构允许： - 对需要恶意软件检测和 IPS/IDS 功能的流量进行深度数据包检查。 - 为 HTTP/HTTPS 服务通信提供基于身份的访问控制。 - 简化服务间连接管理。 - 根据安全需求优化路由。 ## **场景演练：** 在本节中，我们探索了三种保护工作负载的不同方法。 1. 集中式流量检查设置。 2. VPC Lattice 服务网络配置。 3. 结合架构。 # **1\. 集中式流量检查设置** 在本节中，我们讨论使用 AWS Transit Gateway 和 Network Firewall 的集中式检查架构。我们以生产环境 (Production)、开发环境 (Dev) 和 IT/共享服务环境作为基准架构，其中所有 VPC 间流量必须通过集中式检查点进行。这么设计通过深度数据包检查强制执行安全控制，并提供网络层和应用层安全监控。让我们更深入地了解这种传统架构如何处理安全应用连接。  图 1: 集中式检查架构 定义流量检查模式对于使用 Transit Gateway 和 Network Firewall 实现安全连接至关重要。当流量在 VPC 之间流动时，它首先通过 Transit Gateway 路由，然后定向到托管 Network Firewall 的检查 VPC。这创建了一个中心辐射模型 (hub-and-spoke model)，其中所有 VPC 间通信都经过安全检查，无论源或目标。这种方法虽然全面，但会引入额外的网络跳跃和潜在瓶颈。 在集中式检查架构中，生产和开发环境的 Web 服务与共享服务 VPC 中的日志服务和 Redis Cache 服务通信需要多个网络跳跃。如图所示，所有流量首先通过 Transit Gateway，然后通过检查 VPC 中的 Network Firewall 到达目的地。这会带来几个挑战：由于额外网络跳跃导致的延迟、复杂的路由表管理、在检查点可能出现的性能瓶颈，以及由于 Transit Gateway 和 Network Firewall 的数据处理费用而增加的成本。这些限制表明，使用 VPC Lattice 的更现代方法可以为服务间通信提供更高效的解决方案，同时保持安全控制。 要深入了解使用 AWS 服务实现的集中式检查架构，包括详细的实施指导和最佳实践，请参考这些 AWS 博客： * [使用 AWS Network Firewall 部署集中式流量过滤](https://aws.amazon.com/blogs/networking-and-content-delivery/deploy-centralized-traffic-filtering-using-aws-network-firewall/) * [使用 AWS Gateway Load Balancer 和 AWS Transit Gateway 的集中式检查架构](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/) # **2\. VPC Lattice 服务网络配置：** 在本节中，我们讨论 VPC Lattice 服务网络配置。我们以上文提到的生产环境、开发环境和 IT/共享服务环境作为基准架构。我们设置一个 VPC Lattice 网络，并演示从生产和开发环境到 IT/共享服务环境的 服务间连接。我们涵盖第 7 层 HTTP 和第 4 层 TCP 通信模式。让我们更深入地了解如何使用 VPC Lattice 设置安全应用连接。 定义访问模式对于使用 VPC Lattice 构建安全连接至关重要。当你将一个 VPC 与服务网络关联时，该 VPC 中的客户端可以访问与同一服务网络关联的服务。同样，当你将服务与服务网络关联时，这些服务可以被与同一服务网络关联的 VPC 中的客户端访问，前提是授权策略允许客户端到服务的通信。 在集中式检查架构中，生产和开发环境的 Web 服务与共享服务 VPC 中的日志服务和 Redis Cache 服务通信，用于日志记录和缓存相关调用。如图 2 所示，我们引入一个 VPC Lattice 服务网络，并将生产、开发和共享服务环境与它关联。下图展示了从生产和开发环境的 Web 服务到共享服务 VPC 的通信流，用于日志记录 (HTTP logstash) 和 Redis Cache (TCP 6379)，通过 VPC Lattice 服务网络。  图 2: 使用 VPC Lattice 的服务间通信 ### **实施步骤：** 按照说明，我们设置了基准架构中的 VPC 和相应服务。让我们更深入地了解如何使用 VPC Lattice 设置安全应用连接。 **步骤 1:** [创建 VPC Lattice 服务网络:](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-service-network.html) - 创建一个服务网络。 - 将服务网络与生产、开发和 IT/共享服务 VPC 关联。 - 为每个 VPC 关联创建安全组，以控制从相应 VPC 到服务网络的入站流量。 - 对于网络访问授权类型，请选择 AWS IAM。 - 你可以启用“服务访问日志 (Service Access Logs)”和“资源访问日志 (Resource Access Logs)”来监控所有请求和响应。 **步骤 2:** [创建 VPC Lattice 目标组:](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-target-group.html) - 在我们的示例中，日志服务运行在共享服务 VPC 的 EC2 实例上。这是你的 EC2 目标实例。 - 配置协议 HTTP 和端口 5044。 **步骤 3:** [为共享服务 VPC 中的日志服务器创建 VPC Lattice 服务](https://docs.aws.amazon.com/vpc-lattice/latest/ug/services.html#create-service) - 为日志服务器创建一个 VPC Lattice 服务。 - 通过设置监听器和规则定义路由，以定义网络流量在服务内的路由方式。 - 在此案例中，我们设置一个使用协议 HTTP 和端口 5044 的监听器。 - 使用监听器的默认操作转发到目标组。 - 将服务与上面创建的服务网络关联。 **步骤 4:** [为 VPC Lattice 连接 Redis Cache 服务 (TCP) 到服务网络设置 VPC 资源网关](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-resource-gateway.html) 和 [资源配置](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-resource-configuration.html) - 在 IT/共享服务 VPC 中创建一个 VPC 资源网关。 - 关联一个安全组，以控制从 VPC 到服务网络的入站流量。 - 通过指定上面创建的资源网关来创建资源配置。 - 在资源定义下定义 Redis Cache 服务器的 IP 地址和端口 (TCP 6379)。 **步骤 5:** [将上面创建的资源配置与服务网络关联](https://docs.aws.amazon.com/vpc-lattice/latest/ug/resource-configuration-associations.html) - 打开 [Amazon VPC 控制台。](https://console.aws.amazon.com/vpc/) - 在导航窗格中，在 PrivateLink and Lattice 下，选择资源配置。 - 选择资源配置的名称以打开其详细信息页面。 - 选择服务网络关联选项卡。 - 选择创建关联。 - 选择在步骤 1 中创建的服务网络。 - 选择保存更改。 **步骤 6: 配置 DNS (可选)** 默认情况下，VPC Lattice 为每个创建的服务管理唯一的全局 DNS 名称。这些 DNS 名称位于 Amazon Route 53 的公共托管区域。对于此实施，我们已为我们的服务预配置了自定义域名： - 日志服务: logging.example.com - Redis Cache 服务: redis.example.com 此步骤是可选的，仅在你希望使用自己的自定义域名时才需要。如果你选择使用自定义域名，可以在 Route 53 中将 VPC Lattice 管理的域名用作 CNAME 或别名记录。有关详细说明，请参阅 [为 VPC Lattice 服务配置自定义域名](https://docs.aws.amazon.com/vpc-lattice/latest/ug/service-custom-domain-name.html)。 **步骤 7: 创建 AWS Identity and Access Management (IAM) 授权策略：** 使用 IAM 实现零信任认证和授权。创建一个策略，只允许经过认证的访问，要求对服务的请求使用 SIGv4 签名。这种方法使你能够在不通过中央检查 VPC 的情况下，为服务之间配置粒度安全控制。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "o-123456example" ] } } } ] } **步骤 8: 连接验证** #### **针对日志服务的测试：** 使用 curl 操作针对 logging.example.com 进行测试。在步骤 7 中，IAM 授权策略允许任何人进行请求。  图 3: 针对 logging.example.com 的成功 curl 应用 IAM 策略并在不使用凭证的情况下针对 logging.example.com 执行 curl 操作。你无法访问请求，因为你未提供凭证，这会导致访问被拒绝错误，如图 4 所示。  图 4: 针对 logging.example.com 的访问被拒绝 curl #### **针对 Redis Cache 服务的测试：** 同样，针对 redis.example.com 进行成功测试。此域名与我们在服务网络中创建的 Redis Cache 资源关联。你现在可以安全地通过 VPC Lattice 网络连接到共享服务 VPC。  图 5: 针对 redis.example.com 的成功测试 应用 IAM 策略并在不使用凭证的情况下针对 redis.example.com 执行 netcat (nc) 操作。你会得到超时，因为请求缺少凭证。  图 6: 针对 redis.example.com 的失败测试 使用上述 VPC Lattice 方法，我们能够利用 IAM 进行基于身份的认证，并在第 7 层对请求进行认证和授权，而对于第 4 层过滤，我们能够利用关联的安全组来控制服务间流量。 # **3\. 结合架构** 现在，我们探索一种结合策略，其中对于需要深度数据包检查的流量，使用 Network Firewall 的集中式检查方法，而对于其他非关键 TCP 连接和应用层流量 (HTTP)，使用 VPC Lattice 方法。  图 7: 用于 L7-L4 协议的安全服务间通信的结合方法 在此场景中，生产和开发 VPC 中的应用或服务通过 VPC Lattice 服务网络使用 redis.example.com 和 logging.example.com 分别与共享服务 VPC 中的 Redis Cache 服务 (第 4 层) 和集中式日志服务器 (第 7 层) 通信。流量通过与服务网络关联的每个 VPC 中的 VPC Lattice 服务网络端点路由。Transit Gateway 及其附件保持不变，如集中式流量检查部分所述。其他流量，例如与共享服务 VPC 中自管理 MongoDB 的通信 (包含敏感数据，需要防止外泄)，将继续通过 Transit Gateway 和 Network Firewall 的集中式检查路径流动。 这种结合方法确保： 1. 需要深度数据包检查 (DPI) 的关键流量，例如包含敏感数据的 MongoDB 数据库访问，通过集中式检查模式流动。在这里，Network Firewall 可以防止数据外泄，并提供恶意软件检测和 IPS/IDS 功能。 2. 非 DPI 第 4 层连接流量 (如 Redis Cache) 和 HTTP/HTTPS 流量可以通过 VPC Lattice 网络连接。 这种设置维护了 HTTP/HTTPS 服务通信的基于身份的访问控制，并根据安全需求提供优化路由。 ## **结合方法的成本优势：** 将 VPC Lattice 与 Network Firewall 结合的架构与传统集中式检查方法相比，提供显著成本节约。这些节约主要来自三个方面： - 减少 Network Firewall 处理。 - Network Firewall 数据处理成本大幅降低。 - 通过 VPC Lattice 更高效处理 HTTP 和 TCP 流量。 - 成本优势随着流量增加而放大。 - 优化 Transit Gateway 使用。 - 由于 VPC Lattice 流量绕过 TGW，而降低 Transit Gateway 数据处理费用。 - 减少非检查流量的 TGW 附件利用。 - 直接服务间通信消除了不必要的路由。 - 高效资源利用。 - 基于身份的路由消除了复杂网络规则的需求。 - 简化了服务发现和连接管理。 - 减少了维护路由表的操作复杂性。 这种结合方法的成本优势随着流量量的增长而显著增加。因为 Network Firewall 处理成本和 Transit Gateway 数据传输费用会随使用量增加，因此这种架构特别适合具有高服务间通信模式的企业。 要计算你实施的具体成本，请使用以下资源： * [AWS 定价计算器](https://calculator.aws/) * [VPC Lattice 定价](https://aws.amazon.com/vpc/lattice/pricing/) * [Network Firewall 定价](https://aws.amazon.com/network-firewall/pricing/) * [Transit Gateway 定价](https://aws.amazon.com/transit-gateway/pricing/) ## **结论：** 本文展示了如何使用 VPC Lattice 和 Network Firewall 保护你的工作负载。它强调了为需要基于身份控制的 HTTP/HTTPS 服务通信使用 VPC Lattice 的重要性，同时在需要深度数据包检查时采用 Network Firewall。关键点是根据流量类型选择合适的安全控制，平衡安全、性能和成本考虑。通过结合 VPC Lattice 和 Network Firewall 方法，企业可以在 AWS 环境中实现最佳的安全和操作效率。这种策略允许构建一个全面的安全架构，以适应各种通信需求，同时在不同类型网络流量上保持强大保护。 ## **行动号召：** 我们鼓励你使用 VPC Lattice 和 Network Firewall 实施这种结合方法，以提升你的 AWS 网络安全。如果你对本文有疑问，请提交到 [AWS re:Post](https://repost.aws/)。有关更多信息，请参考 [Amazon VPC Lattice，](https://docs.aws.amazon.com/vpc-lattice/) [Network Firewall，](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)，[安全最佳实践，](https://aws.amazon.com/architecture/security-identity-compliance/?cards-all.sort-by=item.additionalFields.sortDate&cards-all.sort-order=desc&awsf.content-type=*all&awsf.methodology=*all) 以及其他 [网络与内容交付博客](https://aws.amazon.com/blogs/networking-and-content-delivery/category/networking-content-delivery/amazon-vpc-lattice/) 文章，涵盖 VPC Lattice。 ## 关于作者  ### Anoop Talluri Anoop Talluri 是 AWS 的解决方案架构师，帮助新上云的 AWS 客户加速云端成果。他拥有超过 8 年的经验，在设计和实施各种网络和云解决方案方面。在业余时间，Anoop 喜欢打羽毛球、徒步旅行、阅读和旅行。 ###  SaiJeevan Devireddy SaiJeevan Devireddy 是 AWS 的资深解决方案架构师，与战略账户合作。他热衷于帮助客户在 AWS 上构建高度可用系统。 <!-- AI_TASK_END: AI全文翻译 -->