网络安全

网络安全通过控制多个边界的流量，防止云工作负载受到未经授权的访问、数据泄露和服务中断等威胁。 与传统以外围为中心的防御不同，新式云环境需要具有分段、专用连接和边缘保护的深度防御策略，以解决动态攻击面，包括公开的服务、横向移动路径和命令和控制通道。 实施全面的网络控制的组织维护默认安全的环境，而忽视这些控制的组织将面临不受限制的横向移动和长期暴露的威胁。

下面是网络安全域的三大核心支柱。

保护网络边界： 通过多层深度防御在网络边缘和段之间强制实施严格的控制，包括防火墙、DDoS 防护、Web 应用程序防火墙和专用连接，遵循最低特权原则，默认拒绝未经授权的流量。

相关控件：

• NS-2：使用网络控制保护云服务
• NS-3：在企业网络边缘部署防火墙
• NS-5：部署 DDOS 保护
• NS-6：部署 Web 应用程序防火墙
• NS-9：私下连接本地或云网络

应用网络隔离： 将网络划分为与企业分段策略和风险级别一致的隔离段，以限制威胁传播、减少攻击面，并防止未经授权的横向移动。

相关控件：

• NS-1：建立网络分段边界

监视和响应： 通过全面监视、入侵检测和协议安全性持续了解网络活动，以快速识别可疑行为、策略冲突和活动威胁。

相关控件：

• NS-4：部署入侵检测/入侵防护系统（IDS/IPS）
• NS-8：检测和禁用不安全服务和协议
• NS-10：确保域名系统（DNS）安全性

NS-1：建立网络分段边界

Azure Policy： 请参阅 Azure 内置策略定义：NS-1。

安全原则

网络分段涉及将网络划分为较小的隔离段，以控制和限制云资源之间的流量流，以减少爆炸半径。

设计网络分段，以确保虚拟网络部署符合企业分段策略和不同的风险级别。 常见的分段策略包括：

• 将 Corpnet 与应用程序网络分开
• 单独的应用程序网络
• 单独的生产和测试环境网络

请参阅 Azure Well-Architected Framework，详细了解网络分段的关键策略：

• Azure 分段策略

待缓解风险

如果没有网络分段边界，组织将面临不受限制的横向移动，使攻击者能够遍历网络基础结构并破坏高价值资产。

• 平面网络曝光： 缺少分段可实现不受限制的横向移动，从而允许攻击者通过遍历非分区网络拓扑来破坏高价值资产。
• 特权提升路径： 边界不足允许未经授权的访问途径，通过访问敏感子网和工作负载促进用户特权升级。
• 恶意软件传播： 分段不足可快速传播恶意代码，例如跨互连节点的勒索软件，放大攻击面和作影响。
• 东西交通盲目： 不受限制的段间流量阻碍异常检测和事件响应，减少对内部威胁移动的可见性，并使取证分析复杂化。

MITRE ATT&CK

• 初始访问（TA0001）： 未经授权访问网络和公开的服务（例如 T1190 - Exploit Public-Facing Application）。
• 横向移动（TA0008）：通过 VNets 和非受限子网间流量进行攻击枢转（例如 T1021 - 远程服务）。
• 外泄（TA0010）： 通过非受限出站流量外泄数据，将未经授权的数据传输到外部服务器（例如 T1041 - 通过 C2 通道外泄）。
• 命令和控制（TA0011）： 通过防火墙规则和威胁情报（例如 T1071 - 应用程序层协议）与恶意 IP 或域通信来传播恶意软件。

NS-1.1：使用 VNet 和子网创建分段

虚拟网络隔离在云环境中建立基本安全边界，使组织能够按信任级别、组织单位或应用程序分组分隔工作负荷。 此方法可防止不受限制的横向移动，并在发生违规时减少爆炸半径，使网络体系结构与企业分段策略和零信任原则保持一致。

通过创建隔离的网络边界和细分来实现虚拟网络分段：

• 基于分段策略设计 VNet 拓扑： 创建与企业分段策略中定义的信任区域、组织单位或应用程序分组一致的 虚拟网络 ，确保每个 VNet 都表示不同的安全边界。

• 隔离高风险工作负荷： 确定需要严格隔离（例如生产数据库、付款处理系统）的工作负荷，并将其部署到专用隔离的隔离 VNet 中，以最大程度地减少暴露并防止交叉污染。

• 创建子网进行精细分段： 在每个 VNet 中， 创建不同的非重叠子网 ，以根据应用程序层（例如 Web 层、应用程序层、数据库层）或功能要求进一步细分网络，从而实现更精确的流量控制和微分段。

NS-1.2：使用 NSG 限制网络流量

网络安全组在子网和网络接口级别强制实施流量筛选，从而对网段与外部网络之间的通信流进行精确控制。 通过实施默认拒绝策略并使用显式允许规则，组织可确保只有授权流量跨越网络边界，从而防止未经授权的访问并减少攻击面。

使用 NSG 规则实现网络流量限制：

• 确定通信要求： 分析每个 VNet 中的资源，以了解其南北（外部）和东西（内部）流量通信需求，记录合法业务功能所需的端口、协议、源地址和目标地址。

• 定义显式允许和拒绝规则： 对于定义完善的应用程序（例如三层体系结构），请使用“默认拒绝，允许例外”方法基于端口、协议、源 IP 地址和目标 IP 地址 创建 NSG 规则 ，同时显式允许必要的流量，同时拒绝所有其他通信。

• 对复杂方案使用应用程序安全组： 当许多应用程序和终结点交互时，使用应用程序安全组（ASG）以逻辑方式（例如 Web 服务器、数据库服务器）对资源进行分组，然后基于这些组而不是显式 IP 地址定义 NSG 规则，从而提高可维护性并减少配置复杂性。

• 使用流日志监视和优化： 启用 虚拟网络流日志记录 以监视 NSG 规则允许或拒绝的流量，识别经常被拒绝的流量，这些流量可能指示配置错误或经常允许的流量，这些流量可以通知规则优化并减少日志记录干扰。

实现示例

组织需要通过单独的生产、开发和测试环境保护多层应用程序，同时防止未经授权的横向移动和外部访问。

挑战： 组织有一个三层应用程序（Web、应用程序、数据库），其中包含单个大型网络段中的所有资源，允许所有层和环境之间不受限制的通信。 这造成了重大安全风险，包括生产与非生产之间潜在的横向移动、数据库服务器的不受限制的 Internet 访问，以及无法隔离高风险工作负荷。

解决方案方法：

• 按环境划分的 VNet 分段： 为生产环境（10.0.0.0/16）、开发（10.1.0.0/16）和测试（10.2.0.0/16）环境创建了单独的虚拟网络，建立了网络隔离边界，防止跨环境访问并限制潜在违规的爆破半径。
• 按层划分的子网分段： 在生产 VNet 中，为每个应用程序层（Web 层（10.0.1.0/24）、应用程序层（10.0.2.0/24）和数据库层（10.0.3.0/24）创建不同的非重叠子网 -- 启用层之间的精细流量控制。
• 南北交通管制的 NSG 规则： 配置了 NSG 规则，以拒绝从 Internet（0.0.0.0/0）到内部子网的所有入站流量，并将出站 Internet 访问限制为仅受信任的目标，特定规则仅允许 Web 层的必要外部连接，同时阻止来自数据库层的所有 Internet 访问。
• 东西向流量控制的 NSG 规则：实施默认拒绝策略，显式规定层之间的允许规则 - Web 层仅在必需端口上允许出站到应用程序层，应用程序层仅在端口 1433 (SQL) 上允许出站到数据库层，数据库层拒绝来自除应用程序层子网外的所有其他入站流量。
• 远程管理访问： 受限的远程管理端口（RDP 3389/TCP，SSH 22/TCP）仅接受来自受信任的堡垒主机子网（10.0.0.0/26）的连接，从而消除了对管理接口的直接 Internet 访问。

结果： 组织消除了应用程序层和环境之间的不受限制的横向移动，通过从后端系统删除直接 Internet 访问来显著减少攻击面，并建立了与零信任原则一致的可强制网络边界。 流日志支持持续监视允许和拒绝的流量，以便持续优化和安全状况验证。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SC-7、SC-32、AC-4、CM-7
• PCI-DSS v4： 1.2.1、1.3.1、1.4.1
• CIS 控件 v8.1： 12.1、12.2、12.6
• NIST CSF v2.0： PR.IR-01, PR.AC-05
• ISO 27001：2022： A.8.20、A.8.21
• SOC 2： CC6.1、CC6.6

NS-2：使用网络控制保护云本机服务

Azure Policy： 请参阅 Azure 内置策略定义：NS-2。

安全原则

使用服务本机功能保护对资源的网络访问，以避免和减少资源暴露给不受信任的网络。 这些功能包括：

• 为资源建立专用接入点，以避免网络流量通过公用网络暴露。
• 将资源部署到虚拟网络中，可在其中限制 VNet 为服务建立专用接入点。
• 配置服务本机防火墙以限制入站流量或禁用公用网络访问。

注意：除了基本的网络访问控制和流量筛选之外，还应使用威胁检测功能监视 DNS（NS-10）等服务，以检测可能的数据外泄。

待缓解风险

威胁参与者利用公开的云服务来执行数据外泄、应用程序层攻击和流量拦截。

• 通过公共终结点外泄数据： 攻击者利用可公开访问的存储帐户、数据库或 API 通过建立对公开终结点的未经授权的连接、绕过网络分段控制并启用大规模数据盗窃来泄露敏感数据。
• 针对公共终结点的应用程序层攻击： 分布式拒绝服务（DDoS）攻击、SQL 注入和其他应用程序攻击针对公开的 Web 服务、API 和数据库，压倒性资源或利用漏洞导致服务中断或数据泄露。
• 中间人攻击： 攻击者截获通过公共网络流向公开的服务的流量，捕获凭据、会话令牌或传输的敏感数据，而无需进行足够的加密或专用连接，从而启用帐户接管或数据盗窃。

