Azure Disk Encryption（ADE）で暗号化した Azure VM を、その状態のまま Azure Site Recovery（ASR）でレプリケーションしたい――本番環境ではよくある要件です。この記事では「そもそもできるのか？」という疑問に対する結論だけでなく、権限設計・Key Vault 設計・クロスサブスクリプション構成まで含めて、運用でつまずきやすいポイントをまとめて解説します。
ADE 暗号化された Azure VM のレプリケーションは可能か？
最初に結論を整理します。
- Azure Disk Encryption（ADE）有効化済みの Windows VM は、Azure Site Recovery（ASR）でレプリケーション可能です。
- ASR は ADE あり／なしの Windows VM の DR を公式にサポートしており、暗号化キー／シークレットはレプリケーション有効化時に ユーザーの権限コンテキストでターゲット側 Key Vault にコピーされます。
- 別サブスクリプションへのレプリケーションもサポートされています。ただし 同一 Microsoft Entra テナント内であることが必須です。
- テナントをまたぐレプリケーション（クロステナント）はサポート外です。
ざっくり可否だけを整理すると、次のようになります。
| 観点 | 可否 | 補足 |
|---|---|---|
| ADE 有効化 Windows VM を ASR で他リージョンへ DR | ○（サポート） | ADE 0.1 / 1.1 ともにサポート（条件あり）。Linux は ADE 1.1 のみ。 |
| 同一テナント内・別サブスクリプションへの DR | ○（サポート） | ソース／ターゲットとも同一 Entra テナント配下であれば選択可能。 |
| テナントをまたいだ DR（クロステナント） | ×（非サポート） | ASR の設計上サポート対象外。 |
| Azure Policy を使った「自動 ASR 有効化」かつクロスサブスクリプション | ×（非サポート） | Policy ベースの ASR 有効化はクロスサブスクリプション非対応。 |
ここからは、どのような前提と設計を満たせば ADE 暗号化 VM のクロスサブスクリプション DR がうまく動くのかを、もう少し実務レベルで掘り下げていきます。
前提整理：Azure Disk Encryption と ASR の基礎
Azure Disk Encryption のバージョンとサポート条件
Azure Disk Encryption は「Microsoft Entra ID（旧 Azure AD）を前提とする従来版」と「Entra ID を不要とする新しい版」の 2 系統があります。公式ドキュメントでは Windows VM 向けに ADE 0.1（Entra 必須） と ADE 1.1（Entra 不要） が明記されています。
| 項目 | ADE 0.1（旧版） | ADE 1.1（新版） |
|---|---|---|
| Entra ID（Azure AD）の利用 | 必須（アプリケーション ID 等の指定が必要） | 不要（Entra アプリなしで暗号化可能） |
| ディスク種別 | マネージド／アンマネージド両方 | マネージドディスクのみサポート（アンマネージド非対応） |
| ASR による DR サポート（Windows） | サポート（後述の制約あり） | サポート（推奨） |
| Linux VM | ASR は非サポート | ADE 1.1（Entra 不要版）のみサポート |
| ASR 設定変更時の注意 | ADE 1.1 へ移行する場合、一度レプリケーションを無効化してから再度有効化が必要。 | キー回転時など、一部操作ではレプリケーションの再構成が必要（後述）。 |
また、ADE 自体はすでに 2028 年 9 月 15 日にリタイア予定であることがアナウンスされています。新規ワークロードでは Encryption at host の利用が推奨されている点も頭の片隅に置いておきましょう。
ディスク暗号化キーと Key Vault の役割
ADE では、概ね次のような構成でディスクが暗号化されます。
- VM 上の BitLocker が ディスク暗号化キー（DEK） を用いて OS／データディスクを暗号化
- DEK をさらに Key Encryption Key（KEK） でラップする構成も選択可能
- これらのキー情報（シークレット／キー）が Azure Key Vault に格納される
- Key Vault は基本的に VM と同じリージョン＆サブスクリプション 内に存在
ASR で DR を構成する際には、この Key Vault に格納されたディスク暗号化キーを、ターゲットリージョン側の Key Vault にコピーする必要があります。ここが ADE＋ASR 構成の最大のポイントです。
ASR は ADE キーをどう扱うか
レプリケーション有効化時の流れ
ADE 有効化済み VM で ASR レプリケーションを有効化すると、ASR は次のような流れで暗号化キーを扱います。
| タイミング | ASR の主な処理 | 暗号化キー／Key Vault まわり |
|---|---|---|
| 1. 保護対象 VM の選択 | Recovery Services コンテナーから「レプリケーションの有効化」を開始 | ソース VM が ADE で暗号化されているかどうかを検出 |
| 2. レプリケーション設定の構成 | ソース／ターゲットのリージョン、サブスクリプション、リソースグループ、VNet 等を指定 | 「暗号化の設定」で ディスク暗号化 Key Vault／KEK Key Vault をターゲット側に指定 |
| 3. 初回レプリケーション設定反映 | レプリケーションポリシー、キャッシュストレージ、ターゲット VM 情報等を構成 | 必要に応じて ターゲットリージョンに新規 Key Vault を自動作成（名前に asr サフィックス） し、ソース Key Vault からキーをコピー |
| 4. 初期レプリケーション中 | ディスクデータをターゲットリージョンに複製 | 暗号化キー自体はすでにターゲット Key Vault に存在。ディスクデータは暗号化状態のまま転送される |
| 5. フェールオーバー／テストフェールオーバー | ターゲットリージョンに新しい VM を作成し起動 | ターゲット VM はターゲット Key Vault のキー／シークレットを参照して起動する |
ポイントは、ASR は「Key Vault 間のキーコピー」と「VM から Key Vault への参照設定」を自動でやってくれるという点です。ただし、それが成立するのはユーザーに必要な権限が付与されている場合のみです。
Key Vault に必要な権限（RBAC／アクセスポリシー）
暗号化された VM のレプリケーションを有効化するために、ユーザーには少なくとも以下の Key Vault 権限が必要です。
- キー権限（Keys）
- List
- Get
- Create
- シークレット権限（Secrets）
- Get
- List
- Set
- キー暗号化キーを利用している場合
- Cryptographic operations: Encrypt / Decrypt
これらは従来の Key Vault アクセスポリシーでも、Azure RBAC ベースでも付与できます。実務的には、次のような分担が現実的です。
- セキュリティ管理者：
- Key Vault に対する「Key Vault Administrator」や「Key Vault Crypto Officer」などのロールを保持
- ASR／バックアップ用の Managed Identity や DR 管理者に対し、必要最低限の権限のみ付与
- 必要に応じて Copy-Keys.ps1 を使い、本人権限でキーをコピー
- DR 管理者（Site Recovery Contributor など）：
- Recovery Services コンテナーで ASR の有効化／監視／フェールオーバーを実行
- Key Vault 側では List/Get 程度に権限を絞る、または完全に委譲しない
ASR は Recovery Services コンテナーに紐づいた Managed Identity を利用して、ストレージアカウントや Key Vault にアクセスする構成もサポートしています。この場合も、Key Vault 側では Managed Identity に対して上記のような権限を付与する必要があります。
同一テナント内でのクロスサブスクリプション レプリケーション
本題の「別サブスクリプションへのレプリケーション」について整理します。
- ASR のウィザードでは、ソース側のサブスクリプションを、「Recovery Services コンテナーと同じ Entra テナント内の任意のサブスクリプション」から選択できます。
- 同様に ターゲットサブスクリプションも選択可能で、既定値はソースと同じサブスクリプションですが、別サブスクリプションを選ぶことでクロスサブスクリプション DR を構成できます。
- ターゲットサブスクリプションを変更すると、ターゲットリソースグループや VNet、Key Vault などのターゲット設定も自動でそのサブスクリプションに切り替えられます。
サポートされる・されないパターンの整理
| 構成パターン | 可否 | ポイント |
|---|---|---|
| 同一サブスクリプション内、別リージョンへの DR | サポート | もっともシンプルな構成。PoC や小規模構成で採用されがち。 |
| 異なるサブスクリプション（同一テナント）の別リージョンへの DR | サポート | 「本番サブスクリプション」と「DR 専用サブスクリプション」を分離する代表的な構成。 |
| 異なるテナントをまたぐ DR | 非サポート | ASR の設計上、テナントをまたぐ構成は不可。クロステナント DR が必要なら別方式を検討。 |
| Azure Policy で自動的に ASR を有効化しつつ、別サブスクリプションへ DR | 非サポート | Azure Policy による ASR 自動有効化シナリオでは Cross-subscription がサポートされていない。 |
サブスクリプション分割設計の例
実務でよくあるのは、次のような構成です。
| パターン | 構成イメージ | メリット | デメリット／注意点 |
|---|---|---|---|
| パターン A：同一サブスクリプション DR | Prod-RG（東日本）→ DR-RG（西日本） | 権限・課金がシンプル。PoC や小規模向け。 | DR によるコストが本番と混在し、部門別課金がしづらい。 |
| パターン B：Prod サブスクリプション → DR サブスクリプション | Prod-Sub（東日本）→ DR-Sub（西日本） | DR コストを別サブスクリプションで管理でき、権限分離もしやすい。 | 権限設計がやや複雑。Key Vault／ネットワーク等の構成を DR 側で再現する工数が発生。 |
| パターン C：部門別サブスクリプション → 共通 DR サブスクリプション | Dept-A-Sub / Dept-B-Sub → Shared-DR-Sub | 複数部門の DR を 1 つの DR サブスクリプションに集約。DR 運用チームを共通化しやすい。 | Shared-DR-Sub のスケーラビリティ・サブスクリプション制限（保護ディスク数上限など）に注意。 |
実装ステップ詳細：ADE 暗号化 VM を ASR で保護する
ここからは、実際に ADE 暗号化 Windows VM を ASR で保護し、同一テナント内の別サブスクリプションへレプリケーションする際の流れを、少し踏み込んで整理します。
ステップ 1：事前チェック（VM／ディスク／Key Vault）
まずはソース環境の棚卸しと要件チェックです。
| 確認項目 | チェック内容 | 補足 |
|---|---|---|
| OS 種別 | 対象 VM が Windows かどうかを確認 | 本記事の前提は Windows VM。Linux の場合は ADE 1.1 のみサポートなど条件が異なる。 |
| ADE バージョン | ADE 0.1（Entra 必須）か 1.1（Entra 不要）かを確認 | 1.1 の場合、マネージドディスク必須。0.1 から 1.1 に切り替える場合は後述の手順に注意。 |
| ディスク種別 | すべてのディスクがマネージドディスクかどうか | ADE 1.1 はマネージドディスクのみサポート。 |
| Key Vault の配置 | 暗号化キーを格納している Key Vault のリージョン／サブスクリプション | 通常は VM と同じリージョン・サブスクリプションだが、例外構成がないか確認。 |
| ASR 対象リージョン | ターゲットリージョン（例：東日本 → 西日本） | ペアリージョンを選ぶのが一般的。DR 戦略・規制要件に応じて設計。 |
| ターゲットサブスクリプション | 同一テナント配下で、ターゲットとして利用するサブスクリプションを決定 | 権限モデル（誰がどこまで操作できるか）も合わせて設計する。 |
ステップ 2：Recovery Services コンテナー（Vault）の準備
次に ASR の中核となる Recovery Services コンテナーを準備します。
- DR をまとめて管理したいサブスクリプションに、Recovery Services コンテナーを作成
- たとえば「Shared-DR-Sub」の「rg-dr-vault-eastasia」など、専用 RG に集約
- コンテナーのリージョンは、基本的に ターゲットリージョンと同じにするのが推奨
- ソース東日本 → ターゲット西日本の場合、Vault は西日本
- 必要に応じて、Vault の Managed Identity を有効化し、Key Vault やストレージアカウントへのアクセスを MI 経由で行う設計も可能
ステップ 3：ターゲット Key Vault 設計とキーコピー
ASR では、暗号化キーをターゲットリージョン／サブスクリプションの Key Vault にコピーする必要があります。公式ドキュメントでは、次のような運用パターンが想定されています。
- ポータルからの自動コピー：
- レプリケーション有効化時に、ターゲット側に「<元 Vault 名>-asr」のような Key Vault を自動作成し、そこにキー／シークレットをコピー
- PowerShell スクリプト（Copy-Keys.ps1）によるコピー：
- セキュリティ管理者が自身の権限でキーをコピーし、その後 ASR から既存のターゲット Key Vault を選択
- Azure が提供している Copy-Keys スクリプト を利用すると、対象 VM ／ソース Key Vault ／ターゲットリージョンを選ぶだけで必要な鍵をコピー可能
セキュリティ分掌の観点からは、「DR 管理者は Key Vault の権限をほとんど持たず、セキュリティ管理者が Copy-Keys.ps1 でキーを複製する」パターンがよく採用されます。
ステップ 4：レプリケーションの有効化（クロスサブスクリプション指定）
ポータルから ADE 暗号化 VM を選び、レプリケーションを有効化します。流れは概ね次の通りです。
- Recovery Services コンテナーを開き、「Site Recovery > Azure 仮想マシン > レプリケーションの有効化」をクリック
- ソース欄で次を指定
- リージョン：ソース VM のリージョン
- サブスクリプション：ソース VM が属するサブスクリプション（同一テナント内なら複数選択可）
- リソースグループ：対象 VM の RG
- レプリケーション対象 VM を選択
- レプリケーション設定で、ターゲット側を構成
- ターゲットリージョン：DR 用リージョン（例：西日本）
- ターゲットサブスクリプション：DR 用サブスクリプションに変更
- ターゲットリソースグループ：DR 用 RG（新規作成または既存）
- VNet／サブネット：DR 用ネットワーク（事前に設計／作成）
- 暗号化の設定を開き、ターゲット Key Vault を指定
- 自動作成された <Vault 名>-asr をそのまま使うか、事前にセキュリティ管理者が準備した Key Vault を選択
- Disk Encryption Key Vault と Key Encryption Key Vault をそれぞれ指定
- レプリケーションポリシー（保持期間・アプリ整合性スナップショット頻度など）を選択し、レプリケーションを有効化
このとき、Key Vault に必要な権限が不足していると、レプリケーション有効化処理は Key Vault 関連のエラーコードで失敗します。貴重な時間を失わないためにも、事前の権限チェックは必ず行いましょう。
ステップ 5：テストフェールオーバーでの検証
本番運用に入る前に、必ず テストフェールオーバーを実施しておきます。
- Recovery Services コンテナーから対象 VM を選択し、「テスト フェールオーバー」を実行
- テスト用 VNet（分離されたサブネット）にフェールオーバー VM を起動
- 次の観点を確認
- VM が正常に起動するか（BitLocker のロックなどで止まらないか）
- ドメイン参加／アプリケーションが正常に動作するか
- ネットワーク的に他システムと疎通できるか（特に Private DNS／NSG／Firewall）
テストフェールオーバーの検証結果は台帳化しておき、障害発生時に「どこまで保証できる構成なのか」を関係者が即座に把握できるようにしておくのがおすすめです。
ステップ 6：運用開始とヘルス監視
運用開始後は、次のような観点で継続的に監視・メンテナンスを行います。
- ASR ジョブ／レプリケーションヘルス
- レプリケーション遅延、失敗ジョブの有無
- 高いデータ変更率（High Churn）が発生していないか
- Recovery Services コンテナー・Key Vault 側の変更
- Managed Identity や Key Vault 権限の変更が、DR に影響を与えていないか
- Key Vault のキー有効期限が近づいていないか
- コスト監視
- 保護ディスク数／保持期間／ネットワークトラフィック量に応じて Site Recovery のコストが増減するため、タグやコストアラートを活用
運用と変更管理のベスト プラクティス
DR が一度構成できても、その後の変更や運用の中で破綻するケースは珍しくありません。代表的な変更イベントと、それに対して ASR 側で必要となる作業を整理します。
| 変更イベント | ASR 側で必要な対応 | 補足 |
|---|---|---|
| VM にデータディスクを追加 | レプリケーション対象ディスクの再評価（通常は自動検出） | ディスク追加後のテストフェールオーバーでアプリ整合性を再確認。 |
| ASR 有効化後に ADE を有効化 | ターゲット側 Key Vault へのキーコピーと、ASR メタデータの「暗号化設定」の更新 | ドキュメントにある「ターゲット VM の暗号化設定更新」手順を実施する。 |
| ディスク暗号化キー／KEK の回転（ローテーション） | 基本的には レプリケーションを一度無効化し、再度有効化 する必要あり | ASR は保護中の暗号化 VM のキー回転をサポートしておらず、回転後は再構成が必要。 |
| ADE 0.1 → ADE 1.1 への移行 | 移行前にレプリケーションを無効化し、移行後に再度 ASR を構成 | 0.1 ベースで保護している状態から 1.1 に切り替える場合の必須ステップ。 |
| VM サイズ変更や可用性ゾーン設定変更 | 場合によってはレプリケーション無効化・再有効化 | 可用性セット／ゾーンはレプリケーション有効化後に変更できないため、事前設計が重要。 |
よくあるトラブルと対処アイデア
ADE 暗号化 VM の ASR 構成で実際によく発生するトラブルを、症状ベースで整理しておきます。
| 症状 | 典型的な原因 | 対処例 |
|---|---|---|
| レプリケーション有効化時に「Key Vault permission error」で失敗 | ソース Key Vault の GET 権限／ターゲット Key Vault の Set 権限不足 | Key Vault のアクセス制御で、対象ユーザー（または Managed Identity）に Keys/Secrets に対する List/Get/Create/Set を付与。 |
| テストフェールオーバー VM が BitLocker 復旧画面で停止 | ターゲット VM が参照している Key Vault／キーが誤っている、またはアクセス不可 | ターゲット側の「暗号化設定」で Key Vault／キーを再指定し、必要なら Copy-Keys.ps1 でキーを再コピー。 |
| Key Vault のキーを回転したらレプリケーションが失敗し始めた | ASR メタデータが古いキー情報を保持したまま | レプリケーションを一度停止し、新しいキーを利用する構成で再度 ASR を有効化。必要に応じて Copy-Keys.ps1 で新しいキーを DR 側へコピー。 |
| Azure Policy で ASR を自動有効化したが、一部 VM だけ保護されない | Policy ベースの ASR 有効化がクロスサブスクリプション未対応／VM 構成がサポート外 | 該当 VM はポータルやスクリプトから個別に ASR を有効化するか、同一サブスクリプション内での DR に切り替える。 |
| DR 用サブスクリプションだけで保護ディスク数上限に近づいている | 複数部門の DR を 1 サブスクリプションに集約している | サブスクリプションごとの「保護ディスク数上限（3,000 台）」に注意し、必要に応じて DR サブスクリプションを分割する。 |
将来を見据えた検討：ADE から Encryption at host へ
現在の公式アナウンスでは、Azure Disk Encryption は 2028 年 9 月 15 日にリタイア予定であり、新規ワークロードには Encryption at host の利用が推奨されています。
- これから新しく DR 構成を組む場合：
- 可能であれば ADE ではなく、サーバーサイド暗号化（SSE）＋ Encryption at host を前提に DR を設計
- ASR 側では「CMK 付きディスク」のサポートも整備されているため、Key Vault 利用という意味では大きく変わらない。
- すでに ADE 暗号化済みの VM を多数抱えている場合：
- 短期的には本記事のように ADE＋ASR の DR を安定稼働させる
- 中長期的には、ADE から Encryption at host への移行計画（メンテナンスウィンドウ／再起動／テストフェールオーバーなどを含む）を立てる
DR 設計の観点では、「暗号化方式（ADE or Encryption at host）」よりも、「キー管理の責任分界（誰が Key Vault を管理し、DR 時にキーをどこまで自動的に利用できるか）」の設計の方が重要です。その意味でも、ASR と Key Vault の連携部分をしっかり作り込んでおくと、将来の暗号化方式変更にも耐えられる構成になります。
まとめ：ADE 有効化 Windows VM の ASR／クロスサブ DR を成功させるポイント
- ADE 有効化 Windows VM は ASR でレプリケーション可能であり、同一 Microsoft Entra テナント内であれば 別サブスクリプションへのレプリケーションもサポートされています。
- 成功のカギは Key Vault／権限設計にあります。ソース／ターゲット双方の Key Vault に対して、ユーザーまたは Managed Identity に適切な権限（List/Get/Create/Set など）を付与することが必須です。
- ADE のバージョン（0.1 / 1.1）やディスク種別（マネージド／アンマネージド）は ASR のサポート可否に直結します。特に ADE 1.1 では マネージドディスク必須である点を忘れないようにしましょう。
- キー回転や ADE バージョン変更といった構成変更では、レプリケーションの再構成が必要になるケースがあります。運用設計の段階で、どの変更時に何をするかを決めておくと安心です。
- ADE 自体は将来的に Encryption at host へ移行していく方向性が示されていますが、当面は既存環境のために ADE＋ASR＋クロスサブ DR をしっかり安定稼働させることが重要です。
以上のポイントを押さえておけば、ADE 有効化 Windows VM の ASR レプリケーションおよび 同一テナント内の別サブスクリプションへのディザスターリカバリーを、安全かつ実運用に耐えるレベルで構築・運用できるはずです。
コメント