セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方

「対応手順書はあります」——では、実際に何かが起きたとき、その手順書を開く前に何をしますか？

セキュリティインシデントは「いつか起きるかもしれないこと」ではなく「いつ起きてもおかしくないこと」です。にもかかわらず、現場では「自分が対応する立場になったことがない」「何をすれば正解かわからない」という状態のまま運用しているエンジニアが少なくありません。

インシデント対応は知識として持っているだけでは意味がありません。「何が起きているか把握する→被害の拡大を止める→安全な状態に戻す→再発を防ぐ」という流れを、実際に動けるレベルで理解しておくことが重要です。

この記事では、セキュリティインシデント対応の全体像——種類と範囲・対応フローの5ステップ・各フェーズで使うツール・よくある失敗パターン——を若手エンジニア向けに解説します。

「何かおかしい」——インシデントに気づけない現場のリスク

インシデント対応で最も多い失敗は「対応が遅れること」です。そしてその多くは、異常に気づくのが遅いことが原因です。

なぜ気づくのが遅れるのか。理由は3つあります。

ログを見ていない。 監査ログやイベントログは取得しているが、誰も定期的に確認していない状態です。攻撃者が侵入してから数日〜数週間、気づかずに放置されるケースがあります。

「自分たちは狙われない」という思い込み。 中小規模の組織でも攻撃を受けます。むしろセキュリティリソースが少ない組織は標的にされやすい傾向があります。

異常の基準が定義されていない。 「正常な状態」を知らなければ「異常な状態」にも気づけません。ログ監視は「溜める」ではなく「異常を定義する」ことが本質です。

ログ監視の設計については「ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド」で詳しく解説しています。

セキュリティインシデントとは何か——種類と範囲を整理する

セキュリティインシデント（Security Incident） 情報資産の機密性・完全性・可用性を侵害する、または侵害するおそれのある事象。不正アクセス・マルウェア感染・情報漏洩・サービス停止など幅広い事象が含まれる。

インシデントの種類は大きく4つに分類できます。

ランサムウェア（Ransomware） ファイルを暗号化して使用不能にし、復号と引き換えに金銭を要求するマルウェア。近年は暗号化と同時にデータを窃取して公開すると脅す「二重脅迫」の手口が増加している。

バックドア（Backdoor） 攻撃者が侵害したシステムに密かに仕込む不正なアクセス経路。正規の認証を迂回して外部から自由に侵入できる状態を維持するために使われる。

  DDoS攻撃（Distributed Denial of Service Attack：分散型サービス妨害攻撃） 大量のトラフィックを標的のサーバやネットワークに送りつけ、サービスを停止・低下させる攻撃手法。複数の踏み台端末を使って分散的に実行されるため遮断が難しい。

「セキュリティインシデント」と「システム障害」は別物です。サーバが落ちた・ネットワークが繋がらない、といった事象は障害として対応することが多いですが、その原因が攻撃によるものであればインシデントとして扱います。最初から決めつけず「攻撃の可能性がないか」を常に疑う視点が重要です。

参考：中小企業のためのセキュリティインシデント対応の手引き | IPA

インシデント対応の全体フロー——5つのフェーズで理解する

インシデント対応は以下の5つのフェーズで構成されます。フェーズを順番に進めることが原則ですが、現実には複数フェーズが同時並行になることもあります。

フェーズ①：検知・トリアージ——何が起きているかを把握する

トリアージ（Triage） 医療の「トリアージ」から転用された概念。インシデント対応では、発生した事象の深刻度・影響範囲・対応優先度を素早く評価することを指す。

まず「何が起きているか」を把握します。アラートの内容・影響を受けているシステム・発生時刻・検知した手段を記録します。

この段階で答えるべき問いは3つです。

• 何が影響を受けているか（サーバ・アカウント・データ）
• いつから起きているか
• どこまで広がっているか

焦って対応を始める前に、まず状況を把握することが最優先です。「とりあえずサーバを再起動する」は証跡を失う可能性があるため、この段階では避けてください。

フェーズ②：初動対応——まず何をすべきか

状況を把握したら、次は「被害を広げないための初動」を取ります。

