Azure：面向虚拟网络的防火墙和应用程序网关

若要保护 Azure 应用程序工作负载，可以在应用程序本身使用保护措施，例如身份验证和加密。 还可以将安全层添加到托管应用程序的 (VM) 虚拟机。 层保护来自用户的入站流。 它们还保护应用程序可能需要的到 Internet 的出站流。 本文介绍 Azure 虚拟网络 安全服务（例如 Azure 防火墙 和 Azure 应用程序网关、何时使用每个服务）以及组合两者的网络设计选项。

• Azure 防火墙托管的下一代防火墙，它通过 NAT (网络地址) 。 Azure 防火墙基于 Internet 协议 (IP) 地址以及传输控制协议和用户数据报协议 (TCP/UDP) 端口，或基于应用程序的 HTTP (S) 或 SQL 属性进行数据包筛选。 Azure 防火墙 Microsoft 威胁情报来识别恶意 IP 地址。 有关详细信息，请参阅 Azure 防火墙 文档。

• Azure 防火墙 高级版包括标准Azure 防火墙的所有功能以及其他功能，例如 TLS 检查和入侵检测和保护系统 (IDPS) 。

• Azure 应用程序网关 托管 Web 流量负载均衡器以及 HTTP (S) 完全反向代理，可以执行安全套接字层 (SSL) 加密和解密。 应用程序网关还使用 Web 应用程序防火墙来检查 Web 流量并检测 HTTP 层上的攻击。 有关详细信息，请参阅应用程序 网关文档。

• Azure Web 应用程序防火墙 (WAF) 是一项可选添加Azure 应用程序网关。 它提供对 HTTP 请求的检查，并防止 Web 层上的恶意攻击，例如SQL注入或跨站点脚本。 有关详细信息，请参阅 Web 应用程序防火墙文档。

这些 Azure 服务是互补的。 其中一种可能最适合工作负荷，也可以将它们一起用于网络层和应用程序层的最佳保护。 使用以下决策树和本文中的示例来确定应用程序虚拟网络的最佳安全选项。

Azure 防火墙Azure 应用程序网关使用不同的技术，并且它们支持不同流的安全化：

根据应用程序所需的网络流，设计可能因应用程序不同而不同。 下图提供了一个简化的决策树，可帮助选择应用程序的建议方法。 决策取决于应用程序是通过 HTTP (S) 还是某些其他协议发布：

本文将介绍流程图中广泛推荐的设计，以及适用于不太常见方案其他设计：

• Azure 防火墙虚拟网络中不存在 Web 应用程序时，单独使用 。 它将控制到应用程序的入站流量和出站流量。

• 仅应用程序网关，当只有 Web 应用程序在虚拟网络中，并且网络安全组 (NSG ) 提供足够的输出筛选。 通常不建议使用此方案，因为 NSG 上具有Azure 防火墙功能。 该功能可以防止许多攻击 (例如数据外泄) ，因此，上述流程图中未记录此方案。

• Azure 防火墙应用程序网关并行运行，这是最常见的设计之一。 当你希望保护 HTTP Azure 应用程序网关 S (应用程序) Web 攻击，Azure 防火墙保护所有其他工作负荷并筛选出站流量时，请使用此组合。

• 应用程序网关位于Azure 防火墙，当你想要Azure 防火墙检查所有流量时，WAF 用于保护 Web 流量，应用程序知道客户端的源 IP 地址。 通过Azure 防火墙 高级版和 TLS 检查，此设计还支持端到端 SSL 方案。

• Azure 防火墙网关的前面，Azure 防火墙在流量到达应用程序网关之前检查和筛选流量。 由于Azure 防火墙不会解密 HTTPS 流量，因此它添加到应用程序网关的功能会受到限制。 此方案未记录在以上流程图中。

本文的最后一部分介绍了以前基本设计的变体。 这些变体包括：

• 本地应用程序客户端。

• 中心和分支网络。

• Azure Kubernetes 服务 (AKS) 实现。

可以添加其他反向代理服务，例如 API Management网关或 Azure Front Door。 或者，可以将 Azure 资源替换为第三 方网络虚拟设备。

Azure 防火墙仅

如果虚拟网络中没有任何可受益于 WAF 的基于 Web 的工作负荷，则只能Azure 防火墙。 在这种情况下，设计很简单，但查看数据包流将有助于了解更复杂的设计。

下表总结了此方案的流量流：

Azure 防火墙不会检查入站 HTTP (S) 流量。 但它将能够应用 L3/L4 规则和基于 FQDN 的应用程序规则。 Azure 防火墙检查出站 HTTP (S) 流量，具体取决于Azure 防火墙层以及是否配置 TLS 检查：

