在 Azure 中为区域 Web 应用程序设计安全中心辐射型网络

在Azure中托管 Web 应用程序时，选择的网络设计将确定基础结构受到攻击的多少。 如果没有有意的设计，团队通常会保留默认配置、向 Internet 公开管理端口或跳过应用程序层检查，所有这些都会增加攻击面。

本文介绍一种可重复的体系结构模式，该模式使用最小 中心辐射型拓扑 为单区域 Web 应用程序构建安全默认基础。 中心虚拟网络托管诸如 Azure Bastion 的共享服务，而分支虚拟网络包含您的工作负荷，无论是在 Azure App Service（PaaS）上运行还是在虚拟机（IaaS）上运行。 该模式通过添加辐条从单个 Web 应用扩展到多个工作负荷。

该模式遵循分层方法。 中心辐射虚拟网络构成了基础，虚拟网络（VNet）对等互连连接它们，而网络安全组（NSG）在每个子网边界添加默认拒绝访问控制。 更高级别的服务包括辐射网络中的应用程序网关与Web应用程序防火墙（WAF）、中心内的Azure Bastion，以及跨两者的DDoS防护。 每个层都取决于下面的层。 本文后面的 “部署步骤” 部分将详细介绍建议的顺序。

此模式适用于小型或中型组织中的网络工程师和架构师，他们需要：

• 使用可随时扩展的中心辐射型拓扑将共享服务与工作负荷分开。
• 将具有 WAF 的应用程序层网关置于每个 Web 工作负载的前面。
• 在子网级别强制实施默认拒绝流量规则。
• 消除对后端虚拟机的直接 RDP/SSH 暴露。
• 当威胁分析需要时，保护公共 IP 免受大流量 DDoS 攻击。
• 保持设计简单，无需专门的网络专业知识即可部署。

建筑

后端计算模型（IaaS 或 PaaS）确定中心需要哪些共享服务。 这两种变体都采用相同的中心辐射模型，包含 VNet 对等互连，每个子网上都有 NSG，以及条件 DDoS 防护措施。

IaaS 后端 （Virtual Machines）

当后端包含 VM 时，Internet 流量通过分支中带 WAF 的应用程序网关流向专用工作负荷子网中的后端 VM。 中心托管 Azure Bastion 用于跨对等网络拓扑分支进行安全的 RDP/SSH 管理，NAT 网关为专用工作负荷子网提供明确的出站连接。 中心中的Azure Firewall是可选的，当需要基于 FQDN 的筛选时提供集中式出口控制。

PaaS 后端 （应用服务）

当后端是 PaaS 时，Internet 流量通过分支中带 WAF 的应用程序网关流向工作负荷子网中的应用程序服务。 你不需要 Bastion，因为没有 OS 级别的访问需要管理。 中心适用于可选的共享服务（Azure Firewall）和未来增长。 始终预配 VNet 对等互连;仅当Azure Firewall处理集中式出口时，它才会携带活动流量。

该体系结构使用通过 VNet 对等互连连接的两个虚拟网络：

中心虚拟网络 - 托管工作负荷使用的共享服务。 在此最小模式中，中心包含用于安全 VM 管理的Azure Bastion。 随着组织的发展，中心还可以托管 Azure Firewall，以实现集中式出口控制，或托管用于本地连接的 VPN 或 ExpressRoute 网关，或集中式 DNS。

辐射式虚拟网络，包含特定于工作负荷的资源。 Internet 流量到达与 Azure Application Gateway 关联的公共 IP 地址，该地址在专用辐射子网中充当第 7 层反向代理。 WAF 策略先检查针对 OWASP 核心规则集规则的每个 HTTP/HTTPS 请求，然后再将流量转发到后端池。 后端池包含专用工作负载子网中的 PaaS 终结点（例如应用服务）或 IaaS 资源（虚拟机或虚拟机规模集）。

VNet 对等互连通过 Azure 主干网提供低延迟、高带宽的连接，实现了中心与辐射网络之间的互连。 对等连接具有非传递性 — 每个辐射只连接到中心，而不连接到其他辐射 — 默认情况下强制实施负载隔离。

网络安全组 （NSG）在两个虚拟网络中的每个子网上强制实施默认拒绝规则。 应用程序网关子网允许入站 HTTPS 和必需的 GatewayManager 运行状况探测端口。 工作负荷子网仅接受来自应用程序网关子网的流量。 当后端系统包含 VM 时，Azure Bastion 在中心通过对等互连连接提供安全的 RDP/SSH 访问。 当存在面向 Internet 的公共 IP 时，Azure DDoS 防护可抵御第 3 层和第 4 层的批量和协议攻击。

此模式中的每个组件都有一个明确的角色：

为什么使用中心辐射而不是单个虚拟网络？

最初设置具有所有资源的单个虚拟网络更简单，但随着组织的增长，它会产生问题：

