監査ログがない・途切れた時の確認方法｜ログ欠損の切り分けと初動対応

監査ログがない時は「何も起きていない」と結論づけない

不審なログインの連絡を受けたのに監査ログが見つからない。昨日まで届いていたSaaSのログが、今日はSIEMで0件になっている。こうした場面では、検索で見えないことと、記録そのものが失われたことを分ける必要があります。

まず、対象サービス・期間・タイムゾーン・閲覧権限を確認し、送信元に記録があるかを調べます。残っている証跡を保全しながら、どこまで観測でき、どこから確認できないのかを明らかにします。不審な変更や進行中の被害があれば、原因の確定を待たず社内の対応責任者へ連絡してください。

誰が何を確認するか

個人利用者は、自分でログ設定を変更せず、通知を受けた時刻、対象サービス、覚えのある操作を管理者へ伝えます。パスワードやセッション情報を添付する必要はありません。

担当	最初に確認すること
情シス・SaaS管理者	正しい組織・テナントを見ているか、監査の対象操作、閲覧権限、保持期限、設定変更
開発者・運用担当	アプリがイベントを出しているか、転送の状態、形式変更、処理失敗、保存先の容量
SOC・CSIRT	重要な監視の空白、不審操作との前後関係、代替証跡、封じ込めと調査の優先順位

複数部署にまたがる場合は、連絡担当を一人決めます。「SaaS側の問題」「SIEM側の問題」と早く決めつけず、同じ期間・同じ対象を照合できる状態を作ることが先です。

最初の確認チェックリスト：設定を変える前に残すこと

• 対象のサービス、組織・テナント、アカウント、端末、ログの種類を特定する。
• 「いつからないように見えるか」と「最後に確認できたイベント」を、タイムゾーン付きで記録する。
• 検索画面の期間、フィルタ、対象データ、使用した閲覧ロールを控える。
• イベントの発生時刻と、収集先への到着時刻を分けて確認する。検索に使われる時刻の種類も確認する。
• 送信元・転送処理・保存先の責任者と、残存ログが消える期限を確認する。
• 同じ時間帯の変更申請、障害情報、不審な管理操作、他のアラートを確認する。

Audit Log（監査ログ）は操作を追跡するための記録です。一方、テレメトリには状態や測定値も含まれます。転送エージェントの稼働情報は切り分けの助けになりますが、「エージェントが動いている」だけでは監査イベントが届いた証明にはなりません。

0件の原因を切り分ける順序

NIST SP 800-92は、ログ管理を基盤と運用プロセスの両面から扱っています。実務では、その考え方を「どの段階まで記録を確認できるか」という問いに落とし込むと、担当間で認識をそろえやすくなります。

1. 検索条件・対象・閲覧権限を確認する

対象期間を前後に広げ、不要な絞り込みを外します。UTCとJSTの違い、別テナントや別ワークスペース、利用者名の変更、発生時刻ではなく取り込み時刻を検索している可能性を確認してください。

権限不足の場合は、承認済みの閲覧権限を持つ担当者に同じ条件で確認してもらいます。切り分けのために全員へ管理者権限を付与してはいけません。エラー表示と正常に完了した0件検索も区別します。

2. その操作が記録対象だったかを確認する

監査機能が有効でも、すべての操作が記録されるとは限りません。対象のイベント種別、記録設定、サービスや契約の範囲を確認します。管理操作とデータの閲覧・ダウンロードで記録対象が異なる場合もあります。

もともと記録されていなかった操作を、今から設定を有効にするだけで過去にさかのぼって生成することはできません。設定変更による今後の改善と、過去の調査で使える証跡を分けて扱います。

3. 送信元にはあるが、収集先にないのかを確認する

自社で閲覧できる送信元のログと、SIEMなどの収集先を、同じイベント識別子や対象・時刻で照合します。送信元にある場合は、転送の失敗、認証期限切れ、キューの滞留、容量不足、取り込み制限、形式変更による解析失敗などを確認します。