MITRE ATT&CK

• 初始访问（TA0001）：通过公共互联网曝光云服务（例如云存储服务、数据库服务）进行未经授权的访问，利用漏洞攻击公共端点（例如 T1190 - 利用面向公众的应用程序）。
• 外泄（TA0010）： 通过专用虚拟网络连接路由流量来泄露数据，从而减少向外部服务器泄露数据的风险（例如，T1041 - 通过 C2 通道外泄）。
• 横向移动（TA0008）： 攻击者在虚拟网络中转移服务，并在云资源之间进行未经授权的访问（例如，T1021 - 远程服务）。

NS-2.1 将专用链接用于服务连接

通过在虚拟基础架构中建立直接网络路径，专用网络连接消除了云服务暴露在公共互联网的风险。 专用链接在虚拟网络中创建具有专用 IP 地址的专用终结点，确保发往云服务的流量永远不会遍历公共 Internet，同时维护基于 DNS 的访问模式。 此方法可显著减少攻击面，并防止数据通过可公开访问的终结点外泄。

通过以下步骤实现云服务的专用连接：

• 为受支持的服务部署专用终结点：在虚拟网络中为支持专用链接（例如 Azure 存储、Azure SQL 数据库、Azure Key Vault）的 Azure 资源创建专用终结点，建立专用 IP 地址（例如，只能从 VNet 访问 10.0.2.4）。

• 配置专用 DNS 区域： 创建 Azure 专用 DNS 区域以替代公共 DNS 解析，确保完全限定的域名（例如 mystorageaccount1.blob.core.windows.net 解析为 VNet 中的专用 IP 地址，而不是公共终结点），从而使用基于 FQDN 的访问为应用程序保持无缝连接。

• 禁用公共访问： 配置服务级别设置以在部署专用终结点后完全禁用公共网络访问，确保所有流量完全通过专用连接进行流式处理，而无需回退到公共终结点。

注意： 某些 Azure 服务还可能允许通过 服务终结点 功能进行专用通信，但建议使用 Azure 专用链接来保护和专用访问 Azure 平台上托管的服务。 对于 Azure VM 上托管的 Web 服务等部署，请避免将公共 IP 直接分配给 VM，除非有充分的理由;而是使用 Azure 应用程序网关或 Azure 负载均衡器作为服务访问的前端。

NS-2.2 将服务部署到 VNet

虚拟网络集成使云服务能够在专用网络边界内运行，从而无需通过公共互联网，即可与虚拟网络托管资源建立直接连接。 通过将服务部署到虚拟网络中，组织可以通过安全组和路由表对网络流量进行精细控制，同时保持服务与外部威胁的隔离。

在支持的情况下部署具有 VNet 集成的服务：

• 将服务部署到虚拟网络： 对于支持 VNet 集成的服务（例如 Azure 应用服务、Azure Functions、Azure 容器实例），请将部署配置为新的或现有的虚拟网络，指定与分段策略相符的相应子网，并启用与其他 VNet 资源的专用通信。

• 配置网络安全控制： 将网络安全组（NSG）规则应用于服务的子网以限制入站和出站流量，通过仅允许与特定目标（例如数据库子网、存储终结点）进行必要的通信来实施最低特权访问，同时拒绝所有其他流量。

NS-2.3 配置服务原生防火墙

服务级别防火墙通过限制资源级别的网络访问来提供深层防御保护，从而补充网络层控制与特定于应用程序的安全边界。 这些本机防火墙功能使组织能够在适当的时候限制对特定 IP 范围或虚拟网络的暴露，同时完全禁用公共访问，从而减少攻击面，而无需复杂的网络拓扑更改。

配置服务防火墙以限制访问：

• 启用服务防火墙功能： 对于支持本机防火墙的服务（例如 Azure 存储、Azure SQL 数据库、Azure Key Vault），可在资源创建期间启用防火墙功能，或者在现有资源上启用防火墙功能，以控制哪些网络可以访问该服务。

• 定义基于 IP 的规则或基于 VNet 的规则： 配置防火墙规则以仅允许从特定公共 IP 范围（例如公司办公室网络）或特定的 Azure 虚拟网络子网进行访问，通过拒绝所有其他源来实现最低特权访问。

• 尽可能禁用公共访问： 如果服务仅需要从专用网络进行访问，请使用切换选项完全禁用公共网络访问，确保无论基于 IP 的规则如何，都无法从 Internet 访问该服务。

NS-2.4 使用网络安全外围进行 PaaS 资源隔离

网络安全外围围绕多个 PaaS 资源建立逻辑网络边界，从而在显式受信任的外围内启用安全的服务到服务通信，同时防止未经授权的数据外泄。 与每个资源控制不同，网络安全边界提供统一的安全边界，允许在不需要单独访问规则的情况下进行边界内通信，同时默认阻止外部访问。

实现网络安全外围来保护 PaaS 资源：

• 创建和关联资源： 建立 网络安全外围 ，并通过资源关联添加 支持的 PaaS 资源 （Azure 存储、SQL 数据库、Key Vault、事件中心、Cosmos DB），从而实现外围通信，使关联的资源可以自由通信。

• 配置访问模式和规则： 从转换模式开始，了解访问模式，然后再过渡到强制模式以实现最大保护。 使用 IP 地址、订阅或 FQDN 定义显式入站和出站访问规则，以控制外围外部的流量，同时保持默认拒绝状态。

• 启用监视和专用链接集成： 配置 诊断日志 以捕获访问尝试和策略冲突。 专用终结点流量会自动允许进入网络边界，从而增强 VNet 到 PaaS 的连接，并在边界级别实现数据泄漏控制。

实现示例

组织需要保护后端数据库和存储资源，同时允许应用程序服务访问这些资源，而无需将资源暴露在公共 Internet 上。

挑战： 组织具有具有默认公共终结点的 Azure SQL 数据库和 Azure 存储帐户，使其可从 Internet 访问，并产生重大数据外泄风险。 应用程序服务部署了公共 IP，并且缺少 VNet 集成，从而阻止基于专用网络的访问控制。 未配置服务级别防火墙，允许身份验证成功后从任何源进行不受限制的访问。

解决方案方法：

• PaaS 服务的专用链接终结点： 已在专用终结点子网（10.0.2.0/24）内部署 Azure SQL 数据库（分配专用 IP 为 10.0.2.4）和 Azure 存储帐户（分配专用 IP 为 10.0.2.5）的专用终结点，从而建立专用连接，使流量在 Azure 主干网络上路由，而不会暴露在 Internet 上。
• 用于名称解析的专用 DNS 区域： 创建了 Azure 专用 DNS 区域 来替代公共 DNS 解析，确保应用程序 FQDN（例如，mysqldb.database.windows.net、mystorageaccount.blob.core.windows.net）解析为 VNet 中的专用 IP，而不是公共终结点，从而使用基于 FQDN 的访问为应用程序保持无缝连接。
• 应用程序服务的 VNet 集成： 为 Azure 应用服务配置 了 VNet 集成 ，将应用程序部署到应用程序子网（10.0.1.0/24），以启用与专用终结点的直接通信，而无需公共 IP 地址或 Internet 路由。
• 服务本机防火墙： 已启用 Azure 存储上的 服务级别防火墙 ，以限制对特定 VNet 子网（应用程序子网 10.0.1.0/24）的访问和受信任的Microsoft服务，同时完全禁用 Azure SQL 数据库的服务级别的公共网络访问以强制实施专用连接。
• 用于深度防御的 NSG 规则： 对应用程序子网应用了 NSG 规则，允许仅向专用终结点子网（10.0.2.0/24）的所需端口（443 for Storage，1433 for SQL）发出出站流量），实现最低特权访问控制，以补充服务级别保护。

结果： 组织消除了后端资源的公共 Internet 暴露，大大减少了数据外泄风险和攻击面。 专用连接可确保应用程序和数据服务之间的所有流量都保留在 Azure 主干网络上，而无需遍历公共 Internet，而分层控制（专用链接、DNS 区域、服务防火墙、NSG）提供了与零信任原则一致的防御深度保护。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SC-7（4）、SC-7（5）、AC-4（21）
• PCI-DSS v4： 1.3.1、1.3.2、1.4.2
• CIS 控件 v8.1： 12.4、12.7
• NIST CSF v2.0： PR.AC-05, PR.DS-05
• ISO 27001：2022： A.8.20、A.8.22
• SOC 2： CC6.1、CC6.6

NS-3：在企业网络边缘部署防火墙

Azure Policy： 请参阅 Azure 内置策略定义：NS-3。

安全原则

使用网络边缘的防火墙对传入和传出外部网络（例如 Internet）的网络流量执行高级筛选，以及在内部网段之间执行高级筛选。

防火墙策略至少应包括：

• 阻止已知错误的 IP 地址和站点。
• 限制高风险协议，例如边缘网络上的远程管理协议和 Intranet 协议，以防止未经授权的访问或横向移动。
• 强制实施应用程序规则，以仅允许批准的外部目标，并阻止未经授权的或有风险的网站。

待缓解风险

攻击者利用通过可访问的协议、恶意域和弱网络控制向公共或不受信任的网络公开的漏洞。

• 通过公开的协议进行未经授权的访问： 通过 RDP（TCP 3389）或 SMB（TCP 445）等可公开访问的协议，攻击者可以通过暴力攻击或 CVE 目标攻击等攻击来破坏系统完整性。
• 通过恶意域/IP 进行恶意软件和网络钓鱼： 恶意域和 IP 通过命令和控制或社会工程攻击促进恶意软件传送或网络钓鱼活动，危及终结点和敏感数据。
• 通过不受限制的出站流量外泄数据： 不受控制的流出到未经批准的目标允许攻击者通过 HTTPS POST 等秘密通道外泄敏感数据、冒违规和合规性违规的风险。
• 由于网络分段不良导致横向移动： 网络分段不足使攻击者能够在网络内部横向移动，利用分段间流量（例如 SMB、Kerberos）从已受损的系统进行传播。
• 来自不受信任的应用程序/URL 的漏洞： 访问有风险或不受信任的 URL 和应用程序会增加攻击风险、提升事件风险和不符合法规标准的风险。

