「Azureに移行したはいいが、パスワードや証明書をどこに置けばいいのか」——オンプレ時代は構成管理ツールや暗号化した設定ファイルでしのいでいた方、あるいはAWSでKMSやSecrets Managerを使ってきた方が、Azureに触れて最初につまずくのがシークレット管理の置き場所です。接続文字列をapp settingsに平文で書くわけにもいかず、かといって独自に金庫サーバーを立てるのもクラウドらしくない。
この記事では、Azure Key Vaultについて、オンプレ経験者およびAWS経験者にもわかりやすく解説します。保管できる3種類のデータ（シークレット・キー・証明書）、アクセス制御の考え方、AWS KMS／Secrets Managerとの違い、料金の仕組み、そしてAzure CLIでの具体的な操作手順までカバーします。
なぜAzure Key Vaultなのか？オンプレのシークレット管理との違い
オンプレ時代、パスワードや秘密鍵の管理は各組織ごとにバラバラでした。設定ファイルに平文で書く、Ansible Vaultで暗号化する、独自の金庫サーバーを立てる、最悪の場合は運用手順書にそのまま記載するなど、「決まった置き場所がない」のが実情でした。監査の度に棚卸しに追われた経験のある方も多いはずです。
Azure Key Vaultは、シークレット・暗号鍵・TLS証明書の3種類をクラウド側のマネージドな金庫に一元集約するサービスです。アプリケーションは認証情報を直接持たず、実行時にKey Vaultへ問い合わせて取得します。Key Vaultはアクセスログを自動記録するため、「誰がいつ何を参照したか」が後から追跡できます。
AWS経験者向けに言えば、Azure Key VaultはAWS KMS（暗号鍵管理）とAWS Secrets Manager（シークレット管理）とAWS Certificate Manager（証明書管理）の3つを1つに統合したような存在です。AWSは機能ごとにサービスを分けていますが、Azureは一つのVaultリソースで3種類をまとめて扱います。
Azure Key Vaultで保管できる3種類のデータ
Key Vaultに格納できるのは以下の3種類です。それぞれ用途とAPIが異なるため、最初に整理しておくと後が楽になります。
1. Secrets（シークレット）
データベース接続文字列、APIキー、OAuthクライアントシークレット、パスワードなど、任意の文字列を暗号化して保管する用途です。値はKey Vault内部で自動的に暗号化され、許可されたIDだけが平文で取得できます。
・最大サイズ: 1シークレットあたり25KBまで
・バージョン管理: 同じ名前で値を更新すると自動的に履歴が残る
・有効期限: 任意で設定可能、期限切れはアラートで検知できる
2. Keys（暗号鍵）
RSA 2048/3072/4096、EC P-256/P-384/P-521などの非対称鍵、およびAES-256対称鍵を保管します。鍵そのものをKey Vaultから取り出さずに、暗号化・復号・署名・検証の操作をKey Vault側で実行できる点が特徴です。つまり、アプリケーションは「秘密鍵を持たずに暗号処理だけ依頼する」運用が可能になります。
オンプレで言えば、HSM（ハードウェアセキュリティモジュール）の役割をマネージドで肩代わりしてくれるイメージです。実際、上位プラン（Premium）ではFIPS 140-2 Level 2認定のHSMバックエンドが利用できます。
3. Certificates（証明書）
TLS/SSL証明書を秘密鍵とセットで保管します。Key Vault上でCSR生成・発行申請・自動更新・失効までを一元管理でき、App ServiceやApplication Gatewayといった上位サービスから参照するだけでHTTPS化が完了します。
DigiCertやGlobalSignなど主要な認証局と連携でき、期限切れの前に自動更新させれば証明書管理の手運用は大幅に減ります。AWSで言えばACMに近い位置付けです。
基本的な使い方（Azure CLI操作）
ここではAzure CLIを使った一連の操作手順を示します。Azure PortalからGUI操作も可能ですが、現場では再現性のあるCLI/IaCが主流です。
1. Key Vaultの作成
まずリソースグループとKey Vaultを作成します。Vault名はAzure全体でグローバルにユニークである必要があります。
# リソースグループ作成（東京リージョン） az group create --name rg-kv-demo --location japaneast # Key Vault作成（Standardプラン） az keyvault create \ --name kv-myapp-prod-001 \ --resource-group rg-kv-demo \ --location japaneast \ --sku standard \ --enable-rbac-authorization true
--enable-rbac-authorization true を付けることで、アクセス制御をAzure RBACで統一します。旧方式の「アクセスポリシー」より推奨される方式です。
2. シークレットの登録と取得
データベース接続文字列をシークレットとして登録する例です。
# シークレット登録 az keyvault secret set \ --vault-name kv-myapp-prod-001 \ --name db-connection-string \ --value "Server=tcp:mydb.database.windows.net,1433;..." # シークレット取得（値を表示） az keyvault secret show \ --vault-name kv-myapp-prod-001 \ --name db-connection-string \ --query value -o tsv
3. RBACによるアクセス権付与
誰がこのVaultを読み書きできるかを制御します。たとえば、App Serviceのマネージドフィーチャから読み取り専用でアクセスさせるケースです。
# Key Vault Secrets Userロールを特定のプリンシパルに付与 az role assignment create \ --role "Key Vault Secrets User" \ --assignee <オブジェクトID or アプリID> \ --scope /subscriptions/<sub-id>/resourceGroups/rg-kv-demo/providers/Microsoft.KeyVault/vaults/kv-myapp-prod-001
主要な組み込みロールは以下の通りです。最小権限の原則に従い、必要な範囲だけを割り当てます。
・Key Vault Administrator: すべてのシークレット・キー・証明書を管理
・Key Vault Secrets Officer: シークレットの読み書き（キー・証明書は不可）
・Key Vault Secrets User: シークレットの読み取りのみ
・Key Vault Crypto Officer: キーの管理（作成・削除・復元など）
・Key Vault Crypto User: キーを使った暗号化・復号・署名のみ
・Key Vault Certificates Officer: 証明書の管理
AWS KMS・Secrets Managerとの違い（比較表）
AWS経験者が最初につまずくのが、サービスの粒度の違いです。主要な違いを整理します。
| 項目 | Azure Key Vault | AWS（KMS/Secrets Manager/ACM） |
|---|---|---|
| シークレット保管 | Key Vault Secrets | AWS Secrets Manager（Systems Manager Parameter Storeも代替可） |
| 暗号鍵管理 | Key Vault Keys | AWS KMS |
| 証明書管理 | Key Vault Certificates | AWS Certificate Manager（ACM） |
| アクセス制御 | Azure RBAC（推奨）/ アクセスポリシー（旧） | IAMポリシー + KMSキーポリシー + Secrets Managerリソースポリシー |
| 認証情報を持たない連携 | マネージドID | IAMロール（EC2/Lambdaのインスタンスプロファイル等） |
| HSMバックエンド | Premiumプランで選択可（FIPS 140-2 Level 2） | AWS CloudHSM（独立サービス、FIPS 140-2 Level 3） |
| 自動ローテーション | キーは自動ローテーション可、シークレットはEvent Grid + Functionsで実装 | Secrets Managerに組み込み機能あり |
最大の特徴は、Azureではシークレット・キー・証明書を1つのVaultリソースに統合している点です。一方AWSは機能ごとに分離しており、それぞれ料金体系も別です。「どっちが優れているか」ではなく「運用モデルの違い」として捉えるのが実態に即しています。
料金の仕組み（コスト感覚）
Key Vaultの課金は大きく「プラン料金」と「操作回数料金」に分かれます。以下は東京リージョン・2026年4月時点の目安です。
・Standardプラン: ソフトウェアで保護される鍵と全シークレット・証明書に対応、1万回の操作あたり約$0.03
・Premiumプラン: HSMで保護される鍵に対応、HSM保護鍵は鍵1本あたり月額約$1（5千鍵まで）、それ以降は逓減
・証明書の更新操作: 1回あたり約$3（認証局への申請操作のみ課金、自動更新含む）
・マネージドHSMプール: 専用HSMプール構成は別料金体系（時間課金、月額数千ドル規模）
通常のWebアプリ・APIバックエンド用途であれば、月額数ドル〜数十ドルに収まるケースが大半です。操作回数が多くなりやすいのは、起動時に毎回Key Vaultから取得するアーキテクチャの場合なので、アプリ側でキャッシュさせる設計が効きます。
応用・実務Tips
本番運用で役に立つポイントをいくつか押さえておきます。
1. マネージドIDで認証情報ゼロを実現する
App Service、Azure Functions、Virtual MachinesなどにはマネージドID（Managed Identity）を割り当てられます。これを使えばアプリ側にクライアントシークレットを持たせる必要がなくなり、Key Vaultへのアクセスがシームレスに完結します。
AWSで言うEC2インスタンスプロファイルのIAMロールと同じ発想です。「認証情報を置かないために認証情報管理を使う」という循環参照を断ち切るのが、クラウドネイティブなシークレット管理の本質です。
2. ソフトデリートとパージ保護は必ず有効化する
誤って削除したシークレットや鍵を復元するための機能がソフトデリートです。さらにパージ保護を有効にすると、保持期間（既定90日）が経過するまで物理削除できなくなります。本番環境では両方とも有効が基本です。
# パージ保護を有効化（一度有効にすると無効化不可） az keyvault update \ --name kv-myapp-prod-001 \ --resource-group rg-kv-demo \ --enable-purge-protection true
3. Private Endpointで社内接続を閉じる
既定ではKey Vaultはパブリックエンドポイント経由で到達できます。社内からのみアクセスさせたい場合は、Private Endpointとネットワークアクセス制限を組み合わせて、公衆インターネットから切り離すのが定石です。監査要件が厳しい金融・公共分野では事実上必須になります。
4. Key Vaultのアクセスログは必ずMonitorへ送る
診断設定でLog Analytics WorkspaceまたはStorageアカウントへログを送っておくと、「誰がいつどのシークレットを参照したか」がすべて追跡できます。漏洩時のインシデント対応の第一歩になるので、初期構築時に必ず設定しておきます。
よくあるトラブルと対処法
現場でよく踏む落とし穴をまとめます。
・「403 Forbidden」エラー: RBACモードなのに旧アクセスポリシーだけ設定しているケースが多い。--enable-rbac-authorization の値と、割り当てたロールが整合しているかを確認する
・シークレット名に使える文字は限定的: 英数字とハイフンのみ。アンダースコアやドットは使えないので、既存の設定キー名をそのまま流用できない場合がある
・操作レート上限にヒット: 既定で1秒あたり2,000リクエストまで。高頻度アクセスする場合はアプリ側のキャッシュ（数分単位）が必須
・ソフトデリート状態のVault名は再利用できない: 完全削除するまで同名で再作成できないので、テスト環境の使い回しでハマりやすい
・証明書の自動更新が動かない: Key Vaultから認証局へアクセスするためのContactsと発行者（Issuer）設定が揃っているか確認する
本記事のまとめ
Azure Key Vaultは、シークレット・暗号鍵・TLS証明書というクラウド運用で必ず発生する3種類の機密データを、1つのマネージド金庫に集約できるサービスです。AWSでは3つに分かれているサービスが統合されており、運用モデルは異なりますが、「認証情報を置かずに、一元管理された場所から都度取得する」という発想は共通です。
現場で最初に押さえるべきは以下の4点です。
・RBACモードで作成し、最小権限ロールで運用する
・アプリ側はマネージドIDでアクセスし、認証情報を持たない
・ソフトデリート＋パージ保護を本番では必ず有効化する
・診断ログをMonitorへ送り、アクセス履歴を可視化する
なお、クラウド上のLinuxサーバー運用やシェルからのCLI操作については、姉妹サイトLinuxMaster.JPでも解説しています。また、IAM・暗号化・コンプライアンスといったクラウドセキュリティの土台を体系的に学びたい方は、SecurityMaster.JPも合わせて参照してください。
クラウドのシークレット管理、現場でちゃんと使える形にしたい方へ
Azure Key VaultもAWS KMSも、単発で機能を覚えるだけでは本番運用で迷子になります。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ、メルマガで実践的なクラウド活用ノウハウをお届けしています。
コメント