亚马逊云科技 WAF 部署小指南（七）使用 Centralized Logging with OpenSearch Light Engine 降低 Amazon WAF 日志监控成本

Amazon WAF 是一款 Web 应用程序防火墙，可以保护您的 Web 应用程序或 API 免受可能影响可用性、危及安全性或消耗过多资源的常见网络攻击和机器人攻击。但是，仅仅部署 WAF 还不够，持续监控 WAF 日志对于确保应用程序的安全性、合规性和业务连续性同样至关重要。

监控 WAF 日志可以帮助您：

• 及时发现和响应 Web 应用程序所面临的各种攻击行为，如 SQL 注入、跨站脚本（XSS）、Bot 攻击等，从而保护应用程序的安全性。
• 分析 WAF 规则的触发情况，了解哪些规则被频繁触发、哪些可能存在误报，进而优化和微调规则配置，提高检测的精准度和效率。
• 满足行业法规和标准（如 PCI DSS、HIPAA 等）对审计日志的合规要求，WAF 日志正是满足这一要求的重要依据。
• 在应用程序遭受攻击时，WAF 日志可提供关键的取证数据，帮助追查攻击源头、分析攻击手法，为进一步的应对措施提供依据。
• 通过监控异常流量模式（如 DDoS 攻击），采取相应措施，确保应用程序的正常运行和业务连续性。
• 将日志数据进行可视化和生成报告，直观呈现应用程序的安全状况，为管理层决策提供支持。

通常，WAF 每月需要处理和监控大量的 Web 请求，所需存储和分析的日志数据量也很大，加上日志数据可视化所需的资源会产生一定的成本。本文将为您提供三个建议，帮助您控制 WAF 日志监控和分析的成本，优化 WAF 的安全运营：

1. 将 WAF 日志通过 Amazon Data Firehose 发送至 Amazon Simple Storage Service (Amazon S3)
2. 启用 WAF 日志过滤
3. 使用亚马逊云科技 Centralized Logging with OpenSearch (CLO) 解决方案分析日志，并采用其 Light Engine 监控引擎

将 WAF 日志通过 Firehose 发送至 Amazon S3

您可以选择将 WAF 日志发送至 Amazon CloudWatch log group，或者 Amazon S3 bucket，或者 Firehose stream。它们所涉及到的成本项目分别为：

• CloudWatch logs – 2 个成本项目：Vended log delivery to CloudWatch Logs Standard 和日志存储。目前，每个月首 10TB 的 Vended log 的定价为$0.50 per GB。请访问 CloudWatch 定价页面的 Vended Logs 部分了解详情。
• Amazon S3 – 3 个成本项目：Vended log delivery to S3、S3 Standard Storage、S3 Put Object。WAF 依靠 CloudWatch，而不是直接把日志传输到 S3。目前，每个月首 10TB 的 Vended log 的定价为$0.25 per GB。请访问 CloudWatch 定价页面的 Vended Logs 部分了解详情。
• Firehose – 支持多种 Destination，如果传输日志到 S3 则涉及 3 个成本项目：Direct PUT to S3、S3 Standard Storage、S3 Put Object。目前，每个月首 500TB 的 Direct PUT 定价为$0.029 per GB。请访问 Firehose 的定价页面了解详情。

假定每个月产生 1 billion 条 WAF 日志，每条日志 1.5KB。因为日志存储和 S3 put object 的 API 费用占比很低，所以我们只计算三种方式的日志传输费用（使用本文发表日期的官方定价）来比较它们的成本。

CloudWatch logs：

• Vended Log Delivery (GB) = 1,000,000,000 * 1.5 KB / 1,024 / 1,024 = 1,430.51
• 日志传输费用 = 1,430.51 GB * $0.5 = $715.26

Amazon S3:

• Vended Log Delivery (GB) = 1,000,000,000 * 1.5 KB / 1,024 / 1,024 = 1,431.51
• 日志传输费用 = 1,430.51 GB * $0.25 = $357.63

Firehose：

• GB Billed Ingestion (单条日志不足 5KB 按照 5KB 计费) = 1,000,000,000 * 5 KB / 1,024 / 1,024 = 4768.37
• 日志传输费用 = 4768.37 GB * $0.029 = $138.28

CloudWatch Vended Log 和 Firehose 都采用阶梯式的计费方式，随着用量的增加，情况也有所变化。按照目前的价格，如果每月 WAF 记录的日志数量少于 69 Billion 条，则使用 Firehose 传输 WAF 日志是成本最低的方式。您可以按照管理 Web ACL 日志记录的指导手工完成相关的配置操作，也可以在创建 CLO 日志分析管道的时候一键完成自动部署。下文会做详细的介绍。

