Moshiru
会社情報記事一覧無料スキャン

会社のセキュリティ教科書　第9部 9-3

インシデントの原因調査とは｜ログとアクセス記録の読み方と復旧の順番

公開：2026年10月15日／最終更新：同／Moshiru 岡﨑 悠太

こんなときに役立ちます

  • 何が原因で、どこまで被害が広がったかを調べるとき
  • 不正アクセスの初動を終え、ログを見て「入口」と「範囲」を確かめたいとき
  • どこまで社内で調べ、どこから専門家に頼むかを決めたいとき

読み終えたあと、社内でこう言えます

「事故のときにログを残す手順と調べる4つの点を、1枚にまとめておきました」

結論：インシデントの原因調査とは、ログなどの記録から、何が起きたかと根本の原因を確かめる作業です。調べることは「どこから入ったか」「どこまで広がったか」「何を持ち出されたか」「何が残っているか」の4つです。進め方は、ログを消える前に保全し、時刻をそろえてタイムライン（時系列の表）を作ることが基本です。復旧は、入口をふさぎ、戻す元のバックアップが無事かを確かめてから始めます。

原因調査は、ログを保全し、時刻をそろえてタイムラインを作り、入口・広がり・持ち出し・残りの4つを確かめてから復旧する

インシデントの原因調査とは？4つの問いで考える

インシデントとは、情報漏えいや不正アクセス、ウイルス感染など、セキュリティを損なう出来事のことです。最初の1時間の動き（切り離す・残す・知らせる）は不正アクセスされた会社が最初の1時間でやることにまとめています。この節は、そのあとの「調べる」と「戻す」を扱います。

米国立標準技術研究所（NIST）は、サイバーセキュリティフレームワーク（CSF）2.0を出しています。CSF 2.0は、調査で「何が起きたか」と「根本の原因」を確かめるよう求めています。会社の言葉にすると、次の4つの問いになります。

問い確かめること主に見る記録
どこから入ったか（入口）最初に破られた所。VPN、メール、公開サーバーなどVPNやクラウドの認証ログ、メールの受信履歴
どこまで広がったか（範囲）ほかのパソコンやアカウントに移ったかWindowsのログオン記録、管理者アカウントの操作
何を持ち出されたか（漏えい）開かれたファイル、外へ送られたデータファイルサーバーのアクセス記録、通信ログ
何が残っているか（残存）攻撃者が作ったアカウントや設定、不審なプログラムアカウント一覧、メールの転送設定、ウイルス対策の検知記録

4つのうち1つでも分からないまま戻すと、同じ入口から再び入られるおそれがあります。個人情報の漏えいでは、個人情報保護委員会への報告に「原因」と「本人の数」も書きます。範囲の調査は、報告の中身にも直結します。

どのログを見ればいい？主な記録と分かること

ログとは、機器やサービスが自動で残す操作や通信の記録です。中小企業でよく使う仕組みごとに、どんな記録があるかを並べます。

記録分かること注意点
VPN機器・クラウドの認証ログ誰が、いつ、どこからログインしたか。失敗の回数機器の中だけに置くと、容量で上書きされる
Windowsのイベントログログオンの成功（4624）と失敗（4625）、接続元パソコンごとに記録されるため、集める手間がいる
ファイルサーバー・NASのアクセス記録どのファイルを、誰が開いた・消したか記録の設定を有効にしていないと残らない
ファイアウォール・UTMの通信ログ社内から外へ、どこに、どれだけ送ったか保存期間が短い機種が多い
メールの送受信履歴・転送設定不審なメールの受信、勝手な自動転送転送設定は「ログ」でなく設定画面で見る
ウイルス対策・EDRの検知記録どの端末で、何を、いつ検知したか管理画面の保存期間を確かめる
AWSのCloudTrailAWS上の操作（誰が何を設定したか）イベント履歴は過去90日分。長く残すには証跡をS3に保存

UTMは、ファイアウォールやウイルス検査を1台にまとめた機器です。EDRは、パソコンの不審な動きを記録して検知する仕組みです（EDRとMDMの節）。サービスごとの保存期間はログの保管期間の手引きで確かめてください。

IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版（2026年3月）も、ログは一定期間で自動削除される設定が一般的だと注意しています。事故に気づいたら、まず消える前にコピーを取ることが最優先です。

ログはどう読む？時刻をそろえてタイムラインを作る

ログは1つだけ見ても全体が分かりません。複数の記録を時刻順に並べ、1本のタイムラインにすると流れが見えてきます。手順は次のとおりです。

  1. 保全する：ログを書き出し、上書きされない場所に複製します。いつ、誰が、どこから取ったかをメモに残します。
  2. 時刻をそろえる：ログが日本時間か、協定世界時（UTC）かを確かめます。日本時間はUTCより9時間進んでいます。
  3. 起点を決める：最初に気づいた出来事（不審なメール、検知の通知など）の時刻を起点にします。
  4. 前後に広げる：起点より前に入口がないか、後に広がりがないかを、ほかのログで探します。
  5. 表にまとめる：「時刻・記録の出どころ・何が起きたか・確からしさ」の4列で1行ずつ書きます。

