災害対策(BCP)
停止しても、決めた時間内に戻す。
地震・停電・広域障害でリージョンや拠点が失われても、事業を続けられる状態をつくります。まず目標を決め、その目標に見合う構成を選びます。
- 目標復旧時間・目標復旧地点の設定と合意形成
- マルチAZ/マルチリージョン構成の設計と構築
- データベースとストレージのレプリケーション設計
- DNS・ネットワークの切替方式の設計
- 復旧手順の整備と、手順のコード化
止まらないための備えと、消させないための備え。
目標復旧時間の設定から、AWSを活用した構成の設計・構築、復旧訓練を回せる基盤の整備、 そして運用設計まで。作って終わりではなく、いざというとき実際に動く状態でお渡しします。
問われているのは、取っているかどうかではなく、それで戻せるかどうかです。
目標復旧時間が決まっていないと、構成の良し悪しを判断する基準がありません。費用のかけどころも決まらず、議論が止まります。
ランサムウェアは、まずバックアップを狙います。本番と同じ権限で消せる場所に置いている限り、備えたことにはなりません。
復旧手順は書いた時点から古くなります。実際に切り替えてみないと、抜けている前提や権限に気づけません。
災害とサイバー攻撃では、守り方が違います。片方だけでは事業は続きません。
停止しても、決めた時間内に戻す。
地震・停電・広域障害でリージョンや拠点が失われても、事業を続けられる状態をつくります。まず目標を決め、その目標に見合う構成を選びます。
侵入されても、データは消させない。
権限を奪われた状態を前提に設計します。本番の権限では触れない場所に、変更も削除もできない形で残すことが要点です。
停止してから復旧までに許容できる時間。ここが決まらないと、どの構成を選ぶべきかが決まりません。
どの時点まで戻せれば許容できるか。バックアップの取得間隔とレプリケーション方式を決める基準になります。
どの工程からでもご相談いただけます。現状構成の評価だけ、訓練の基盤整備だけ、という形も可能です。
いまの構成でどこまで戻せるのかを確認し、業務への影響から目標復旧時間・目標復旧地点を決めます。ここが以降のすべての判断基準になります。
設定した目標に見合う構成を選びます。過剰にも過小にもならないよう、費用と復旧時間の見合いをお示ししたうえで決めます。
権限を奪われた状態を前提に、削除・変更ができない保管と、本番から隔離した退避先を設計します。暗号化鍵の分離もここで決めます。
設計した構成を Terraform / AWS CDK で構築します。復旧手順も可能な範囲でコードにし、人の記憶に依存しない状態にします。
訓練用の環境をコードから立ち上げられるようにし、実際に切り替えて戻すところまでご支援します。訓練で見つかった差分は構成と手順に反映します。
誰が・どの判断で・何を実行するのかを定めます。バックアップの成否確認、保管期間の見直し、定期訓練の回し方まで含めて設計します。
手順書だけでは、抜けている前提に気づけません。実際に切り替えてみて、 想定どおりに動かなかったところを直す。その繰り返しができる基盤を整えます。
本番に影響を与えずに復旧を試せる環境を、コードから何度でも立ち上げられるようにします。
切替と切り戻しの手順に沿って実際に動かし、所要時間と詰まった箇所を記録します。
訓練で見つかった差分を、構成・手順・運用設計に反映します。次の訓練の出発点になります。
目標復旧時間と予算に応じて、必要なものを選んで組み合わせます。すべてを使うわけではありません。
目標が定まっていない段階でも構いません。現状構成の評価からご相談を承ります。