• Azure 防火墙标准仅检查网络规则中数据包的 3-4 层属性，以及应用程序规则中的主机 HTTP 标头。

• Azure 防火墙 高级版添加一些功能，例如检查其他 HTTP 标头 (如用户代理) 启用 TLS 检查，以便进行更深入的数据包分析。 Azure 防火墙不等同于 Web 应用程序防火墙。 如果虚拟网络中具有 Web 工作负载，强烈建议使用 WAF。

下面的数据包演练示例演示客户端如何从公共 Internet 访问 VM 托管的应用程序。 为简单起见，该图仅包含一个 VM。 为了提高可用性和可伸缩性，负载均衡器后面会有多个应用程序实例。

1. 客户端启动与客户端的公共 IP 地址Azure 防火墙：

• 源 IP 地址：ClientPIP

• 目标 IP 地址：AzFwPIP

• 源 IP 地址：192.168.100.7

• 目标 IP 地址：192.168.1.4

• 源 IP 地址：192.168.1.4

• 目标 IP 地址：192.168.100.7

• 源 IP 地址： AzFwPIP

• 目标 IP 地址： ClientPIP

在此设计中，Azure 防火墙使用 UDR 检查来自公共 internet 的传入连接和来自应用程序子网 VM 的出站连接。

• IP 地址 192.168.100.7 是 Azure 防火墙服务在其中部署的一个实例，其中包含前端 IP 地址 192.168.100.4 。 Azure 管理员通常不会看到这些单独的实例。 但请注意，在某些情况下，这种区别很有用，例如，在对网络问题进行故障排除时。

• 如果流量来自本地虚拟专用网络 (VPN) 或 Azure ExpressRoute 网关而不是 internet，则客户端将启动到 VM 的 IP 地址的连接。 它不会启动与防火墙的 IP 地址的连接，并且每个默认情况下，防火墙将不执行源 NAT。

仅应用程序网关

此设计涵盖了虚拟网络中仅存在 web 应用程序的情况，并且通过 Nsg 检查出站流量足以保护出站流到 internet。

 备注

这不是一种建议的设计，因为使用 Azure 防火墙来控制出站流 (而不是仅 Nsg) 将阻止某些攻击方案，例如 data 渗透，这会确保工作负荷仅将数据发送到已批准的 Url 列表。

与以前的设计相比，只有 Azure 防火墙的主要区别是，应用程序网关不能充当带有 NAT 的路由设备。 它表现为完整的反向应用程序代理。 也就是说，应用程序网关会从客户端停止 web 会话，并使用其后端服务器之一建立单独的会话。

下表汇总了流量流：

以下数据包审核示例演示客户端如何从公共 internet 访问 VM 托管的应用程序。

1. 客户端开始连接到 Azure 应用程序网关的公共 IP 地址：

• 源 IP 地址： ClientPIP

• 目标 IP 地址： AppGwPIP

• 源 IP 地址： 192.168.200.7 (应用程序网关实例的专用 IP 地址)

• 目标 IP 地址：192.168.1。4

• X 转发的标头： ClientPIP

• 源 IP 地址：192.168.1。4

• 目标 IP 地址：192.168.200。7

• 源 IP 地址： AppGwPIP

• 目标 IP 地址： ClientPIP

Azure 应用程序网关会将元数据添加到数据包 HTTP 标头，如包含原始客户端 IP 地址的 X 转发的 标头。 某些应用程序服务器需要源客户端 IP 地址来提供地理位置特定的内容，或用于日志记录。 有关详细信息，请参阅应用程序网关的工作原理。

• IP 地址 192.168.200.7 是 Azure 应用程序网关服务在其中部署的一个实例，其中包含前端 IP 地址 192.168.200.4 。 Azure 管理员通常不会看到这些单独的实例。 但请注意，在某些情况下，这种区别很有用，例如，在对网络问题进行故障排除时。

• 如果客户端来自于 VPN 或 ExpressRoute 网关的本地网络，则流类似。 不同之处在于，客户端访问应用程序网关的专用 IP 地址，而不是公共地址。

防火墙和应用程序网关并行

由于其简易性和灵活性，并行运行应用程序网关和 Azure 防火墙通常是最佳方案。

如果在虚拟网络中混合使用 web 工作负载和非 web 工作负载，则可实现此设计。 Azure WAF 保护发往 web 工作负荷的入站流量，Azure 防火墙将检查其他应用程序的入站流量。 Azure 防火墙将涵盖这两种工作负荷类型的出站流。

下表总结了这种情况下的流量：

此设计比 Nsg 提供更精细的出口筛选。 如果应用程序需要连接到特定的 Azure 存储帐户，则可以使用 完全限定的域名 (基于 FQDN) 的筛选器。 对于基于 FQDN 的筛选器，应用程序不会将数据发送到恶意存储帐户。 只能使用 Nsg 阻止该方案。 此设计通常用于出站流量需要基于 FQDN 的筛选的位置。 一个例子就是 限制来自 Azure Kubernetes 服务群集的出口流量。

下图说明了来自外部客户端的入站连接的流量流：

下图说明了从网络 Vm 到 internet 的出站连接的流量流。 例如，连接到后端系统或获取操作系统更新：

每个服务的数据包流步骤与以前的独立设计选项相同。

防火墙之前的应用程序网关

在此选项中，入站 web 流量通过 Azure 防火墙和 WAF。 WAF 提供 web 应用程序层保护。 Azure 防火墙充当中心日志记录和控制点，并检查应用程序网关和后端服务器之间的流量。 应用程序网关和 Azure 防火墙并不并行，而是另一个。

利用azure 防火墙高级版，这种设计可以支持端到端方案，在此方案中，Azure 防火墙应用 TLS 检查来对应用程序网关和 web 后端之间的加密流量进行 idp。

此设计适用于需要了解传入客户端源 IP 地址的应用程序，例如，用于提供地理位置特定的内容或用于日志记录。 Azure 防火墙 SNATs 传入流量，从而更改原始源 IP 地址。 Azure 防火墙前面的应用程序网关在 X 转发 的标头中捕获传入数据包的源 IP 地址，以便 web 服务器可以在此标头中看到原始 IP 地址。 有关详细信息，请参阅应用程序网关的工作原理。

下表总结了此方案的流量流：

对于从本地或 Internet 到 Azure 的 Web 流量，Azure 防火墙将检查 WAF 已允许的流。 根据应用程序网关是否加密后端流量 (从应用程序网关到应用程序服务器) 流量，你将有两种不同的可能方案：

1. 应用程序网关按照零信任原则加密流量 (端到端 TLS 加密) ，Azure 防火墙接收加密的流量。 不过，Azure 防火墙标准版将能够应用检查规则，例如网络规则中的 L3/L4 筛选，或者使用 TLS 服务器名称指示 (SNI) 标头在应用程序规则中筛选 FQDN。 Azure 防火墙 高级版IDPS 提供更深入的可见性，例如基于 URL 的筛选。

2. 如果应用程序网关将未加密的流量发送到应用程序服务器，Azure 防火墙将看到以纯文本格式的入站流量。 在中不需要 TLS Azure 防火墙。

3. 如果 IDPS 在 Azure 防火墙中启用，它将验证 HTTP 主机标头是否与目标 IP 匹配。 为此，它将需要主机标头中指定的 FQDN 的名称解析。 此名称解析可以通过使用 Azure DNS 专用区域 和默认 Azure 防火墙 DNS 设置Azure DNS。 此外，还可通过自定义 DNS 服务器实现此目的，这些服务器需要在设置Azure 防火墙配置。 (有关详细信息，请参阅 Azure 防火墙 DNS设置.) 如果没有对部署 Azure 防火墙 的虚拟网络的管理访问权限，则只能使用后一种方法。 例如，在虚拟 WAN 安全中心部署 Azure 防火墙。

对于流的其余部分 (入站非 HTTP (S) 流量和任何出站流量) ，Azure 防火墙 将在适当的时候提供 IDPS 检查和 TLS 检查。 它还在基于 DNS 的网络规则中提供基于 FQDN 的筛选。

来自公共 Internet 的网络流量遵循以下流程：

1. 客户端启动与客户端的公共 IP 地址Azure 应用程序网关：

• 源 IP 地址：ClientPIP

• 目标 IP 地址：AppGwPIP

• 源 IP 地址：192.168.200.7 (应用程序网关实例实例的专用 IP)

• 目标 IP 地址：192.168.1.4

• X-Forwarded-For 标头：ClientPIP

• 源 IP 地址：192.168.200.7 (应用程序网关实例实例的专用 IP)

• 目标 IP 地址：192.168.1.4

• X-Forwarded-For 标头：ClientPIP

• 源 IP 地址：192.168.1.4

• 目标 IP 地址：192.168.200.7

• 源 IP 地址：192.168.1.4

• 目标 IP 地址：192.168.200.7

• 源 IP 地址：AppGwPIP