証跡の保全が最優先です。ログ・メモリダンプ・ネットワークキャプチャなど、後の調査に必要な情報を失う前に保全します。再起動・ファイル削除・設定変更はすべて証跡を失うリスクがあります。

関係者への報告も初動の重要な要素です。上長・セキュリティ担当・場合によっては法務・経営層への報告タイミングを判断します。個人で抱え込まず、早期に組織として対応できる状態にすることが重要です。

証跡保全の具体的な手順については「証跡保全の基本｜インシデント対応で最初にやること」（公開予定）で詳しく解説します。

フェーズ③：封じ込め——被害の拡大を止める

封じ込め（Containment） インシデントの影響範囲がこれ以上広がらないようにする対応。感染端末のネットワーク切断・アカウントの無効化・通信のブロックなどが含まれる。

感染端末のネットワーク切断・侵害されたアカウントの無効化・不審な通信のファイアウォールブロックなど、攻撃の継続と拡大を止める措置を取ります。

封じ込めは「完全に排除する」ことではなく「これ以上広げない」ことが目標です。完全な排除は次の復旧フェーズで行います。

侵害されたアカウントの対応については「AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務」も参照してください。

フェーズ④：復旧——安全な状態に戻す

封じ込めが完了したら、システムを安全な状態に戻します。マルウェアの除去・脆弱性の修正・パスワードのリセット・バックアップからの復元などが含まれます。

フォレンジック調査（Digital Forensics） インシデントの原因・経路・影響範囲を特定するためにデジタル証跡を収集・分析する調査手法。復旧前に実施することで、再発防止に必要な情報を得られる。

復旧前にフォレンジック調査を行い「どこから侵入したか・何が持ち出されたか・どこまで汚染されているか」を把握することが重要です。原因が特定されないまま復旧すると、同じ手口で再侵害されるリスクがあります。

フェーズ⑤：事後対応——再発防止と記録

復旧後に行う事後対応は、多くの現場で省略されがちですが最も重要なフェーズです。

• 原因分析：なぜ侵害が発生したか・どこに設計上の問題があったか
• 対策の実施：脆弱性の修正・設計の見直し・運用ルールの改定
• 記録の整備：いつ・何が起きたか・どう対応したかをドキュメント化
• 関係者への報告：経緯と対応結果を組織内外の関係者に報告

「インシデントが起きたことを恥じる」のではなく「次に活かす」姿勢が組織のセキュリティレベルを上げます。

参考：インシデントハンドリングマニュアル | JPCERT/CC

各フェーズで使うツールと記録の考え方

各フェーズで活用するツールと記録の考え方を整理します。

EDR（Endpoint Detection and Response） エンドポイント（PCやサーバ）上の不審な挙動をリアルタイムで検知・記録・対応するセキュリティツール。アンチウイルスより高度な検知能力を持ち、インシデント調査の証跡収集にも活用できる。

SIEM（Security Information and Event Management） 複数のシステムやネットワーク機器のログを一元収集・相関分析するセキュリティ管理システム。Azure Sentinelなどがその代表例。

記録は「やったこと」だけでなく「判断した理由」も残すことが重要です。後から「なぜそう判断したか」を説明できる記録が、組織の学習と外部報告の両方に役立ちます。

M365環境でのログ収集・調査については「M365 Purview入門｜監査ログの取り方と活用」（公開予定）で解説します。Windowsイベントログを使った初動調査については「Windowsイベントログ調査入門｜インシデント発生時の初動調査」（公開予定）で詳しく解説します。

参考：インシデント対応ガイドライン | NIST SP 800-61

インシデント対応で現場がやりがちな失敗パターン

① 最初に証跡を消してしまう

「とりあえず再起動する」「怪しいファイルを削除する」——善意の対応が証跡を失う結果になります。再起動するとメモリ上の情報が消え、ファイルを削除すると攻撃者のツールや侵入経路の手がかりが失われます。何かアクションを取る前に「これは証跡を消す可能性がないか」を考える習慣を持ってください。

② 一人で抱え込む

「自分が対応できるから大丈夫」「報告すると責任を問われそう」という心理から、インシデントを一人で抱え込むケースがあります。インシデント対応は組織で動くものです。早期に上長や関係者を巻き込むことで、対応のスピードと品質が上がります。報告が遅れるほど、後から問われる責任は大きくなります。

