Azure Key Vault Managed HSM

解決する課題

• 共有基盤ではなく単一テナント専用のハードウェアで暗号鍵を保護したい（マルチテナント分離では不十分な規制要件）
• 鍵マテリアルの主権を自組織が完全に握りたい（Microsoft でも鍵を取り出せない設計）
• FIPS 140-3 Level 3 など厳格な検証レベルが監査・コンプライアンスで求められる
• 大量の HSM 保護鍵を高いスループットで集中管理したい（Storage / SQL / Disk のカスタマー管理キーの保管先）

主要概念と用語

• Managed HSM プール: 専用 HSM パーティションの論理コンテナ。共有基盤ではなく、契約した組織が占有する単一テナント構成
• セキュリティドメイン（Security Domain）: HSM プールを暗号学的に縛るデータの塊。鍵やロール割り当てなどプール全体の状態を暗号化して保護し、災害復旧や別 HSM への移行の起点になる。生成時に取得し、安全に保管する必要がある
• クォーラム（M of N）: セキュリティドメインを複数の RSA 鍵で分割保護する仕組み。例として 3 個の鍵のうち 2 個が揃わないとセキュリティドメインを復号できない、といった閾値を設定する
• ローカル RBAC（マネージドHSMロール）: プール内で完結する独自のロールベース認可。Azure 全体の RBAC とは別に、HSM 管理者・暗号担当者などのロールをデータプレーンで割り当てる
• 保護レベル（hsm-platform）: 鍵は HSM の境界内で生成・保持され、平文で外部に出ない。FIPS 140-3 Level 3 検証済みのハードウェアで動作する
• BYOK（Bring Your Own Key）: オンプレミスの HSM で生成した鍵を暗号化したまま取り込み、自組織起源の鍵として運用する
• 論理的な削除（Soft Delete）/ 消去保護（Purge Protection）: 誤削除・悪意ある削除からプールと鍵を守る安全装置

仕様・制限・クォータ

• プールは複数の HSM パーティションで構成され、可用性のために冗長化される。鍵はパーティション間でレプリケートされる
• 暗号操作のスループットは Vault（premium）より高い水準を狙える設計で、1 秒あたりの操作数に上限（スロットリング）がある。超過時は 429 Too Many Requests が返るためリトライ（指数バックオフ）が前提
• 格納できる鍵の数や種類（RSA / EC / AES など）に上限があり、用途に応じて選ぶ
• Soft Delete は既定で有効で、削除後も保持期間内は復元できる。Purge Protection を有効化すると保持期間中の完全削除を禁止できる
• 各 Azure サービス（Storage / SQL / Disk など）の**カスタマー管理キー（CMK）**の保管先として参照できる

内部の仕組み

Managed HSM の鍵は、鍵マテリアル自体が HSM の境界外に出ないことが前提です。アプリは「この鍵で暗号化・署名して」という暗号操作をプールに依頼し、結果だけを受け取ります。大きなデータには各サービスがエンベロープ暗号化を使い、実データは高速なデータ暗号化キー（DEK）で暗号化し、その DEK を Managed HSM 上のキー暗号化キー（KEK）でラップして保管します。

• プールの作成後、**セキュリティドメインを生成・ダウンロードして初めて有効化（アクティベート）**される。この手順を経るまでプールは使えない
• すべてのアクセスは Microsoft Entra ID で認証され、**ローカル RBAC（マネージドHSMロール）**で認可される
• 鍵・操作の**ログは Azure Monitor（診断設定）**経由で Log Analytics / Storage / Event Hubs に送れる
• アプリ側はマネージド ID で認証すれば、プールにアクセスするための資格情報自体が不要になる

設計パターン / ベストプラクティス

• セキュリティドメインのファイルとクォーラム鍵を分散保管し、復旧手順を文書化・訓練する
• ローカル RBAC で職務を分離（管理者・暗号担当者・読み取りなど）し、最小権限を徹底する
• アプリにはマネージド ID を付与し、資格情報のハードコードを排除する
• Purge Protection を本番で有効化し、CMK を使うサービスの鍵を不可逆な削除から守る
• 鍵のローテーションポリシーを設定し、有効期限切れ前に自動更新する
• BYOK で持ち込んだ鍵も含め、用途・環境ごとにプールやキーを整理する

運用・監視

• 診断設定を有効化し、すべてのアクセスと暗号操作を Log Analytics で監査する
• 鍵のローテーション期限・有効期限をアラート（Azure Monitor）で監視する
• 403 Forbidden 時は ローカル RBAC ロール割り当て / ネットワーク（ファイアウォール・Private Endpoint） を確認する
• 429（スロットリング）時は指数バックオフでリトライし、頻繁に使う鍵操作の負荷を平準化する
• Private Endpoint でパブリックアクセスを遮断し、VNet 内からのみ到達可能にする

コスト

固定費の比重が大きいのが特徴です。プールを確保している時間に対して課金され、Vault の従量課金とは性質が異なります。

セキュリティ

• 単一テナント専用 HSM と FIPS 140-3 Level 3 検証で、共有基盤では満たせない要件に対応する
• セキュリティドメイン + クォーラムで鍵の主権を自組織が握り、Microsoft でも鍵を取り出せない
• ローカル RBAC で職務を分離し、アクセスを最小化する
• ネットワーク制限（ファイアウォール許可・Private Endpoint）でパブリック到達面を縮小する
• Soft Delete + Purge Protection で誤削除・悪意ある削除から守る
• 診断ログで全アクセスを監査し、異常をアラートする

関連サービス・比較

最も近いのは AWS CloudHSM です。占有 HSM という位置づけが共通します。

ハンズオン / CLI例

# Managed HSM プールを作成（管理者に自分を指定）
az keyvault create \
  --hsm-name demo-mhsm-0628 \
  --resource-group demo-rg \
  --location japaneast \
  --administrators "$(az ad signed-in-user show --query id -o tsv)" \
  --retention-days 90

# セキュリティドメインを生成してダウンロード（3個中2個のクォーラム）
# ※ cert1.cer〜cert3.cer は事前に用意した RSA 公開鍵証明書
az keyvault security-domain download \
  --hsm-name demo-mhsm-0628 \
  --sd-wrapping-keys cert1.cer cert2.cer cert3.cer \
  --sd-quorum 2 \
  --security-domain-file demo-sd.json

# ローカル RBAC で暗号担当者ロールを付与
az keyvault role assignment create \
  --hsm-name demo-mhsm-0628 \
  --role "Managed HSM Crypto User" \
  --assignee "$(az ad signed-in-user show --query id -o tsv)" \
  --scope /keys

# RSA 鍵を HSM 保護で作成
az keyvault key create \
  --hsm-name demo-mhsm-0628 \
  --name app-kek \
  --kty RSA-HSM \
  --size 2048