インシデント対応

一言でいうと

システムの障害やセキュリティ上の攻撃が起きたときに、検知から影響の抑制、復旧、再発防止までを、事前に決めた手順と役割分担で進める活動です。

提唱者と登場年

米国国立標準技術研究所（NIST）は、2004年1月にSP 800-61「Computer Security Incident Handling Guide」を発行しました。このガイドは、インシデント対応の体制づくり、担当者の選定と訓練、検知と分析、種類ごとの対処を扱っています。改訂を重ね、2025年4月に公開された第3版は、NISTのサイバーセキュリティフレームワーク（CSF 2.0）に沿って、インシデント対応をリスク管理全体に組み込む内容になりました。

セキュリティとは別に、サービスの障害対応の分野では、GoogleがSRE本の第14章で役割分担の型を示しています。インシデントコマンダー、実際にシステムを操作する担当、関係者への連絡を担う担当、長期的な作業を計画する担当を分けるという内容です。

何を解決するか

障害の最中に、誰が何を判断するかで混乱し、復旧が遅れる事態を防ぎます。複数の担当者がそれぞれの判断でシステムを操作すると、状況の把握が難しくなり、別の障害を引き起こすことがあります。SRE本は、障害の間にシステムを変更するのは操作の担当だけにするべきだとしています。

もう一つの目的は、関係者への情報の共有です。影響の範囲、見通し、次の報告の時刻を決まった担当が定期的に伝えることで、問い合わせへの対応に復旧の担当者の時間が奪われることを防ぎます。

実際の進み方

監視やアラート、利用者からの報告で異常を検知したら、重大度を判定してインシデントとして宣言します。SRE本は、宣言が遅れるよりも早めに宣言するほうがよいとしています。インシデントコマンダーが役割を割り当て、影響を抑える措置と復旧を進めます。

対応中は、判断と操作の経過を共有の文書に記録します。復旧後はポストモーテムを行い、原因と再発防止策をまとめます。SRE本は、手順を普段から使わないと対応の熟練度がすぐに下がるとし、日常的な利用と訓練を勧めています。

導入でよくある失敗

• 手順書を作っても訓練をせず、実際の障害で誰も手順に従わない
• 重大度の基準が曖昧で、宣言するかどうかの判断に時間がかかる
• ポストモーテムが個人の責任追及になり、原因の報告が上がらなくなる

求人票にこの語がある場合に読み取れること

SREやインフラの求人にインシデント対応とある場合、オンコール（勤務時間外の呼び出し対応）の有無と頻度が条件に関わります。セキュリティの求人では、CSIRTのような社内の対応チームに加わる役割を指すことがあります。候補者には、インシデントコマンダーを務めた経験、ポストモーテムで決めた再発防止策とその結果を確認してください。

隣接手法との違い