概览

大型组织有多个团队开发和运营自己的 Web 应用程序或 API，需要使用工具和流程来推动各团队安全控制的一致性，以避免暴露的端点保护薄弱或没有保护。AWS Firewall Manager 是组织可以用来大规模治理 AWS WAF 和 Shield Advanced 部署的一种工具。

AWS Firewall Manager

Firewall Manager 允许您定义 AWS WAF 或 Shield Advanced 策略，这些策略会在您的公开资源（例如 CloudFront 分配、ALB 或 API Gateway）上自动部署。策略包括：

  • 定义其适用的范围：什么类型的资源（CloudFront、ALB 等）？是否包含或排除带有特定标签的资源？要包含或排除哪些帐户或组织单位？
  • 规则：定义应用哪些 WAF 规则组、是否集中启用日志记录以及是否添加 Shield Advanced 保护。
  • 操作：定义在策略范围内找到资源时要执行的操作。例如，您可以自动强制执行策略规则或仅报告该规则。在初始 Firewall Manager 部署中，建议在不进行自动修复的情况下启动，以确定需要手动处理的资源，同时将对现有应用程序的影响降至最低。获得更高的置信度后，可以将 Firewall Manager 切换为自动修复。

要使用 Firewall Manager，请首先考虑其先决条件。请注意，AWS Config 是 Firewall Manager 的先决条件之一。为了优化 AWS Config 的成本，如果仅允许使用 Firewall Manager，则将资源类型限制为记录与场景相关资源的设置（例如 WAF、CloudFront 分配、负载均衡器等）。另请注意，策略是区域构造（例如，您需要 CloudFront 的全局策略，以及拥有 ALB 和 API Gateway 等区域资源的每个区域的区域策略）。考虑使用此 AWS 解决方案，以便在 AWS Organizations 中部署 Firewall Manager 策略

大规模 AWS WAF 部署

创建 WAF 策略时，Firewall Manager 会在策略范围内的 AWS 账户中部署 WAF WebACL，其中包含策略 WAF 规则。在 WAF 策略中，您可以定义两种类型的规则组，由 Firewall Manager 将其添加到已部署的 WebACL：

  • 第一个规则组，将在任何其他规则之前进行评估。
  • 最后一个规则组，将在最后进行评估。

这样便可让中央安全团队管理整个组织的通用规则组，同时让您的应用程序团队可以在第一个和最后一个通用规则组之间添加与其应用程序相关的自定义规则。由于 AWS WAF 中的规则是按顺序评估的，因此首先评估第一个通用规则组，然后评估应用程序团队创建的规则，最后评估最后一个通用规则组。

您可以构建 CI/CD 管道来更新管理 AWS 账户上 AWS WAF 策略中的通用 WAF 规则组，然后 Firewall Manager 会在几分钟内将其部署到您的组织中。在此博客中了解 OLX 如何使用 CI/CD 管道和中央日志记录系统部署中央 WAF 策略。

常见的 WAF 治理模型

Firewall Manager 是一款灵活的工具，允许您根据组织的要求制定各种安全治理策略。在任何集中式安全治理中，您都需要在集中执行规则以提高保护级别与处理集中部署的通用规则造成的误报之间进行权衡。

缓解严重威胁的单一策略

如果您拥有高度自主的应用程序团队，并且想要避免管理误报，请创建单一的中央 WAF 策略来应对严重威胁。例如，您可以根据具有高阈值的速率限制创建 WAF 规则，与高可信度的恶意 IP 信誉列表以及针对禁运国家/地区的地理封锁规则结合使用。您还可以启用 Shield Advanced 并激活自动应用程序层 DDoS 缓解。这些规则的误报率往往很低，但可以有效防御 HTTP 泛洪。此外，当发现严重且影响较大的零日漏洞时，您可以使用已部署的 WAF 通用规则组集中应用缓解措施。

建议为您的应用程序团队创建一个内部 wiki，并提供有关在其 WebACL 中添加与其应用程序相关的自定义 WAF 规则的最佳实践指导。例如，如果其应用程序容易受到 SQLi 和 XSS 攻击，则指导其增加针对此类攻击的保护。

缓解各种威胁的单一策略

如果想将中央安全覆盖范围扩大到更广泛的威胁，请加强中央通用规则组，但允许应用程序团队自主管理误报。要实现此 WAF 治理模型，请将您的通用规则放在计数模式下 WAF 策略的第一个规则组中。这些规则仅发出标签，您可以在 WAF 策略的最后一个规则组中使用这些标签来阻止与这些标签匹配的请求。

