CloudTrail — 「誰が何をしたか」を絶対に逃さない

CloudTrail — 誰が何をしたか、見逃さない

今日はCloudTrailという、AWSでめちゃくちゃ大事なサービスについて、一緒に学んでいきます。

前回まではIAMとKMS、つまり権限管理と暗号化についてやってきました。今日は監査とロギングです。これ、セキュリティの最後の砦なんですよ。

実は、このサービスについて一番よくある誤解があります。知ってますか。「CloudTrailを有効にしたから、これで全てのAPI操作が記録されるようになった」と。

これ、半分正解で、半分間違いなんです。なぜだと思いますか。実は、AWSアカウントを作った瞬間から、CloudTrailは黙ってあなたのAPI操作を記録してるんですよ。有効化してなくても。ただし、保持期間が90日間だけ。つまり、3ヶ月経ったらポイ。消えます。これが問題なんです。

今日は、その仕組み、そしてどうやって「永遠に保存」「改ざん防止」「高速検索」まで実現するか、その全部を学びます。

防犯カメラシステムとしてのCloudTrail

想像してみてください。銀行があるとして、セキュリティカメラって何個ありますか。複数の層ですよね。

入口に来た人は誰か。顔、時刻。金庫室に誰が入ったか。金庫室の中で何かが盗まれたか。異常な行動パターン。深夜3時に誰かが侵入。CloudTrailも全く同じです。

実は CloudTrail には3種類のカメラがあります。管理イベント、データイベント、Insights。それぞれが違う視点から「何が起きたか」を記録しています。

管理イベント — 入口の防犯カメラ

「管理イベント」とは何か。簡単に言うと、AWS の「設定」が変わった時のログです。

具体例を出すと、IAM ユーザーを作った。記録。EC2 インスタンスを起動した。記録。S3 バケットのポリシーを変更した。記録。RDS のセキュリティグループを変更した。記録。ルート認証情報で MFA 有効化した。記録。

つまり「リソースの設定が変わった瞬間」です。これは、CloudTrail を有効化した瞬間から、デフォルトで記録される。追加設定なし。ただし、CloudTrail コンソールには 90 日間だけ保持される。

ここが重要な落とし穴。「AWS アカウント作ったときから、CloudTrail は自動で API 操作を記録してる」。つまり、有効化してなくても、過去 90 日のイベント履歴は見られる。でも 91 日目からは消えます。永遠に。7 年間のコンプライアンス監査が必要な場合、90 日だけでは足りない。だから S3 配信が必須になるわけです。

データイベント — 金庫室のカメラ

「管理イベント」だけだと、何が足りないか。「S3のバケットに誰がアクセスしたか」「誰がLambda関数を実行したか」「DynamoDBのテーブルで誰が読み書きしたか」。こういう日々のデータ操作は分かりません。

これが「データイベント」です。具体例は、S3から10GBのファイルをダウンロードした。記録。Lambdaを1000回実行した。記録。DynamoDBで大量のスキャンが走った。記録。

ここで気をつけないといけないポイントは、データイベントはデフォルトOFF。自分で有効化しないと記録されません。なぜって。料金がかかるから。管理イベントは最初の10万件毎月は無料。データイベントは10万件で約1000円かかります。本番環境で「全S3バケット、全Lambda、全DynamoDB」をログしたら、月のログ代だけで数万円から数十万円ですよ。

だから、「特定のバケット」「特定のテーブル」って限定する必要があります。戦略的に、ね。

CloudTrail Insights — 異常行動検知AI

さて、ここが面白い。管理イベントもデータイベントも記録できたとしましょう。でも、膨大なログの中から「異常」を見つけるのって、大変じゃないですか。

CloudTrailは、自分で異常を見つけてくれる機能があります。それが「Insights」、インサイツですね。

どういう異常か。例えば、通常は1時間に1回しかS3から読み取らないユーザーが、突然1分間に1000回読み取り始めた。月5回のIAMロール変更が、5分で50回に。深夜3時に「管理者権限の付与」が大量に実行された。

「え、これ普通じゃないな」って、AIが自動で検知する。これは追加料金がかかりません。Insights Eventsって呼ばれて、CloudTrail自体の料金に含まれてます。

時間軸の問題：90日の呪い

ここからが、SCS-C03試験で絶対に押さえておかないといけない部分です。

