亚马逊AWS官方博客

在多账户场景下将 Amazon WAF 安全自动化解决方案与 Amazon Firewall Manager 结合使用

1.背景

Amazon WAF安全自动化解决方案[1]可用于自动部署一系列Amazon WAF(Web应用程序防火墙) 规则。除了最基本的策略，这一解决方案还包含了通过对Amazon Application Load Balancer (ALB) 和WAF日志进行分析而自动生成的WAF策略，从而对Web应用程序的请求进行更精细的控制，自动化解决方案简化了Amazon WAF 的配置过程，帮助用户更好地进行Web应用安全防护。

Amazon Firewall Manager能够在Amazon Organizations中跨账户和应用程序集中配置和管理防火墙规则，监控不在WAF规则覆盖范围内的账户和资源的状态，并采取相应的措施。使用Amazon Firewall Manager可以帮助用户确保Organization多账号环境下的Web应用程序得到最基本的保护。

在企业多账户环境下，对于Web应用安全防护的管理需求是复杂多变的。一方面，管理员希望能够对所有Web应用安全配置进行关联管理和持续的配置合规审计；另一方面，对于特定应用，可能需要有针对性地设置一些定制化Web访问控制列表 (Web ACL) 策略，进行更精细化的防护。Amazon WAF 安全自动化解决方案会生成一个包含一系列规则的Web ACL，而Amazon Firewall Manager也会在指定账户内根据policy创建一个Web ACL。那么，有没有可能将这两者合二为一，既保留Amazon Firewall Manager的多账号集中管理能力，保障基本的安全防护，又能获得Amazon WAF 安全自动化解决方案的自定义能力呢？华讯网络作为通过亚马逊云科技安全能力认证的咨询合作伙伴，在实际项目中摸索出一套将上述WAF配置管理方式进行集成，从而更好地适应企业客户需求的方法。

2.Web ACL 的管理策略

我们需要先梳理清楚Web ACL 的管理策略，哪些策略由Amazon Firewall Manager进行管理，哪些通过Amazon WAF 安全自动化解决方案下发，或者由用户自己管理。采用清晰的Web ACL 管理策略才能有效避免重复的规则配置，使所有账户下的Web ACL 配置保持一致。

规则适用范围 举例 管理位置与方式
Web ACL 与ALB、API Gateway的关联关系 — 由Amazon Firewall Manager统一进行管理
普遍适用的规则 Core rule set中的规则，统一的header处理标准 Amazon Firewall Manager中的基础Security policy
具有一定通用性，针对特定Web应用类型和场景的规则 SQL database rule set，Bot Control rule set中的规则 为组织中常见的Web应用类型有针对性地创建Amazon Firewall Manager Security policy作为模板
针对特定应用的规则，或者不便于通过Amazon Firewall Manager配置的规则 Amazon WAF安全自动化解决方案中通过分析ALB access log生成的规则 通过Amazon WAF安全自动化解决方案，或以其为模板修改后进行配置
临时或测试规则 — 通过console或命令行手工创建管理

3.技术实现思路

由Amazon Firewall Manager托管生成的Web ACL 与Amazon WAF 安全自动化等其他方式生成的Web ACL 是不同的。Firewall Manager管理的Web ACL 将规则分为三组，first rule group和last rule group由Firewall Manager管理，而两组中间的规则由对应账户自行管理。因此，如果以Firewall Manager管理的Web ACL 为基础，将Amazon WAF 安全自动化生成的规则配置到first rule group和last rule group之间，即可实现两者的集成。

那么，如何让Amazon WAF 安全自动化的CloudFormation模板不创建新的Web ACL，而是使用Amazon Firewall Manager管理的已有Web ACL呢？这就要用到CloudFormation的导入资源功能。首先，对Amazon WAF 安全自动化的 CloudFormation 模板进行分析，其包含一个主stack和两个nested stack，而Web ACL 和规则的创建，就是由nested stack完成的。

然后，进一步分析Amazon WAF 安全自动化解决方案的CloudFormation模板，我们发现其中包含的资源之间，存在较为复杂的依赖关系。在这种情况下，要将现有的资源导入模板，基本逻辑就是把模板中的所有资源按照“不依赖要导入的资源”、“导入的资源”和“依赖要导入的资源”进行分组，将原有模板拆分为“create”、“import”和“update”三个模板，分别执行“创建堆栈”、“导入资源”和“更新模板”三个操作。这套方法可以应用于所有需要通过外部逻辑对自动化解决方案进行自定义的类似场景。

4.技术实现细节

以下演示集成方案的实现过程。

4.1 创建基础Amazon Firewall Manager Security policy

按照下图所示信息配置安全策略，单击“Next


稍等片刻，可以看到由Amazon Firewall Manager根据Security policy在指定账户中创建的Web ACL。

4.2 修改Amazon WAF 安全自动化解决方案 CloudFormation 模板

原Amazon WAF安全自动化解决方案有适用于AWS全球区域和适用于亚马逊云科技中国区域两个版本，下面以适用中国区域的版本为例，全球区域修改方法类似。

从以下地址可以获取到三个原解决方案的CloudFormation模板：https://www.amazonaws.cn/solutions/amazon-waf-security-automations/

