Azure Disk Storage のクロステナント CMK 対応は、単に「暗号化の選択肢が増えた」という話ではありません。企業やSaaS事業者が、ディスクを持つテナントと暗号鍵を管理するテナントを分離できるようになる点が重要です。特に、共有サービス基盤、マルチテナントSaaS、金融・公共・医療などの規制対応が求められるAzure環境では、インフラ運用と鍵管理の責任分界を明確にしやすくなります。
2026年4月16日時点のAzure Updatesでは、Azure Disk Storageにおいて、Premium SSD v2 と Ultra Disks 向けの cross-tenant customer-managed keys、つまりクロステナント CMK が一般提供されたことが案内されています。これにより、高性能ディスクを使うワークロードでも、別の Microsoft Entra テナントにある Azure Key Vault のカスタマー管理キーを使った暗号化設計を採用しやすくなりました。(Microsoft Azure)
Azure Disk Storage のクロステナント CMK とは何か
Azure Disk Storage の CMK、つまり customer-managed keys は、マネージドディスクの暗号化に使われる鍵管理をユーザー側で制御する仕組みです。通常、Azureのマネージドディスクは保存時に暗号化されますが、CMKを使うと、Azure Key Vault または Managed HSM に格納した自社管理の鍵で、ディスク暗号化に関わるアクセス制御やローテーションをより細かく管理できます。(Microsoft Learn)
クロステナント CMK は、この鍵をディスクと同じ Microsoft Entra テナントではなく、別テナントの Key Vault に置けるようにする仕組みです。
たとえば、次のような構成が可能になります。
| 構成要素 | 所有・管理する主体 | 例 |
|---|---|---|
| VM、マネージドディスク、Disk Encryption Set | サービス提供側・共通基盤側のテナント | SaaS事業者、社内共通クラウド基盤チーム |
| Azure Key Vault、暗号鍵、鍵へのアクセス許可 | 顧客側・事業部側・セキュリティ管理側のテナント | 顧客企業、規制対象部門、CISO配下の鍵管理チーム |
| 鍵の利用許可 | 鍵所有者が明示的に付与 | Key Vault RBAC、サービスプリンシパル、フェデレーションID |
ポイントは、ディスクの運用権限と暗号鍵の支配権を同じ管理境界に置かなくてよいことです。これは、エンタープライズの分離モデルでは非常に大きな意味を持ちます。
2026年4月の更新で何が変わったのか
今回の更新では、Azure Disk Storage の Premium SSD v2 と Ultra Disks に対して、クロステナント CMK が一般提供されました。Premium SSD v2 と Ultra Disks は、高いIO性能や低レイテンシが求められるデータベース、分析基盤、トランザクション処理、SAPなどの重要ワークロードで検討されやすいディスクです。
これまでもAzureではCMKによるディスク暗号化の設計は可能でしたが、高性能ディスクを使う環境では「性能要件」「暗号鍵の統制」「テナント分離」を同時に満たす設計が難しくなる場面がありました。今回の一般提供により、Premium SSD v2 や Ultra Disks を使うシステムでも、鍵管理を別テナントに分離する設計を本番ワークロードの選択肢として検討しやすくなります。
Microsoft Learnでは、クロステナント CMK を使う構成として、サービスプロバイダー側のテナントに Disk Encryption Set、マネージドID、アプリ登録を置き、顧客側のテナントにエンタープライズアプリ、Key Vault、鍵、ロール割り当てを置くワークフローが説明されています。(Microsoft Learn)
なぜ企業の分離モデルで重要なのか
エンタープライズ環境では、「Azureサブスクリプションを分ける」だけでは十分でないケースがあります。サブスクリプション分離は課金・権限・リソース管理には有効ですが、ID基盤やアプリケーション同意、鍵管理の境界としては Microsoft Entra テナントの設計が重要になります。
クロステナント CMK が重要なのは、次のような分離を実現しやすくするためです。
| 分離したいもの | 従来起きやすかった課題 | クロステナント CMK で得られる効果 |
|---|---|---|
| インフラ運用と鍵管理 | インフラ管理者が鍵にも強い権限を持ちがち | 鍵の所有・ローテーション・無効化を別テナント側に寄せられる |
| サービス提供者と顧客 | SaaS基盤側に顧客データと鍵の両方が集まりやすい | 顧客が自テナントのKey Vaultで鍵を管理できる |
| 事業部と共通基盤 | 共通基盤チームに統制が集中しやすい | 事業部や規制対象部門が鍵の統制権を持てる |
| グローバル運用とローカル規制 | 各国・各地域のデータ統制要件に合わせにくい | 地域・法人・規制単位で鍵管理テナントを分けやすい |
特に重要なのは、鍵を持つ側が最終的な統制点を持てることです。インフラ側がVMやディスクを運用していても、鍵へのアクセスが失われれば暗号化されたディスクデータを利用できなくなります。これは強力な統制手段である一方、設計を誤ると可用性リスクにもなります。
共有サービス基盤での価値
大企業では、各事業部が個別にAzure環境を作るのではなく、クラウドCoEやプラットフォームチームが共通基盤を提供する形が増えています。このとき問題になるのが、「基盤は共通化したいが、データや鍵の責任は事業部ごとに分けたい」という要件です。
たとえば、次のような構成です。
- 共通基盤チームが、VM、ネットワーク、監視、バックアップ、セキュリティ標準を管理する
- 金融系事業部が、自部門の鍵を専用テナントのKey Vaultで管理する
- 医療系事業部が、別のテナントで鍵のローテーションやアクセス監査を管理する
- 海外子会社が、地域ごとの規制に合わせて鍵管理を分離する
この場合、すべてのディスクとKey Vaultを同一テナントに置くと、組織上の責任分界が曖昧になります。クロステナント CMK を使えば、共通基盤側はAzureリソースの標準化と運用効率を維持しながら、鍵の統制は各事業部や顧客側に委ねる設計ができます。
これは、単なるセキュリティ強化ではなく、プラットフォーム運用のスケーラビリティにも関係します。共有サービス基盤は「全員に同じものを押し付ける基盤」ではなく、「共通化しつつ、責任境界を選べる基盤」であるべきだからです。
規制対応が必要なAzure環境で重要になる理由
規制対象のAzureデプロイでは、「データが暗号化されているか」だけでなく、「誰が鍵を管理しているか」「誰が鍵へのアクセスを承認できるか」「鍵を無効化した場合に何が起きるか」まで問われます。
クロステナント CMK は、こうした説明責任を整理しやすくします。
| 規制・監査で問われやすい観点 | 設計上の回答例 |
|---|---|
| 鍵の所有者は誰か | 顧客または規制対象部門のMicrosoft EntraテナントでKey Vaultを管理する |
| インフラ管理者が鍵を自由に使えないか | Key Vault RBACで必要最小限のロールのみを付与する |
| 鍵の利用状況を監査できるか | Key Vaultの監査ログ、Azure Monitor、SIEM連携で確認する |
| 契約終了時にアクセスを停止できるか | 顧客側がKey Vaultの権限を取り消す、または鍵を無効化する |
| グローバル展開時に地域要件を満たせるか | 地域ごとにKey Vaultとディスクの配置を確認する |
ただし、CMKは「導入すれば自動的にコンプライアンスを満たす機能」ではありません。鍵のライフサイクル、ロール設計、監査ログの保全、障害時の復旧手順まで含めて、運用プロセスとして成立している必要があります。
アーキテクチャの基本パターン
クロステナント CMK の構成では、大きく分けて「サービス提供側テナント」と「鍵所有側テナント」が登場します。
サービス提供側テナントに置くもの
サービス提供側、または共有基盤側のテナントには、主に次のリソースを配置します。
- Azure VM
- Premium SSD v2 または Ultra Disk
- Disk Encryption Set
- ユーザー割り当てマネージドID
- マルチテナント Microsoft Entra アプリ登録
- 必要に応じたIaCテンプレートや運用自動化
このテナントは、ワークロードを動かす側です。SaaS事業者であればサービス基盤、社内共通基盤であればクラウドプラットフォームチームの管理領域になります。
鍵所有側テナントに置くもの
鍵所有側、つまり顧客・事業部・セキュリティ組織側のテナントには、主に次のリソースを配置します。
- Azure Key Vault
- CMKとして使うRSA鍵
- サービス提供側アプリのエンタープライズアプリ
- Key Vaultへのロール割り当て
- 鍵ローテーション、監査、アラート設定
Microsoft Learnでは、顧客側がサービス提供側のアプリに対してKey Vaultアクセスを許可し、サービス提供側がその鍵URIを使ってAzureリソースを暗号化する流れが説明されています。Key Vaultへの権限付与では、Key Vault Crypto Service Encryption User ロールが例として示されています。(Microsoft Learn)
導入前に確認すべき判断基準
クロステナント CMK は強力ですが、すべてのAzure Disk Storage環境に必要なわけではありません。導入判断では、次の基準で考えると実務的です。
| 判断項目 | 導入を検討すべきケース | 見送ってよいケース |
|---|---|---|
| テナント分離 | 顧客、子会社、事業部、規制単位で鍵管理を分けたい | 単一テナント・単一運用チームで完結している |
| ディスク性能 | Premium SSD v2 や Ultra Disks を使う重要ワークロードがある | Standard SSD/HDD中心で高度な分離要件がない |
| 監査要件 | 鍵所有者、利用履歴、権限付与の説明が必要 | 暗号化方式の標準設定だけで要件を満たせる |
| SaaS/BYOK | 顧客が自社テナントで鍵を持つBYOKを求める | 顧客別の鍵管理を提供していない |
| 運用成熟度 | Key Vault、RBAC、監査、障害対応の運用体制がある | 鍵失効時の影響や復旧手順を管理できない |
導入の目安は、「鍵の所有者がインフラ所有者と異なることを、契約・監査・運用のいずれかで説明する必要があるか」です。必要がないなら、通常のCMKやプラットフォーム管理キーで十分な場合もあります。
設計時のチェックポイント
ディスクとKey Vaultのリージョンを合わせる
クロステナント CMK では、マネージドディスクと顧客側の Key Vault は同じAzureリージョンに配置する必要があります。一方で、サブスクリプションは異なっていても構いません。Microsoft Learnでは、Ultra Disks と Premium SSD v2 について、利用可能リージョンの例外として一部の政府系リージョンや China North 3 が挙げられています。(Microsoft Learn)
本番導入前には、利用予定リージョン、ディスクSKU、Key Vault構成、可用性ゾーンの要件を必ず確認してください。Azureの対応リージョンは更新される可能性があるため、設計書には「確認日」と「参照した公式ドキュメント」を残しておくと、後から監査や変更管理で説明しやすくなります。
鍵の無効化・削除・期限切れ時の影響を理解する
CMKでは、鍵の制御権を持てることがメリットです。しかし、鍵を無効化・削除・期限切れにすると、ワークロードに直接影響します。Microsoft Learnでは、キーが無効化、削除、または期限切れになった場合、該当するOSディスクやデータディスクを使うVMが自動的にシャットダウンし、キーが再度有効になるか新しいキーが割り当てられるまで起動できないと説明されています。また、一般にディスクI/Oはキーが無効化・削除・期限切れになってから約1時間後に失敗し始めます。(Microsoft Learn)
そのため、鍵の無効化を「緊急停止ボタン」として扱う場合でも、事前に次の内容を決めておく必要があります。
- 誰が鍵を無効化できるか
- 無効化前に誰へ通知するか
- 誤操作時に誰が復旧を承認するか
- 復旧に必要な作業手順と所要時間
- 監査ログをどこに保管するか
鍵を握るチームとVMを運用するチームが別組織になるほど、連絡経路と承認フローの設計が重要になります。
アプリ登録とフェデレーションIDのスケールを設計する
クロステナント CMK では、マルチテナントアプリ登録、ユーザー割り当てマネージドID、フェデレーションID資格情報、顧客テナント側のサービスプリンシパルが関係します。ここを曖昧にすると、導入初期は動いても、顧客数や事業部数が増えたときに管理できなくなります。
Microsoft Learnでは、同じマルチテナントアプリを複数テナントのキーアクセスに使える一方、アプリケーションが持てるフェデレーションID資格情報の上限に関する注意点も示されています。(Microsoft Learn)
実務では、次のように設計方針を決めておくと安全です。
| 設計項目 | 推奨される考え方 |
|---|---|
| アプリ登録 | 顧客単位、環境単位、サービス単位のどこで分けるかを先に決める |
| マネージドID | 共有しすぎると影響範囲が広がるため、ワークロード単位の分離を検討する |
| Key Vaultロール | 最小権限を原則にし、暗号化操作に必要な権限だけを付与する |
| 命名規則 | テナント、顧客、環境、本番・非本番が判別できる名前にする |
| 棚卸し | どのDisk Encryption SetがどのKey Vaultキーを参照しているか定期的に確認する |
サブスクリプション移動やテナント移動を安易に行わない
CMKはマネージドIDやMicrosoft Entra IDに依存します。Microsoft Learnでは、CMKを構成した後にサブスクリプション、リソースグループ、マネージドディスクを別の Microsoft Entra ディレクトリへ移動すると、関連するマネージドIDが新しいテナントへ移らず、CMKが機能しなくなる可能性があると説明されています。(Microsoft Learn)
M&A、組織再編、サブスクリプション統合、テナント統合を予定している企業では、クロステナント CMK の導入前にID基盤のロードマップを確認してください。暗号化設計は、ネットワークやVMよりも後から変更しにくい場合があります。
失敗しやすいポイント
「暗号化されているから安全」と考えてしまう
Azure Disk Storageは標準で保存時暗号化が行われます。CMKやクロステナント CMK は、暗号化の有無だけを変えるものではなく、鍵の管理責任とアクセス制御を変えるものです。
そのため、「とりあえずCMKにする」では不十分です。誰が鍵を作成し、誰がローテーションし、誰が削除でき、誰が監査ログを見るのかを決めなければ、むしろ運用リスクが増えます。
Key Vaultの権限付与を広くしすぎる
検証環境でよくある失敗は、動作確認を急いで広い権限を付与してしまうことです。本番では、Key Vault Contributor のような管理権限と、暗号化操作に必要な利用権限を分けて考える必要があります。
鍵を作る人、鍵を使わせる人、鍵の利用状況を監査する人は、同じである必要はありません。むしろ規制対応では分けるべきケースが多くなります。
鍵ローテーションを運用に組み込んでいない
CMKを使うなら、鍵ローテーションの運用が必要です。Azure Disk Storageでは、Disk Encryption Setがキーを参照し、自動ローテーションを有効にすると、関連するマネージドディスク、スナップショット、イメージが新しいキーバージョンを使うよう更新されます。Microsoft Learnでは、通常1時間以内に新しいキーバージョンへ更新され、VMの再起動は不要と説明されています。(Microsoft Learn)
ただし、自動ローテーションを有効にしていても、監査、通知、期限切れ前の検知は別途設計が必要です。特に複数テナントをまたぐ場合、鍵所有側のチームがローテーションした結果、基盤側の監視や運用ドキュメントが追随していない、というズレが起きやすくなります。
ディザスタリカバリを鍵込みで考えていない
ディスクのバックアップやスナップショットだけを考えても、Key Vaultと鍵が利用できなければ復旧できない場合があります。規制対象ワークロードでは、リージョン障害、Key Vaultアクセス障害、誤削除、権限取り消しを含めた復旧設計が必要です。
最低限、次の観点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| バックアップ | バックアップ対象ディスクと鍵の対応関係を記録しているか |
| 復旧先リージョン | 復旧先で同等のディスクSKUとKey Vault構成が使えるか |
| 権限復旧 | サービスプリンシパルやロール割り当てを再作成できるか |
| 鍵の保護 | Key Vaultの削除保護、論理削除、アクセス監査を有効化しているか |
| 手順訓練 | 鍵無効化、権限取り消し、復旧のリハーサルを行っているか |
既存環境での導入ステップ
既存のAzure環境にクロステナント CMK を導入する場合は、いきなり全ディスクへ展開するのではなく、対象を絞って段階的に進めるのが現実的です。
| ステップ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | Premium SSD v2、Ultra Disks、重要ワークロードを棚卸しする | 対象ディスク一覧 |
| 要件整理 | 鍵を誰が持つべきか、テナント分離が必要かを確認する | 鍵所有モデル |
| 設計 | Disk Encryption Set、Key Vault、アプリ登録、RBACを設計する | 構成図・権限表 |
| 検証 | 非本番で鍵ローテーション、権限取り消し、障害時の挙動を試す | 検証結果・運用手順 |
| 自動化 | Bicep、Terraform、Azure CLIなどで再現可能にする | IaCテンプレート |
| 統制 | Azure Policy、監査ログ、アラート、定期レビューを整備する | 運用ルール |
| 本番展開 | 重要度の高いワークロードから段階的に適用する | 移行計画・完了報告 |
特に重要なのは、検証段階で「正常に暗号化できるか」だけでなく、「鍵を無効化したら何が起きるか」「権限を戻したら復旧できるか」「ローテーション時に監視アラートは出るか」まで確認することです。
セキュリティアーキテクトが見るべき設計観点
セキュリティアーキテクトは、クロステナント CMK を単体機能としてではなく、エンタープライズ全体の統制モデルとして見る必要があります。
チェックすべき観点は次の通りです。
- テナント境界は、組織上の責任境界と一致しているか
- 鍵所有者とワークロード運用者の責任分界が文書化されているか
- Key Vaultのロール割り当てが最小権限になっているか
- 鍵の無効化・削除・期限切れが業務停止につながることを関係者が理解しているか
- 鍵ローテーション、監査ログ、アラートが運用プロセスに組み込まれているか
- 契約終了、顧客退会、事業移管時の鍵アクセス停止手順があるか
- DR時にKey Vaultとディスクの両方を復旧できるか
ここで重要なのは、「誰がAzureリソースを作れるか」ではなく、「誰がデータへの最終的なアクセス可否を左右できるか」です。クロステナント CMK は、この統制点をインフラ運用者から鍵所有者へ分離するための設計部品と考えると理解しやすくなります。
クラウドインフラチームが見るべき運用観点
クラウドインフラチームにとっては、クロステナント CMK は運用負荷を増やす要素にもなります。だからこそ、標準化が欠かせません。
運用で整備すべきものは次の通りです。
- Disk Encryption Setの標準命名規則
- Key Vault URIとディスクの対応台帳
- テナント間の連絡先とエスカレーションルート
- 鍵ローテーション時の確認手順
- Key Vault権限変更時の変更管理
- Azure Policyによる非準拠リソースの検知
- 本番障害時に鍵所有側へ連絡する手順
- サービスプロバイダー・顧客間の責任分界表
共有サービス基盤では、個別案件ごとに手作業で設定すると破綻します。IaCで再現できること、監査ログが自動で集まること、権限変更がチケットや承認フローに残ることを前提に設計してください。
まとめ：クロステナント CMK は「鍵の所在」を設計するための機能
Azure Disk Storage の Premium SSD v2 と Ultra Disks でクロステナント CMK が一般提供されたことにより、高性能ディスクを使う重要ワークロードでも、テナントをまたいだ鍵管理モデルを取り入れやすくなりました。
この機能が特に重要なのは、次のような環境です。
- SaaS事業者が顧客管理の鍵を使ったBYOKを提供したい
- 企業の共通Azure基盤で、事業部ごとに鍵管理を分離したい
- 金融、公共、医療、グローバル企業などで、鍵の所有者を明確にしたい
- Premium SSD v2 や Ultra Disks を使う重要システムでも、規制対応と性能要件を両立したい
次に行うべきことは、すべてのディスクへ一律に適用することではありません。まず、Premium SSD v2 と Ultra Disks を使っている重要ワークロードを棚卸しし、鍵の所有者とインフラ運用者を分ける必要があるかを確認してください。そのうえで、非本番環境でクロステナント CMK の構成、鍵ローテーション、権限取り消し、復旧手順を検証するのが安全な進め方です。
コメント