0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@80-cloud

CloudTrailのEvent Historyで、DynamoDBの読み書きとS3のアップロードだけが1件も見つからなかった話

0
Posted at

先に結論：CloudTrailのEvent historyは管理イベント(コントロールプレーン操作)しか記録しない仕様で、DynamoDBのPutItem/QueryやS3のPutObjectのようなデータイベント(データプレーン操作)は標準では表示対象外でした。見えなかったのは設定ミスではなく仕様です。

環境

  • AWSアカウント(個人の学習用アカウント)
  • リージョン: アジアパシフィック(東京)ap-northeast-1
  • AWS CLI 2.34.44
  • 2026年7月時点
  • CloudTrailはデフォルトで有効な状態(専用のTrailは未作成)

起きたこと

やったことは大きく2つです。

1. DynamoDBの操作

AWS公式のGetting Startedに沿って、パーティションキー Artist・ソートキー SongTitle を持つ Music テーブルを作成し、項目を3件登録、Artist を指定してクエリを実行しました。

2. S3の操作

汎用バケットを1つ作成し、ファイルを1つアップロード、ダウンロード、フォルダへのコピーを行いました。

その後、CloudTrailのイベント履歴を開いて、イベントソースを dynamodb.amazonaws.com で絞り込みました。

CreateTable       ← ある
DescribeTable     ← ある(何度も)
ListTables        ← ある
DeleteTable       ← ある
PutItem           ← ない
Query             ← ない

同様にイベントソースを s3.amazonaws.com に変えると、

CreateBucket                              ← ある
GetBucketVersioning / GetBucketEncryption ← ある
PutObject(アップロード)                    ← ない
GetObject(ダウンロード)                    ← ない
CopyObject(フォルダへのコピー)              ← ない

「項目を3件も入れたのに、なぜ1件も出てこないんだろう」というのが最初の疑問でした。

切り分け

まず疑ったのはフィルタの入力ミスでした。イベント名の欄に直接 PutItem と入れて検索しても、結果はやはり0件です。次にAWS CLIでも同じ条件を叩いてみました。

aws cloudtrail lookup-events \
  --region ap-northeast-1 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateTable \
  --max-items 3 \
  --query 'Events[].{Time:EventTime,User:Username,Name:EventName}' \
  --output json

[
    {
        "Time": "2026-07-30T11:22:33+09:00",
        "User": "my-iam-user",
        "Name": "CreateTable"
    },
    {
        "Time": "2026-06-19T21:55:33+09:00",
        "User": "my-iam-user",
        "Name": "CreateTable"
    },
    {
        "Time": "2026-06-18T20:55:53+09:00",
        "User": "my-iam-user",
        "Name": "CreateTable"
    }
]

※ Time はAWS CLIが実行環境のローカルタイムゾーンで自動表示したもので、手動で変換したものではありません(生のイベントレコード内の eventTime はUTC表記です)。

CreateTable はちゃんと返ってきます。ところが同じコマンドの AttributeValue を PutItem や Query、S3の PutObject に変えると、いずれも [] でした。

コンソールと lookup-events の両方で同じ結果になりました。ただし lookup-events もEvent historyと同様に、基本的には管理イベントを検索するコマンドです。そのため、この確認だけではデータイベントの記録有無までは判定できません。今回はデータイベントを有効にしたTrailやイベントデータストアを作成していなかったため、PutItem や PutObject はそもそも保存対象になっていませんでした。

「出てきたイベント」と「出てこなかったイベント」を並べてみると、ある共通点に気づきました。

出てきたイベント 出てこなかったイベント
CreateTable / DeleteTable PutItem / Query
CreateBucket PutObject / GetObject / CopyObject
ConsoleLogin -

今回確認したDynamoDBとS3では、「箱そのものを管理する操作」と「箱の中のデータを読み書きする操作」に分けると理解しやすい結果になりました(すべてのAWSサービスで同じように分類できるとは限らないので、あくまで今回の理解のための例えです)。

原因

CloudTrailには「管理イベント」と「データイベント」という2種類のイベント分類があり、それぞれコントロールプレーン操作とデータプレーン操作に対応しています。

Management events provide visibility into management operations that are performed on resources in your AWS account. These are also known as control plane operations.

Data events provide information about the resource operations performed on or in a resource. These are also known as data plane operations.

そして、Event historyが対象にしているのは前者だけだと明記されています。

The Event history page on the CloudTrail console only shows management events. It does not show data events, Insights events, or network activity events.

DynamoDBのPutItem/GetItem/UpdateItemも、公式ドキュメントで明確にデータイベントとして扱われています。

Amazon DynamoDB item-level API activity on tables (for example, PutItem, DeleteItem, and UpdateItem API operations).

気をつける点

  • データイベントを記録するには、CloudTrail Trail を作成し、データイベントの収集を有効にします。CloudTrail Lakeを既に利用しているアカウントでは、イベントデータストアを使う方法もありますが、CloudTrail Lakeは2026年5月31日から新規顧客への提供を終了しています(通常のTrailは引き続き利用できます)。
  • Trailでデータイベントを有効にしても、Event historyに表示されるようになるわけではありません。Event historyはTrailやイベントデータストアとは独立しており、引き続き管理イベントだけを表示します。Trailで収集したデータイベントは、配信先のS3ログなどで確認します。
  • 対象リソースの絞り込みは、特定の1バケット・1テーブルだけでなく、リソースタイプ・ARN・読み取り/書き込み・イベント名など、いくつかの軸で設定できます。
  • Event historyの「Read only」フィルタは、Event historyに含まれている管理イベントを読み取り/書き込みに絞り込むものであり、管理イベント/データイベントを切り替えるフィルタではありません(readOnly自体はデータイベント側のセレクターにも使える属性ですが、Event history画面内では管理イベントの範囲でしか機能しません)。
  • Event historyは過去90日間のみが対象という制限もあります。

学び

  • CloudTrailの「操作履歴には何でも映る」というイメージは正確ではなかった。リソースの作成・削除・設定変更(管理イベント)は標準で見えるが、データの読み書き(データイベント)は見えない、という前提を持っておく必要がある
  • 「出てくるイベント」と「出てこないイベント」を並べて共通点を探すと、原因の見当がつけやすい
  • コンソールで0件だったとき、AWS CLIで同じ条件を叩いて突き合わせると早く切り分けられる。ただし同じ仕組み(Event history)を裏で使っているツール同士を比較しても、「別の保存先にも記録がない」ことまでは証明できない点には注意が必要
  • データイベントは件数が多くなりやすいため、標準で全件を収集するのではなく、必要な対象を利用者が選んで有効化する設計には納得感があった

おわりに

「監査ログなんだから全部映るだろう」という思い込みが一番の落とし穴でした。管理イベントとデータイベントという区別を知っているかどうかで、CloudTrailの見え方がまったく変わってきます。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?