DR（Disaster Recovery／災害復旧）とは、災害やシステム障害、サイバー攻撃で停止したシステムを復旧し、サービスを再開するための備えと手順です。バックアップがデータのコピーを残す作業なのに対し、DRにはサーバーやネットワークの再構築、動作確認、復旧先への切り替えまで含まれます。
マルチクラウドDRは、複数のクラウド事業者を使って復旧に備える構成です。たとえばAWSで動かしているWebサイトのデータをAzureにも保管し、必要なときにAzure側でサービスを再開できるようにします。
WebサイトのDRでは、別リージョンへの切り替えだけを考えがちです。ランサムウェアは、その前提を崩します。攻撃者は本番に加えて、オンラインのバックアップや管理アカウントも狙うからです。
守るべき境界はクラウド名ではありません。認証、削除権限、暗号鍵、ネットワークを本番から分け、侵害前のデータを隔離環境へ戻せる状態を作ります。
障害対策とサイバー復旧
機器故障やリージョン障害では、正常なデータが残っている前提で待機系へ切り替えます。ランサムウェアでは直近のコピーも安全とは限りません。侵入前の世代を選び、検査してから公開します。
目標はRPOとRTOで決めます。RPOは許容できるデータ損失、RTOは再開までの時間です。バックアップの完了時刻ではなく、隔離、復元、検査、切り替えまでを測ります。
消されないバックアップ
保存期間中のデータを削除できないWORMやイミュータブルストレージを使います。AWS Backup Vault Lock、Azure Blobの不変ストレージ、Google Cloud Backup and DRのBackup vaultが代表例です。
保持ポリシーは、転送と復元を試してからロックします。ロック後に期間を短縮できない設定では、誤った保存期間も費用もすぐには戻せません。
管理権限の分離
本番とバックアップを同じSSOと管理者で運用すると、一つの認証情報から両方を失います。バックアップは別アカウントか別サブスクリプションへ置き、重要度が高ければIDテナントも分けます。
本番管理者には、保管済みデータの削除と保持期間の変更を許可しません。復元や設定変更は別担当者が承認し、暗号鍵と監査ログも本番から離します。
オンプレとVPCからの退避
オンプレやVPCからは、バックアップ用ゲートウェイを経由して別クラウドへ送信します。保管庫から本番へ自由に接続できる双方向経路は作りません。
仮想マシンのスナップショットだけでは不十分です。データベースは整合性の取れたバックアップとトランザクションログを残します。IaC、コンテナイメージ、DNS、WAF、証明書、復旧用の認証情報も必要です。データが戻っても、これらがなければWebサイトは再開できません。
復旧先の選び方
全機能を二つのクラウドで常時稼働させると、費用と運用負荷が増えます。ログイン、主要画面、注文や問い合わせなど、再開を急ぐ機能だけを待機させます。管理画面や集計はIaCから構築する方が扱いやすいでしょう。
別クラウドのデータベースへ戻す場合は、エンジンのバージョン、拡張機能、文字コード、接続方式を事前に合わせます。復旧当日に互換性を調べ始める構成は避けます。
AWSからAzureへの実装例
ここでは本番をAWS、退避先をAzureとします。MABS/DPMはAWS EC2などパブリッククラウド上の仮想マシンをバックアップ対象にしていません。AWS側で復元可能なデータを作り、Azure Blobへ送ります。
- Azureにバックアップ専用のサブスクリプションとStorage Accountを作る
- Blobのバージョン管理と時間ベースの保持ポリシーを設定する
- AWSのプライベートサブネットで、DBバックアップとファイルを日時別のパスへ出力する
- Microsoft EntraのWorkload identity federationを使い、長期シークレットを置かずに転送する
- Azure側の権限を作成と書き込みに絞り、削除と保持設定の変更を許可しない
- 隔離VNetへ定期復元し、件数、ハッシュ、主要機能を確認する
小規模なら送信HTTPS通信で始められます。閉域経路が必要ならAWS Site-to-Site VPNとAzure VPN GatewayをIPsecで接続し、Azure側VNetからBlobのPrivate Endpointへ到達させます。
本番がAzureで退避先がAWSなら、Azure Blobの不変ストレージをS3 Object Lockへ、Azureサブスクリプションを別AWSアカウントへ読み替えます。IDと削除権限を分ける原則は同じです。
復旧の手順
侵害された本番へ直接復元すると、マルウェアや漏えいした認証情報まで戻すおそれがあります。復旧は別アカウントの隔離環境で進めます。
- 侵害アカウントとネットワークを隔離する
- ログから侵入時期を調べ、それより前の世代を選ぶ
- 隔離環境へ復元し、マルウェアと設定変更を検査する
- 管理者、APIキー、証明書を交換する
- ログインや注文などの主要業務を確認する
- DNSやロードバランサーを切り替える
起動しただけでは復旧完了にしません。利用者が実行する主要操作まで通ったことを確認します。
復元演習
バックアップ成功の表示は、復旧できる証明になりません。定期的に実データを隔離環境へ戻し、公開可能になるまでの時間と失ったデータ量を測ります。
目標を超えたら、バックアップ頻度、待機範囲、自動化する手順を見直します。担当者を替えても戻せるか試すと、手順書の抜けも見つかります。
小さく始める順番
最初から本番一式を二重運用する必要はありません。
- 重要データのRPOとRTOを決める
- 別アカウントに変更不能なコピーを作る
- 管理者、ID、暗号鍵を本番から分ける
- 別クラウドの隔離環境へ実データを復元する
マルチクラウドDRの価値は、クラウドを二つ契約することではありません。本番の侵害から切り離したコピーを、自分たちの手で戻せることです。
