<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 利用 DNS 防火墙增强 Pinterest 组织安全（二）
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
该解决方案详细阐述了 **Pinterest** 如何利用 AWS 服务构建一个可扩展、安全且灵活的 **DNS 防火墙**，以增强其整个 AWS Organization 的组织安全。方案的核心目标是集中管理和控制从所有 VPC 发起的 DNS 查询，从而主动防御恶意软件通信、数据泄露等网络安全风险。
该方案解决了大型企业在多账户云环境中面临的 DNS 出口流量管控难题。它提供了两种核心安全策略以适应不同业务场景的需求：
- **DNS Walled Garden (围墙花园模式)**：采用 **allowlist (允许列表) + default deny (默认拒绝)** 的零信任安全模型。这是组织范围内的默认策略，仅允许访问预先批准的域名，从而最大限度地减少攻击面。
- **DNS Deny Malicious (恶意域名拦截模式)**：采用 **denylist (拒绝列表) + default allow (默认允许)** 的策略。此模式作为例外情况，为特定账户提供更大的灵活性，仅阻止对已知恶意或可疑域名的访问。
技术上，该方案通过 **AWS Firewall Manager** 跨 **AWS Organization** 统一部署和管理 **Amazon Route 53 Resolver DNS Firewall** 规则，实现了策略的自动化和一致性。
## 实施步骤
方案采用了一种成熟的 **"Alert-Then-Block" (先告警后拦截)** 的渐进式部署方法，以确保业务的连续性和稳定性。
1. **策略设计与资源准备**
- **创建两套并行的 Firewall Manager 策略**:
- **Onboarding Policy (上线策略)**: 用于初始部署，其最终规则动作为 `ALERT`。此策略不实际拦截流量，而是对本应被拦截的 DNS 查询生成告警日志。
- **Blocking Policy (拦截策略)**: 最终生效的策略，其最终规则动作为 `BLOCK`。此策略的规则组优先级必须高于 Onboarding Policy（即优先级数值更小）。
- **定义域名列表 (Domain Lists)**: 基于第一部分中通过分析 **Route 53 Resolver query logs** 生成的域名列表，创建全局基线允许列表和账户/VPC 级的自定义允许列表。
- **配置规则组 (Rule Groups)**:
- **Walled Garden 模式**:
- *Baseline allow rule group* (优先级 1): 包含适用于所有账户的通用域名，由 Firewall Manager 集中管理。
- *Custom allow rule group* (优先级 100-9900): 包含特定账户或 VPC 的专属域名，在成员账户中单独部署和关联。
- *Baseline deny all rule group* (优先级 10000): 包含一条拦截所有未匹配流量的规则（`*`）。
- **Deny Malicious 模式**:
- *Baseline deny rule group*: 包含拦截恶意域名的规则，可引用 **AWS Managed Domain Lists**。
2. **部署 Alert 模式**
- 在 Firewall Manager 中创建并部署 **Onboarding Policy**。
- 策略将 `ALERT` 规则组关联到范围内的所有 VPC。
- 监控 DNS 查询日志，重点分析 `firewall_rule_action` 字段为 `ALERT` 的日志条目。
- 根据告警日志，识别出被误判的正常业务域名，并将其更新到相应的允许列表中，持续优化规则。
3. **分批次切换到 Block 模式**
- 部署 **Blocking Policy**，并在其 `ExcludeMap` 字段中包含所有待迁移的账户 ID，使其初始不生效。
- **选择一小批账户 (例如 4-5 个)** 作为首轮迁移对象。
- 对选定账户进行最后一次日志分析，并更新其允许列表。
- 从 **Blocking Policy** 的 `ExcludeMap` 中移除这批账户的 ID，使其正式切换到 `BLOCK` 模式。
- 监控业务运行状况，确保无异常。
- 重复以上步骤，分批次将其余所有账户迁移到 **Blocking Policy**。
4. **清理与收尾**
- 在所有账户成功迁移后，删除 **Onboarding Policy** 及其关联的规则组和资源。
- 移除用于在部署阶段排除特定 VPC 的临时标签。
## 方案客户价值
- **集中化与可扩展的安全治理**: 通过 **AWS Firewall Manager** 与 **AWS Organizations** 的集成，实现了对数千个账户和 VPC 的 DNS 安全策略的自动化部署与生命周期管理。新创建的账户将自动继承安全策略，确保了安全覆盖的完整性和一致性。
- **灵活的分层安全模型**: 同时提供 **"Walled Garden" (默认拒绝)** 和 **"Deny Malicious" (默认允许)** 两种策略，使企业能够根据不同业务单元的安全要求和风险等级，实施差异化的管控，完美平衡了极致安全与业务灵活性。
- **低风险的渐进式部署**: _"Alert-Then-Block"_ 的部署方法论是企业级大规模变更管理的最佳实践。它通过非侵入式的 `ALERT` 模式，在不影响业务的前提下发现并修复策略漏洞，显著降低了实施风险，避免了"一刀切"可能导致的业务中断。
- **增强主动威胁防御**: 通过严格控制 DNS 出口，有效阻断恶意软件连接 C2 服务器、防范基于 DNS 的数据渗透、过滤钓鱼和恶意域名，将安全防御关口前移，实现了从被动响应到主动预防的转变。
## 涉及的相关产品
- **AWS Firewall Manager**: 方案的核心编排引擎，用于在整个 **AWS Organization** 中集中配置、部署和审计 DNS 防火墙策略。
- **Amazon Route 53 Resolver DNS Firewall**: 核心的 DNS 过滤服务，负责根据已定义的规则对 VPC 内的 DNS 查询执行 `ALLOW`、`BLOCK` 或 `ALERT` 操作。
- **AWS Organizations**: 提供多账户治理框架，是 Firewall Manager 实现跨账户统一策略管理的基础。
- **Amazon Route 53 Resolver Query Logs**: DNS 查询日志的来源，是生成 "Walled Garden" 模式所需允许列表的关键数据输入。
- **AWS Managed Domain Lists**: 由 AWS 维护的恶意域名列表，可直接用于 "Deny Malicious" 策略，简化了威胁情报的管理。
- **AWS IAM**: 用于配置 Firewall Manager 管理员账户跨成员账户操作所需的相应权限。
## 技术评估
- **优势**:
- **原生集成与自动化**: 方案完全基于 AWS 原生服务，与 AWS 生态（特别是 Organizations 和 IAM）无缝集成，实现了新账户的"零接触"自动防护，自动化程度极高。
- **精细化与分层控制**: DNS Firewall 的规则组和优先级机制设计精良，支持全局基线、账户级和 VPC 级规则的叠加，为实现复杂场景下的精细化访问控制提供了强大的技术支持。
- **成熟的部署方法论**: 文中详述的 "Alert-Then-Block" 流程是一个经过实践检验的、成熟的部署模型，对其他企业在生产环境中实施大规模安全策略变更具有很高的参考价值。
- **局限性与考量**:
- **对日志分析的强依赖**: "Walled Garden" 模式的有效性高度依赖于前期对 DNS 查询日志的全面和准确分析。如果日志分析不充分，可能导致误拦截正常业务流量，引发业务中断。
- **管理复杂性**: 尽管 Firewall Manager 提供了集中管理能力，但在拥有数千个 VPC 和多样化业务的大型组织中，维护大量账户级和 VPC 级的自定义允许列表（Custom allow rule groups）仍可能带来一定的管理开销。
- **功能边界**: 该方案聚焦于 DNS 协议层面的安全控制，是纵深防御体系中的一环。它不能替代网络层的防火墙（如 Security Groups, AWS Network Firewall）或应用层的 WAF，需要与其他安全措施协同工作。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 使用 DNS 防火墙增强 Pinterest 的组织安全性：第 2 部分
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/enhancing-pinterests-organizational-security-with-a-dns-firewall-part-2/](https://aws.amazon.com/blogs/networking-and-content-delivery/enhancing-pinterests-organizational-security-with-a-dns-firewall-part-2/)
**发布时间:** 2025-08-18
**厂商:** AWS
**类型:** BLOG
---
***本文由 Pinterest 基础设施安全团队的高级安全软件工程师 Ali Yousefi 撰写***
# 介绍
在本博客系列 (共两部分) 的 [第 1 部分](https://aws.amazon.com/blogs/networking-and-content-delivery/enhancing-pinterests-organizational-security-with-a-dns-firewall-part-1/) 中，我们演示了 Pinterest 如何通过在其整个 Amazon Web Services (AWS) Organization 中启用 [Amazon Route 53 Resolver 查询日志](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html) ，从而获得了对其 VPCs 源发 DNS 流量的可见性。我们还展示了如何使用 Python 分析这些日志，以生成一组 DNS 查询允许列表。在第 2 部分中，我们将概述 Pinterest 如何使用 [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) 、[Amazon Route 53 Resolver DNS Firewall](https://aws.amazon.com/route53/resolver-dns-firewall/) 以及本系列第 1 部分中生成的允许列表，实现一个可扩展、安全、经济高效且灵活的 DNS 防火墙。我们演示了如何默认将 Organization 的成员账户置于 DNS 围墙花园 (Walled Garden) (允许列表 + 默认拒绝) 之下，同时为某些需要例外的账户提供使用 Deny Malicious (拒绝恶意域名) (拒绝列表 + 默认允许) 策略的选项。
知名的供应商解决方案为消费行业提供了类似的 DNS 过滤功能。本文中引用的技术在企业级提供了类似的保护，同时使其能够在 AWS 云中轻松地大规模管理这些 DNS 控制，并遵循安全最佳实践。
# 解决方案概述
使用的服务包括：
- **Organizations**: 实现对多个 AWS 账户的集中管理和治理
- **Firewall Manager**: 实现对整个 Organization 中各种防火墙解决方案的集中管理
- **Route 53 Resolver DNS Firewall**: 允许为从 VPC 发往 [Amazon Route 53 Resolver](https://aws.amazon.com/route53/resolver/) 的 DNS 查询配置防火墙规则
Route 53 Resolver DNS Firewall 的一些重要概念如图 1 所示：
*图 1: Route 53 Resolver DNS Firewall 服务概念*
*替代文本: 图表展示了 Amazon VPC DNS Firewall 规则组与域名列表和优先级的关联关系。上半部分说明一个防火墙规则组包含多个规则，例如规则 1 允许对域名列表 A (*.amazonaws.com., *.example.com.) 中的域名进行 A 查询，规则 n 允许对域名列表 B (*.amazonaws.com., *.example2.com.) 中的域名进行 AAAA 查询。此防火墙规则组以优先级 1 与一个 Amazon VPC 关联。下半部分显示了另一个防火墙规则组，其中规则 1 允许对域名列表 C (example3.com.) 进行 A 查询，规则 m 拒绝向域名列表 D (example4.com., example5.com.) 进行 MX 查询。第二个规则组以优先级 p 与同一个 Amazon VPC 关联。*
- [规则组 (Rule group)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-groups.html) : Route 53 Resolver DNS Firewall 规则的集合。规则组以特定的优先级与 VPC 关联。
- [规则 (Rule)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-groups.html) : 一组定义防火墙如何处理匹配的 DNS 查询的属性。
- [域名列表 (Domain list)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-domain-lists.html) : 可被防火墙规则引用的域名集合。
### 用例 1: DNS 围墙花园
*图 2: DNS 围墙花园防火墙*
*替代文本: 架构图展示了如何使用 AWS Firewall Manager 和 AWS Resource Access Manager (RAM) 跨多个 AWS 账户集中管理 Amazon VPC DNS Firewall 规则组。左侧的安全工具账户包含位于 us-east-1 区域的 WalledGarden DNS 防火墙策略，由 AWS Firewall Manager 管理。此策略包含通过 AWS RAM 共享给范围内账户的规则组。右侧显示了 AWS 账户 1 和 AWS 账户 p，每个账户都有多个 VPC。防火墙规则组通过 AWS Firewall Manager 与这些 VPC 关联，确保在所有账户和 VPC 中应用一致的 DNS 防火墙策略。箭头描绘了安全工具账户和成员账户之间的共享和关联流程。*
- **Firewall Manager** : 管理应用于 Organization 的 [DNS 防火墙策略 (DNS Firewall policies)](https://docs.aws.amazon.com/waf/latest/developerguide/dns-firewall-policies.html) 。
- **us-east-1 WalledGarden DNS 防火墙策略** : 一项 [Firewall Manager 策略 (Firewall Manager policy)](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-policies.html) ，用于规定如何在整个 Organization 中应用围墙花园。该策略确保新创建的账户立即选择加入允许列表和默认拒绝策略。
- **Route 53 Resolver DNS Firewall 规则组:** 如图 3 所示，有三种类型的规则组与围墙花园策略范围内的 VPC 相关联。
- **所有账户基线允许 us-east-1 规则组** (优先级: 1; [预处理规则组 (preProcess rule group)](https://docs.aws.amazon.com/waf/latest/developerguide/dns-firewall-policies.html) ): 包含一组标准的 ALLOW 规则，适用于策略范围内所有账户中的所有 VPC。该允许列表是使用本系列第 1 部分中的日志分析管道生成的。Firewall Manager 将此规则组共享给策略范围内的每个账户。
- **自定义允许账户 *p* VPC *m* us-east-1 规则组** (优先级 100–9900): 包含一组 ALLOW 规则，用于进一步确定账户 *p* 内的 VPC *m* 可以解析哪些 DNS 查询。该规则组包含两套规则：
1. 允许对账户 *p* 内特定、通用访问的域名和查询类型进行 DNS 查询的规则，无论该查询来自账户 *p* 中的哪个 VPC
2. 允许对账户 *p* 中 VPC *m* 特有的域名和查询类型进行 DNS 查询的规则
对于每个 VPC，都有一个这样定义的自定义规则组。这些规则组不会通过 Firewall Manager 共享或关联到范围内的 VPC。相反，它们被单独部署到账户 *p* 并手动与其各自的 VPC 关联。
- **基线全部拒绝 us-east-1 规则组** (优先级: 10,000; [后处理规则组 (postProcess rule group)](https://docs.aws.amazon.com/waf/latest/developerguide/dns-firewall-policies.html) )**: 包含一条 BLOCK 规则，用于拒绝所有与关联优先级为 1–9999 的规则组中任何规则都不匹配的 DNS 查询。Firewall Manager 将此规则组共享给策略范围内的每个账户。
*图 3: DNS 围墙花园规则组*
*替代文本:*
*图表展示了 us-east-1 区域中 AWS 账户 p 内的 Amazon VPC m 的 DNS Firewall 规则组关联关系。第一个规则组包含规则 1，允许对基线域名 (*.amazonaws.com., *.example.com.) 进行 A 查询，优先级为 1；规则 n 允许对基线域名 (*.amazonaws.com., *.example2.com.) 进行 AAAA 查询，优先级为 n。第二个规则组包含规则 1，允许对 VPC 特定域名 (example3.com., *.example4.com.) 进行 A 查询，优先级为 1；规则 k 允许对 *.in-addr.arpa. 进行 PTR 查询，优先级为 k。最后一个规则组以优先级 10,000 阻止对所有域名 (*.) 的所有查询类型。每个规则组都以定义的优先级范围与 VPC 关联，以强制执行分层的 DNS 查询控制。*
#### **先决条件**
完成此解决方案需要满足以下先决条件：
- 已在您的 Organization 中启用 Firewall Manager。所有 [启用 Firewall Manager 的先决条件](https://docs.aws.amazon.com/waf/latest/developerguide/fms-prereq.html) 均已满足。
- 一个 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 主体，该主体能够管理 Firewall Manager、策略范围内账户的 Route 53 Resolver DNS Firewall 以及策略范围内 VPC 的标签。
#### **实施**
此部署过程需要两个 Firewall Manager 策略：
1. 一个引导策略
2. 一个阻止策略
这种方法可以在策略范围内的账户过渡到阻止模式期间，维持持续的警报覆盖。每个策略都需要独立的预处理/后处理规则组和 DNS 防火墙规则。但是，两套 DNS 防火墙规则应引用相同的域名列表。对于这些策略：
- **阻止策略**: “基线全部拒绝 us-east-1 规则组” 中的规则应将其操作设置为 BLOCK。
- **引导策略**: “基线全部拒绝 us-east-1 引导规则组” 中的规则应将其操作设置为 ALERT。
如图 4 所示，阻止策略中的预处理/后处理规则组的优先级必须始终高于 (数值更小) 引导策略中对应的规则组。
*图 4: 用于将账户过渡到阻止模式的阻止和引导 Firewall Manager 策略*
*替代文本: 架构图展示了 us-east-1 区域中 AWS 账户 p 内的 Amazon VPC 的 DNS Firewall 规则组关联关系。该图包含多个具有不同优先级的防火墙规则组。第一个组包括规则 1，允许对基线列表 (*.amazonaws.com., *.example.com.) 中的域名进行 A 查询，优先级为 1；规则 n 允许对另一个基线列表 (*.amazonaws.com., *.example2.com.) 中的域名进行 AAAA 查询，优先级为 n。第二个组包括规则 1，允许对账户和 VPC 特定的域名 (example3.com., *.example4.com.) 进行 A 查询，优先级为 1；规则 k 允许对域名 (*.in-addr.arpa.) 进行 PTR 查询，优先级为 k。最后一个组包含一个阻止规则，用于阻止对所有域名 (*.) 的所有查询类型，优先级为 1,0000。这些规则组以不同的优先级范围 (1, 100–9990, 和 10,000) 与 Amazon VPC m 关联。*
要在警报模式下部署围墙花园：
1. 使用引导策略和阻止策略的 [ResourceTags](https://docs.aws.amazon.com/fms/2018-01-01/APIReference/API_Policy.html) 字段中指定的标签，标记应从围墙花园范围中排除的 VPC。在两个策略中都将 [ExcludeResourceTags](https://docs.aws.amazon.com/fms/2018-01-01/APIReference/API_Policy.html) 字段设置为 **true**。
2. 在您的 [Firewall Manager 默认管理员账户](https://docs.aws.amazon.com/waf/latest/developerguide/fms-administrators.html) (建议是您 Organization 的 [安全工具账户](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html) ) 中：
1. 创建必要的规则组
2. 配置规则
3. 创建供引导策略和阻止策略使用的域名列表
3. 对于每个策略范围内的 VPC，直接在其各自的账户中创建自定义规则组、规则和域名列表。使用日志分析 (在本系列第 1 部分中详述) 生成的允许列表来定义规则和域名列表。
4. 将自定义规则组与策略范围内的 VPC 关联，设置优先级在 100–9900 之间。
5. 在您的 Firewall Manager 默认管理员账户中，创建引导 Firewall Manager 策略：
1. 指定一个 [ExcludeMap](https://docs.aws.amazon.com/fms/2018-01-01/APIReference/API_Policy.html) ，其中包含应选择加入 Deny Malicious 选项的账户 (如果不存在则省略 ExcludeMap)
2. 使用适当的预处理/后处理值配置规则组
3. 按照图 4 所示设置关联优先级
最后一步是将账户过渡到阻止策略中。
当您的 DNS 防火墙在警报模式下运行时，[查询日志将显示警报](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/firewall-resolver-query-logs-configuring.html) ，针对任何匹配引导策略 ALERT 规则的 DNS 查询。使用 Python 分析日志中的任何警报。按照本系列第 1 部分中描述的方式处理日志，但还需包括对以下字段的分析：
- `firewall_rule_group_id`
- `firewall_rule_action`
- `firewall_domain_list_id`
来自引导策略的警报 DNS 查询可以通过以下方式识别：
1. 存在这些字段
2. `firewall_rule_action` 字段的值设置为 ALERT
在过渡到阻止模式之前，您应该为任何触发警报的 DNS 查询更新允许列表，或者对发出不希望的查询的工作负载采取适当的措施。要将策略范围内的账户过渡到阻止模式，请确保您的阻止策略已部署，并且其 ExcludeMap 字段中列出了所有账户 ID。按照图 4 所示，使用预处理/后处理值和优先级配置阻止策略中的规则组。然后，使用以下协议，分批 (每批四到五个账户) 将账户过渡到阻止模式：
3. 选择本轮要过渡的账户
4. 对于每个选定的账户：
1. 使用 Python 对策略范围内的 VPC 进行最终的查询日志分析
2. 更新粗粒度或细粒度的防火墙允许规则，以允许在步骤 2a 中识别出的任何缺失或新的 DNS 查询
3. 从阻止策略的 ExcludeMap 中移除该账户 ID
5. 对后续批次重复步骤 1 和 2，直到所有策略范围内的账户都已过渡到阻止策略
将所有策略范围内的账户过渡到阻止模式后：
6. 删除引导策略
7. 从您的 Firewall Manager 默认管理员账户中删除引导策略中使用的规则组和规则
8. 删除之前用于将 VPC 从引导策略范围中排除的任何 VPC 标签
9. 在阻止策略中，将“基线全部拒绝 us-east-1 规则组”关联的优先级设置为 10000
### 用例 2: DNS Deny Malicious
与围墙花园方法相反，Deny Malicious (拒绝恶意域名) 策略采用拒绝列表加默认允许的方法。该策略仅阻止对已知恶意或可疑域名的 DNS 查询，同时允许所有其他 DNS 查询通过。其架构如图 5 所示：
*图 5: Deny Malicious DNS 防火墙*
*替代文本: 图表展示了一个位于 us-east-1 的安全工具账户，该账户使用 AWS Firewall Manager 管理一个“DenyMalicious DNS 防火墙策略”。该策略的规则组通过 AWS Resource Access Manager (RAM) 共享给 AWS 账户 n，并在该账户中通过 AWS Firewall Manager 与多个 VPC 关联，以阻止恶意域名。*
上述架构与围墙花园类似，但更为简化，在 Firewall Manager 策略中只包含一个规则组：基线拒绝 us-east-1 规则组。该规则组仅包含阻止规则，并引用包含恶意或可疑域名的域名列表。[AWS 托管域名列表 (AWS Managed Domain Lists)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html) 可以被整合到 Deny Malicious 策略的阻止规则中。
此部署过程需要两个 Firewall Manager 策略：
1. 一个引导策略
2. 一个阻止策略
重要的配置细节：
3. 阻止策略的规则组关联优先级必须高于 (使用数值更小的值) 引导策略的规则组关联优先级。
4. 在 Deny Malicious 策略中使用 [IncludeMap](https://docs.aws.amazon.com/fms/2018-01-01/APIReference/API_Policy.html) 。
此配置确保围墙花园作为默认的组织 DNS 防火墙，而 Deny Malicious 策略则需要账户明确选择加入。
#### **先决条件**
与用例 1 的先决条件相同。在继续之前，请确保满足这些条件。
#### **实施**
要在警报模式下部署 Deny Malicious 防火墙：
1. 使用引导策略和阻止策略的 [ResourceTags](https://docs.aws.amazon.com/fms/2018-01-01/APIReference/API_Policy.html) 字段中指定的标签，标记应从 Deny Malicious 策略范围中排除的 VPC。在两个策略中都将 [ExcludeResourceTags](https://docs.aws.amazon.com/fms/2018-01-01/APIReference/API_Policy.html) 字段设置为 **true**。
2. 在您的 Firewall Manager 默认管理员账户中：
1. 创建必要的规则组
2. 配置规则
3. 在防火墙规则中引用 [AWS 托管域名列表](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html)
4. 创建引导 Firewall Manager 策略，将所有策略范围内的账户放入引导策略的 IncludeMap 中。将“基线拒绝 us-east-1 引导规则组”的规则组关联优先级设置为 2，作为预处理规则组。引导规则组中的所有规则都应将其操作设置为 ALERT
最后一步是将策略范围内的账户过渡到 Deny Malicious 阻止策略中。为此，请遵循以下步骤：
3. 对第一批账户的查询日志进行分析，查找警报。如果您在此策略范围下的 VPC 查询日志中发现警报，这可能表明您的工作负载正在尝试连接到恶意域名。请与相关团队跟进以解决这些问题，并采取适当的补救措施。
4. 将第一批账户的 ID 添加到阻止策略的 IncludeMap 字段中，并部署该策略。
5. 对于后续批次的账户：
1. 重复查询日志分析以搜索警报
2. 当准备好将账户过渡到阻止策略时，将其账户 ID 添加到阻止策略的 IncludeMap 中。
阻止策略中的“基线拒绝 us-east-1 规则组”应设置为优先级 1，作为预处理规则组。将所有策略范围内的账户过渡到阻止模式后：
6. 删除引导策略
7. 从您的 Firewall Manager 默认管理员账户中删除引导策略中使用的规则组及相关规则。
8. 删除之前为将 VPC 从引导策略范围中排除而添加的任何 VPC 标签。
# 结论
我们演示了如何在 AWS Organization 中部署 DNS 防火墙，首先以警报模式运行，然后将账户过渡到阻止模式。默认情况下，此 DNS 防火墙实施围墙花园策略，以提供强大、自动化的安全性。但是，它也可以配置为让某些账户选择加入 Deny Malicious 方法，以适应特定的例外情况。维持强大的云网络安全态势对于保护数字资产免受攻击者侵害、维护用户和合作伙伴的信任至关重要。针对公司 DNS 配置的攻击可能会严重损害其行业声誉，如果影响重大，还可能导致收入下降。部署 DNS 防火墙有助于大规模保护组织的敏感信息，并展示了在降低网络安全风险方面采取的主动方法。有任何问题或反馈吗？请在下方的评论区分享您对这个主题的看法。
* * *
### 关于作者
### Ali Yousefi
Ali Yousefi 是 Pinterest 的一名高级软件工程师，专注于网络安全、大数据、AI/ML 和云架构。在他的职位上，他领导设计和实施 AWS 中大规模、安全、多账户的架构，这些架构影响着各种不同的系统。他与组织内的多个团队协作，解决复杂的技术问题。Ali 在数据、分析、AI、数字广告和金融服务等多个行业拥有丰富的工作经验。
<!-- AI_TASK_END: AI全文翻译 -->