MITRE ATT&CK

• 初始访问（TA0001）： 未经授权访问高风险协议（例如 RDP/TCP 3389、SSH/TCP 22）或恶意域（例如 T1190 - 攻击 Public-Facing 应用程序）。
• 命令与控制（TA0011）：恶意软件连接到恶意 IP/域名（例如，T1071 - 应用层协议）。
• 数据外泄（TA0010）： 未经授权的数据通过出站流量传输到未经批准的目标（例如，T1041 - 通过 C2 通道的数据外泄）。
• 横向移动（TA0008）： 在未过滤的段间流量（例如 SMB/TCP 445、Kerberos/TCP 88）中抑制内部横移（例如 T1021 - 远程服务）。

NS-3.1 准备 Azure 防火墙部署

Azure 防火墙部署需要适当的网络拓扑，以便跨网络边界进行集中流量检查。 中心辐射型架构将防火墙置于网络核心位置，通过中央检查点路由所有分支流量，同时用户定义的路由确保流量流按照预期路径传递。 此准备为全面的边缘保护和段间筛选奠定了基础。

为 Azure 防火墙部署准备网络基础结构：

• 设置中心/辐射型虚拟网络拓扑： 在 中心 VNet 中部署 Azure 防火墙，以集中管理和保护托管应用程序工作负荷的多个辐射 VNet 之间的流量，从而为网络安全策略建立单一强制点。

• 加入分支虚拟网络： 使用 VNet 对等互连 将每个分支 VNet 连接到已部署 Azure 防火墙的中心 VNet，从而通过中心实现分支之间的通信，同时保持网络隔离。

• 配置用户定义的路由（UDR）： 创建路由表，以便将辐射 VNet 的网络流量通过中心网络中的 Azure 防火墙定向，包括互联网出口（0.0.0.0/0）的路由，如果辐射之间的通信需要检查，还可包括辐射间流量的路由。

NS-3.2 使用适当的策略部署 Azure 防火墙

Azure 防火墙通过跨企业网络段的集中式策略管理提供有状态应用程序层流量筛选。 通过结合网络规则、应用程序规则和威胁智能，防火墙会检查多个层的流量流，而 URL 筛选和 TLS 检查可实现对 HTTP/HTTPS 通信的精细控制。 适当的策略设计通过结构化规则层次结构和基于类别的筛选平衡安全需求与作需求。

使用全面的策略部署和配置 Azure 防火墙：

• 在中心 VNet 中部署 Azure 防火墙： 根据所需的功能，选择在中心 VNet 中部署 Azure 防火墙（标准层或高级层），为出互联网流量分配公共 IP 地址，并为从属 VNet 的内部路由分配专用 IP 地址。

• 使用筛选规则创建防火墙策略： 定义包含网络规则（基于 IP/端口的筛选）、应用程序规则（基于 FQDN 的筛选）和威胁情报规则的 Azure 防火墙策略 ，根据安全要求（例如，允许业务关键服务、阻止恶意 IP、拒绝风险类别）将规则组织到集合中。

• 为 HTTP/HTTPS 流量配置 URL 筛选： 实现 基于 FQDN 的应用程序规则 以允许或拒绝特定域（例如，允许 *.microsoft.com、拒绝 *.torrent），并配置 基于类别的筛选 ，以阻止整个网站类别（例如黑客攻击、社交媒体），同时允许与工作相关的类别。

• 为高级筛选启用 TLS 检查： 对于高级层部署，通过将证书上传到 Azure Key Vault 来启用 TLS 检查 ，使防火墙能够解密、检查和重新加密 HTTPS 流量，以便在基于 SNI 的检查之外进行更深入的 URL 筛选和威胁检测。

实现示例

具有多个应用程序工作负荷的组织跨不同的辐射型虚拟网络，需要对所有去往互联网的流量和辐射型虚拟网络之间的通信进行集中网络安全审查，同时防止访问恶意域和未经授权的网站类别。

挑战： 组织在单独的分支 VNet 中部署了具有直接 Internet 访问权限的工作负荷，创建了不一致的安全策略，并且无法集中检查流量。 每个分支都有自己的 NSG 规则，导致策略偏移和安全差距。 无法查看与潜在恶意域的出站连接，无法阻止有风险的网站类别（社交媒体、文件共享），也没有检查 HTTPS 流量内容。 辐射网络节点之间的流量在未经检查的情况下自由流动，使得在被攻陷后可能发生横向移动。

解决方案方法：

• 具有集中式防火墙的中心辐射型拓扑： 在中心虚拟网络(VNet)（10.0.0.0/16）中部署了 Azure Firewall Premium，使用专用 AzureFirewallSubnet（10.0.1.0/26，防火墙专用 IP 10.0.1.4），为所有网络流量检查和策略管理建立了一个单一的强制点。
• 分支连接的 VNet 对等互连： 使用 VNet 对等互连 将应用程序分支 VNet（10.1.0.0/16）和数据库分支 VNet（10.2.0.0/16）连接到中心 VNet，从而通过防火墙实现集中式流量路由。
• 用于流量引导的用户定义路由： 在每个辐射 VNet 中创建 路由表 ，将所有流向互联网的流量 (0.0.0.0/0) 和辐射网络之间的流量重定向到 Azure 防火墙专用 IP (10.0.1.4)，强制所有出口流量通过中央检查点。
• 使用多层筛选的防火墙策略： 定义全面的 Azure 防火墙策略 （包括网络规则（允许 DNS UDP/53 到 Azure DNS、默认拒绝所有其他协议）、应用程序规则（允许业务关键 FQDN（如 *.microsoft.com、拒绝文件共享域（如 *.torrent）和威胁情报规则（阻止已知恶意 IP 从 Microsoft Defender 威胁源）。
• URL 筛选和基于类别的阻止： 实现了 基于 FQDN 的应用程序规则 ，用于精确域控制和 基于类别的筛选 ，以阻止整个网站类别（黑客、社交媒体、赌博），同时允许与工作相关的类别（商业/经济、技术/Internet），在网络边缘强制执行可接受的使用策略。
• HTTPS 流量的 TLS 检查： 已启用 TLS 检查 ，其中存储于 Azure Key Vault 中的证书，允许防火墙解密、检查和重新加密 HTTPS 流量，以便在基于 SNI 的检查之外进行更深入的 URL 筛选和威胁检测，同时根据合规性要求排除敏感银行域解密。

结果： 组织建立了对所有面向互联网和辐射点间流量的集中可见性和控制，消除了策略偏离和安全盲点。 TLS 检查允许检测加密 HTTPS 流量中隐藏的威胁，而基于类别的筛选大大减少了对有风险的 Web 内容的暴露。 中心辐射型体系结构为所有工作负载提供了一种可缩放的、一致的安全态势，并且具有统一的策略管理和全面的威胁防护。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SC-7、SC-7（5）、AC-4、SI-4（4）
• PCI-DSS v4： 1.2.1、1.3.1、1.4.1、1.4.2
• CIS 控件 v8.1：9.2 、9.3、13.1
• NIST CSF v2.0： PR.AC-05, PR.PT-04, DE.CM-01
• ISO 27001：2022： A.8.20、A.8.22
• SOC 2： CC6.1、CC6.6、CC7.2

NS-4：部署入侵检测/入侵防护系统 (IDS/IPS)

安全原则

使用网络入侵检测和入侵防护系统（IDS/IPS）检查传入和传出工作负荷或虚拟网络的网络和有效负载流量。 确保不断调整 IDS/IPS，以向 SIEM 解决方案提供高质量的警报。

注意：有关更深入的主机级别检测和防护功能，请使用基于主机的 IDS/IPS 或基于主机的终结点检测和响应（EDR）解决方案与网络 IDS/IPS。

待缓解风险

攻击者利用协议、应用程序和内部流量中的漏洞来执行恶意活动。

• 协议攻击： RDP（TCP 3389）或 HTTP/HTTPS（TCP 80/443）等协议中的漏洞通过 CVE 目标攻击等漏洞启用未经授权的访问或系统入侵。
• 命令和控制 （C2） 通信： 恶意服务器通过 DNS 查询或基于 IP 的回调建立对已泄露设备的控制，从而促进持续利用或恶意软件传播。
• 应用程序攻击： SQL 注入、跨站点脚本（XSS）或缓冲区溢出等攻击会针对应用程序漏洞窃取数据或执行任意代码。
• 横向移动： 异常的内部流量，例如 SMB（TCP 445）枚举或 Kerberos（TCP 88）票证滥用，表明攻击者在网络中进行横向移动。
• 数据外泄： 通过加密通道（例如 HTTPS POST）或大容量出口（使用模糊处理来逃避检测）发生未经授权的数据传输。

MITRE ATT&CK

• 初始访问（TA0001）： 通过利用目标网络漏洞（例如 T1190 - 利用公共面向应用程序）进行未经授权的入侵。
• 执行（TA0002）： 恶意代码执行漏洞攻击或 C2 有效负载（例如 T1059 - 命令和脚本解释器）。
• 命令和控制（TA0011）： 恶意软件 C2 通信，方法是利用 DNS 查询或基于 IP 的回调（例如 T1071 - 应用程序层协议）。
• 横向移动（TA0008）： 异常的内部流量（例如 SMB 枚举）表明横向渗透行为（例如 T1021 - 远程服务）。
• 外泄（TA0010）： 通过加密通道或模糊通道（例如 T1041 - 通过 C2 通道外泄）进行未经授权的数据传输。

NS-4.1 为 IDPS 部署 Azure 防火墙高级版