読むときは、ふだんと違う点に印をつけます。見つけたいのは、次のような「いつもと違う」動きです。

証拠として残す：揮発性の順序と保管の記録

訴訟や警察への相談に備えるなら、記録を「証拠」として扱います。インターネットの標準文書RFC 3227（2002年2月）は、消えやすいものから先に集める「揮発性の順序」を示しています。

消えやすさ例
とても消えやすいメモリ（実行中のプログラム、通信の状態）。電源を切ると消える
消えやすい一時ファイル
比較的残るディスク、離れた場所に送ったログ
長く残るネットワークの構成、保管用の媒体（バックアップなど）

被害にあった機器の電源を切らないのは、このメモリの情報を残すためです。また、証拠を誰がいつ受け取り、どう保管したかを記録します。これを保管の連鎖（チェーン・オブ・カストディ）と呼びます。メモリの取得などは専門の作業です。頼むかどうかの判断はフォレンジック調査の費用相場を参考にしてください。

たとえば社員30人の卸売業では（架空の例）

総務の1人が情報システムを兼務する、社員30人の卸売業を考えます。取引先から「御社の経理担当から、振込先変更の不審なメールが来た」と連絡がありました。メールはクラウドのサービスを使っています。

総務の担当者が、メールの管理画面と認証ログを書き出して作ったタイムラインが次の表です。ログはUTCだったため、日本時間に直しています。

日本時間記録分かったこと
3日 9:12メール受信履歴経理担当が「請求書の確認」という偽のメールを受信
3日 9:20認証ログ経理担当のアカウントに、海外の接続元からログイン成功
3日 9:25メールの設定「振込」を含むメールを外部へ転送するルールが追加
5日 14:03送信履歴経理担当の名前で、取引先へ振込先変更のメールを送信

入口は偽のメールから入力されたパスワード、範囲は経理担当の1アカウントと分かります。持ち出しは「転送されたメール」、残りは「転送ルール」です。この4つがそろって初めて、ルールの削除やパスワードの変更で戻せると判断できます。具体的な止め方はMicrosoft 365の乗っ取りの手引きにあります。

復旧はどの順番で進める？入口をふさいでから戻す

NIST CSF 2.0は、復旧に使う前にバックアップが無事かを確かめること、復旧後に正常に動くかを確かめることを求めています。中小企業向けに順番を並べると、次のとおりです。

  1. 封じ込めを確かめる：切り離した機器や止めたアカウントが、まだ外とつながっていないかを見ます。
  2. 原因を取り除く：パスワードを変え、ログイン中のセッションを切り、攻撃者が作った設定やアカウントを消します。弱点の修正（更新の適用など）もここで行います。
  3. 戻す元を確かめる：バックアップが暗号化や改ざんを受けていないか、いつの時点のものかを確かめます。
  4. 大事な業務から戻す：受注や請求など、止まると困る業務の仕組みを先に戻します（BCPとBIAの節）。
  5. 見張りを強めて様子を見る：戻したあとしばらくは、ログを毎日確認し、同じ動きが出ないかを見ます。
  6. 終わりを決めて記録する：何をもって復旧とするかを決め、調査と対応の記録をまとめます。

戻し方には、いくつかの選び方があります。

戻し方向いている場面気をつけること
バックアップから戻すデータやサーバーが暗号化・改ざんされた侵入より前の時点か。戻した後に弱点が残っていないか
初期化して作り直す不審なプログラムが残っている、範囲が読み切れない時間はかかるが、残存を断ちやすい
設定を直して使い続けるアカウントの乗っ取りだけで、端末に異常がない4つの問いに答えが出ている場合に限る

原因が分かったら、同じことを起こさない手当てに進みます。書き方は次の節の再発防止策の書き方で扱います。社内で調べきれないときの相談先はインシデントの相談先にまとめています。

チェックシートではこう聞かれる

よくある設問答え方の例
インシデント発生時に、原因と影響範囲を調査できるだけのログを取得・保管していますか。はい。VPNとメールの認証ログ、ファイルサーバーのアクセス記録を1年間、別の場所に保管しています。
機器の時刻を同期していますか。はい。社内の機器は時刻サーバーと自動で同期しています。クラウドのログの時刻はUTCと把握しています。
証拠保全の手順を定めていますか。一部。電源を切らずに切り離す、ログを複製する手順はあります。メモリの取得は外部の専門事業者に頼む前提です。
復旧前に、原因の除去と復旧データの健全性を確認していますか。いいえ。現在は手順がなく、〇月までに復旧手順書へ確認の項目を加える予定です。

保管期間を書くときは、実際の設定画面で確かめた数字を使ってください。「いいえ」の項目は、予定と代わりの対策を添えると誠実な回答になります。

試験ではここが問われる