对于 S3 destination，Firehose stream 默认的 buffer size 和 buffer interval 分别为 5MB 和 300s。为了提高日志传输的实时性，您可以按照 Amazon Data Firehose 开发人员指南>目标设置的指导，将它们分别修改为 1MB 和 60s。利用 Firehose 零缓冲功能，我们甚至可以将 buffer interval 设置为 0s，从而为实时使用场景提供支持。但请注意，如果 buffer interval 小于 60s，Firehose 就使用 multi-part upload 向 S3 传输日志，S3 put object 的费用会相应增加。

启用 WAF 日志过滤

在未启用日志过滤的情况下，WAF 会记录所有 Web 请求的日志，包括被允许（Allow）和被默认允许（Default Allow）的请求。这会产生大量的日志数据，从而导致较高的日志传输成本。以上文每月 1 billion 个 Web 请求为例，如果全部记录日志，则每月的 Firehose 日志传输费用为 138.28 美元。

考虑到被允许的请求最终都会到达受保护的资源（如 Amazon CloudFront 或 Application Load Balancer），且这些资源也会记录相应的访问日志，因此记录所有 WAF 日志并不是必需的。通过启用 WAF 日志过滤功能，我们可以让 WAF 只记录动作为阻止（Block）、挑战（Challenge）、验证码（Captcha）的日志，以及部分动作为计数（Count）的日志。同时，利用 Centralized Logging 解决方案，我们可以在统一的视图中监控和分析那些动作为允许（Allow）或默认允许（Default Allow）的日志。

假设启用日志过滤后，WAF 记录的日志数量只有原来的 10%，那么日志传输成本就可以降低到原来的 10%，即每月只需支付 13.828 美元。下面是启用 WAF 日志过滤的具体步骤：

1. 在 WAF 控制台中，选择需要配置日志过滤的 Web ACL。
2. 在”Logging and metrics”选项卡中，点击”Logging”部分的”Edit”按钮。
3. 在”Edit logging”页面底部的”Filter logs”部分，点击”Add filter”按钮。
4. 添加过滤规则并保存配置。如果配置了多个过滤规则，WAF 从上到下按顺序执行——所以您需要将限定范围较小的过滤规则放到上面。

在下图所示的过滤规则配置示例中，我们让 WAF 为除了动作为 Allow 之外的其他 Web 请求记录日志。因为存在多个动作，多个 Condition，所以需要选择匹配条件为”Match at least one of the filter conditions”，这是一个”OR”逻辑。您应该已经注意到，截图中出现了 2 种 Count 动作：

• Count – 如果自定义规则的动作是 Count，或者整个托管规则组的动作被 Override 成 Count，则匹配过滤条件
• EXCLUDED_AS_COUNT – 如果托管规则组里面的某一条规则的动作被单独地 Override 成 Count，则匹配过滤条件

Figure 1. 为特定动作的 Web 请求记录日志

值得注意的是，”Count”是一个非终止操作，这意味着即使 Web 请求与某条规则匹配并执行了”Count”动作，WAF 仍会继续使用 Web ACL 中的其他规则对该请求进行检查。只有在所有规则都未匹配的情况下，WAF 才会执行默认动作——通常是”Default Allow”。这可能导致 WAF 记录了大量动作为”Default Allow”的 Web 请求日志，即便我们在上面的过滤规则中并未将”Allow”动作作为匹配条件。为了解决这个问题，我们需要新建一个过滤规则，匹配特定的 WAF 标签（label），并将符合条件的 Web 请求从 WAF 日志中排除。

我们假设用户为 Web ACL 配置了核心规则集（Core Rule Set）托管规则组，其中的”SizeRestrictions_BODY”规则会阻止所有 Request Body 超过 8KB 的 Web 请求。有些用户因此会选择将”SizeRestrictions_BODY”规则的动作 Override 成 Count，但并不希望为这些 Count 请求记录 WAF 日志。每一条托管规则都会为符合匹配条件的 Web 请求标记一个 Label，您可以访问开发人员指南查询所有托管规则的 Label。此外，您也可以让您的自定义规则为符合匹配条件的 Web 请求标记自定义 Label。

下图是一个基于 Label 的过滤规则配置示例。