入侵检测和防护系统通过匹配网络流量模式来针对已知攻击签名提供基于签名的威胁识别，从而实时阻止攻击尝试和恶意通信。 Azure 防火墙高级版的 IDPS 功能提供持续更新的签名库，包括攻击、恶意软件、命令和控制和网络钓鱼类别，同时同时支持仅警报模式和防护模式。 适当的签名选择和优化可确保高保真检测，同时最大程度地减少误报。

通过 Azure 防火墙高级版部署和配置 IDPS：

• 部署 Azure 防火墙高级版： 在中心 VNet 中使用高级策略部署 Azure 防火墙高级 版，以启用 IDPS 功能以及其他高级功能，例如 TLS 检查和 URL 筛选。

• 选择 IDPS 签名规则： 根据威胁优先级从签名库中选择 IDPS 签名规则 ，从“恶意软件”、“攻击”和“网络钓鱼”等关键类别中的高严重性签名开始，这些签名符合组织的威胁配置文件和风险容忍度。

• 配置 IDPS 模式： 最初将 IDPS 模式设置为警报模式，以便测试和优化以观察签名匹配，而不会阻止流量，然后转换为生产环境的警报和拒绝模式，以主动防止检测到的威胁，同时维护安全监视警报。

• 微调签名： 根据操作经验调整单个签名规则，对产生过多误报的签名进行禁用或降低优先级，同时确保高优先级签名保持活动状态，优化安全运营团队的信号噪声比。

实现示例

组织需要保护关键基础结构免受已知攻击和零日攻击，同时保持对威胁活动的可见性，而不会破坏合法的业务运营。

挑战： 该组织运营了一个多层次的 Web 应用程序，用于处理财务交易，但是没有基于签名的威胁检测机制，只有基本的防火墙规则。 安全团队对针对应用程序服务器的攻击尝试缺乏可见性，无法检测命令和控制通信，并且遇到需要广泛优化的泛型 IDS 解决方案的误报警报。

Solution:

• 使用 IDPS 的 Azure 防火墙高级版： 在中心 VNet 中部署了 Azure 防火墙高级 版，支持 IDPS 功能以及 TLS 检查和 URL 筛选，为所有辐射 VNet 流量建立基于签名的集中式威胁检测。

• 签名规则选择： 从关键类别中选择高严重性 IDPS 签名 ，包括恶意软件（Cobalt Strike、Metasploit、勒索软件 C2）、攻击（PaperCut CVE-2023-27350、Log4Shell、ProxyShell）、网络钓鱼（凭据收获）和命令和控制模式。

• 警报模式和优化： 在警报模式下配置 IDPS，以便进行初始测试以观察签名匹配项而不阻止流量，分析警报以识别来自合法 DevOps 工具和合作伙伴 API 调用的误报，然后为已知良好的方案创建签名异常，同时保持高优先级 CVE 签名处于活动状态。

• 防护模式过渡：经过验证后，将入侵检测和防护系统（IDPS）过渡到警报和拒绝模式，积极阻止检测到的威胁，包括对 PaperCut 的利用尝试、Log4Shell 攻击以及 C2 通信。

• Sentinel 集成： 将 诊断日志 配置为 Log Analytics，创建了 Sentinel 分析规则，将 IDPS 检测与身份验证事件相关联，并为高严重性警报建立了自动事件创建。

结果： 成功阻止了攻击尝试，防止远程代码执行。 在发生入侵之前，已消除严重漏洞利用。 假正率大幅下降，同时保持全面的 CVE 覆盖范围。 安全团队实现了快速警报审查和事件响应，通过可作的情报建立持续威胁可见性，以实现主动防御。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SI-4、SI-4（4）、SI-4（5）、SC-7（5）
• PCI-DSS v4： 11.4.1、11.4.2、1.4.1
• CIS 控件 v8.1： 13.2、13.6、13.7
• NIST CSF v2.0： 德。CM-01、DE。CM-04、DE。CM-07
• ISO 27001：2022： A.8.16、A.8.22、A.5.24
• SOC 2： CC6.1、CC7.2

NS-5：部署 DDOS 防护

Azure Policy： 请参阅 Azure 内置策略定义：NS-5。

安全原则

跨不同层部署 DDoS 防护，以有效缓解针对网络层和应用程序层的不同服务和协议的攻击。

待缓解风险

威胁参与者使用压倒性的恶意流量攻击网络、服务器或应用程序，导致服务中断。

• 批量攻击（网络洪水）： 攻击者将大量流量（例如每秒数百万数据包）的网络接口淹没，以耗尽带宽、路由器处理能力或负载均衡器资源，导致服务不可用。 示例包括 UDP 洪水、ICMP 洪水或利用 NTP 或 SSDP 等协议的放大 DNS 反射攻击。
• 协议攻击（状态耗尽）： 攻击者利用第 3/4 层协议漏洞来耗尽有状态资源，例如 TCP 连接表或防火墙会话状态。 常见技术包括 TCP SYN 洪水，它们使具有半开放连接的服务器不知所措，或针对有状态设备的 ACK 洪水。
• 资源层攻击（应用程序重载）： 第 7 层攻击有限，例如 HTTP GET/POST 洪水、目标应用程序资源（例如 CPU、内存或数据库连接），以压倒 Web 服务器或 API。 这些攻击旨在耗尽计算资源，导致延迟高峰或中断。
• 放大攻击： 攻击者利用配置错误的服务器（如运行在 UDP 32414 上的 DNS、NTP 或 Plex 媒体服务器）来放大流量，发送小型查询以生成大规模响应，目标是使网络容量不堪重负。 示例包括 DNS 放大或 SSDP 反射攻击。

MITRE ATT&CK

• 影响（TA0040）： 通过批量洪水（例如 UDP/ICMP）或资源重载（例如 HTTP 洪水）中断服务可用性，以拒绝访问（例如 T1498 - 网络拒绝服务）。
• 资源开发（TA0042）： 利用受损的系统进行放大攻击（例如 DNS/NTP 反射），以扩大攻击影响（例如 T1584 - 入侵基础结构）。

NS-5.1 在适当的网络层中实现 DDOS 保护

在网络层和应用程序层部署 DDoS 防护，以抵御批量攻击和特定于应用程序的攻击。 Azure 提供多层级别的保护：DDoS 网络保护，全面覆盖虚拟网络，提供快速响应支持；DDoS IP 保护，为单个 IP 提供经济高效的保护；以及通过 WAF 实现的应用程序层保护。 配置监视和警报以验证保护有效性，并确保攻击期间应用程序复原能力：

• 部署网络层 DDoS 保护： 在 DDoS 网络保护之间进行选择，用于工作负荷部署，需要全面的 VNet 覆盖范围和快速响应支持，以便进行攻击调查和攻击后分析，或者选择 DDoS IP 防护，以便对有限数量的 IP 进行经济高效的保护，而无需快速响应支持。

• 部署应用程序层 DDoS 防护： 在 Azure Web 应用程序防火墙（WAF）、应用程序网关或 Azure Front Door 上启用 DDoS 保护，以防止应用程序层（第 7 层）攻击。

• 配置监视和警报： 配置警报并监视来自 DDoS 防护服务和应用程序的指标和日志，以确保攻击期间和之后的保护有效性、应用程序复原能力和所需的性能。

实现示例

一家电子商务组织需要为客户端应用程序提供全面的 DDoS 保护，以应对高峰购物季节中不断增加的流量型和应用层攻击尝试。

挑战： 该组织运营了一个全球电子商务平台，其中包含公开给 Internet 的面向公众的 Web 应用程序、API 和内容交付基础结构。 在高峰事件期间，平台经历了多个 DDoS 攻击，包括 UDP 洪水、TCP SYN 耗尽负载均衡器连接表、面向结帐 API 的 HTTP 洪水和 DNS 放大攻击。 如果没有专用的 DDoS 保护，这些攻击会导致服务中断，导致收入损失，客户不满。

Solution:

• DDoS 网络保护： 在托管面向客户的应用程序的生产虚拟网络上启用了 Azure DDoS 网络保护 ，通过自适应优化、第 3 层和第 4 层的自动攻击检测以及实时缓解提供全面的 VNet 级保护。

• 应用程序层保护： 部署 了 Azure 应用程序网关，其中 WAF 适用于区域应用程序和 具有 WAF 的 Azure Front Door ，用于全局边缘交付，启用第 7 层 DDoS 防护，并具有速率限制、HTTP 洪水检测和机器人保护规则。

• 保护策略配置： 创建了 DDoS 防护计划 ，将所有生产 VNet 关联、配置的自适应优化学习基线流量模式、启用始终启用的流量监视和定义的保护策略，涵盖 UDP 洪水、TCP SYN 洪水、ICMP 洪水和协议攻击。

• 监视和警报： 配置的 DDoS 诊断日志 将攻击遥测发送到 Log Analytics 工作区，创建了 Azure Monitor 警报，在检测到攻击时触发即时通知，建立的 Sentinel 工作簿将 DDoS 攻击与应用程序性能指标相关联，并在缓解期间配置了 Application Insights 监视应用程序运行状况。

• 快速响应参与： 激活的 DDoS 快速响应 可在主动攻击期间直接访问 DDoS 保护专家，以便进行实时攻击分析、自定义缓解策略开发和攻击后取证。

结果： 在高峰购物季节，DDoS 攻击已成功缓解，服务中断零。 卷洪水、SYN 洪水和 HTTP 洪水被自动阻止，从而保持平台可用性。 快速响应为复杂的攻击提供了专家分析。 关键购物时期保持高可用性，在缓解期间没有客户交易延迟。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SC-5、SC-5（1）、SC-5（2）、SI-4（4）
• PCI-DSS v4： 6.4.2、11.4.7
• CIS 控件 v8.1： 13.3
• NIST CSF v2.0： PR.PT-05, DE.CM-01
• ISO 27001：2022： A.8.13、A.8.24
• SOC 2： CC6.1、CC7.2

NS-6：部署 Web 应用程序防火墙

