第7章：復旧とロールバック判断（暫定/恒久、リスク管理）
この章で学ぶこと
- 暫定と恒久を分けて考える
- ロールバック判断の基準を持つ
- 復旧によるリスク（副作用）を評価する
- 封じ込め、根絶、復旧の目的と完了条件を分ける
成果物（または判断基準）
- 復旧方針（暫定/恒久）と判断根拠
- ロールバック手順と検証項目
本文
復旧判断は“正しさ”ではなく“リスク最小化”で行う。まず暫定対応で影響拡大を抑止し、恒久対応は状況安定後に実施する。
封じ込め・根絶・復旧の境界
セキュリティ疑いでは、サービスが応答することと侵害要因が除去されたことを分けて判断する。3段階は並行または反復する場合があるが、各段階の完了状態を混同しない。
| 段階 | 目的 | 最小の完了条件 |
|---|---|---|
| 封じ込め（Containment） | 進行中の被害と影響範囲の拡大を止める | 悪用中の経路、権限、通信、公開範囲を制御し、監視で拡大停止を確認した。暫定措置と残る侵害要因を記録した |
| 根絶（Eradication） | 侵害要因、永続化、悪用可能な認証情報を除去する | 原因となる脆弱性/設定、不要な権限、永続化、侵害済み認証情報を特定して除去・失効し、再確認の証跡を残した |
| 復旧（Recovery） | 信頼できる状態から資産と業務を安全に戻す | 復元元/変更内容の信頼性を確認し、段階的に再開して、セキュリティ指標と業務指標の安定、残リスクの承認を確認した |
ロールバック、機能フラグ OFF、通信遮断で影響が止まっても、それだけでは根絶完了ではない。根絶が未完了のまま限定的に再開する場合は、補完統制、承認者、監視条件、停止条件、期限、残リスクを記録し、インシデントを close しない。
NIST SP 800-61 Rev. 3 の Table 1 は、旧モデルの Containment, Eradication & Recovery を CSF 2.0 の Respond / Recover と、Identify 配下の Improvement Category に対応付ける。本書では、封じ込め・根絶・復旧の3段階を Respond / Recover における運用判断の最小分解として扱う。Improvement は4番目の完了段階ではなく、全Functionの活動から得た教訓を集約し、全Functionの改善へ反映する別の区分である。製品別の実装手順は扱わない。
セキュリティ疑い時の再開前後確認
- 再開前: 証跡を保全し、進行中の侵害経路を閉じる。再開対象が信頼できる状態か、認証情報の失効/ローテーション、永続化除去、必要な補完統制、承認者、再停止条件を確認する
- 再開後: 段階的にトラフィック/機能を戻し、不審なアクセス、権限逸脱、同一アラート、データ不整合、業務影響の再発を監視する。根絶と復旧の各完了証跡、残リスク、フォローアップ Issue を更新する
判断の観点
- 影響（継続時間と範囲）
- ロールバック可否
- 副作用（データ整合性、再発）
- 恒久対応の見通し
ロールバック判断マトリクス（例）
| 観点 | 確認する問い | ロールバック寄り（例） | 慎重/回避寄り（例） |
|---|---|---|---|
| 影響 | 顧客影響は大きいか、継続しているか | 売上/主要機能に影響、悪化傾向 | 影響が限定/回避可能 |
| 可逆性 | 変更は戻せるか | アプリのみ変更、手順が確立 | DB 変更/外部副作用が大きい |
| データ整合性 | 戻すことで壊れるデータはあるか | 影響なし/検証観点が揃っている | 片側だけ戻すと不整合が出る |
| 見通し | 恒久修正の見込みは立っているか | 修正に時間がかかる/不明 | すぐ直せる、影響小 |
| 検証 | 戻した後に「良くなった」を判定できるか | SLI/エラー率等で判定可能 | 判定指標がない/観測できない |
復旧（Recovery）の完了条件
「戻ったように見える」だけでは復旧完了にしない。少なくとも次を確認する。
| 観点 | 確認すること |
|---|---|
| サービス指標 | エラー率、レイテンシ、成功率、キュー滞留などが基準内に戻ったか |
| 業務影響 | 顧客影響、未処理データ、手動補正、問い合わせ対応が残っていないか |
| 再発兆候 | 同じアラートやログ異常が再発していないか |
| セキュリティ疑い | 根絶状態、認証情報、権限、永続化、外部共有先、再開後の監視結果を確認したか |
| 記録 | 復旧判断、検証指標、残リスク、フォローアップ Issue を残したか |
セキュリティ疑いでは、単にサービスを再開するだけでは不十分である。封じ込め、根絶、復旧を別々に判定し、根絶未完了ならその状態と補完統制を明示する。各完了証跡、ログ保全、通知判断、残リスクの承認が揃うまで、インシデント全体の完了を宣言しない。
典型の難所（例）
- DB マイグレーション等の“戻せない変更”: ロールバックではなく forward fix（前進修正）や復旧手順（復元/再適用）が必要になることがある
- 機能フラグ/段階リリース: 影響を抑止（フラグ OFF）→原因特定→恒久修正の順にしやすい
- 部分ロールバック: 片側だけ戻すと互換性（API/スキーマ/データ形式）で副作用が出やすい。境界を明確にして実施する
具体例（場当たり→再現性）
悪い例（場当たり）
原因が分かるまで何もしない
ロールバック手順が無い
良い例（再現性）
暫定: 機能フラグ OFF で影響を抑止する
恒久: 原因特定後に修正 PR
ロールバック: 手順/検証を Runbook（運用手順書）へ記録
判断根拠: 影響と副作用を比較
チェックリスト
- 暫定/恒久が分離されている
- 封じ込め、根絶、復旧の状態と完了証跡が分離されている
- サービス再開だけを根絶完了としていない
- ロールバック可否が評価されている
- 検証項目がある
- 復旧完了条件と残リスクが記録されている
まとめ
- 暫定と恒久を分離し、復旧判断は影響とリスク（副作用）を軸に行う
- 封じ込め、根絶、復旧を別々に判定し、サービス再開だけで根絶完了としない
- ロールバック可否、復旧完了条件、残リスクを整理し、判断の再現性を確保する
- 手順は Runbook（運用手順書）として整備し、実施後の検証までを含めて運用する
次章への接続
- 次章: 第8章