AWSアカウントを作った瞬間から、CloudTrailは勝手にあなたのAPI操作を記録してます。だから、有効化してなくても「過去90日間のログは見られる」。

でも、91日目からは消えます。永遠に。

セキュリティ規制で「過去7年間のログを保持しないといけません」とか「過去3年間のコンプライアンス監査をしないといけません」とか言われたら、どうします。

S3にCloudTrailのログを配信する必要があります。そしたら「S3の保持期間」で管理できる。30日で消す、90日で消す、7年保つ。自分で決められます。

ここで大事なのは、CloudTrailのコンソールから見える90日分と、S3に保存された永続記録は別モノということ。混同する人が多い。試験でもひっかかる人多いです。

証跡設計：マルチリージョン、マルチアカウント

さて、組織全体を守るとしましょう。100アカウントあるとして、全部のCloudTrailログを1ヶ所に集めたいですよね。

マルチリージョン証跡

ひとつのアカウント内で複数リージョンを使ってるなら、マルチリージョン証跡を作ります。このリージョン、あのリージョン、全部を一つの S3バケット に配信。これ、チェックボックス1個で実現できます。便利ですね。

組織証跡（Organizations Trail）

これがすごい。複数アカウントがあるなら、Organizations Trail を親アカウントで作ると、子アカウント全部のログが自動で集まります。

例えば、親アカウントで Organizations Trail を作成する。そしたら、子アカウント A のログが勝手に親のバケットに流れ込む。子アカウント B のログも。子アカウント C のログも。自動です。

でも注意。子アカウント側で「CloudTrailを無効化する」ことはできません。親の指示に従う。これ、セキュリティ上の強力さですが、理解してないと「あれ、なんでCloudTrail作ったのに動かないんだ」ってなります。

整合性検証：ダイジェストファイルの魔法

今から、すごく大事な話をします。CloudTrail が S3 に配信したログファイルが、改ざんされてないことを証明する方法があるんです。

どうやって。ダイジェストファイル。簡単に言うと、CloudTrail ログファイル A をハッシュ値計算、つまり SHA256 で計算して、ダイジェストファイルに署名付きで保存。後で検証。つまり「このハッシュ値と今のログのハッシュ値が一致してたら、改ざんされてない証拠」って論理です。

さらにチェーンのような仕組みがあります。時刻 1：ログ A のハッシュ値を計算。Digest1(A)。時刻 2：ログ B とひとつ前の Digest1 を組み合わせてハッシュ計算。Digest2(B + Digest1)。時刻 3：ログ C と Digest2 を組み合わせてハッシュ計算。Digest3(C + Digest2)。こうやってチェーンが続く。もし途中で ログ A が改ざんされたら、Digest1 のハッシュ値が変わり、連鎖的に Digest2、Digest3 も変わる。改ざんを検知できます。

なぜこれが大事か。規制審査で「このログが改ざんされてない証拠を出してください」って言われる。ダイジェストファイルがあれば、技術的に証明できる。「ハッシュチェーンが一致しています。改ざんされていません」と。

S3 に配信する時に「Enable log file validation」って設定があります。ここにチェックを入れるだけで、自動でダイジェストファイルが生成される。簡単です。AWS が毎時間のように「このハッシュ値です」と署名付きで保存。後で検証者が「本当にこのハッシュですか」と確認できます。

S3配信の防盗性

ここも重要。CloudTrail が S3 にログを配信しますね。でも、そのバケットが、誰かに改ざんされたら。防ぐ方法が 3 つあります。

1. S3バケットポリシー

CloudTrail が書き込みできるアカウント・リージョン・サービスを限定する。例えば、CloudTrail サービス自体だけが書き込める。特定のアカウントからのアクセスだけ許可。特定のリージョンからだけ。具体的には「Principal」に CloudTrail サービスのみを指定し、「Action」を「s3:PutObject」「s3:GetBucketAcl」に限定。これで、不正なアクセスキーが漏洩しても、攻撃者はこのバケットに書き込めません。

2. 暗号化

S3 に配信されるログを、KMS 暗号化する。設定画面で「Use KMS encryption」選ぶだけ。そしたら、たとえ誰かがバケットに侵入して「ログファイルを盗もう」としても、復号化キーがなければ読めない。KMS キーの権限を厳しく制御。「ログの読み取りは、セキュリティ監査者のみ」とか。

