インシデント発生時の初動対応を迷わず進める方法（連絡・復旧・公表）

インシデント初動対応が難しい理由と、最初に決めるべきゴール

セキュリティのインシデント（不正アクセス、ランサムウェア感染、情報漏えいの疑い、アカウント乗っ取り等）が起きたとき、現場が最も困るのは「何から手を付ければいいか分からない」ことです。特に、開発の専門知識がない中小企業や、情シスが少人数の企業では、連絡・復旧・公表を同時に迫られ、判断が遅れやすいという共通の落とし穴があります。

初動対応でありがちな失敗は次の3つです。第一に、原因が分からないまま“とりあえず再起動”“とりあえずパスワード変更”など場当たり的な操作を行い、証拠（ログ）を消したり、攻撃者の痕跡を見失ったりすること。第二に、社内連絡が遅れて現場の混乱が拡大し、二次被害（同じパスワードを使い回していた別システムの侵害など）が起きること。第三に、外部への説明が後手に回り、取引先や顧客の不信を招くことです。

では、初動対応のゴールは何か。結論から言うと、初動のゴールは「犯人探し」ではなく、被害の拡大を止め、復旧のための材料を残し、必要な相手へ正しく連絡することです。これを達成できれば、その後の調査（フォレンジック）や恒久対策に繋げられます。逆に、初動で証拠が失われると、何が起きたか確定できず、報告や補償判断が長期化し、最終的なコストが膨らみます。

本記事では、セキュリティ事故に不慣れでも迷わないように、初動を「検知→封じ込め→連絡→復旧→公表（必要時）」の流れで整理し、社内外の連絡先や判断基準まで具体化します。読み終わったら、最低限の“持ち出せる手順書”として自社に落とし込める状態を目指しましょう。

最初の30分でやること：検知の確認と封じ込め（拡大防止）

インシデントが疑われた瞬間、最初の30分での優先順位は「調査」よりも「封じ込め」です。なぜなら、攻撃が進行中の場合、数分単位で被害が広がるからです。ここで重要なのは、“止血しつつ、証拠を残す”という両立です。

状況の切り分け（事実と推測を分ける）

まず、何が“起きた可能性”ではなく“起きた事実”なのかをメモします。例として、次のように書き分けます。

• 事実：社員AのPCに「ファイルが暗号化された」旨の表示、共有フォルダが開けない
• 事実：外部からの大量ログイン失敗、管理者アカウントで深夜にログイン成功
• 推測：ランサムウェアかもしれない／パスワード漏えいが原因かもしれない

推測で動くと誤った操作をしがちなので、事実の積み上げを最初に行います。スクリーンショット、警告メール、ログの時刻など、後で必要になる情報を確保してください。

封じ込めの基本（ネットワーク・アカウント・権限）

封じ込めは、侵入経路や横展開（他システムへの拡散）を止める作業です。次の順番が実務的です。

1. 疑わしい端末をネットワークから隔離（LANケーブルを抜く、Wi-Fiを切る）。電源はむやみに切らず、可能なら画面を写真で残します。
2. 侵害が疑われるアカウントを停止（退職者アカウント、管理者、外部委託の共用IDなど）。パスワード変更は有効ですが、攻撃者が既に別の手段を持つ場合もあるため、まず停止・無効化を優先します。
3. 重要システムへのアクセス経路を絞る（VPN停止、踏み台サーバの遮断、特定IPのみ許可など）。停止の影響範囲は記録し、業務影響が大きい場合は経営判断に繋げます。

注意点として、いきなり全社ネットワーク遮断は有効な場合もありますが、業務停止コストが大きく、証拠収集が難しくなるケースがあります。判断に迷うときは「被害が拡大している兆候があるか（暗号化が増えている、ログインが連続している等）」を基準に、段階的に遮断範囲を広げるのが現実的です。

ログと証拠の保全（“消さない”が最優先）

技術に詳しくなくても守れる鉄則は、ログを消さない・上書きしないことです。具体的には、次を意識してください。

• PCのクリーンアップ、最適化ツール、ログ削除はしない
• ウイルス対策ソフトの「駆除」実行前に、検知名・検知時刻・対象ファイルを記録
• クラウド（Microsoft 365、Google Workspace、AWS等）の監査ログは保持期間に注意し、早めにエクスポート

もし外部の調査会社や開発ベンダーに依頼する可能性があるなら、時系列メモ（いつ、誰が、何を見て、何をしたか）だけでも大きな助けになります。

社内の連絡体制：誰に・何を・いつ伝えるか（連絡テンプレ付き）

