AWS / SAP-C02

セクション 02 · タスク 1.2 · SAP-C02-019

CloudTrailによる監査設計

AWS CloudTrail / 管理イベント / データイベント / 組織の証跡 / ログの完全性 / 集中ログ記録

このページのゴール

監査要件から、CloudTrailで記録すべき管理イベント / データイベントを選び、AWS Organizations全体の証跡を中央保管し、ログ改ざん検知まで含めた監査アーキテクチャを設計できることをゴールにします。

1. 監査では「後から何を説明できる必要があるか」を決める

例えばセキュリティグループが変更され、外部公開されていたとします。必要なのは、現在の設定だけではありません。

誰が?

いつ?

どのアカウントで?

どのリージョンで?

どのAPIを?

どのリソースへ?

どこから実行した?

こうしたアカウントアクティビティの証跡を記録する中心サービスがAWS CloudTrailです。CloudTrailはIAM アイデンティティ、AWSサービス、コンソール、CLI、SDK/APIなどによるアカウントアクティビティをイベントとして記録します。

2. CloudTrailは「現在状態」ではなく「操作履歴」を記録する

例えばセキュリティグループの現在設定だけでは、誰が・いつ・どのAPIで変更したかは分かりません。CloudTrailでは操作そのものをイベントとして追跡します。

プリンシパル
    │
    │ AuthorizeSecurityGroupIngress
    ▼
AWS API
    │
    ▼
CloudTrail イベント

したがって、設定の現在状態と設定を変更した操作履歴は別の情報として扱います。

3. 最初に管理イベントとデータイベントを分ける

SAP-C02で特に重要なのは、管理イベントとデータイベントの違いです。

イベント主に記録するもの
管理イベントAWSリソース / アカウントの管理操作
データイベントリソース内のデータに対する操作

現在 CloudTrailには管理イベント、データイベント、ネットワークアクティビティイベント、Insights イベントがあります。セキュリティアーキテクチャではまず、制御プレーンを記録する管理イベントとリソース上の操作を記録するデータイベントを正しく使い分けます。

4. 管理イベントは制御プレーン操作

管理イベントは、AWSリソースやアカウントを管理する操作を記録します。

IAM ポリシーをアタッチ

サブネットを作成

セキュリティグループを変更

CloudTrail 証跡を作成

コンソールへログイン

代表例には iam:AttachRolePolicy、ec2:CreateSubnet、cloudtrail:CreateTrail、ConsoleLogin などがあります。AWSでは管理イベントを制御プレーン運用とも呼びます。

5. 管理イベントは監査の基本

「誰が本番セキュリティグループを変更したか」を追跡したいなら、セキュリティグループ設定変更は管理運用なので管理イベントを確認します。

セキュリティグループ設定変更
↓
管理 運用
↓
管理イベント

IAMロール作成、KMS キーポリシー変更、VPC作成、ルート変更なども、リソースやアカウントを管理する操作として監査します。

6. データイベントはリソース内の操作

データイベントはリソース自体を作る・変更する操作ではなく、そのリソース上またはリソース内で実行された操作を記録します。

S3 バケットを作成
→ 管理イベント

オブジェクトを取得
→ データイベント

オブジェクトを保存
→ データイベント

オブジェクトを削除
→ データイベント

S3 オブジェクト-レベル APIアクティビティなどがデータイベントに該当します。

7. 「S3を監査したい」だけではイベントタイプは決まらない

誰がS3 バケットポリシーを変更した?
↓
管理イベント

誰が機密オブジェクトを読み取った?
↓
データイベント

サービス名でイベントタイプを決めるのではなく、何の操作を監査したいかで判断します。

8. データイベントはデフォルトでは記録されない

証跡では管理イベントを記録するのが基本ですが、データイベントはデフォルトでは記録されません。データイベントは高ボリュームになり得るためです。

S3オブジェクト取得
× 数百万リクエスト
↓
監査データ量も増加

したがって、データイベントを機械的にすべて有効化するのではなく、監査対象リソース・必要運用・ボリューム / コストを考えます。

9. データイベントは必要な範囲を選択する

例えばパブリックイメージバケットより財務レコードバケットのオブジェクトアクセスを重点監査したい場合、機密バケットのS3 オブジェクトデータイベントを記録します。

CloudTrailの高度なイベントセレクターでは、リソースタイプや条件を使って記録対象を絞れます。SAP-C02ではセレクター構文より、高ボリュームなデータイベントを必要な監査範囲へ限定するという判断を押さえます。

10. 管理イベントとデータイベントを比較する

