Azure Storage で暗号化やキー管理を検討するとき、「Microsoft 管理キー（MMK/PMK）はどこにあって安全なのか？」「CMK（顧客管理キー）を使うべきか？」という疑問はほぼ必ず出てきます。本記事では公式ドキュメントをベースに、MMK の保管場所・ローテーション・CMK との違いを実務目線で整理します。
Azure Storage における Microsoft 管理キー（MMK/PMK）の要点まとめ
この記事で整理する疑問
- MMK（Microsoft / Platform Managed Keys）はどこに保管されるのか？Key Vault の場所を特定できるのか？
- MMK はどのくらいの頻度でローテーションされるのか？自動なのか？
- MMK と CMK（Customer Managed Keys）の違い・安全性の差はどこにあるのか？
- MMK の保管場所を明示した公式情報は存在するのか？
結論（先に要点だけ知りたい方向け）
- MMK/PMK は Azure の「Microsoft key store」で、Azure が内部的に生成・保管・運用するキー。顧客から具体的な保管場所（Key Vault や HSM のインスタンス）を特定することはできません。
- MMK のローテーションは Microsoft が自動で実施。Azure Storage のドキュメント上は「コンプライアンス要件に沿って適切にローテーションされる」とだけ記載されており、具体的な間隔は意図的に非公開です。
- 暗号化の強度（AES 256 など）は MMK でも CMK でも同等。違いは「鍵の所在・操作権限・監査可能性・責任分界」です。
- 「MMK がどの Key Vault に入っているか」といったレベルの場所は、公式には公開されていません。公式に分かるのは「Microsoft key store にあり、Azure が全面的に管理する」というところまでです。
ここから先は、この結論をもう少し分解して、「なぜそうなっているのか」「監査や設計ではどう説明・判断すべきか」を詳しく見ていきます。
Azure Storage の暗号化とキー管理の前提
Azure Storage の暗号化の基本
Azure Storage は、すべてのデータを AES 256 ビットでサーバー側暗号化（Service-side Encryption, SSE）し、すべてのストレージアカウントで既定有効・無効化不可という仕様になっています。暗号化対象は Blob / Files / Queues / Tables だけでなく、メタデータも含めて全面的です。
新規に作成されたストレージアカウントでは、暗号化に使用されるキーはデフォルトで Microsoft-managed keys（MMK） です。必要に応じて、後から CMK（Customer-managed keys）や CPK（Customer-provided keys）を選ぶこともできます。
キー管理方式の種類
Azure Storage の公式ドキュメントには、キー管理方式の比較表が掲載されています。簡略化した形で再整理すると次のようになります。
| 項目 | Microsoft-managed keys (MMK) | Customer-managed keys (CMK) | Customer-provided keys (CPK) |
|---|---|---|---|
| 主な用途 | 既定の暗号化（ほぼ全サービス） | Blob / Files などでの BYOK / 監査要件対応 | Blob 単位での細かい暗号制御 |
| キーの保管場所 | Microsoft key store（Microsoft 内部基盤） | Azure Key Vault / Managed HSM（顧客テナント） | 顧客側のキーストア（アプリごとに任意） |
| キーの生成・ローテーション | Microsoft が自動で実施 | 顧客が実施（自動ローテーション設定も可） | 顧客が実施 |
| キー操作の権限 | 顧客からは操作不可 | 顧客が Key Vault / HSM 上でフル管理 | アプリ側でフル管理 |
| 監査ログ | Azure 内部。顧客からの詳細参照は不可 | Key Vault / HSM の診断ログで詳細監査可能 | 顧客実装次第 |
| コスト | 追加コストなし | Key Vault / HSM 利用料 + 運用コスト | 独自実装のコスト |
| 主な選択理由 | シンプル、運用レス | 規制・社内ポリシー・契約で BYOK/監査が必要 | アプリ固有の暗号要件 |
Microsoft 管理キー（MMK/PMK）の正体と保管場所
MMK はどこに保管されるのか？
Azure Security のキー管理ドキュメントでは、Platform-managed keys (PMKs) は「Azure によって生成・保管・管理され、顧客はそれに直接触れない」と明記されています。
さらに、Azure Storage の暗号化ドキュメントの比較表では、Microsoft-managed keys の「Key storage」が Microsoft key store とされています。
これらから言える公式情報は次の通りです。
- MMK/PMK は Azure の Microsoft key store（Microsoft 管理のキー保管基盤）に格納される。
- この基盤は顧客のサブスクリプション外にあり、顧客テナントからはリソースとして見えない。
- 顧客はキーの 生成・削除・ローテーション・バックアップ場所に直接関与しない。
独立した第三者ホワイトペーパーでも、PMK は顧客環境の外側に存在するため、顧客はログや直接の管理情報を取得できないと整理されています。
Key Vault の場所を特定できるか？Microsoft key store にアクセスできるか？
結論から言うと、MMK に対して Key Vault のインスタンス名やリージョンを特定したり、Microsoft key store に直接アクセスすることはできません。
理由はシンプルで、MMK/PMK は「Azure 側で完全に閉じたマネージドキー」であり、顧客サブスクリプション配下の Azure Key Vault や Managed HSM とはまったく別ラインに置かれているためです。
実務上は次のように理解しておくと整理しやすいです。
- MMK は 「Azure Storage が内部的に使うルート鍵」であり、サービスの一部として組み込まれている。
- 顧客から見えるのは「このストレージアカウントが MMK か CMK か」という設定だけで、鍵そのものはブラックボックス。
- 内部的には HSM などの保護されたストレージ上で管理されるが、どのハードウェア／クラスタに置かれているかといった情報は非公開。
内部実装のヒント：統合 HSM と Azure Storage
Key management in Azure の最新ドキュメントでは、新しい Azure サーバーハードウェアに 統合 HSM（Integrated HSM） が組み込まれ、Azure Storage 暗号化や Azure Key Vault のキーをハードウェア境界内で保護する設計が紹介されています。
この記述から、MMK も含め Azure Storage の暗号化キーは、ソフトウェアだけでなく FIPS 認定 HSM によるハードウェア保護も組み合わせた形で保管されていることが分かります（ただし、具体的な構成や場所は公開されていません）。
「MMK の保管場所を明示した公式情報」はどこまであるか？
まとめると、Microsoft が公式に公開しているのは次のレベルまでです。
- PMK / MMK は Azure によって生成・保管・管理され、顧客は直接触れない。
- Azure Storage における Microsoft-managed keys のキー保管先は Microsoft key store である。
- PMK は顧客環境の外側に存在し、顧客にはログなどの詳細情報は提供されない。
「どの Key Vault（名称・URI）が使われているか」「どの物理リージョン／ラックに置かれているか」といった情報は公開されておらず、今後も公開予定はないと考えてよいでしょう。
MMK のローテーション（定期更新）について
Azure Storage 公式ドキュメントが明言していること
Azure Storage encryption for data at rest のドキュメントには、次のような記載があります（要約）。
- Microsoft-managed keys はコンプライアンス要件に従って適切にローテーションされる。
- ローテーション頻度などに特定の要件がある場合は、Customer-managed keys に移行して自分で管理・監査することが推奨される。
つまり、ローテーション自体は Azure 側で自動実行されており、顧客が何か設定する必要はありません。
ローテーション頻度はなぜ公開されていないのか
Microsoft Q&A で、Platform-managed keys (PMKs) のローテーション頻度について公式に確認された結果が公開されています。
- PMK のローテーション頻度は意図的に非公開であり、ドキュメントに記載しない方針である。
- 顧客がローテーション頻度をコントロール・監査する必要がある場合は、Customer-managed keys を使うべきというのが Microsoft の推奨。
セキュリティの観点から見ると、これはいわゆる「security by obscurity」の一面もありますが、クラウド事業者としての内部運用を公開しすぎないためのポリシーとも言えます。
ローテーション時に何が起きるのか（概念的な理解）
Azure の「Encryption at rest」ドキュメントでは、Azure 全体の暗号化モデルとして 「DEK（Data Encryption Key）と KEK（Key Encryption Key）の階層構造（エンベロープ暗号）」を採用していることが説明されています。
- 大容量データの暗号化には対称鍵（DEK）を利用
- DEK 自体は、別の鍵（KEK）で暗号化して安全な場所に保存
- DEK の保管場所はサービス内部に近く、KEK はより厳格なキー管理サービス（Key Vault など）で保護
Azure Storage の CMK ドキュメントでは、次のような動きを明記しています。
- ストレージアカウントに CMK を設定すると、「アカウント暗号化キー（ルート DEK）」が CMK でラップされる。
- CMK のキーやバージョンを変更しても、「ルート暗号化キーの保護方法が変わるだけ」であり、データの再暗号化は不要・ダウンタイムも発生しない。
MMK について内部実装の詳細は公開されていませんが、同じ Azure Storage の暗号化機構上に乗っているため、MMK 側でも「ルート鍵の保護方式（PMK）をローテーションしているが、保存済みデータが毎回フル再暗号化されるわけではない」という設計だと考えるのが自然です（設計思想からの推測であり、細部は非公開）。
監査で「ローテーション頻度を証跡として出せ」と言われたら
MMK については、前述のとおり 具体的なローテーション間隔やスケジュールを証跡として出すことはできません。そのため、監査・規制・顧客との契約で「ローテーション頻度を自ら定義し、証跡も残すこと」が求められる場合は、実務上次のような方針になります。
- Azure Storage の暗号化方式自体は MMK のままで良いか？ → 要件次第。
- 明示的なローテーション頻度の設定や証跡が必須なら、CMK を選ぶ（もしくは補助的に利用）。
- Key Vault のローテーションポリシー機能を使うことで、「1 年ごと」など自社ポリシーに沿った自動ローテーションと監査ログを残せる。
MMK と CMK の安全性・違いを実務視点で比較
暗号強度はどちらも同じレベル
Azure Storage の暗号化は、AES 256 ビットかつ FIPS 140 準拠で実装されており、MMK でも CMK でもこの点は共通です。
つまり、「どちらの鍵を使うか」で暗号アルゴリズムの強さが変わるわけではありません。安全性の差は「暗号方式」ではなく 「鍵の所有者・運用・監査・責任分界」 にあります。
MMK vs CMK 詳細比較（実務版）
| 観点 | MMK（Microsoft / Platform Managed Keys） | CMK（Customer Managed Keys） |
|---|---|---|
| 鍵の所在 | Microsoft key store（Azure 内部。顧客から不可視） | 自テナントの Azure Key Vault / Managed HSM（顧客管理） |
| 鍵の生成・破棄・ローテーション | Azure が自動実施。頻度は非公開 | 顧客が実施（手動 or Key Vault の自動ローテーションポリシー） |
| 鍵操作へのアクセス | 顧客はアクセス不可 | Key Vault / HSM の RBAC / アクセスポリシーで細かく制御可能 |
| 監査ログ | Azure 内部ログのみ。顧客は参照不可 | Key Vault 診断ログや Azure Monitor で誰がいつ鍵を触ったかを詳細に監査可能 |
| 運用負荷・コスト | 追加コスト・運用ほぼゼロ | Key Vault / HSM の利用料 + キー運用（ローテーション・権限管理・障害対応など）が必要 |
| 可用性リスク | Azure が吸収（内部で高可用に設計） | Key Vault / HSM 障害や誤設定でキーにアクセスできなくなると、ストレージの復号ができなくなるリスク（例：Azure NetApp Files では、Key Vault にアクセスできないとデータの読み書きができなくなることが明記） |
| 即時失効（キルスイッチ） | Azure 側の運用範囲で管理され、顧客が直接トリガーすることはできない | Key Vault のキーを無効化・削除・アクセス権剥奪で「暗号鍵へのアクセスを即時遮断」できる |
| 適した用途 | 既定暗号化で十分なシステム、規制・契約要件が緩い環境 | 規制・顧客契約で BYOK / ローテーション監査 / キー所有が必須な環境 |
二重暗号化（Infrastructure encryption）との関係
Azure Storage では、通常の SSE に加えて Infrastructure encryption（インフラレベルの二重暗号化） を有効化することもできます。この場合、サービスレベル暗号化とインフラレベル暗号化で別々のキー・アルゴリズムが使われ、インフラレベル側は常に Microsoft-managed keys です。
つまり、CMK を選んだ場合でも、インフラ側では常に MMK が併用されるという点は押さえておくとよいでしょう。
MMK / CMK どちらを選ぶべきか ― 意思決定ガイド
MMK で十分なケース
次のような条件であれば、Azure 既定の Microsoft-managed keys のままで十分なことが多いです。
- 規制や顧客契約で BYOK / CMK / 鍵ローテーションの監査 が明示されていない。
- 「暗号化されていること」が求められるが、「鍵の所有者が自社であること」までは要求されていない。
- セキュリティ要件と比較して、運用負荷（24時間対応の鍵運用チームなど）を増やしたくない。
- インシデント時も「Azure 標準の責任分界（物理層～ハイパーバイザ層は Microsoft 管理）」に乗せたい。
CMK を選ぶ／検討すべきケース
一方、以下のような要件がある場合は、CMK を強く検討すべきです。
- 法規制・業界規制（金融・公共など）で BYOK / CMK / 鍵ローテーションの証跡が要求されている。
- 顧客との契約上、鍵の所有権が自社にあることを明示する必要がある。
- 特定のデータについて、鍵を無効化することでアクセスを即時に遮断できる仕組みが求められる。
- セキュリティ監査で「誰がいつ鍵を使って復号したのか」という詳細なログを提示する必要がある。
- 職務分掌（アプリ運用担当と鍵管理担当を分離）や、HSM レベルの分離など、より厳格な要件がある。
意思決定を整理するための簡易マトリクス
| 要件 | MMK | CMK |
|---|---|---|
| 暗号化必須だが、鍵の所有者は問われない | ◎（既定で満たす） | △（過剰な場合も） |
| 鍵ローテーションの頻度を自社で決めたい・監査したい | ×（具体的な頻度は非公開） | ◎（Key Vault ポリシーで制御・監査可能） |
| 「鍵を無効化＝データアクセスを止める」キルスイッチが必要 | △（Azure サポート経由の対応のみ） | ◎（Key Vault のアクセス権・有効状態で即時制御） |
| 運用コストを最小にしたい | ◎ | △（Key Vault/HSM の設計・運用が必要） |
| 社外・親会社のセキュリティレビューで「クラウド事業者管理の鍵では不可」と言われている | × | ◎ |
CMK を使うときの設計・移行の実務ポイント
1. 鍵保管先（Key Vault / Managed HSM）の設計
Azure Storage で CMK を使う場合、鍵は Azure Key Vault または Azure Key Vault Managed HSM に保存する必要があります。
Key Vault 側では次の点を必ず満たす必要があります。
- Soft delete と purge protection を有効化（削除・完全削除の誤操作からキーを守るため。Storage 向け CMK では必須）。
- ネットワーク制御（パブリックアクセス制限・Private Endpoint 利用など）をどうするか。
- RBAC / アクセスポリシーで、誰がどの操作（get / wrapKey / unwrapKey など）を実行できるかを設計。
2. 鍵の種類とサイズ
Azure Storage の CMK では、RSA および RSA-HSM キーの 2048 / 3072 / 4096 ビットがサポートされています。
- 多くの環境では RSA 3072 または 4096 ビットが推奨されます（長期利用や高い安全性を要求する場合）。
- HSM キーを使うかどうかは、FIPS レベルやコンプライアンス要件次第です。
3. Storage アカウントとのひも付け（Managed Identity）
Azure Storage で CMK を利用するフローは概ね次のようになります。
- Key Vault 管理者が、ストレージアカウントに割り当てる Managed Identity（システム割り当て or ユーザー割り当て）に対して、対象キーの
get/wrapKey/unwrapKeyなど必要な権限を付与。 - Storage 管理者が、ストレージアカウントの 暗号化設定で CMK を選択し、Key Vault のキー URI を設定。
- 以降、Azure Storage は Managed Identity を使って Key Vault にアクセスし、アカウント暗号化キーを CMK でラップした上で暗号・復号処理を行う。
重要なのは、CMK を構成しても 実際のデータを暗号化するのはあくまでサービス内部の DEK であり、CMK はその DEK を保護する KEK として使われるという点です。
4. ローテーション運用（Key Vault 側と Storage 側）
Key Vault で CMK を運用する場合、ローテーション設計では次の 2 つを切り分けて考えます。
- Key Vault 側：鍵バージョンを増やしていく（新バージョンの生成・有効期限・ローテーションポリシー）。
- Storage 側：どのバージョンのキーを暗号化に使うか（URI にバージョンを含めるかどうか）。
Azure Storage のドキュメントでは、次のようなローテーション動作が定義されています。
- Storage は毎日 Key Vault を確認し、新しいキー バージョンがあれば自動的に切り替えることができる。
- そのためには、Storage 側に設定するキー URI から「バージョン部分」を省略しておく必要がある。
- 逆に、特定のバージョンを固定したい場合は、URI にバージョンを含めて明示的に指定する。
- キーやバージョンを変更しても、ルート暗号化キーの保護だけが切り替わり、データ自体の再暗号化は不要。パフォーマンスや可用性への影響はほぼない。
5. 障害・誤操作への備え
CMK を採用すると、「Key Vault が真の単一障害点（SPOF）になり得る」という視点が重要になります。
- Key Vault の一時的な障害やネットワーク切断・アクセス誤設定により、Storage がキーを取得できなくなると、データの読み書きに失敗する可能性があります。
- 誤ってキーを無効化・削除すると、事実上データを復号できなくなるリスクがあります（暗号的な削除）。
- Soft delete / Purge Protection の有効化、ブレークグラス用の管理者・サブスクリプション、バックアップポリシーなどを必ず設計する必要があります。
よくある誤解と、その整理のしかた
「MMK の Key Vault（場所）を教えてほしい」
→ 不可です。
MMK / PMK は、顧客テナントの Key Vault ではなく、Azure 内部の Microsoft key store に存在します。そのため、Key Vault 名や URI・リージョンなどを特定することはできません。
「MMK はローテーションされないのでは？」
→ 公式には「コンプライアンスに沿って適切にローテーションされる」と明言されています。
ただし、具体的な間隔・スケジュール・内部運用プロセスは公開されていません。監査で明示的な頻度や証跡が必要な場合は、CMK を使って自社のローテーションポリシーを適用・監査するのが現実解です。
「MMK と CMK はどちらが“強い暗号”か？」
→ 暗号アルゴリズムや鍵長という意味ではほぼ同等です。
Azure Storage の SSE は AES256 を使用し、FIPS 140 に準拠して実装されています。これは MMK でも CMK でも共通です。
違いは次の 3 点に集約できます。
- 鍵の所在：Azure 内部か、自社の Key Vault / HSM か。
- 鍵の運用：Azure が全自動でやるのか、自社でポリシーを決めて運用するのか。
- 監査・責任分界：鍵操作ログを自社で取得・提示できるか、責任範囲をどう分けるか。
監査・設計レビューでの説明テンプレート例
最後に、セキュリティレビューや監査対応で説明する際に使いやすい整理を紹介します。
MMK を採用している場合の説明例
- Azure Storage のデータは、SSE により AES256 で暗号化されており、暗号鍵は Microsoft-managed keys（MMK）で保護されています。
- MMK は Azure の Microsoft key store に保管され、Azure が生成・保管・ローテーション・廃棄を一貫して管理しています。
- MMK のローテーション頻度は非公開ですが、Azure は国際的なコンプライアンス基準に従ってローテーションを実施します。頻度を顧客側で制御したい場合には CMK を選択する設計になっています。
CMK を採用している場合の説明例
- 暗号化アルゴリズムは MMK と同じ AES256 ですが、ルート暗号化キーの保護に自社 Key Vault の鍵（CMK）を使用しているため、キーの所有・ローテーション・監査を自社ポリシーで管理できます。
- Key Vault では Soft delete / Purge Protection を有効化し、誤削除・悪意ある削除から鍵を保護しています。
- Key Vault の診断ログを利用して、誰がいつ鍵を利用・変更したかを監査し、必要に応じてキーのローテーションポリシーを適用しています。
まとめ
ここまでの内容を一文でまとめると、次のようになります。
MMK は「Azure に鍵運用を全面的に委任する方式」、CMK は「自分で鍵のライフサイクルを握る方式」です。
- 暗号化方式そのものの強度は概ね同じ。
- 違いは、鍵の所在・運用・監査可能性・責任分界・運用コスト。
- 特に規制や契約で BYOK / CMK / ローテーション証跡が求められない限りは、MMK のままでも十分なケースが多い。
- 一方で、コンプライアンスやセキュリティ要件が厳しいシステムでは、CMK を使うことで鍵の所有権と監査性を確保するのが実務的な落としどころになります。
自社の要件と照らし合わせて、「どこまで鍵を自分で握るべきか」を整理すると、Azure Storage における MMK / CMK の選択方針がクリアに見えてくるはずです。
コメント