セキュリティインシデントとは？種類・発生原因・初動対応の基本をわかりやすく解説

2026年8月16日

セキュリティインシデントが起きた瞬間、あなたは何をすべきか正確に答えられますか？

「社内サーバーへの不審なアクセスを検知した」「顧客データが外部に漏れたかもしれない」——そんな場面が訪れたとき、あわてて動いた結果、証拠を消してしまったり、被害をさらに広げてしまったりする事例は少なくありません。

この記事では、セキュリティインシデントとは何か、その種類・発生原因・初動対応の基本ステップを、現場で役立つレベルで解説します。難解な専門用語はできるだけ平易に補足しながら進めますので、情シス担当者だけでなく、経営層や一般社員の方にも参考にしていただける内容です。

セキュリティインシデントとは？

セキュリティインシデントとは、情報システムや情報資産に対して、機密性・完全性・可用性（CIA三原則）のいずれかを脅かす事象が発生した、または発生する可能性が確認された状態のことです。

「インシデント（incident）」は英語で「事件・出来事」を意味しますが、セキュリティの文脈では「組織のセキュリティポリシーや標準に違反する、あるいは違反するおそれのある事象」と定義されることが多いです。ISO/IEC 27035では「情報資産を危殆化させ、業務を脅かす可能性が高い情報セキュリティ事象」とされています。

重要なのは、「悪意ある外部攻撃だけがインシデントではない」という点です。

・外部からのサイバー攻撃（ランサムウェア、不正アクセス、DDoSなど）
・従業員の誤操作や設定ミス（メールの誤送信、S3バケットの公開設定など）
・機器の盗難・紛失（ノートPCやスマートフォン）
・内部不正（退職者によるデータ持ち出しなど）
・自然災害や設備障害（火災・停電によるサービス停止）

これらはすべてセキュリティインシデントに該当します。攻撃かどうかに関わらず、「組織の情報資産の安全性が脅かされた出来事」すべてがインシデントです。

また、セキュリティインシデントと混同しやすい言葉に「セキュリティイベント」があります。イベントとは「何かが起きた」という観測可能な出来事を指し、インシデントはそのなかで「対応が必要」と判断されたものを指します。大量のログイン試行はイベントですが、それが侵害につながった場合はインシデントです。

セキュリティインシデントの主な種類

インシデントを性質で分類すると、主に以下の3カテゴリに整理できます。

1. 外部からのサイバー攻撃

最もニュースになりやすいカテゴリです。外部の攻撃者が意図的に仕掛けてきます。

・ランサムウェア・マルウェア感染: 悪意あるソフトウェアがシステムに侵入し、データの暗号化・破壊・情報窃取を行う
・不正アクセス・アカウント侵害: フィッシングや認証情報の窃取により、正規ユーザーになりすましてシステムに侵入する
・DDoS攻撃: 大量のトラフィックを送りつけてサービスを停止・妨害する
・Webアプリケーション攻撃: SQLインジェクション・XSS・SSRFなどを悪用してデータ窃取・改ざんを行う
・サプライチェーン攻撃: 取引先企業や使用しているソフトウェアを経由して自組織へ侵入する

2. 内部起因のインシデント

外部攻撃と違い、発覚が遅れがちで被害が長引きやすいのが特徴です。

・内部不正（インサイダー脅威）: 現役・元従業員・業務委託者が意図的に情報を持ち出す、改ざん・破壊する
・誤操作・ヒューマンエラー: メールの誤送信、設定の誤り、ファイルの誤削除など。攻撃意図はなくても重大な漏洩につながる
・ポリシー違反: 承認されていないクラウドサービスの利用（シャドーIT）、私物USBへのデータコピーなど

3. 物理的・環境的インシデント

・端末の盗難・紛失: 暗号化されていないPCや記録媒体が流出し、情報漏洩につながる
・設備障害・自然災害: 火災・水害・停電による可用性への影響。バックアップが不十分だとデータ消失に至る
・物理的な不正侵入: サーバー室や執務スペースへの不正立ち入り

インシデントが発生する主な原因

なぜインシデントは起きてしまうのか。現場でよく見られる原因を整理します。脅威・脆弱性・リスクの違いを理解しておくと、原因の切り分けに役立ちます。

・脆弱性の放置: パッチが当たっていないOSやソフトウェア、デフォルト設定のまま放置されたサービスが攻撃の入り口になる。「後でやる」が命取りになります
・弱い認証: 推測されやすいパスワード、使い回し、多要素認証の未導入。認証情報の管理が甘いと、攻撃者はここから侵入します
・ソーシャルエンジニアリング: フィッシングメールや電話による巧みな誘導で、正規ユーザーが認証情報を渡してしまう
・設定ミス・セキュリティ設定の不備: クラウドストレージの公開設定、ファイアウォールルールの誤り、不要ポートの開放など
・セキュリティ教育の不足: 従業員がリスクを認識していないため、危険な操作をしてしまう。フィッシングを見抜けない、不審なUSBを挿してしまう、など
・ログ・監視の不在: 異常が起きても気づける仕組みがない。侵入から発覚まで数百日かかるケースも珍しくありません

どれか一つを対策すれば安全、というものではなく、技術・運用・人の3方向からの総合的なアプローチが必要です。

具体的な初動対応の手順

インシデントが発生した（または疑われる）場合、最初の数時間の動きが被害の拡大を大きく左右します。以下の5ステップが基本的な流れです。

1. 発見・報告

インシデントはセキュリティツールのアラート、社員からの報告、外部機関からの通知など、様々なルートで発覚します。