• 目标 IP 地址：ClientPIP

从 VM 到公共 Internet 的出站流Azure 防火墙 UDR 定义的到 0.0.0.0/0 。

防火墙后的应用程序网关

此设计Azure 防火墙在恶意流量到达应用程序网关之前进行筛选和丢弃。 例如，它可以应用基于威胁情报的筛选等功能。 另一个好处是，应用程序为入站和出站流量获取相同的公共 IP 地址。

此方案的好处有限，因为Azure 防火墙只会看到发到应用程序网关的加密流量。 在某些情况下，此设计是首选。 例如，如果网络服务器中较早有另一个 WAF (，则Azure Front Door) 。 或者，如果需要多个公共 IP 地址，则设计是首选。

下表总结了此方案的流量流：

对于入站 HTTP (S) 流量，Azure 防火墙通常不会解密流量。 而是应用不需要 TLS 检查的 IDPS 策略，例如基于 IP 的筛选或 HTTP 标头。

应用程序看不到 Web 流量的原始源 IP 地址;Azure 防火墙数据包进入虚拟网络时进行 SNAT。 若要避免此问题，请使用 Azure Front Door 前面的防火墙。 Azure Front Door在客户端进入 Azure 虚拟网络之前，将客户端的 IP 地址作为 HTTP 标头注入。

来自公共 Internet 的网络流量遵循以下流程：

1. 客户端启动与客户端的公共 IP 地址Azure 防火墙：

• 源 IP 地址：ClientPIP

• 目标 IP 地址：AzFWPIP

• 源 IP 地址：192.168.100.7 (实例的专用 IP Azure 防火墙地址)

• 目标 IP 地址：192.168.200.4

• 源 IP 地址：192.168.200.7 (应用程序网关实例实例的专用 IP)

• 目标 IP 地址：192.168.1.4

• X-Forwarded-For 标头：192.168.100.7

• 源 IP 地址：192.168.1.4

• 目标 IP 地址：192.168.200.7

• 源 IP 地址：192.168.200.4

• 目标 IP 地址：192.168.100.7

• 源 IP 地址：AzFwPIP

• 目标 IP 地址：ClientPIP

即使应用程序网关没有为应用程序配置侦听器，它仍然需要公共 IP 地址，以便 Microsoft 可以管理它。

 备注

不支持应用程序网关子网中指向 Azure 防火墙 的默认路由，因为它会中断正确操作应用程序所需的控制平面 0.0.0.0/0 Azure 应用程序网关。

本地客户端

上述设计都显示来自公共 Internet 的应用程序客户端。 本地网络也会访问应用程序。 上述大部分信息和流量流与 Internet 客户端相同，但存在一些明显的差异：

• VPN 网关或 ExpressRoute 网关位于 Azure 防火墙 或应用程序网关的前面。

• WAF 使用应用程序网关的专用 IP 地址。

• Azure 防火墙专用 IP 地址不支持 DNAT。 因此，必须使用 UDR 将入站流量发送到Azure 防火墙 VPN 或 ExpressRoute 网关的流量。

• 请确保验证有关事件 和 的强制 隧道 Azure 应用程序网关注意事项 Azure 防火墙。 即使工作负荷不需要到公共 Internet 的出站连接，也无法为应用程序网关注入指向本地网络的默认路由，否则会中断控制流量。 0.0.0.0/0 对于Azure 应用程序网关，默认路由需要指向公共 Internet。

下图显示了并行Azure 应用程序网关Azure 防火墙设计。 应用程序客户端来自通过 VPN 或 ExpressRoute 连接到 Azure 的本地网络：

即使所有客户端都位于本地或 Azure 中，Azure 应用程序网关Azure 防火墙都需要具有公共 IP 地址。 公共 IP 地址允许 Microsoft 管理服务。

中心和辐射拓扑

本文中的设计仍 适用于中心分支 拓扑。 中心虚拟网络中的共享资源通过虚拟网络对等互连连接到单独分支虚拟网络中的应用程序。

此拓扑的一些注意事项包括：

• 该Azure 防火墙部署在中心虚拟网络中。 不过，应用程序团队通常管理Azure 应用程序网关或 Azure API Management网关等组件。 这些组件部署在分支虚拟网络中。