• CIDR 冲突阻止对等互连。 如果你从单个虚拟网络开始，后来需要将其与中心对等，地址空间不能重叠。 在正在运行的工作负载上修改 CIDR 范围通常需要进行重新部署。
• 不能重复使用共享服务。 你在工作负荷虚拟网络中部署每个新工作负荷时，必须复制其堡垒、DNS 和监控资源。
• 无隔离边界。 所有工作负荷共享相同的网络边界，因此，一个工作负荷中的妥协影响更大。

本文中的最小中心-辐射结构仅添加一个额外的虚拟网络和一个对等互联链接。 增量的复杂性很小，大致相当于创建一个 NSG；但该体系结构已可以扩展，无需重新设计。

部署步骤

此基础是分层构建的。 每个层都依赖于前一层，因此按以下顺序进行部署：

网络基础：VNet 和子网规划

在部署任何安全服务之前，请同时创建虚拟网络并调整所有子网的大小。 此模式中的每个组件都需要特定的子网，有些组件具有严格的命名和大小调整要求。

中心虚拟网络

集线器刻意设计得很小。 它托管分支使用的共享服务。

辐射型虚拟网络

这个节点包含了特定于工作负载的资源。 每个新工作负荷都有自己的分支。

中心辐射型 CIDR 规划

在首次部署之前，为两个 VNet 规划 CIDR 范围。 地址空间不得重叠。 如果 CIDR 范围发生冲突，VNet 对等互连将失败。 采用以下方法实现精简中心-辐射结构：

VNet 对等互连

虚拟网络对等互连通过使用Azure主干为枢纽和辐条提供低延迟连接。 将路由协议对等配置为双向，使流量在两个方向上流动。

• Hub → Spoke：使 Bastion 能够到达 VM，Azure Firewall（如果存在）能够检查分支流量。
• 辐射→集线器： 允许工作负载使用共享集线器服务。

密钥对等互连设置：

使用 NSG 进行网络分段

中心和分支虚拟网络均使用 NSG 在每个子网边界强制实施默认拒绝规则。 通过使用每个角色（应用程序网关、工作负荷、Bastion 和可选防火墙）的单独子网，可以使用 NSG 精确控制流量。

部署时的基本信息

• 将 NSG 与这两个 VNet 中的每个子网相关联。 从拒绝所有入站规则开始。 仅为设计所需的流量添加显式允许规则。
• 应用程序网关子网规则（边缘网络）： 允许从互联网接入入站 HTTPS 端口 443。 允许从 GatewayManager服务标记 入站到端口 65200-65535（该入站是 v2 健康探测所需的）。 允许AzureLoadBalancer服务标记。
• 工作负荷子网规则（分支）：仅允许来自应用程序网关子网的应用程序端口入站。 拒绝所有其他入站流量。
• Bastion 子网规则（中心）： 严格遵循 Bastion NSG 要求 。 Bastion 具有特定的入站和出站规则，必须应用这些规则以确保连接在对等互连的 VNet 上正常工作。
• 限制出口。 使用 NSG 出站规则拦截不需要的出站流量。 对于大多数区域 Web 应用，将出口限制为已知的Azure服务目标已足够。 如果需要基于 FQDN 的筛选，请在枢纽虚拟网络中添加 Azure Firewall（请参阅 使用 Azure Firewall 实现集中式出口）。
• 启用流日志。虚拟网络流日志 捕获流量模式，以便进行安全分析和故障排除。 如果仍使用 NSG 流日志，请在 2027 年 9 月 30 日 NSG 流日志停用之前 迁移到 VNet 流日志 。

DDoS 防护：是否需要？

Azure DDoS 基础结构保护和Azure DDoS 防护是单独的服务。 所有具有公共 IPv4 和 IPv6 地址的Azure服务都会收到 Azure DDoS 基础结构保护，无需额外付费。 但是，基础结构保护是保护整个 Azure 平台的，它的操作阈值高于大多数单个应用程序可以处理的水平，并且不在资源级别保护客户资源。 它不提供对特定流量模式的自适应优化、无诊断或警报以及无响应支持。 对于接受来自公共 Internet 的流量的工作负荷，请启用 DDoS 保护计划（网络保护或 IP 保护），以获取资源级自适应优化、攻击诊断、快速响应支持和成本保护保证。 不要仅依赖基础结构保护来保护服务。

决策非常简单：

• 面向 Internet 的公共 IP →启用 DDoS 防护。 根据保护的公共 IP 数量选择等级。 不要仅依赖基础结构保护来处理面向客户的工作负载。
• 专用（无公共 IP）或Azure Front Door → DDoS 保护计划是可选的。 Front Door 包含集成的 DDoS 保护。 仅限私人访问的资源没有可以被攻击的公共终结点，但单靠基础设施保护无法提供资源级别的安全保证。