SG・支援士・Security+ 4・AWS 2・CISSP 7

  • 揮発性の順序：メモリ → 一時ファイル → ディスク → 離れた所のログ → 保管媒体の順に集めます。「消えやすいものから」が原則です。
  • 証拠保全：原本ではなく複製を調べ、ハッシュ値で同じであることを示します。受け渡しの記録が保管の連鎖（Chain of Custody）です。
  • 時刻同期：NTP（時刻を合わせる仕組み）で機器の時刻をそろえないと、ログを突き合わせられません。UTCと現地時刻の差も記録します。
  • ログの集約：SIEM（ログを集めて関連づけて分析する仕組み）は、複数の記録をまとめて相関分析するために使います。ログの改ざん防止も問われます。
  • AWS：CloudTrailのイベント履歴は過去90日の管理イベント。長期保管は証跡をS3へ。根本原因の調査にはAmazon Detectiveが挙がります。

確認問題

問1 被害にあったサーバーから証拠を集めます。揮発性の順序に従うとき、最初に集めるべきものはどれですか。

  1. ア バックアップ用の外付けディスク
  2. イ サーバーのディスクの内容
  3. ウ 実行中のメモリの内容
  4. エ ネットワークの構成図
答えと解説
正解：ウ　メモリは電源が切れると消えるため、最も先に集めます。ディスク（イ）はその次、構成図（エ）やバックアップ媒体（ア）は長く残るため後回しにできます。

問2 社員20人の会計事務所（架空）で、クラウドのメールの認証ログに「01:40」の不審なログインがありました。ログはUTCで記録されています。日本時間で何時の出来事ですか。

  1. ア 前日の16:40
  2. イ 同じ日の01:40
  3. ウ 同じ日の10:40
  4. エ 同じ日の17:40
答えと解説
正解：ウ　日本時間はUTCより9時間進んでいるので、10:40です。業務時間内のログインに見えるため、接続元など別の手がかりと合わせて判断します。アは9時間を引いた誤りです。

問3 ランサムウェアでファイルサーバーが暗号化されました。バックアップから戻す前に行うこととして、最も適切なものはどれですか。

  1. ア 社員全員に、すぐ通常業務に戻るよう伝える
  2. イ 侵入の入口をふさぎ、バックアップが侵入前の無事なものかを確かめる
  3. ウ 調査の手間を省くため、ログをすべて削除する
  4. エ 最新のバックアップを、確かめずにすぐ戻す
答えと解説
正解：イ　入口が開いたまま戻すと、再び暗号化されるおそれがあります。最新のバックアップが感染後のものである場合もあるため、時点と状態の確認が要ります。ウは原因調査の手がかりを失います。

よくある質問

ログがほとんど残っていない場合、原因調査はできませんか？
できる範囲は狭くなりますが、調査は可能です。メールの受信履歴や、クラウドの管理画面の記録など、別の場所に残る記録から入口を推測します。JPCERT/CCも、ログが使えない場合は影響範囲から入口の候補を推測し、優先して調べる方法を示しています。
原因調査は社内でやるべきですか、専門家に頼むべきですか？
アカウント1つの乗っ取りのように範囲が限られるなら、社内で調べられることが多いです。サーバーへの侵入や大量の個人情報の漏えいが疑われる、訴訟になりそうな場合は、専門家に頼む方が確実です。判断の目安はフォレンジック調査の費用相場にまとめています。
原因が分からないまま、業務を再開してもよいですか？
おすすめしません。入口が分からないまま戻すと、同じ方法で再び入られるおそれがあります。急ぐ場合は、切り離した別の環境で大事な業務だけを動かし、調査と並行して進めます。

この記事のまとめ

ログの見立てを受け取り、判断を一人で抱えない

Moshiruは、打合せなしでテキストだけでお受けします。インシデントが起きたときは、手元のログや画面の写しをお送りください。入口と範囲の見立て、復旧の順番、専門家に頼むべきかの判断を文面でお返しします。

インシデントが起きたら相談する24時間受付・30分以内に返信メニューにないことを頼む文面で合意するまで料金はかかりません

参考にした資料

  1. NIST「The NIST Cybersecurity Framework (CSF) 2.0」CSWP 29（2024年2月）RS.AN・RC.RP
  2. NIST「SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management」（2025年4月）
  3. IETF「RFC 3227 Guidelines for Evidence Collection and Archiving」（2002年2月）
  4. IPA「中小企業のためのセキュリティインシデント対応の手引き」（2026年6月）
  5. IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版（2026年3月）
  6. JPCERT/CC「侵入型ランサムウェア攻撃を受けたら読むFAQ」（2026年6月更新）
  7. Microsoft Learn「4625(F): アカウントのログオンに失敗しました」
  8. AWS「Working with CloudTrail event history」（AWS CloudTrail User Guide）
  9. AWS「AWS Certified Security - Specialty (SCS-C03) Content Domain 2: Incident Response」
  10. 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」3-5（2026年6月一部改正）