• 特别注意分支网络中 UDR：当分支中的应用程序服务器接收来自特定 Azure 防火墙 实例的流量（如前面的示例中的地址）时，它应发送回同一实例的返回 192.168.100.7 流量。 如果分支中的 UDR 将发送到中心的流量的下一跃点设置到) 上图中的 Azure 防火墙 IP 地址 (，则返回数据包最终可能会在不同的 Azure 防火墙 实例上， 192.168.100.4 从而导致非对称路由。 确保分支 VNet 中具有 UDR，以通过 Azure 防火墙 将流量发送到中心中的共享服务，则这些 UDR 不包含 Azure 防火墙 子网的前缀。

• 前面的建议同样适用于应用程序网关子网以及可能部署在中心 VNet 中的其他任何网络虚拟设备或反向代理。

• 无法为应用程序网关设置下一跃点，或Azure 防火墙下一跃点类型为 的静态路由设置子网 Virtual Network 。 此下一跃点类型仅在本地 VNet 中有效，在 VNet 对等互连中无效。 有关用户定义的路由和下一跃点类型的信息，请参阅 虚拟网络流量路由。

下图显示了分支如何将 SNA 点流量发回到该分支的 ALB Azure 防火墙。 此设置会导致非对称路由：

若要解决此问题，请定义分支中的 UDR，Azure 防火墙子网，但仅定义共享服务所在的子网。 在示例中，分支中的正确 UDR 应仅包含 192.168.1.0/24。 它不应包含整个 192.168.0.0/16，用红色标记。

与其他 Azure 产品集成

可以将 Azure 防火墙 Azure 应用程序网关与其他 Azure 产品和服务集成。

API Management网关

将反向代理服务 （API Management 网关）集成到以前的设计中，以提供 API 限制或身份验证代理等功能。 集成API Management网关不会极大地改变设计。 主要区别在于，有两个相互链接的反向代理，而不是单个应用程序网关反向代理。

有关详细信息，请参阅在虚拟网络中集成API Management应用程序网关的设计 指南和 微服务的应用程序模式 API 网关。

Azure Kubernetes 服务

对于在 AKS 群集上运行的工作负荷，Azure 应用程序网关群集独立部署。 或者，可以使用入口控制器 将其与 AKS Azure 应用程序网关集成。 在 Kubernetes 级别配置某些对象 (例如服务和入口) ，应用程序网关会自动调整，而无需额外的手动步骤。

Azure 防火墙在 AKS 群集安全性中扮演着重要角色。 它提供所需的功能，以基于 FQDN（而不只是 IP 地址）筛选来自 AKS 群集的出口流量。 有关详细信息，请参阅控制 AKS 群集节点 的出口流量。

将应用程序网关和Azure 防火墙来保护 AKS 群集时，最好使用并行设计选项。 具有 WAF 的应用程序网关处理对群集中 Web 应用程序的入站连接请求。 Azure 防火墙只允许显式允许的出站连接。

Azure Front Door

Azure Front Door 功能部分与Azure 应用程序网关。 例如，这两个服务都提供 Web 应用程序防火墙、SSL 卸载和基于 URL 的路由。 一个主要区别是，Azure 应用程序网关虚拟网络内部，Azure Front Door是一种分散式全局服务。

有时，可以通过将应用程序网关替换为分散式网关来简化Azure Front Door。 此处所述的大多数设计都保持有效，但将Azure 防火墙放在前一个Azure Front Door。

一个有趣的用例是Azure 防火墙虚拟网络中应用程序网关前面的应用程序网关。 如前文所述，应用程序网关注入的标头将包含防火墙实例的 IP 地址，而不是 X-Forwarded-For 客户端的 IP 地址。 解决方法是，在Azure Front Door之前，使用防火墙前面的地址将客户端的 IP 地址注入为标头，然后流量进入虚拟网络并命中 X-Forwarded-For Azure 防火墙。

有关这两个服务之间的差异或何时使用每个服务，请参阅两者之间的常见问题Azure Front Door。

其他网络虚拟设备

Microsoft 产品并不是在 Azure 中实现 Web 应用程序防火墙或下一代防火墙功能的唯一选择。 各种 Microsoft 合作伙伴为 NVA (网络) 。 概念和设计实质上与本文中的概念和设计相同，但有一些重要注意事项：

• 用于下一代防火墙的合作伙伴 NVA 可能会为应用程序不支持的 NAT 配置提供更高的控制Azure 防火墙。 示例包括来自本地的 DNAT 或来自 Internet 的 DNAT（不含 SNAT）。

• 与 NVA 相比， (网关和 Azure 防火墙) 等 Azure 托管的 NVA 可以降低复杂性，因为用户需要处理多个设备中的可伸缩性和复原能力。

• 在 Azure 中使用 NVA 时，请使用 主动-主动 和自动缩放设置，因此这些设备不是虚拟网络中运行的应用程序的瓶颈。