AWS CLF-C02 で AWS CloudTrail はどう問われるか

監査やインシデント調査では「誰が、いつ、どこから、どのリソースに対して、どの操作を実行したか」を後から追跡できることが不可欠です。AWS CloudTrail はアカウント内で発生した API 呼び出しを記録するサービスで、マネジメントコンソール、AWS CLI、SDK のいずれからの操作であってもイベントとして捕捉し、送信元 IP アドレス、実行したプリンシパル、リクエストパラメータ、発生時刻を含むログを残します。証跡 (Trail) を作成すれば Amazon S3 バケットへ継続的にログを配信して長期保存でき、CloudWatch Logs との連携や Amazon Athena による検索も可能になるため、設問の「削除操作を含むすべての API アクティビティの記録、数年分の保持、事後調査」という要件を満たします。Amazon CloudWatch は CPU 使用率などのメトリクスやアプリケーションログを収集して監視とアラームを行うサービスであり、API 呼び出しの証跡そのものを生成するわけではありません。AWS Config はリソースの構成項目とその変更履歴を記録して準拠状態を評価するサービスで、構成変更を伴わない読み取り系を含めた全 API 呼び出しの履歴を残す用途には対応しません。AWS Systems Manager はインスタンスの運用管理、パッチ適用、パラメータ管理などを行うサービスで、アカウント全体の API 監査ログを提供するものではありません。

AWS アカウント内で誰が何をしたかを後から追跡できるようにするための監査基盤が AWS CloudTrail です。CloudTrail は、AWS マネジメントコンソール、AWS CLI、AWS SDK、API のいずれから実行されたアクションであっても、呼び出したプリンシパル (IAM ユーザーやロール)、発生時刻、送信元 IP アドレス、リクエストパラメータ、応答要素をイベントとして記録します。S3 のオブジェクト単位の読み取り操作はデータイベントに分類されるため、対象バケットに対してデータイベントの記録を有効化しておけば、GetObject を誰がいつ実行したかを特定でき、本設問の要件を満たします。Amazon CloudWatch は CPU 使用率やリクエスト数といったメトリクスとログを収集して可視化・アラーム発報を行うモニタリングサービスであり、個々の API 呼び出しの実行者を記録する仕組みではありません。AWS Config はリソースの構成変更を記録し準拠状況を評価するサービスで、バケットの設定変更は追えてもオブジェクトのダウンロード操作は追跡できません。AWS Infrastructure Event Management (IEM) は大規模セールや製品ローンチなど予定されたイベントに向けてアーキテクチャとスケーリングの助言や当日の運用支援を提供するサポート提供物であり、ログ監査の機能ではありません。

AWS CloudTrail は AWS アカウント内で発行されたすべての API 呼び出しを記録するガバナンス・監査サービスで、各イベントに「誰が (IAM プリンシパル)」「いつ (タイムスタンプ)」「どこから (送信元 IP アドレスとユーザーエージェント)」「何に対して (リソースとパラメータ)」操作したかが含まれます。CloudTrail のイベント履歴は追加設定なしに既定で有効で、直近 90 日間の管理イベントをコンソールや CLI から検索でき、それ以上の長期保存が必要な場合は証跡 (trail) を作成して S3 に配信します。本シナリオが求めているのは操作者・送信元・時刻の特定であり、まさに CloudTrail の役割なので A が正解です。B の Amazon CloudWatch はメトリクスやログを収集してモニタリングとアラームを提供しますが、CPU 使用率のグラフからはインスタンスが停止した時刻の推測はできても、誰が API を呼んだかという主体の情報は得られません。C の AWS Config はリソース構成の変更履歴を記録しルールで準拠状態を評価するサービスで、構成が変わった事実は分かりますが、監査証跡として操作者を一次的に示すのは CloudTrail です。D の AWS Trusted Advisor は MFA 未設定や公開されたセキュリティグループなどのベストプラクティス違反を横断チェックする助言サービスであり、過去の個別 API 呼び出しの追跡には使えません。