3. MFA Delete

これがすごい。S3 オブジェクトを削除するのに、MFA、つまり多要素認証が必須にできるんです。つまり、普通に誰かが侵入してバケットアクセス権を奪ったとしても、MFA Delete が有効だと「スマホの確認コード」がないと削除できない。攻撃者「ログファイル全部削除して証拠隠滅だ」。しても、MFA コード入力しないと削除完了しない。物理的に防ぐ仕組みを入れてます。オフライン攻撃では突破不可。

高速検索：Athena連携

さあ、ここからが実務的な話です。CloudTrail のログって、すごい量ですよね。毎日何 GB、何 TB。そのログの中から「2026 年 4 月 27 日午後 3 時にセキュリティグループを変更した奴は誰だ」って探すの、どうやります。

S3 から全ファイル取ってくる。遅い。AWS Management Console で手でフィルタリング。ムリ。答えは Athena。簡単に言うと「S3 に積まれた大量のログに対して、SQL で検索かける」サービスです。

SELECT userIdentity.principalId, eventName, sourceIPAddress
FROM cloudtrail_logs
WHERE eventName = 'ModifySecurityGroupIngress'
AND eventTime > '2026-04-27T15:00:00'

こんな SQL を実行したら、数秒で結果が出てきます。なぜこれが大事か。セキュリティインシデントが起きた時、「この時刻にこのアカウントで何が起きてたのか」を素早く把握できるから。「あ、15:03 に alice というユーザーが SecurityGroupIngress ルール追加した」。あ、その時刻に EC2 のセキュリティ設定が変わったんだ、と分かる。犯人追跡できる。

実務シナリオ。金融機関の規制監査。「過去 2 年間、IAM ユーザーへの権限追加を全部出してください」。Athena に「SELECT * FROM cloudtrail_logs WHERE eventName LIKE ‘AttachUserPolicy’ AND eventTime >= ‘2024-04-27’ AND eventTime <= ‘2026-04-27’」。数秒で結果。Excel に落とし込んで監査官に提出。

Athena がないと、ログファイルを手でダウンロードして、grep でフィルタリングして、みたいなことになる。数時間かかる。

試験では「CloudTrail のログを調査する」ってシナリオが出ます。そん時は「Athena で検索する」が正解。

リアルタイム検知：EventBridge連携

さて、これが一番イケてる連携です。CloudTrail がイベントを記録する と同時に、EventBridge に流し込む設定ができます。EventBridge で何ができるか。ルール作成です。例えば、「root ユーザーで API 呼び出しがあったら」、「SNS で通知」「Lambda 起動」「Slack 通知」。「セキュリティグループが変更されたら」、「ログを DynamoDB に保存」「Slack alert」。

実務シナリオ。IAM ユーザーの AccessKey が盗まれて、リスト内の全 S3 バケットから データ流出してる。深夜 2 時。人間は寝てる。でも EventBridge ルール「GetObject API 大量呼び出し」がトリガーする。Lambda 関数「該当アクセスキーを無効化」。実行。被害拡大を数分で止める。人間が朝 6 時に気づいたときには、既に自動対応完了してる。損失最小化。

つまり、「CloudTrail が何かを検知した瞬間に、リアルタイムで動く」アクションを仕込めるんです。これ、手作業でログを確認するのと違って「秒単位で反応できる」。人間が寝てる深夜 3 時に不正アクセスがあっても、Lambda が自動で対応開始する。これが EventBridge 連携の力です。

ただし、EventBridge のイベント配信はリアルタイムじゃなく数秒遅延があります。でもインシデント対応では「数秒」は充分に価値。

よくある誤解と落とし穴

試験の直前に、ぜひこれを頭に入れてください。

誤解1：「CloudTrailは有効化しなくても動いてる」

半分正しい。AWS アカウント作成時から、CloudTrailは API操作を CloudTrail Event history に記録してます。でも、これは 90日間だけ。S3配信もされてない。

S3配信は、証跡を明示的に作らないと始まらない。試験問題。「CloudTrailを有効化してないアカウントで、過去180日前のAPIログを確認したい」。不可能。90日を過ぎたら、その時点でCloudTrailを有効化しても遅い。

誤解1-補足：「EventHistory で調査できるから S3 配信は不要」