発見した人は即座に情報システム担当者または上長へ連絡します。この段階での重要なポイントは、「確証がない」「大したことではないかもしれない」という自己判断で抱え込まないこと。報告が遅れるほど、初動の選択肢が狭まります。

報告を受けた担当者も、「どうせ誤検知だろう」と軽視せず、まず事実確認に動くことが大切です。

2. 初期トリアージ（深刻度の評価）

「トリアージ（triage）」とは、医療の現場で重症度に応じて治療の優先順位を決める手法を指します。セキュリティでも同様に、インシデントの深刻度・影響範囲・緊急度を素早く評価します。

確認すべき主な点：
・どのシステム・データが影響を受けているか？
・現在も攻撃は継続中か？
・外部への通信遮断や業務停止は必要か？
・個人情報漏洩が疑われる場合、規制当局への報告義務は発生するか？
・経営層への報告・エスカレーションは必要か？

深刻度が高いと判断した場合は、専門家への相談（JPCERT/CCへの届出、セキュリティベンダーの緊急対応チームの呼び出し）も並行して検討します。

3. 封じ込め（コンテインメント）

被害がこれ以上広がらないよう、感染端末・侵害されたアカウント・不正通信の経路を素早く遮断します。

具体的な手順例：
・感染が疑われる端末をネットワークから物理的に切り離す（LANケーブルを抜く、Wi-Fiを無効化する）
・侵害されたアカウントのパスワードを即時変更、またはアカウントを一時停止する
・不審な外部IPアドレスへの通信をファイアウォールでブロックする
・影響を受けていない重要システムを保護するため、セグメント分離を検討する

【重要】感染端末をいきなりシャットダウンしないこと。揮発性メモリ（RAM）上の攻撃者の痕跡や接続情報が消えてしまい、後の調査が著しく困難になります。ネットワーク切り離し→電源はそのまま維持、が基本です。

4. 証拠保全

封じ込めと並行して、インシデントの証拠を保全します。これは攻撃者の侵入経路・手口・影響範囲を解明するためだけでなく、規制当局への報告や将来の法的手続きにも必要です。

保全すべき主な対象：
・システムログ・セキュリティログ・アクセスログ（上書きされる前に！）
・メモリイメージ（可能であれば）
・ネットワークトラフィックのキャプチャデータ
・対応経緯のタイムライン（誰が・何時に・何をしたか）

証拠保全の専門的な手順については、デジタルフォレンジックの知識が役立ちます。証拠の扱いを誤ると法的効力を失う場合もあるため、重大なインシデントでは専門家への依頼を検討してください。

5. 根絶・復旧・再発防止

マルウェアの完全除去、脆弱性へのパッチ適用、改ざんされたデータの復元、アカウントの再設定などを行い、安全が確認されたシステムから順次業務を再開します。

最後に、インシデントの根本原因を特定し、同じ事象が再発しないようセキュリティポリシーの見直し・設備と体制の改善を行います。対応後の振り返り（ポストモーテム）は、次の備えに直結する最も重要なプロセスです。

中小企業でも今日からできること

「専任のSOCも、セキュリティ専門家もいない」という状況でも、最低限の備えは整えられます。

・インシデント対応手順書の整備: 「誰が・何を・どの順番で」を文書化しておく。有事の際、人は冷静に考えられません。事前に手順を決めておくことが、初動の速さを決定づけます。中小企業向けインシデント対応手順書の作り方を参考に、自社用にカスタマイズしてみてください
・報告文化の醸成: 「おかしいと思ったらすぐ報告する」習慣を作る。報告した人が責められない心理的安全性が、早期発見のカギです
・ログの取得と保存期間の確保: 最低90日～180日分のログが保存されるよう設定する。インシデント後の調査に不可欠です
・アカウント侵害の早期検知: 不正アクセスの10の兆候を知っておくことで、早期発見につながります
・連絡先リストの整備: JPCERT/CC・IPA・セキュリティベンダーの緊急連絡先を、平時のうちにまとめておく

よくある誤解と注意点

【誤解1】「攻撃されていなければインシデントではない」

従業員のメール誤送信、設定ミスによる情報公開、端末の紛失なども、すべてインシデントです。攻撃の有無に関わらず、情報資産の安全が脅かされた時点で適切な対応が必要です。

【誤解2】「大企業だけが狙われる」

攻撃者は防御が薄い組織を優先して狙います。むしろ中小企業はセキュリティ対策が手薄なケースが多く、狙われやすい側面があります。「うちは小さいから大丈夫」は最も危険な思い込みです。

【誤解3】「発生してから考えれば良い」

インシデントが起きた後に初めて手順を考えていては、初動が遅れ被害が拡大します。平時の準備が、有事のコストを決定づけます。

【注意】個人情報漏洩が疑われる場合は法的対応が必要

個人情報保護法では、個人情報の漏洩・滅失・毀損が一定の基準を超えた場合、個人情報保護委員会への報告と本人への通知が義務付けられています。インシデント対応はIT部門だけの問題ではなく、法務・経営層との連携が必須です。詳細な要件は法律の専門家にご確認ください。

本記事のまとめ

項目	内容
インシデントの定義	CIA三原則を脅かす事象の発生・発生可能性の確認（攻撃に限らない）
主な種類	外部攻撃・内部起因（誤操作・不正）・物理的インシデント
主な発生原因	脆弱性の放置、弱い認証、ソーシャルエンジニアリング、監視不在
初動5ステップ	発見・報告 → トリアージ → 封じ込め → 証拠保全 → 根絶・復旧
感染端末の扱い	即シャットダウンはNG。ネットワーク切り離し後、電源は維持して証拠を保全
今すぐできること	手順書の整備・報告体制の周知・ログ設定・連絡先リストの整備