クラウドサービス

Azure Key Vault

鍵やパスワードをコードに埋めず安全に管理。Azure Key Vault が暗号鍵・シークレット・証明書を集中管理し、HSM 保護・RBAC 制御・自動ローテーション・監査ログを提供。

中級セキュリティ運用上の優秀性信頼性
最終更新: 2026-06-13公式ドキュメント
3つの要点
TL;DR
  1. 暗号鍵・シークレット・証明書を保管する金庫サービス。
  2. HSM で鍵を保護し、誰がいつ使ったかまで監査。
  3. KMS + Secrets Manager + ACM を1つに集約した相当。

解決する課題

  • 接続文字列・API キー・パスワードをコードや構成ファイルにハードコードしたくない
  • 暗号鍵を安全に生成・保管し、ローテーションや監査を統制したい
  • TLS 証明書の発行・更新・配布を自動化したい
  • 鍵やシークレットへのアクセスを最小権限で制御し、利用を監査したい

主要概念と用語

Key Vault が扱うオブジェクトは大きく3種類です。

  • キー(Keys): RSA / EC の非対称鍵や AES の対称鍵。署名・暗号化・ラップ(鍵の暗号化)に使う。鍵そのものは Vault の外に出さず、暗号操作を Key Vault に依頼する(外部に出ないことが前提)
  • シークレット(Secrets): パスワード・接続文字列・API キーなど任意の文字列値。最大 25KB
  • 証明書(Certificates): X.509 証明書。内部で「鍵+シークレット(証明書本体)」のペアとして管理され、CA(DigiCert / GlobalSign など)連携で自動更新できる
  • コンテナの2種類: Vault(ソフトウェア保護 or HSM 保護を選択)と、専用ハードウェアを占有する Managed HSM
  • 保護レベル(SKU): standard(ソフトウェア保護)と premium(HSM 保護)。新しい HSM 保護鍵は FIPS 140-3 Level 3 の HSM Platform 2 で作成され、既存の古い鍵バージョンは HSM Platform 1 の場合がある
  • アクセス制御の2方式: Azure RBAC(推奨)と、従来の アクセスポリシー。API バージョン 2026-02-01 以降で作る新規 Vault は Azure RBAC が既定
  • 論理的な削除(Soft Delete)/ 消去保護(Purge Protection): 誤削除・悪意ある削除から鍵を守る安全装置

仕様・制限・クォータ

  • Vault はリージョン内で冗長化され、内容はセカンダリリージョンへ自動レプリケートされる。サービス側がフェイルオーバーを処理する
  • トランザクション上限(スロットリング)があり、サブスクリプション×Vault 単位で 1 秒あたりの操作数に上限がある。429 Too Many Requests が返るためリトライ(指数バックオフ)が前提
  • シークレット値は最大 25KB、証明書・鍵にもサイズ上限がある
  • Soft Delete は既定で有効(無効化不可)。削除後も保持期間(7〜90 日、既定 90 日)内は復元できる
  • Managed HSM は単一テナント専用プールで、鍵数・パーティションのスケールが Vault と異なる(FIPS 140-3 Level 3 検証済み)
  • 各 Azure サービス(Storage / SQL / Disk など)のカスタマー管理キー(CMK)の保管先として参照される
Vault と Managed HSM の違い

Vault(premium) は共有基盤上の HSM で鍵を保護します。新しい鍵バージョンは FIPS 140-3 Level 3 の HSM Platform 2、古い鍵バージョンは HSM Platform 1 の場合があります。Managed HSM単一テナント専用の HSM プールで、セキュリティドメインやクォーラムを自組織で管理します。多くの用途は Vault で十分です。

内部の仕組み

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

  • premium SKU や Managed HSM では、鍵はHSM の境界内で生成・保持され、平文で外部に出ない
  • すべてのアクセスは Microsoft Entra ID で認証され、RBAC / アクセスポリシーで認可される
  • 鍵・シークレットの利用ログは Azure Monitor(診断設定)経由で Log Analytics / Storage / Event Hubs に送れる
  • アプリ側はマネージド ID で認証すれば、Vault にアクセスするための資格情報自体が不要になる

横にスクロール

アプリがMicrosoft Entra ID、Private Endpoint、Azure RBACを通ってAzure Key Vaultのキー、シークレット、証明書へアクセスする判定経路と、データ暗号化キーをキー暗号化キーでラップするエンベロープ暗号化の流れ
Key Vaultのデータ操作は、認証、ネットワーク到達性、データプレーン権限の順に切り分けます。大きなデータはDEKで暗号化し、そのDEKだけをKey VaultのKEKでラップするため、鍵素材を外へ出さずに処理できます。
Key Vault と Managed HSM、どちらを選ぶ?

統制・コンプライアンス要件が厳しく、鍵の所有権(Bring Your Own Key / セキュリティドメイン)を自分で握りたいなら Managed HSM。一般的なシークレット保管・CMK・証明書管理は Key Vault(standard/premium)で十分です。

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

  • アプリにはマネージド ID を付与し、Key Vault 参照で接続文字列等を取得(資格情報のハードコードを排除)
  • App Service / Functions の「Key Vault 参照」 を使い、アプリ設定に @Microsoft.KeyVault(...) 構文で直接シークレットを注入
  • 環境ごと(dev/stg/prod)に Vault を分離し、ネットワーク・RBAC の爆発半径を小さくする
  • アクセス制御は RBAC を採用(アクセスポリシーより細粒度・条件付きアクセス連携が可能)
  • Purge Protection を本番で有効化し、CMK を使う Storage/Disk の鍵を不可逆な削除から守る
  • 証明書は CA 連携で自動更新し、有効期限切れの事故を防ぐ

