CloudTrailによる操作監査のシナリオ判断
Web公開設定が変わり、重要ファイルも削除されました。設定変更とファイル操作は同じ記録範囲とは限りません。調査の対象、時刻、保存先を絞り、証跡がないことと操作がなかったことを区別します。
この単元で学ぶこと
- 設定変更とデータ操作に必要な証跡を選べる
- 履歴が見つからない原因を保存範囲から調べられる
- 操作記録と構成・性能を結び付けて調査できる
本文解説
設定変更を調べる セキュリティグループの受信範囲が変わっていました。対象の資源、アカウント、リージョン、変更が起きた時間帯を特定し、CloudTrailの管理イベントを調べます。似た名前の別資源のイベントを根拠にしないよう、対象識別子を確認します。
実行主体の解釈 記録された主体がIAMロールなら、そのセッションや関連する証跡を確認します。ロール名が表示されているだけで、特定個人の故意と断定しないことが大切です。共有認証情報を使う運用は、個人との対応を難しくする場合があります。
S3ファイル削除を調べる 設定変更の履歴はあっても、オブジェクトのDeleteObjectが記録されていない場合があります。対象バケットのデータイベントが記録対象に入っていたかを確認します。管理イベントしか取っていなければ、ファイル操作の全履歴が揃うとは限りません。
検索範囲を見直す 記録が見つからないときは、時刻の基準、リージョン、アカウント、操作種別、保持期間を確認します。別リージョンのイベントを同じ画面条件で探していたり、90日を超えた過去を標準履歴だけで探したりしていないかを調べます。
保存期間の要件 監査で一年分を求められるなら、その期間に合う記録・保管を事前に構成します。保存先へ出力されること、担当者が調査できること、不要に消せないことを検証します。履歴画面へアクセスできるというだけでは長期監査の要件を満たしません。
構成と照合する CloudTrailで変更操作を特定したら、Configに記録された前後の状態と照らし合わせます。操作APIが呼ばれたことと、意図した設定になったことを分けます。操作結果や対象に基づき、期待した構成変更が起きたかを調べます。
性能悪化と照合する 変更後に応答が悪化したならCloudWatchのメトリクスやアプリログを合わせます。時刻が近いだけの無関係な操作を原因としないよう、対象と設定内容を確認します。証跡は仮説を検証する材料であり、自動的に原因を確定するものではありません。
再発防止 記録漏れが見つかったら必要なデータイベントやリージョンを対象へ加え、サンプル操作で届くことを確認します。ただし、今の設定変更によって過去の未記録操作が戻ることはありません。調査で確認できた事実と確認できない範囲を分けて報告します。
図解
重要ポイント
- 設定変更は管理イベント、S3データ操作は対象データイベントを確認する。
- 対象ID・時刻・アカウント・リージョンをそろえる。
- 証跡がないことだけで操作なしと断定しない。
- 保存とアクセスを事故前に検証する。
間違えやすい点
- ロール名だけから個人の動機を断定しない。
- 90日より古い調査を標準履歴だけへ依存しない。
- 後から設定して過去の記録漏れを解消したと扱わない。
用語解説
- メトリクス
- CPU使用率や要求数など、時刻とともに記録される数値。単位・集計期間・対象を合わせて読む。
- アラーム
- メトリクスなどの評価条件に応じて状態が変わり、設定した通知や対応へつなげる仕組み。
- 管理イベント
- AWSリソースの作成や設定変更など、管理面の操作を記録するイベント。
- データイベント
- S3オブジェクトへの取得・書込みなど、資源内のデータに対する操作を記録するイベント。対象の明示設定を確認する。
- 構成項目
- AWS Configが記録する、対象資源のある時点での属性や関係などの情報。
- 準拠評価
- 定めたルールに対象構成が合っているかを判定すること。未設定の要件まで保証するものではない。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。