メインコンテンツへスキップ
       

情報漏えいのフォレンジック報告書をどう読むか―調査範囲,ログ欠落及び「痕跡なし」の限界(AI作成)

第1 報告書の結論と調査の限界を一緒に読む

1 対象と結論

サイバー事故の調査報告書に「情報の持出しは確認されなかった」と記載されていても,その一文だけで漏えいがなかったとは判断できない。
どの機器・サービスを,どの期間のどの記録で調べ,何が確認できずに残ったのかを併せて読む必要がある。
逆に,ログが不足していることだけで漏えいが実際に起きたと断定することもできない。

本記事は,企業の法務担当者,顧問弁護士及び法律・税理士事務所が,調査会社又はクラウド事業者の報告を受け取る場面を扱う。
個人情報保護委員会が関係機関と開催する個人情報保護法サイバーセキュリティ連絡会がまとめた「不正アクセス発生時のフォレンジック調査の有効活用に向けた着眼点」を中心に,報告書への質問と法的判断へのつなぎ方を整理する。
制度の整理の基準日は令和8年10月13日であり,GMOの公表事例に関する今回の追補の基準日は同月30日である。
また,以下の質問表は法定の様式ではなく,事案に応じて使う運用上の提案である。

2 フォレンジック調査と法的判断の役割

フォレンジック調査は,端末,サーバー,ログ等を保全・解析して,侵入経路や影響を調べるための技術的な調査である。
調査の結論と,個人情報保護法上の報告対象事態への該当性,契約違反,過失,損害及び懲戒等の判断は区別する。
技術的な評価語が,そのまま法律上の要件を満たすとの意味で使われているかも確認する必要がある。

第2 調査対象と対象外の理由を確かめる

1 機器名だけでなく業務上の役割を見る

報告書を読む担当者は,調査対象の端末・サーバー・クラウドを,業務上のデータの流れと対応付ける。
ファイルサーバーを調べても,メール,バックアップ,共有リンク,管理用アカウント又は別のクラウドが対象外であれば,その領域の影響まで調査済みとはいえない。
機器が多いという理由で全てを同じ深さで調べる必要があるとは限らないが,対象を絞った理由と,そこから説明できる範囲は必要である。

2 除外理由と未調査の範囲を残す

PPC資料31・32頁は,対象機器や保全データの詳細に加え,調査対象として選定した理由及び選定しなかった理由を明らかにすることを勧めている。
費用,ログ不足又は簡易調査の結果に基づき対象を絞った場合にも,調査範囲と被害が生じ得る範囲が同じとは限らない。
調査依頼時と結果受領時に,対象の追加・変更とその理由を記録すると,後日の説明に役立つ。

確認事項調査担当者へ求める説明
対象の同定機器・サービス・アカウントの識別情報,業務上の役割,保存されるデータ。
対象外除外した機器・サービスと理由。他の記録で影響を確認したか。
調査期間想定する侵入期間と,実際に調べられる期間の差。
根拠資料使用したログ・保全イメージの一覧,取得日時,取得者及び同一性の確認。
追加調査結論が変わり得る未取得資料,取得可能性,保存期限及び担当者。

第3 ログの有無,期間及び偏りを点検する

1 取得できたログと失われたログ

PPC資料33頁は,調査の前提となったログの詳細と,重要なログを保存していなかった又は消失していた事情を明らかにすることを勧めている。
接続成功だけを記録するログ,操作を記録しないサービス,暗号化されて読めないログ,攻撃者が削除したログは,それぞれ説明できる内容が異なる。
報告書の「ログなし」を,保存設定なし,保存期限切れ,消去,取得不能又は対象外に分けて確認する。

半田病院が公表した調査報告書の3.4.3.1(PDF実頁19頁・紙面16頁)は,VPN装置の脆弱性や資格情報に関する事情等を踏まえ,そのネットワークを悪用した侵入の可能性が極めて高いと評価している。
一方で,侵入経路を証明するためログ分析を試みたものの,事故後にログ保存を考慮しないファームウェア更新等が行われ,その調査を実施できなかったとも記載している。