インシデント対応は技術対応だけでは終わりません。実際には「情報の流れ」を作れるかが勝負です。特にセキュリティ事故では、現場担当者が抱え込み、経営層が状況を把握した頃には被害が拡大している、というパターンが多発します。ここでは、非エンジニアでも回る連絡体制を作ります。

最少人数の“対策本部”を即時に作る

初動は人数が多いほど混乱します。まずは次の役割だけを集めます。

• 指揮：経営者または意思決定者（停止判断・公表判断・外部依頼の決裁）
• 実務：情シス/総務（端末・アカウント管理、ベンダー連絡窓口）
• 法務・個人情報：個人情報保護、契約違反リスクの確認（社内にいなければ顧問弁護士）
• 広報：対外文の作成・問い合わせ窓口（不在なら指揮が兼務）

ここで重要なのは、連絡手段です。社内チャットが侵害されている可能性もあるため、代替手段（電話、別メール、緊急用グループ）を決めます。

社内連絡で必ず含める情報（5W1Hを簡略化）

社内向けの第一報は完璧でなくて構いませんが、次の項目を揃えると混乱が減ります。

• 何が起きたか（例：不正ログイン疑い、暗号化被害、情報漏えい“疑い”）
• いつ気付いたか（検知時刻）
• どこまで影響しそうか（対象システム、拠点、部署）
• 今やっていること（隔離、アカウント停止、調査依頼中など）
• 現場への依頼（PCを触らない、再起動しない、パスワード変更は指示待ち等）

外部ベンダー・クラウド事業者への連絡は“事実だけ”で早く

クラウド（Microsoft 365、Google、AWS等）や利用サービスに関しては、サポート窓口への連絡が復旧速度を左右します。ここで推測を書きすぎると話がブレるので、ログイン元IP、時刻、対象アカウント、起きた現象の事実を共有し、調査に必要なログの取り方も確認してください。

復旧の進め方：安全確認→優先順位→段階復旧（“元に戻す”の罠を避ける）

復旧で最も危険なのは「とにかく業務を戻したい」気持ちから、原因が残ったままシステムを再開してしまうことです。セキュリティの観点では、復旧は“元の状態に戻す”ではなく、攻撃者を締め出した状態に作り直す作業です。

復旧の前に行う安全確認（再侵入の芽を潰す）

最低限、次の確認ができていない状態でサービスを再開すると、短時間で再侵害されるリスクがあります。

• 侵害が疑われるアカウントの無効化・強制ログアウトが完了している
• 管理者権限の棚卸し（不要な管理者、共用ID、外部委託の権限）
• リモートアクセス経路（VPN、RDP、管理画面公開）の制限
• 認証強化（多要素認証、条件付きアクセス等）の適用

例えば、Microsoft 365の不正ログインが疑われる場合、パスワード変更だけでなく多要素認証の有効化、トークンの無効化（サインアウト強制）、転送ルール（勝手に外部転送される設定）の確認が重要です。

優先順位の付け方（止める順・戻す順）

復旧の優先順位は「売上」だけでなく「被害拡大」と「法令・契約」を含めて決めます。迷う場合の基準は次の通りです。

• 個人情報・機密情報に近いシステムほど慎重（顧客DB、勤怠、人事、会計）
• 横展開の起点になりやすい基盤を先に固める（ID基盤、メール、VPN）
• 業務影響が大きいが情報が少ない領域は「限定運用」で再開（アクセス制限・監視強化）

バックアップからの復旧時の注意（“感染したバックアップ”問題）

ランサムウェア等では、バックアップ自体が暗号化・改ざんされていることがあります。復旧前に、バックアップの世代（いつの時点のデータか）と、復元先の環境が安全かを確認してください。可能なら、隔離ネットワーク上で復元テストを行い、復元後に最新のセキュリティパッチ適用、設定見直しをした上で本番に戻します。

また、復旧後は監視を強めます。ログイン失敗の急増、海外IPからのアクセス、権限昇格の痕跡など、再侵入の兆候を数日〜数週間は重点的に見ます。復旧は“完了”ではなく、“監視フェーズへの移行”だと捉えると事故の再発を防げます。

公表・報告の判断：どこまで、いつ、誰に（取引先・顧客・当局）

インシデント時に最も神経を使うのが公表や報告です。「漏えいが確定していないのに言うべきか」「取引先にいつ伝えるか」「SNSで炎上しないか」など、判断が遅れるほど不信が膨らみます。一方で、誤った内容を出すと訂正が必要になり、二次炎上を招きます。ここでは、非専門家でも判断しやすい軸を示します。

“公表”と“個別連絡”と“規制・当局対応”を分けて考える

対外対応は一枚岩ではありません。主に次の3つに分かれます。