本当に引っかかる誤り。CloudTrail Event History はコンソール上で 90 日間見られます。「あ、これだけあれば充分」と思う。でも、規制監査で「過去 2 年間のログを出してください」と言われたら、90 日以前は「存在しません」と答えるしかない。

S3 配信を開始した時点から、ログは永続保存。でも開始前のログは消えてる。だから「今すぐ S3 配信を有効化」が鉄則。翌年「過去 1 年のログが欲しい」と言われても、「あ、1 年前から S3 配信を有効化してます。あります」と答えられます。

実務では「S3 配信、いつから有効化した？」という質問が監査で出ます。「3 年前から」と答えられれば、3 年分のログがある。「去年から」なら「去年以前は保有してません」。証拠がなければ、規制対応失敗。

誤解2：「データイベント有効化は無料」

全然違う。金がかかる。「全 S3 バケット、全 Lambda」でデータイベント有効化して、本番環境で走らせたら、ログ代だけで月数万円。最悪、それに気づかずに放置して請求額がえらいことに。

本番環境のデータイベントは、「本当に必要なリソース」だけに限定しましょう。例えば「Production S3 バケットだけ」「金融系 DynamoDB テーブルだけ」。限定しないと cost explosion です。

実務での失敗ケース。「セキュリティ強化で、全 S3 にデータイベント有効化」。そしたら月 15 万円の追加請求。「え、何だこれ」。CloudTrail コンソールで確認。あ、Log Files 数が数千個。毎日数 GB。あ、金かかるんだ、となって慌てて「本当に必要なバケットだけ」に絞る。もう遅い。請求額は返ってこない。試験でも出ます。「本番環境で大量データイベント有効化したら費用爆増。対策は」。答え「対象を限定。ReadOnly だけに限定」。

誤解3：「ダイジェストファイルをONにしたから改ざん防止完璧」

それだけではダメ。ダイジェストファイル自体が改ざんされたら。S3のアクセス権限が甘かったら。ダイジェストファイル + バケットポリシー + KMS暗号化 + MFA Delete まで揃えて、初めて「改ざん防止完璧」です。

誤解4：「CloudTrail Insightsで全ての異常が検知される」

そんなわけない。CloudTrail Insightsは「統計的に異常な API パターン」を検知します。でも、例えば「慎重に、毎日1個ずつ権限を盗む」みたいなスローな攻撃には引っかかりません。

Insightsは「助け」に過ぎない。人間の監視が必須。

試験対策：まとめ

では、SCS-C03 試験で CloudTrail が出た時、何を見るか。

1 番目、イベントタイプ。管理イベントはリソース設定変更、デフォルト ON、90 日保持。データイベントはリソース操作、デフォルト OFF、追加料金。Insights は異常行動検知、自動、追加料金なし。

2 番目、保持と配信。CloudTrail コンソール上の Event History は 90 日のみ。S3 配信は手動設定で永続保存可能。マルチリージョン、Organizations Trail で集約。

3 番目、セキュリティ。ダイジェストファイル + バケットポリシー + 暗号化 + MFA Delete。EventBridge 連携でリアルタイム検知。Athena 連携で高速検索。この 3 つが柱です。

実装パターンを覚えておいてください。本番環境なら：マルチリージョン証跡を作成→S3 配信→ダイジェスト検証有効化→CloudWatch Logs にも配信→EventBridge ルール作成→Athena テーブル作成。これで「過去 7 年間の完全な監査ログ。改ざん検知可能。リアルタイム検知。高速検索」が実現します。

試験での頻出問題パターン。「CloudTrail を有効化したけど、90 日以前のログが見たい」。不可能。有効化後のみ記録。過去ログが必要なら「その時点で S3 配信を有効にして、今後は保存」しかない。「Data イベント有効化したら月額請求が跳ね上がった」。全リソース対象にしたから。本番環境では対象を限定。「ダイジェスト検証してたのに、改ざん検知されなかった」。ダイジェストファイル自体が改ざんされた。バケットポリシー + KMS + MFA Delete も一緒に。多層防御。

CloudWatch Logs フィルター連携

CloudTrail のログを CloudWatch Logs に流し込むと、リアルタイムアラートが可能になります。

メトリクスフィルター「Root ユーザー使用」を作成。CloudTrail ログの「userIdentity.type = ‘Root’」を検知。メトリクス増加。CloudWatch Alarm トリガー。SNS 通知飛ぶ。「Root ユーザーが API 操作しました」。人間が即座に「何が起きた？」と調査開始。

