AWS 道場 02–05

監査ログ基盤 — 証跡を軽く残し、あとからSQLで追う

監査ログは「誰が、いつ、何をしたか」を説明するための証跡です。APIの応答を遅くせず、長期保存と検索可能性を両立する責務分割を捉えます。

TL;DR

  1. 監査ログはアプリのデバッグ用ログではなく、利用者の操作を証明する記録。
  2. APIでは軽く出力し、配送・保存・分析は非同期に分離する。
  3. CloudWatch Logs → Firehose → S3 → Athena が役割を分担する。

01監査の問いに答えられる属性を、操作時点で失わない。

監査担当者が後日、ひとつの操作を再現できる情報を定義する。

監査の問いに答えられる属性を、操作時点で失わない。
中央の5要素が1件の証跡を構成し、周囲のカードが具体的な記録項目を示す。

たとえばユーザー削除なら、実行者IDだけでなく、削除対象ID・操作時刻・送信元IP・環境まで同じJSONに含める。

リクエストボディには機密情報が含まれ得る。監査に必要な項目だけを選び、秘密値をそのまま保存しない。

02監査のためのI/Oが、ユーザー向けAPIを遅くしてはいけない。

ユーザー向け処理と、証跡の配送処理を別の時間軸に置く。

監査のためのI/Oが、ユーザー向けAPIを遅くしてはいけない。
上側の短い応答経路と、下側のCloudWatch LogsからS3までの非同期経路を見比べる。

APIはJSONログを出して応答し、subscription filterがaudit_logだけをFirehoseへ渡す。配送の再試行はFirehose側が受け持つ。

S3やDBへの直接書き込みをmiddlewareに入れると、保存先の遅延や障害が全APIへ波及する。

03データ本体はS3、読み方はCatalog、問い合わせはAthenaが担う。

長期保管、読み方、問い合わせを別サービスへ分ける。

データ本体はS3、読み方はCatalog、問い合わせはAthenaが担う。
下のS3がデータ本体、中央のCatalogが目録、上のAthenaがSQLの実行者という上下関係を読む。

監査担当者が期間とuser_idで絞ると、AthenaはCatalogの列定義を使い、S3上のParquetを走査する。

Catalogにログ本体は入らない。S3の削除・移動やスキーマ変更は、そのままクエリ失敗や誤読につながる。

結論

  1. 監査ログは「意味が読める証跡」として設計する。
  2. APIは軽く、配送・永続化・分析を非同期の別責務に置く。
  3. S3の実体とGlueのメタデータをAthenaが結び、長期保存と調査を両立する。