[解决方案] 使用 Network Firewall Proxy 保障出口架构安全

**发布时间:** 2025-11-25 **厂商:** AWS **类型:** BLOG **原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/securing-egress-architectures-with-network-firewall-proxy/ --- <!-- AI_TASK_START: AI标题翻译 --> [解决方案] 使用 Network Firewall Proxy 保障出口架构安全 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析：使用AWS Network Firewall Proxy保护Egress架构 ## 解决方案概述 该解决方案介绍了一项新的AWS托管服务 **AWS Network Firewall Proxy**，旨在简化和增强云中出站（Egress）流量的安全性。它解决了客户在管理基于 **EC2** 或容器的 **自建代理集群** 时面临的部署、扩展和补丁管理的复杂性。通过将代理功能作为一项完全托管的服务，AWS使用户能够专注于安全策略的制定，而非底层基础设施的运维。 该方案适用于需要对VPC内部工作负载访问互联网、其他AWS环境或本地数据中心进行精细化控制和审计的场景。其技术核心是作为一个 **显式代理 (Explicit Proxy)**，与 **NAT Gateway** 服务深度集成进行IP地址转换，并通过 **AWS PrivateLink** 提供VPC接口端点，确保客户端可以安全、私密地连接到代理服务。 ## 技术原理与工作流程 AWS Network Firewall Proxy 对网络流量进行显式检查。应用程序需配置为向代理发送 `HTTP CONNECT` 请求，代理随后代表应用程序建立到目标的新连接，并在此过程中执行多阶段检查。 - **多阶段检查流程:** 代理按以下顺序在三个不同阶段检查流量： 1. **PreDNS:** 在代理为目标域进行DNS解析之前应用。用于基于域名的早期过滤。 2. **PreRequest:** 在代理向目标服务器发送HTTP请求之前应用。可检查HTTP头部等信息。 3. **PostResponse:** 在代理从目标服务器收到HTTP响应后应用。可检查响应内容。 - **TLS 拦截 (TLS Interception):** 解决方案提供两种TLS处理模式： - **启用TLS拦截:** 代理终止来自工作负载的TLS会话，并与目标建立新的TLS会话。它会动态生成目标证书并呈现给客户端，因此客户端必须信任由 **AWS Private Certificate Authority (PCA)** 管理的代理CA证书。此模式下，代理可以解密并检查HTTPS流量的完整内容。 - **禁用TLS拦截:** 代理仅在TCP层建立两个独立的连接，而TLS握手直接在工作负载和目标之间进行，形成端到端加密隧道。此模式下，代理无法检查加密内容，只能基于DNS、IP地址或SNI等未加密元数据执行策略。 ## 实施步骤 1. **创建并配置代理策略 (Proxy Configuration):** - 在VPC控制台中创建 **代理规则组 (Proxy rule groups)**。 - 在规则组中定义具体的过滤规则，每个规则包含匹配条件（如域名、请求头）、操作（**allow, deny, alert**）和优先级。规则按优先级顺序进行评估。 - 将一个或多个规则组整合到一个 **代理配置 (Proxy Configuration)** 中，并为每个检查阶段（PreDNS, PreRequest, PostResponse）设置默认操作。 2. **创建代理并建立信任关系:** - 使用上一步创建的 **Proxy Configuration** 和一个已有的 **NAT Gateway** 来创建代理实例。 - 创建过程中，一个 **PrivateLink 端点** 会自动在NAT Gateway所在的子网中生成。 - （可选）若要启用TLS拦截，需使用 **AWS Private Certificate Authority (PCA)** 创建或导入一个私有从属CA，并确保客户端操作系统或应用程序的信任存储中包含该CA的根证书。 3. **配置客户端应用程序:** - 由于是 **显式代理**，需要修改应用程序或操作系统的配置，使其将HTTP/HTTPS流量指向代理的私有DNS名称和端口。 - 例如，在Linux环境中，可以通过设置 `https_proxy` 和 `http_proxy` 环境变量来完成配置。 ## 架构模式与部署选项 - **访问模式:** - 任何能够连接到代理VPC端点的工作负载（无论是在本地VPC、远程VPC还是本地环境）都可以使用该代理服务。 - **多VPC连接模型:** - **分布式模型:** 在每个VPC中都部署一个独立的Network Firewall Proxy和NAT Gateway。此模型隔离性好但成本较高。 - **集中式模型 (端点模式):** 在一个中央VPC中部署代理，其他VPC通过在各自VPC内创建 **PrivateLink端点** 来访问该中央代理。这是在没有Transit Gateway或Cloud WAN时的推荐模式，简化了路由配置。 - **集中式模型 (路由模式):** 使用 **AWS Transit Gateway** 或 **AWS Cloud WAN** 将多个VPC的流量路由到部署了代理的中央出口VPC。当环境中已存在TGW或Cloud WAN时，此模型能更好地优化端点成本。 - **混合流量模型:** 结合代理和传统路由检测。使用代理端点处理 **HTTP/HTTPS** 流量，同时使用Transit Gateway将 **非HTTP流量** 路由到传统的 **AWS Network Firewall** 进行检测，实现对不同协议流量的差异化安全控制。 ## 方案客户价值 - **简化运维:** 作为一项 **完全托管服务**，它为客户免去了部署、扩展、打补丁和维护代理服务器集群的运营负担，显著降低了管理开销。 - **集中化策略管理:** 通过 **代理配置 (Proxy Configuration)** 和可共享的 **规则组 (Rule Groups)**，实现了安全策略的集中定义、版本控制和跨账户共享，提升了治理效率。 - **精细化访问控制:** 提供基于 **多阶段（PreDNS, PreRequest, PostResponse）** 的流量检测，并支持 **TLS解密**，实现了对HTTP/HTTPS流量的深度内容检查和精细化控制，远超传统基于IP/端口的过滤。 - **灵活的网络架构:** 原生支持分布式、集中式以及混合流量等多种架构模式，能够无缝融入客户现有的AWS网络拓扑，满足不同规模和复杂度的需求。 - **云原生集成:** 与 **NAT Gateway**, **AWS PrivateLink**, 和 **AWS Private Certificate Authority** 等关键AWS服务深度集成，提供了一个无缝、安全且高可用的云原生出站安全解决方案。 ## 涉及的相关产品 - **AWS Network Firewall:** 该代理功能是其一部分。 - **NAT Gateway:** 代理与NAT Gateway绑定，用于提供互联网出口和IP地址转换。 - **AWS PrivateLink:** 为代理提供VPC接口端点，实现跨VPC的安全私有连接。 - **AWS Private Certificate Authority (PCA):** 用于管理TLS拦截所需的CA证书。 - **Amazon VPC:** 所有组件部署的基础网络环境。 - **AWS Transit Gateway / AWS Cloud WAN:** 用于构建集中式出站安全架构的可选网络组件。 ## 技术评估 - **优势:** - **托管与自动化:** 核心优势在于其托管特性，将客户从繁琐的代理基础设施管理中解放出来，专注于安全策略本身。 - **深度集成:** 与AWS网络生态系统无缝集成，简化了架构设计和部署，提供了比第三方虚拟设备更原生的体验。 - **高级检测能力:** 多阶段检测模型和原生的TLS解密功能提供了强大而灵活的流量控制能力。 - **高可用与可扩展性:** 作为AWS托管服务，继承了其高可用和按需自动扩展的特性，无需客户手动规划容量。 - **限制与考量:** - **预览阶段:** 该功能目前处于 **预览 (Preview)** 阶段，可能不适合所有生产环境，其功能和API未来可能发生变化。 - **协议支持:** 目前仅支持 **HTTP/HTTPS** 流量。非HTTP流量需要结合其他解决方案（如传统的Network Firewall路由模式）进行处理。 - **显式代理模式:** 应用程序需要感知并配置代理，无法对应用实现透明代理。这可能需要对现有应用或部署流程进行调整。 - **仅支持IPv4:** 文档提及，预览版仅支持IPv4。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 使用网络防火墙代理保护出站架构 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/securing-egress-architectures-with-network-firewall-proxy/](https://aws.amazon.com/blogs/networking-and-content-delivery/securing-egress-architectures-with-network-firewall-proxy/) **发布时间:** 2025-11-25 **厂商:** AWS **类型:** BLOG --- 使用自行管理的代理来控制其 AWS 环境出站访问的客户，常常发现部署、扩展和修补其基于 EC2 或容器的代理集群是一项挑战。随着最近 [AWS 网络防火墙代理 (AWS Network Firewall proxy)](https://docs.aws.amazon.com/network-firewall/latest/developerguide/network-firewall-proxy-developer-guide.html) 预览版的发布，AWS 承担了代理管理和部署的繁重工作，让客户可以专注于控制其 VPC 出站访问的安全策略。 在这篇博客文章中，我们将介绍该代理的工作原理及其设置步骤。文章还将讨论代理的网络连接选项和各种架构模式。该代理在流量被允许到达互联网、AWS 甚至本地环境中的目标之前对其进行过滤。 ## 代理连接组件 网络防火墙代理直接与在 VPC 内运行的 NAT 网关 (NAT Gateway) 服务集成，负责出站流量的 IP 地址转换。您的应用程序可以使用由 [AWS Private Link](https://aws.amazon.com/privatelink/) 提供支持的代理专用 VPC 接口终端节点 (VPC interface endpoint)，从本地或远程 VPC 访问该代理。图 1 描述了参与流量转发的组件及其功能。  图 1. 代理组件 ## 网络防火墙代理如何检查我的流量？ 网络防火墙代理为您的网络流量提供显式检查。也就是说，您需要设置应用程序向代理发送 HTTP CONNECT 请求，代理会代表应用程序与所需目标建立新连接，同时在多个阶段执行检查。对于明文 HTTP 请求，代理还支持处理 [HTTP 请求的绝对形式 (absolute-form of the HTTP request)](https://datatracker.ietf.org/doc/html/rfc7230#page-42) 。 代理总共在以下三个不同阶段按顺序检查您的流量： - **DNS 解析前 (PreDNS)** – 在代理尝试为目标域解析 DNS 之前应用 - **请求前 (PreRequest)** – 在代理向目标服务器发送 HTTP 请求之前应用 - **响应后 (PostResponse)** – 在代理从目标服务器接收到 HTTP 响应之后应用 每个阶段的评估都是数据包流中的一个步骤，允许代理管理员应用访问规则。如果较早的阶段阻止了流量，则后续阶段不会被触发。图 2 描述了 TCP 连接建立、HTTP 请求和响应流程，以及每个检查阶段的位置。  图 2. 通过代理的 TCP 连接和请求流程 1. 工作负载与代理建立 TCP 连接 2. 工作负载发送一个 HTTP CONNECT 消息，以表明它希望通过代理连接到特定目标 3. 代理首先评估 **DNS 解析前** 策略，如果域名被允许，它将使用 VPC 指定的 DNS 解析器执行 DNS 解析以获取目标的 IP 地址 4. 代理与返回的目标 IP 地址建立 TCP 连接 5. 代理向工作负载发送 HTTP 响应，表明到目标的连接已建立 6. 工作负载向代理发送针对先前包含在 CONNECT 请求中相同域名的 HTTP GET 请求 7. 代理评估 **请求前** 策略以验证请求是否应被允许 8. 如果请求被允许，代理向目标发送自己的 GET 请求 9. 目标返回相应的详细信息 10. 代理使用 **响应后** 策略评估响应 11. 如果响应被允许，代理将响应负载发送给工作负载 网络防火墙代理可以配置为拦截 TLS 或允许 TLS 原封不动地通过。当 **启用 TLS 拦截 (TLS interception)** 时，代理会终止来自工作负载的 TLS 会话，并向目标发起一个新的 TLS 会话。为此，代理会代表真实目标生成一个证书并将其呈现给工作负载。要使其正常工作，工作负载必须信任代理的证书颁发机构；建立该信任的过程将在后续章节中介绍。启用拦截后，代理可以检查 HTTP 层的内容并应用细粒度的策略。 当 **禁用 TLS 拦截** 时，代理仍然会创建两个独立的 TCP 连接——一个在工作负载和代理之间，另一个在代理和目标之间。然而，TLS 握手直接在工作负载和目标之间发生，从而创建了一个端到端加密隧道。在这种模式下，代理无法解密或检查加密的负载，只能基于未加密的元数据 (如 DNS、IP 地址或 SNI) 来执行策略。 图 3 说明了启用和禁用 TLS 拦截的流程差异。  图 3. 启用和禁用 TLS 拦截的代理流程对比 ## 快速入门 概括地说，您可以按照以下三个步骤设置网络防火墙代理： 1. **创建并填充代理配置**：代理配置允许您按照期望的实施优先级来配置过滤规则。 2. **创建代理并 [可选] 与客户端建立信任**：使用步骤 1 中创建的代理配置来创建代理。您还需要一个现有的 NAT 网关与代理集成。可选地，要执行 TLS 检查，您必须在代理和客户端之间建立信任。 3. **配置您的客户端以使用代理**：您需要明确配置您的客户端以使用网络防火墙代理。 #### **步骤 1：创建网络防火墙代理配置** 代理配置 (Proxy Configuration) 是一个顶层容器，您可以在其中配置所有希望应用于流量的过滤规则。您可以将这些规则放在称为规则组 (rule groups) 的可共享容器中，并按期望的优先级排序。 要创建代理配置，首先导航到 **Amazon VPC 控制台**，在导航窗格下选择 **代理规则组**。然后创建一个规则组，为其命名并填充过滤规则。规则语言模仿了代理在不同阶段的过滤行为。  图 4. 规则组中不同流量阶段的规则条目 您可以通过选择不同的条件键和运算符，然后输入适当的匹配值来定义匹配条件。  图 5. 规则的示例匹配标准 您可以为单个规则创建多个匹配条件。有关条件键选项和过滤规则示例的详细信息，请参阅 [文档](https://docs.aws.amazon.com/network-firewall/latest/developerguide/managing-your-proxy-rules.html#proxy-rule-structure) 。只有当所有条件都匹配时，规则才会被执行。您可以使用这些条件来创建细粒度的、特定于源的规则。定义匹配条件后，您可以选择操作——允许 (allow)、拒绝 (deny) 或警报 (alert)——然后创建规则。 您可以在一个规则组中创建多达一千条规则，并按期望的优先级排列它们。网络防火墙代理按优先级顺序依次评估规则。规则根据其插入位置进行处理，数字越小优先级越高。在每个阶段内，评估会持续进行，直到找到第一个匹配的规则。当规则匹配时，结果遵循严格的模式： - **拒绝** 操作会立即阻止流量并终止所有后续的规则处理。 - **允许** 操作会结束当前阶段的处理，但仍需要在后续阶段进行评估。 - **警报** 操作会记录事件并允许评估继续进行。  图 6. 在规则组中为不同规则设置优先级 您可以创建多个规则组并存储它们。公司中的不同组织单位可以创建特定于自己单位的规则组，并与您共享以在代理上实施。 您可以将不同的规则组整合到一个网络防火墙代理配置中。创建代理配置时，您必须为每个阶段选择默认操作。当所有规则组中的规则都与流量不匹配时，将应用默认操作。  图 7. 创建代理配置并为不同阶段设置默认操作 定义默认操作后，您可以附加不同的规则组及其相对优先级。  图 8. 将规则组附加到代理配置 然后，您可以在一个地方查看所有规则组并创建网络防火墙代理配置。 #### **步骤 2：使用代理配置创建网络防火墙代理** 除了代理配置，您还需要账户中有一个 NAT 网关来完成设置。您可以在代理控制台中关联代理配置和选定的 NAT 网关。在关联过程中，代理终端节点会自动在 NAT 网关的子网中创建。  图 9. 使用代理配置和 NAT 网关创建代理 在创建工作流中，您还需要选择是否要在代理中启用 TLS 模式。要启用 TLS 拦截，您必须在客户端和代理之间建立信任。一旦您的客户端信任由代理生成的转发证书，代理就可以解密您的流量。 要建立信任，您必须将您的企业证书颁发机构 (CA) 的根证书导入到您的操作系统或应用程序的信任存储 (trust store) 中。然后，您的客户端将信任所有由链接到您企业 CA 的从属 CA (subordinate CAs) 签名的证书。 要使用代理，您可以使用现有的企业 CA 签署一个由 AWS Private Certificate Authority 管理的私有从属 CA 证书。有关导入外部签名 CA 证书的更多详细信息，请参阅 AWS 文档。 或者，您可以使用 AWS PCA 创建根 CA 或从属 CA。有关详细的设置说明，请参阅文档。您的代理使用此从属 CA 签署它代表目标服务器自动生成的所有证书，这些证书随后会发送给客户端以建立信任。 #### **步骤 3：配置应用程序以使用网络防火墙代理** 网络防火墙代理是一个显式代理，这意味着您不需要设置路由规则来将流量转发到代理。相反，您必须明确配置您的工作负载，以便任何 HTTP/HTTPS 通信都使用代理终端节点。根据所使用的操作系统或应用程序，配置工作负载以使用显式代理的方式可能有所不同。例如，Linux 使用环境变量将流量发送到代理： ``` export https_proxy="https://proxy_host:proxy_port" export http_proxy="https://proxy_host:proxy_port" ``` 无论是否启用 TLS 拦截，向网络防火墙代理发出的 HTTP CONNECT 请求都可以通过 HTTP 或 HTTPS 进行，具体取决于您的终端节点配置。使用 HTTPS 时，初始连接利用了代理终端节点的亚马逊公共证书，该证书由 ACM 签名并受标准信任存储的信任。 您可以在代理控制台的“私有 DNS 名称”和“侦听器属性”下找到您的代理主机名以及 HTTP 和 HTTPS 端口，如图 10 所示。  图 10. 代理主机名和侦听器端口 当代理被创建并附加到 NAT 网关时，网络防火墙会 **自动** 在与 NAT 网关相同的子网中创建一个 PrivateLink 终端节点。 对于与代理在同一 VPC 中的工作负载，不需要额外的终端节点。 对于其他 VPC 中的工作负载，您只需在每个无法直接路由到代理终端节点的 VPC 中创建一个 PrivateLink 终端节点。 私有子网也不需要指向互联网的默认路由来通过代理发送流量——它们只需要能够访问代理终端节点，该终端节点使用来自 VPC CIDR 范围的 IP 地址。(预览版仅支持 IPv4。) 图 11 显示了单个 VPC 的示例路由配置。  图 11. 网络防火墙代理访问 现在我们知道了如何设置网络防火墙代理并将其与您的应用程序一起使用，接下来的部分将讨论客户可以使用的不同架构和部署模式。 ## 代理访问模式 网络防火墙代理可用于保护来自本地 VPC、远程 VPC 甚至本地源的流量。只要您的工作负载能够连接到代理终端节点，它就可以使用代理服务。请注意，流量只能通过终端节点到达代理。如果您只是将流量路由到 NAT 网关，它不会对其应用代理策略。 因为代理附加到 NAT 网关，所以它可以到达与 NAT 网关相同的目标。这包括互联网上、本地环境或甚至其他 VPC 中的目标。图 12 显示了流量源和目标的示例。  图 12. 代理的源与目标 ## 多 VPC 连接选项 就像使用 NAT 网关的网络模式一样，您可以选择分布式或集中式地部署您的代理连接。在分布式模型中，您在每个 VPC 中都部署一个带有代理的 NAT 网关。  图 13. 分布式代理模型 客户通常更喜欢集中式模型，以优化成本并更好地利用 NAT 网关和代理。在集中式模型中，您可以通过代理终端节点在多个 VPC 之间共享单个 NAT 网关和代理。或者，您可以使用像 AWS Transit Gateway 或 AWS Cloud WAN 这样的网络结构，将来自多个 VPC 的流量路由到一个中央代理终端节点。 图 14 显示了通过代理终端节点的集中式出站连接。因为终端节点由 PrivateLink 提供支持并托管在每个 VPC 内部，所以不需要额外的路由配置。需要访问代理的流量会连接到每个 VPC 中的本地终端节点 IP 地址。  图 14. 通过代理终端节点的集中式出站代理 与终端节点模型相比，通过 AWS Cloud WAN 或 AWS Transit Gateway 集中出站流量需要更新参与的 VPC 和连接组件中的路由表，以确保所有客户端都能到达出口 VPC (egress VPC) 中的代理终端节点。这些模型之间的选择通常取决于成本考虑以及是否已存在 Transit Gateway 或 Cloud WAN 部署。如果没有此类基础设施，客户应使用终端节点模型。当 Transit Gateway 或 Cloud WAN 已经是架构的一部分时，可以利用它们来集中出站流量并优化终端节点的小时成本。  图 15. 使用 AWS Cloud WAN 或 AWS Transit Gateway 的集中式出站 目前，代理仅支持处理 HTTP/HTTPS 流量。如果您想将这些流量的代理与处理非 HTTP 流量的另一个安全解决方案结合起来，您可以在同一架构中结合代理模型和路由模型。代理通过终端节点访问并用于 HTTP 流量，而 Transit Gateway 或 Cloud WAN 用于路由非 HTTP 流量。图 16 显示了一个组合模型，其中 HTTPS 流量使用代理，而非 HTTPS 流量使用传统的 AWS 网络防火墙进行防火墙保护。  图 16. 代理流量与非代理流量的组合 该模型以两种不同的模式使用 NAT 网关。首先，它接收已经由 AWS 网络防火墙 (或使用 Gateway Load Balancer 的其他网关模式安全解决方案) 检查过的路由流量。这种路由流量不经过代理。另外，NAT 网关还接收由代理转发的代理流量，而代理又通过来自多个 VPC 的终端节点接收该流量。只有通过代理终端节点路径到达的流量才会受到代理功能的影响。 ## 结论 在这篇博客文章中，我们介绍了目前处于预览阶段的 AWS 网络防火墙代理服务的部署细节。我们分享了如何设置您的第一个代理、配置规则，以及探讨了不同的网络架构模式，以帮助您保护出站流量。要测试该功能并设置您的第一个代理，请遵循 [文档](https://docs.aws.amazon.com/network-firewall/latest/developerguide/network-firewall-proxy-developer-guide.html) 中的说明。 ## 关于作者  ### Tom Adamski Tom 是一位专注于网络和安全的首席解决方案架构师。他在不同行业 (从电信公司和 ISP 到小型初创公司) 拥有超过 15 年的构建网络和安全解决方案的经验。在过去的 8 年里，他一直帮助 AWS 客户在 AWS 云中构建他们的网络环境。在业余时间，Tom 会在加州海岸寻找可以冲浪的海浪。  ### Akshay Choudhry Akshay 是亚马逊云科技网络和安全服务团队的首席产品经理。他致力于让数百万在 AWS 上运行工作负载的客户的虚拟私有云变得更直观、更安全。在业余时间，他喜欢探索户外、尝试新餐厅以及与朋友和家人共度时光。 <!-- AI_TASK_END: AI全文翻译 -->