セキュリティグループ削除。「eventName = ‘DeleteSecurityGroup’」を検知。メトリクス増加。「セキュリティグループが削除されました」。通知。調査。

IAM ポリシー付与。「eventName = ‘PutUserPolicy’ OR eventName = ‘AttachUserPolicy’」。権限昇格の兆候。即座に通知。

これらを組み合わせると、「疑わしい操作が検知されたら、数秒以内に通知」という体制が作れます。手作業でログを見ている場合ではない。

設定のコツ。フィルターパターンを絞り込む。「全イベント通知」にすると、ノイズが増えて「アラート疲れ」になる。「本当に疑わしい操作」だけに絞る。

Organizations Trail と複数アカウント集約

実は、大企業では複数アカウント構成が普通です。開発アカウント 10 個、ステージング 10 個、本番 20 個。全部の CloudTrail ログを一箇所に集めたい。手動で 50 個の証跡作ってたら、管理地獄ですね。

答えが Organizations Trail。親アカウント（管理アカウント）で Organizations Trail を作る。そしたら、全子アカウントのログが自動で集まります。新規アカウント追加されても、自動で対象。委任管理者を指定することで、セキュリティチームが一箇所で全社ログを監視。

具体例。50 個の子アカウント。各アカウント月に数GB のログ。合計 150GB の CloudTrail ログ。Organizations Trail 作成。親アカウントの S3 バケット 1 個に全部集約。Athena テーブル 1 個。全社ログをワンテーブルで分析。コストも効率化。

ただし注意点。子アカウント側で CloudTrail を無効化することはできません。親の指示に従う。これはセキュリティ強化になりますが、理解してないと「あ、CloudTrail 作ったのに動かない。なぜ」ってなります。試験では「複数アカウント環境で CloudTrail を一元管理するには」という問題が出ます。答え「Organizations Trail を設定。委任管理者を指定」。これだけで OK。

設定の流れ：親アカウント側で Organizations Trail 作成→委任管理者アカウントを指定→S3 バケット作成（全アカウントが書き込み可能に）→CloudWatch Logs も設定→Athena テーブル作成。これで自動集約完成。

実務での使用例：不正アクセス調査シナリオ

具体的なシナリオを一つ。2026 年 4 月 27 日午後 3 時、Lambda 関数が大量に実行。デフォルト実行回数は月 10 回なのに、1 時間で 1000 回。異常です。CloudTrail Insights「API CallRateInsight」が検知。Finding 出力。

早速 Athena で調査。「2026-04-27T15:00:00 から T16:00:00 の間、InvokeFunction API を実行したのは誰」。

SQL：「SELECT userIdentity.principalId, eventCount FROM cloudtrail_logs WHERE eventName = ‘InvokeFunction’ AND eventTime BETWEEN ‘2026-04-27T15:00:00Z’ AND ‘2026-04-27T16:00:00Z’」

結果：「AIDAI123456（IAM ユーザー alice）が 1000 回実行」。あ、alice のアクセスキーが盗まれたか。

次のクエリ。「alice のアクセスキー、いつから何をしてた」。結果が出たら、タイムライン作成。「14:50 初回不正アクセス」「15:00 Lambda 大量実行開始」「15:30 S3 GetObject 大量実行」。あ、データ流出してるな。

すぐに alice のアクセスキーを無効化。Lambda 実行ロール修正。S3 バケットアクセス確認。CloudTrail がなかったら「何が起きた？」が分かりません。被害も把握できない。完全に暗闇。

最後に

CloudTrail って、一見「単なるログ記録」に見えるじゃないですか。でも、実は、セキュリティ監査、コンプライアンス対応、インシデント対応、全部の基盤になる。

これがないと、もし何か起きた時「誰が何をしたのか、全く分かりません」ってなってしまいます。本番環境では、絶対に CloudTrail を有効化して、S3 に配信してください。そして、ダイジェストファイルを ON にして。それをやってれば、もし何か起きた時「原因究明が早い」。これがプロの環境です。

7 年間のコンプライアンス保持、改ざん防止、リアルタイム検知。全部実現可能。お金もそんなにかかりません。むしろ、かけなかったときのインシデント対応費用のほうが莫大。CloudTrail なしに本番環境は語れません。では、この講義をまとめます。