セキュリティ事故の影響範囲評価｜対象資産・データ・顧客影響を分けて見積もる方法

不正アクセスを検知したあと、「どの端末が侵害されたか」は分かっても、「誰の、どのデータに、どのような影響があったか」まで一度に確定するとは限りません。アカウントが持つ権限の範囲、記録された操作、保存されていた情報、業務停止の影響を混ぜると、被害を過大にも過小にも伝えてしまいます。

セキュリティ事故の影響範囲は、資産・アカウント・データ・顧客影響を対応付け、確認済み、調査中、根拠をもって対象外とした範囲を分けて評価します。アクセスできた可能性と実際に確認した操作を区別し、証拠、調査対象期間、ログの網羅性、判断時点を一緒に残してください。影響範囲の数字には、対象期間と証拠の届く範囲を必ず添えます。

事故の種類によって必要な確認は変わります。まずセキュリティインシデントの主要事例と教訓で、自社の事故が情報の漏えい、改ざん、サービス停止などのどこに影響するかを整理すると、調べる項目を選びやすくなります。以下は2026年9月24日時点のNISTと個人情報保護委員会の公開資料を踏まえた、企業内で使う記録・判断手順の例です。

---

本記事のポイント

1. 影響範囲は資産・アカウント・データ・顧客を対応付け、確認済みと調査中の対象を根拠とともに分けます。
2. アクセス可能な範囲と実際の操作、レコード数と本人の人数を区別し、ログがないだけで影響なしとは判断しません。
3. 対象期間と証拠の網羅性を添えて評価を更新し、調査完了を待たず個人データの報告・通知要否を並行して判断します。

---

1. 調査対象期間と資産・アカウントの範囲を決める

最初に事故番号、評価の責任者、評価時点、確認した事象、調査対象期間を記録します。「9月に見つかった事故」と「9月だけを対象にした調査」は違います。検知時刻は侵害の開始時刻とは限らないため、最も早い不審な記録、認証情報が利用できた期間、ログの保持期間などを使い、どこまで過去へ確認できるかを示します。開始点が不明なら、そのまま不明として残し、検知日時で代用しません。

資産台帳では端末やサーバーだけでなく、クラウドの契約・プロジェクト・テナント、データベース、共有ストレージ、SaaSの連携先を確認します。表示名だけでは同名資産を取り違えるため、資産ID、テナントID、所有部門、利用業務を対応付けます。共通の認証基盤や管理者アカウントを使っていた資産は、最初の検知対象とは別でも調査候補になります。

アカウントは利用者、管理者、サービスアカウント、APIトークンなどに分け、事故当時の権限を調べます。現在の権限が小さくても、事故時点には広い権限があった可能性があります。グループ所属、代理操作、委任、連携アプリ、セッションなども確認し、削除済みのアカウントや失効済みのトークンを調査対象から自動的に外さないでください。

NIST SP 800-61 Rev.3のRS.AN-08は、既知の対象資産に加え、他の潜在的な対象でも侵害指標や永続化の兆候を調べることを勧めています。最初に警告が出た端末だけの確認で範囲を閉じると、別の資産に残る活動を見落とすおそれがあります。一方、つながっている資産をすべて「侵害済み」とする必要もありません。調査候補への追加と、侵害の確認は別の判断です。

調査中に必要なログが消えないよう、保全と分析を並行します。原本の保存、取得者、ハッシュ、受け渡しの記録はセキュリティ事故の証拠保全手順で整理できます。範囲評価の表には証拠の保存先や識別子を記載し、機密データそのものを広く共有する報告書へ貼り付けない運用にします。

2. アクセス権限と実際の操作をデータへ対応付ける

次に、対象アカウントがどのデータへ到達できたかを調べます。共有フォルダー、顧客テーブル、添付ファイル、エクスポート、バックアップなどを挙げ、データの種類、管理部署、顧客や本人との対応、保存期間を記録してください。「顧客情報」という大きな分類だけでは、連絡先、契約情報、決済情報などの違いを判断できません。