この段階でコネクタを削除・再作成すると、処理位置や残っていた情報を失う可能性があります。まず状態、エラー、最終成功時刻、未処理データの有無を記録し、復旧操作は担当者と合意して実施します。

4. 検索可能期間と保管先を確認する

検索画面に出る期間と、別のアーカイブに残っている期間は同じとは限りません。サービス側の保持期限、収集先の保存設定、ローテーション、アーカイブやバックアップの有無を確認します。

「古いログはあるはず」と想定して待たず、残存データの有無と取り出せる見込みを担当者・提供元に確認します。保持期限が迫っているなら、その確認と証拠保全を優先します。

5. 記録停止・削除・設定変更の証跡を確認する

監査設定の無効化、保持期間の短縮、転送先や権限の変更があれば、変更申請と実施者を照合します。ログの空白だけで攻撃と断定しませんが、説明できない管理者追加や認証設定変更が同時に起きているなら、通常の障害対応だけで終わらせない判断が必要です。

ASD ACSCとCISAなどの共同ガイダンスは、時刻の整合、ログの保護、適時の取り込みを重視しています。停止原因の確認に使うログ基盤自身の操作記録も、保護対象に含めてください。

判断基準：障害対応か、セキュリティ対応も必要か

次の表は社内で優先順位を相談するための例です。固定の待機時間ではなく、対象の重要性、空白の長さ、他の兆候、証跡の残存期限で判断します。

確認できた状態	優先する対応
不審な権限変更・データ操作とログ停止が重なる	CSIRTや対応責任者へ直ちに連絡。被害を止める判断と証跡保全を並行する
重要な認証・管理操作のログが止まり、理由が不明	優先度の高い監視障害として扱う。運用担当とセキュリティ担当で空白範囲・代替監視を決める
残存ログの削除・上書き期限が迫る	原因調査の完了を待たず、権限のある担当者に保全と取り出しを依頼する
正規の変更による転送遅延で、送信元の記録は残る	遅延量と保管余裕を確認し、合意した復旧期限・連絡先を置く。欠落がないか後で照合する
検索条件や閲覧権限が原因で、必要なイベントを確認できた	条件と確認結果を記録し、依頼元へ回答。記録対象外の期間がないかも確認する

被害が進行している状況で、「証拠を完全に集めるまで封じ込めない」と待つことは避けます。NIST SP 800-61 Rev. 3が扱う組織的な検知・対応・復旧の考え方を踏まえ、サービス責任者と対応責任者が業務影響も含めて判断します。

初動でやること・やらないこと・記録すること

やること：残っている証跡と調査可能な範囲を確保する

取得権限のある担当者が、元のログ、検索条件、関連する設定・変更履歴を保全します。収集先だけに頼らず、IdP、アプリ、端末、ネットワークなど別の観測点で照合できるかを確認します。ただし、認証の成功ログからファイル閲覧の有無まで推測するなど、別のログで分からないことを埋め合わせてはいけません。

ログ原本はアクセスを制限した承認済みの保存先で扱い、共有用の資料と区別します。個人情報や認証情報を含むログを、公開チケットや外部の生成AIへ貼り付けないでください。

やらないこと：証跡や保護を失う変更を急がない

• 証跡の確認前にログ、キュー、収集基盤を一括削除・初期化しない。
• 原因を確かめず、転送の認証や暗号化を無効にして接続を通さない。
• ログに秘密値が含まれる状態で、詳細出力を本番全体へ無制限に広げない。
• 空白を埋めるために攻撃や認証回避を再現しない。
• 「ログが戻ったので被害なし」と結論づけない。

記録すること：調査できない範囲も報告する

チケットには次の項目を転記すると、後続担当が同じ条件で確認できます。認証情報やログ原本そのものは記入しません。

件名：監査ログの欠損・遅延疑い
発見日時／報告者：
対象サービス・環境／ログ種別：
検索期間・タイムゾーン／フィルタ／閲覧ロール：
最後に確認できたイベント発生時刻／到着時刻：
送信元・転送処理・収集先でそれぞれ確認できた状態：
不審な操作・正規の変更申請との関係：
保全した証跡の保管先・取得者・取得条件：
確認できない期間・操作／残存データの保持期限：
実施した変更・実施者・承認者・結果：
次の確認担当者／期限／エスカレーション先：

