**发布时间:** 2025-10-15
**厂商:** AZURE
**类型:** TECH-BLOG
**原始链接:** https://techcommunity.microsoft.com/blog/azurenetworkingblog/deploying-third-party-firewalls-in-azure-landing-zones-design-configuration-and-/4458972
---
<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 在 Azure 登陆区部署第三方防火墙：设计、配置与最佳实践
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 在 Azure 登陆区域中部署第三方防火墙的架构方案分析
## 解决方案概述
该方案详细阐述了在微软 **Azure 登陆区域 (Azure Landing Zone)** 企业级架构中，部署和配置**第三方防火墙网络虚拟设备 (NVA)** 的设计模式与最佳实践。Azure 登陆区域为企业提供了一个标准化的云环境部署框架，而此方案专注于解决其中的核心网络安全问题。
该方案主要面向那些因**高级功能需求**、**现有技术栈和团队技能**、或**跨混合云的一致性策略**而选择使用 Palo Alto、Fortinet、Check Point 等第三方防火墙，而非 Azure 原生防火墙的企业。
其技术核心是采用 **Hub-Spoke (中心-辐射型)** 网络拓扑。
- **中心 VNet (Hub VNet):** 部署第三方防火墙集群，作为流量检查和策略执行的中心枢纽。同时承载 VPN/ExpressRoute 网关、DNS 等共享服务。
- **辐射 VNet (Spoke VNet):** 承载各类应用负载。通过**用户定义路由 (UDR)**，将所有出站（**南北向**）和跨 VNet（**东西向**）的流量强制路由到中心 VNet 的防火墙进行深度检测和过滤，从而实现集中化的安全管控。
## 方案对比：第三方防火墙 vs. Azure Firewall
企业在选择防火墙方案时，通常在 Azure 原生服务与第三方设备之间权衡。
- **选择第三方防火墙的主要原因：**
- **功能深度与高级安全:**
- 提供**深度包检测 (DPI)**、**入侵检测与防御 (IDS/IPS)**、**SSL/TLS 解密**、高级威胁情报、沙箱及僵尸网络检测等更成熟的高级功能。
- **运营熟悉度与技能复用:**
- 网络安全团队已具备对特定厂商（如 Palo Alto, Fortinet）设备的管理经验，可复用现有技能和运维流程，降低学习成本。
- **与现有安全生态系统集成:**
- 可与厂商的集中管理平台（如 Palo Alto 的 **Panorama**、Fortinet 的 **FortiManager**）无缝集成，实现对本地和云端防火墙策略的统一管理。
- **合规性与监管要求:**
- 满足特定行业（如金融、医疗）对经过认证的成熟防火墙供应商的合规要求。
- **混合云与多云战略对齐:**
- 在本地、Azure 及其他云平台之间提供统一的安全层，简化跨环境的安全治理。
- **定制化与灵活性:**
- 提供对操作系统、补丁、高级路由和自定义集成的完全控制权。
- **许可成本优势 (BYOL):**
- 企业可利用现有的企业许可协议 (EA) 将许可证**自带许可 (Bring Your Own License)** 至 Azure，通常比按需付费模式更具成本效益。
- **Azure Firewall 适用的场景：**
- 安全需求相对简单（如基本的南北向检查、FQDN 过滤）。
- 偏好云原生、零基础设施运维的托管服务。
- 希望避免手动扩展和虚拟机补丁管理。
> 实践中，许多大型企业采用混合模式：使用 Azure Firewall 满足轻量级场景需求，同时为核心业务负载部署功能更强大的第三方防火墙。
## 部署模型与架构
第三方防火墙在 Azure 中主要以 **IaaS 虚拟机**形式部署，通常采用高可用性架构。
- **部署模式:**
- **1. Active-Active (主-主模式):**
- 多台防火墙虚拟机通过 **Azure 负载均衡器** 同时处理流量，分担负载。
- **优点:** 高吞吐、高弹性和近乎零停机的故障切换。
- **适用场景:** 对性能和可用性要求极高的关键业务系统。
- **2. Active-Passive (主-备模式):**
- 一台防火墙处理所有流量，另一台作为备用节点。当主节点故障时，通过自动化脚本（通常利用 Azure 服务主体）将 IP 地址和路由切换至备用节点。
- **优点:** 管理相对简单，运维复杂性较低。
- **缺点:** 故障切换期间会产生短暂的业务中断（秒级到分钟级）。
- **网络接口 (NICs) 设计:**
- 防火墙虚拟机通常配置多个专用网络接口以实现流量隔离和安全管理。
- **Untrust/Public NIC:** 连接外部网络，处理南北向流量。
- **Trust/Internal NIC:** 连接内部 VNet，管理东西向流量。
- **Management NIC:** 用于设备管理，将管理流量与数据流量分离。
- **HA NIC:** 在 Active-Passive 模式下，用于主备节点间的状态同步。
## 关键配置与技术考量
- **路由管理:**
- **用户定义路由 (UDRs):** 在所有 Spoke VNet 的子网上配置 UDR，将下一跳 (Next Hop) 指向中心 VNet 防火墙集群的内部负载均衡器 IP，强制所有流量通过防火墙进行检查。
- **对称路由:** 必须确保请求和响应流量经过同一台防火墙设备，避免因状态丢失导致会话中断。可利用 **Azure Route Server** 配合 BGP 简化复杂环境下的路由管理。
- **策略配置:**
- **NAT 规则:**
- **DNAT:** 用于将公网访问请求安全地发布到内部应用。
- **SNAT:** 用于在内部负载访问互联网时，将其源 IP 地址转换为防火墙的公网 IP。
- **安全规则:** 基于最小权限原则，精细化定义允许/拒绝的流量策略，并应用到南北向和东西向流量。
- **应用感知策略:** 利用防火墙的 L7 检测能力，基于应用、用户身份和内容（而非仅 IP/端口）创建策略。
- **负载均衡器:**
- **内部负载均衡器 (ILB):** 用于在 Active-Active 模式下分发东西向流量。
- **外部负载均衡器 (ELB):** 用于分发来自互联网的南北向流量。
- **许可模式:**
- **Pay-As-You-Go (PAYG):** 从 Azure Marketplace 部署，许可费用包含在虚拟机小时费率中，适合短期或弹性需求。
- **Bring Your Own License (BYOL):** 使用企业已有的许可证，适合长期、大规模部署，成本更优。
## 技术评估：优势与挑战
- **技术优势:**
- **深度安全能力:** 提供远超网络安全组 (NSG) 的高级威胁防护能力。
- **运营一致性:** 统一本地与云端的安全技术栈，降低管理复杂性。
- **集中化管控:** 通过统一管理平台实现跨混合云环境的策略一致性。
- **高度灵活性:** 提供对网络配置和安全策略的完全控制。
- **技术挑战与限制:**
- **配置复杂性:** 错误的 UDR 或非对称路由是常见问题，易导致流量中断。
- **性能瓶颈:** 防火墙吞吐量受限于底层 **VM SKU 的性能**（CPU、内存、网络带宽），选型不当会成为性能瓶颈。
- **故障切换延迟:** Active-Passive 模式的故障切换会造成短暂业务中断。
- **备份与恢复:** 防火墙配置需通过厂商工具手动导出备份，Azure Backup 无法直接备份其操作系统状态。
- **Azure 平台连接数限制:** 一个关键限制是 **Azure 对单台 VM 的并发连接数上限为 250,000**。即使防火墙设备本身支持更高连接数，也会受此平台限制。当达到上限时，即使 VM 资源充足，也会出现无法解释的丢包。解决方案是**横向扩展**防火墙集群。
## 最佳实践
- **[x] 跨可用区部署:** 将防火墙实例部署在不同的可用区 (Availability Zones) 以实现区域内高可用。
- **[x] 优先选择 Active-Active 模式:** 对于关键业务，推荐使用 Active-Active 模式以避免故障切换带来的中断。
- **[x] 使用专用子网:** 为防火墙的不同网络接口（Trust, Untrust, Management, HA）分配独立的子网，增强隔离性并简化路由管理。
- **[x] 遵循最小权限原则:** 默认拒绝所有流量，仅开放业务必需的端口和协议。
- **[x] 标准化命名与标签:** 对防火墙、路由表、子网等资源采用一致的命名和标签规范，便于自动化和故障排查。
- **[x] 端到端流量验证:** 部署后使用 **Azure Network Watcher** 等工具验证南北向和东西向流量是否按预期路径通过防火墙。
- **[x] 规划可扩展性:** 持续监控防火墙的 CPU、吞吐量和会话数，以便在需要时进行纵向（更高 SKU）或横向（增加实例）扩展。
- **[x] 及时更新与维护:** 定期更新防火墙固件、操作系统补丁和威胁特征库，以抵御最新威胁。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 在 Azure 登陆区域部署第三方防火墙：设计、配置与最佳实践
**原始链接:** [https://techcommunity.microsoft.com/blog/azurenetworkingblog/deploying-third-party-firewalls-in-azure-landing-zones-design-configuration-and-/4458972](https://techcommunity.microsoft.com/blog/azurenetworkingblog/deploying-third-party-firewalls-in-azure-landing-zones-design-configuration-and-/4458972)
**发布时间:** 2025-10-15
**厂商:** AZURE
**类型:** TECH-BLOG
---
Azure Networking Blog
# 在 Azure 登陆区域部署第三方防火墙：设计、配置与最佳实践
2025 年 11 月 5 日
随着企业将大规模工作负载迁移至 Microsoft Azure, 保护网络流量已成为平台基础的关键一环。Azure 的 [**良好架构框架 (Well-Architected Framework)**](https://learn.microsoft.com/en-us/azure/well-architected/) 为企业级 **登陆区域 (Landing Zone)** 的设计和部署提供了蓝图。尽管 **[Azure 防火墙 (Azure Firewall)](https://learn.microsoft.com/en-us/azure/firewall/overview)** 是一个内置的平台即服务 (PaaS) 选项，但一些组织出于对产品的熟悉度、功能深度以及与现有供应商的合作关系，更倾向于使用 **第三方防火墙设备 (third-party firewall appliances)**。
本文将阐述在 Azure 登陆区域中部署第三方防火墙 (如 Palo Alto、Fortinet、Check Point 等) 时的 **基本设计模式**、**关键配置** 和 **最佳实践**。
## 1. 登陆区域架构与防火墙的角色
**Azure 登陆区域** 是微软推荐的企业级架构，旨在帮助企业大规模上云。它提供了一个标准化的模块化设计，使组织能够在不同订阅和区域中一致地部署和治理工作负载。
其核心结构包括：
* **中心 (连接订阅):**
* 集中部署共享服务的地方，例如 **DNS、私有终结点、VPN/ExpressRoute 网关、Azure 防火墙 (或第三方防火墙设备)、Bastion 和监控代理**。
* 为所有工作负载提供一致的安全控制和连接。
* 防火墙部署于此，作为 **流量检测和策略执行点**。
* **分支 (工作负载订阅):**
* 应用程序工作负载 (例如 SAP、Web 应用、数据平台) 部署在分支 VNet 中。
* 可能存在用于 **身份**、**共享服务**、**安全** 或 **管理** 的专用分支。
* 这些分支为实现治理与合规而被隔离，但所有返回其他工作负载或本地的连接都通过中心网络路由。
#### 通过防火墙的流量类型
* **南北向流量 (North-South Traffic):**
* 来自互联网的入站连接 (例如，客户访问应用程序)。
* 从 Azure 工作负载到互联网服务的出站连接。
* 连接到本地数据中心或其他云的混合连接。
* 流量通过 **外部防火墙集群** 进行检测和策略执行。
* **东西向流量 (East-West Traffic):**
* 分支之间的横向流量 (例如，应用 VNet 到数据库 VNet)。
* 跨环境通信，如开发 → 测试 → 生产 (如果允许)。
* 流量通过 **内部防火墙集群** 进行路由，以实现分段、零信任原则并防止威胁的横向移动。
#### 为何防火墙在登陆区域中至关重要
尽管 Azure 提供了 **网络安全组 (NSG)** 和 **路由表 (Route Tables)** 用于基本的包过滤和路由，但这对于高级安全场景来说是远远不够的。防火墙增加了以下能力：
* **深度包检测 (DPI)** 和 **应用层过滤**。
* **入侵检测/防御系统 (IDS/IPS)** 功能。
* 跨多个分支的 **集中式策略管理**。
* **工作负载分段**，以减少潜在攻击的影响范围。
* 在混合云和多云环境中 **一致地执行** 企业安全基线。
#### 组织的选择
根据 **安全需求、成本容忍度以及运维复杂性**，组织通常会采用以下两种第三方防火墙模型之一：
1. **两套防火墙集群**
* 一套专用于 **南北向流量** (Azure 对外)。
* 另一套用于 **东西向流量** (VNet 和分支之间)。
* 这种模式提供了 **最高的安全粒度**，但成本和管理开销也更高。
2. **单套防火墙集群**
* 一种整合部署，**同一个防火墙集群同时处理东西向和南北向流量**。
* 更简单且成本效益更高，但可能会在路由和策略隔离方面引入复杂性。
这一设计决策通常在登陆区域设计阶段做出，旨在平衡 **安全要求、预算和运维成熟度**。
## 2. 为什么选择第三方防火墙而非 Azure 防火墙？
尽管 **[Azure 防火墙](https://learn.microsoft.com/en-us/azure/firewall/overview)** 作为一项托管服务提供了简便性，但客户选择第三方解决方案通常是出于以下原因：
* **高级功能** – 深度包检测、IDS/IPS、SSL 解密、威胁情报源。
* **供应商熟悉度** – 网络团队已接受过 Palo Alto、Fortinet 或 Check Point 的培训。
* **现有合同** – 已签订的企业许可协议和支持渠道。
* **混合云一致性** – 在本地和 Azure 中使用同一供应商的防火墙。
Azure 防火墙是一项 **完全托管的 PaaS 服务**，非常适合希望获得简单、云原生解决方案且无需担心底层基础设施的客户。然而，许多企业在实施其登陆区域时仍会选择 **第三方防火墙设备** (如 Palo Alto、Fortinet、Check Point 等)。这一决策通常取决于 **功能、熟悉度和企业战略**。
#### 选择第三方防火墙的关键原因
1. **功能深度与高级安全性**
* 第三方供应商提供的高级功能包括：
* 用于应用感知过滤的 **深度包检测 (DPI)**。
* **入侵检测和防御系统 (IDS/IPS)**。
* **SSL/TLS 解密与检测**。
* **高级威胁情报源、恶意软件防护、沙箱和僵尸网络检测**。
* 尽管 Azure 防火墙在不断发展，但这些供应商在高级威胁防护领域拥有更长的历史。
2. **运维熟悉度与技能**
* 网络和安全团队通常拥有多年在本地管理 Palo Alto、Fortinet 或 Check Point 设备的经验。
* 在 Azure 中采用相同的技术可以减少学习曲线，确保 **更快的故障排查、更平稳的运维以及对现有操作手册的复用**。
3. **与现有安全生态系统的集成**
* 许多组织已经在使用特定供应商的 **管理平台** (例如，Palo Alto 的 **Panorama**、Fortinet 的 **FortiManager** 或 Check Point 的 **SmartConsole**)。
* 将相同的工具扩展到 Azure，可以实现跨本地和云的 **集中式策略管理**，确保一致的策略执行。
4. **合规性与法规要求**
* 某些行业 (如金融、医疗、政府) 要求使用 **经过验证和认证的防火墙供应商** 来满足安全合规性。
* 客户可能已经拥有经审计师验证的第三方解决方案，并倾向于将其扩展到 Azure 以保持一致性。
5. **混合云与多云战略对齐**
* 许多企业采用 **混合模式**，工作负载分布在本地、Azure、AWS 或 GCP。
* 第三方防火墙可在 **不同环境中提供统一的安全层**，从而简化多云运维和治理。
6. **定制化与灵活性**
* 与 Azure 防火墙这种后端可见性有限的托管服务不同，第三方防火墙让管理员可以 **完全控制操作系统、补丁、高级路由和自定义集成**。
* 在支持复杂或非标准工作负载时，这种灵活性至关重要。
7. **许可优势 (BYOL)**
* 拥有现有企业协议或批量折扣的企业可以 **将自己的防火墙许可 (BYOL)** 带到 Azure。
* 与即用即付的 Azure 防火墙定价相比，这通常能降低成本。
#### 何时 Azure 防火墙可能依然足够
* **安全需求简单** 的组织 (基本的南北向流量检测、FQDN 过滤)。
* 偏好托管服务、希望 **基础设施开销最小化** 的 **云优先团队**。
* 希望避免 **手动扩展和虚拟机补丁管理** 的客户，这些是基础设施即服务 (IaaS) 设备固有的工作。
在实践中，许多大型组织采用 **混合方法**：将 Azure 防火墙用于轻量级场景或特定环境，而将第三方防火墙用于需要 **高级检测、供应商一致性和合规认证** 的企业级工作负载。
## 3. Azure 中的部署模型
Azure 中的第三方防火墙主要是以虚拟机 (VM) 形式部署的 **基于 IaaS 的设备**。主流供应商会发布 **Azure Marketplace 镜像** 和 **ARM/Bicep 模板**，从而实现在多个环境中的快速、可重复部署。这些防火墙使组织能够执行高级网络安全策略、进行深度包检测，并与虚拟网络 (VNet) 对等互连、Azure Monitor 和 Azure Sentinel 等 Azure 原生服务集成。
**注意：** 一些供应商现在也推出了其防火墙的 **PaaS 版本**，提供操作简化的托管防火墙服务。然而，本文将主要关注 **基于 IaaS 的防火墙部署**。
#### 常见部署模式
1. **双活模式 (Active-Active)**
* **描述：** 在此模式下，多个防火墙虚拟机同时运行，分担流量负载。一个 **Azure 负载均衡器** 将入站和出站流量分配到所有活动的防火墙实例。
* **使用场景：** 适用于需要 **高吞吐量**、**高弹性** 和 **接近零停机时间** 的环境，例如企业数据中心、多区域部署或关键任务应用。
* **注意事项：**
* 需要仔细进行防火墙实例间的 **路由和策略同步**，以确保流量处理的一致性。
* 通常涉及 **BGP 或用户定义路由 (UDR)**，以实现最佳的流量引导。
* 扩展更容易：可以在负载均衡器后添加额外的防火墙虚拟机来应对流量高峰。
2. **主-备模式 (Active-Passive)**
* **描述：** 一台防火墙虚拟机处理所有流量 (**活动**)，而另一台 (**备用**) 则处于待机状态以备故障切换。当活动节点发生故障时，Azure 服务主体会管理 IP 地址的重新分配和流量重路由。
* **使用场景：** 适用于 **管理更简单**、**运维复杂度更低** 的环境，而非追求持续的负载均衡。
* **注意事项：**
* 故障切换可能会导致 **短暂的停机**，通常在几秒到几分钟之间。
* 主备节点之间的同步可确保防火墙的 **策略、会话和配置** 得以镜像。
* 推荐用于较小规模的部署或流量模式可预测的场景。
#### 网络接口 (NIC)
第三方防火墙虚拟机通常包含 **多个网络接口 (NIC)**，每个接口专用于特定类型的流量：
1. **非信任/公共 NIC (Untrust/Public NIC):** 连接到互联网或外部网络。处理入站/出站的公共流量，并执行边界安全策略。
2. **信任/内部 NIC (Trust/Internal NIC):** 连接到私有 VNet 或子网。管理应用层之间的内部流量，并执行内部分段策略。
3. **管理 NIC (Management NIC):** 专用于防火墙管理流量。将管理流量与数据平面流量分离，从而提高安全性并减少性能干扰。
4. **高可用性 NIC (HA NIC，用于主-备模式):** 促进主备防火墙节点之间的同步，确保会话和配置状态在故障切换时得以保持。
这一设计决策通常在登陆区域设计阶段做出，旨在平衡 **安全要求、预算和运维成熟度**。
**图 1:** 在两套防火墙集群场景中，Palo Alto 外部防火墙和 FortiGate 内部防火墙的 NIC 配置
## 4. 关键配置注意事项
在 Azure 中部署第三方防火墙时，有几个设计和配置要素对于确保 **安全性、性能和高可用性** 至关重要。这些考量应与组织的安全策略、合规要求和运维实践紧密结合。
#### 路由
* **用户定义路由 (UDR):**
* 在 **分支虚拟网络** 中定义 UDR，以确保所有出站流量都流经防火墙，从而在流量到达互联网或其他虚拟网络之前强制执行检测和安全策略。
* 集中式路由有助于在多个应用虚拟网络中实现标准化的控制。
* 根据架构的流量流设计，在分支虚拟网络的 UDR 上使用适当的负载均衡器 IP 作为下一跳。
* **对称路由 (Symmetric Routing):**
* 确保流量
* 避免 **非对称路由 (asymmetric routing)**，这可能导致有状态防火墙丢弃返回的流量。
* 在支持的情况下，利用 **BGP 与 Azure Route Server** 来简化中心辐射型拓扑中的路由传播。
**图 2:** 将来自 Spoke VNET 的所有流量定向到防火墙 IP 地址的 Azure UDR
#### 策略
* **NAT 规则:**
* 配置 **DNAT (目标 NAT)** 规则，以安全地将应用程序发布到互联网。
* 当工作负载访问外部资源时，使用 **SNAT (源 NAT)** 来隐藏私有 IP。
* **安全规则:**
* 为 **南北向流量** (互联网到 VNet) 和 **东西向流量** (虚拟网络或子网之间) 定义精细的 **允许/拒绝规则**。
* 通过仅允许必需的端口、协议和目标来确保最小权限原则。
* **分段 (Segmentation):**
* 应用防火墙策略来隔离 **工作负载、环境和租户** (例如，生产环境 vs. 开发环境)。
* 通过隔离受 **法规标准** (PCI-DSS、HIPAA、GDPR) 约束的工作负载来强制执行合规性。
* **应用感知策略 (Application-Aware Policies):**
* 许多供应商支持第 7 层检测，从而能够基于 **应用程序、用户和内容** (而不仅仅是 IP/端口) 进行控制。
* 与 **身份提供商 (Azure AD、LDAP 等)** 集成，以实现基于用户的防火墙规则。
**图 3:** Palo Alto 外部防火墙上 NAT 规则的配置示例
#### 负载均衡器
* **内部负载均衡器 (ILB):**
* 使用 ILB 对虚拟网络或子网之间的 **东西向流量** 进行检测。
* 确保应用程序之间的流量无论来源如何，都始终通过防火墙。
* **外部负载均衡器 (ELB):**
* 使用 ELB 处理 **南北向流量**，负责互联网的流入和流出。
* 在 **双活防火墙集群** 中是必需的，用于在防火墙节点之间均匀分配流量。
* **其他配置:**
* 为防火墙实例配置健康探测，以确保故障节点被自动绕过。
* 根据相应供应商的建议，验证负载均衡规则上的浮动 IP 配置。
#### 身份集成
* **Azure 服务主体 (Azure Service Principals):**
* 在 **主-备部署** 中，配置服务主体以在故障切换期间实现自动 **IP 重新分配**。
* 这确保了服务的持续可用性，无需手动干预。
* **基于角色的访问控制 (RBAC):**
* 将防火墙管理与 **Azure RBAC** 集成，以控制谁可以部署、管理或修改防火墙配置。
* **SIEM 集成:**
* 将日志流式传输到 **Azure Monitor、Sentinel 或第三方 SIEM**，用于审计、监控和事件响应。
#### 许可
* **即用即付 (PAYG):**
* 从 **Azure Marketplace** 部署时，许可费用已捆绑在虚拟机成本中。
* 最适合 **短期项目、概念验证 (PoC) 或可变工作负载**。
* **自带许可 (BYOL):**
* 企业可将其与供应商签订的现有合同和许可应用于 Azure 部署。
* 对于 **大规模、长期** 的部署通常更具成本效益。
* **混合许可模型:**
* 一些供应商支持从本地到 Azure 的 **许可迁移**，从而减少成本的重复。
## 5. 常见挑战
Azure 中的第三方防火墙提供了强大的安全控制，但组织在日常运维中常常面临实际挑战：
* **配置错误 (Misconfiguration)**
* 不正确的 **UDR、路由表或 NAT 规则** 可能导致流量被丢弃或检测被绕过。
* **非对称路由** 是中心辐射型拓扑中的常见问题，会导致有状态防火墙的会话中断。
* **性能瓶颈 (Performance Bottlenecks)**
* 防火墙的吞吐量取决于 **VM SKU (CPU、内存、NIC 限制)**。
* 规格过低会导致延迟和丢包，而规格过高则会增加不必要的成本。
* 持续监控和参考供应商的规模指南至关重要。
* **故障切换停机时间 (Failover Downtime)**
* **主-备模式** 在重新分配 IP 和路由时会引入短暂的服务中断。
* 即使有状态同步，某些会话也可能丢失，这使得双活模式对关键任务工作负载更具吸引力。
* **备份与恢复 (Backup & Recovery)**
* Azure Backup 不支持供应商防火墙的操作系统。
* 配置必须 **导出并存储在外部** (例如，存储账户、代码仓库或供应商管理工具)。
* 如果没有适当的备份，从故障或配置错误中恢复可能会非常缓慢。
* **Azure 平台的连接数限制**
* Azure 对 **每台虚拟机的活动连接数上限为 250,000**，无论防火墙供应商设备本身支持多少。
* 这意味着即使设备设计用于处理数百万个会话，它也会受到 Azure 网络架构的限制。
* 达到此上限可能导致在 CPU/内存充足的情况下出现无法解释的流量丢弃。
* 解决方法是 **横向扩展** (在负载均衡器后部署多个防火墙虚拟机) 并仔细监控连接分布。
## 6. 第三方防火墙部署的最佳实践
为了最大化 Azure 中第三方防火墙的安全性、可靠性和性能，组织应：
* **部署在可用区 (Availability Zones) 中：**
将防火墙实例部署在 **不同的可用区**，以确保区域内的弹性，并在区域级故障时将停机时间降至最低。
* **关键工作负载优先选择双活模式：**
在要求 **零停机** 的场景下，使用 Azure 负载均衡器后的双活集群。主-备模式可能更简单，但会引入故障切换延迟。
* **为接口使用专用子网：**
将 **信任、非信任、高可用性和管理 NIC** 分隔到各自的子网中。这可以强制实现分段，简化路由管理，并降低配置错误的风险。
* **应用最小权限策略：**
始终从 **全部拒绝的基线** 开始，然后仅允许必要的应用程序、端口和协议。定期审查规则以避免策略泛滥。
* **标准化命名与标记：**
为防火墙、子网、路由表和策略采用一致的 **命名约定和资源标签**。这有助于故障排查、自动化和合规性报告。
* **验证端到端的流量流：**
部署后测试 **南北向 (互联网 ↔ VNet)** 和 **东西向 (VNet ↔ VNet/子网)** 的流量流。使用 **Azure 网络观察程序 (Azure Network Watcher)** 和供应商的流量日志来确认流量是否被检测。
* **规划可扩展性：**
监控 **吞吐量、CPU、内存和会话数**，以预测何时需要横向扩展或升级 VM SKU。一些供应商支持 **自动扩展集群** 以应对突发性工作负载。
* **维护固件和威胁签名：**
定期更新防火墙的 **软件、补丁和威胁情报源**，以确保能够抵御新出现的漏洞和攻击。尽可能自动化更新过程。
## 结论
第三方防火墙仍然是许多企业 Azure 登陆区域的核心组成部分。它们提供了企业所需的深度安全控制和运维熟悉度，而 Azure 则为托管它们提供了可扩展的基础设施。
通过
更新于 2025 年 10 月 15 日
版本 1.0
<!-- AI_TASK_END: AI全文翻译 -->