Azure Policy： 请参阅 Azure 内置策略定义：NS-6。

安全原则

部署 Web 应用程序防火墙（WAF）并配置规则，通过检查、检测和筛选恶意 HTTP/HTTPS 流量来保护 Web 应用程序和 API 免受特定于应用程序的攻击。

待缓解风险

攻击者利用 Web 应用程序漏洞获取未经授权的访问、执行恶意代码、窃取凭据或泄露数据。

• 注入攻击（例如 SQL 注入、命令注入）： 攻击者利用输入验证漏洞将恶意代码注入 Web 应用程序查询或命令，从而启用未经授权的数据库访问、数据外泄或系统泄露。 SQL 注入（SQLi）通过操纵后端查询（例如，将 ' OR '1'='1 追加到登录表单），而命令注入则执行任意操作系统命令（例如，通过表单字段输入 ; rm -rf /）。
• HTTP 协议冲突和格式不正确的请求： 攻击者发送格式不正确的 HTTP 请求（例如标头无效、负载过大或 TRACE 等非标准方法），以利用 Web 服务器或应用程序中的漏洞，可能导致崩溃或未经授权的访问。 这些攻击针对配置错误的服务器或未修补的框架。
• 机器人驱动的攻击（例如凭据填充、爬取）：自动机器人发起凭据填充攻击（例如，使用被盗凭据对登录端点进行暴力破解）或抓取敏感内容（例如，定价数据），导致服务器过载或危害用户帐户安全。 这些攻击利用弱身份验证或未受保护的 API。
• 应用程序特定的攻击（例如远程文件包含、本地文件包含）： 攻击者利用漏洞来包含恶意文件（例如，包含‘http://evil.com/shell.php’）或访问本地服务器文件（例如，../../etc/passwd），通过修改的 URL 参数或表单输入，进行代码执行或数据泄露。

MITRE ATT&CK

• 初始访问（TA0001）： 利用 SQL 注入、XSS 或远程文件包含来获取访问权限（例如 T1190 - Exploit 公开可访问的应用程序）。
• 执行（TA0002）： 通过命令注入、RFI 或 XSS（例如 T1059 - 命令和脚本解释器）执行恶意代码。
• 凭据访问（TA0006）： 通过 XSS 或凭据填充窃取凭据（例如，T1539 - 窃取 Web 会话 Cookie、T1110 - 暴力破解）。
• 集合（TA0009）： 通过 SQL 注入或抓取收集数据（例如 T1213 - 来自信息存储库的数据）。

NS-6.1 使用适当的规则配置 Azure WAF

在 Azure 应用程序网关、Azure Front Door 或 Azure 内容分发网络（CDN）中启用 Web 应用程序防火墙（WAF）功能，以保护应用程序和 API 免受基于 Web 的攻击。 根据应用程序要求选择适当的服务，使用内置和自定义规则配置 WAF 策略，根据安全状况设置策略模式，并将策略与服务终结点相关联：

• 选择适当的 WAF 服务： 选择用于 VNet 托管应用程序的 Azure 应用程序网关、用于全局边缘交付的 Azure Front Door，或根据应用程序要求和体系结构为内容密集型工作负荷选择 Azure CDN。

• 使用内置规则和自定义规则配置 WAF 策略： 从常见的内置规则集（如 OWASP 核心规则集（CRS 3.2）和机器人保护（Microsoft Bot Manager）规则开始。 添加自定义规则（例如，100 个请求/分钟速率限制 >）和排除项，以根据威胁形势和应用程序安全配置文件减少误报。

• 设置 WAF 策略模式： 最初或对非关键应用程序使用检测模式，以避免在设置和规则优化期间中断合法流量。 验证规则以阻止恶意请求后，切换到关键应用程序的防护模式。

• 将 WAF 策略与服务终结点相关联： 将 WAF 策略与应用程序网关、Front Door 或 CDN 终结点相关联，以确保通过 WAF 路由所有 HTTP/HTTPS 流量以检查。

实现示例

组织需要保护面向客户的 Web 应用程序和 API 免受 SQL 注入、XSS 攻击和机器人驱动的凭据填充，同时保持合法用户的性能。

挑战： 组织在全球部署了 Web 应用程序，没有针对 OWASP 前 10 个漏洞的保护，导致多次 SQL 注入尝试、机器人驱动的攻击压倒性登录终结点，并且无法查看恶意流量模式。 应用程序缺少速率限制控制，允许 API 滥用和凭据填充攻击，并且没有将合法用户与恶意机器人区分开来的机制。

解决方案方法：

• WAF 服务选择： 为 VNet 托管应用程序部署了 Azure 应用程序网关和 WAF，而对于需要边缘保护和低延迟访问的全球分布式应用程序，部署了 Azure Front Door 和 WAF。
• 内置保护规则集： 已启用 OWASP 核心规则集 （CRS） 3.2 ，以防止 SQL 注入、跨站点脚本（XSS）、远程文件包含和其他常见 Web 漏洞，并激活 Microsoft Bot Manager 规则 来识别和阻止恶意机器人，同时允许合法的搜索引擎爬网程序和监视服务。
• 特定威胁的自定义规则： 实施速率限制规则，阻止每分钟超过 100 个请求的客户端，以防止 API 滥用和凭据填充，异地筛选规则阻止来自服务不可用的高风险区域的流量，以及基于 IP 信誉的规则阻止通过威胁情报源识别的已知恶意 IP 范围的请求。
• 排除管理： 为合法业务方案创建了特定的排除项，例如对于具有复杂表单输入且在OWASP规则中触发误报的/checkout端点，处理大型文件提交的/upload端点，以及具有异常但有效的来自移动应用的标头模式的/api端点。
• 检测到预防转换： WAF 在检测模式下运行了两周，以识别误报，并根据合法流量模式细化规则和排除项，然后转换为应用于生产环境的预防模式，以在保持业务连续性的同时，主动阻止威胁。

结果： 组织消除了 SQL 注入和 XSS 利用尝试，通过机器人管理器规则大幅减少机器人驱动的攻击，并建立了对 Web 应用程序威胁的全面可见性。 速率限制控制阻止了 API 滥用和凭据填充，而从检测到预防模式的分阶段转换可确保合法用户没有服务中断。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SC-7、SC-7（5）、SI-10、SI-10（1）、SI-11
• PCI-DSS v4： 6.4.1、6.4.2、11.4.7
• CIS 控件 v8.1： 13.2、13.9
• NIST CSF v2.0： PR.AC-05、PR.PT-05、DE.CM-04
• ISO 27001：2022： A.8.20、A.8.22、A.8.25
• SOC 2： CC6.1、CC6.6、CC7.2

NS-7：集中有效地管理网络安全

安全原则

若要降低复杂和分散的网络环境中的作风险和配置错误，请使用云本机网络管理功能集中、简化和强制实施一致的网络安全配置。

待缓解风险

缺乏集中控制会导致被忽视或过时的安全设置，增加了利用风险。

• 策略强制实施和配置不一致： 分散式管理通常会导致分散的规则集和策略差距，使攻击者更容易发现和利用薄弱点。 配置错误的可能性更大，从而增加了意外暴露或未授权访问的风险。
• 减少可见性和延迟响应： 如果没有统一的管理方法，监视和事件响应就会变慢且效率更低。 这可以延迟检测恶意活动，使攻击者有更多的时间升级攻击或外泄数据。
• 难以保持合规性： 集中管理不足使一贯满足法规和行业标准的努力复杂化，并有可能面临不合规和潜在处罚的风险。

MITRE ATT&CK

• 初始访问（TA0001）： 利用错误配置或过时的安全设置来获取未经授权的访问（例如，T1190 - Exploit Public-Facing Application，T1133 - External Remote Services）。
• 防御逃避（TA0005）： 利用碎片化规则集和缺乏集中监视来避免检测（例如 T1562 - 损害防御）。
• 横向移动（TA0008）： 通过利用策略漏洞或过时的分段机制（例如 T1021 - 远程服务）以实现横向移动。
• 命令和控制（TA0011）： 使用不受监视或配置错误的网络路径建立和维护 C2 通道（例如 T1071 - 应用程序层协议）。

NS-7.1 集中有效地管理网络安全

使用 Azure 的集中式工具和标准化做法来简化和缩放网络安全管理，确保一致的强制实施、减少配置和改进监视。 实施集中式策略强制实施、标准化防火墙和路由管理、实现全面的监视和分析，并通过治理做法保持资源一致性：

• 实现集中式策略强制实施： 使用 Azure 虚拟网络管理器（AVNM）定义跨订阅和区域一致应用的安全管理员规则。 保持 NSG 以实现工作负荷级别的微观分段。 在网络组中应用策略（如按环境：生产、非生产）。

• 标准化防火墙和路由管理： 使用防火墙策略对象通过防火墙管理器管理 Azure 防火墙规则。 标准化 IP 组和服务标记，而不是原始 IP。 使用 Azure 防火墙高级版，其中需要 TLS 检查、IDPS 和 URL 筛选。 建议使用虚拟 WAN 安全中心或共享的 hub-and-spoke 拓扑结构，以确保路由意向的一致实施。

• 启用全面的监视和分析： 使用虚拟网络流日志 v2（替换 NSG 流日志）。 启用 Azure 防火墙诊断日志并与流量分析、Log Analytics 和 Microsoft Sentinel 集成。 使用防火墙策略分析和规则命中计数来消除未使用或重复的规则。

• 维护资源一致性和治理： 将所有 VNet、NSG、防火墙规则和组应用 CAF 命名约定和强制资源标记。 使用 Defender for Cloud 的自适应网络强化来优化过度宽松的规则。

实现示例

用例： 多区域支付平台大规模整合网络安全

上下文： 一个在美国东部和西欧运营的中型支付处理器，在一个租户下拥有 4 个订阅（Prod、Non-Prod、Shared Services、SecOps），需要 PCI-DSS 分段、减少来自规则偏移的事件和集中监视。