如果您的应用程序团队遇到误报，他们可以使用您的规则发出的标签来创建排除规则。为了举例说明此情况，请考虑在计数模式下将用于防御 SQLi 的 Amazon 托管规则（AMR）添加到第一个规则组的场景。在最后一个规则组中，规则阻止了上述 AMR 发出的标签为 label_matched=”SQLi_BODY” 的请求。如果 AMR 在特定 URL（url=”/form1”）上给应用程序带来误报，则应用程序团队可以在 WebACL 中创建排除规则来减少这种误报（例如 IF url=”/form1” AND label_matched=”SQLi_BODY” then ALLOW）。允许规则操作将终止，这意味着 AWS WAF 将停止评估后续的阻止规则。

要在不影响现有应用程序的情况下推出此策略的更改，请考虑创建此策略的副本，供应用程序团队在暂存环境中使用。两个策略都需要有相互排斥的范围。例如，生产策略适用于除带暂存标签外的所有 CloudFront 分配，而暂存策略适用于所有带暂存标签的 CloudFront 分配。对于大多数更新，您可以先将其发布到暂存策略中，然后使用 SNS 主题通知所有应用程序团队。收到更改通知后，应用程序团队将在其暂存环境中测试新的策略版本，该环境可以自动化，并在需要时管理误报。然后，在商定的延迟之后，中央团队会将更改传播到生产策略。可以立即应用一周内无法完成的关键更新（例如针对 Log4j CVE 的保护），代价是暂时出现一些误报，直到应用程序团队处理异常。

如果您希望强制应用一致的安全基准，同时仍允许账户管理员进行一些自定义设置。本文概述了设计和实施集中管理的安全基准策略的步骤。它还详细介绍了测试和部署该策略的最佳实践。

适用于不同应用程序类型的多种策略

如果您的要求与以前相同，但想减少应用程序团队加强应用程序安全所带来的认知负担，可以考虑为组织中存在的不同应用程序类型创建策略目录。例如，可以创建一个包含两个策略的目录：

  • 第一个策略：建议保护基于 Wordpress 的应用程序
  • 第二个策略：建议保护使用 SQL 数据库的 PHP 应用程序。您可以创建此策略的两个版本，采用不同的阻止敏感度级别。这样，应用程序团队便可选择符合其安全要求（偏执级别）以及管理误报意愿的策略。

每个策略的范围由特定标签定义（例如，第一个策略为 wordpress，第二个策略为 LAMP_HIGH/LAMP_LOW）。应用程序团队会查阅可用策略的目录，并将所需策略的标签应用于其资源。Firewall Manager 会自动将 WAF WebACL 与其资源相关联。

请注意，使用这种方法，您可以管理误报，并以与上一节中所述相同的方式进行分阶段更改。

应用程序级行为检测

在应用程序级别，您可以根据应用程序的预期使用自定义信号来识别异常行为。例如，您可能希望用户按特定的顺序浏览您的应用程序，或者您不希望用户根据其注册地址从/向某些国家/地区订购某些商品。通过此类信号，您可以使用 AWS WAF 自动进行响应，例如阻止或质询使用来自具有可疑应用程序级别行为 IP 的 CAPTCHA 请求。要开始使用基于应用程序信号的 WAF 自动化概念，请考虑此 AWS 解决方案中的示例。

高级自动化包括：

  • 消耗 Cognito 在登录/注册过程中发出的高风险事件。
  • 消耗 Fraud Detector 确定的高风险事件。Fraud Detector 使用机器学习（ML）以及来自 Amazon Web Services（AWS）和 Amazon.com 20 年积累的欺诈检测专业知识，可实时自动识别人类和机器人执行的潜在欺诈模式。Fraud Detector 通可过分析应用程序级用户行为来检测欺诈，使用您自己的历史欺诈数据来训练、测试和部署为您的使用案例量身定制的欺诈检测机器学习模型。

为每个应用程序团队提供完全托管的策略

如果您希望将 WAF 管理从应用程序团队完全转移到您的中央安全团队，则为每个应用程序团队创建专用策略，范围仅适用于其 AWS 账户。在这种情况下，您需要创建初始设置流程，并建立应用程序团队和中央安全团队之间的沟通渠道以管理误报等操作。

资源

此页内容对您是否有帮助？

 反馈