Azure VMをRubrik Security Cloud（以下、RSC）で保護する場合、DiskやAvailability Zoneだけでなく、もう一つ大きな設計ポイントがあります。
それがセキュリティ設定です。
Azure VMでは、
- Server-Side Encryption（SSE）
- Platform-Managed Key（PMK）
- Customer-Managed Key（CMK）
- Disk Encryption Set（DES）
- Azure Disk Encryption（ADE）
- Encryption at Host
- Azure Key Vault
- Azure RBAC
- Azure Policy
- Resource Lock
- Managed Disk / SnapshotのNetwork Access Policy
など、複数のセキュリティ機能を組み合わせられます。
しかし、
Azureで安全性を高めるための設定が、RubrikのBackup / Recoveryに影響する場合があります。
例えば、
Azure Policy
↓
Managed DiskのPublic Accessを禁止
↓
RubrikがSnapshotを処理するときの
アクセス方式に影響
というケースです。
また、
CMKで暗号化したから安全
だけで終わりではありません。
Recovery時には、
Key Vaultは存在する？
Keyは有効？
Disk Encryption Setは利用できる？
Target Subscriptionで権限はある？
Rubrikがその暗号化方式をサポートしている？
まで考える必要があります。
今回はRubrik × Azure VMシリーズのセキュリティ編として、
「Azure VMを安全にした結果、バックアップや復旧を難しくしていないか？」
という視点から整理します。
※本記事は2026年9月時点のMicrosoftおよびRubrik公開情報をもとに整理しています。特に暗号化機能は変更が多いため、実環境では最新のRubrik Compatibility Matrixも確認してください。
1. まずAzure VMの暗号化方式を整理する
Azure Managed Diskには複数の暗号化方式があります。
大きく分けると次のようになります。
| 暗号化方式 | 概要 |
|---|---|
| SSE + PMK | Microsoft管理Keyによる保存時暗号化 |
| SSE + CMK | ユーザー管理Keyによる保存時暗号化 |
| Encryption at Host | VM HostからStorageまで暗号化 |
| Azure Disk Encryption | Guest OS側のBitLocker / dm-crypt |
| Confidential Disk Encryption | Confidential VM向け |
Azure Managed DiskではServer-Side Encryptionが標準で有効で、通常はPlatform-Managed Keyで暗号化されています。CMKを使用する場合はDisk Encryption Setを経由してAzure Key VaultなどのKeyを利用します。
2. SSE + PMKはAzure Managed Diskの標準
Azure Managed Diskはデフォルトで暗号化されています。
Application
↓
Azure VM
↓
Managed Disk
↓
Server-Side Encryption
↓
Platform-Managed Key
このKeyをMicrosoftが管理する方式が、
Platform-Managed Key（PMK）
です。
通常のAzure VMを特別な暗号化設定なしで作成した場合も、Managed Disk内のデータは保存時に暗号化されています。
Rubrik視点では、これは一般的なManaged Disk保護として考えられます。
3. CMKとは
企業によっては、
「暗号化KeyまでMicrosoftに任せず、自社で管理したい」
という要件があります。
その場合に利用されるのが、
Customer-Managed Key（CMK）
です。
構成は概ね次のようになります。
Azure VM
│
Managed Disk
│
Disk Encryption Set
│
▼
Azure Key Vault
│
└── Customer Managed Key
AzureではCMKをAzure Key VaultまたはManaged HSMに保存し、Disk Encryption Setから参照します。
4. PMKとCMKの違い
簡単に整理すると、
| 項目 | PMK | CMK |
|---|---|---|
| Key管理 | Microsoft | ユーザー |
| Key Vault | 不要 | 必要 |
| DES | 不要 | 必要 |
| Key Rotation | Microsoft管理 | ユーザー管理可能 |
| 管理負荷 | 小 | 大 |
| Recovery設計 | 比較的シンプル | Key / DESも考慮 |
CMKはSecurityやCompliance上有効ですが、
バックアップ・DR設計では依存コンポーネントが増える
ことになります。
5. Rubrikで最も注意したい「SSE + CMK」
ここは今回の記事で非常に重要です。
Rubrikの公開Compatibility Matrixでは現在、
Storage Service EncryptionをCMKで暗号化したAzure VMおよびManaged DiskをRSCで保護できない
と記載されています。
つまり公開Matrix上は、
SSE + PMK
↓
通常のManaged Disk保護
SSE + CMK
↓
Rubrik Compatibility要注意
という大きな違いがあります。
これはAzure設計者にとってかなり重要なポイントです。
6. Azure PolicyでCMKを強制している場合は特に注意
Azureには次のようなBuilt-in Policyがあります。
OS Disk / Data DiskをCustomer-Managed Keyで暗号化する
あるいは、
指定したDisk Encryption Setだけを利用する
というPolicyです。
例えば、
Management Group
│
Azure Policy
│
└── CMK必須
↓
全Managed Disk
SSE + CMK
という企業環境の場合、
セキュリティ標準として正しい構成でも、Rubrik Cloud Native ProtectionとのCompatibilityに影響する
可能性があります。
これはRubrik導入前に必ず確認したい項目です。
7. 「RubrikもCMKを使える」という話と混同しない
少しややこしい点があります。
RSC自身が作成するAzure Archive Storageなどについては、
Azure Storage Account
↓
CMK
↓
Azure Key Vault
で暗号化する機能があります。
RubrikはArchive用Storage AccountでCMKを使用するためのKey Vault / Key権限も公開しています。
しかしこれは、
Rubrikのバックアップデータ保存先をCMKで暗号化する話
です。
一方、
保護対象VMのManaged DiskがSSE + CMKで暗号化されている
という話は別です。
Source Azure VM DiskのCMK
≠
Rubrik ArchiveデータのCMK
と分けて理解する必要があります。
8. Azure Disk Encryption（ADE）とは
次にAzure Disk Encryptionです。
ADEはAzure Storage側ではなく、Guest OS側でDiskを暗号化する方式です。
Windowsでは、
BitLocker
Linuxでは、
dm-crypt
を利用します。
イメージすると、
Windows VM
│
BitLocker
│
Encrypted Volume
│
Managed Disk
です。
CMKを利用するSSEとは暗号化レイヤーが異なります。
9. RubrikはADE VMをバックアップできる
Rubrik Compatibility Matrixでは、
ADEが有効なAzure VMについて、
- Primary Backup
- Archive
- Replication
をサポートしています。
ただし、バージョン条件があります。
| OS | Rubrik Backup条件 |
|---|---|
| Windows | ADE 2.2以降 |
| Linux | ADE 1.1以降 |
それ以前のADE Versionではバックアップ非対応です。
10. ADEではRecovery制限がある
ADE VMはBackup可能だからといって、Recoveryが完全に自由なわけではありません。
Rubrikの現行公開Compatibility Matrixでは、ADE + PMK / CMKについて、
Same Region + Same Subscription
のRecoveryが明示的にサポートされています。
一方、
Different SubscriptionへのRecoveryは非対応
です。
概念的には、
Source
Subscription-A
Japan East
ADE VM
│
▼
Rubrik Snapshot
│
▼
Subscription-A
Japan East
○
一方、
Subscription-A
↓
Subscription-B
Cross Subscription
×
です。
11. ADEではIndexingも利用できない
ADE VMではさらに、
- File Indexing
- Virtual Disk Mount
がサポートされません。
つまり、
ADE VM
Backup
○
Archive
○
Replication
○
VM Recovery
○（条件あり）
Indexing
×
Virtual Disk Mount
×
という構成です。
ここでも、
Backup ○ ＝ 全Recovery機能 ○
ではありません。
12. さらに重要：ADEは2028年に廃止予定
2026年時点では、ADEについてもう一つ大きな注意があります。
Microsoftは、
Azure Disk Encryptionを2028年9月15日に廃止予定
と発表しています。
Microsoftは新規VMについて、
- Encryption at Host
- Confidential VM
などへの移行を案内しています。
したがって今から新規Azure VMを設計する場合、
「RubrikがADEをサポートしているからADEで設計する」
という判断だけでは不十分です。
13. BackupにもADE廃止対応が必要
Microsoftの案内では、
ADE対応VMだけでなく、バックアップも含めて廃止前にEncryption at Hostへ移行する必要がある
とされています。
つまりRubrikユーザーも、
現在
ADE VM
↓
Rubrik Backup
2028年まで
↓
Encryption at Hostへ移行
というLifecycleを考える必要があります。
これは今後かなり重要になるポイントです。
14. Encryption at Hostとは
Encryption at Hostは、ADEとは異なり、Azure VM Host側で暗号化します。
通常のSSEでは、
VM Host
↓
Storage
↓
Encryption
ですが、
Encryption at Hostでは、
VM Host
↓
Encryption
↓
Encrypted Traffic
↓
Azure Storage
となります。
さらに、
- Temporary Disk
- OS / Data Disk Cache
なども暗号化できます。
またGuest OSのCPUを暗号化処理に使用しません。
15. RubrikのEncryption at Host対応
Rubrik Compatibility MatrixではEncryption at Host VMについて、
- Source SnapshotからExport
- Archived SnapshotからExport
- Replicated SnapshotからExport
- Cross-Region Export
- Cross-Subscription Export
をサポートしています。
ただし重要な条件があります。
Encryption at Host VMのBackupを有効化するにはRubrik Supportへの問い合わせが必要
とされています。
つまり、
Encryption at Host VM
│
├─ Recovery / Export
│ ○
│
└─ Backup Enablement
↓
Rubrik Support確認
です。
16. Cross-Subscriptionでも追加条件
Encryption at Host VMを別SubscriptionへExportする場合、
Target側を含む関連SubscriptionでEncryption at Hostを有効にする必要があります。
Rubrik Compatibility Matrixでは、この有効化についてもRubrik Supportへ問い合わせるよう案内されています。
したがって、
Subscription-A
Encryption at Host
│
▼
Rubrik
│
▼
Subscription-B
Encryption at Host
まで揃えておく必要があります。
17. 2026年以降の設計ではEncryption at Hostが重要
MicrosoftがADEの廃止予定を発表しているため、今後は、
Legacy
ADE
↓ Migration
Modern
Encryption at Host
という流れが強くなります。
しかしRubrikでは現状、
Encryption at HostのBackup利用についてSupportへの確認が必要
という条件があります。
したがって、新規設計では、
Microsoftの推奨方式とRubrik Compatibilityの両方を確認する
ことが重要です。
18. Key VaultもRecoveryコンポーネントの一部
暗号化をCMKやADEで行う場合、Key Vaultが重要になります。
Recovery対象が正常でも、
Snapshot
○
Disk
○
VM
○
Key
×
なら復旧できない可能性があります。
例えば、
- Key Vault削除
- Key削除
- Key無効化
- Key期限切れ
- Permission不足
- Subscription間移行
- Tenant変更
などです。
CMKはセキュリティを高めますが、
Key ManagementそのものがDR設計に入る
ということです。
19. CMKではKey Rotationにも注意
Azure Managed DiskのCMKではAutomatic Key Rotationを利用できます。
Disk Encryption Setで自動Rotationを有効にすると、Managed Disk、Snapshot、Imageが新しいKey Versionへ更新されます。
そのため、
Backup Recovery Test
だけでなく、
Key Rotation
↓
Recovery Test
も定期的に行う方が安全です。
20. Azure RBACもRubrik Backupの一部
RSCはAzureへアクセスするためにMicrosoft Entra IDのService Principalを利用します。
そして、
- Disk Read
- Disk Write
- Snapshot Read
- VM Size Read
- Resource Group Write
- Key Vault Deploy
- VM Extension Write
- NSG Write
- Storage Account Write
など、さまざまなPermissionを利用します。
つまり、
Azure RBACを必要以上に厳しく変更するとRubrik処理が失敗する
可能性があります。
21. Least PrivilegeとRubrik権限のバランス
セキュリティ設計では、
Ownerを付ければ簡単
という考え方は避けたいところです。
一方で、
最小権限にしすぎる
↓
Rubrik Recoveryに必要なActionがない
という問題もあります。
特に確認したいのは、
Microsoft.Compute/disks/*
Microsoft.Compute/snapshots/*
Microsoft.Compute/virtualMachines/*
Microsoft.Network/*
Microsoft.KeyVault/*
Microsoft.Storage/*
Microsoft.Authorization/locks/*
などです。
Rubrikが公開しているPermission Categoryに従って設計するのが基本です。
22. Azure Policyもバックアップへ影響する
企業Azure環境では、
Management Group
↓
Azure Policy
↓
Subscription
↓
Resource Group
という形でPolicyを強制していることがあります。
例えば、
- CMK必須
- Public Network Access禁止
- 指定Regionのみ
- 指定VM SKUのみ
- Private Endpoint必須
- 特定DES必須
などです。
AzureにはManaged DiskのPublic Network Accessを禁止したり、CMKを必須化したりするBuilt-in Policyがあります。
23. Azure PolicyによってRubrik Exportが止まる例
例えば企業Policyとして、
Allowed Locations
=
Japan East only
を設定していたとします。
Rubrikから、
Japan East
↓
Japan WestへExport
しようとしても、
Azure PolicyがDenyすればVM作成できません。
つまり、
Rubrik
Recovery Supported
○
Azure Policy
×
Result
Recovery Failed
です。
配置編でも触れた、
Rubrik対応 ○ ＝ Azure環境で必ず実行可能
ではないという話が、セキュリティでも当てはまります。
24. Snapshot Network Access Policy
ここも非常に重要です。
Azure Managed DiskとSnapshotには、
NetworkAccessPolicy
があります。
これによって、
- Public Access
- Private Access
- Deny All
などを制御できます。
AzureではPolicyを利用してManaged DiskのPublic Network Accessを禁止できます。
25. RubrikはSnapshotへどうアクセスするのか
RSCはAzure Disk / Snapshotのデータを読み取る際にSAS URIを利用します。
Rubrikのドキュメントでは、通常はSnapshotのNetwork Access PolicyがPublicである必要がある一方、追加権限とExocomputeを構成することでPrivate Accessを利用できます。
ここは企業環境ではかなり重要です。
26. Private Accessを使う場合
RSCがPrivate AccessでSnapshotへアクセスする場合、
Rubrikでは少なくとも、
- Private access to snapshots Permission Category
- Private endpoints Permission Category
が必要です。
またExocompute側のPrivate Endpoint構成も関係します。
つまり、
Private Access
↓
Security向上
しかし
Network
Permission
Exocompute
Private Endpoint
と設計要素が増えます。
27. Replicationではさらに注意
RubrikのSnapshot Replicationでは、ネットワークアクセスについて重要な制限があります。
Rubrikドキュメントでは、
Replication Job実行中はPrivate Accessを維持することをサポートしておらず、必要に応じてPublic Accessへ切り替える
とされています。
一方、Archivingなど他の処理ではPrivate Accessを維持できます。
これは、
Public Network Accessを
絶対禁止
という企業Policyと衝突する可能性があります。
28. Azure PolicyでPublic Access変更を禁止すると？
Rubrikは、Public Accessへ切り替えさせたくない場合、
Azure Policyで変更を防止できる
と説明しています。
ただしその場合、
Rubrikが必要な処理をPrivate Accessで完結できるようにPermission / Exocomputeを設計する
必要があります。
つまり、
Security Policy
+
Rubrik Permission
+
Network Design
をセットで考えます。
29. NetworkAccessPolicy = DenyAllにも注意
AzureではManaged Disk / SnapshotのNetworkAccessPolicyを、
DenyAll
に設定できます。
この場合、そのリソースのExportを防止できます。
これはData Exfiltration対策として有効です。
しかし、
Disk Export
Snapshot Export
Rubrik Recovery処理
との関係を必ず確認する必要があります。
30. Resource Lockも意外な落とし穴
Azure Resource Lockには、
- CanNotDelete
- ReadOnly
があります。
CanNotDeleteでは変更可能ですが削除不可。
ReadOnlyでは更新も削除もできません。
また上位Scopeに設定したLockは子Resourceへ継承されます。
例えば、
Subscription
↓
Resource Group
↓
ReadOnly Lock
↓
VM / Disk / Network
となる可能性があります。
31. ReadOnly LockはVM操作そのものを止めることがある
Microsoftのドキュメントでは、VMを含むResource GroupへReadOnly Lockを設定すると、
VMのStart / Restartもできなくなる
例が説明されています。
つまりRecovery時に、
Rubrik Export
↓
Resource作成・変更
が必要なのに、
ReadOnly Lock
が存在すれば、Azure側で拒否される可能性があります。
32. RSC自身もLock Permissionを利用する
RubrikがAzure Native Protectionで要求するPermissionには、
Microsoft.Authorization/locks/*
も含まれています。
用途は、
ResourceをLockするため
です。
そのため、
「Azure Resource Lockがある／ない」
だけでなく、
誰がLockを作成・解除・管理するのか
も運用設計に含める必要があります。
33. Securityを強くするとRecovery Pathが細くなる
ここまでを見ると、セキュリティを強くすること自体が悪いわけではありません。
むしろ、
CMK
Private Endpoint
Azure Policy
Resource Lock
RBAC
は重要なSecurity Controlです。
ただし、
Control 1
+
Control 2
+
Control 3
+
Control 4
と制約を追加するほど、
Recovery時に必要な操作が通るかどうか
を検証する必要があります。
34. Backup Securityは「データ」だけではない
セキュリティ設計では、少なくとも4レイヤーを確認します。
1. Data
Encryption
2. Identity
RBAC / Service Principal
3. Network
Public / Private Access
4. Governance
Azure Policy / Lock
どれか一つだけを見るのではなく、
4つすべてを通過して初めてRecoveryできる
と考えると分かりやすくなります。
35. セキュリティ編の重要対応表
今回の内容を簡単にまとめます。
| Azure Security機能 | Rubrik観点 | 注意点 |
|---|---|---|
| SSE + PMK | ○ | 一般的なManaged Disk |
| SSE + CMK | 要注意 / 公開Matrix上非対応 | 最新Matrix確認必須 |
| ADE | ○ | Version・Recovery制限 |
| ADE Cross Subscription | × | 非対応 |
| ADE Indexing | × | 非対応 |
| Encryption at Host | △ | BackupはSupport確認必要 |
| Encryption at Host Export | ○ | Cross Region / Subscription対応 |
| Key Vault | △ | Key LifecycleとPermission重要 |
| Private Snapshot Access | ○ | Permission + Exocompute必要 |
| Public Access禁止Policy | △ | Rubrik処理との整合確認 |
| NetworkAccessPolicy DenyAll | △ | Export等への影響 |
| Azure Policy | △ | Recovery Resource作成をDenyする可能性 |
| Resource Lock | △ | Update / Delete等を阻害 |
| Azure RBAC | 必須 | RSC Permission Category確認 |
36. 2026年時点で特に重要な3項目
今回、特に押さえておきたいのは次の3つです。
① ADEは2028年に廃止予定
ADE
↓
2028/09/15 Retirement
↓
Encryption at Hostへ
今からADE前提の新規設計を行う場合は、Migrationまで考える必要があります。
② SSE + CMKはRubrik Compatibilityを必ず確認
AzureではCMK利用が一般的なSecurity Requirementになりつつあります。
しかしRubrik公開MatrixではSSE + CMKのSource VM / Managed Disk保護に制限が記載されています。
③ Public Access禁止とRubrik Snapshot Accessの整合
企業PolicyでManaged Disk / SnapshotのPublic Accessを禁止している場合、
Private Access + Exocompute + Permission Categoryまで含めて設計する必要があります。
37. セキュリティ設計チェックリスト
| # | 確認項目 | Check |
|---|---|---|
| 1 | Managed Diskの暗号化方式を確認したか | ☐ |
| 2 | SSE + PMKか | ☐ |
| 3 | SSE + CMKを利用していないか | ☐ |
| 4 | Disk Encryption Setを確認したか | ☐ |
| 5 | Azure Key Vaultを確認したか | ☐ |
| 6 | Keyが有効か | ☐ |
| 7 | Key Expirationを確認したか | ☐ |
| 8 | Key Rotation方式を確認したか | ☐ |
| 9 | ADEを利用していないか | ☐ |
| 10 | Windows ADE 2.2以降か | ☐ |
| 11 | Linux ADE 1.1以降か | ☐ |
| 12 | ADE廃止予定を考慮したか | ☐ |
| 13 | ADEからEncryption at Hostへの移行計画があるか | ☐ |
| 14 | ADE Cross-Subscription Recoveryが不要か | ☐ |
| 15 | ADE VMでIndexingが不要か | ☐ |
| 16 | Encryption at Hostを利用しているか | ☐ |
| 17 | Rubrik Supportへ確認したか | ☐ |
| 18 | Target SubscriptionでもEncryption at Hostを利用できるか | ☐ |
| 19 | RSC Service Principalの権限を確認したか | ☐ |
| 20 | Key Vault権限を確認したか | ☐ |
| 21 | Azure Policyを確認したか | ☐ |
| 22 | CMK強制Policyがないか | ☐ |
| 23 | Allowed Locations Policyを確認したか | ☐ |
| 24 | Public Network Access禁止Policyがないか | ☐ |
| 25 | Managed Disk NetworkAccessPolicyを確認したか | ☐ |
| 26 | Snapshot NetworkAccessPolicyを確認したか | ☐ |
| 27 | Private Snapshot Accessを使うか | ☐ |
| 28 | Exocomputeを準備したか | ☐ |
| 29 | Private Endpointを準備したか | ☐ |
| 30 | Replication時のNetwork制約を確認したか | ☐ |
| 31 | Resource Lockがないか | ☐ |
| 32 | ReadOnly Lockを確認したか | ☐ |
| 33 | CanNotDelete Lockを確認したか | ☐ |
| 34 | Cross-Region Recoveryを試験したか | ☐ |
| 35 | Cross-Subscription Recoveryを試験したか | ☐ |
| 36 | Key Rotation後にRecovery Testを実施したか | ☐ |
| 37 | 最新Rubrik Compatibility Matrixを確認したか | ☐ |
38. まとめ
今回最も重要なのは、
セキュリティを強化するほど、Recovery設計もセットで強化する必要がある
ということです。
例えば、
CMK
Azure Policy
Private Endpoint
Resource Lock
Least Privilege RBAC
はどれもSecurity上は有効です。
しかし、
Backup
↓
Snapshot
↓
Key Access
↓
Disk Export
↓
Network Access
↓
VM Creation
のどこか一つでもSecurity Controlによって拒否されればRecoveryは成立しません。
つまり、
Security
+
Backup
+
Recovery
を一つの設計として考える必要があります。
そして2026年時点では、
ADE
↓
2028年廃止予定
↓
Encryption at Host
というMicrosoft側の大きな変化もあります。
Rubrikを利用する場合も、
「今バックアップできるか」だけでなく、「暗号化方式を変更した後も保護できるか」
まで考えておくことが重要です。
最終的には、
暗号化方式は？
↓
Rubrik対応？
↓
Keyは利用可能？
↓
RBACは十分？
↓
Azure Policyに拒否されない？
↓
Network Accessは可能？
↓
Resource Lockは？
↓
Recovery先でも同じSecurity条件を満たせる？
↓
Application起動
まで確認して、初めてSecurityを含めたBackup / DR設計が成立します。
次回：高度機能編
次回は、
【Rubrik × Azure VM｜高度機能編】VMバックアップだけでは足りない？Application ConsistencyとFile Recoveryを整理する
として、
- Crash Consistent
- Application Consistent
- Windows VSS
- Rubrik Backup Service（RBS）
- Exocompute
- File Indexing
- File-Level Recovery
- In-place File Recovery
- Premium SSD v2
- Ultra Disk
- Storage Spaces
- Supported File System
- Anomaly Detection
などを整理します。
特に、
VM Backupが成功していても、ファイルやApplicationを必要な粒度で戻せるとは限らない
という点を掘り下げます。
参考資料
- Rubrik Compatibility Matrix：Azure virtual machine supported features and limitations
- Rubrik Documentation：Required permissions for protecting Azure resources
- Rubrik Documentation：Private access to an Azure snapshot
- Rubrik Documentation：Replication of Azure snapshots
- Microsoft Learn：Overview of managed disk encryption options
- Microsoft Learn：Server-side encryption of Azure managed disks
- Microsoft Learn：Azure Disk Encryption
- Microsoft Learn：Customer-managed keys for Azure managed disks
- Microsoft Learn：Restrict managed disks from being imported or exported
- Microsoft Learn：Azure Virtual Machines Policy Reference
- Microsoft Learn：Azure Resource Locks