要件イベント
誰がIAM ポリシーを変更した?管理
誰がセキュリティグループを変更した?管理
誰がVPCを作成した?管理
誰がS3 オブジェクトを取得した?データ
誰がS3 オブジェクトを削除した?データ
誰がLambda関数を呼び出した?データ
リソースを管理した?
→ 管理

リソース内のデータへ操作した?
→ データ

11. CloudTrail イベント履歴は最初から利用できる

CloudTrail イベント履歴では、現在のリージョンについて過去90日間の管理イベントを表示・検索できます。

AWSアカウント
↓
イベント履歴
↓
過去90日
管理イベント

「昨日のIAM変更を少し確認したい」といった直近の調査に役立ちます。

12. イベント履歴だけを長期監査基盤にはしない

管理イベントのみ

過去90日

組織全体の長期集約ではない

7年間保管、全アカウント収集、データイベント記録、中央アーカイブへの保管が必要ならイベント履歴だけでは不足します。この場合は証跡を設計します。

13. 証跡は継続的な監査ログをS3へ配信する

CloudTrail 証跡を作成すると、選択したイベントをAmazon S3 バケットへログファイルとして継続配信できます。

AWSアカウントアクティビティ
        │
        ▼
    CloudTrail
        │
        ▼
      証跡
        │
        ▼
中央 S3 バケット

これにより長期保管、中央集約、後日のフォレンジックへ利用できます。

14. マルチリージョン証跡を基本候補にする

主に東京リージョンを利用していても、別リージョンで意図しないリソースが作成される可能性があります。アカウント全体の監査を目的とするならマルチリージョン証跡を基本候補にします。

東京リージョンを主に利用
↓
別リージョンでリソース作成
↓
マルチリージョン証跡で追跡

15. マルチアカウントでは組織証跡を評価する

Organizations環境で各アカウントへ個別証跡を作ると、設定差異・作成漏れ・ログ宛先の分散が起きやすくなります。そこでAWS Organizations全体へ適用する組織証跡を評価します。

AWS Organizations
      │
      ▼
組織の証跡
      │
 ┌────┼─────┐
 ▼    ▼     ▼
本番開発サンドボックス

16. 組織証跡はメンバーアカウントへ適用される

組織証跡は組織内のメンバーアカウントへ適用されます。メンバーアカウントは組織証跡を表示できますが、変更・削除はできません。

新しいAWSアカウントが組織へ追加された場合も組織証跡の対象となり、監査設定漏れを減らせます。

17. 組織証跡は管理アカウントまたは委任管理者で管理する

組織証跡はOrganizationsの管理アカウントまたはCloudTrail 委任管理者から管理できます。

管理 アカウントで
日常セキュリティ運用を全部実施
        ↓
セキュリティ / 監査アカウント
委任管理者を評価

エンタープライズではセキュリティ管理を専用アカウントへ分離する設計を評価できます。具体的な登録手順はここでは扱いません。

18. 監査ログは中央アカウントへ集約する

エンタープライズ環境では各ワークロードアカウントのローカルバケットだけへ保存するのではなく、専用ログアーカイブアカウントへ集約する集中型ログ記録を評価します。

本番 ─────┐
開発 ──────┤
サンドボックス ──┼──→ 中央ログアーカイブアカウント
セキュリティ ─┤            │
          └────────────▼
                    S3 バケット

目的はワークロードアカウント管理者と監査ログ管理者の責任を分離することです。

19. 中央ログバケットはワークロードから分離する

本番管理者が本番アカウント内の監査ログも自由に削除できる構成では、監査基盤として弱くなります。

ワークロードアカウント
≠
ログアーカイブアカウント

CloudTrail
↓
専用S3 バケット
↓
監査 / セキュリティチームが管理

ワークロードとログアーカイブを分離し、監査ログへのアクセスを必要なプリンシパルへ限定します。

20. 集中型ログ記録にはバケットポリシーも必要

ログアーカイブバケットを別アカウントへ置くだけでは、CloudTrailが自動的に書き込めるわけではありません。

CloudTrail サービス
↓
S3 バケットポリシー
↓
PutObjectを許可

組織証跡用S3 バケットでは、CloudTrailが組織ログを書き込めるバケットポリシーを設定します。SAP-C02ではポリシー全文暗記ではなく、中央ログ宛先にはCloudTrailからの書き込み権限設計が必要と理解します。

21. 「ログがある」だけでは改ざんされていない証明にならない

監査ではCloudTrail ログが存在するだけでなく、配信後に変更・削除・偽造されていないかを検証できることも重要です。そのためCloudTrailにはログファイル完全性検証があります。

22. ログファイル検証ではダイジェストファイルを使う

