利用AWS Firewall Manager统一部署Network Firewall (一)分布式架构

摘要：本文中主要介绍通过AWS Firewall Manager为用户集中创建管理多账号下的分布式Network Firewall部署。

01 一、引言

02 二、AWS Firewall Manager

03 三、使用 Firewall Manager 的先决条件

04 四、Firewall Manager 支持的 NFW 部署模式

05 五、总结

一、引言

随着企业业务的快速扩展， AWS 环境的规模也在持续增长。越来越多的团队选择采用多账户架构来实现资源隔离、权限管控和成本分摊 —— 这是 AWS 最佳实践所推荐的。

然而，多账户架构在带来灵活性的同时，也引入了新的安全管理挑战：如何确保每一个账户都部署了一致的安全策略？如何防止某个账户因配置疏漏而成为整体安全体系中的薄弱环节？

传统的安全配置方式依赖人工逐账户操作，不仅效率低下，还极易因操作差异导致策略不一致。当组织规模扩大到数十甚至数百个账户时，这种方式几乎无法维持有效的安全治理。与此同时，随着新账户的不断创建，如何保证它们在上线之初就满足安全合规要求，也成为安全团队面临的现实难题。

二、AWS Firewall Manager

AWS Firewall Manager正是为解决上述问题而生，它是一项 AWS 安全管理服务，可以帮助您集中管理和统一部署跨多个 AWS 账户和资源的安全策略，以 ” 一次定义、全组织生效 ” 的方式实现，从根本上解决多账户环境下安全管理的规模化难题。

集中管控：通过 AWS Organizations ，在组织级别统一管理 WAF 规则、安全组、 AWS Shield Advanced 、 Network Firewall 、 Route 53 DNS Firewall 等多种安全策略

自动化合规：新账户或新资源加入后， Firewall Manager 可自动应用预设的安全策略，确保合规性，无需手动逐一配置

三、使用 Firewall Manager 的先决条件

在使用 Firewall Manager 创建和应用 Network Firewall 策略之前，您必须完成以下先决条件：

1. AWS Organizations ：您的公司必须使用 AWS Organizations 管理您的账户，并且必须启用所有功能。有关更多信息，请参阅创建组织和启用组织中的所有功能。

2. Firewall Manager 管理员账号：您必须将组织中的一个 AWS 账户指定为 Firewall Manager 管理员。这将授予该账户在整个组织内部署安全策略的权限。

3. AWS Config ：您必须为组织中的所有账户启用 AWS Config ，以便 Firewall Manager 可以检测到新创建的资源。要为组织中的所有账户启用 AWS Config ，请使用 StackSets 示例模板中的 “ 启用 AWS Config” 模板。

4. AWS Resource Access Manager (AWS RAM) ：您必须为组织中的所有账户启用 AWS RAM ，以便 Firewall Manager 可以修改网络防火墙配置。

5. 其他具体要求，请详见如下链接

四、Firewall Manager 支持的 NFW 部署模式

分布式架构

集中式架构

导入现有 NFW

4.1 Network Firewall 创建 ( 分布式架构 )

用户需要在同一个 Org 下多个账号的不同的 VPC 内分别部署 NFW ，用于各 VPC 与互联网边界的安全管控需求，属于典型的分布式 NFW 的部署场景。

[图1]

4.1.1. 选择部署 NFW Policy 的 Region

ℹ️ 提示：

Firewall Manager 虽然是集中配置管控工具，但创建的 NFW 的 policy 是基于 Region 的。

假设用户在 3 个 region 内给各自所属的 VPC 部署 NFW ，那么最少需要部署 3 个 Firewall Manager Policy 。

[图2]

4.1.2. 选择部署 NFW Distributed 模式

[图3]

4.1.3. 命名 NFW Policy

Stream exception Policy如果没有特殊需求，一般选择默认的就可以，默认 Drop 。

[图4]

4.1.4. Stateless default action

除了 ICMP 等管理流量，我们不推荐用户使用 Stateless 引擎，建议用户使用 Stateful ，所以 Stateless 配置留空，不做特殊配置。

配置将所有流量转发至 Stateful 引擎即可。

[图5]

4.1.5. Stateful rule 配置

建议选择 Strict 按照顺序执行，在 default action 中按需选择，在 stateful rule group 中添加在 Firewall Manager Administrator 账户中创建的 Rule Group ，这里不详细介绍 Stateful rule 的配置细节，主要关注在 Firewall Manager 创建 NFW 的流程上。

[图6]

ℹ️ 提示：

在这里关联的 rule group ，是Firewall Manager Administrator账户中创建的 Rule Group ，它具有全局最高优先级的隐含定义。

[图7]

可以将 Firewall Manager Administrator 账户中创建的Rule Group关联到此 policy 中。

[图8]

4.1.6. Logging 配置

在这里配置的 alert 或者 flow 的 log 目标只能是 S3 桶，所以如果有特别配置要求，此处可以留空，进入到具体创建好的 NFW 中再去打开并配置比如发往 Cloudwatch 或者 Kinesis 。

[图9]

4.1.7. NFW Endpoint 配置

建议选择自定义 EP 的配置，按需选择多 AZ 的 HA 部署模式，可以自定义每个 EP 所属的 subnet 子网，或者 Firewall Manager 会自动按照 /28 的子网，从 VPC 中自动配置。

[图10]

ℹ️ 提示：

这里面会有配置提示：

1. Firewall Manager 会按照如上定义的 Policy 创建 NFW 。

2. Firewall Manager 关联的全局的 Firewall Manager Administrator 账户中创建的 Rule Group 优先级是最高的，子账号的用户是无法修改这部分的配置，也无法查看这部分的具体配置信息，该 Rule Group 是通过 RAM share 给关联的子账号下。

3. Firewall Manager 只创建 NFW 和 EP ，具体 EP 所在子网的路由表中的路由信息，需要用户自己编辑填写。

[图11]

4.1.8. 路由配置

Firewall Manager具备帮助用户检查 / 检测 EP 所在子网中的路由缺失的功能，可以进一步防止流量没有经过 NFW 导致的策略没有生效的问题。比如可以帮助用户将与互联网 /IGW 之间的路由做添加，包括是否打开跨 AZ 等功能。

但由于如上涉及的内容，是标准 VPC Networking/subnet/routing table 的配置选项，还是建议用户按照标准的 VPC networking 的配置方式进行配置梳理，这样逻辑性会更强一些。

此选项可以选择 Off 。

[图12]

4.1.9. Policy Scope

如下配置示例中的定义：

在此 Org 下的所有 account 都适用此 Firewall Manager 定义的 Policy ，对于具体的 Resource 如 VPC 中，定义了 Tag 为 NFW ， test 的 VPC ，适用此 Policy ，即会为所有账号下的所有打了此 Tag 的 VPC ，创建 NFW 。