与过去流行的传统"城堡与护城河"部署相比，安全边界已经变得不那么明确。在固定边界内，使用部署在数据中心内的单一 Web 应用程序防火墙（WAF）来保护多个应用程序相对容易。然而，随着应用程序和服务扩展到传统数据中心之外，这种方法不再具备足够的灵活性。以混合方式配置网络和服务、以及采用 SaaS 平台有很多充分的理由，因此更新 WAF 方案以覆盖这种场景非常有价值。
基于云的 WAF 解决方案可以通过灵活的部署模型来控制边界蔓延，覆盖部署在本地、基于云的 IaaS 和 PaaS 环境以及混合环境中的应用程序和服务。
与此同时，基于云的 WAF 的错误实施可能导致安全策略碎片化和重复，从而增加维护和监控的开销。除了这些低效率带来的明显经济影响外，效率降低还可能削弱安全态势本身。这最终可能导致不同严重程度的安全事件，具体取决于实际场景。
本设计指南面向希望实施灵活、基于云的 WAF 安全配置的安全和网络管理员/架构师。此配置可以跨越多个应用程序、域和服务——所有这些都部署在混合环境中。
Cloudflare 提供全面的应用程序安全与性能解决方案，其中包括高度可配置的基于云的 Web 应用程序防火墙（WAF）。
在本指南中，您将学到：
- 如何实施 Cloudflare WAF 并提取公共规则。
- 如何在多个应用程序之间轻松实施通用配置。
- 如何在需要时部署例外和特定配置。
- 部署 Cloudflare WAF 时应遵循的最佳实践。
大多数 Cloudflare 客户在单个账户（或企业组织）中会接入多个 Cloudflare 区域（Zone）。每个 Cloudflare 区域通常映射到一个二级域名（如 example.com），然后该区域内处理其所有子域名（web1.example.com、web2.example.com 等）。
在此设置中，Cloudflare 是一个基于 DNS 的反向代理。每个完全限定域名（FQDN）都在其 Cloudflare 区域中配置，并指向客户的源服务器。在这方面，Cloudflare 不区分源服务器的位置。它可以部署在本地、在云中运行的虚拟机上，也可以是第三方提供的 SaaS 服务。
通常，多个 FQDN 指向相同的共享 Web 基础架构。例如，通过 IP 地址或另一个 FQDN 访问该基础架构。某些 FQDN 也可能指向专用的源基础架构或外部 SaaS 端点。
在许多情况下，Cloudflare 客户最终会在单个 Cloudflare 账户中管理多个 Cloudflare 区域（如 example.com、example.org、myappexample.com 等），以及每个区域内的多个 FQDN。通常，多个区域的多个 FQDN 在背后都指向同一共享 Web 基础架构。
例如，您可能处于以下（或类似）场景：
- 您的大多数 Web 应用程序运行在新部署的内部内容管理系统（CMS）上
- 您还有一些运行在自定义技术栈上的旧版 Web 应用程序。
- 最后，您可能为少数应用程序提供了由合作伙伴管理的专用基础架构。
以下示意图可视化了示例场景：
从 WAF 设置的角度来看，此场景提出了一些有趣的需求：
- 创建一个易于部署的配置，在大多数应用程序前实施标准 WAF 规则配置。
- 能够微调和调整部署在旧版应用程序前的规则，这些应用程序比其他应用程序更容易产生误报。
- 包含一个"全量匹配"配置，确保始终对不属于上述场景的所有 Web 流量应用 Cloudflare 默认 WAF 设置。
- 随着应用程序的添加和删除，尽量减少设置时间和持续维护工作量。
在本设计指南中，我们将回顾 Cloudflare WAF 的工作原理以及为实现上述所有架构需求而提供的工具。
Cloudflare WAF 在区域和账户级别运作。有不同的 WAF 阶段（http_request_firewall_custom、http_ratelimit 和 http_request_firewall_managed），分别对应自定义规则、速率限制规则和托管规则。这些阶段在账户级别和区域级别都存在。更多信息，请参阅以下文档。需要注意的是，账户规则集会在区域规则集之前进行评估。
出于本指南的目的，我们将基于上述示例场景和 WAF 需求进行构建。您有一个 Cloudflare 账户（或企业组织），并在其中接入了两个二级域名。
假设六个 FQDN 对应六个跨两个域的应用程序。对于这些应用程序，您希望应用基线 WAF 安全态势。然而，在这六个应用程序中，有两个需要特殊处理：
- 一个实现在旧版应用程序服务器上，容易产生误报。
- 另一个由第三方在其自己的基础架构上实施。
让我们在下面可视化该场景：
我们将以 Cloudflare 托管规则集为例，同时请记住，该方法也可用于其他 Cloudflare 托管规则、速率限制规则和自定义规则。
- 对于
web1.example.com、web2.example.com、web3.example.com和web5.example.org：您希望应用已由 Cloudflare 调整好的默认 WAF 托管规则集。 - 对于
special4.example.com：您希望应用默认托管规则集的不同子集，因为您已经发现了几条在旧版应用程序上导致误报的规则。 - 对于
special6.example.org：您希望以日志记录模式应用托管规则集，因为这是第三方新引入的应用程序，您需要开始评估如何保护它。
然后，您可以采用以下方法：
- 在账户级别部署一个 Cloudflare 托管规则集实例。这为需要它的四个 FQDN 实施了通用规则子集。这比在区域级别重复相同配置四次更容易设置和维护。
- 对于
special4.example.com和special6.example.org，您将部署另外两个托管规则集实例，并针对这些特定 FQDN 背后的应用程序进行特定调整。
实际上，使用账户级 WAF 的托管规则集，您可以部署三个托管规则集实例。每个实例都有自己的自定义过滤表达式，用于检查 HTTPS 请求的主机名是否属于列表中的某个 FQDN：
- 对于第一个列表（
web1.example.com、web2.example.com、web3.example.com和web5.example.org），您将以Default配置应用 Cloudflare 托管规则集。 - 对于
special4.example.com，相同的规则集将以Default模式部署，但需要禁用导致误报的特定规则。这可以通过仪表板或 API 使用规则覆盖来实现。此处提供了实际示例。 - 对于
special6.example.org，您重复第一个列表的设置，这次将托管规则集实例修改为以Log模式而非Default模式运行。
让我们在下面的示意图中可视化完整配置：
此设置将提供三个托管规则集实例，针对每个应用程序组进行校准。
如果将来有其他需要保护的应用程序，只需将新应用程序的 FQDN 添加到过滤表达式中即可。通常，大多数应用程序会被添加到使用推荐 Cloudflare 配置的标准规则集实例中。另一个常见策略是将新应用程序添加到 Log 模式实例，以便对其进行监控，并最终过渡到 Default 模式规则集或在需要时过渡到更具体的变体。
规则集（尤其是托管规则集）已经由 Cloudflare 精心调整以避免误报。它们可以针对大多数应用程序部署，几乎不需要或完全不需要调整。这意味着在大多数情况下，客户可以直接使用默认规则集配置，仅在需要时进行自定义。
如果这是您的场景，您可以通过使用例外（Exceptions）按以下方式简化上述设置：
- 首先，您可以通过以
Log模式部署规则集来识别哪些应用程序（FQDN）需要特殊处理。例如，经过测试后，您发现special1.example.com需要禁用一小组托管规则，而special2.example.org需要禁用类似但不同的一组规则。 - 部署两个托管例外，过滤器与每个 FQDN 匹配，然后跳过托管规则集中的这些规则。
- 最后，部署托管规则集的默认版本，该版本将匹配其他所有内容，并运行 Cloudflare 推荐的托管规则集设置。
当例外情况较少，且初始校准确认 Cloudflare 为最大程度减少误报而进行的精细调整适合您的情况时，这种方法可能更简单。
Cloudflare 提供创建主机名列表的功能。在这种情况下，过滤表达式可以更改为引用此类列表变量。
然后，您可以直接更新列表并在多个规则集中重复使用它们。例如，对 Cloudflare 托管规则和 OWASP 规则集以及速率限制使用相同的列表。您的过滤器将直接引用列表，从而实现更清晰、更易维护的配置。
使用列表时，还可以更轻松地采用在评估顺序中最后运行的"全量匹配规则"。例如，当 HTTPS 请求中的主机不包含在任何列表中时，可以实施 Default Cloudflare 托管规则集。这确保始终应用默认 WAF 托管规则配置，以防某些应用程序因错误而未添加到列表中。
WAF 配置可以通过 API 调用和 Terraform ↗ 进行管理。当您希望将该方法扩展到更多区域和 FQDN，并避免在仪表板中进行重复性手动操作时，这尤其有用。
例如，可以创建一个默认的 Terraform 配置文件来定义规则集和列表，然后根据需要进行维护和应用，而无需在 Cloudflare 仪表板中进行更改。
在可能的情况下，Cloudflare 建议在账户级别维护配置，尤其是当 Cloudflare 区域将包含多个 DNS 记录，且每个记录都需要自定义配置时。
在区域级 WAF 中，您只能部署每个规则集的一个实例（托管规则、OWASP 规则等），因此在此级别处理特殊场景可能更复杂或无法实现。
上述针对托管规则的方法也可以应用于自定义规则集和速率限制，将灵活性扩展到您可用的所有 WAF 安全工具。
除非您的配置特定于单个区域，否则 Cloudflare 建议在账户级别实施。
更多信息，请参阅以下资源：
总之，本设计指南说明了如何实施灵活的 WAF 配置以覆盖多个应用程序和域。所描述的方法减少了部署、维护和更新 WAF 安全配置所需的工作量。