ログファイル検証を有効にすると、CloudTrailはログファイルに加えてダイジェストファイルを配信します。ダイジェストにはハッシュやデジタル署名が利用され、ログ完全性を検証できます。

CloudTrailログファイル
        │
        ▼
ハッシュ
        │
        ▼
ダイジェストファイル
        │
        ▼
デジタル署名

CloudTrailはSHA-256によるハッシュとRSA + SHA-256による署名を利用します。暗号方式そのものの暗記より、ダイジェストを用いて完全性を検証する役割を理解します。

23. ログ完全性検証は「改ざん防止」ではなく「改ざん検知」

完全性検証を有効にしても、ログファイルを絶対に削除できなくなるわけではありません。目的は、CloudTrailが配信した後でログファイルが変更・削除されたかを検証できるようにすることです。

変更防止
≠
検知 変更

保存期間や削除防止そのものは、S3側の保持期間やアクセス制御なども含めて別途設計します。

24. 監査アーキテクチャは「収集・保管・検証」を分ける

① 収集
CloudTrail

        ↓

② 選択
管理 / データイベント

        ↓

③ 中央集約
組織の証跡

        ↓

④ 保管先
中央 S3 バケット

        ↓

⑤ 保護 / 検証
アクセス制御
+
ログ完全性検証

単に「CloudTrailを有効化」にするのではなく、収集・選択・中央化・保管・完全性検証を別々の責任として設計します。

25. 要件から設計を選ぶ

要件基本判断
誰がIAM ポリシーを変更したか確認管理イベント
誰がセキュリティグループを変更したか確認管理イベント
誰がS3 オブジェクトを読み取ったか確認データイベント
データイベントの量が多すぎる必要リソース / 運用へ限定
直近の管理イベントを確認イベント履歴
90日を超えて継続保存証跡
全リージョンのアカウントアクティビティを監査マルチリージョン証跡
Organizations全アカウントを統一監査組織証跡
新アカウントでも自動的に監査適用組織証跡
ワークロードから監査ログを分離中央ログアーカイブアカウント
配信後ログの変更・削除を検知ログファイル完全性検証

26. 混同ポイント

  • CloudTrail = 現在のリソース設定を見るサービス:CloudTrailはアカウントアクティビティを記録します。
  • CloudTrailが有効 = すべてのイベントが無期限保存:イベント履歴には90日などの制限があります。
  • 管理イベント = データへの読み取り / 書き込み:管理イベントは制御プレーン操作です。
  • データイベント = デフォルトで全部記録:必要な対象を明示して記録します。
  • S3 バケットを作れば組織全体のログが自動集約:組織証跡と書き込み権限を設計します。
  • 組織証跡 = メンバーアカウントが自由に変更できる証跡:メンバーアカウントは変更・削除できません。
  • ログ完全性検証 = ログ削除防止:配信後の変更・削除の検知に使います。
  • CloudTrail = 脅威検知サービス:CloudTrailは監査イベントを記録し、セキュリティ分析・検出は別サービスと組み合わせます。

27. SAP-C02判断フロー

監査要件がある
        │
        ▼
何を追跡したい?
        │
   ┌────┴────────┐
   │             │
制御プレーンデータプレーン
   │             │
   ▼             ▼
管理     データ
イベントイベント
                   │
                   ▼
             ボリューム / 範囲を
             必要範囲へ限定
        │
        ▼
短期確認だけ?
   │
 はい
   ▼
イベント履歴

 いいえ
   │
   ▼
証跡
   │
   ▼
マルチアカウント?
   │
 はい
   ▼
組織の証跡
   │
   ▼
中央 S3 ログアーカイブ
   │
   ▼
ログ完全性が必要?
   │
 はい
   ▼
ログファイル検証

28. まとめ

AWS CloudTrail
→ アカウントアクティビティの監査 証跡

管理イベント
→ 制御プレーン
→ リソース / アカウント管理操作

データイベント
→ データプレーン
→ リソース内の操作
→ デフォルトでは記録されない

イベント履歴
→ 過去90日
→ 管理イベントのみ

証跡
→ 継続的にS3へログを配信

組織の証跡
→ 組織全アカウントへ適用
→ 新アカウントにも適用

集中ログ記録
→ 専用ログアーカイブへ集約

ログ完全性検証
→ ダイジェストファイル
→ 配信後の変更・削除を検知

最重要ポイントは、「CloudTrailを有効にする」で終わらず、何を記録するか・どのアカウント / リージョンから集めるか・どこへ保管するか・配信後の完全性をどう検証するかまで設計することです。

29. 主要AWS公式資料

理解確認

このページの内容を15問で確認します。

理解確認15問へ →