運用・監視・トラブルシュート

  • 診断設定(AuditEvent)を有効化し、すべてのアクセスを Log Analytics で監査
  • 証明書の有効期限・鍵のローテーション期限をアラート(Azure Monitor / Event Grid 通知)で監視
  • 403 Forbidden 時は RBAC ロール割り当て / アクセスポリシー / ファイアウォール(ネットワーク) の3点を確認
  • 429(スロットリング)時は指数バックオフでリトライし、頻繁に取得する値はアプリ側でキャッシュ
  • Private Endpoint でパブリックアクセスを遮断し、VNet 内からのみ到達可能にする

コスト

操作(トランザクション)課金が基本で、HSM 保護鍵や Managed HSM は固定費の比重が上がります。

プラン / 項目課金の考え方向いている用途
Standard Vault操作(取得/暗号操作)ごとの従量課金シークレット・ソフトウェア鍵・証明書の一般用途
Premium Vault(HSM鍵)操作課金+HSM保護鍵ごとの月額HSM保護とFIPS 140-3 Level 3が要る鍵
証明書(CA連携)更新(renewal)操作ごとに課金TLS 証明書の自動発行・更新
Managed HSMプール(HSMインスタンス)の時間課金(固定費)規制要件・占有HSM・セキュリティドメイン管理

セキュリティ

  • マネージド ID + RBAC でアクセスを最小化し、資格情報をコードから排除
  • ネットワーク制限(ファイアウォール許可 IP / Private Endpoint)でパブリック到達面を縮小
  • Soft Delete + Purge Protection で誤削除・悪意ある削除から鍵を保護
  • 診断ログで全アクセスを監査し、異常をアラート
  • 厳格な規制要件や単一テナント専用HSMが必要なら Managed HSM(FIPS 140-3 Level 3)
アンチパターン

接続文字列や API キーを appsettings.json・環境変数・ソースコードに直書きするのは NG。リポジトリ流出・ログ漏えいの温床になります。Key Vault に格納し、マネージド ID(または Key Vault 参照)で取得してください。さらに、アクセスポリシーで全員に全権限を付与する「広すぎる権限」も避け、RBAC で用途別ロール(例: Secrets User)に絞ること。

関連サービス・比較(AWS との対応)

Key Vault は AWS の複数サービスにまたがる役割を1つに統合しています。

観点AzureAWS
暗号鍵の管理Key Vault(Keys)KMS
占有HSMManaged HSMCloudHSM
シークレット保管Key Vault(Secrets)Secrets Manager / Parameter Store
TLS証明書Key Vault(Certificates)ACM
アクセス制御RBAC(Entra ID)/ アクセスポリシーキーポリシー / IAM / グラント
誤削除保護Soft Delete + Purge Protection削除待機期間(7〜30日)
アプリ認証マネージド IDIAM ロール
AWS との対応のキモ

AWS では KMS(鍵)/ Secrets Manager(シークレット)/ ACM(証明書)/ CloudHSM(占有HSM) に分かれている機能を、Azure では Key Vault と Managed HSM の2つでカバーします。

ハンズオン / CLI例

# リソースグループと Key Vault を作成(RBAC 認可・Purge Protection 有効)
az group create --name demo-rg --location japaneast

az keyvault create \
  --name demo-kv-0603 \
  --resource-group demo-rg \
  --location japaneast \
  --sku standard \
  --enable-rbac-authorization true \
  --enable-purge-protection true

# 自分(実行ユーザー)にシークレット操作のロールを付与
az role assignment create \
  --role "Key Vault Secrets Officer" \
  --assignee "$(az ad signed-in-user show --query id -o tsv)" \
  --scope "$(az keyvault show --name demo-kv-0603 --query id -o tsv)"

# シークレットを登録・取得
az keyvault secret set --vault-name demo-kv-0603 --name DbPassword --value "S3cr3t!"
az keyvault secret show --vault-name demo-kv-0603 --name DbPassword --query value -o tsv

# RSA 鍵を HSM 保護で作成(premium SKU 時)し、自動ローテーションポリシーを設定
az keyvault key create --vault-name demo-kv-0603 --name app-kek --kty RSA-HSM --size 2048

az keyvault key rotation-policy update \
  --vault-name demo-kv-0603 --name app-kek \
  --value '{"lifetimeActions":[{"trigger":{"timeBeforeExpiry":"P30D"},"action":{"type":"Rotate"}}],"attributes":{"expiryTime":"P1Y"}}'

Azure Service

Azure Key Vaultを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

セキュリティ・ID

比較で見る軸

クラウド: Azure / カテゴリ: セキュリティ・ID / 難易度: intermediate

導入後に効く点

HSM で鍵を保護し、誰がいつ使ったかまで監査。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
セキュリティ・ID
難易度
intermediate
関連資格
設計柱
security / operational / reliability

判断チェックリスト

  • 自社の用途が「セキュリティ・ID / security」に近いか確認する。
  • 強みである「暗号鍵・シークレット・証明書を保管する金庫サービス。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

セキュリティ・IDsecurityoperationalreliability

他クラウドの同等サービス

役割が近いサービスです。設計の置き換えや比較検討の参考に。