インシデント対応

インシデント対応とは

インシデントとは、情報の機密性・完全性・可用性が損なわれた、または損なわれるおそれのある事象です。不正アクセス、マルウェア感染、情報の誤送信、設定ミスによる公開などが該当します。

インシデント対応(Incident Response)は、そうした事象を検知し、被害を止め、復旧し、再発を防ぐまでの一連の活動です。前提にあるのは「防御は完璧にはならない」という現実的な認識で、だからこそ起きたときにどう動くかをあらかじめ決めておきます。

対応の6ステップ

順番が大事です。原因究明より先に封じ込めを行います。調査に時間をかけている間にも被害は広がるためです。一方で、封じ込めの際に証拠を消してしまうと後の調査ができなくなるので、ログやディスクの保全を並行して行います。

準備段階でやっておくこと

実際の対応の質は、事前準備でほぼ決まります。

• 連絡体制 — 誰が指揮を執り、誰が判断し、誰が外部に連絡するか。どの程度から責任者に上げるかの線引きも決めておく
• [[ログ設計]] — 調査に必要なログが、必要な期間残っているか。ログがなければ被害範囲すら分かりません
• [[監視とアラート]] — 異常を人が気づける形にする。検知が遅れるほど被害は膨らみます
• [[バックアップとリカバリ]] — 復旧の生命線。復元テストを済ませたものだけが、いざというとき頼りになります
• 訓練 — 手順書は机上演習で動かしてみて初めて使えるものになります

検知が遅れる理由

インシデントは「派手に壊れる」とは限りません。静かに情報を抜き続ける種類のものは、長期間気づかれないこともあります。監視がサービスの稼働だけを見ていて不審な挙動を見ていない、ログは取っているが誰も見ておらずアラートにもなっていない、「たまに出る変なエラー」として片付けられている、といった状態が典型です。

普段の状態を把握していないと、異常も判別できません。[[監視とアラート]] は平常時の姿を知るための投資でもあります。

振り返りの作法

対応後の振り返りでは、人ではなく仕組みを責めるのが原則です。[[SRE]] の分野で広まったポストモーテム(事後検証)の考え方で、非難しない姿勢(ブレームレス)を徹底します。担当者を責める文化になると、次から報告が遅れ、被害が拡大するからです。記録に残すのは、時系列(いつ何が起き、誰が何をしたか)、影響範囲、根本原因と検知が遅れた理由、そして担当者と期限を伴う改善アクションです。原因が既知の脆弱性であれば、[[脆弱性管理とCVE]] の運用そのものを見直す必要があります。

初学者向けポイント

• 「やってしまった」と思ったときこそ、隠さずすぐ報告が最善手です。初動の遅れが被害を何倍にもします
• 個人情報の漏洩など、法令で報告が義務づけられる事案があります。技術的な復旧だけで終わりではありません。障害対応と流れはよく似ているので、日頃の障害対応をきちんとやることがそのまま訓練になります

関連技術とのつながり

• [[ログ設計]] — 調査と被害範囲の特定に不可欠な記録
• [[監視とアラート]] — 検知を早め、被害を小さくする
• [[脆弱性管理とCVE]] — 根絶と再発防止の中心的な運用
• [[バックアップとリカバリ]] — 復旧手段の確保
• [[SRE]] — ポストモーテムなど振り返りの実践
• [[デプロイ戦略]] — リリース起因の事故では、前のバージョンへの切り戻しがそのまま封じ込めの手段になる

Q: インシデント対応で、原因の詳細な究明より先に行うべきなのはどれ?
- [x] 被害の拡大を止める封じ込め
- [ ] 再発防止策の文書化
- [ ] 振り返り会の日程調整
解説: 調査中も被害は広がるため、まず封じ込めで拡大を止め、証拠の保全を並行して行います。

Q: 事前準備として本文で挙げられているのはどれ?
- [ ] 攻撃者の身元を特定する技術の習得
- [x] 復元テストまで済ませたバックアップの用意
- [ ] すべてのログの即時削除
解説: 復元テストをしていないバックアップは復旧時に頼れません。ログは調査に必要なので保全します。

Q: 振り返り(ポストモーテム)の原則として正しいのはどれ?
- [ ] ミスをした担当者の責任を明確にして処分する
- [x] 人を責めず、仕組みの改善に焦点を当てる
- [ ] 記録は残さず口頭で共有する
解説: 非難する文化は報告の遅れを招きます。ブレームレスに仕組みを改善するのが原則です。