そのシークレットを見たのは誰？監査ログが思っている以上に重要な理由

午前3時に通知が届きます。誰かが本番データベースの認証情報を使って破壊的なクエリを実行しました。損害は発生済みです。最初の疑問は「どうやって侵入したのか」ではなく「そのパスワードに誰がアクセスできたのか」です。

チームがその質問に数分以内に答えられなければ、どんな暗号化やローテーションでも解決できない問題を抱えていることになります。監査ログがなければ、手探りで進むしかありません。シークレットが何週間も漏洩し続けていても、それが外部からの侵害なのか、チーム内の誰かによるものなのかを知る術がないのです。

シークレットのための監視カメラ

シークレットの監査ログは、建物の入り口にある防犯カメラのようなものです。誰かまたは何かがシークレットを取得するたびに、ボールトは誰がリクエストしたか、どのシークレットを要求したか、正確な時刻、リクエストの発信元を記録します。この記録を監査証跡と呼びます。

重要なルール：通常のユーザーはこれらのログをオフにしたり削除したりできません。特別な権限を持つ管理者だけが可能です。ユーザーが自分のアクセス履歴を消せてしまうと、監査システム全体が無意味になります。人に見せたいものだけが表示されるログになってしまうからです。

監査証跡が必ず捕捉すべき情報

有用な監査証跡には、少なくとも4つの情報が必要です。

誰がアクセスしたか。 これはユーザー名、サービスアカウント、アプリケーション名のいずれかです。「バックエンドチームの誰か」ではなく、正確にどのアイデンティティがリクエストを行ったかを把握する必要があります。

どのシークレットにアクセスしたか。 シークレットの名前またはパスを記録します。値そのものは不要です。実際のパスワードをログに保存する必要はありません。「本番データベースのパスワード」が取得されたことだけがわかれば十分です。

いつ発生したか。 タイムスタンプは秒単位の精度が必要です。インシデント調査中は、数分の違いが全体のストーリーを変える可能性があります。アクセスはインシデントの5分前だったのか、5分後だったのか。

結果。 リクエストは成功したか失敗したか。拒否された場合、その理由は何か。失敗したアクセス試行は、成功したものと同様に重要です。盗まれた認証情報をテストしている可能性を示すからです。

HashiCorp Vault、AWS Secrets Manager、Azure Key Vaultといった最新のボールトは、これらのログを標準で提供しています。ログはSIEMシステムやElasticsearchのような集中ログストアに送信できます。重要なのはログがどこにあるかではなく、誰が読めるかです。セキュリティチームとインシデント対応者は読み取りアクセスを持つべきです。通常の開発者は監査証跡を参照する必要は通常ありません。

以下はHashiCorp Vaultの実際の監査ログエントリです。

{
  "time": "2025-03-15T02:34:12.847Z",
  "type": "response",
  "auth": {
    "client_token": "hmac-sha256:abc123...",
    "display_name": "deploy-bot",
    "policies": ["deploy", "default"]
  },
  "request": {
    "path": "secret/data/production/db-password",
    "operation": "read",
    "remote_address": "10.0.1.42"
  },
  "response": {
    "data": {
      "data": null
    },
    "warnings": null
  }
}

ログを読むには慣れが必要

監査ログはインシデント後のフォレンジックだけのためのものではありません。通常のパターンを理解して異常を発見するのに役立ちます。

次のシナリオを考えてみてください。監査ログに「deploy-bot」アカウントが午前2時34分に「db-production-password」シークレットにアクセスしたと記録されています。これは正常でしょうか。状況によります。パイプラインが毎晩デプロイを実行しているなら、そのアクセスは想定内です。しかし、その夜に予定されたデプロイがなかった場合、疑問を持つ必要があります。誰かが手動でパイプラインを実行したのか、あるいはdeploy-botの認証情報が侵害されたのかもしれません。

監査ログによく現れる不審なパターンは以下の通りです。

  • 短時間に同じシークレットへの繰り返しアクセス
  • チームの通常のレンジと一致しないIPアドレスからのアクセス
  • 通常はステージングのシークレットにしかアクセスしない開発者が突然本番の認証情報を取得する
  • ユーザーのロールに合わない環境のシークレットへのアクセス

最後のパターンは厄介です。緊急修正のために本番アクセスが本当に必要な場合もあります。しかし、説明なしに繰り返し発生する場合は、悪用の可能性があります。監査ログはそのような会話をするためのデータを提供します。

監査ログは復旧にも役立つ

シークレットが侵害された疑いがある場合、監査ログは被害の範囲を教えてくれます。特定の時間枠内でそのシークレットを取得したアイデンティティを正確に確認できます。これによりローテーションの優先順位付けが可能になります。侵害されたシークレットにアクセスしたのが1つのサービスアカウントだけなら、そのアカウントの認証情報だけをローテーションすれば済みます。20の異なるユーザーとアプリケーションが取得していた場合、はるかに大規模なクリーンアップ作業が必要です。

監査ログがなければ、最悪のケースを想定してすべてをローテーションするしかありません。それにより不要な作業とダウンタイムが発生します。監査ログがあれば、必要なものだけをローテーションできます。

シークレット監査ログの実践的チェックリスト

今日シークレット管理を設定する場合、監査カバレッジを確認するためのクイックチェックリストを以下に示します。

  • すべてのシークレットアクセスが、アイデンティティ、シークレット名、タイムスタンプ、結果とともに記録されている
  • 通常のユーザーはログを削除または変更できない
  • 監査ログはセキュリティチームがクエリできる集中ロケーションに送信されている
  • インシデント時だけでなく、定期的にログをレビューするプロセスがある
  • 各環境の通常のアクセスパターンを把握している

結論

監査ログはシークレットの漏洩を防ぐわけではありません。しかし、侵害後に最も重要な質問「誰が何をいつ見たのか」に答える能力を提供します。その答えがなければ、推測するしかありません。セキュリティにおいて推測は、小さなインシデントを大きな災害に変える方法です。