在中心辐射型拓扑中，将 DDoS 防护计划链接到中心和分支 VNet，以便任一网络中的公共 IP 均受保护。

有关详细信息，请参阅 Azure DDoS 防护层比较。

使用 WAF 的应用程序网关

应用程序网关是一个区域第 7 层负载均衡器，专为 Web 流量构建。 WAF_v2 SKU 针对 SQL 注入、跨站点脚本和其他常见 Web 攻击提供基于 OWASP CRS 的保护。 它支持自动缩放、区域冗余和静态 VIP。

将应用程序网关部署到分支虚拟网络中其专用的子网 — 靠近它保护的工作负荷。 将入口流量保持在辐射节点中，避免通过中心不必要地路由 Internet 流量。

何时选择其他选项： 如果您需要在多个 Azure 区域之间进行全局负载均衡，请使用Azure Front Door 加 WAF。 如果流量不是 HTTP/HTTPS（例如原始 TCP 或 UDP），请在第 4 层使用 Azure Load Balancer。

部署时的基本信息

• 使用 WAF 策略，而不是旧版 WAF 配置。 从 2025 年 3 月 15 日起，无法在 WAF v2 上创建新的 WAF 配置部署。 在 2027 年 3 月 15 日之前将现有配置迁移到 WAF 策略。 Web 应用防火墙策略提供每站点和每 URI 规则粒度、机器人防护和下一代 Web 应用防火墙引擎。
• 在检测模式下启动，在生产之前切换到“预防”。 检测模式会记录威胁而不阻止它们，让你有时间优化规则并识别误报。 对所有生产工作负荷使用预防模式。
• 将子网大小调整为 /24。 应用程序网关 v2 最多支持 125 个实例，并且需要 专用子网。 /24 提供 251 个可用于自动缩放和维护升级的可用地址。
• 将 TLS 证书存储在Azure Key Vault中。 将 Key Vault 集成与托管标识配合使用，实现自动证书轮换。 此方法消除了手动管理证书的需求，并防止因证书过期导致的中断。
• 从第一天启用诊断日志记录。 将访问日志、防火墙日志和性能指标发送到 Log Analytics 工作区。 如果没有日志，则无法调查安全事件或优化 WAF 规则。

有关安全强化指南，请参阅 Secure Azure Application Gateway。 有关大小和性能建议，请参阅 应用程序网关 v2 的体系结构最佳做法。

中心Azure Bastion：PaaS 与 IaaS 决策

是否需要Azure Bastion完全取决于后端计算模型：

为什么 Bastion 住在中心

将 Bastion 放置在中心虚拟网络中时，只需部署一次，即可用于管理所有对等辐射网络中的 VM。 如果将 Bastion 放在每个分支中，则每个新工作负载都需要自己的 Bastion 实例，这会增加成本和管理开销。

基本 SKU 及更高版本支持虚拟网络对等互连，因此中心中的 Bastion 可以连接到任何对等互连分支中的 VM。 有关开发人员、基本、标准和高级 SKU 的完整功能比较，请参阅 Bastion SKU 比较。

部署时的基本信息

• 在专用的 AzureBastionSubnet /26 或更大子网中部署 Bastion。 Azure需要此确切的子网名称，并且无法与其他资源共享它。
• 请使用高级 SKU 以处理生产工作负荷。 高级版支持专用部署（无需公共 IP）、符合性会话记录和主机缩放（2-50 个实例）。 与标准的成本差异是微小的。 对于较小部署，基本 SKU 是可接受的最低配置 — 它提供专用实例并支持 VNet 对等互连。 开发人员 SKU 使用共享基础结构，不支持对等互连，不适用于生产。
• 遵循 Bastion NSG 要求。 Bastion 子网具有必须完全应用的特定入站和出站规则。 缺少规则会导致连接失败。 当 Bastion 位于中心时，确保分支工作负荷子网的 NSG 允许来自中心 VNet 地址空间的入站 RDP（3389 端口）或 SSH（22 端口）。
• 为 SSH/RDP 启用Microsoft Entra ID身份验证。 Entra ID身份验证消除了分发 SSH 密钥或本地密码，并启用 MFA 和条件访问策略。 门户中通过 Entra ID 的 SSH 已正式发布；门户中通过 Entra ID 的 RDP 处于公共预览阶段。 基本 SKU 支持门户中Entra ID身份验证;本机客户端连接需要标准 SKU 或更高版本。 有关设置说明，请参阅 Azure Bastion 的 Entra ID 身份验证。

使用Azure Firewall集中出口（可选）

对于需要基于 FQDN 的出站筛选、TLS 检查或所有出口流量的集中日志记录的组织，请将 Azure Firewall 添加到中心虚拟网络。 在此模式中，Azure Firewall 是可选的 - NSG 提供基本的出口控制，并且许多初创公司在没有 Azure Firewall 的情况下也能成功运营。