使用 Azure 虚拟网络管理器实施集中式策略：

• 设计： 在管理组级别创建 AVNM。 定义两个网络组：ng-prod 和 ng-nonprod，并按 subscriptionId 标签动态确定成员资格。 创建安全管理员规则 (SAR) 以在 NSG 之前实施组织的防护措施：拒绝-入站-互联网到分支（阻止从互联网到所有分支子网的未经请求的入站），允许-中心基础设施（允许中心服务 - 防火墙/Bastion - 进入分支），允许-平台DNS（允许从中心解析器到分支的 DNS）。
• 应用团队边界： 工作负荷将 NSG 保留在每个分支内的微分段（例如 Web 到 api ：443、api 到 db ：1433） 中。 NSG 更改由应用团队负责；SARs 由平台安全团队负责。
• 结果： 防护措施在两个区域都是一致的，即使网络安全组（NSG）配置不当，应用团队也不会意外创建直接的互联网访问。

使用防火墙管理器和虚拟 WAN 进行防火墙和路由管理：

• 设计： 在每个区域（美国东部、西欧）部署虚拟 WAN 安全中心。 将辐条附加到最近的集线器，并启用路由意图，以便检查所有 Internet 出口流量。 将防火墙管理器与高级层级的全局防火墙策略以及两个子策略（生产环境/非生产环境）一起使用，以进行环境覆盖。
• 策略结构： 基本（全局）策略包括威胁智能设置为警报 + 拒绝、针对出站 HTTPS 启用的 TLS 检查、处于均衡模式的 IDPS，以及使用服务标记（存储、KeyVault、AzureMonitor）和合作伙伴终结点的 IP 组的出站允许规则。 Prod 子策略具有更严格的 URL 筛选（阻止未分类），并允许通过 IP 组列出付款网关。 非生产子项目策略通过服务标记（AzureDevOps、AzureContainerRegistry）具有更广泛的开发工具访问权限。
• 结果： 用于管理规则的单个窗格，其中更改传播到两个中心。 路由是一致的，所有出口都使用允许的 TLS 解密进行检查。

使用流日志 v2 和 Sentinel 进行监视和分析：

• 遥测设置： 在所有 VNet 上启用虚拟网络流日志 v2，并发送到 SecOps 订阅中的中央 Log Analytics 工作区。 将 Azure 防火墙诊断日志（应用程序、网络、DNS、ThreatIntel、IDPS）配置为同一工作区。 针对工作区启用流量分析。
• 优化循环： 启用防火墙策略分析并每月查看规则命中计数。 创建一个关联流日志（南北向和东西向）、防火墙允许/阻止命中以及触发的 IDPS 签名的 Sentinel 工作簿。 如果一个规则45天内没有命中（可作为删除候选项），或者生产子网命中了拒绝规则（可能存在错误路由），则自动化处理更改请求。
• 结果： 在两个评审周期后，将删除 18 个防火墙规则% 和 22 个过时的 NSG 规则，从而减少规则评估延迟和更改风险。

使用 CAF 和 Defender for Cloud 进行资源一致性和管理：

• 标准： 应用 CAF 命名（例如 vnet-prd-eus-01、nsg-prd-eus-web-01、azfw-policy-global-01）和必需标记：env、owner、dataClass、costCenter。
• 执法： 使用 Azure Policy 倡议要求每个子网必须配置 NSG，必须将 VNet 和防火墙的诊断设置集中到中心 LA 工作区，并拒绝在没有强制标记的情况下创建。 在所有分支上启用 Defender for Cloud - 自适应网络强化，并在 SecOps CAB 中每周审查操作项目。
• 结果： 平台偏移迅速浮出水面;使用 Defender 的数据驱动建议来收紧过度宽松的规则。

推出顺序和验收条件：

• 建立 vWAN 安全中心、附加分支、启用路由意图（仅限试点分支）。 接受条件：试点分支通过防火墙出站，无法直接访问任何公共 IP。
• 将 AVNM SARs 部署到 ng-nonprod，验证没有中断，然后再部署到 ng-prod。验收标准：合成探测确认中心服务（DNS/Bastion）仍能够到达分支；入站互联网访问仍被拒绝。
• 启用 vNet 流日志 v2 和所有防火墙诊断;载入 Sentinel 工作簿。 接受条件：仪表板显示每个区域的流、拒绝、IDPS 命中数。
• 应用策略计划;修正不符合的项目;启用自适应强化。 验收标准：合规性达到 95%，NSG/防火墙收紧项积压工作。
• 首次策略分析评审；通过变更窗口期删除未使用的规则。 接受条件：规则计数减少 15%，对客户没有影响。

操作手册示例：

• Azure 虚拟网络管理器 SAR： 拒绝入站 Internet 到分支点（优先级 100），允许中心基础设施访问分支点（优先级 200：来源 10.0.0.0/16 的中心范围）
• 防火墙策略结构：azfw-policy-global-01（Premium），包含规则集合 Allow-Azure-Platform-ST（Service Tags）和 Allow-Partners-IPs（IP组: ipg-payment-gws），以及子策略 azfw-policy-prd-01 和 azfw-policy-npd-01
• 诊断： 目标：law-secops-01，类别：AZFWApplicationRule、AZFWNetworkRule、AZFWIDPS、AZFWThreatIntel、AZFWDnsProxy、FlowLogV2

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： CM-2、CM-3、CM-6、CA-7、SI-4
• PCI-DSS v4： 1.4.5、11.5.1、12.4.1
• CIS 控件 v8.1：4.1 、4.2、12.4、13.6
• NIST CSF v2.0： PR.IP-01、DE.CM-01、DE.CM-07
• ISO 27001：2022： A.8.9、A.8.32、A.5.37
• SOC 2： CC6.6、CC7.2、CC8.1

NS-8：检测和禁用不安全服务和协议

Azure Policy： 请参阅 Azure 内置策略定义：NS-8。

安全原则

在 OS、应用程序或软件包层发现和禁用不安全的服务和协议。 如果无法禁用不安全服务和协议，则部署补偿控制。

待缓解风险

威胁参与者利用不安全和易受攻击的服务和协议来破坏系统和数据。

• 加密漏洞利用：SSL/TLSv1 和弱密码（例如 RC4、DES）容易受到 MITM 攻击（例如 POODLE、BEAST）攻击，使攻击者能够通过填充 oracle 或所选密码攻击来解密敏感数据，例如会话令牌。
• 通过协议攻击进行未经授权的访问： SSHv1 和 SMBv1 漏洞（例如 CVE-2001-1473、CVE-2017-0144/EternalBlue）允许远程代码执行或未经身份验证的访问，从而启用初始立足点。
• 凭据被盗： LM/NTLMv1 和 wDigest 存储弱哈希或纯文本凭据，容易受到传递哈希或内存擦除（例如 Mimikatz 提取 LSASS 数据）攻击。
• 横向移动： SMBv1 的未加密会话和攻击（例如，EternalBlue）可能导致恶意软件传播或跨网络的凭据中继。

MITRE ATT&CK

• 初始访问（TA0001）： 利用 SSL/TLSv1 或 SSHv1 等不安全协议，这些协议容易受到协议降级攻击或已知攻击，阻止未经授权的进入（例如 T1190 - Exploit Public-Facing 应用程序）。
• 凭据访问（TA0006）： 利用 LM/NTLMv1 和 wDigest（以可逆格式或弱哈希存储凭据、阻止传递哈希或内存擦除（例如 T1003 - OS 凭据转储）来窃取凭据。
• 横向移动（TA0008）： 阻止攻击者通过 SMBv1 进行横向移动，因 SMBv1 易受 EternalBlue 等漏洞利用的影响，从而防止在网络间传播（例如 T1021 - 远程服务）。

NS-8.1 检测和禁用不安全服务和协议

使用 Microsoft Sentinel 的内置不安全协议工作簿发现和缓解 Azure 环境中的不安全服务和协议。 此工作簿标识不符合适当安全标准的协议和服务的使用，例如 SSL/TLSv1、SSHv1、SMBv1、LM/NTLMv1、wDigest、Kerberos 中的弱密码和未签名 LDAP 绑定。 标识后，禁用这些不安全的协议和服务。 禁用不可行时，实现补偿控制以减少攻击面。

发现不安全的协议： 使用 Microsoft Sentinel 的不安全协议工作簿来识别 SSL/TLSv1、SSHv1、SMBv1、LM/NTLMv1、wDigest、弱 Kerberos 密码以及整个环境中的未签名 LDAP 绑定的使用。

禁用不安全服务和协议： 禁用未满足适当安全标准的不安全服务和协议，以消除漏洞。

实现补偿控件： 如果由于业务要求或技术约束而无法禁用不安全的服务或协议，请使用补偿控制措施，例如阻止通过网络安全组、Azure 防火墙或 Azure Web 应用程序防火墙访问资源以减少攻击面。

实现示例

医疗保健组织需要在其 Azure 环境中消除不安全的协议，以满足 HIPAA 合规性要求，并减少受保护运行状况信息的攻击面。

挑战： 组织使用需要连接到 Azure 托管资源的旧应用程序运行混合基础结构。 安全评估揭示了不安全协议的广泛使用，包括为患者门户提供服务的 Web 服务器上的 SSL/TLSv1.0、在用于旧式医疗成像软件的文件服务器上启用 SMBv1、域控制器和应用程序服务器上的 LM/NTLMv1 身份验证、WDigest 身份验证以可逆格式存储凭据、Active Directory 控制器上的未签名 LDAP 绑定，以及服务帐户上的弱 Kerberos 加密。 组织缺乏对协议使用情况的可见性，并面临潜在的 HIPAA 合规性违规行为。

Solution:

• Sentinel 不安全协议工作簿部署： 已从内容中心部署 Microsoft Sentinel 并安装了 不安全协议工作簿 、连接的数据源（包括 Windows 安全事件日志、Azure Monitor 日志、Active Directory 日志和网络流日志），从而跨混合环境建立不安全协议使用的综合基线。