アクセス権限があること、一覧やファイルを閲覧したこと、外部へ送信したことは、それぞれ別の事実です。権限設定から分かるのは到達可能な範囲であり、それだけで漏えいを確定できません。ダウンロードイベントがあっても、イベントの仕様によっては完了や転送量までは分からないため、ログが何を記録するのかを確認します。逆に、ダウンロードログがないだけで、閲覧や別の経路による取得を否定することもできません。

確認する層	根拠の例	その根拠だけでは言えないこと
到達可能性	事故当時の権限、共有設定、ネットワーク到達性	実際に閲覧・取得されたか
操作の記録	認証、参照、検索、ダウンロード、更新のログ	ログ仕様の範囲外の操作や、記録されていない期間の状態
情報の移動	エクスポート結果、通信、転送先、取得ファイルの照合	確認した移動以外に別の経路がなかったか
業務・本人への影響	停止時間、改ざん対象、データ分類、対象者の重複除去結果	未確認の二次被害や将来の損失額

この表は調査を進めるための整理例であり、すべての事故で同じ証拠がそろうわけではありません。ログを取得できないSaaSでは、提供元への照会結果、機能の記録仕様、取得できる期間を残します。「ベンダーから回答待ち」と「ログ上は異常なし」を同じ欄に書かず、何を確認できていないかを明示します。

データへのアクセスだけでなく、可用性と完全性も確認します。個人データの外部送信が見つからなくても、受注データの改ざんやサービス停止が起きていれば顧客影響があります。漏えい、改ざん、消失、利用停止を分けて記録し、ある項目で未確認だからといって、事故全体を「影響なし」とまとめないでください。

複数の記録を照合する際は、時間帯や時計のずれをそろえる必要があります。時刻の扱いはセキュリティ事故の時系列整理を参照し、対象期間の判断根拠を共通にしてください。時系列の推定が変わった場合は、その時間帯に到達できた資産とデータの範囲も見直します。

3. 確認済み・調査中・対象外を分け、人数と件数を混ぜない

影響範囲の台帳では、対象IDごとに状態を持たせると説明しやすくなります。ここでは「確認済み」「調査中」「対象外」の三つに分ける運用例を示します。この三分類はNISTや個人情報保護法が一律に指定した分類ではなく、確度の異なる情報を混ぜないための記録方法です。

状態	記録内容	更新する条件
確認済み	確認した影響の種類、対象、証拠ID、対象期間、確認者	別のデータや顧客との関連が見つかった場合
調査中	到達できた可能性、未取得のログ、照会先、調査の限界	証拠の追加、提供元の回答、権限履歴の判明
対象外	対象期間にアクセスできなかったなどの除外根拠と、その適用範囲	対象期間、権限、接続経路などの前提が変わった場合

「対象外」は証拠が見つからなかった対象を置く場所ではありません。対象期間にはまだ作成されていなかった資産、当該経路では到達できなかったことを裏付けられたデータなど、除外の理由を示せる場合に使います。それでも別の経路や時期まで否定したことにはならないため、「どの仮説に対して対象外か」を記録します。

対象数を示すときは、ファイル数、レコード数、アカウント数、本人の人数、顧客企業数を分けます。一人に複数の注文行があるなら、行数をそのまま人数としてはいけません。識別子の欠落や重複がある場合は、重複除去の方法、照合できなかった件数、集計対象を記録します。国・地域の区分も、契約先の所在地、利用者の所在、本人の属性を混同しないよう定義します。

たとえば、仮想の事故で3,000行の顧客テーブルに到達可能だった一方、取得が確認できたファイルには200行が含まれていたとします。200行を「被害者200人」と言い換えるのは不適切です。重複を除いて180人と確認できたなら、確認できた取得対象は180人と記録します。残る行への操作が不明なら、テーブルの到達可能範囲と、未確認の操作を別に示します。

また、3,000行を事故全体の上限にできるのは、他のテーブル、添付ファイル、複製、別アカウントなどが調査範囲に含まれ、その範囲の完全性を説明できる場合に限られます。調べた一つのテーブルの件数を、事故全体の最大被害数と断定しないでください。上限を確定できないときは「現時点で確認できた対象」と「追加調査の対象」を示す方が正確です。

4. 更新条件と報告・通知の判断を並行して管理する