在后续引用CloudFormation模板的步骤中，也会给出基于原解决方案v1.0.0版本修改后的模板地址， 感兴趣的读者可以以此为基础直接使用或进行其他自定义修改。 如果未来原解决方案升级修改了CloudFormation模板，也可以按以下大致步骤自行进行修改：

  1. 如下图所示，修改原模版中TemplateBucket的值为用于存放修改后CloudFormation模板的S3 Bucket， 该值用于定义子堆栈所用的CloudFormation模板位置。注意，由于仍要使用原解决方案中Lambda code zip，因此KeyPrefix不要修改。

  1. 模板aws-waf-security-automations-webacl.template中的资源“WAFWebACL”和模板aws-waf-security-automations.template中的资源“WebACLStack”是需要导入的资源。因此，将“WAFWebACL”和“WebACLStack“，以及依赖于这两个资源的其他资源从原模版中去除，保存为“create”模板。
  2. 在“create”模板基础上，增加两个需要导入的资源“WAFWebACL”和“WebACLStack”，保存为“import”模板。注意，对于要导入的资源需要增加“DeletionPolicy”属性，如下图所示。

另外，WebACLStack资源的TemplateURL需要替换为修改后的“update”模板存放的地址，如下图所示。

  1. 在原始模板的基础上，将以上“create”和“import”两个模板的修改合并进来，保存为“update”模板。这样，原Amazon WAF 安全解决方案的CloudFormation模板就被分解为三个模板，将这些模板上传至新的位置。

4.3 导入Amazon Firewall Manager创建的Web ACL

按照create->import->update的顺序创建相应的Amazon WAF安全解决方案CloudFormation Stack。

  1. Web ACL。按照下图所示进行设置，并等待Stack创建完成。注意这里的参数应与之后的WAF Automation Stack的参数保持一致，另外ParentStackName与之后创建的WAF Automation Stack名称保持一致。

示例所使用的修改后模板位置为: https://solutions-dist-cn-northwest-1.s3.cn-northwest-1.amazonaws.com.cn/aws-waf-security-automations/v1.0.0/aws-waf-security-automations-webacl-create.template

注意，由于是手动进行原子堆栈的创建过程，这里所使用的参数应与之后的WAF Automation Stack的参数保持一致，另外ParentStackName与之后创建的WAF Automation Stack名称保持一致。

  1. Web ACL的import。导入Firewall Manager创建的Web ACL，按下图所示信息设置，并等待导入操作完成。

示例所使用的修改后模板位置为: https://solutions-dist-cn-northwest-1.s3.cn-northwest-1.amazonaws.com.cn/aws-waf-security-automations/v1.0.0/aws-waf-security-automations-webacl-import.template


  1. 导入Firewall Manager创建的Web ACL

  1. Web ACL的update。单击“Update”按钮，按下图所示信息设置，并等待更新操作完成。

示例所使用的修改后模板位置为: https://solutions-dist-cn-northwest-1.s3.cn-northwest-1.amazonaws.com.cn/aws-waf-security-automations/v1.0.0/aws-waf-security-automations-webacl-update.template


4.4 导入Web ACL nested stack至WAF Automation解决方案

  1. WAF Automation的create。按照下图所示进行设置，并等待Stack创建完成。

示例所使用的修改后模板位置为: https://solutions-dist-cn-northwest-1.s3.cn-northwest-1.amazonaws.com.cn/aws-waf-security-automations/v1.0.0/aws-waf-security-automations-create.template


  1. WAF Automation的import。

示例所使用的修改后模板位置为: https://solutions-dist-cn-northwest-1.s3.cn-northwest-1.amazonaws.com.cn/aws-waf-security-automations/v1.0.0/aws-waf-security-automations-import.template



  1. WAF Automation的update。

示例所使用的修改后模板位置为: https://solutions-dist-cn-northwest-1.s3.cn-northwest-1.amazonaws.com.cn/aws-waf-security-automations/v1.0.0/aws-waf-security-automations-update.template

等待更新完成。

至此，在Amazon Firewall Manager创建的Web ACL 基础上的WAF Automation方案已部署完成。完成后的控制台界面如下图所示。

6.总结

通过CloudFormation的导入资源功能对Amazon WAF 安全自动化解决方案进行简单的修改，就可以让原来针对单个Web ACL 设计的解决方案融入企业客户多账户体系，在统一管理和定制化的Web ACL策略配置之间取得平衡，满足多账户部署的复杂需求。这样的思路同样可以应用到很多其他的解决方案实践中，增强和扩展解决方案的使用场景。

另外，本文介绍的实现过程主要用于说明实现思路，实现过程操作稍显繁琐，还有进一步优化的空间，读者可以根据实际情况在实践中进行进一步修改：

  1. 可以通过CloudFormation直接生成Firewall Manager Security Policy简化操作过程，不过由于一些限制暂未实现，如：Security Policy的分租逻辑和账号应用范围因实际需求而异，无法进行标准化定义；亚马逊云科技中国区域的CloudFormation在撰写本文时暂时无法识别AWS::FMS::Policy资源类型。
  2. 可以使用AWS CLI 编写shell来进行CloudFormation模板的create、import和update操作，以简化操作过程。

参考资料

[1] https://www.amazonaws.cn/solutions/amazon-waf-security-automations/

本篇作者

霍延峰

拥有超过17年的IT从业经历，包括 ERP 系统前端和后端开发人员、OA 系统和基础架构运维、企业软件系统架构、数据库管理员和商业智能工程师、虚拟化和私有云工程师、公有云解决方案架构师。他热衷于使用新技术来解决客户的实际问题，在云架构和应用现代化、DevOps、数据科学和其他领域具有独特的见解。他从2016年开始为使用亚马逊云科技的ECCOM客户提供帮助，并陪伴数十家客户的亚马逊云科技迁移旅程，以及ECCOM自身从传统网络系统集成商到亚马逊云科技的现代MSP服务提供商的转型过程。