• 协议发现： 使用不安全协议工作簿识别 Web 服务器上的 SSL/TLSv1.0 使用情况、来自旧式医学成像工作站的 SMBv1 流量、LM/NTLMv1 身份验证模式、在 Windows 服务器上启用 wDigest、旧应用程序的未签名 LDAP 绑定以及服务帐户上的弱 RC4 Kerberos 加密。

• 系统协议禁用： 创建了通过变更顾问委员会验证的分阶段修正计划， 在确认患者门户用户运行支持 TLS 1.2+ 的新式浏览器后，在 Web 服务器上禁用了 TLSv1.0/1.1，在与医疗成像供应商软件升级协调后禁用了 SMBv1、将域控制器从 NTLMv1 转换为 NTLMv2 身份验证、通过组策略禁用 wDigest、在域控制器上强制实施 LDAP 签名，并将服务帐户 Kerberos 加密升级到 AES256。

• 异常情况的补偿控制措施： 实施了针对需要临时不安全协议支持的系统的网络基础补偿控制措施，包括需要 SMBv1 的旧式医疗成像工作站的隔离虚拟局域网（VLAN）、限制 SMBv1 流量的 NSG 规则、Azure 防火墙禁止来自生产子网的出站 SMBv1流量、用于托管旧 HR 应用程序的专用跳转主机，以及通过 Defender for Endpoint 标记在已批准例外子网之外使用协议的情况以进行增强监控。

• 持续监视： 通过 Microsoft Sentinel 分析规则建立持续协议卫生机制，从而触发针对新不安全协议连接的警报（在批准的异常之外）、Azure Policy 拒绝部署而不满足 TLS 1.2 最低要求，以及每周不安全的协议工作簿评审跟踪修正进度。

结果：去除患者门户中的弱 TLS 连接。 SMBv1 在医学成像升级后被禁用，消除了永恒蓝漏洞并实现了 HIPAA 合规性。 NTLMv1 已转换为 NTLMv2，从而阻止传递哈希攻击。 为了防止凭据被盗，已禁用 wDigest。 LDAP 签名阻止了未签名的查询。 Kerberos 升级到 AES256，降低了 Kerberoasting 攻击的风险。 补偿措施限制了旧系统，使其无任何横向移动。 实现了完全 HIPAA 符合性。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SC-8、SC-8（1）、SC-13、IA-5（1）
• PCI-DSS v4： 2.2.4、4.2.1、6.2.4
• CIS 控件 v8.1： 4.8、9.3、13.4
• NIST CSF v2.0： PR.DS-02、PR.IP-01、DE.CM-04
• ISO 27001：2022： A.8.24、A.8.26、A.5.14
• SOC 2： CC6.1、CC6.7、CC7.1

NS-9：以私密方式连接本地或云网络

安全原则

使用专用连接在不同的网络（例如云服务提供商数据中心和托管环境中的本地基础结构）之间安全通信。

待缓解风险

当数据通过公用网络传输时，它容易受到拦截、未经授权的访问和篡改。

• 数据截获： 当数据通过 Internet 等公用网络传输时，它会通过多个路由器、交换机和服务提供商传递，其中任何一种都可能被恶意参与者入侵或监视。 攻击者可以部署数据包探查工具（例如 Wireshark）来捕获数据包。 如果数据未加密或弱加密，则可以公开敏感信息（例如登录凭据、财务详细信息或专有业务数据）。
• 中间人（MitM）攻击： 在 MitM 攻击中，攻击者秘密拦截并可能改变两方之间的沟通，他们相信他们正在直接与对方通信。 这给敏感作（如金融交易或身份验证流程）构成严重威胁。
• 未经授权的访问： 公共或安全不足的网络会增加未经授权的用户获得对专用系统或资源的访问或篡改的可能性。 攻击者可以利用网络弱点来侵入本应从外部无法访问的内部基础设施。

MITRE ATT&CK

• 初始访问（TA0001）： 利用未加密或弱加密协议（例如 HTTP 或过时的 TLS 版本）容易受到数据包探查或 MitM 攻击的攻击，从而允许未经授权的进入系统（例如 T1190 - Exploit Public-Facing Application）。
• 凭据访问（TA0006）： 通过拦截的网络流量窃取凭据、利用明文协议（例如 Telnet 或 FTP）或易解密的弱加密，从而促进未经授权的访问（例如 T1040 - 网络嗅探）。
• 横向移动（TA0008）： 通过利用错误配置或暴露的服务（比如未修补的 RDP 或 SMB）在网络中扩散，允许攻击者使用被盗凭据或漏洞（比如 T1021 - 远程服务）进行横向移动。

NS-9.1 使用 Azure 虚拟专用网络（VPN）进行轻型站点到站点连接或点到站点连接

使用 Azure 虚拟专用网络（VPN）在本地站点或最终用户设备和 Azure 虚拟网络之间创建安全的加密连接，以用于轻型连接方案。 Azure VPN 为站点到站点连接（连接整个网络）或点到站点连接（连接单个设备）提供经济高效的解决方案，无需专用基础结构：

• 部署站点到站点 VPN： 使用站点到站点 VPN 安全地将本地网络连接到 Azure 虚拟网络，从而在本地资源和 Azure 工作负荷之间实现无缝通信。

• 部署点到站点 VPN： 使用点到站点 VPN 使单个最终用户设备（笔记本电脑、工作站）能够安全地从远程位置连接到 Azure 虚拟网络。

NS-9.2 使用 Azure ExpressRoute（或虚拟 WAN）进行企业级高性能连接

使用 Azure ExpressRoute 或 Azure 虚拟 WAN 在托管环境中建立 Azure 数据中心与本地基础结构之间的专用、高性能、低延迟连接。 这些企业级解决方案绕过公共 Internet，为需要一致连接的任务关键型工作负荷提供专用带宽、可预测的性能和增强的安全性：

• 为专用连接部署 ExpressRoute： 使用 Azure ExpressRoute 通过连接提供商在本地基础结构和 Azure 数据中心之间创建专用连接，确保企业工作负荷的专用带宽和可预测的延迟。

• 部署虚拟 WAN 进行全局连接： 使用 Azure 虚拟 WAN 通过具有集成安全性和路由功能的统一中心辐射型体系结构构建连接多个站点、分支和 Azure 区域的全局网络。

NS-9.3 使用 VNet 或子网对等互连加入虚拟网络

使用虚拟网络对等互连或子网对等互连在 Azure 虚拟网络之间建立专用连接，而无需通过公共 Internet 路由流量。 对等互连虚拟网络之间的网络流量仍保留在 Azure 主干网络上，提供低延迟、高带宽连接，且没有加密开销。 当不需要完全虚拟网络连接时，选择子网级别的对等连接，仅将访问限制到特定子网。

• 部署虚拟网络对等互连： 使用虚拟网络对等互连连接整个 Azure 虚拟网络，使不同 VNet 中的资源可以像在同一网络中一样以私密方式进行通信。

实现示例

跨国金融服务组织需要本地数据中心、分支机构和 Azure 云资源之间的安全高性能连接，同时消除敏感金融交易的公共 Internet 暴露。

挑战： 该组织在全球运营了多个本地数据中心，需要连接到处理财务交易和客户数据的 Azure 托管应用程序。 初始的架构设计使用基于互联网的站点到站点 VPN，在高峰交易时段遇到了不可预知的延迟和带宽限制，金融数据穿越公共互联网时即使加密仍面临安全问题，此外，合规要求规定必须为 PCI-DSS 和 GDPR 建立专用连接。 通过点到站点 VPN 连接的远程员工遇到不一致的性能和身份验证问题。 不同 Azure 区域中的应用程序需要低延迟区域间通信，而无需通过本地中心进行路由。

Solution:

• 用于主要数据中心连接的 ExpressRoute：通过专线连接提供商的协同定位设施在主要数据中心部署了 Azure ExpressRoute 线路，建立了与 Azure 主干网络的专用第 3 层连接，并且延迟一直较低。为 Azure PaaS 服务配置了 Microsoft 对等互连，为 VNet 托管资源配置了专用对等互连，实现了以主动-主动配置方式实现高可用性和自动故障转移的 BGP 路由。

• 用于分支机构连接的站点到站点 VPN： 为缺少共同位置设施访问的分支机构部署 的站点到站点 VPN， 在中心 VNet 中创建具有主动-主动配置的高可用性 VPN 网关、配置了符合金融部门安全标准的 IPsec/IKE 隧道、实现了动态路径选择的 BGP 路由，允许分支连接到最近的区域中心、建立的冗余隧道可确保维护时段内的连接。

• 远程员工的点到站点 VPN： 为需要安全访问 Azure 托管应用程序的远程员工配置了 点到站点 VPN，通过 Azure Active Directory 进行身份验证。在无法通过 Internet 访问 Azure AD 的情况下，启用证书认证作为备用方案。将客户端 IP 地址分配给专用池，并通过用户定义的路由将流量引导至 Azure VNet 资源。为 macOS/Linux 客户端实现了 OpenVPN 协议，为 Windows 客户端实现了 IKEv2/SSTP，确保广泛的设备兼容性。配置了拆分隧道，允许非企业流量直接访问 Internet，同时通过 VPN 隧道路由 Azure 流量，以优化带宽。

• 用于全球网状连接的虚拟 WAN： 在多个区域部署了具有安全中心的 Azure 虚拟 WAN，以提供全球传输架构。将 ExpressRoute 线路连接到虚拟 WAN 中心，实现数据中心和 Azure 区域之间的任意互联，而无需通过本地中心路由。从分支机构到最近的虚拟 WAN 中心的站点到站点 VPN 连接进行了集成，并通过自动路由优化实现。启用了每个虚拟 WAN 中心的 Azure 防火墙，为分支机构、数据中心和 Azure VNet 之间的流量提供集中式安全检查。配置了路由策略，实现了全球传输路由，允许分支机构通过 Azure 主干与本地数据中心通信。

