監査ログの保管期間を、インシデント初動、SaaS棚卸し、内部統制、証拠保全から逆算して決める実務ガイド。残すログ、残しすぎない情報、見直し周期を整理する。
ログ保管は「長く残す」より「調査できる状態で残す」
インシデント対応で一番困るのは、アラートが出なかったことだけではない。あとから調べようとして、必要なログが消えている、時刻がずれている、誰も検索できない場所にある、という状態だ。ログがなければ、影響範囲も、初動の優先順位も、顧客や社内への説明も曖昧になる。
一方で、すべてのログを無期限に残せばよいわけでもない。個人情報、認証情報、業務データ、コスト、閲覧権限、法務・契約上の扱いを無視して長期保存すると、ログ基盤そのものが新しいリスクになる。
この記事では、情シス、CSIRT、SaaS管理者、開発組織の担当者向けに、監査ログの保管期間を「なんとなく90日」ではなく、調査シナリオから逆算して決める考え方を整理する。ログの読み方そのものは セキュリティログの読み方 で、手を動かす練習は アクセスログ解析ミニCTF で確認できる。
この記事は、防御・運用改善を目的にしたログ保管設計の考え方を扱う。法令、業界規制、契約、社内規程で保存期間が決まっている場合は、その要件を優先する。ここでは特定の保存日数を法的な正解として提示しない。
保管期間は「何を説明したいか」から逆算する
ログ保管の議論は、最初に「何日残すべきか」から始めると迷いやすい。先に決めるべきなのは、そのログで何を説明したいのかだ。
| 使い道 | 説明したいこと | 必要になりやすいログ |
|---|---|---|
| 初動確認 | 直近の不審ログイン、権限変更、外部共有、管理操作 | IdP、SaaS監査ログ、EDR、Webアクセスログ |
| 影響範囲確認 | いつから、誰が、どのデータやシステムへ触れたか | 監査ログ、アプリログ、ストレージログ、APIログ |
| 復旧判断 | パッチ後や設定変更後に不審な操作が止まったか | 変更履歴、認証ログ、検知ログ、管理画面ログ |
| 内部統制・監査 | 重要操作が承認済みで、追跡可能か | 管理者操作ログ、権限付与履歴、例外申請記録 |
| 再発防止 | どの検知・権限・手順が足りなかったか | タイムライン、アラート履歴、チケット、証跡 |
たとえば、フィッシング報告を受けたときは、メール原本だけでなく、サインインログ、MFA結果、SaaS監査ログ、外部共有、OAuthアプリ追加の有無を同じ時間軸で見る。GitHubのsecret leakでは、トークンの最終利用、Actions実行履歴、監査ログ、関連システムのAPI利用状況を確認する。
つまり、保管期間は「普段どのログを残しているか」ではなく、「あとからどの判断を説明する必要があるか」から決める。ログが残っていても、担当者が検索できず、時刻が揃わず、チケットと結びついていなければ、実務では使いにくい。
ログを3階層に分けると優先順位を決めやすい
すべてのログを同じ粒度、同じ期間、同じ保存先で扱う必要はない。まずは、調査での重要度と機密性に応じて3階層に分ける。
| 階層 | 代表例 | 保管設計のポイント |
|---|---|---|
| 高重要ログ | IdP、管理者操作、SaaS監査ログ、EDR検知、クラウド監査ログ | 改ざん防止、検索権限、長めの保持、停止検知を重視する |
| 調査補助ログ | Webアクセスログ、APIログ、DNS/プロキシログ、メールゲートウェイログ | 初動で絞り込める検索性と時刻同期を重視する |
| 詳細・大量ログ | デバッグログ、詳細イベント、長文リクエスト、アプリ内部ログ | 必要最小限にし、機密情報の混入とコストを抑える |
高重要ログは、後から「誰が何をしたか」を説明する根拠になる。管理者権限の付与、MFA設定変更、ログ設定の無効化、外部共有、APIキー作成、セキュリティ例外の承認などは、短期保存だけでは足りないことが多い。
一方で、詳細ログには個人情報や秘密情報が混ざる場合がある。アプリケーションのエラーログにAuthorizationヘッダー、Cookie、APIキー、リクエスト本文をそのまま残すと、ログ基盤が情報漏えいの入口になる。OWASP Logging Cheat Sheet でも、ログに含める情報と避けるべき情報を分けて考えることが強調されている。
トークン、Cookie、セッションID、パスワード、完全な個人情報、決済情報、復旧コードをログへそのまま残さない。調査に必要な場合も、識別子、ハッシュ化、マスキング、アクセス制御を組み合わせる。
保存日数は「短期・中期・長期」の役割で分ける
ログ保管期間は、1つの数字にまとめるより、短期・中期・長期で役割を分ける方が実務に合う。以下は日数の正解ではなく、設計時に使う考え方の例だ。
| 期間の考え方 | 主な用途 | 設計時に見ること |
|---|---|---|
| 短期 | 直近アラートの初動確認、誤検知確認、本人確認 | すぐ検索できるか、担当者がアクセスできるか |
| 中期 | 侵害開始時期の推定、権限変更の追跡、横展開確認 | 複数ログを同じ時間軸で追えるか |
| 長期 | 内部統制、監査、契約・法務対応、傾向分析 | 改ざん防止、保管コスト、提出可能性、削除ルール |
たとえば、SaaSの外部共有は短期のアラートだけで判断しにくい。数週間前に権限が変更され、その後に共有リンクが作られ、さらに別アカウントからアクセスされることがある。GitHubやクラウドの監査ログも、直近だけでなく、設定変更やトークン発行の前後関係を見る必要がある。
逆に、詳細なデバッグログを長期に残すことが常に正しいわけではない。個人情報、機密情報、運用コスト、検索性能、権限管理が重くなる。長く残すログほど、誰が読めるか、何の目的で使うか、いつ削除するかを明確にする。
最初に設計するべきログは5種類
ログ保管をこれから整えるなら、最初から全ログを対象にしない。インシデント対応とSaaS管理で使う頻度が高い5種類から設計する。
| ログ | 残す理由 | 見落とすと起きること |
|---|---|---|
| IdP / サインインログ | 誰がどこから認証したかを確認する | 乗っ取り、MFA失敗、条件付きアクセスの回避を追えない |
| SaaS監査ログ | 権限変更、外部共有、OAuth同意、管理者操作を見る | 正規機能を使ったデータ持ち出しを見落とす |
| 管理者操作ログ | 管理画面、クラウド、CI/CD、セキュリティ設定の変更を見る | 事故後に設定変更の責任と時刻を説明できない |
| EDR / 端末ログ | 不審プロセス、隔離、端末上の操作を確認する | 認証ログだけでは端末側の影響範囲が分からない |
| Web / APIアクセスログ | 管理画面、API、外部公開アプリへのアクセスを見る | 探索、失敗、成功、異常な連続アクセスを追えない |
この5種類は、SaaS権限棚卸しチェックリスト や 漏えい疑い初動テンプレート でも使う。特にSaaSやクラウドでは、ユーザー一覧だけでは判断できない。監査ログ、外部共有、OAuthアプリ、APIトークン、管理者操作を合わせて見る必要がある。
「残す」だけでなく「消えたことを検知する」
ログ保管で見落としがちなのは、ログが取れていない状態を検知する仕組みだ。インシデント後に確認して初めて「監査ログが無効だった」「保持期間が短かった」「転送が止まっていた」と分かるのでは遅い。
最低限、次の状態は定期確認またはアラート化したい。
| 確認対象 | 見ること |
|---|---|
| ログソース | IdP、SaaS、EDR、クラウド、Web/APIから転送が続いているか |
| 時刻同期 | UTC/JST、NTP、タイムゾーン表記が混在していないか |
| 権限 | 調査担当者が必要なログを読めるか、過剰に読めないか |
| 改ざん防止 | 削除、上書き、保持期間変更が検知・承認されるか |
| 検索性 | 事故時にユーザー、IP、端末、アプリ、時刻で検索できるか |
CISAのCybersecurity Performance Goalsは、重要なログソースが無効になった場合にセキュリティチームへ通知する考え方を含む。実務では、SIEMやログ基盤を導入したかどうかよりも、重要なログが止まったことに気づけるかが重要になる。
記録テンプレート：ログ保管設計を1枚にまとめる
ログ保管は、ツール設定だけでなく運用設計として残す。次のような表を作ると、監査、引き継ぎ、インシデント初動で使いやすい。
| 項目 | 記入例 |
|---|---|
| ログ名 | Microsoft Entra ID サインインログ |
| 用途 | 不審ログイン、MFA失敗、条件付きアクセス確認 |
| 所有者 | 情シスID管理チーム |
| 保存先 | SIEM、クラウド監査ログ保管領域 |
| 保管期間 | 社内規程と調査要件に基づき設定 |
| 検索できる人 | CSIRT、ID管理担当、監査担当 |
| 重要フィールド | ユーザー、時刻、IP、端末、アプリ、MFA結果、条件付きアクセス結果 |
| マスキング | 個人情報とトークンは必要最小限に制限 |
| 停止時の通知 | ログ転送停止、保持期間変更、管理者による削除操作 |
| 見直し周期 | 四半期、重大インシデント後、SaaS構成変更時 |
ここで重要なのは、保管期間を空欄にしないことではなく、その根拠を残すことだ。「法務要件」「社内監査」「インシデント初動」「顧客契約」「コスト」のどれを優先したのかが分からないと、あとから削除も延長も判断できない。
ログ保管の目的は、あとからタイムラインを作れるようにすることだ。時刻、根拠ログ、担当者、未確認事項を残す運用は Incident Timeline と合わせて確認したい。
よくある失敗：保存期間だけを決めて運用を決めない
ログ保管でよくある失敗は3つある。
1つ目は、保存期間だけ決めて、検索権限を決めないことだ。ログは残っているのに、事故時に誰も見られない、申請に時間がかかる、担当者が休みで開けない、という状態では初動に使えない。閲覧権限は最小限にしつつ、緊急時の代理経路を決めておく。
2つ目は、保管コストだけを見て重要ログを削ることだ。大量のデバッグログを減らすのはよい。しかし、IdP、SaaS監査ログ、管理者操作ログまで短期で消すと、事故後に説明できない。削るなら詳細度、対象、保存先を分ける。
3つ目は、ログの中身を確認しないことだ。保管設定があっても、必要なフィールドが出ていない、時刻がずれている、ユーザー識別子が変換されている、外部共有やOAuth同意が記録されていない場合がある。年1回の棚卸しではなく、インシデント訓練やミニCTFのような形で実際に読めるか確認する。
まとめ：ログ保管は「調査・説明・再発防止」のために設計する
監査ログの保管期間は、単に長くすればよいものではない。インシデント初動、影響範囲確認、復旧判断、内部統制、再発防止のどれに使うのかを決め、重要ログ、調査補助ログ、詳細ログに分けて設計する。
まずはIdP、SaaS監査ログ、管理者操作ログ、EDR、Web/APIアクセスログから始める。保存期間、保存先、検索権限、改ざん防止、停止検知、削除ルールを1枚の設計表にまとめるだけでも、初動の質は大きく変わる。
次に読むなら、ログの見方は セキュリティログの読み方 、実際の初動メモは 漏えい疑い初動テンプレート 、SaaS権限の観点は SaaS権限棚卸しチェックリスト が使いやすい。基礎概念は Audit Log と Log Retention で整理できる。
参考・出典
- NIST SP 800-92: Guide to Computer Security Log Management — ログ管理の計画、収集、保持、運用プロセスを確認できる。
- NIST Cybersecurity Framework — 検知、対応、復旧を含むセキュリティ運用の枠組みを確認できる。
- CISA Cybersecurity Performance Goals — 重要なログソースやセキュリティ基礎対策の考え方を確認できる。
- OWASP Logging Cheat Sheet — アプリケーションログで記録すべきイベントと避けるべき記録を確認できる。