1. 选择”Condition type”为”Request has label”。
2. 在”Condition value”文本框中搜索关键字（通常与规则名称相同，在本例中是”size”或者”body”）即可找到相应的 Label。
3. 选择”Filter behavior”为”Drop from logs”。
4. 因为这个过滤规则的限定范围比前一个过滤规则小，为了保证它能生效，点击”Move up”按钮，将它移到最上方。

Figure 2. 基于 Label 的过滤规则配置示例

最后，我们设置”Default logging behavior”为”Drop from logs”。

Figure 3. 设置 Default logging behavior

通过上述步骤，您可以有效降低 WAF 的日志传输成本，同时仍能够获取所需的安全分析数据。

使用 Centralized Logging with OpenSearch Light Engine 分析日志

Centralized Logging with OpenSearch（CLO）可帮助公司和组织集中管理来自各种来源的日志数据。该解决方案提供了一个基于 Web 的控制台，通过几次点击即可创建日志提取管道，包括日志收集、富化、缓冲和索引配置，然后自动生成用于分析不同日志格式的控制面板。结合其他亚马逊云科技服务，它为您提供了一站式的应用程序日志记录和监控环境，可以很好的替代商业版本的安全信息和事件管理（SIEM）系统。

CLO 提供两种日志监控引擎：OpenSearch 和 Light Engine。其中，Light Engine 采用轻量级设计，通过 Grafana 和 Amazon Athena 插件实现日志分析和可视化，有助于进一步降低日志监控的成本。请访问 CLO 实施指南了解成本评估的细节。

下表对比了两种引擎的主要差异：

Table 1. CLO OpenSearch 监控引擎和 Light 引擎的对比

接下来，我们将详细介绍 CLO Light Engine 的安装流程。虽然这个过程相对简单，但也有一些需要特别关注的地方。我们将一一拆解，确保您能够顺利地完成部署，享受到 Light Engine 带来的便利。

安装 CLO 基础组件

CLO 基础组件提供了一个 Web 控制台，让您可以方便地管理和监控日志数据。在部署之前，您需要先决定使用何种 Web 控制台的用户认证方式。CLO 支持两种认证方案：Amazon Cognito 用户池或 OpenID Connect（OIDC）。

选定认证方式后，您可以运行 CLO 实施指南中提供的 Amazon CloudFormation 模板，自动化部署所需的基础组件。点击模版链接，将会跳转到您的亚马逊云科技账号下的 CloudFormation 控制台，根据向导填写必要的信息即可完成安装。考虑到 CloudFront 和保护 CloudFront 分配的 Global WAF 的控制面都位于”us-east-1″区域，您需要将 CLO 也部署在”us-east-1″区域。

在”创建堆栈”向导的最后一步”Review and create”，请确保选择的模板版本至少为 v2.2.0。另外，该堆栈会创建一个 Amazon Identity and Access Management（IAM）角色，角色名称格式为 CL-<stackName>-<regionName>。由于 IAM 对角色名称长度有 64 字符的限制，所以在命名堆栈时，请保持名称长度不超过 46 个字符。

Figure 4. 确定 CloudFormation 模版的版本和堆栈名称长度

堆栈运行结束之后，在”Outputs”中找到”WebConsoleUrl”，保存它的 Value。接下来，您将通过这个 URL 访问 CLO 的 Web 控制台。

安装 Grafana

接下来，您需要安装 Grafana 来提供可视化仪表盘。我们推荐您安装 Amazon Managed Grafana。相比于自行在 Amazon Elastic Compute Cloud（Amazon EC2）实例上部署 Grafana，Managed Grafana 有以下几个主要优势：

• 无需预置和管理基础设施 – Managed Grafana 是一个全托管的数据可视化服务，您无需预置和管理任何底层基础设施，如 EC2 实例、存储等。亚马逊云科技会为您处理所有的供应、配置和扩缩容等运维工作，大大降低了运维复杂度和成本。
• 自动扩展和高可用性 – Managed Grafana 可以根据工作负载的变化自动扩展和缩减，确保始终有足够的资源。同时它提供了高可用性，您无需手动构建冗余架构。
• 与亚马逊云科技生态无缝集成 – Managed Grafana 与亚马逊云科技生态系统深度集成，可以无缝连接各种亚马逊云科技数据源，如 Athena、CloudWatch、Amazon X-Ray、Amazon IoT 等，并且可以直接从亚马逊云科技账单中查看 Grafana 的使用费用。
• 简化维护和升级 – 亚马逊云科技会自动为您的 Grafana 实例打补丁和升级，您无需手动维护和升级 Grafana 版本，减轻了运维负担。
• 增强安全性 – 如果您的数据源位于私有的 Amazon Virtual Private Cloud（Amazon VPC）内，Managed Grafana 默认启用了 Amazon PrivateLink，支持将 Grafana 与您的私有 VPC 无缝集成，增强了数据传输的安全性和隔离性。

