監査ログその１：Webサービスにおける監査ログの考え方 ― 要件整理の基礎編

コンペでよく見る「監査ログ」って何を残せばいい？

こんにちは、リベロジックでCTOをしている大塚です。

WebサイトやWebサービスのコンペに参加していると、要件の中に「監査ログを取得できること」「ログを一定期間保存すること」と書かれていることがよくあります。

その要件に合わせてサービスを選んだり、プランを変更したり、ログ保存用のオプションを追加したりするわけですが、そもそも「監査ログ」とは何を指しているのでしょうか。

今回はそのあたりを、少し整理してみようと思います。

ログにもいろいろある

ひとことでログといっても、実際にはいくつか種類があります。

どれもログには違いありませんが、記録する内容も利用する目的も異なります。
例えば、管理者がユーザーの権限を変更した、担当者がコンテンツを公開した、といった操作を記録するものが、一般的に監査ログと呼ばれるものに近いですね。

障害調査と証跡保全は分けて考える

ログの目的は、大きく2つに分けられます。

ひとつは、障害や不具合が起きたときに原因を調べるためのログです。

「昨日フォームを送ったのに届いていない」「特定の時間だけエラーが発生していた」といった問い合わせを調査するときに使います。

もうひとつは、あとから操作の事実を確認するためのログです。

「誰が設定を変更したのか」「いつコンテンツが公開されたのか」「管理画面でどのような操作が行われたのか」といった記録です。

この2つは保存期間も使い方も違います。

すべてのログを長期間検索できる状態で保管しようとすると、費用も大きくなります。反対に、直近のログしか残していなければ、監査やインシデント調査で必要な証跡が消えてしまいます。

最初から分けて考えたほうが無理のない設計になります。

「監査ログが必要」を要件へ落とし込む

監査ログという言葉だけでは具体的な構成は決められません。

まずは目的を確認し必要な記録と保存方法へ落とし込んでいきます。

「ログが取れます」だけでは少し足りない

クラウドサービスの管理画面にログが表示されていれば、つい「ログは取れています」と考えてしまいます。

ただし、サービスによって保存される内容や期間は異なります。

• エラーは残るが、管理者の操作までは残らない
• 管理画面では確認できるが、一定期間で消える
• 外部へ転送するには上位プランが必要
• アプリケーション独自の操作は、自分たちで記録する必要がある

「誰が商品情報を変更したか」「どの申込データを処理したか」といった業務上の記録は、クラウドサービスだけでは分からないこともあります。

コンペの要件に「監査ログ」と書かれていたら、少なくとも次の点は確認しておきたいところです。

要件整理のチェックリスト

✅️ どの操作を記録するのか
✅️ 利用者と管理者、どちらの操作なのか
✅️ 障害調査と監査、どちらが目的なのか
✅️ どのくらいの期間保存するのか
✅️ 普段から検索する必要があるのか
✅️ ログを閲覧できる人は誰なのか
✅️ 個人情報を含む可能性があるか

ここが分からないままサービスやプランを決めると、必要以上に大きな構成になったり、逆に必要なログが残っていなかったりします。

現代のWebサービスではログも分散する

昔ながらのWebサーバーであれば、サーバー内のログファイルを保存しておく、という比較的分かりやすい考え方ができました。

現在はCDN、ホスティング、データベース、ヘッドレスCMS、メール配信など、複数のクラウドサービスを組み合わせてWebサービスを作ることが増えています。

リベロジックでも、AWSだけでなく、Cloudflare、Vercel、Supabase、microCMS、Kurocoなどを案件に合わせて利用しています。

ログもそれぞれのサービスに分かれて保存されるため、「システム全体として何が残るのか」を見渡して考える必要があります。

まずは目的を確認するところから

「監査ログが必要」と言われると、特別なサービスを導入しなければならないように感じます。

もちろん要件によっては、外部のログ管理サービスや長期保存の仕組みが必要です。ただし、最初から大きな構成を用意すればよいというものでもありません。

まずは、何を、何のために、どのくらい残すのか。

そこを整理したうえで、標準機能で対応できる部分と、追加で仕組みを作る部分を分けていくのが現実的です。

次回は、AWS、Cloudflare、Vercel、Supabase、ヘッドレスCMSなど、私たちがよく扱うサービスではどのようなログが残るのか、ざっくり比較してみます。

ではでは。