azure-firewall

Azure Firewall

Azure Firewall 是一款托管的、高可用、云原生有状态网络防火墙，用于集中管理和记录流量，通常部署在中心辐射式网络的中心。它是实施 Azure 环境默认拒绝出站策略的流量控制点。

适用场景

集中控制和检查 Azure 网络环境中的出站（以及东西向／入站）流量。使用此技能选择 SKU、设计规则并在中心部署。

此技能不适用于 L7 Web 应用防护（Front Door / App Gateway 上的 WAF）、子网微分段（NSG - 请参阅 azure-network-security-design）或第三方 NVA 设计。

按功能需求选择 SKU

需求	SKU	备注
SMB / 开发 / 小型环境，< 250 Mbps	Basic	优化成本；不支持威胁情报拒绝
标准出站筛选、FQDN、威胁情报	Standard	大多数企业中心的默认选择
TLS 检查、IDPS 特征码、URL 筛选、Web 类别	Premium	适用于受监管或高保障环境
多中心全球部署	Premium + Firewall Manager + Virtual WAN	大规模集中管理策略

经验法则： 对于 2026 年的大多数企业中心，Standard SKU 都是合适的选择。只有在确实需要 TLS 检查或 IDPS 时才升级到 Premium——TLS 检查带来的证书／PKI 负担不容小觑，而且会导致某些应用无法正常运行。Basic 仅适用于 SMB 或沙盒环境。

实施方法

1. 部署在中心 — 每个区域在中心 VNet 中部署一个防火墙（至少跨越两个可用区以确保复原能力）。所有分支都与中心建立对等连接；出站和东西向流量均经由中心转发。 验证：防火墙具有用于出站流量的公共 IP，部署跨越 ≥ 2 个 AZ，并已建立容量基线。

2. 使用 Firewall Policy（而非经典规则） — 在 Azure Firewall Policy 中编写规则，采用分层父策略 + 子策略（例如，父策略 = 企业基线，子策略 = 区域专用）。不要为每个防火墙单独编写规则。 验证：已规划策略层级；各区域防火墙复用同一个基础策略。

3. 默认拒绝 + 结构化规则集合 — 顺序：DNAT（入站）→ 网络规则（IP／端口／协议）→ 应用程序规则（FQDN／URL）。在每个集合组中，优先级决定评估顺序。默认操作 = 拒绝。 验证：从分支探测未允许的 FQDN 时，日志中会记录拒绝操作。

4. 使用 FQDN 标记配置应用程序规则 — 对于 Microsoft 服务出站流量，使用内置的 FQDN 标记（WindowsUpdate、AzureKubernetesService、Office365），而不是手动维护列表。第三方 SaaS 使用自定义 FQDN。

5. 通过 UDR 强制分支流量经由防火墙出站 — 在分支子网上配置用户定义路由：0.0.0.0/0 的下一跃点 = 防火墙专用 IP。如果没有 UDR，流量就会绕过防火墙。 验证：在分支 NIC 上运行 Get-AzEffectiveRouteTable，确认下一跃点 = 防火墙。

6. 启用威胁情报 + IDPS（Premium） — 将基于威胁情报的筛选设为 Deny 模式，以拦截已知恶意 IP / FQDN。Premium：对高严重性特征码启用 IDPS，并调整误报。

7. 流式传输日志并监控容量 — 使用结构化防火墙日志发送到 Log Analytics / Sentinel。使用工作簿查看被拒绝次数最多的流量、容量／吞吐量。 验证：防火墙工作簿已填充数据；若吞吐量持续 15 分钟超过 80%，则触发警报。

防护措施

• Azure Firewall 是 NSG（子网/NIC 微分段）和 WAF（L7 Web 防护）的补充，而非替代品。 采用分层防御；它们各司其职。
• TLS 检查（Premium）需要规划证书/PKI。 客户端必须信任内部 CA 证书链；某些应用（证书固定、mTLS）会因检查而无法正常工作。请先试点。
• 为具备韧性的中心部署规划容量和可用性区域。 仅部署在单个区域意味着该区域一旦中断，中心也会宕机。
• UDR 才是强制执行机制。 如果辐射网中没有 0.0.0.0/0 → firewall，流量就不会经过防火墙。请将 UDR 审计纳入着陆区管理。
• 防火墙策略采用分层结构自有其原因。 不要大规模地为每个防火墙单独编写规则，否则规则会逐渐不一致。
• 不要猜测性地启用 Premium 功能。 成本会显著增加；仅在有明确用例时启用。

常见反模式

• “先允许出站流量使用 *” — 这会让防火墙形同虚设。从第一天起就采用默认拒绝，并配置命名的 FQDN 规则。
• “所有人都用 Premium SKU” — 如果不需要 IDPS/TLS 检查，就只有成本，没有价值。
• “第一天就对所有流量启用 TLS 检查” — 这会导致一半的应用无法正常工作。请按工作负载逐步试点。
• “不配置 UDR——我们认为流量会经过防火墙” — 实际并非如此。路由才是强制执行机制。
• “只用单个防火墙，且只部署在单个区域” — 可用性区域中断会导致中心宕机。从第一天起就采用多区域部署。
• “不记录日志——太嘈杂了” — 首次发生事件时，就没有取证依据。始终使用结构化日志和 Sentinel。

示例提示词

• Design Azure Firewall egress filtering with FQDN and application rules in a hub-spoke topology.
• When should I choose Firewall Premium with IDPS and TLS inspection?
• Set up Firewall Policy hierarchy and force spoke egress through UDRs.
• How do I protect Azure Virtual Desktop traffic with Azure Firewall?
• Build a Sentinel workbook for top denied flows from Azure Firewall logs.
• Plan capacity, availability zones, and DNS proxy for the hub firewall.

Microsoft Learn

• Azure Firewall 概述：https://learn.microsoft.com/azure/firewall/overview
• 防火墙策略：https://learn.microsoft.com/azure/firewall/policy-rule-sets
• Premium 功能（IDPS/TLS）：https://learn.microsoft.com/azure/firewall/premium-features
• 中心辐射拓扑 + 防火墙：https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke
• FQDN 标记：https://learn.microsoft.com/azure/firewall/fqdn-tags
• 威胁情报：https://learn.microsoft.com/azure/firewall/threat-intel
• 结构化日志：https://learn.microsoft.com/azure/firewall/firewall-structured-logs
• 强制隧道：https://learn.microsoft.com/azure/firewall/forced-tunneling