# 復旧計画の実行 ## 定義 復旧計画の実行(executing the recovery)とは、セキュリティインシデントにおいて攻撃者を環境から安全に追い出し、システムを既知の良い状態(known-good state)へ戻すための運用判断・体制・チェックリストの総体を指す。中心にあるのは「攻撃者は復旧行動そのものを観察し反応しうる能動的な主体である」という前提であり、この前提が、信頼性障害からの復旧(第8・9章が扱う設計時の機構)とセキュリティインシデントからの復旧を分ける核心である。復旧計画の実行は、(1) 攻撃者をいつ追い出すか(タイミング)、(2) 攻撃者を追い出す短期的な緩和策と組織の長期的なセキュリティ体制強化との間のトレードオフ(即時緩和対長期改善)、(3) 誰が何を担当し何を確認したかを可視化する復旧チェックリストの設計、という 3 つの実務的な柱で構成される。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 18 Recovery and Aftermath]] §Recovery Considerations, §Recovery Checklists) ## 攻撃者追い出しのタイミングとトレードオフ 攻撃者を追い出すタイミングの原則は「攻撃の全容を理解するまで待つ」ことである。全容を理解しないまま攻撃者を追い出すと、攻撃者は自分の行動が察知されたことを他の侵害済みシステムから観測でき、証拠隠滅やインフラ破壊などの予測できない反撃に転じるリスクがある。ただし、データ窃取やシステム破壊など生命・重大データに関わる差し迫った危険がある場合は、全容解明を待たずに行動する判断も正当化される。この場合、対応チームは攻撃者との「チェスの対局」に入ることを自覚し、後続の一手まで見据えて動く必要がある。 追い出しのための短期的な緩和策(例: 手動でのファイアウォール規則追加、通常のピアレビュー・バージョン管理プロセスの一時的な迂回)は、ほぼ必ず技術的負債を生む。この負債への対処方針は緩和策を導入する時点で明示しておくべきで、具体的には「いつ・どうやってこの緩和策を撤去するか」「その負債を組織のどのチームが引き受けるか」「エラーバジェットへの影響はどの程度か」「緩和策が長期間放置された場合の被害はどの程度か」「ドメイン知識のない将来のエンジニアが撤去の安全性をどう証明できるか」を問うことが推奨される。 ## 横断的知見 - **第9章が設計時に用意する「機構の速度とポリシーの分離」は、本章が運用の場で下す即時緩和/長期改善のトレードオフ判断を可能にする前提条件として機能する**: [[復旧のための設計]] が集約するとおり、第9章は復旧機構自体は最速で動作するように設計し、実際にどれだけ速く動かすかは独立したポリシー層(レートリミッティングマイクロサービス等)で制御すべきだと説く。本章(第18章)が扱う「短期的な緩和策としてどこまで技術的負債を許容するか」という判断は、まさにこの分離されたポリシー層の運用側の意思決定に他ならない。第9章が機構の設計原則を示し、第18章がその機構をインシデント対応の現場でどう「絞る」かの判断基準を示すという分業関係にあり、両者を合わせて初めて「設計された復旧能力を、実際の攻撃者相手にどう使うか」という一連の流れが完成する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] §Design to Go as Quickly as Possible (Guarded by Policy), [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 18 Recovery and Aftermath]] §What are your mitigation options?) - **「調査チームと対応チームを分離し並列化する」というパターンは、危機の最中(第17章)と復旧フェーズ(第18章)という時間軸上の異なる局面で、それぞれ独立に採用されている**: [[危機時の指揮系統]] が集約するとおり、第17章は危機発生後の指揮・統制そのものの並列化(IC のもとでのチーム編成、引き継ぎ、follow-the-sun ローテーション)を扱う。本章は一段進んで、調査チームと復旧(修復)チームという**役割の異なる 2 つの並列チーム**を編成すべきだと説き、その理由として「調査は長時間の集中作業で疲弊が早い」「復旧は調査の完了を待たず始まることが多い」「必要スキルが異なる」を挙げる。第16〜18章は準備(16)→指揮の維持(17)→役割分担の並列化(18)という時間軸上の異なる粒度で「並列化」という同じ設計思想を反復的に適用しており、書籍全体として並列化がインシデント対応の随所で繰り返される中心原則であることが分かる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Parallelizing the Incident, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 18 Recovery and Aftermath]] §Recovery Logistics) - **攻撃者を観察者として意識したコミュニケーション経路の切り替えは、第17章の運用セキュリティと本章の復旧ロジスティクスで独立に、しかし異なる目的から要請される**: [[インシデント対応時の運用セキュリティ]] が集約する第17章は、調査活動そのものを攻撃者に気づかれないよう秘匿することを目的として通信チャネルの分離を説く。本章第18章は、秘匿というより「攻撃者に見られている情報共有基盤で復旧計画そのものを話し合うと、攻撃者がその計画に対抗する行動を先回りして取れてしまう」という、より直接的な運用上のリスク回避を目的として、攻撃者から隔離した新しい通信基盤(新規チャットシステム・安価な新規端末等)への切り替えを推奨する。手段(通信経路の分離)は同一だが、動機(調査の秘匿 vs 復旧計画の防御)が異なる点は、両概念を並べて初めて見える。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Operational Security, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 18 Recovery and Aftermath]] §Recovery Logistics) ## 未解決の問い - 「機構の速度とポリシーの分離」(第9章)が実際にどれだけ効果的に働くかは、復旧の現場で緩和策の技術的負債がどの程度・どれだけの期間放置されるかという実測データに依存するはずだが、本書はこの分離がもたらす定量的な効果を示していない。技術的負債の放置期間と実際のインシデント再発率の相関を検証した研究はあるか。 - 攻撃者を追い出すタイミングの判断(全容解明を待つか、即座に行動するか)を支援する定量的な基準(例えば「被害額の増加速度」や「データ露出範囲の拡大速度」を閾値化する)は存在するか。本章は定性的な判断基準(生命・重大データへの差し迫った危険)しか示していない。 - 調査チームと復旧チームの並列化(本章)と、第17章の IC 主導の指揮系統の並列化は、実務上どちらが先に立ち上がりどちらが後から統合されるのか。両者の連携が破綻するとどのような失敗モードが起こりうるか。 - 復旧チェックリスト(Figure 18-1 のテンプレート)は、[[危機時の指揮系統]] が扱う引き継ぎ(handover)の仕組みとどう統合されるべきか。長時間化する復旧でチェックリストの担当者自体が交代する場合の運用パターンは本章に記述がない。 ## 関連 - 概念: [[復旧のための設計]](設計時の復旧機構。本概念は運用時の実行を扱う点で棲み分ける) / [[ポストモーテム]](復旧完了後の事後分析) / [[危機時の指揮系統]] / [[インシデント対応時の運用セキュリティ]] / [[ゼロトラスト]] - 実体: [[BeyondCorp]](ゼロトラストによる隔離の平時からの強化) - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 18 Recovery and Aftermath]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] - 関連 MOC: なし(新規 concept) ## 出典 - Alex Perry, Gary O'Connor, and Heather Adkins (with Nick Soda), "Recovery and Aftermath", in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 18. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 9, §Design to Go as Quickly as Possible (Guarded by Policy). - Matt Linton (with Nick Soda and Gary O'Connor), "Crisis Management", in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 17.