実務例：転送が戻っても空白期間は別に確認する

以下は架空の例です。あるSaaSの監査ログについて、担当者が09:20 JSTに「SIEMに新着がない」と気づきました。SIEMで最後に見えたイベントの発生時刻は09:00、到着時刻は09:03でした。一方、SaaS側には09:10のイベントが残っています。

ここで言えるのは「少なくとも確認した09:10のイベントは送信元にあるが、収集先では未確認」ということです。09:03を欠損開始時刻と決めたり、09:00以降の全操作が失われたと断定したりはできません。

転送担当がエラーとキューの状態を保全し、承認された復旧操作を行った後、新着が再開したとします。それでも、09:10のイベントが届いたか、ほかに取りこぼしがあるか、重複がないかを照合します。再送できない記録があれば、別途保管した証跡と収集先の空白を明記します。

復旧完了のチェックリスト

• 承認済みの無害な確認操作など、発生が分かるイベントを使い、送信元から検索画面まで追えることを確認する。
• 発生時刻と到着時刻の差が、通常時の基準や合意した許容範囲に戻っていることを確認する。
• 重要フィールド、イベント種別、検索・閲覧権限が復旧していることを確認する。
• 滞留分の処理結果、欠落・重複、復元できない期間を記録する。
• 停止を検知する通知と連絡先を確認し、必要なら承認済みの環境で通知の到達を試す。
• 監視基盤の復旧と、インシデントの影響調査の完了を別々に判断する。

データが少ない夜間や休日は、一定時間0件でも正常な場合があります。件数だけの停止通知ではなく、通常の発生頻度、収集処理の状態、重要イベントの到達を組み合わせる設計にします。

よくある誤解

ログがないなら被害もない？

いいえ。正しく観測できていなければ、被害の有無は判断できません。「確認した範囲で痕跡がない」と「調査する記録がない」は、報告書でも分けてください。

監査機能を有効にすれば過去のログも戻る？

記録されていなかった過去のイベントは、その設定だけでは生成できません。すでに記録されていて、アーカイブや送信元に残るデータなら取り出せる可能性があります。提供元と保存設計を確認します。

SIEMを入れていれば欠損には気づける？

自動的にすべて検知できるとは限りません。収集対象、停止監視、通知先、遅延の基準を決め、検索まで含めて確認する必要があります。SIEMと対応自動化の役割分担は、SIEMとSOARの違いも参照してください。

関連用語・次に読むページ

• 基本を押さえる：Audit Log、Log Retention、時刻同期。
• 残す期間を設計する：監査ログの保管期間。本記事は「見つからない時の切り分け」、こちらは「事前の保存設計」を扱います。
• 記録を読み解く：セキュリティログの読み方、SIEMとログ管理。
• 権限変更が疑わしい：SaaS権限棚卸しチェックリスト。
• 漏えいの兆候もある：漏えい疑い初動テンプレート。ログ欠損だけで漏えいと断定せず、確認済みの事実と不明点を整理します。
• 安全に練習する：アクセスログトリアージCTF、用語クイズ。演習は学習用データで行い、本番で攻撃を再現しません。

公式情報・参考情報

以下はいずれも2026年5月18日以前に公開された資料です。実際の閲覧・確認日は2026年9月14日です。製品ごとの最新仕様や法的な保存義務を一律に示すものではありません。

1. NIST SP 800-92：Guide to Computer Security Log Management — 2006年9月の確定版。ログ管理基盤・運用プロセスの基本。Rev. 1のドラフトとは区別して参照しています。
2. ASD ACSC・CISA等：Best practices for event logging and threat detection — 2024年8月22日公開・更新。時刻の整合、保護、集約、取り込み遅延の考え方。
3. NIST SP 800-61 Rev. 3：Incident Response Recommendations and Considerations — 2025年4月の確定版。組織的な検知・対応・復旧をリスク管理へ組み込むための資料。