何时添加Azure Firewall

如果选择添加它，

• 中小型企业使用基本 SKU。 Azure Firewall Basic 支持高达 250 Mbps 的吞吐量和成本低于标准或高级 SKU。 它专为小型和中型环境而设计。 有关选择 SKU 的帮助，请参阅 选择正确的Azure Firewall SKU。
• 在中心的 AzureFirewallSubnet (/26) 子网中部署。 Azure Firewall Basic 还需要专用的 AzureFirewallManagementSubnet （/26） 将管理流量与客户流量分开。 在部署防火墙之前创建这两个子网。
• 在分支子网上创建 UDR，默认路由 (0.0.0.0/0) 指向防火墙的专用 IP。 此路由强制所有出站流量通过中心进行检查。
• 从简单开始。 从一小部分应用程序和网络规则开始。 在了解工作负荷的流量模式时添加规则。

出站访问和专用子网

从 2026 年 3 月 31 日起，Azure中的新虚拟网络默认为 private 子网（defaultOutboundAccess设置为 false）。 专用子网中的 VM 不会从Azure接收隐式出站公共 IP - 需要显式出站方法才能访问公共终结点。 此更改符合Zero Trust原则：上一个默认值分配了一个Microsoft拥有的 IP 地址，该地址可能会随时更改，从而使出站流量不可预知。 有关详细信息，请参阅 Azure 中 VM 的默认出站访问。

对于体系结构而言，这意味着什么

此模式中的工作负荷子网需要显式出口路径。 选择符合要求的方法：

用于显式出站的 NAT 网关

如果不需要基于 FQDN 的筛选，请向工作负荷子网附加 NAT 网关 ，以建立明确的可预测出站连接。 NAT 网关提供静态出站 IP，支持高达 50 Gbps 吞吐量（标准 SKU），无需 UDR。

NAT 网关 V2（StandardV2 SKU） 在所有可用性区域、IPv6 支持和 100 Gbps 吞吐量上提供区域冗余操作，其价格与标准 SKU 相同。 部署新的 NAT 网关时，首选 StandardV2（如果可用）。 请注意当前限制：StandardV2 要求 StandardV2-SKU 公共 IP（标准公共 IP 不兼容），尚不支持 Terraform，并且在所有区域中都不可用。 有关完整比较，请参阅 NAT 网关 SKU 比较。

标识和访问控制

在所有网络资源中使用 Microsoft Entra ID 进行基于角色的访问控制（RBAC）：

• 尽可能分配 内置角色 ，例如 网络参与者 ，而不是自定义角色。
• 对于运行应用程序网关的用户和服务主体，至少需要 Microsoft.Network/virtualNetworks/subnets/join/action 和 subnets/read。
• 使用 托管标识 为应用程序网关访问 Key Vault—不要存储凭据。

要避免的错误

出现问题时

应用程序网关返回 502 错误网关

首先检查： 验证应用程序网关子网 NSG 是否允许从 GatewayManager访问端口 65200-65535。 确认后端运行状况探测设置与应用程序的侦听端口和路径匹配，并且后端在探测终结点上返回 HTTP 200-399。

常见原因： 启用端到端 TLS 时，阻止 GatewayManager 的运行状况探测、配置错误的自定义运行状况探测、后端应用崩溃或 TLS 证书不匹配 。

WAF 阻止合法流量（误报）

首先检查： 启用 WAF 诊断日志，并按阻止的操作进行筛选。 标识规则 ID（例如， 942130 用于 SQL 注入检测），并确定匹配项是否在身份验证令牌等安全内容上。

修复： 使用 WAF 排除列表省略特定请求属性，或在 WAF 策略中按规则使用排除项。

无法通过 Bastion 连接到 VM

首先检查： 验证其 AzureBastionSubnet 是否为 /26 或更大。 检查中心的 Bastion 子网上的 NSG 是否具有 所需的规则。 确认分支中目标 VM 的 NSG 允许来自中心 VNet 地址空间的入站 RDP（3389 端口）或 SSH（22 端口）。

常见原因： Bastion 子网上缺少或不正确的 NSG 规则，Bastion SKU 不支持对等互连（开发人员 SKU）、子网太小或目标 VM 的 OS 级防火墙阻止连接。

对等互连显示“已断开连接”状态

首先检查： 验证对等连接的两端是否存在（中心到辐射节点和辐射节点到中心）。 必须在两个方向创建对等互连。 如果删除一侧，另一端显示“已断开连接”。

修复：删除剩余对等互连并重新创建双方。 确保 CIDR 地址空间不重叠。

后续步骤

• 将零信任原则应用于 Azure 中的中心虚拟网络
• 将 Zero Trust 原则应用于 Azure PaaS 服务中的辐射虚拟网络