总的来说，Managed Grafana 提供了一种无需过多运维就可获得高可用、可扩展、安全的 Grafana 服务的解决方案，让您能专注于数据可视化本身，而不是基础架构的运维。

您可以按照亚马逊托管 Grafana 入门所介绍的步骤，轻松创建一个 Managed Grafana 工作空间。考虑到 CloudFront 和保护 CloudFront 分配的 Global WAF 的控制面都位于”us-east-1″区域，您也需要在”us-east-1″区域创建工作空间。此外，我们建议您特别关注以下几个重要注意事项，以确保配置工作顺利完成：

不要配置”Outbound VPC connection”

“Outbound VPC connection”功能可以将您的 Managed Grafana 工作空间连接到同一账户和区域中的 VPC。通过这种方式，Managed Grafana 可以直接访问 VPC 内部的资源，而无需通过公共互联网发送请求，从而提高了安全性和网络性能。然而，启用此功能后，您的工作空间将无法访问公共互联网上的服务和资源。我们的需求是分析 WAF 日志，需要将 Athena 设置为数据源。但是，一旦配置了”Outbound VPC connection”，您的 Managed Grafana 工作空间将无法从 Athena 获取所需数据，也无法访问 Amazon Security Token Service（Amazon STS）获取必要的访问权限。

Figure 5. 不配置”Outbound VPC connection”

勾选”Turn plugin management on”

默认情况下，Managed Grafana v9 工作空间只预装了几个核心插件。您必须启用插件管理功能，才可以允许工作空间管理员在您的 Managed Grafana 工作空间中发现、安装、更新和卸载 Athena 插件和其他插件。您还可以根据您的需求来决定是否勾选”Turn Grafana alerting on”。利用 Grafana 基于 WAF 日志发送告警可以针对个性化的指标来发送通知，而不局限于 CloudWatch WAF metrics。你可以访问 Grafana 官方文档了解更多详情。

Figure 6. 勾选”Turn plugin management on”

在”Data sources”中勾选”Amazon Athena”

在数据源列表中，您需要选择”Amazon Athena”，这将自动为 Managed Grafana 创建一个 IAM 角色，以便它能够访问您当前账户中的 Athena 资源。请注意，此操作仅授予访问权限，并不会将 Athena 设置为数据源。我们将在后续的”Pipeline步骤”中完成数据源的配置。

Figure 7. 在”Data sources”中勾选”Amazon Athena”

完成工作空间管理员身份认证的配置

如果您选择了 IAM Identity Center 作为身份验证的方式，需要为工作空间指定 IAM User 或者 Group。如果您的组织已有 SAML 身份提供商，也可选择 SAML 登录，并完成相关配置。

为”AthenaPublicAccessRole”添加信任关系

如下图所示，进入 Managed Grafana 工作空间详情页面，记录它的 IAM role 的 ARN。

Figure 8. 记录工作空间的 IAM role 的 ARN

按照以下步骤，为”AthenaPublicAccessRole”添加信任关系：

1. 在 IAM Roles 控制台搜索”AthenaPublicAccessRole”，您会看到一个名称格式为<stackName>-AthenaPublicAccessRole-<randomId>的角色，这是在安装 CLO 基础组件的时候由 CloudFormation 堆栈自动创建的。点击角色名称，进入其详情页面。
2. 点击”Trust relationships”选项卡 → 点击”Edit trust policy” → 点击”Add a principal” → 选择”IAM Roles” → 输入 Managed Grafana 工作空间的 IAM role 的 ARN → 点击”Add principal” → 点击”Update Policy”。修改之后的信任关系如下图所示：

Figure 9. 修改之后的信任关系

为 Grafana 安装 Athena 插件

点击工作空间详情页面的”Grafana workspace URL”，用管理员账户登录进入 Grafana 控制台。在”Home > Administration > Plugins”页面搜索”Athena”，进入其详情页之后，再点击右上角蓝色的”Install”按钮为 Grafana 安装 Athena 插件。

Figure 10. 为 Grafana 安装 Athena 插件

为 Grafana 创建 Service account 并生成 token

