AWS Audit Manager

解決する課題

• 監査のたびにスクリーンショットや設定情報を手作業でかき集めるのが大変 → 証拠を自動収集したい
• 「どの統制に対してどの証拠が揃っているか」が散らばって把握できない → 統制ごとに証拠を整理したい
• 監査の直前にあわてて準備するため、いつも証跡が不足する → 継続的に証拠を蓄積したい
• 監査人へ提出する資料の作成に時間がかかる → レポートとして一括出力したい

主要概念と用語

• フレームワーク（Framework）: 監査対象とする基準を表すテンプレート。AWS提供の標準フレームワークと、独自に作るカスタムフレームワークがある
• 統制（Control）: フレームワークを構成する個々の要求事項。各統制には、どこからどう証拠を集めるかを定めたデータソースが紐づく
• アセスメント（Assessment）: フレームワークを基に作成する評価の実体。対象のアカウントやサービスの範囲（スコープ）を定義し、証拠の収集をここから開始する
• 証拠（Evidence）: 統制を裏付ける記録。設定情報やイベント、リソースの状態などが該当する
• 自動証拠（Automated Evidence）: AWSの各種ログやAPI、構成情報から自動で収集される証拠
• 手動証拠（Manual Evidence）: 自動収集できない事項について、利用者が手作業でアップロードする証拠
• データソース: 証拠の取得元。CloudTrailの操作ログ、Configのルール評価結果、Security Hubの検出結果、各サービスのAPI呼び出しなどがある
• アセスメントレポート（Assessment Report）: 収集した証拠を統制ごとにまとめ、監査人へ提出できる形に出力した成果物
• 委任管理者（Delegated Administrator）: AWS Organizations配下で組織全体のアセスメントを集中管理する役割のアカウント

仕様・制限・クォータ

• リージョン単位のサービス。アセスメントは作成したリージョン内のデータを対象とする。複数リージョンを対象にする場合は構成を工夫する
• AWS提供の 標準フレームワーク には主要なコンプライアンス基準やベストプラクティスに対応したものが用意されている。要件に合わせて カスタムフレームワーク も作成できる
• 自動証拠の収集は、CloudTrail・AWS Config・Security Hub・各サービスのAPI といったデータソースに依存する。これらが有効でないと自動で集まる証拠が限られる
• 1アカウント・1リージョンあたりのアセスメント数やカスタムフレームワーク数などにクォータがあり、上限緩和を申請できる場合がある
• 収集された証拠には 保持期間 の概念がある。長期保管したい場合はレポートやエクスポートしたデータを別途管理する
• AWS Organizationsと連携して 委任管理者 を指定すると、組織内の複数アカウントを横断したアセスメントを集中管理できる

内部の仕組み

利用者はまずフレームワークを選び、それを基に アセスメント を作成します。アセスメントには対象とするアカウントやAWSサービスの スコープ を指定します。アセスメントを有効化すると、各統制に紐づいた データソース からの証拠収集が継続的に始まります。

自動証拠は複数の経路から集まります。CloudTrailからは「誰がどの操作をしたか」の操作ログが、AWS Configからは「リソースがあるべき設定か」のルール評価結果が、Security Hubからはセキュリティ検出結果が取り込まれます。さらに各サービスのAPIを呼び出して、その時点のリソース構成をスナップショットとして取得します。これらが統制ごとに自動で振り分けられて蓄積されていきます。

自動では裏付けられない統制（運用手順の整備状況など）については、利用者が 手動証拠 をアップロードして補います。集まった証拠は統制単位で整理され、準備状況をいつでも確認できます。監査のタイミングでは、これらをまとめた アセスメントレポート を出力して監査人へ提出します。

設計パターン / ベストプラクティス

• データソースを先に整える: 自動証拠を最大化するため、CloudTrail・AWS Config・Security Hubを事前に有効化しておく
• 標準フレームワークから始める: 目的の基準に合う標準フレームワークでアセスメントを作り、不足分だけをカスタム統制で補う
• 継続的に回す: 監査直前ではなく常時アセスメントを動かし、証拠を日々蓄積して準備不足を防ぐ
• 手動証拠の運用を決める: 自動化できない統制について、誰がいつ証拠をアップロードするか責任分担をあらかじめ定める
• 組織横断は委任管理者で集約: マルチアカウント環境ではOrganizationsと連携し、委任管理者で組織全体のアセスメントを一元管理する
• レポート出力先を保護する: アセスメントレポートやエクスポート先のS3バケットはアクセス制限と暗号化を施す

運用・監視

• アセスメントごとの証拠収集状況を定点観測し、想定どおりに証拠が集まっているかを確認する
• 統制ごとに証拠の有無や充足度をレビューし、不足している統制を特定して手動証拠で補完する
• データソースとなるCloudTrailやAWS Configが無効化・設定変更されていないかを監視し、証拠の欠落を防ぐ
• 監査サイクルに合わせて定期的にアセスメントレポートを出力し、最新の証跡を提出可能な状態に保つ
• 委任管理者のアカウントで、組織全体のアセスメント状況をまとめて把握する

コスト

従量課金が基本で、主に 有効化したアセスメントの数や規模 に応じて費用が発生します。証拠の収集量や対象とするアカウント・リソースが多いほど費用は増える傾向があります。また、証拠の供給源となるCloudTrail・AWS Config・Security Hubそれぞれにも個別の課金が発生する点に注意が必要です。不要になったアセスメントは無効化する、対象スコープを必要な範囲に絞るといった工夫で費用を抑えられます。最新の料金は公式の料金ページで確認してください。

セキュリティ

• 証拠そのものが監査の根拠となるため、レポートやエクスポート先のS3バケットには 暗号化 とアクセス制限を施し、改ざんを防ぐ
• Audit Managerが証拠収集に使うサービスロールの権限は 最小権限 に絞る
• 収集される証拠には設定情報や操作ログなど機微な情報が含まれうるため、アセスメントの閲覧権限を必要な担当者に限定する
• Audit Manager自体は証拠の収集と整理が役割であり、防御や是正は各サービス側で行う。Audit Managerは「監査に備えて証跡を整える役割」として位置づける

Well-Architected の観点

• セキュリティ: コンプライアンス基準に対する証跡を継続的に整え、統制の充足状況を可視化することで、ガバナンスと監査対応の土台を作る
• 運用上の優秀性: 手作業の証拠集めを自動化し、監査準備を仕組み化することで、運用負荷を下げて反復可能なプロセスにできる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 利用可能な標準フレームワークの一覧を確認
aws auditmanager list-assessment-frameworks --framework-type Standard

# フレームワークを基にアセスメントを作成
aws auditmanager create-assessment \
  --name "annual-compliance-assessment" \
  --framework-id <framework-id> \
  --assessment-reports-destination '{"destinationType":"S3","destination":"s3://my-audit-reports-bucket"}' \
  --scope '{"awsAccounts":[{"id":"111122223333"}],"awsServices":[{"serviceName":"s3"}]}' \
  --roles '[{"roleType":"PROCESS_OWNER","roleArn":"arn:aws:iam::111122223333:role/AuditOwner"}]'

# 作成済みアセスメントの一覧を確認
aws auditmanager list-assessments