Azure Backupで「VMのバックアップを取って、いざというとき復元する」ところまでは、意外とすぐにできるようになります。ところが実務で本当に怖いのは、その先です。せっかく取ったバックアップごと壊される・消される、リージョンまるごと落ちて復元先すら失う、そして気づいたら請求額がじわじわ膨らんでいる——このあたりを設計できて、はじめて「本番で守れている」と言えます。
この記事は、そもそもAzure Backupとは何かを解説した親記事 Azure Backupとは？VMのバックアップ・復元・ランサムウェア対策・コストを実務目線で解説 の子記事（保護・運用編）です。基本のバックアップ／復元は親記事に任せて、こちらは「バックアップごと壊されない／賢く残す／安く運用する」に特化して、公式ドキュメントの分かりにくいところを噛み砕いていきます。まだ全体像があやふやな方は、先に親記事に目を通しておくと、この記事の位置づけがはっきりします。
「バックアップは取ってるけど、ランサムウェアに感染したらそのバックアップも消されるって聞いて急に不安になった…どう守ればいいの？」
親記事では「Azure Backup＝クラウドの金庫」というたとえを使いました。この記事はその続きで、金庫の中身を守るだけでなく、金庫そのものを攻撃・災害・誤操作から守る話です。保険に入っているだけで安心せず、その保険証券自体を燃えない金庫にしまい、写しを別の街にも置き、金庫を開ける手続きを二人がかりにする——そんな「守りを固める」設計を、順番に見ていきましょう。読み終えるころには、本番の重要データを攻撃・災害・誤操作から守る運用像が描けるようになります。
バックアップポリシーとGFS保持を「写真の間引き」で設計する
守りを固める話に入る前に、まず土台となるバックアップポリシーの設計を押さえます。ポリシーとは「いつ取って、いつまで残すか」を定めたルールのことです。ここがぶれると、後段のセキュリティもコストも全部ぶれます。
そして保持を考えるときの王道がGFS保持（Grandfather-Father-Son／祖父-父-子）です。名前だけ見ると身構えますが、やっていることはスマホの写真整理とそっくりです。直近1週間の写真は全部残す。でも1年前は「イベントの1枚」だけ、10年前は「その年に数枚あればいい」——というふうに、古くなるほど残す密度を下げていく。これがGFSの発想そのものです。
Azure Backupのポリシーに当てはめると、日次（子）・週次（父）・月次（祖父）・年次を、それぞれ別々の保持期間で残していく形になります。ポータルのポリシー編集画面には、これらの保持を入れる欄がそれぞれ用意されていて、たとえば次のような組み合わせにします。
日次（子） … 毎日取得 / 30日保持 → 昨日・一昨日への細かい巻き戻し
週次（父） … 毎週日曜 / 12週保持 → 「先々週の状態」に戻る
月次（祖父）… 毎月1日 / 12か月保持 → 「半年前の月末」に戻る
年次 … 毎年1/1 / 7年保持 → 監査・法令対応の長期保存ポイントは、「直近は細かく、過去は間引いて長く」を1つのポリシーで同時に満たせることです。もし全部を毎日365日ぶん残そうとすると、保管量（＝ストレージ料金）が一気に膨らみます。でもGFSなら、監査で「7年保存」が求められる業種でも、年次だけを7年に伸ばせばよく、日次を7年持つ必要はありません。要件（どこまで戻せる必要があるか）とコストのバランスを取る、いちばん現実的な落としどころなのです。
拡張ポリシー（Enhanced Policy）という新しい選択肢
VMのバックアップポリシーを新規作成すると、いまは「標準（Standard）」と「拡張（Enhanced）」の2種類を選べます。ここで初心者がよく「どっち？」と固まるので、違いをはっきりさせておきましょう。
拡張ポリシーは、1日に複数回のバックアップ（時間単位バックアップ）ができたり、Trusted Launchが有効なVMなど新しめの構成に対応していたりする、より新世代のポリシーです。「1日1回では復旧ポイントの間隔が粗すぎる」「もっと直近に巻き戻したい」という要件があるなら拡張を選びます。一方で、拡張ポリシーは既定でスナップショットの保持期間が長めに取られるぶん、コストが増える面もあります。まずは要件に『1日複数回』が無ければ標準で十分、と割り切って問題ありません。
注意したいのは、標準ポリシーで運用中のVMを、あとから拡張ポリシーへ切り替えることはできない点です（逆方向も同様）。拡張を使いたいなら、保護を有効化するタイミングで拡張ポリシーを割り当てる必要があります。「あとで変えればいいや」が効かないので、最初に要件を確認しておきましょう。詳細は公式の Enhanced policy for Azure VM backup にまとまっています。
【最重要】ランサムウェア・誤削除からバックアップ自体を守る三重防御
ここがこの記事の主役です。近年、実務でもっとも重要になっているテーマで、いちばん厚く解説します。
ひと昔前は「バックアップさえ取っていれば安心」でした。ところが、ランサムウェア攻撃はその常識を崩してしまいました。最近の攻撃者は、サーバーを暗号化する前に、まずバックアップを探し出して削除・破壊しにきます。理由は単純で、バックアップが生きていれば身代金を払わずに復旧できてしまうからです。つまり「バックアップごと人質に取る」のが今の手口。金庫のたとえでいえば、泥棒が中身を盗む前に、まず金庫の鍵と予備の金庫を壊しにくるようなものです。
そこでAzure Backupには、「金庫そのものを守る」ための三重の防御が用意されています。この3つは重ねて使うほど強くなるので、1つずつ、なぜ効くのかを含めて見ていきます。公式の全体像は Overview of security features in Azure Backup にあります。
① 論理削除（Soft Delete）：消しても一定期間はゴミ箱に残る
論理削除は、バックアップデータが「削除」されてもすぐには物理的に消えず、一定期間（既定14日間）ゴミ箱状態で保持される仕組みです。攻撃者やオペミスでバックアップを消されても、その期間内なら復活させられます。PCのゴミ箱とまったく同じ発想ですね。
この機能のありがたいところは、Recovery Servicesコンテナーでは標準で有効になっていることです。特別な操作をしなくても、いったん消えても14日間は戻せる状態が最初から確保されています。とはいえ、既定の論理削除は設定を無効化することも可能なので、攻撃者が「まず論理削除をオフにしてから削除する」という手を打てる余地が残ります。
そこで本番向けには、常時オン（Always-on / 拡張された論理削除）を検討します。これは論理削除を「無効化できない」状態にロックする設定で、いったん有効にすると管理者ですらオフにできません。攻撃者が管理者権限を奪っても、論理削除だけは外せない——という守りが一枚増えるわけです。「消しても消えない」を、攻撃者にすら外させない、というイメージで捉えてください。
② 不変性（イミュータブル）：書き換え・早期削除そのものを禁じる
論理削除が「消しても14日間は戻せる」だとすると、不変性（イミュータブルVault）は一歩踏み込んで、そもそも書き換えも早期削除もできないようにロックする設定です。いったん保管した復旧ポイントは、保持期間が切れるまで誰も——管理者本人ですら——中身を取り出して書き換えられません。金庫でいえば「一度預けたら期限が来るまで開かない、開かずの金庫」です。
これがランサムウェア対策として強力なのは、攻撃者が管理者権限を奪ったとしても、不変ロックされた復旧ポイントは改ざんも削除もできないからです。攻撃者がよく使う「保持期間を1日に縮めて、すぐ期限切れにして消す」という裏技も、不変性の前では通用しません。保持期間を短くする方向の変更が拒否されるためです。
ここで大事な選択があります。不変性には「ロックを解除できる状態」と「ロックしたら二度と緩められない状態」の2段階があるのです。テスト中や設定を詰めている段階では前者（解除可能）にしておき、本番の重要データで「これはもう絶対に緩めない」と確信できたら後者（ロック確定）に上げる、という順番が安全です。いきなりロック確定にすると、設定ミスに気づいても直せなくなるので、まずは解除可能な状態で運用感を掴むのがおすすめです。
③ 多要素削除保護（MUA）：危険な操作に「二人目の承認」を要求する
三重防御の締めがMUA（Multi-User Authorization／多要素承認）です。これは、バックアップの削除・保護の停止・論理削除の無効化といった「取り返しのつかない危険な操作」に、もう一人の承認を必須にする仕組みです。
実現の仕組みが少しだけ独特なので噛み砕きます。MUAでは「Resource Guard」という別のガード役リソースを用意し、コンテナーの危険な操作をそのResource Guard越しに行うように縛ります。そして、そのResource Guardを管理する権限は別のアカウント（別の管理者やセキュリティチーム）に持たせておく。すると、コンテナーの管理者が「バックアップを削除したい」と操作しても、Resource Guard側の承認がないと実行できなくなります。
たとえるなら、核ミサイルの発射に二人の鍵が同時に必要な「ツーマンルール」です。攻撃者が1つのアカウントを乗っ取っても、削除操作には別の管理者の承認が要るため、単独ではバックアップを消せません。攻撃対策としてはもちろん、「うっかり本番のバックアップを消してしまった」という人為ミスの防止にも効きます。
MUAを設定するときは、Resource Guardを「守りたいコンテナーとは別のサブスクリプション」に置くのが定石。同じ場所に置くと、攻撃者にまとめて権限を奪われた瞬間に承認の壁ごと突破されてしまうからです。
この3つは、役割が少しずつ違うからこそ重ねる意味があります。論理削除で「消しても消えない」、不変性で「そもそも改ざん・早期削除できない」、MUAで「危険な操作に承認を挟む」。中身（VM）だけでなく金庫（コンテナー）そのものを守る——これが現代のバックアップ設計の勘所です。本番の重要データには、この三重防御を全部乗せる前提で設計しておくと安心です。
クロスリージョン復元（CRR）：地域まるごとダウンに備える
ここまでは「攻撃・誤削除からバックアップを守る」話でした。次は「リージョンごと使えなくなったらどうするか」という、一段大きな災害への備えです。
鍵になるのがコンテナーの冗長性設定です。コンテナー作成時に冗長性をGRS（geo冗長ストレージ）にしておくと、バックアップはペアリージョン（東日本なら西日本のような、あらかじめ決められた対のリージョン）にも自動で複製されます。この状態でクロスリージョン復元（CRR：Cross Region Restore）を有効にしておくと、元のリージョンが災害でダウンしていても、ペアリージョン側のコピーから復元できるようになります。
金庫のたとえでいえば、大事な書類のコピーを、別の街の支店の金庫にも置いておくようなもの。本店が火事になっても、別の街の支店からいつでも取り出せる、というわけです。
実務でつまずく3つのポイント
CRRは頼もしい機能ですが、いざ使おうとすると引っかかりやすいポイントがあります。
1つ目は、冗長性がGRSであることが大前提だということ。CRRはGRSの上でしか使えません。しかも冗長性の変更は「コンテナーにまだ何も保護していない状態」でないとできない場合があります。あとから「やっぱりCRRを使いたい」と思っても、すでにLRSで運用を始めていると簡単には切り替えられません。災害耐性が要るなら、コンテナーを作る最初の段階でGRS＋CRRを選んでおくのが鉄則です。
2つ目は、CRRは既定でオフだということ。GRSにしただけでは「複製されている」だけで、ペアリージョンから復元する機能自体は別途「有効化」の操作が要ります。コンテナーの「プロパティ」→「クロスリージョン復元」から明示的にオンにしてください。
3つ目は、復元操作のときにリージョンを切り替えるという点です。いざCRRで復元するときは、復元画面で復元元として「セカンダリリージョン」を選びます。ここを見落として一次リージョンのまま操作しようとすると「一次側がダウンしていて復元できない」と勘違いしがちです。手順の詳細は Restore VMs by using the Azure portal が参考になります。
なお、GRSはLRS（ローカル冗長）より料金が高くなります。すべてのVMにGRS＋CRRを付けるのではなく、「リージョン災害でも止められない本番の基幹データ」に絞って適用するのが、コストと災害耐性のバランスを取るコツです。この費用差については後半のコストの章で改めて触れます。
RBACと監視：Backup Centerで一元管理し、最小権限で委任する
コンテナーが1つ2つのうちはポータルを直接見れば済みますが、プロジェクトが増えてくると「どのVMがちゃんと取れてる？昨夜失敗したジョブはない？」を全体で見たいという悩みが必ず出てきます。そこで使うのがBackup Centerです。
Backup Centerは、複数のコンテナー・サブスクリプションをまたいでバックアップの状態を一元監視できる管理画面です。「昨夜バックアップに失敗したジョブはどれか」「保護されていないVMはないか」「もうすぐ保持切れになる復旧ポイントは」といった情報を横断的に確認できるので、運用のダッシュボードとして重宝します。コンテナーを1個ずつ開いて回る手間が要らなくなる、と考えると価値が伝わりやすいはずです。詳しくは Overview of Backup center にまとまっています。
権限は「所有者を配る」のではなく専用ロールで委任する
運用担当にバックアップを任せるとき、フルの所有者（Owner）権限を渡すのは避けたいところです。所有者を渡すと、コンテナーの削除やアクセス権の付与まで何でもできてしまい、これはまさに三重防御で守ろうとしている「危険な操作」ができる状態を、自分から作ってしまうことになります。
代わりに、目的に合ったバックアップ用の組み込みロールで委任します。代表的なのが次の2つです。
- バックアップ共同作成者（Backup Contributor）：バックアップの有効化・ポリシー設定・オンデマンド実行などができる。ただしコンテナー自体の削除やアクセス権の付与はできないので、日々の運用担当に渡すのに向く。
- バックアップオペレーター（Backup Operator）：バックアップの実行や復元はできるが、ポリシーの変更はできない、より限定的なロール。「決められた運用をこなす人」向け。
「バックアップを運用する人」に、金庫を建て直す権限（コンテナーの削除）まで渡す必要はありません。最小権限で委任する——この考え方は、前半で見たMUAの「危険な操作には承認を挟む」という思想と一直線につながっています。ロール割り当ての基本的な考え方は 【初心者向け】Azure RBACとは？ロール割り当ての3要素と組み込みロールを実務目線で解説 で噛み砕いているので、あわせて読むと「なぜ組み込みロールで委任するのか」が腹落ちします。
コスト：料金は「保護インスタンス＋ストレージ」で決まる
最後は、地味だけど後で効いてくるコストの話です。守りを固めるほど保管量は増えがちなので、料金の決まり方を理解しておかないと請求額に驚くことになります。
Azure Backupの料金は、大きく2つの要素の足し算で決まります。
- 保護インスタンス料金：保護している対象（VMなど）1つあたりに、そのサイズに応じてかかる固定的な料金。「守っている対象の数」で効いてくる部分。
- バックアップストレージ料金：実際に保管しているデータ量に対してかかる料金。「どれだけ、どんな冗長性で残しているか」で変わる部分。
ここで、これまでの章で出てきた設計がそのままコストに跳ね返ることに気づいてほしいのです。GFSで「古いものを間引く」ほどストレージ料金は下がり、逆に日次を長期保持すれば上がる。CRRのためにGRSを選べば、LRSよりストレージ単価が高くなる（別リージョンにも複製を持つぶんの費用）。守りを厚くする判断は、たいていコスト増とセットなのです。
冗長性の選び方でコストが変わる
コスト最適化でいちばん効くのが冗長性の選択です。ざっくり整理するとこうなります。
- LRS（ローカル冗長）：同じリージョン内で複製。最も安いが、リージョンまるごと落ちると復元不可。開発・検証環境や「消えても致命傷でない」データ向け。
- GRS（geo冗長）：ペアリージョンにも複製。CRRが使える。料金は高いが、リージョン災害に耐えられる。本番の基幹データ向け。
- ZRS（ゾーン冗長）：同一リージョン内の複数の可用性ゾーンに複製。データセンター単位の障害に強い中間の選択肢。
ありがちな失敗は、何も考えず全部GRSにしてしまうことです。災害耐性は上がりますが、開発環境のVMまでGRSにすると、要らない冗長性にお金を払い続けることになります。「このデータはリージョン災害でも守る必要があるか？」を1本ずつ問い、必要なものだけGRS＋CRRにするのが、コストと安全の両立です。
もう1つ効くのが保持期間の見直しです。「念のため」で日次を1年ぶん持ち続ける、といった保持は、静かにストレージ料金を押し上げます。前半のGFSに立ち返り、日次は短く・年次だけ長くのメリハリを付けるだけで、体感できるレベルでコストが変わります。実際の単価はリージョンや時期で変動するので、正確な数字は公式の Azure Backup pricing と料金計算ツールで確認してください。
ちなみに、こうした「使っていない冗長性・過剰な保持でムダに払っている」状態は、Azure Advisor のコスト推奨からも気づけることがあります。守りを固めつつ払いすぎない——この両立を助けてくれる相棒として、あわせて使うと運用がラクになります。
まとめ：攻撃・災害・誤操作の三方向から守れるようになった
この記事では、Azure Backupで「バックアップごと壊されない／賢く残す／安く運用する」ための守りを、実務でつまずく順に見てきました。要点を振り返っておきます。
- ポリシー／GFS保持：写真の間引きと同じで「直近は細かく、過去は間引いて長く」。要件とコストを1つのポリシーで両立。1日複数回が要れば拡張ポリシーを、なければ標準を。
- 三重防御（最重要）：論理削除で消しても戻せる、不変性で改ざん・早期削除を封じる、MUAで危険な操作に二人目の承認を要求。重ねて全部乗せが本番の勘所。
- CRR：GRSでペアリージョンに複製し、地域まるごとダウンに備える。最初にGRS＋CRRを選ぶ／既定オフを有効化／復元時はセカンダリを選ぶ、の3点に注意。
- RBACと監視：Backup Centerで横断監視。運用は所有者ではなくバックアップ共同作成者／オペレーターで最小権限委任。
- コスト：料金は「保護インスタンス＋ストレージ」。冗長性（LRS/GRS/ZRS）と保持期間の選び方で大きく変わる。守りとコストはセットで判断。
ここまで設計できれば、本番の重要データを、ランサムウェア攻撃・リージョン災害・誤操作という三方向から守れるようになりました。バックアップを「取っているだけ」から「壊されても、消されても、地域が落ちても復旧できる」状態へ——これが、守りを固めるということです。
あわせて読みたい：