この事例では,侵入経路についての技術的な評価と,ログによる検証の限界を併せて読む必要がある。
調査報告書の評価を,裁判所が認定した事実又は個別の保守事業者の損害賠償責任に置き換えてはならない。
被害拡大の防止と並行して,更新・再起動・初期化の前にどの記録を保全するかを,保守事業者と調査担当者が調整することが実務上の教訓となる。

2 直近のログから過去全体を推定しない

例えば,直近90日のログを確認した結果に痕跡がなかったとしても,それ以前の記録がなければ,過去3年間の侵入不存在まで説明したことにはならない。
この例は調査範囲の限界を示す仮定であり,特定の企業又はサービスの被害を認定するものではない。
時刻がUTCか日本時間か,機器の時計にずれがないかも確認し,記録間の時系列を合わせる。

ログの保存は事故後に始めても,過去に取得されなかった記録を作り出すことはできない。
PPC資料14頁は,調査に必要なログを少なくとも1年程度保管することが望ましいとするが,一律の法定義務を定めたものではなく,法令上許容される範囲を超える保存を推奨するものでもない。
平時の保存・分析の設計は,個人情報保護委員会が示した不正アクセス9類型を参照されたい。

長期潜伏は,単なる仮定にとどまらない。
米国等の関係機関による令和6年2月の共同注意喚起は,Volt Typhoonについて,一部の被害組織のIT環境で少なくとも5年間アクセスを維持していたことを示す兆候を確認したとしている。
ただし,これは特定の被害組織についての観測であり,5年間何も活動していなかったという意味でも,全ての侵害が5年間続くという意味でもない。

報告書を読む際には,侵入した可能性のある時期と,実際に確認できたログの期間を別々に示してもらうとよい。
期間外を「侵害なし」と扱わず,認証情報,管理用アカウント及び侵入後に残されたアクセス手段について,確認済みの範囲と未確認の範囲を区別する。
これは調査の説明を受けるための提案であり,上記注意喚起が日本の全企業に5年間のログ保存を義務付けたという趣旨ではない。

出典:豪州サイバーセキュリティセンター掲載の共同注意喚起(令和6年2月8日)のSummary及びOverview。

第4 閲覧,取得及び外部送信を分けて評価する

1 確認された事象と技術上の可能性

報告書に「攻撃が1万件あった」とある場合は,何を1件と数え,どの段階まで確認したのかを質問する。
次の区分は調査内容を確認するための整理であり,各段階が必ずこの順序で記録されることや,特定の法的評価を示すものではない。

観測した事象報告書で確かめること
接続・探索の試行対象のIPアドレス・ポート,記録期間及び応答の有無。侵入成功の件数と同一視しない。
認証の試行入力された認証情報の試行か,認証の成功を確認したか。失敗した試行と成功を分ける。
認証成功・セッション誰の権限が使われ,どの機器・資源に到達できたか。個別ファイルの閲覧とは別に確認する。
コマンド・操作実行した操作と結果,設定変更,マルウェア等の痕跡。ログの欠落や記録対象外も確認する。
閲覧・取得・外部送信対象データと操作を対応付け,可能性と実際の記録を分ける。外部送信の記録の有無だけで閲覧を判断しない。

例えばSophosの2019年の調査は,AWS上の10か所のSSHハニーポットに対するログイン試行を観測したものである。
その初回試行までの時間を,家庭や事務所のあらゆる機器が侵入されるまでの時間に置き換えることはできない。

不正なログイン,個別ファイルへのアクセス,圧縮・複製又は外部との通信は,相互に関連し得るが,同じ事実ではない。
PPC資料38頁は,外部送信の可能性と閲覧の可能性という二つの経路から,漏えいの可能性の有無・程度を評価する視点を示している。
悪用された権限で何にアクセスできたか,実際にどの記録が残っているか,ログ消去が評価にどう影響するかを確認する。