用管理员账户登录进入 Grafana 控制台。在”Home > Administration > Service accounts”页面中新建一个 Service account，选择 Role 为”Admin”，然后再为这个 Service account 新建一个 token。保存这个 token，在接下来的”Pipeline 步骤”中，CLO 需要使用这个 token。请注意，这个 token 的默认有效期只有一天。如果需要，您可以在过期之后再创建新的 token。

手工创建一个 S3 桶：Centralized Bucket

如下图所示，CLO Light Engine 架构涉及 3 个 S3 桶：

• Log Bucket – 存储 WAF 原始日志。您应该已经在上文将 WAF 日志通过 Firehose 发送至 Amazon S3 的部分完成相关的配置。
• Staging Bucket – CLO 在创建日志分析管道的时候会自动创建 Staging Bucket，用于存储中间态的日志。您不需要关注这个 S3 桶。
• Centralized Bucket – 存储 LogProcessor 处理之后的最终的日志数据。由于多个日志分析管道可以共用一个 Centralized bucket，所以 CLO 并不会为您自动创建它。考虑到 CloudFront 和保护 CloudFront 分配的 Global WAF 的控制面都位于”us-east-1″区域，您需要在创建日志分析管道之前，在”us-east-1″区域手工创建一个私有的 S3 桶作为 Centralized Bucket。

Figure 11. CLO Light Engine 架构图

为 WAF Web ACL 创建一个 Service log pipeline

您可以按照 Centralized Logging with OpenSearch 实施指南的”AWS WAF Logs > Create log ingestion（Light Engine for log analytics）“部分所介绍的步骤，在 CLO Web 控制台上点击”Create a pipeline”按钮，轻松部署 WAF 日志分析管道。在创建管道的过程中，您需要按照配置向导的提示，使用没有过期的 Service account token 导入您之前所创建的 Managed Grafana 工作空间，在”S3 bucket for log location”下拉菜单中选择您所创建的 Centralized bucket 名称。

Figure 12. 创建日志分析管道

如果您还没有手工为 Web ACL 开启日志记录，可以在创建管道配置向导的第 1 步，点击下面截图所示的”Enable”按钮。CLO 会自动地为 Web ACL 开启日志记录，并自动地创建 WAF 日志记录所需要的 Firehose stream 和 S3 bucket。

Figure 13. 为 Web ACL 一键开启日志记录功能

在创建管道配置向导的第 2 步，您可以指定日志保存的时间，以及触发日志处理工作流的频率。CLO 默认每 5 分钟触发一次日志处理工作流，所以您可能需要 5 分钟之后才能在 Grafana 仪表盘上看到 Web 请求的数据。如果您对实时性有更高的要求，可以将这个频率修改为 1 分钟，相应地，您需要按照上文的介绍将 Firehose stream 的 buffer size 和 buffer interval 分别修改为 1MB 和 60s。

Figure 14. 修改触发日志处理工作流的频率

您需要为每一个 WAF Web ACL 分别创建一个日志分析管道。在管道配置向导的第 2 步，”Log table name”默认为 waf_<webAclName>。如果您希望在同一个仪表盘中可视化多个 Web ACL 的日志，为它们指定相同的”Log table name”。

为受 WAF 保护的资源（CloudFront 分配、ALB）创建 Service log pipeline

您可以分别按照 Centralized Logging with OpenSearch 实施指南 Amazon CloudFront Logs 部分和 Application Load Balancing（ALB）Logs 部分所介绍的步骤，为受 WAF 保护的资源创建日志分析管道，以实现在统一的 Grafana 视图中监控和分析那些动作为允许（Allow）或默认允许（Default Allow）的日志。

使用 Centralized Logging with OpenSearch Light Engine 仪表盘

Well done! 现在您可以使用 CLO 的仪表盘统一可视化监控 WAF 日志和受保护资源的日志了。由于篇幅限制，本文不再多做介绍，您可以在这个页面的最底部查看 CLO Light Engine 仪表盘的样例，我们将在以后的博客文章中分享具体的使用经验。

总结

本文从三个层面详细阐述了降低 Amazon WAF 日志监控成本的最佳实践。首先，利用 Firehose 将 WAF 日志高效传输至 S3，实现日志集中存储。其次，启用 WAF 日志过滤功能，有效降低 WAF 日志传输成本并提高分析效率。最后，借助 Centralized Logging with OpenSearch 解决方案及其 Light Engine 可视化监控引擎，您可以全面分析 WAF 日志，深入洞察 Web 流量情况，优化 Web 应用程序的安全性和性能。通过采纳这些最佳实践，您将在保证日志数据完整性的同时，显著降低 WAF 日志监控的总体成本。

本篇作者