Azure Key Vault Managed HSMのExternal Key Management（外部キー管理）は、暗号鍵を単に「より厳重に保護する」ための機能ではありません。鍵暗号化キーをMicrosoftのインフラストラクチャ外に置かなければならない法令・規制・契約要件に対応するための選択肢です。
Microsoftは米国時間2026年7月7日付の公式ブログでパブリックプレビューを発表し、Azureサービスの顧客管理キー対応一覧も7月8日に更新しました。対象は限定されており、利用にはMicrosoftアカウントチームによる有効化が必要です。また、外部HSMや接続用プロキシの可用性はManaged HSMのSLAで保護されません。一般的な暗号鍵管理では、従来のManaged HSMキーを引き続き利用する方が、可用性、性能、運用負荷の面で合理的です。(Microsoft Azure)
Azure Managed HSMの外部キー管理で何が変わるのか
従来のAzure Key Vault Managed HSMでは、鍵はAzure内の単一テナント向けHSMで生成・保管されます。HSMはFIPS 140-3 Level 3に準拠し、鍵素材をMicrosoftの運用担当者が読み取ることはできません。
今回のExternal Key Managementでは、鍵暗号化キー、いわゆるKEKを顧客または指定事業者が運用する外部HSMに置きます。Managed HSMには実際の鍵素材ではなく、外部HSM内の鍵を示す参照情報が登録されます。(Microsoft Azure)
| 比較項目 | 通常のManaged HSMキー | External Key Management |
|---|---|---|
| KEKの保管場所 | Azure内の専用HSM | Microsoftインフラストラクチャ外のHSM |
| 鍵素材へのMicrosoftのアクセス | 不可 | 鍵素材自体がMicrosoft側に存在しない |
| Azureサービスからの利用方法 | Managed HSMのキーURIを利用 | Managed HSMのキーURIを利用 |
| 対応する暗号操作 | Managed HSMの通常の鍵操作 | wrapKeyとunwrapKeyのみ |
| ネットワーク | Azure側で管理 | 顧客がEKM Proxyと通信経路を管理 |
| 可用性 | Managed HSM SLAの対象 | 外部キーを含む一連の処理はエンドツーエンドのSLA対象外 |
| 主な用途 | 一般的なCMK、BYOK、暗号鍵管理 | 鍵の物理的な外部保管が必須の規制対応 |
重要なのは、External Key Managementが通常のManaged HSMより一律に安全というわけではない点です。
Managed HSMはもともと、顧客固有のセキュリティドメイン、複数人による復旧制御、ローカルRBAC、鍵のアテステーションなどを備えています。外部キー管理が追加するのは、鍵素材をMicrosoftの施設やインフラストラクチャの外に置く物理的な主権性です。(Microsoft Azure)
External Key Managementの仕組み
顧客管理キーによる保存データの暗号化では、通常、データ自体をデータ暗号化キーで暗号化し、そのデータ暗号化キーをKEKでラップします。
External Key Managementでは、このKEKが外部HSMに保管されます。処理経路は次のとおりです。
Azureサービス
↓ CMKのwrapKey／unwrapKey要求
Azure Key Vault Managed HSM
↓ mTLS
顧客運用のEKM Proxy
↓ HSMベンダー固有の通信
外部HSM各コンポーネントの役割は明確に分かれています。
- Managed HSM：Microsoft Entra IDとManaged HSMローカルRBACによる認証・認可、キー参照の管理、監査ログの出力
- EKM Proxy：Managed HSMからの要求を受け、外部HSM用のプロトコルに変換
- 外部HSM：実際のKEKを保管し、ラップとアンラップを実行
- Azureサービス：従来と同じManaged HSMのキーURIをCMKとして使用
Managed HSMから見ると、外部キーは外部キー識別子を持つキーオブジェクトです。暗号操作が要求されると、Managed HSMはローカルで処理せず、登録されたEKM Proxyへ要求を転送します。KEKそのものがMicrosoftのインフラストラクチャへ送信されることはありません。(Microsoft Learn)
アプリケーションの呼び出し方法は基本的に変わらない
Azureサービスは従来と同じManaged HSMのキーURIとAzure Key Vault APIを利用します。そのため、すでにManaged HSM対応のCMK機能を利用している場合、アプリケーション側のAPIを外部HSM固有のAPIへ書き換える必要はありません。(Microsoft Azure)
ただし、既存のManaged HSMキーをそのまま外部キーへ変換することはできません。キーが通常のManaged HSMキーか外部キーかは作成時に固定されます。
既存環境を移行する場合は、新しい外部キー参照を作成し、各AzureサービスのCMK設定を新しいキーURIへ切り替える作業が必要です。(Microsoft Learn)
対象となるユーザーと利用を見送るべきケース
External Key Managementの主な対象は、政府機関、金融機関、重要インフラ事業者など、次のような要件を持つ組織です。
- 暗号鍵をクラウド事業者の設備内に置けない
- 鍵を保管するHSMの物理的な管理権限が必要
- 契約上、クラウド事業者から独立したルートオブトラストが必要
- 鍵の停止や破棄を自社の物理的な管理下で実施する必要がある
- デジタル主権に関する要件で、鍵の所在を明確に証明する必要がある
Microsoftも、外部キー管理を一般的なセキュリティ強化策ではなく、厳格な規制や契約要件に対応するための限定的な選択肢と位置付けています。(Microsoft Azure)
| 確認する質問 | 判断 |
|---|---|
| 鍵素材をMicrosoftインフラストラクチャ外に置くことが法的・契約的に必須か | 必須なら検討対象 |
| Managed HSMの通常機能では監査要件を満たせないか | 満たせない理由を文書化する |
| エンドツーエンドでSLA保証された鍵利用が必要か | 必要なら通常のManaged HSMキーを優先 |
sign、verify、直接のencrypt、decryptが必要か | 必要なら外部キーは利用不可 |
| EKM Proxyと外部HSMを24時間運用できるか | 運用できなければ利用を見送る |
| 外部HSM障害がAzure上のデータアクセスへ波及しても許容できるか | 許容できなければ利用を見送る |
| Microsoftのプレビュー参加条件を満たすか | アカウントチームへ確認する |
「自社でHSMを持っているから」「セキュリティレベルを上げたいから」という理由だけでは、導入効果よりも可用性低下と運用負荷の方が大きくなる可能性があります。
パブリックプレビューの提供条件
2026年7月時点の公式情報では、External Key Managementには次の提供条件があります。
| 項目 | パブリックプレビューの条件 |
|---|---|
| 利用申請 | Microsoftアカウントチームによるサブスクリプションの有効化が必要 |
| 参加資格 | 担当Microsoftアカウントマネージャーが割り当てられていること |
| 金額条件 | 年間の総Azureコミット額が1,000万米ドル以上 |
| リージョン | 全Azureパブリックリージョン |
| 対象外クラウド | Azure Government、Azure China |
| 利用目的 | Managed HSM対応CMKによる保存データの保護 |
| Microsoft側の追加料金 | 外部キー管理の追加サーチャージなし |
| 別途必要な費用 | 外部HSM、EKM Proxy、ライセンス、ネットワーク、保守運用費 |
| サービス状態 | プレビュー。一般提供までに仕様が変更される可能性あり |
特に、公式ドキュメントに記載された年間1,000万米ドル以上という条件は、多くの一般企業にとって大きな制約です。パブリックプレビューという名称であっても、任意のAzureユーザーがポータルから即座に有効化できる機能ではありません。(Microsoft Learn)
公式ドキュメントでは、プレビュー開始時点の対応ベンダーとしてEntrust、Eviden、Fortanix、Futurex、Securosys、Thales、Utimacoが掲載されています。ただし、この一覧は情報提供を目的としたものであり、Microsoftが各社のプロキシ実装の互換性、品質、可用性を保証するものではありません。導入時はベンダー自身が公開する適合情報とサポート条件を確認する必要があります。(Microsoft Learn)
対応する鍵と暗号操作
External Key Managementは、Managed HSMのすべての暗号操作を外部HSMへ転送する機能ではありません。
プレビュー時点で対応する範囲は次のとおりです。(Microsoft Learn)
| 項目 | 対応内容 |
|---|---|
| RSA鍵 | 2048、3072、4096ビット |
| AES鍵 | AES-256 |
| 対応操作 | wrapKey、unwrapKey |
| RSAアルゴリズム | RSA-OAEP、RSA-OAEP-256 |
| AESアルゴリズム | A256KW、A256KWP |
| 非対応 | sign、verify、通常のencrypt、decrypt |
| 非対応シナリオ | Secure Key Release、Confidential VMの起動時ディスク暗号化など |
| 自動ローテーション | 非対応。顧客側で調整して実施 |
| 外部キーのバックアップ／復元 | Managed HSM側では非対応 |
「Managed HSM対応サービス」だけでは判断できない
利用できるのは、Managed HSMをCMKとしてサポートし、データ暗号化キーの保護にwrapKeyとunwrapKeyを使用するAzureサービスです。
たとえばAzure Storageは対象例として示されています。一方、直接の署名処理や暗号化処理、Secure Key Releaseを必要とするサービスやシナリオでは使用できません。導入判断では、サービス名だけでなく、対象サービスが内部で必要とする暗号操作と対応アルゴリズムまで確認する必要があります。(Microsoft Learn)
導入前に確認すべきネットワーク条件
External Key Managementで特に注意すべきなのが、プレビュー時点の接続方式です。
Managed HSMからEKM Proxyへの接続は、公開インターネット上のパブリックFQDNを使用する方式のみがサポートされています。Private Linkや固定送信元IPアドレスによる接続制限を前提に設計することはできません。(Microsoft Learn)
EKM Proxyに必要な条件
- 公開DNSで名前解決できるFQDN
- インターネットから到達可能なTCP 443
- TLS 1.3
TLS_AES_256_GCM_SHA384またはTLS_AES_128_GCM_SHA256- Managed HSMとの相互TLS認証
- サーバー証明書のSANとプロキシFQDNの一致
- Managed HSMクライアント証明書のCNとルートCAの検証
Managed HSM側の送信元IPアドレスは固定されておらず、プレビュー時点ではEKM通信用のAzureサービス目印も提供されていません。そのため、EKM Proxy側ではTCP 443を広い送信元から受け付け、mTLSのクライアント証明書検証を実質的なアクセス制御として使用します。(Microsoft Learn)
これは一般的な「送信元IPを許可リストに登録する」設計とは大きく異なります。セキュリティ審査では、次の点を事前に説明できるようにしておく必要があります。
- インターネット公開されたプロキシをどの層で保護するか
- 不正なクライアント証明書を確実に拒否できるか
- TLS終端装置やロードバランサーがmTLSを正しく処理できるか
- DDoS対策がレイテンシー要件を損なわないか
- プロキシ自体に鍵素材やセッション情報を残さない設計か
250ミリ秒のレイテンシー上限を満たせるか
Managed HSMからEKM Proxyを経由した処理には、1要求当たり250ミリ秒以下というレイテンシー予算があります。プロキシが時間内に応答しなければ、Managed HSMはタイムアウトとしてエラーを返します。Microsoft側が外部HSMの遅延を吸収したり、専用の再試行処理で障害を隠したりする仕組みはありません。(Microsoft Learn)
設計時は平均値だけでなく、ピーク時のp95、p99を確認します。
- Managed HSMとEKM Proxy間のネットワーク遅延
- EKM Proxy内の処理時間
- Proxyから外部HSMまでの遅延
- 外部HSM内のキュー待ち時間
- TLS接続確立にかかる時間
- 障害時のロードバランサー切り替え時間
- HSMの最大同時処理数とスロットリング条件
Microsoftは、Managed HSMの利用リージョンに近い場所へリージョン別のプロキシを配置することを推奨しています。外部HSMを国内のオンプレミス施設に置く場合も、実際のネットワーク経路を使った負荷試験が必要です。(Microsoft Learn)
SLAと責任分界を誤解しない
Managed HSMサービス自体は、Microsoftが公開するManaged HSM SLAの対象です。
一方、外部キー、EKM Proxy、外部HSMにはManaged HSMのSLAが適用されません。Microsoftの責任範囲は、Managed HSMが顧客のEKM Proxyを呼び出す地点までです。(Microsoft Learn)
| 領域 | 主な責任者 |
|---|---|
| Managed HSMサービスの可用性 | Microsoft |
| Entra IDとManaged HSMローカルRBACの適用 | Microsoftが実施、設定責任は顧客 |
| 外部KEKの保管 | 顧客または指定事業者 |
| EKM Proxyの構築、更新、脆弱性対応 | 顧客またはHSMベンダー |
| 外部HSMの可用性と容量 | 顧客またはHSMベンダー |
| Proxy側のサーバー証明書 | 顧客またはHSMベンダー |
| Managed HSMクライアント証明書の信頼設定 | 顧客またはHSMベンダー |
| 外部HSMのバックアップと復旧 | 顧客 |
| Proxy・外部HSM側のログ | 顧客またはHSMベンダー |
| 障害の一次切り分け | 原因となった領域の運用者 |
EKM Proxyが停止すると、外部キーを使うwrapKeyとunwrapKeyが失敗します。外部HSMの障害や証明書期限切れも、Azureサービス側のデータアクセスへ直接影響する可能性があります。
「HSMを切断すれば暗号操作を止められる」という点は強い主権性を示しますが、同時に、自社の操作や障害でAzure上のワークロードを停止できてしまうことも意味します。
導入前チェックリスト
規制要件を文書化する
まず、次の文章を具体的に完成させます。
当組織は、〇〇法令または〇〇契約の第〇条により、〇〇データを保護する鍵暗号化キーをMicrosoftインフラストラクチャ外のHSMに保管する必要がある。
この文章を作れない場合、通常のManaged HSMで要件を満たせる可能性があります。
単に「クラウド事業者に鍵を預けたくない」という理由だけでは、Managed HSMの顧客固有セキュリティドメインやMicrosoftからの鍵アクセス不可という既存機能を評価し切れていない可能性があります。
Azureサービスごとの互換性を確認する
対象サービスごとに、少なくとも次の項目を確認します。
- Managed HSMをCMKとして指定できるか
- 必要な鍵種別と鍵長
- 使用するラップアルゴリズム
- バージョンなしキーURIを利用できるか
- キーローテーション時の反映方法
- キーにアクセスできない場合のサービス挙動
- キーのキャッシュ時間
- 既存CMKから新しいキーURIへ切り替える手順
- 切り戻しに必要な時間
可用性と災害対策を決める
外部HSMとEKM Proxyについて、次の設計が必要です。
- プロキシの冗長化
- 外部HSMクラスタの冗長化
- データセンター障害時の切り替え
- 地理的冗長性
- DNS障害への対応
- 証明書失効時の緊急更新
- HSMベンダーの24時間サポート
- 復旧目標時間と復旧目標時点
- Azure側とHSM側を含む定期的な障害訓練
1つのManaged HSMプールに同時に関連付けられるEKM Proxy接続は1つです。複数のプロキシインスタンスを使う場合は、単一FQDNの背後で冗長化する方法や、接続先を更新する手順まで含めて設計します。(Microsoft Learn)
費用をManaged HSM料金だけで判断しない
Microsoftによる外部キー管理の追加サーチャージはありませんが、実際には次の費用が発生します。
- 外部HSM本体またはCloud HSM
- HSMの保守契約
- EKM Proxy用のコンピューティング環境
- 冗長構成と災害対策環境
- TLS証明書
- ネットワークとDDoS対策
- ログ保存とSIEM
- HSMベンダーのEKMライセンス
- 24時間監視と障害対応要員
- 定期的な適合性監査
通常のManaged HSMと比較する際は、HSM製品価格ではなく、複数年の運用費用と停止リスクまで含めて判断します。(Microsoft Azure)
導入の基本手順
プレビュー利用の大まかな流れは次のとおりです。
- Microsoftアカウントチームへ利用申請する
- 対象サブスクリプションでExternal Key Managementを有効化してもらう
- Managed HSMを用意する
- 外部HSM内にKEKを作成する
- EKM Proxyを構築し、外部キー識別子を取得する
- Managed HSMのクライアント証明書情報をProxy側へ登録する
- EKM Proxy接続をManaged HSMに登録する
- 接続確認を行う
- 外部キー参照をManaged HSMに作成する
wrapKeyとunwrapKeyの往復テストを行う- 対象AzureサービスのCMK設定へキーURIを登録する
- 障害、ローテーション、復旧、切り戻しをテストする
Managed HSM側では、接続管理にManaged HSM EKM Administrator、キー参照の作成と利用にManaged HSM Crypto Userが必要です。(Microsoft Learn)
Azure CLIでの最小構成例
最初に、Azure CLIのkeyvault拡張機能を最新化します。
az extension add --name keyvault
az extension update --name keyvaultManaged HSMがEKM Proxyへの接続時に提示するクライアント証明書情報を取得します。
az keyvault ekm-connection certificate show \
--hsm-name <managed-hsm-name>返されたsubjectCommonNameとcaCertificatesを、EKM Proxy側の許可設定へ登録します。
続いて、ProxyのFQDNとサーバー証明書を発行したルートCAを登録します。
az keyvault ekm-connection create \
--hsm-name <managed-hsm-name> \
--host <proxy.example.com> \
--server-ca-certificate <root-ca.pem>接続を確認します。
az keyvault ekm-connection check \
--hsm-name <managed-hsm-name>外部HSMに作成済みの鍵を、Managed HSMのキー参照として登録します。
az keyvault key create \
--hsm-name <managed-hsm-name> \
--name <external-key-reference-name> \
--external-key-id <external-key-identifier>--server-ca-certificateには、Proxyのリーフ証明書ではなく、その証明書を発行したルートCA証明書を指定します。リーフ証明書を直接登録すると、証明書更新時にmTLS接続が失敗する原因になります。(Microsoft Learn)
動作確認ではencryptコマンドを使わない
外部キーが対応するのはwrapKeyとunwrapKeyです。
az keyvault key encryptは直接のencrypt操作を実行するため、外部キーのテストには使用できません。公式クイックスタートに従い、az restなどからwrapkeyとunwrapkeyのデータプレーンAPIを呼び出して往復確認します。(Microsoft Learn)
鍵のローテーションと削除で注意すること
外部キー識別子は、作成済みのキーバージョンでは変更できません。
鍵をローテーションする場合は、次の順序で新しいバージョンを作成します。
- 外部HSMで新しい鍵を生成する
- 新しい外部キー識別子を取得する
- Managed HSMで同じキー名の新しいバージョンを作成する
- 新しいバージョンでラップ処理が成功することを確認する
- 古いキーバージョンでアンラップが必要なデータが残っていないか確認する
- 必要な保持期間が過ぎた後に古い外部鍵を廃止する
バージョンを指定しないキーURIをAzureサービスに設定している場合、新しいラップ処理では最新バージョンが使用されます。一方、過去の鍵でラップされたデータをアンラップするには、古い外部鍵を引き続き使用できる状態にしておかなければなりません。(Microsoft Learn)
外部HSM側の鍵を先に削除してはいけない
Managed HSMのキー参照が残っている状態で外部HSM側の鍵素材を削除すると、そのバージョンを使用するwrapKeyとunwrapKeyは直ちに失敗します。
推奨される削除順序は次のとおりです。
- キーを使用しているAzureサービスを特定する
- 各サービスを別のキーへ切り替える
- 古いキーへの暗号操作が発生していないことをログで確認する
- Managed HSMのキー参照を削除する
- 必要に応じてキー参照を消去する
- 最後に外部HSM側の鍵素材を削除する
Managed HSMのキー参照を削除しても、外部HSMの鍵素材は削除されません。両者は別々に管理する必要があります。(Microsoft Learn)
バックアップ／復元を前提にしない
プレビュー時点では、Managed HSMによる外部キーのバックアップと復元はサポートされていません。外部キーをバックアップから復元しようとすると、Managed HSMリソースが機能低下状態になる可能性があると案内されています。
外部HSM内の鍵素材は、HSMベンダーの機能を使って顧客側でバックアップします。Managed HSM側のキー参照を失った場合は、復元操作に頼らず、外部キー参照を再作成する手順を準備しておく必要があります。(Microsoft Learn)
監視で確認すべきログとアラート
Managed HSM、EKM Proxy、外部HSMは、それぞれ別の運用主体がログを出力します。1つのログだけでは暗号操作全体を追跡できません。
Managed HSMでは、EKM Proxyへの呼び出しごとにEkmProxyOperation関連の監査ログが出力されます。Proxyと外部HSMのログはMicrosoftから参照できないため、顧客またはHSMベンダー側で収集・保存します。(Microsoft Learn)
失敗した操作を確認するKQL
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName contains "Ekm"
| where ResultType != "Success"
| where TimeGenerated > ago(24h)
| summarize Failures = count()
by ResultType, ResultDescription, bin(TimeGenerated, 1h)
| order by TimeGenerated descこのログだけでなく、外部キー識別子、要求時刻、Correlation IDなどをProxy側のログにも記録し、Azure側の記録と突合できるようにします。(Microsoft Learn)
推奨されるアラート基準
| 監視項目 | 目安となる条件 |
|---|---|
| 外部キー操作のエラー率 | 5分間で1％超 |
| Proxy認証エラー | 5分間で1件以上 |
| p95レイテンシー | 5分間で250ミリ秒超 |
| 証明書期限 | 期限の30日前 |
| 操作が途絶えた状態 | 通常利用時間に15分以上ログがない |
| タイムアウト | 1分以内に504系エラーが3回以上 |
これらはMicrosoftの監視ガイドで示されている初期基準です。実際の本番環境では、250ミリ秒に達してから対応するのではなく、より低い警告値を設定して余裕を確保する方が安全です。(Microsoft Learn)
よくある失敗と回避方法
| 失敗 | 起こり得る問題 | 回避方法 |
|---|---|---|
| 通常のセキュリティ強化策として導入する | 運用負荷と障害点だけが増える | 法令・契約上の必須要件を先に確認する |
| Managed HSM対応ならすべて使えると思う | 非対応の暗号操作で設定に失敗する | wrapKeyとunwrapKeyだけで成立するか確認する |
| 送信元IPアドレスでProxyを制限する | Managed HSMから接続できない | mTLSのCNとルートCAで認証する |
| Proxyを外部HSMから遠い場所に置く | 250ミリ秒を超えてタイムアウトする | リージョン別にProxyを配置し負荷試験する |
| Managed HSM SLAが外部HSMまで適用されると思う | 障害時の責任分界が曖昧になる | Proxy、HSM、通信経路のSLOを別に定義する |
| 古い外部鍵をローテーション直後に削除する | 過去データをアンラップできなくなる | 旧バージョンの利用終了をログで確認する |
| Managed HSMのバックアップで復旧できると思う | 復旧手順が成立しない | 外部HSMとキー参照の復旧手順を別々に用意する |
encrypt操作で接続確認する | 非対応操作のためテストが失敗する | wrapKeyとunwrapKeyで往復試験する |
| 導入だけを検討し撤退方法を決めない | GA条件変更や障害時に切り戻せない | 通常のManaged HSMキーへの移行手順も事前検証する |
対応要否の判断と次に行うこと
External Key Managementを検討すべきなのは、次の条件をすべて満たす組織です。
- 鍵素材をMicrosoftインフラストラクチャ外に置く明確な法令または契約要件がある
- 対象AzureサービスがManaged HSMと必要なラップ操作に対応している
- Microsoftのプレビュー参加条件を満たしている
- EKM Proxyと外部HSMを高可用性で運用できる
- 250ミリ秒以内の応答を実環境で維持できる
- SLA対象外となる範囲を業務側が受け入れている
- 鍵ローテーション、バックアップ、復旧、削除、撤退手順を自社で管理できる
該当する場合は、最初にMicrosoftアカウントチームへサブスクリプションの有効化条件を確認します。その後、HSMベンダーを選定し、保存データの暗号化だけを対象とした小規模な検証環境で、正常系だけでなくProxy停止、HSM停止、証明書不一致、250ミリ秒超過、鍵ローテーション、旧鍵削除前確認まで試験します。
一方、鍵をMicrosoftインフラストラクチャ外に置く明確な義務がない場合は、通常のAzure Key Vault Managed HSMを継続する方が適切です。外部キー管理の採用そのものをセキュリティ目標にせず、要件を満たす中で最も単純で可用性の高い構成を選ぶことが重要です。(Microsoft Azure)
コメント