外部送信の明確な記録がないことだけで,不正な閲覧の可能性まで否定しない。
反対に,技術的にアクセスできる設定だったことを,直ちに全ファイルが閲覧・取得されたという事実に置き換えない。
対象データの一覧と,確認済みの操作を対応付ける必要がある。

持出しの形跡が見つからないことと,情報が外部に出ていないことも別の事柄である。
株式会社東北新社と株式会社オムニバス・ジャパンの令和8年6月4日の第六報は,不正アクセスの対象となったサーバーのうち1台について,ファイルが外部に持ち出された形跡は確認されなかったものの,そのサーバーに保存されていたファイルと同一のファイルがリークサイト上に公開されていることを確認したと説明している。
政府の「サイバー攻撃被害に係る情報の共有・公表ガイダンス」(令和5年3月8日)も,通信ログの保存期間の不足や攻撃者による痕跡の消去によって,どの情報が閲覧・窃取されたかを追跡できないケースが多いとしている(印刷43頁)。
報告書の「形跡なし」を公表文に書くときの注意は,「現時点で漏えいの事実は確認されていない」と公表してよいか―調査段階・ログの有無で変わる書き方と個人情報保護法の「おそれ」で整理している。

ソフトウェアの脆弱性が問題となる場合には,脆弱な版を使用していたこと,攻撃を試みられたこと,攻撃が成功したこと,及び個人データが閲覧・取得・外部送信されたことを区別する。
修正済みの現在の環境だけでなく,問題となる期間の版・実行方式・設定,修正の適用時刻,ベンダー独自修正の有無と根拠資料を調査担当者に確認する。
PHP公式の脆弱性報告も,実行方式等に応じて,攻撃を実証した範囲と解析による影響評価を区別しており,一般的な技術上の危険と個別事故の事実認定を分けて読む必要がある。
出典:php/php-src「RCE via OOM corruption」及び「RCE via stale global state」。
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

外部の流出データに見付かったことと,今回のシステムから漏えいしたことは分ける。
外部から入手したメールアドレス,パスワード又は認証情報の一覧については,取得元,収集・公表・登録の日時,元の事故が起きたとされる時期,重複除去及び他のデータとの結合方法を確認する。
一覧への追加日を,そのまま漏えい発生日と扱わない。