• 取引先・顧客への個別連絡：契約上の報告義務、業務影響の共有、被害拡大防止（パスワード変更依頼等）
• Web等での公表：影響が広範、憶測が広まっている、問い合わせが殺到する場合の情報集約
• 当局・関係機関への報告：個人情報を扱う場合や、業界ルールにより必要となる場合

まずは契約（委託元とのDPA、SLA、情報セキュリティ条項）を確認し、報告期限や報告項目を洗い出します。社内に法務がない場合、顧問弁護士に早めに相談することで、後から「報告が遅い」と指摘されるリスクを下げられます。

初報で書くべきこと／書かないほうがよいこと

初報は「現時点で分かっている事実」と「今後の見通し」を短くまとめます。逆に、原因の断定や被害件数の断定は、裏取りができるまで避けます。

• 書く：発生日（検知日）、対象サービス、影響の可能性、実施した封じ込め、問い合わせ窓口、次回更新予定
• 慎重に：漏えい“確定”の表現、犯人像、技術的詳細（攻撃を助長する恐れ）

謝罪のポイント（過不足なく、信頼を落とさない）

謝罪は重要ですが、過度に断定・約束をすると後で矛盾します。「ご迷惑をおかけしている事実」への謝意と、「調査・再発防止を進める意思」を明確にし、補償や責任範囲は確認後に提示する形が安全です。FAQ（想定問答）を用意し、問い合わせ対応者によって説明がブレないようにしましょう。

再発防止と“次の事故”を小さくする準備：平時に整えるチェックリスト

インシデント対応は、発生後の頑張りだけでは限界があります。次の事故を小さくするのは、平時の準備です。ここでは、予算はあるが詳しくない情シス・管理者でも取り組みやすい、効果が出やすい順に整理します。ポイントは、「検知できる」「止められる」「説明できる」の3点を揃えることです。

連絡網と意思決定ルール（人の準備）

• 緊急連絡先（社内・ベンダー・顧問弁護士・保険会社・クラウド窓口）を1枚に集約
• 休日夜間の判断者（代行含む）と、停止判断の基準（例：顧客データに到達の疑いがあれば即停止）
• 社内アナウンスのテンプレ（第一報・続報・復旧報）

これだけでも初動の迷いが大きく減ります。インシデントは“担当者の勇気”ではなく、仕組みで動かすべきです。

IDと端末の基本対策（技術に詳しくなくても効果大）

• 多要素認証の徹底（メール、VPN、管理画面は必須）
• 管理者アカウントの分離（普段使いのIDに管理者権限を付けない）
• 退職・異動時のアカウント停止の即日運用
• 端末の暗号化、パッチ適用、ウイルス対策の集中管理

攻撃者は「弱いところ」から入ります。高度な対策より、基本の徹底が一番の近道です。

バックアップと復旧訓練（復旧時間＝損失を左右する）

• バックアップの世代管理（最低でも複数世代）
• バックアップ先の権限分離（本番の認証情報で削除できない構成が理想）
• 年に1回でもよいので復元テスト（“取れているつもり”をなくす）

特にランサムウェアでは、復旧時間がそのまま売上・信用の損失に直結します。復元テストはコストに見えて、最も費用対効果が高い投資です。

ログの見える化（何が起きたか説明できる状態へ）

インシデント後に「結局、何が起きたのか分からない」となる最大要因がログ不足です。クラウドの監査ログ、認証ログ、端末ログを必要期間保管し、アラート（例：海外ログイン、管理者権限付与、短時間での大量失敗）を設定します。難しければ、まずは重要システムだけでも構いません。“説明できる”ことは、対外信用と法的リスクを下げる武器になります。

まとめ

インシデントの初動対応は、セキュリティの専門知識よりも「順番」と「連絡の設計」で成否が決まります。最初の30分は、調査より封じ込めを優先し、端末隔離・アカウント停止・アクセス経路の制限を段階的に実施しつつ、ログや画面などの証拠を残してください。社内では最少人数の対策本部を立て、事実ベースの第一報テンプレで混乱を抑えます。

復旧は“元に戻す”ではなく“締め出して作り直す”発想が重要です。安全確認を挟み、優先順位を付けて段階復旧し、復旧後は監視フェーズへ移行します。公表・報告は、個別連絡／公表／当局対応を分け、断定を避けつつ、更新予定と窓口を明示することで信頼を守れます。

そして次の事故を小さくする鍵は平時の準備です。連絡網、意思決定ルール、多要素認証、権限管理、バックアップの復元テスト、ログ保管とアラート設定から整えましょう。「検知できる・止められる・説明できる」状態を作ることが、実務で一番強いセキュリティ対策です。