若要保护 Azure 应用程序工作负载，应在应用程序本身中使用保护措施，例如身份验证和加密。 还可以将安全层添加到托管应用程序的虚拟网络（VNet）。 这些安全层保护应用程序的入站流免受意外利用率的占用。 它们还会将出站流限制为只有应用程序所需的终结点才能流到 Internet。 本文介绍 Azure 虚拟网络 安全服务，例如 Azure DDoS 防护、Azure 防火墙和 Azure 应用程序网关，何时使用每个服务和同时组合的网络设计选项。
- Azure DDoS 防护与应用程序设计最佳做法相结合，提供了增强的 DDoS 缓解功能，以提供更多防御 DDoS 攻击。 应在任何外围虚拟网络上启用 Azure DDOS 防护。
- Azure 防火墙 是一种托管的下一代防火墙，提供 网络地址转换（NAT）。 Azure 防火墙基于 Internet 协议（IP）地址和传输控制协议和用户数据报协议（TCP/UDP）端口或基于应用程序的 HTTP（S）或 SQL 属性的数据包筛选。 Azure 防火墙还Microsoft威胁情报来识别恶意 IP 地址。 有关详细信息，请参阅 Azure 防火墙文档。
- Azure 防火墙高级版 包括 Azure 防火墙标准版的所有功能和其他功能，例如 TLS 检查和入侵检测和保护系统（IDPS）。
- Azure 应用程序网关 是一个托管的 Web 流量负载均衡器和 HTTP（S）完全反向代理，可以执行安全套接字层（SSL）加密和解密。 应用程序网关在 X-Forwarded-For HTTP 标头中保留原始客户端 IP 地址。 应用程序网关还使用 Web 应用程序防火墙来检查 Web 流量，并检测 HTTP 层的攻击。 有关详细信息，请参阅 应用程序网关文档。
- Azure Web 应用程序防火墙（WAF） 是 Azure 应用程序网关的可选补充。 它提供 HTTP 请求的检查，并防止 Web 层（例如 SQL 注入或跨站点脚本）上的恶意攻击。 有关详细信息，请参阅 Web 应用程序防火墙文档。
这些 Azure 服务是互补的。 一种或另一种可能最适合工作负荷，也可以将它们一起使用，以便在网络层和应用程序层中获得最佳保护。 使用以下决策树和本文中的示例来确定应用程序虚拟网络的最佳安全选项。
Azure 防火墙和 Azure 应用程序网关使用不同的技术，并支持不同流的证券化：
| 应用程序流 | 可以通过 Azure 防火墙筛选 | 应用程序网关上的 WAF 可以筛选 |
|---|---|---|
| 从本地/Internet 到 Azure 的 HTTP（S） 流量（入站） | 是的 | 是的 |
| 从 Azure 到本地/Internet 的 HTTP（S） 流量（出站） | 是的 | 不 |
| 非 HTTP（S） 流量、入站/出站 | 是的 | 不 |
根据应用程序所需的网络流，每个应用程序的设计可能有所不同。 下图提供了一个简化的决策树，可帮助为应用程序选择建议的方法。 决策取决于应用程序是通过 HTTP（S） 还是其他协议发布：
本文将介绍流程图中广为推荐的设计，以及在不太常见的方案中适用的其他设计：
- 在虚拟网络中没有 Web 应用程序时，
单独 Azure 防火墙。 它将同时控制应用程序的入站流量和出站流量。 - 仅 应用程序网关，仅当 Web 应用程序位于虚拟网络中时，网络安全组（NSG） 提供足够的输出筛选。 Azure 防火墙提供的功能可以阻止许多攻击方案（例如数据外泄、IDPS 等）。 出于此原因，通常不建议使用应用程序网关方案，因此不建议记录，也不会记录在上面的流程图中。
- Azure 防火墙和应用程序网关并行，这是最常见的设计之一。 如果希望 Azure 应用程序网关保护 HTTP（S） 应用程序免受 Web 攻击，并使用 Azure 防火墙来保护所有其他工作负荷并筛选出站流量，请使用此组合。
- Azure 防火墙前的应用程序网关，如果希望 Azure 防火墙检查所有流量、WAF 以保护 Web 流量，以及应用程序知道客户端的源 IP 地址。 通过 Azure 防火墙高级版和 TLS 检查，此设计也支持端到端 SSL 方案。
- 如果希望 Azure 防火墙在到达应用程序网关之前检查和筛选流量，应用程序网关前的 Azure 防火墙。 由于 Azure 防火墙不会解密 HTTPS 流量，因此添加到应用程序网关的功能有限。 上述流程图中未记录此方案。
本文的最后一部分介绍了以前的基本设计变体。 这些变体包括：
可以添加其他反向代理服务，例如 API 管理 网关或 Azure Front Door。 或者，可以将 Azure 资源替换为第三方 网络虚拟设备。
注意
在以下方案中，Azure 虚拟机用作 Web 应用程序工作负荷的示例。 这些方案也适用于其他工作负荷类型，例如容器或 Azure Web 应用。 有关包括专用终结点的设置，请考虑 使用 Azure 防火墙检查发往专用终结点的流量
仅限 Azure 防火墙
如果虚拟网络中没有可从 WAF 中受益的基于 Web 的工作负荷，则只能使用 Azure 防火墙。 在这种情况下，设计很简单，但查看数据包流将有助于了解更复杂的设计。 在此设计中，所有入站流量都通过用户定义的路由（UDR）发送到 Azure 防火墙，以便从本地或其他 Azure VNet 建立连接。 它被寻址到 Azure 防火墙的公共 IP 地址，用于从公共 Internet 进行连接，如下图所示。 来自 Azure VNet 的出站流量通过 UDR 发送到防火墙，如下所示。
下表总结了此方案的流量流：
| 流 | 浏览应用程序网关/WAF | 通过 Azure 防火墙 |
|---|---|---|
| 从 Internet/onprem 到 Azure 的 HTTP（S） 流量 | N/A | 是（请参阅下文） |
| 从 Azure 到 Internet/onprem 的 HTTP（S） 流量 | N/A | 是的 |
| 从 Internet/onprem 到 Azure 的非 HTTP（S） 流量 | N/A | 是的 |
| 从 Azure 到 Internet/onprem 的非 HTTP（S） 流量 | N/A | 是的 |
Azure 防火墙不会检查入站 HTTP（S） 流量。 但它将能够应用第 3 层 & 第 4 层规则和基于 FQDN 的应用程序规则。 Azure 防火墙将检查出站 HTTP（S） 流量，具体取决于 Azure 防火墙层，以及是否配置 TLS 检查：
- Azure 防火墙标准版将仅检查网络规则中数据包的第 3 层 & 第 4 层属性，以及应用程序规则中的主机 HTTP 标头。
- Azure 防火墙高级版添加了功能，例如检查其他 HTTP 标头（如 User-Agent），并启用 TLS 检查，以便进行更深入的数据包分析。 Azure 防火墙不等同于 Web 应用程序防火墙。 如果虚拟网络中有 Web 工作负载，强烈建议使用 WAF。
以下数据包演练示例演示客户端如何从公共 Internet 访问 VM 托管的应用程序。 为了简单起见，关系图仅包含一个 VM。 为了提高可用性和可伸缩性，负载均衡器后面有多个应用程序实例。 在此设计中，Azure 防火墙使用 UDR 检查来自公共 Internet 的传入连接以及来自应用程序子网 VM 的出站连接。
- Azure 防火墙服务在此范围内部署多个实例，前端 IP 地址为 192.168.100.4，内部地址范围为 192.168.100.0/26。 这些单个实例通常对 Azure 管理员不可见。 但指出差异在某些情况下很有用，例如在排查网络问题时。
- 如果流量来自本地虚拟专用网络（VPN）或 Azure ExpressRoute 网关而不是 Internet，客户端将启动与 VM IP 地址的连接。 它不会启动与防火墙 IP 地址的连接，防火墙不会默认执行源 NAT。
建筑
下图显示了假设实例 IP 地址 192.168.100.7的流量流。
工作流
- 客户端启动与 Azure 防火墙的公共 IP 地址的连接：
- 源 IP 地址：ClientPIP
- 目标 IP 地址：AzFwPIP
- 对 Azure 防火墙公共 IP 的请求将分发到防火墙的后端实例，在本例中为 192.168.100.7。 Azure 防火墙 目标 NAT （DNAT） 规则 将目标 IP 地址转换为虚拟网络中的应用程序 IP 地址。 Azure 防火墙还会 源 NAT（SNAT） 数据包（如果它执行 DNAT）。 有关详细信息，请参阅 Azure 防火墙已知问题。 VM 在传入数据包中看到以下 IP 地址：
- 源 IP 地址：192.168.100.7
- 目标 IP 地址：192.168.1.4
- VM 会回答应用程序请求、撤销源 IP 地址和目标 IP 地址。 入站流不需要 用户定义的路由（UDR），因为源 IP 是 Azure 防火墙的 IP 地址。 0.0.0.0/0 关系图中的 UDR 用于出站连接，以确保到公共 Internet 的数据包通过 Azure 防火墙。
- 源 IP 地址：192.168.1.4
- 目标 IP 地址：192.168.100.7
- 最后，Azure 防火墙会撤消 SNAT 和 DNAT 操作，并向客户端传递响应：
- 源 IP 地址：AzFwPIP
- 目标 IP 地址：ClientPIP
仅限应用程序网关
此设计涵盖虚拟网络中仅存在 Web 应用程序的情况，并且检查 NSG 的出站流量足以保护发到 Internet 的出站流。
注意
这不是建议的设计，因为使用 Azure 防火墙控制出站流（而不是仅 NSG）将阻止某些攻击方案，例如数据外泄，确保工作负荷仅将数据发送到批准的 URL 列表。 此外，NSG 仅适用于第 3 层和第 4 层，并且没有 FQDN 支持。
与仅使用 Azure 防火墙的上一个设计的主要区别在于，应用程序网关不充当具有 NAT 的路由设备。 它的行为是完整的反向应用程序代理。 也就是说，应用程序网关停止来自客户端的 Web 会话，并与其中一个后端服务器建立单独的会话。 需要将来自 Internet 的入站 HTTP（S） 连接发送到应用程序网关的公共 IP 地址、从 Azure 或本地到网关的专用 IP 地址的连接。 从 Azure VM 返回流量将遵循标准 VNet 路由回应用程序网关（有关详细信息，请参阅数据包进一步下降）。 来自 Azure VM 的出站 Internet 流将直接转到 Internet。
下表汇总了流量流：
| 流 | 浏览应用程序网关/WAF | 通过 Azure 防火墙 |
|---|---|---|
| 从 Internet/onprem 到 Azure 的 HTTP（S） 流量 | 是的 | N/A |
| 从 Azure 到 Internet/onprem 的 HTTP（S） 流量 | 不 | N/A |
| 从 Internet/onprem 到 Azure 的非 HTTP（S） 流量 | 不 | N/A |
| 从 Azure 到 Internet/onprem 的非 HTTP（S） 流量 | 不 | N/A |
建筑
以下数据包演练示例演示客户端如何从公共 Internet 访问 VM 托管的应用程序。
工作流
- 客户端启动与 Azure 应用程序网关的公共 IP 地址的连接：
- 源 IP 地址：ClientPIP
- 目标 IP 地址：AppGwPIP
- 应用程序网关公共 IP 的请求将分发到网关的后端实例，在本例中为 192.168.200.7。 接收请求的应用程序网关实例会停止来自客户端的连接，并建立与其中一个后端的新连接。 后端将应用程序网关实例视为源 IP 地址。 应用程序网关使用原始客户端 IP 地址插入 X-Forwarded-For HTTP 标头。
- 源 IP 地址：192.168.200.7（应用程序网关实例的专用 IP 地址）
- 目标 IP 地址：192.168.1.4
- X-Forwarded-For 标头：ClientPIP
- VM 会回答应用程序请求、撤销源 IP 地址和目标 IP 地址。 VM 已知道如何访问应用程序网关，因此不需要 UDR。
- 源 IP 地址：192.168.1.4
- 目标 IP 地址：192.168.200.7
- 最后，应用程序网关实例回答客户端：
- 源 IP 地址：AppGwPIP
- 目标 IP 地址：ClientPIP
Azure 应用程序网关将元数据添加到数据包 HTTP 标头，例如包含原始客户端 IP 地址的 X-Forwarded-For 标头。 某些应用程序服务器需要源客户端 IP 地址来提供特定于地理位置的内容，或用于日志记录。 有关详细信息，请参阅 应用程序网关的工作原理。
192.168.200.7IP 地址是 Azure 应用程序网关服务在此中部署的实例之一，其中包含内部专用前端 IP 地址192.168.200.4。 这些单个实例通常对 Azure 管理员不可见。 但指出差异在某些情况下很有用，例如在排查网络问题时。如果客户端通过 VPN 或 ExpressRoute 网关来自本地网络，则流类似。 区别在于客户端访问应用程序网关的专用 IP 地址，而不是公共地址。
注意
请参阅 在反向代理与其后端 Web 应用程序之间保留原始 HTTP 主机名，详细了解 X-Forwarded-For 并在请求中保留主机名。
防火墙和应用程序网关并行
由于它的简单性和灵活性，并行运行应用程序网关和 Azure 防火墙通常是最佳方案。
如果虚拟网络中混合了 Web 和非 Web 工作负荷，则实现此设计。 Azure 应用程序网关中的 Azure WAF 可保护发到 Web 工作负荷的入站流量，Azure 防火墙会检查其他应用程序的入站流量。 Azure 防火墙将涵盖这两种工作负荷类型的出站流。
应将来自 Internet 的入站 HTTP（S） 连接发送到应用程序网关的公共 IP 地址、从 Azure 或本地到其专用 IP 地址的 HTTP（S） 连接。 标准 VNet 路由会将数据包从应用程序网关发送到目标 VM，以及从目标 VM 发回应用程序网关（请参阅数据包进一步向下走以了解更多详细信息）。 对于入站非 HTTP（S）连接，流量应面向 Azure 防火墙的公共 IP 地址（如果来自公共 Internet），或者流量将通过 UDR 通过 Azure 防火墙发送（如果来自其他 Azure VNet 或本地网络）。 来自 Azure VM 的所有出站流将由 UDR 转发到 Azure 防火墙。
下表总结了此方案的流量流：
| 流 | 浏览应用程序网关/WAF | 通过 Azure 防火墙 |
|---|---|---|
| 从 Internet/onprem 到 Azure 的 HTTP（S） 流量 | 是的 | 不 |
| 从 Azure 到 Internet/onprem 的 HTTP（S） 流量 | 不 | 是的 |
| 从 Internet/onprem 到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 从 Azure 到 Internet/onprem 的非 HTTP（S） 流量 | 不 | 是的 |
此设计提供比 NSG 更精细的出口筛选。 例如，如果应用程序需要连接到特定的 Azure 存储帐户，则可以使用 完全限定的域名（FQDN）筛选器。 使用基于 FQDN 的筛选器，应用程序不会将数据发送到恶意存储帐户。 仅使用 NSG 无法阻止这种情况。 此设计通常用于出站流量需要基于 FQDN 的筛选。 一个示例情况是 限制来自 Azure Kubernetes 服务群集的出口流量。
架构
下图演示了来自外部客户端的入站 HTTP（S） 连接的流量流：
下图演示了从网络 VM 到 Internet 的出站连接的流量流。 一个示例是连接到后端系统或获取操作系统更新：
每个服务的数据包流步骤与前面的独立设计选项中的步骤相同。
防火墙前的应用程序网关
本文档更详细地介绍了此设计，Azure 防火墙和应用程序网关的 Web 应用程序的零信任网络，本文档将重点介绍与其他设计选项的比较。 在此拓扑中，入站 Web 流量通过 Azure 防火墙和 WAF。 WAF 在 Web 应用程序层提供保护。 Azure 防火墙充当中心日志记录和控制点，并检查应用程序网关和后端服务器之间的流量。 应用程序网关和 Azure 防火墙不是并行的，而是一个接一个。
使用 Azure 防火墙高级版，此设计可以支持端到端方案，其中 Azure 防火墙应用 TLS 检查，对应用程序网关和 Web 后端之间的加密流量执行 IDPS。
此设计适用于需要知道传入的客户端源 IP 地址的应用程序，例如提供特定于地理位置的内容或日志记录。 Azure 防火墙前面的应用程序网关捕获传入数据包的源 IP 地址，该地址位于 x-forwarded-for 标头中，因此 Web 服务器可以看到此标头中的原始 IP 地址。 有关详细信息，请参阅 应用程序网关的工作原理。
需要将来自 Internet 的入站 HTTP（S） 连接发送到应用程序网关的公共 IP 地址、从 Azure 或本地到专用 IP 地址的 HTTP（S） 连接。 从应用程序网关 UDR 将确保数据包通过 Azure 防火墙路由（请参阅数据包进一步向下走以了解更多详细信息）。 对于入站非 HTTP（S）连接，流量应面向 Azure 防火墙的公共 IP 地址（如果来自公共 Internet），或者流量将通过 UDR 通过 Azure 防火墙发送（如果来自其他 Azure VNet 或本地网络）。 来自 Azure VM 的所有出站流将由 UDR 转发到 Azure 防火墙。
此设计的重要说明是，Azure 防火墙高级版将看到来自应用程序网关子网的源 IP 地址的流量。 如果此子网配置有专用 IP 地址（10.0.0.0/8、192.168.0.0/16、172.16.0.0/12 或 100.64.0.0/10），Azure 防火墙高级版会将来自应用程序网关的流量视为内部流量，并且不会对入站流量应用 IDPS 规则。 可以在 Azure 防火墙 IDPS 规则中找到有关 IDPS 的 Azure 防火墙 IDPS 规则指示和专用 IP 前缀的详细信息。 因此，建议修改 Azure 防火墙策略中的 IDPS 专用前缀，以便应用程序网关子网不被视为内部源，以将入站和出站 IDPS 签名应用于流量。
下表总结了此方案的流量流：
| 流 | 浏览应用程序网关/WAF | 通过 Azure 防火墙 |
|---|---|---|
| 从 Internet/onprem 到 Azure 的 HTTP（S） 流量 | 是的 | 是的 |
| 从 Azure 到 Internet/onprem 的 HTTP（S） 流量 | 不 | 是的 |
| 从 Internet/onprem 到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 从 Azure 到 Internet/onprem 的非 HTTP（S） 流量 | 不 | 是的 |
对于从本地或 Internet 到 Azure 的 Web 流量，Azure 防火墙将检查 WAF 已允许的流。 根据应用程序网关是否加密后端流量（应用程序网关到应用程序服务器的流量），你将有不同的潜在方案：
- 应用程序网关遵循零信任原则（端到端 TLS 加密）加密流量，Azure 防火墙将收到加密的流量。 不过，Azure 防火墙标准版将能够应用检查规则，例如网络规则中的第 3 层 & 第 4 层筛选，或使用 TLS 服务器名称指示（SNI）标头在应用程序规则中进行 FQDN 筛选。 Azure 防火墙高级版 通过 TLS 检查（例如基于 URL 的筛选）提供更深入的可见性。
- 如果应用程序网关正在向应用程序服务器发送未加密的流量，则 Azure 防火墙将以明文形式看到入站流量。 Azure 防火墙中不需要 TLS 检查。
- 如果在 Azure 防火墙中启用了 IDPS，它将验证 HTTP 主机标头是否与目标 IP 匹配。 出于此目的，它需要主机标头中指定的 FQDN 的名称解析。 可以使用 Azure DNS 专用区域和使用 Azure DNS 的默认 Azure 防火墙 DNS 设置来实现此名称解析。 也可以使用需要在 Azure 防火墙设置中配置的自定义 DNS 服务器来实现此目的。 （有关详细信息，请参阅 Azure 防火墙 DNS 设置。）如果部署了 Azure 防火墙的虚拟网络没有管理访问权限，则后一种方法是唯一的可能性。 一个示例是部署在虚拟 WAN 安全中心的 Azure 防火墙。
建筑
对于其余的流（入站非 HTTP（S）流量和任何出站流量，Azure 防火墙将在适当情况下提供 IDPS 检查和 TLS 检查。 它还在基于 DNS 的网络规则中提供基于 FQDN 的筛选
工作流
来自公共 Internet 的网络流量遵循以：
- 客户端启动与 Azure 应用程序网关的公共 IP 地址的连接：
- 源 IP 地址：ClientPIP
- 目标 IP 地址：AppGwPIP
- 应用程序网关公共 IP 的请求将分发到网关的后端实例，在本例中为 192.168.200.7。 应用程序网关实例停止来自客户端的连接，并与其中一个后端建立新连接。 应用程序网关子网中要
192.168.1.0/24的 UDR 会将数据包转发到 Azure 防火墙，同时将目标 IP 保留到 Web 应用程序：- 源 IP 地址：192.168.200.7（应用程序网关实例的专用 IP 地址）
- 目标 IP 地址：192.168.1.4
- X-Forwarded-For 标头：ClientPIP
- Azure 防火墙不会对流量进行 SNAT，因为流量将转到专用 IP 地址。 如果规则允许，它会将流量转发到应用程序 VM。 有关详细信息，请参阅 Azure 防火墙 SNAT。 但是，如果流量在防火墙中命中应用程序规则，则工作负荷将看到处理数据包的特定防火墙实例的源 IP 地址，因为 Azure 防火墙将代理连接：
- 如果 Azure 防火墙网络规则允许流量，则源 IP 地址：192.168.200.7（应用程序网关实例之一的专用 IP 地址）。
- 如果 Azure 防火墙应用程序规则允许流量，则源 IP 地址：192.168.100.7（Azure 防火墙实例之一的专用 IP 地址）。
- 目标 IP 地址：192.168.1.4
- X-Forwarded-For 标头：ClientPIP
- VM 会回答请求、撤销源 IP 地址和目标 IP 地址。 要
192.168.200.0/24的 UDR 捕获发回应用程序网关的数据包，并将其重定向到 Azure 防火墙，同时将目标 IP 保留到应用程序网关。- 源 IP 地址：192.168.1.4
- 目标 IP 地址：192.168.200.7
- 同样，Azure 防火墙不会 SNAT 流量，因为它会转到专用 IP 地址，并将流量转发到应用程序网关。
- 源 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 防火墙 SNAT 传入的流量，因此应用程序无法查看 HTTP 请求的原始 IP 地址。 从管理的角度来看，例如出于故障排除目的，可以通过将其与 Azure 防火墙的 SNAT 日志相关联来获取特定连接的实际客户端 IP。
此方案中有一定的好处，因为 Azure 防火墙只会看到发送到应用程序网关的加密流量。 在某些情况下，此设计是首选方案。 一种情况是，如果另一个 WAF 早于网络（例如，使用 Azure Front Door），它可以捕获 X-Forwarded-For HTTP 标头中的原始源 IP。 或者，如果需要许多公共 IP 地址，则首选设计。
来自公共 Internet 的 HTTP（S） 入站流应面向 Azure 防火墙的公共 IP 地址，Azure 防火墙会将数据包 DNAT（和 SNAT）发送到应用程序网关的专用 IP 地址。 从其他 Azure VNet 或本地网络，HTTP（S） 流量应发送到应用程序网关的专用 IP，并使用 UDR 通过 Azure 防火墙转发。 标准 VNet 路由将确保从 Azure VM 返回流量返回到应用程序网关，如果使用 DNAT 规则，则从应用程序网关返回到 Azure 防火墙。 对于来自应用程序网关子网中本地或 Azure UDR 的流量，应使用（有关详细信息，请参阅数据包进一步下行）。 从 Azure VM 发往 Internet 的所有出站流量都将通过 UDR 通过 Azure 防火墙发送。
下表总结了此方案的流量流：
| 流 | 浏览应用程序网关/WAF | 通过 Azure 防火墙 |
|---|---|---|
| 从 Internet/onprem 到 Azure 的 HTTP（S） 流量 | 是的 | 是（请参阅下文） |
| 从 Azure 到 Internet/onprem 的 HTTP（S） 流量 | 不 | 是的 |
| 从 Internet/onprem 到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 从 Azure 到 Internet/onprem 的非 HTTP（S） 流量 | 不 | 是的 |
对于入站 HTTP（S） 流量，Azure 防火墙通常不会解密流量。 而是应用不需要 TLS 检查的 IDPS 策略，例如基于 IP 的筛选或使用 HTTP 标头。
建筑
应用程序看不到 Web 流量的原始源 IP 地址;Azure 防火墙在数据包传入虚拟网络时对数据包进行管理。 若要避免此问题，请使用防火墙前 Azure Front Door。 Azure Front Door 在进入 Azure 虚拟网络之前，将客户端的 IP 地址作为 HTTP 标头注入。
显示 Azure 防火墙后的应用程序网关的 
工作流
来自公共 Internet 的网络流量遵循以：
- 客户端启动与 Azure 防火墙的公共 IP 地址的连接：
- 源 IP 地址：ClientPIP
- 目标 IP 地址：AzFWPIP
- 对 Azure 防火墙公共 IP 的请求将分发到防火墙的后端实例，在本例中为 192.168.100.7。 Azure 防火墙 DNAT Web 端口（通常为 TCP 443）到应用程序网关实例的专用 IP 地址。 执行 DNAT 时，Azure 防火墙还会有 SNAT。 有关详细信息，请参阅 Azure 防火墙已知问题：
- 源 IP 地址：192.168.100.7（Azure 防火墙实例的专用 IP 地址）
- 目标 IP 地址：192.168.200.4
- 应用程序网关在处理连接和后端服务器之一的实例之间建立新会话。 客户端的原始 IP 地址不在数据包中：
- 源 IP 地址：192.168.200.7（应用程序网关实例的专用 IP 地址）
- 目标 IP 地址：192.168.1.4
- X-Forwarded-For 标头：192.168.100.7
- VM 会回答应用程序网关，并反转源和目标 IP 地址：
- 源 IP 地址：192.168.1.4
- 目标 IP 地址：192.168.200.7
- 应用程序网关会回复 Azure 防火墙实例的 SNAT 源 IP 地址。 即使连接来自特定应用程序网关实例（如
.7），Azure 防火墙也会将应用程序网关的内部 IP 地址视为源 IP.4：- 源 IP 地址：192.168.200.4
- 目标 IP 地址：192.168.100.7
- 最后，Azure 防火墙撤消 SNAT 和 DNAT 并回答客户端：
- 源 IP 地址：AzFwPIP
- 目标 IP 地址：ClientPIP
即使应用程序网关没有为应用程序配置侦听器，它仍然需要公共 IP 地址，以便Microsoft可以管理它。
注意
不支持在指向 Azure 防火墙的应用程序网关子网中 0.0.0.0/0 的默认路由，因为它会中断 Azure 应用程序网关正确操作所需的控制平面流量。
本地客户端
上述设计都显示来自公共 Internet 的应用程序客户端。 本地网络也访问应用程序。 上述大部分信息和流量流与 Internet 客户端相同，但存在一些显著差异：
- VPN 网关或 ExpressRoute 网关位于 Azure 防火墙或应用程序网关前面。
- WAF 使用应用程序网关的专用 IP 地址。
- Azure 防火墙不支持专用 IP 地址的 DNAT。 因此，必须使用 UDR 从 VPN 或 ExpressRoute 网关将入站流量发送到 Azure 防火墙。
- 请务必验证 强制隧道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 管理网关等组件。 在这种情况下，这些组件部署在辐射虚拟网络中。
- 特别注意辐射网络中 UDR：当辐射中的应用程序服务器接收来自特定 Azure 防火墙实例的流量时，如前面的示例中的
192.168.100.7地址，它应将返回流量发回同一实例。 如果辐射中的 UDR 将发送到中心的下一跃点流量设置为 Azure 防火墙 IP 地址（上图中的192.168.100.4），则返回数据包可能最终位于不同的 Azure 防火墙实例上，从而导致非对称路由。 请确保分支 VNet 中有 UDR，以便通过 Azure 防火墙将流量发送到中心内的共享服务，则这些 UDR 不包括 Azure 防火墙子网的前缀。 - 上述建议同样适用于应用程序网关子网以及可能在中心 VNet 中部署的任何其他网络虚拟设备或反向代理。
- 不能通过具有下一跃点类型的
Virtual Network的静态路由为应用程序网关或 Azure 防火墙子网设置下一跃点。 此下一跃点类型仅在本地 VNet 中有效，不能跨 VNet 对等互连。 有关用户定义的路由和下一跃点类型的详细信息，请参阅 虚拟网络流量路由。
非对称路由
下图显示了辐射如何将 SNATted 流量发回 Azure 防火墙的 ALB。 此设置会导致非对称路由：
若要解决此问题，请在辐射中定义没有 Azure 防火墙子网的 UDR，但只定义共享服务的子网。 在此示例中，辐射中正确的 UDR 应仅包含 192.168.1.0/24。 它不应包含整个 192.168.0.0/16，如红色标记。
与其他 Azure 产品的集成
可以将 Azure 防火墙和 Azure 应用程序网关与其他 Azure 产品和服务集成。
API 管理网关
将反向代理服务（如 API 管理 网关）集成到以前的设计中，以提供 API 限制或身份验证代理等功能。 集成 API 管理网关不会大大改变设计。 主要区别在于，而不是单个应用程序网关反向代理，有两个反向代理相互链接。
有关详细信息，请参阅 设计指南，以将 API 管理和应用程序网关集成到虚拟网络 以及用于微服务的应用程序模式 API 网关。
Azure Kubernetes 服务
对于在 AKS 群集上运行的工作负荷，可以独立于群集部署 Azure 应用程序网关。 或者，可以使用 Azure 应用程序网关入口控制器将其与 AKS 群集集成。 在 Kubernetes 级别（如服务和入口）上配置某些对象时，应用程序网关会自动调整，无需额外的手动步骤。
Azure 防火墙在 AKS 群集安全性中起着重要作用。 它提供所需的功能来基于 FQDN 筛选 AKS 群集的出口流量，而不仅仅是 IP 地址。 有关详细信息，请参阅 控制 AKS 群集节点的出口流量。
将应用程序网关和 Azure 防火墙组合在一起以保护 AKS 群集时，最好使用并行设计选项。 WAF 的应用程序网关处理群集中 Web 应用程序的入站连接请求。 Azure 防火墙仅允许显式允许的出站连接。 有关并行设计选项的示例，请参阅 azure Kubernetes 服务（AKS）群集
Azure Front Door
Azure Front Door 功能部分与 Azure 应用程序网关重叠。 例如，这两个服务都提供 Web 应用程序防火墙、SSL 卸载和基于 URL 的路由。 一个主要区别是，虽然 Azure 应用程序网关位于虚拟网络中，但 Azure Front Door 是一项全球分散式服务。
有时可以通过将应用程序网关替换为分散式 Azure Front Door 来简化虚拟网络设计。 此处介绍的大多数设计仍然有效，除了在 Azure Front Door 前面放置 Azure 防火墙的选项外。
有趣的用例是在虚拟网络中的应用程序网关前面使用 Azure 防火墙。 如前所述，应用程序网关注入的 X-Forwarded-For 标头将包含防火墙实例的 IP 地址，而不是客户端的 IP 地址。 解决方法是在防火墙前使用 Azure Front Door 将客户端的 IP 地址作为 X-Forwarded-For 标头注入，然后流量进入虚拟网络并命中 Azure 防火墙。 第二个选项是 使用 Azure Front Door Premium中的专用链接保护源。
有关两个服务之间的差异的详细信息，或何时使用每个服务，请参阅 Azure Front Door的
其他网络虚拟设备
Microsoft产品并不是在 Azure 中实现 Web 应用程序防火墙或下一代防火墙功能的唯一选择。 广泛的Microsoft合作伙伴提供网络虚拟设备（NVA）。 概念和设计实质上与本文相同，但有一些重要的注意事项：
- 用于下一代防火墙的合作伙伴 NVA 可以为 Azure 防火墙不支持的 NAT 配置提供更多控制和灵活性。 示例包括来自本地的 DNAT 或来自 Internet 的 DNAT（没有 SNAT）。
- 与用户需要跨多个设备处理可伸缩性和复原能力的 NVA 相比，Azure 托管的 NVA（如应用程序网关和 Azure 防火墙）降低了复杂性。
- 在 Azure 中使用 NVA 时，请使用 主动-主动 和 自动缩放 设置，因此这些设备对于在虚拟网络中运行的应用程序不是瓶颈。
贡献
本文由Microsoft维护。 它最初由以下参与者编写。
主体作者：
- 何塞·雷诺 |首席客户工程师
后续步骤
详细了解组件技术：
- 什么是 Azure 应用程序网关？
- 什么是 Azure 防火墙？
- 什么是 Azure Front Door？
- Azure Kubernetes 服务
- 什么是 Azure 虚拟网络？
- 什么是 Azure Web 应用程序防火墙？
相关资源
探索相关的体系结构：
- 实现安全的混合网络
- 安全管理的 Web 应用程序
- 保护防火墙后面的 Microsoft Teams 频道机器人和 Web 应用
- Azure 中高度敏感的 IaaS 应用的安全注意事项
- Azure 上的多租户 SaaS
- 使用应用服务环境
企业部署 - 使用应用服务环境
高可用性企业部署 - Azure Kubernetes 服务 （AKS） 群集的基线体系结构