Have I Been Pwned運営者の令和7年11月5日の説明(https://www.troyhunt.com/2-billion-email-addresses-were-exposed-and-we-indexed-them-all-in-have-i-been-pwned/)は,複数の情報源を集めたデータについて,過去のパスワードが含まれ,利用者が自分のものと認識しないパスワードもあり得ることを説明している。
同説明は運営者による検証・処理の説明であり,収録された全ての組合せの正確性を第三者が監査したとの意味ではない。
パスワード文字列だけの一致から,その値を使った本人やサービスを特定することもできない。

個別事故への帰属は,顧客・依頼者の登録履歴,対象サービスの公表,保全した認証・操作・通信のログ等と突き合わせて判断する。
データの偏りや規則的な文字列の多さだけで,ボットによる登録,攻撃主体又は侵入経路まで認定しない。
外部照合の結果を,確認済み事実,提供者の説明,推測及び不明事項に分けることが実務上の提案である。

「お名前.com デスクトップクラウド」の公表を読む場合にも,クラウド環境と利用者の手元のPCを別の調査対象として扱う必要がある。
GMOインターネットは第2報で悪意あるプログラムの検出を説明した一方,第14報では,預かった利用者端末の解析を進め,マルウェアやランサムウェアの痕跡が確認されていないと説明している。

この二つは対象と調査範囲が異なり,直ちに矛盾する説明ではない。
そこで,上記の対象範囲・記録・期間の確認を,クラウド側と利用者端末側の双方について行う。

仮にリモート接続でドライブを共有できる設定であったとしても,実際にその経路でファイルが取得されたかは別に確認する必要がある。
MicrosoftのRDP設定資料は,ドライブのリダイレクトを設定できることを示しているが,その一般的な機能説明は,今回の侵入経路や個別PCからの取得を証明する資料ではない。
接続方式・クライアント・有効だった設定・アクセス権限・操作の記録を対応付けて確認するというのが,ここでの実務上の提案である。

出典:GMOインターネット第2報及び第14報,Microsoft LearnサポートされているRDPプロパティのdrivestoredirectの説明。
刑事責任は,技術上の呼称と犯罪の成立要件を分けて,GMOサイバー攻撃は何罪かで検討している。

2 対外説明は根拠と留保を合わせる

次の表は,断定の範囲を点検するための記載例である。
実際の文案は,調査結果,法律上の報告要件及び本人が取るべき行動に合わせて作成する。

報告書の記載追加確認と説明の方向
持出しの痕跡なし対象ログ,対象期間及び対象データを明記し,調査対象外や未判明事項を残す。
ファイルにアクセス可能権限・設定による可能性か,実際のアクセス記録があるかを分ける。
漏えいの可能性を否定できない可能性を支える事情,確認不能の理由及び対象範囲を具体化する。単なる一般的不安と区別する。
侵入経路を推定確認済み事象と推測の根拠を分け,矛盾する記録と別の経路の可能性も確認する。

第5 調査完了を待たず報告対象と期限を検討する

1 個人データと報告対象事態への当てはめ

民間事業者については,個人情報保護法26条及び施行規則7条により,要配慮個人情報,財産的被害のおそれ,不正目的の行為又は本人の数1000人超という各類型を確認する。
漏えい等が発生した場合だけでなく,発生したおそれがある場合も対象となる。
ログ欠落という事情は判断材料の一つであり,それだけで全ての事案を報告対象にするものではない。
高度な暗号化等の措置による除外を含め,各号の要件を具体的なデータと事実に当てはめる。
第3号では,個人データとして取り扱われることが予定されている取得済み又は取得予定の個人情報も含まれるため,個人データを既に保存したサーバーの侵害だけに限定しない。

侵害された環境にどの個人データがあったか,どの権限が悪用され,どの操作が可能又は確認済みかを,調査担当者と法務担当者が対応付ける。
漏えいの有無に加え,滅失・毀損も別に確認し,復旧できたことだけで報告の検討を終了しない。
クラウド利用者と事業者の義務主体は,クラウド事業者がランサムウェア被害を受けたときの利用者の報告義務で整理している。

2 速報,確報及び本人通知

通則編3-5-3は,報告対象事態を知った後の速報を速やかに行い,その目安を概ね3~5日以内とする。
法人では,いずれかの部署が当該事態を知った時点を基準とし,経営者への報告日や調査報告書の完成日まで起算点を遅らせない。
速報はその時点で把握している内容を報告すれば足りるため,未知の事項を確認済みと装う必要はない。

確報は原則30日以内,不正目的の行為による事態は60日以内であり,知った時点を1日目とする。
合理的努力を尽くしても一部が判明しない場合は,期限内に把握した内容を報告し,判明次第追完する。
本人通知は確報と同じ固定期限ではなく,状況に応じて速やかに行う必要があるため,調査の進行とは別に判断する。

第6 調査会社・クラウド事業者への質問を記録にする

1 回答の根拠,担当及び更新を残す

依頼元の担当者は,質問,回答者,回答日時,根拠資料及び回答の対象範囲を一つの記録にまとめるとよい。
未判明事項については,追加取得の担当,ログの保存期限,次回回答予定及び法定報告への影響を記録する。
保存期限が迫る資料は,最終報告書の完成を待たず,権限と保全方法を調整して保存を依頼する。

脆弱性対応を含む回答では,脆弱性の公表,修正の提供,対象環境への適用,攻撃の観測及び影響確認の日時を分け,それぞれの根拠資料を求めるとよい。
「更新済み」という回答を,更新前の侵害がなかったとの回答へ読み替えず,未調査の期間や対象を残す。

法律事務所では事件・依頼者ごと,税理士事務所では顧客・データ区分ごとに,影響を判断した根拠を対応付ける。
提供者全体の公表件数やアカウント数を,個々の依頼者・顧客の漏えい確定人数に置き換えない。
調査資料の受渡しは必要な範囲と権限を確認し,保全用データと解析用複製の関係を記録する。

接続元IPアドレスの国・地域と,実際の操作者の所在・身元を分けて説明する。
Sophosの同調査も,IPアドレスの国・地域から実際の攻撃者の所在は分からないと留保している。
調査担当者には,IPアドレスの割当時点,時刻・タイムゾーン,認証・操作の記録及び中継の可能性を含め,誰の行為と評価する根拠を確認する。
国・地域の集計や回線の名義だけで,特定人の実行行為や責任を断定しない。

外部の流出データを根拠とする回答には,①取得元と取得日時,②元データと加工後データの関係,③対象アカウントと結び付けた根拠,④事故時期と一覧への追加時期の区別,⑤重複・混在・誤対応の確認方法,⑥内部ログと整合する点・矛盾する点を追加で質問するとよい。
照会のために他の顧客の情報や使用中の秘密情報まで一括送信せず,調査目的と受領権限に応じた範囲を定める。

「AIを使った攻撃」と説明された場合には,①利用を直接裏付ける記録はあるか,②挙動からの推定ならどの事実を根拠とするか,③AIを使わない自動化など別の説明とどう区別したか,④確認できない範囲はどこかを質問するとよい。
国家サイバー統括室掲載のIPA担当者のコラムは,攻撃の様子だけからAIとの関わりを判別できないのが通例であると説明している。
大量又は高速のアクセスだけでAI利用を認定せず,影響するデータや操作について確認できた事実とも分けて記録することが,報告書を評価する際の実務上の提案である。
出典:https://security-portal.cyber.go.jp/cybersecuritymonth/2026/column/c04.html

事故後の作業についても,誰が,いつ,何の目的で,更新・再起動・初期化又はログ設定の変更をしたかを質問するとよい。
作業前のメモリ,ディスク,機器内外のログを保全したか,保全できなかった理由は何か,外部転送ログや他の機器の記録で補えるかを確認し,その結果を侵入経路や影響範囲の評価へ反映する。
保全のために被害拡大防止を調査完了まで遅らせるのではなく,隔離その他の操作と証拠への影響を記録する。

ARTEXなどのツールが報告に登場した場合は,①ツール又は設定ファイルの存在,②対象に対する実行記録,③認証・権限変更等の成功,④データの閲覧・取得・外部送信を,別々の確認事項として尋ねるとよい。
攻撃側の作業履歴だけから,対象側で各処理が成功したことや全被害範囲まで一律に認定しない。
これは,観測資料と処理結果を対応付けて読むための実務上の提案である。

Microsoftの令和8年10月21日のConnectWise関係の報告も,影響するアプリの存在や認証成功だけで,顧客データへのアクセス・外部送信があったとは限らないと説明している。
利用者のサインインだけでなく,サービスプリンシパルのサインイン,アプリ資格情報・権限の変更及び対象サービス側の記録について,取得した範囲と未取得の範囲を確認する。
エンタープライズアプリの削除を急いで設定等の証拠を失わないようにしつつ,緊急の封じ込めを遅らせないことも必要である。

原資料:https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/
具体的な点検事項は,Microsoft 365の外部アプリ権限と情報漏えい―ConnectWise事案から学ぶ点検事項を参照されたい。

2 専門会社への依頼と再調査の必要性

PPC資料7・8頁は,必要な調査を自ら実施することが困難な場合には専門会社の活用が有用であるとし,法令に基づく報告の場面でも,専門会社によるフォレンジック調査が義務付けられているものではないと説明している。
全ての事案で専門会社への依頼が一律に必要となるわけではない。
重要な環境が対象外,ログ消去が疑われる,調査の結論とデータ一覧が対応しない,又は説明が更新されない場合には,追加調査や独立した専門家への相談を検討する。

費用の回収可能性や責任制限条項の適用は,調査の必要性とは別に,契約と個別事実から判断する。
報告書の不足だけから,調査会社又は委託先の賠償責任が直ちに成立するとはいえない。

復旧や修正の完了と,侵害の調査・排除の完了も区別したい。
警察庁・内閣サイバーセキュリティセンターの令和7年1月8日付MirrorFaceに関する注意喚起は,侵害されたネットワーク機器では,脆弱性を修正してもバックドアが残る場合があることや,ウイルス対策ソフトによる検知・駆除だけでは完全な排除にならない可能性を説明している(5~6頁)。

そこで,調査会社には,修正・駆除の対象,侵入後に追加されたアクセス手段,調査した期間及び再侵入を防ぐ措置を分けて確認することが考えられる。
同注意喚起の機器交換等の記述は侵害された機器への対処の文脈にあるため,全ての端末を一律に交換する義務として一般化しない。

出典:警察庁・内閣サイバーセキュリティセンターによるMirrorFaceに関する注意喚起5~6頁。

第7 関連する実務と出典

1 関連する実務

PHPの緊急セキュリティ更新とWordPress保守―法律・税理士事務所の確認,バックアップ,互換性試験及び復旧手順(AI作成)

解析前のデータ取得と同一性の記録は,デジタル証拠の原本保全とハッシュ値を参照されたい。
事故当日の隔離・保全・期限確認は,法律事務所のサイバー事故初動チェックリスト,委託元の対応は,外部委託先で個人情報が漏えいした場合の委託元の対応で扱っている。

広く弱点を探す攻撃と個別のシステムを狙う攻撃の関係,AIによる効率化及び企業の対策は,AIを悪用した無差別サイバー攻撃とは―仕組みと企業の対策(AI作成)で整理している。

2 出典

①個人情報保護法サイバーセキュリティ連絡会「不正アクセス発生時のフォレンジック調査の有効活用に向けた着眼点」(令和8年1月16日,個人情報保護委員会ウェブサイト掲載)7・8・14・30~39頁。
https://www.ppc.go.jp/files/pdf/260116_forensics_keypoints.pdf

②個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」3-5-1,3-5-2,3-5-3及び3-5-4。
https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

③e-Gov法令検索「個人情報の保護に関する法律」23・25・26条及び同法施行規則7~10条。
https://laws.e-gov.go.jp/law/415AC0000000057
https://laws.e-gov.go.jp/law/428M60020000003

④Sophos「Exposed: Cyberattacks on Cloud Honeypots」(2019年)3・4頁。
AWS上のSSHハニーポットの観測条件,ログイン試行及び接続元IPアドレスの国・地域に関する留保を確認した。
https://assets.sophos.com/X24WTUEQ/at/rgbjvgnx6qwwj7wvx764rmbn/sophos-exposed-cyberattacks-on-cloud-honeypots-wp.pdf

⑤サイバー攻撃被害に係る情報の共有・公表ガイダンス検討会「サイバー攻撃被害に係る情報の共有・公表ガイダンス」(令和5年3月8日)印刷43頁。
https://www.soumu.go.jp/main_content/000867112.pdf

⑥株式会社東北新社・株式会社オムニバス・ジャパン「ランサムウェアによる不正アクセスに関するご報告(第六報)」(令和8年6月4日)1頁。
https://www.tfc.co.jp/cms/wp-content/uploads/【重要なお知らせ】ランサムウェアによる不正アクセスに関するご報告(第六報).pdf