③ 封じ込めを急ぎすぎて原因調査が不十分になる

「早くサーバを復旧させなければ」というプレッシャーから、原因が特定されないまま復旧してしまうケースがあります。原因不明のまま復旧した環境は、同じ手口で再侵害される可能性があります。「復旧の速さ」より「再発しない状態に戻すこと」を優先してください。

④ 事後対応を省略する

復旧したら終わり、という現場が非常に多くあります。原因分析・対策の実施・記録の整備が省略されると、同じインシデントが繰り返されます。インシデントは「対応コスト」ではなく「セキュリティレベルを上げるための情報」と捉えることが重要です。

インシデント対応体制を作る——個人でできることと組織で決めておくこと

インシデント対応は「起きてから考える」では遅いです。事前に準備しておくことで、いざというときの対応速度と品質が大きく変わります。

個人レベルで準備できること

• 自分が管理するシステムの「正常な状態」を把握しておく
• ログの取得設定と保存期間を確認しておく
• 上長・セキュリティ担当の連絡先を把握しておく
• 証跡保全の基本手順を知っておく

組織レベルで決めておくべきこと

• インシデント発生時の連絡・報告フロー（誰に・いつ・何を報告するか）
• 対応の役割分担（誰が指揮を執り・誰が技術対応し・誰が対外連絡するか）
• 対応優先度の基準（どの事象をインシデントとして扱うか）
• 外部への報告義務（個人情報保護法等の報告義務への対応）

CSIRT（Computer Security Incident Response Team） 組織内でセキュリティインシデントに対応するための専門チームまたは機能。大規模組織では専任チームを設置し、中小規模では兼任で機能を担うケースが多い。

最小権限の設計・ADのセキュリティ設計がインシデントの発生を抑制し、イベントログ監査が早期検知を可能にします。設計と監視の基礎については「若手インフラエンジニアが最初に身につけるべきセキュリティ知識10選」から読み始めることをおすすめします。

参考：組織における内部不正防止ガイドライン | IPA

インシデント対応チェックリスト

事前準備

• 管理するシステムの正常状態（ログ・通信・プロセス）を把握している
• 監査ログ・イベントログの取得設定と保存期間を確認している
• インシデント発生時の連絡フロー・報告先を把握している
• 証跡保全の基本手順を知っている

検知・トリアージ

• 何が影響を受けているか・いつから・どこまで広がっているかを把握した
• 攻撃の可能性がないか確認した
• 発生時刻・検知手段・影響範囲を記録した

初動対応

• 証跡（ログ・メモリ・ネットワークキャプチャ）を保全した
• 再起動・ファイル削除など証跡を消す操作を保全前に行っていない
• 上長・関係者への報告を行った

封じ込め

• 感染端末・侵害アカウントを隔離・無効化した
• 実施した措置・時刻・担当者を記録した
• 封じ込め範囲が十分か確認した

復旧・事後対応

• 原因を特定してから復旧作業を開始した
• 脆弱性の修正・設定変更を実施した
• 対応経緯・原因・再発防止策を記録した
• 関係者への最終報告を行った

まとめ——インシデント対応は「起きてから学ぶ」では遅い

セキュリティインシデントへの対応力は、設計・監視・対応フローの3つが揃って初めて機能します。

設計で攻撃の起点を減らし・監視で早期に異常を検知し・対応フローを知っておくことで被害を最小化する——この3つが「守れる設計」の全体像です。

今日確認すべきことは2つです。自分が管理するシステムで「インシデントが起きたとき、誰に最初に連絡するか」を確認してください。次に、ログが適切に取得・保存されているかを確認してください。この2つを把握しておくだけで、いざというときの対応速度が大きく変わります。

このカテゴリーでは、証跡保全・M365 Purviewでのログ調査・Windowsイベントログの読み方を順次解説していきます。

あわせてご覧ください

• ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド
• AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る
• AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務
• 最小権限の原則とは？実務での考え方と設計例
• 若手インフラエンジニアが最初に身につけるべきセキュリティ知識10選
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド