基于 CloudTrail 数据构建表

在告诉 Athena 如何读取原始 S3 文件之前，Athena 无法查询这些文件。表会将 S3 存储桶中的 CloudTrail JSON 文件映射到具有名称和类型的列。表创建后，CloudTrail 事件的丰富结构就可以通过普通 SQL 进行访问。

CloudTrail 以 JSON 格式传送事件，每条记录描述一次 API 调用，并包含 userIdentity、eventName、sourceIPAddress 和 requestParameters 等嵌套字段。表架构必须镜像这种嵌套结构，包括用于表示对象的 struct 类型，这样查询才能访问 userIdentity.arn 等字段。

您不必手动编写架构。AWS 会发布适用于 CloudTrail 的标准 CREATE TABLE 语句，CloudTrail 控制台和 Athena 也可以为您生成该语句。使用 AWS 提供的 DDL 可以确保每个字段（包括深层嵌套字段）都得到正确映射，从而避免查询遗漏数据。

SerDe（序列化器/反序列化器）用于告诉 Athena 如何解析每个文件。CloudTrail 表使用专为 CloudTrail JSON 布局设计的 SerDe，它能够识别 records 数组和嵌套结构。选择正确的 SerDe 至关重要；错误的 SerDe 会导致解析错误或列值为 null。

表的 LOCATION 子句指向 CloudTrail 存储日志的 S3 前缀，通常是包含账户 ID 和区域的路径。正确设置此前缀非常重要：范围过大会扫描无关数据，范围过小则会漏掉您想要查询的事件。

创建表后，您可以使用点表示法查询嵌套字段，例如 userIdentity.arn 或 requestParameters.bucketName。SQL 函数可以帮助展开数组和 JSON 字符串。这正是 Athena 在调查中发挥优势的地方：您可以精确地按照任意 API 调用的事件名称、主体和参数进行筛选。

无需手动编写 DDL，AWS Glue 爬虫可以扫描 S3 数据，并自动推断架构写入数据目录。对于 CloudTrail 这类已知格式，所提供的 DDL 通常更加简洁；但如果日志格式是自定义的或不断变化的，而您又不想手动编写架构，爬虫会很有帮助。

CloudTrail JSON 中有些字段本身就是 JSON 字符串，例如值会因服务而异的 requestParameters。您通常会在查询时使用 JSON 函数解析这些字段。了解某些列是需要解析的字符串，而不是预先构建好的列，可以避免在字段表现得不像普通列时产生困惑。

对于组织跟踪，所有账户的日志都会存放在同一个存储桶下，并按账户使用不同的前缀。您可以针对整个前缀创建一个表，一次查询所有账户；也可以为每个账户创建独立的表以实现隔离。统一表非常适合通过一次查询在整个组织范围内进行威胁搜寻。

创建表后，使用较小的 LIMIT 运行一个快速的 SELECT，确认能够返回行，并且列能按预期填充。如果列值为 null，通常说明 SerDe、位置或架构设置有误。这个合理性检查可以避免您在一张悄悄失效的表上开展调查。

CloudTrail 表确认无误后，您就拥有了一条涵盖所有已记录历史、可供查询的审计轨迹。每次控制台登录、API 调用和错误现在都是一行数据，您可以对其进行筛选和聚合。这张表是您接下来要编写的事件查询的基础。

测试您构建表的知识。

要在 Athena 中查询 CloudTrail，您需要创建一个表，将 JSON 文件映射到各列，并使用 AWS 提供的 CREATE TABLE DDL、正确的 SerDe 和正确的 S3 LOCATION。使用点表示法查询嵌套字段，在查询时解析 JSON 字符串列，并通过较小的 SELECT 进行验证。组织跟踪可以使用一张表来进行整个组织范围的威胁搜寻。