影響範囲の評価は、一度作って完了する資料ではありません。NIST SP 800-61 Rev.3は、悪影響の範囲と影響を見直し、精緻化する考え方を示しています。追加ログ、委託先からの回答、新たな侵害指標、権限履歴、データの照合結果が出たときに、担当者が同じ台帳を更新できるようにします。

1. 現在の評価時点、対象期間、集計単位を固定する。
2. 確認済みの対象と、調査中の対象、その根拠を別々に集計する。
3. 前回から増減した対象について、証拠の追加・重複除去・除外判断などの理由を記録する。
4. 調査担当が根拠を確認し、事業部門が業務影響、法務・プライバシー責任者が報告・通知要否を確認する。
5. 次に必要な調査、担当者、期限、次回の評価予定を残す。

件数が減る変更にも理由が必要です。重複除去で人数が減ったのか、別の顧客だったため対象外にしたのかでは意味が異なります。古い評価を上書きして消すのではなく、版と判断時点を保存してください。対外説明に使った数字については、どの版を参照したかが追えるようにします。

日本の個人データに関する事故では、調査が終わるまで報告・本人通知の検討を待つ運用にしないことが重要です。個人情報保護委員会は、一定の漏えい等やそのおそれについて報告・本人通知を求めています。要配慮個人情報を含む場合、財産的被害のおそれがある場合、不正の目的で行われたおそれがある場合、本人の数が1,000人を超える場合など、対象類型を現行の案内で確認してください。人数が少ないことだけで報告不要とは判断できません。

同委員会の案内では、速報は事態を知った後速やかに、目安として概ね3〜5日以内、確報は原則30日以内、不正の目的で行われたおそれがある事態では60日以内とされています。本人通知の時期はこれらの確報期限と同じではなく、状況に応じて速やかに行う扱いです。法令上の起算点、委託関係、通知が困難な場合の扱いなどは事案ごとに確認し、未判明の事項があっても必要な手続きを遅らせないよう、法務・プライバシー責任者と並行して進めます。

報告先には、調査中の仮説を確定事項として伝えず、確認できた内容、まだ分からない内容、次の更新予定を分けて説明します。範囲評価の台帳は技術調査の結果を事業判断へ渡すための資料です。台帳を作ったこと自体で、原因究明、封じ込め、法令対応、復旧のすべてが完了したことにはなりません。

よくある質問

侵害されたアカウントが見られるデータは、すべて漏えい済みですか？

権限の範囲は到達可能性を示しますが、実際の閲覧や取得をそのまま証明しません。権限、操作記録、転送の証拠を分けて確認します。一方、実際の取得が未確認でも、漏えい等のおそれとして報告・通知の検討が必要になる場合があります。

ダウンロードログがなければ対象外にできますか？

それだけではできません。ログの記録仕様、保持期間、欠落、別の取得経路を確認します。調査できない範囲が残る場合は、影響なしとせず、未確認の内容と調査の限界を記録します。

顧客レコード数と被害を受けた人数は同じですか？

同じとは限りません。一人が複数のレコードに含まれる場合や、同じ顧客企業に複数の担当者がいる場合があります。集計単位を明記し、重複除去と照合できなかった対象を分けて説明します。

対象外と判断した資産を後から戻してもよいですか？

新しい証拠や対象期間の変更で前提が変わった場合は、調査中や確認済みへ更新します。元の除外理由、変更の根拠、判断者、時点を保存し、過去の判断を消してつじつまを合わせないようにします。

対象人数が未確定なら個人情報保護委員会への報告を待てますか？

人数の確定だけを理由に待つ運用にはしません。報告対象は人数だけで決まらず、一定の漏えい等のおそれも含まれます。現行の案内に基づき、判明した内容での速報や追加情報の扱いを法務・プライバシー責任者と確認します。

封じ込めが終われば範囲評価も完了ですか？

別の判断です。現在の活動を止めても、過去にアクセスされたデータや顧客影響が未確定な場合があります。追加調査の必要性と評価の終了条件を決め、未確認事項を引き継いだうえで完了を判断します。

参考情報

• NIST SP 800-61 Rev.3（DE.AE-04、RS.AN-08）
• NIST Cybersecurity Framework 2.0
• 個人情報保護委員会：漏えい等の対応とお役立ち資料
• 個人情報保護法ガイドライン（通則編）（3-5-3、3-5-4）