情報漏洩やその疑いを見つけたら、被害の拡大を止める作業と、調査に必要な証拠を残す作業を並行して進めます。 原因が分かるまで放置することも、証拠を確認せずサーバーやアカウントを消すことも、後の判断を難しくします。
この記事は、Webサービスを運営する企業の技術担当者と意思決定者に向けた対応の整理です。実際の封じ込めは被害の進行と事業への影響で判断し、個人データに関する報告は法務担当や専門家と確認します。技術・制度の確認時点は2026年10月22日です。
初動は指揮・封じ込め・記録を同時に進める
対応責任者、技術調査、顧客や関係先への説明を担う人を決めます。兼務でも役割は明確にします。連絡に使っているメールやチャットの侵害が疑われる場合は、安全を確認した端末と別の連絡経路を使います。
記録の開始を待たないでください。
検知時刻、検知した人、対象システム、観測した事象、実施した変更、判断者を残します。タイムゾーンも必要です。責任者への連絡を待つ間も、定めた権限の範囲で被害拡大を防ぎます。
対象アカウントの停止、共有の解除、通信や公開範囲の制限。影響と操作時刻を記録します。
監査ログ、設定、対象データ、通知を保全。取得者・取得時刻・保存先を記録します。
漏洩が続く共有リンクは無効化し、不審なセッションや認証情報は失効を検討します。サーバーの侵害が疑われる場合はネットワーク隔離などを行います。電源断・再起動・初期化は揮発性の証拠を失う可能性があるため、専門担当と判断します。
NIST SP 800-61 Rev. 3は、時系列や原因の分析と、対応記録・証拠の完全性や出所の保全を扱っています。コピーを保存するだけでなく、誰が何を取得・変更したか追える状態にします。取得したログやディスクにも機密情報が含まれるため、調査用の保存先の権限も限定します。
原因はアカウント・SaaS・クラウド・アプリに分ける
最初に見つけた異常が、最初の侵入経路とは限りません。不審なダウンロードの前にOAuth連携の追加があり、その前に従業員アカウントへの不正ログインがあった、という順序も考えられます。
本文で扱う技術の例です。ロゴは各技術の識別に使用し、公式サイトへリンクしています。提供元との提携・認定を示すものではありません。
次の表は、NCSCの技術的なインシデント対応などを踏まえた、調査対象の整理例です。製品名だけで担当を分けず、同じ利用者・時刻・操作をログ間で照合します。
| 仮説・対象 | 確認する証拠 | 切り分ける問い |
|---|---|---|
| 従業員アカウント・IdP | サインイン、MFAや復旧先の変更、管理権限の付与 | いつ誰のアカウントが使われたか。退職・契約終了後のアクセスか |
| SaaS・OAuth連携 | ファイル共有、データ出力、連携アプリとスコープ、メール転送 | 正規のログイン後に、別の連携先へ情報が渡っていないか |
| APIキー・クラウドIAM | キーの発行・使用、権限変更、ストレージ操作 | どの認証情報で何を取得・変更できたか |
| Webアプリ・API・DB | アクセス、認証・認可、クエリや出力、デプロイ履歴 | 脆弱性、認可不備、設定変更のどれが関係するか |
| 委託先・外部サービス | 事業者の通知、対象データ、保全したログ、こちら側の操作履歴 | どこまで調査済みで、何が未確認か |
| 誤送信・公開設定 | 宛先、添付、共有範囲、公開期間、閲覧・取得記録 | 誰がアクセス可能で、実際の取得を確認できるか |
IPアドレスの一致や海外からのアクセスだけで犯人や原因を断定しません。VPN、共有回線、攻撃者による中継などで見え方が変わります。事実と仮説を分け、別の証拠で裏付けます。
パスワード以外のアクセスも調べる
パスワードの変更後も、SaaS固有のセッション、APIキー、OAuth連携が残る場合があります。Microsoftの不正なOAuth同意への対応は、不正なアプリへの権限付与を別途調べる必要を示しています。
Google Workspaceの侵害アカウントへの対応では、管理操作やログインの記録、転送設定などを調べます。ログインの停止と、データの持ち出し経路を閉じる操作は分けて確認してください。
PHPの脆弱性が関係しそうなら、php2shellの影響と対応を参照します。脆弱性が存在したという事実だけでは、今回の漏洩原因だったとは断定できません。
漏洩した範囲と調査できない範囲を分ける
「侵害された可能性がある」「データにアクセスできた」「実際に持ち出しを確認した」は異なる事実です。顧客への説明や社内報告では、この区別を保ちます。
| 区分 | 記録する内容 |
|---|---|
| 確認できた漏洩 | 対象データ、確認した証拠、時刻、件数と集計方法 |
| アクセス可能だった範囲 | 当時の権限や公開設定から届き得たデータ |
| 未確認の範囲 | ログ不足、保存切れ、委託先の調査待ちなどの理由と次の確認事項 |
たとえばAWS CloudTrailのデータイベントは、証跡やイベントデータストアでデフォルトでは記録されません。S3のGetObjectのようなデータ取得を調べたい場合、「CloudTrailが有効だった」だけでは足りず、その操作が記録対象だったか確認が必要です。
対象期間、時刻のずれ、ログの完全性、取得できる契約プランや保存期間も確認します。ログに痕跡がない理由が分からないなら、その不確実性を報告に残します。
個人データの報告と本人通知を並行して判断する
一般の個人情報取扱事業者では、以下の類型に当たる個人データの漏えい等は、発生した場合に加え、発生したおそれがある場合も個人情報保護委員会への報告対象になります。
- 要配慮個人情報を含むもの
- 不正利用による財産的被害のおそれがあるもの
- 不正の目的が疑われる行為によるもの
- 対象となる本人の数が1,000人を超えるもの
出典：個人情報保護委員会「漏えい等の対応」。少人数なら報告不要という意味ではありません。人数以外の類型にも照らして判断します。
| 対応 | 期限・考え方 |
|---|---|
| 速報 | 報告対象事態を知った後、速やかに。概ね3〜5日以内が目安 |
| 確報 | 知った日から30日以内。不正目的が疑われる行為による類型は60日以内 |
| 本人通知 | 状況に応じて速やかに。30日・60日という一律期限ではない |
法人では、いずれかの部署が事態を知った時点が期限の基準になります。調査が完了するまで速報を待つのではなく、その時点で把握できた内容を整理します。高度な暗号化等による除外、委託先からの通知、本人通知が困難な場合の代替措置などには条件があります。現行の通則編3-5で確認してください。
取引先への通知、業法上の報告、海外の個人データに関する義務は別に生じる場合があります。法務担当と確認し、顧客には確認済みの事実、利用者に必要な行動、問い合わせ先、次回の更新予定を伝えます。未確認の段階で「影響はありません」と言い切らないようにします。
復旧は侵入経路と残存アクセスを確認してから進める
侵入に使われた欠陥や設定を修正し、不審なアカウント、連携、タスク、認証情報が残っていないか確認します。侵害が疑われる実行環境は、証拠を保全したうえで、信頼できるイメージやコードからの再構築を検討します。
認証情報の再発行は、安全を確認した管理環境から行います。侵害された環境に新しい秘密情報を配ってしまうと、再び取得されるおそれがあります。バックアップも取得時刻と侵害期間を照合し、復元先で動作と安全性を確認します。
復旧の承認者、確認項目、監視期間、問題が再発した場合の判断を決め、段階的に利用を再開します。原因と対応を振り返る際は、個人の操作だけで終わらせず、広すぎた権限、見えていなかったログ、判断に必要だった情報まで改善対象にします。
wrenの運用から考える、平時に残しておく情報
wrenでも日々、ライブラリのバージョン管理や技術的な防御を行っています。自社サイトでは、依存関係のlockfileとコードの変更履歴をGitで管理しています。こうした記録は、問題が見つかった際に、どの変更で依存関係や設定が変わったかを調べる材料になります。
ただし、コードの履歴だけでは、その時点に本番で動いていたものや、データが取得された事実までは確定できません。デプロイ記録や監査ログと結び付ける必要があります。これは当社サイトの管理方法を使った説明であり、情報漏洩事故への対応実績を示すものではありません。
平時の確認項目はWebサービス事業者のセキュリティ対策にまとめています。ログ、権限、更新、復旧手順を継続的に整える担当を検討する場合は、SRE顧問の役割と契約範囲も参照してください。
wrenの受託開発・SRE顧問の対応領域では、監視や障害対応の手順づくりなどを紹介しています。SRE顧問の相談フォームでは、対象システムと課題を伺い、関わり方の案をメールでお返しします。継続的な運用改善の相談窓口です。進行中の事故については、契約中の緊急対応先や専門の調査事業者への連絡を並行してください。