• Azure 区域间连接的 VNet 对等互连： 实现了将分支 VNet 连接到每个区域中的虚拟 WAN 中心 VNet 的 虚拟网络对等互连。启用了 全局 VNet 对等互连，通过 Azure 主干实现跨区域应用程序连接，提供低延迟。配置了网关中转，允许分支 VNet 使用虚拟 WAN 中心的 VPN/ExpressRoute 网关，而无需部署额外的网关，从而降低成本和复杂性。在分支子网上实施了网络安全组，控制对等 VNet 与对等互连 VNet 之间的流量流，以维护最小特权访问。

• 流量优化和监视： 配置了 ExpressRoute 电路，使用 QoS 标识以财务事务流量优先于批量数据传输，启用连接监视器功能以跟踪 ExpressRoute 电路及 VPN 连接的延迟、数据包丢失和可用性并进行告警；实施 Azure Monitor 工作簿，以可视化全球连接拓扑，显示当前连接、带宽使用情况和故障转移事件；为自动告警建立可接受性能的基线以应对阈值超出。

结果： 所有财务交易都实现了专用连接，满足 PCI-DSS 要求。 ExpressRoute 为实时交易提供了一致的低延迟。 虚拟 WAN 大大减少了分支到数据中心的延迟。 远程员工通过点对站点 VPN 和改进的身份验证成功连接。 全局 VNet 对等互连启用了高效的跨区域灾难恢复。 通过虚拟 WAN 整合实现的成本优化。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SC-7、SC-7（4）、SC-8
• PCI-DSS v4： 1.2.1、2.2.7、4.2.1
• CIS 控件 v8.1： 12.8、13.8
• NIST CSF v2.0： PR.AC-05, PR.DS-02
• ISO 27001：2022： A.8.21、A.8.22、A.5.14
• SOC 2： CC6.6、CC6.7

NS-10：确保域名系统（DNS）安全性

安全原则

确保域名系统（DNS）安全配置可防范已知风险：

• 在云环境中使用受信任的权威和递归 DNS 服务来确保客户端（如作系统和应用程序）收到正确的解析结果。
• 将公共和专用 DNS 解析分开，以便专用网络的 DNS 解析过程可以与公用网络隔离。
• 确保 DNS 安全策略还包括针对常见攻击的缓解措施，例如悬空 DNS、DNS 放大攻击、DNS 中毒和欺骗等。

待缓解风险

威胁参与者攻击 DNS 服务或利用易受攻击的 DNS 服务来入侵应用程序和重定向流量。

• DNS 欺骗/中毒： 攻击者伪造 DNS 响应或损坏的解析程序缓存（例如 Kaminsky 攻击），以将客户端重定向到恶意服务器，从而启用网络钓鱼或数据拦截。
• DNS 放大攻击： 攻击者利用配置错误的 DNS 服务器来放大 DDoS 流量（例如，60 字节查询生成 4,000 字节响应），从而压倒性目标网络。
• 悬空 DNS 开发： 悬空记录（例如，过时的 CNAME）允许攻击者劫持已解除授权的资源，将流量重定向到恶意终结点进行钓鱼或恶意软件。
• 通过 DNS 隧道外泄数据： 恶意参与者在 DNS 查询（例如，data.exfil.evil.com）中对数据进行编码，以秘密外泄敏感信息，绕过防火墙。
• 网络钓鱼/恶意软件传送： 遭到入侵的解析程序将合法域重定向到攻击者控制的 IP，将网络钓鱼页或恶意软件传送到不知情的客户端。

MITRE ATT&CK

• 命令和控制（TA0011）： 使用 DNS 隧道在查询（例如，data.exfil.evil.com）或欺骗解析中对 C2 命令进行编码，以连接到恶意服务器（例如 T1071.004 - 应用程序层协议：DNS）。
• 集合（TA0009）： 通过欺骗 DNS 来收集数据，以将用户重定向到钓鱼网站或通过隧道外泄数据（例如 T1040 - 网络嗅探）。
• 影响（TA0040）： DNS 放大攻击，发送小型查询以生成大型响应，中断服务可用性（例如 T1498.002 - 网络拒绝服务：反射放大）。
• 初始访问（TA0001）： 利用悬而未决的 DNS 记录或欺骗解决方案来传送恶意软件/网络钓鱼，获取系统（例如 T1190 - Exploit Public-Facing 应用程序）的入口。

NS-10.1 使用受信任的 DNS 服务

使用受信任的 DNS 服务来确保客户端收到正确的解析结果并防范基于 DNS 的攻击。 Azure 以 168.63.129.16（通常通过 DHCP 或预配置）提供递归 DNS 服务，以便在作系统或应用程序级别进行工作负荷 DNS 解析。 或者，使用受信任的外部 DNS 服务器。 对于托管自己的域的组织，Azure DNS 提供可靠的权威 DNS 托管。 构建自定义 DNS 服务器的组织应遵循 NIST SP 800-81 Rev. 3 安全部署准则：

• 使用 Azure 递归 DNS 或受信任的外部 DNS： 将工作负荷配置为在 VM作系统或应用程序 DNS 设置中使用 Azure 递归 DNS（168.63.129.16）或受信任的外部 DNS 服务器，以确保可靠的名称解析。

• 允许防火墙规则中的 Azure DNS： 将 168.63.129.16 添加到防火墙和 NSG 允许列表，以确保为 Azure 资源提供适当的 DNS 功能。

• Azure DNS 上的主机域： 使用 Azure DNS 为权威 DNS 需求托管域解析，提供可靠且可缩放的 DNS 托管（注意：Azure DNS 不提供域注册服务）。

• 遵循安全的 DNS 部署准则： 如果生成自定义 DNS 服务器，请按照 NIST SP 800-81 Rev. 3 安全域名系统 （DNS） 部署指南实施安全最佳做法。

NS-10.2 在虚拟网络中使用专用 DNS

使用 Azure 专用 DNS 建立 DNS 解析保留在虚拟网络中的专用 DNS 区域，从而阻止 DNS 查询遍历公用网络。 这对于专用终结点配置至关重要，其中专用 DNS 区域会替代公共 DNS 解析，以私下将流量路由到 Azure 服务。 自定义 DNS 解决方案可以进一步将解析限制为仅受信任的源，从而增强专用工作负荷的安全性：

• 部署 Azure 专用 DNS 进行专用解析： 使用 Azure 专用 DNS 创建在虚拟网络中保留 DNS 解析的专用 DNS 区域，确保查询永远不会离开网络边界。

• 为专用终结点配置专用 DNS： 为专用终结点配置专用 DNS 区域以替代公共 DNS 解析，并确保客户端将专用终结点 FQDN 解析为虚拟网络中的专用 IP 地址。

• 实现自定义 DNS 以实现受限解析： 使用自定义 DNS 服务器将 DNS 解析限制为仅允许客户端的受信任解析源，从而进一步控制名称解析安全性。

NS-10.3 将 Defender 用于 DNS 进行高级保护

使用 Microsoft Defender for DNS 检测和警报高级基于 DNS 的安全威胁，包括通过 DNS 隧道外泄数据、命令和控制通信、恶意域交互（网络钓鱼、加密挖掘）和涉及恶意解析程序的 DNS 攻击。 Defender for DNS 保护现已包含在 Defender for Servers 计划中。 此外，使用 Microsoft Defender for App Service 来检测在停用网站时可能导致子域接管攻击的悬空 DNS 记录。

• 启用 Defender for DNS 保护： 使用 Microsoft Defender for DNS（包含在 Defender for Servers 计划中）监视和警报可疑 DNS 活动，包括通过 DNS 隧道外泄数据、恶意软件命令和控制通信以及与恶意域的交互。

• 监视恶意 DNS 活动： 配置警报以检测与恶意 DNS 解析程序以及可能危及工作负荷安全性或 DNS 服务可用性的 DNS 攻击的通信。

• 检测悬空 DNS 记录： 使用 Microsoft Defender for App Service 在解除应用服务网站授权时识别悬空 DNS 记录，通过确保从 DNS 注册机构中删除自定义域来防止子域接管攻击。

实现示例

挑战： 企业需要全面的 DNS 安全性，包括受信任的解析服务、内部资源的专用网络 DNS 以及跨混合云基础结构的高级威胁检测。

解决方案方法：

• 部署的 Azure 递归 DNS（168.63.129.16） 适用于所有具有 NSG 规则的 Azure VM 工作负荷，允许 DNS 流量
• Azure DNS 上托管的权威区域，用于公共域名解析和地理分布
• 为专用终结点解析（privatelink.database.windows.net，privatelink.blob.core.windows.net）实现了链接到生产 VNet 的 Azure 专用 DNS 区域
• 配置的 专用 DNS 集成 可确保专用终结点 FQDN 解析为专用 IP（例如，sqlserver.database.windows.net → 10.0.2.4）
• 通过 Defender for Servers 计划启用Microsoft Defender for DNS以监视 DNS 隧道、C2 通信和恶意域交互。
• 部署 Defender for App Service ，用于在网站停用期间检测悬空 DNS 记录

结果： DNS 安全实现确保云工作负载的可靠名称解析，同时维护内部资源的隐私。 专用 DNS 区域阻止敏感查询遍历公共网络，而 Defender for DNS 提供了对基于 DNS 的威胁的可见性，包括数据外泄尝试和命令和控制活动。 在资源生命周期更改期间，该解决方案通过自动悬空 DNS 检测消除了子域接管风险。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： SC-7、SI-4、SI-4（4）、SI-4（5）
• PCI-DSS v4： 11.5.1、12.10.1
• CIS 控件 v8.1： 8.5、13.6、13.8
• NIST CSF v2.0： 德。CM-01、DE。CM-04、DE。AE-02
• ISO 27001：2022： A.8.16、A.8.22、A.5.24
• SOC 2： CC6.1、CC7.2、CC7.3