Azure Key Vaultを安全に運用したい場合、まず確認すべき答えはシンプルです。「Key Vaultを作っただけで安全」と考えず、ネットワーク、ID、RBAC、削除保護、ローテーション、監査ログ、バックアップ権限まで一体で点検する必要があります。Microsoft Azureの公式ドキュメント「Secure your Azure Key Vault」は、Azure Key Vaultでキー、証明書、シークレットを保護するためのベストプラクティスを整理したページで、ゼロトラストの「明示的に検証する」「最小特権を使う」「侵害を前提にする」という考え方に沿っています。(Microsoft Learn)
2026年5月時点で特に重要なのは、Private Endpointを使ってもパブリックDNSの名前解決は残ること、バックアップから復元したキーは元のキーから独立すること、そして新規Key VaultではAzure RBAC前提の運用がより重要になることです。既存環境の管理者は、設定を一括で棚卸しし、開発者はアプリケーションの認証方式やキー参照方法を見直すのが現実的な対応です。(GitHub)
Secure your Azure Key Vaultは何を目的とした公式情報か
「Secure your Azure Key Vault」は、Azure Key Vaultの単一機能を紹介するページではなく、Key Vault全体を安全に設計・運用するためのセキュリティ指針です。対象は、暗号化キー、証明書、秘密情報をKey Vaultで管理している管理者、クラウドアーキテクト、DevOps担当者、アプリケーション開発者です。Microsoft Learn上の対象ページは、確認時点で「Last updated on 2026-05-04」と表示されています。(Microsoft Learn)
この情報を読む際のポイントは、「新しい単一の設定が追加された」と捉えるのではなく、Key Vaultの攻撃面を減らすための運用基準がより明確になったと理解することです。具体的には、アプリケーション・リージョン・環境ごとにKey Vaultを分ける、マルチテナントSaaSではテナント単位で分離する、Key Vaultを一般的なデータストアとして使わない、証明書をシークレットとして保存しない、といった設計面の注意も含まれます。(Microsoft Learn)
2026年5月時点で特に押さえるべき変更点
Private Endpoint専用でもパブリックDNSの名前解決は残る
今回の実務上の大きなポイントは、パブリックネットワークアクセスを無効化してPrivate EndpointだけでKey Vaultに接続していても、Key VaultのFQDNはパブリックDNSで名前解決されるという明確化です。これは設計上の動作であり、パブリックDNSで解決できること自体は、Private Endpointの設定ミスやデータプレーンの公開を意味しません。(GitHub)
セキュリティ診断でnslookupやdigの結果だけを見て「Key Vaultが外部公開されている」と判断するケースがあります。しかし、重要なのはDNS解決ではなく、パブリック経由のデータプレーン要求が拒否されるか、アプリケーションがPrivate Endpoint経由で到達できるかです。公式更新でも、パブリックDNS解決はPrivate Endpointの存在、プライベートIP、ネットワークルール、データ内容を公開するものではないと説明されています。(GitHub)
ただし、Key Vault名そのものが推測されやすい場合は別のリスクがあります。たとえばcustomer-a-prod-kvのように、顧客名、環境名、用途がそのまま分かる命名は避けた方が安全です。DNS抑止をセキュリティ対策と考えるのではなく、推測されにくい命名、Private Endpoint、RBAC、ログ監視を組み合わせるのが現実的です。(GitHub)
バックアップから復元したキーは元のKey Vaultから独立する
もう一つの重要な追記は、Key Vaultのバックアップと復元に関するインシデント対応です。公式ドキュメントでは、バックアップから別のKey Vaultへ復元されたキーは元のキーから完全に独立し、元のキーを無効化・削除・完全削除しても、復元済みのコピーには影響しないと説明されています。(Microsoft Learn)
これは、キー侵害時の対応を誤りやすいポイントです。たとえば、攻撃者がバックアップ権限を悪用してキーを別のKey Vaultに復元した疑いがある場合、元のキーを即座に無効化しても復元済みコピーは止まりません。一方で、元のキーを急に無効化すると、Azure SQL TDE、Azure Storageのカスタマー管理キー、Azure Disk Encryptionなど、依存しているサービスが停止する可能性があります。(GitHub)
そのため、対応順序は「古いキーを止める」ではなく、バックアップ・復元権限を持つプリンシパルの確認と取り消し、監査ログ調査、別Key Vaultでの置換キー作成、依存サービスの移行、動作確認後の旧キー無効化が基本です。公式更新でも、この順序でインシデント対応することが示されています。(GitHub)
Azure RBACを前提にしたアクセス管理がより重要になる
Secure your Azure Key Vaultでは、レガシのアクセスポリシーではなくAzure RBACを使うことが推奨されています。Azure RBACは、ロール割り当て、スコープ、PIM、Deny assignmentなどAzure全体のアクセス管理と統合しやすく、Key Vaultのデータプレーン権限管理でも推奨モデルとされています。(Microsoft Learn)
関連する公式情報として、Key Vault APIバージョン2026-02-01以降では、新しく作成するKey Vaultの既定のアクセス制御モデルがAzure RBACになります。既存のKey Vaultは、enableRbacAuthorizationを明示的に変更しない限り現在のアクセス制御モデルを維持します。また、2026-02-01より前のKey VaultコントロールプレーンAPIバージョンは2027年2月27日に廃止予定で、データプレーンAPIは影響を受けないと説明されています。(Microsoft Learn)
影響を受ける対象者と最初に確認すべきこと
| 対象者 | 影響範囲 | 最初に確認すべき項目 |
|---|---|---|
| Azure管理者 | Key Vault全体のセキュリティ設定、ネットワーク、削除保護、監査 | Public network access、Private Endpoint、Firewall、Soft delete、Purge protection、診断ログ |
| ID・セキュリティ担当者 | RBAC、PIM、最小特権、条件付きアクセス | Key Vault AdministratorやSecrets Officerなどの割り当て、Owner/User Access Administratorの範囲 |
| DevOps・IaC担当者 | ARM、Bicep、Terraform、CLI、SDKのデプロイ動作 | APIバージョン、enableRbacAuthorization、アクセスモデルの明示指定 |
| アプリ開発者 | Key Vaultへの接続方式、シークレット取得、キー参照 | マネージドID、Azure Identity SDK、ハードコードされた資格情報の有無 |
| 監査・SOC担当者 | 不審操作の検知、バックアップ・復元の監視 | KeyBackup、KeyRestore、SecretGet、SecretDeleteなどの監査ログ |
この表で特に見落としやすいのは、Key Vault Contributorがキーやシークレットを読めるわけではない点です。Key Vault ContributorはKey Vaultリソース自体の管理向けであり、キー・シークレット・証明書のデータプレーンアクセスは別途RBACロールやアクセスポリシーが必要です。公式のRBACガイドでも、コントロールプレーンとデータプレーンは別のアクセス制御として説明されています。(Microsoft Learn)
管理者が優先して確認すべき設定
Key Vaultの分離設計を確認する
最初に見るべきは、Key Vaultをどの単位で分けているかです。公式情報では、アプリケーション、リージョン、環境ごとにKey Vaultを分けることが推奨されています。開発、検証、本番を同じKey Vaultに入れると、権限ミスや侵害時の影響範囲が広がります。(Microsoft Learn)
実務では、次のような分け方が扱いやすいです。
| 分離単位 | 推奨される場面 | 目的 |
|---|---|---|
| 環境別 | dev、stg、prodを分ける | 開発環境の権限ミスが本番へ波及するのを防ぐ |
| アプリ別 | 複数アプリが別々の秘密情報を持つ | アプリ間の不要な横断アクセスを防ぐ |
| リージョン別 | DRや地域要件がある | 障害対応とデータ所在管理を明確にする |
| テナント別 | マルチテナントSaaS | 顧客データの分離を強化する |
Key Vaultは設定情報や顧客データを大量に保存するデータストアではありません。アプリ設定はAzure App Configuration、一般データはAzure StorageやCosmos DBなど、用途に合ったサービスへ分けるべきです。(Microsoft Learn)
ネットワーク公開範囲を確認する
ネットワーク設定では、最も制限の強い選択肢から検討します。公式ドキュメントでは、Private Endpointのみを使いパブリックネットワークアクセスを無効化する、Firewallで静的IPや仮想ネットワークに限定する、Network Security Perimeterを使う、という選択肢が示されています。(Microsoft Learn)
| 設定 | 向いている環境 | 注意点 |
|---|---|---|
| Public network access無効 + Private Endpoint | 本番、機密性の高いシステム | DNSとPrivate Endpointの接続確認後に無効化する |
| Firewall + IP許可 | 固定IPから接続する運用端末や一部サービス | 動的IPのサービスでは運用が不安定になりやすい |
| Firewall + VNet/Service Endpoint | Azure内の特定サブネットから接続 | サブネット設定とKey Vault側ルールの両方が必要 |
| Trusted Microsoft Servicesのバイパス | 一部のMicrosoft管理サービス連携 | すべてのAzureサービスが対象ではない |
| Network Security Perimeter | PaaSリソースを論理境界で制御したい場合 | SecuredByPerimeterではTrusted Microsoft Servicesのバイパスが上書きされる場合がある |
新しいKey Vaultでは、既定でFirewallが無効になっているため、すべてのアプリケーションやAzureサービスから要求を送れる状態です。ただし、Key Vaultの操作にはMicrosoft Entra認証と権限が必要なため、「ネットワーク的に到達できる」と「シークレットを読める」は別問題です。(Microsoft Learn)
RBACとアクセスポリシーの状態を確認する
次に、Key VaultがAzure RBACで管理されているか、レガシのアクセスポリシーで管理されているかを確認します。Azure CLIでは、公式ドキュメントでもaz keyvault showやaz keyvault listでenableRbacAuthorizationを確認する方法が案内されています。(Microsoft Learn)
az keyvault show \
--name <vault-name> \
--resource-group <resource-group> \
--query "{name:name, rbacEnabled:properties.enableRbacAuthorization, publicNetworkAccess:properties.publicNetworkAccess}" \
--output table複数のKey Vaultを棚卸しする場合は、サブスクリプション単位で一覧化して、RBACが有効なもの、アクセスポリシーを使っているもの、不明なものを分けます。
az keyvault list \
--query "[].{name:name, resourceGroup:resourceGroup, rbacEnabled:properties.enableRbacAuthorization}" \
--output tableアクセスポリシーを使い続けること自体は現時点で完全にサポートされています。ただし、APIバージョン2026-02-01以降で新規Key Vaultを作成し、アクセスポリシーを使いたい場合は、enableRbacAuthorizationを明示的にfalseにする必要があります。指定しないとAzure RBACが既定になります。(Microsoft Learn)
Soft deleteとPurge protectionを確認する
Azure Key Vaultでは、誤削除や悪意ある削除に備えてSoft deleteとPurge protectionが重要です。Soft deleteが有効な場合、削除されたKey Vaultやキー、シークレット、証明書は7〜90日の保持期間内で復元できます。新しいKey VaultではSoft deleteは既定で有効で、一度有効になると無効化できません。保持期間は作成時に設定でき、後から変更できない点に注意が必要です。(Microsoft Learn)
Purge protectionを有効にすると、削除済み状態のKey Vaultやオブジェクトを保持期間が過ぎるまで完全削除できなくなります。ランサムウェアや内部不正を想定するなら、本番環境ではPurge protectionを有効化しておくのが基本です。(Microsoft Learn)
ローテーションと旧バージョンの扱いを確認する
暗号化キーは、ローテーションポリシーを使って定期的に新しいバージョンを作成できます。公式ドキュメントでは、暗号化のベストプラクティスとして少なくとも2年ごとのキー更新が示されています。(Microsoft Learn)
注意点は、ローテーションが「既存データをすべて再暗号化する」わけではないことです。多くのAzureサービスでは、新しいキーでデータ暗号化キーを再ラップします。処理が完了するまでは、古いキーと新しいキーの両方を有効にしておく必要があります。旧キーを早く無効化すると、既存データへアクセスできなくなる可能性があります。(Microsoft Learn)
監査ログとアラートを確認する
Key Vaultでは、誰が、いつ、どの操作を行ったかを監査することが重要です。Key Vault loggingを有効化すると、Key Vaultへのアクセス情報をログとして保存できます。ログには操作名、結果、呼び出し元IP、ID情報、HTTPステータスなどが含まれます。(Microsoft Learn)
特に監視したい操作は次のとおりです。
| 操作 | 監視すべき理由 |
|---|---|
SecretGet | 通常より多い取得はシークレット漏えいの兆候になり得る |
SecretDelete / KeyDelete / CertificateDelete | 誤削除や破壊的操作の検知に必要 |
KeyBackup / KeyRestore | キーの持ち出しや不正復元の兆候になり得る |
KeyPurge / SecretPurge | 復元不能な削除につながる |
VaultAccessPolicyChangedEventGridNotification | 権限変更の追跡に役立つ |
Secure your Azure Key Vaultでは、監査ログに加えてMicrosoft Defender for Key Vaultを有効化し、不審なアクティビティを監視・通知することも推奨されています。(Microsoft Learn)
開発者が確認すべき実装ポイント
ハードコードされた資格情報をマネージドIDへ置き換える
アプリケーションからKey Vaultへ接続する場合、クライアントシークレットや証明書をコードや設定ファイルに埋め込むのは避けるべきです。公式ドキュメントでは、アプリケーション認証の推奨方式としてシステム割り当てマネージドIDを有効化する方法が示されています。マネージドIDを使うと、Azure側でサービスプリンシパルを管理し、明示的な資格情報をアプリに持たせずに認証できます。(Microsoft Learn)
実装上は、Azure App Service、Azure Functions、VM、AKSなど、利用している実行基盤がマネージドIDをサポートしているかを確認します。そのうえで、対象のマネージドIDにKey Vault Secrets User、Key Vault Crypto User、Key Vault Certificate Userなど、必要最小限のデータプレーンロールを割り当てます。(Microsoft Learn)
Key Vaultをアプリ設定の保管庫として使いすぎない
Key Vaultに入れるべきものは、パスワード、接続文字列、APIキー、暗号化キー、証明書など、保護が必要な秘密情報です。フラグ、表示文言、機能切り替え、一般的なサービス設定までKey Vaultに入れると、パフォーマンス、運用、権限設計が複雑になります。公式情報でも、顧客構成やサービス構成の保存先としてKey Vaultを使うのではなく、Azure StorageやAzure App Configurationの利用が推奨されています。(Microsoft Learn)
判断基準は次のとおりです。
| 入れるもの | Key Vaultに適しているか | 理由 |
|---|---|---|
| DB接続文字列 | 適している | 漏えい時の影響が大きい |
| 外部APIキー | 適している | ローテーションとアクセス監査が必要 |
| TLS証明書 | 適している | 証明書オブジェクトとして管理できる |
| 機能フラグ | 適していない | App Configurationの方が運用しやすい |
| 画面表示メッセージ | 適していない | 秘密情報ではない |
| 顧客データ | 適していない | Key Vaultはデータストアではない |
キー参照はバージョンレスURIを検討する
Azureサービスでカスタマー管理キーを使う場合、キーのローテーション後に新しいバージョンへ自動追従できるよう、対象サービスの仕様に従ってバージョンレスキーURIの利用を検討します。公式ドキュメントでは、対象サービスが最新バージョンを自動取得できるようにバージョンレスキーURIを使うこと、ただし復号やアンラップで同じキー素材を指す必要がある場合はバージョン付きURIとの関係に注意することが説明されています。(Microsoft Learn)
重要なのは、ローテーション後すぐに古いキーを無効化しないことです。サービスによって新しいキーの検出と適用にかかる時間は異なり、公式ドキュメントでも1時間から24時間以上かかる場合があると説明されています。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
Azure RBACへ切り替える前にロールを割り当てる
既存Key VaultをアクセスポリシーからAzure RBACへ切り替える場合、いきなり権限モデルを変更すると障害につながります。公式RBACガイドでは、Azure RBAC権限モデルに切り替えると既存のアクセスポリシー権限が無効化され、同等のAzureロールが割り当てられていない場合に停止を引き起こす可能性があると警告されています。(Microsoft Learn)
安全な移行順序は次のとおりです。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 事前調査 | 現在のアクセスポリシーを一覧化 | 誰が何にアクセスしているかを把握する |
| ロール設計 | 必要なAzure RBACロールへ置き換え | Secrets User、Crypto Officerなどを使い分ける |
| 事前割り当て | ユーザー、グループ、マネージドIDへロール付与 | アプリ単位・環境単位で最小権限にする |
| 検証 | 検証環境で読み取り・更新・ローテーションを確認 | 403エラー、ネットワーク遮断、ログ出力を確認 |
| 切り替え | 本番Key Vaultの権限モデルを変更 | 変更時間帯とロール反映遅延を考慮する |
| 監視 | 変更後の失敗ログを確認 | アプリのシークレット取得失敗を早期検知する |
IaCではアクセスモデルを明示する
ARM、Bicep、Terraform、CLI、SDKでKey Vaultを作成している環境では、APIバージョンの変更に注意が必要です。APIバージョン2026-02-01以降で新規Key Vaultを作成する場合、既定はAzure RBACです。アクセスポリシーを使い続ける場合は、enableRbacAuthorizationを明示的にfalseへ設定する必要があります。(Microsoft Learn)
反対に、RBACへ移行する方針なら、テンプレート内でRBACを前提にしたロール割り当てまで含めて管理します。Key Vaultだけを作成し、データプレーンロールの割り当てを手作業にすると、デプロイ直後にアプリケーションがシークレットを取得できない状態になりやすいです。
ネットワーク制限は段階的に強める
Private Endpointを使う場合、いきなりPublic network accessを無効化すると、アプリケーションや運用端末からKey Vaultへ接続できなくなることがあります。公式ドキュメントでも、パブリックアクセス無効化後はPrivate Endpoint経由でのみアクセス可能になるため、Private Endpoint構成を完了してから無効化する必要があると説明されています。(GitHub)
推奨順序は次のとおりです。
- Private Endpointを作成する
- Private DNSゾーンまたは名前解決を設定する
- アプリケーション実行環境からKey Vaultへ接続テストする
- 監査ログで接続元と失敗ログを確認する
- FirewallまたはPublic network access無効化を適用する
- パブリック経由の要求が拒否されることを確認する
このとき、外部から名前解決できることだけを理由に失敗と判断しないでください。2026年5月上旬の公式更新で明確化されたとおり、パブリックDNSの解決は残る設計です。(GitHub)
バックアップ権限を広く付けない
Key Vaultのバックアップは、事業継続やリージョン移行、コンプライアンス上の要件がある場合に有効です。ただし公式ドキュメントでは、多くのシナリオではKey Vaultの冗長性、Soft delete、Purge protectionで十分であり、バックアップは重要な業務上の理由がある場合に検討するものと説明されています。(Microsoft Learn)
さらに、Key Vault全体を一括バックアップする機能はなく、キー、シークレット、証明書は個別にバックアップする必要があります。バックアップされた暗号化BlobはAzure外では復号できず、同じAzureサブスクリプションとAzure geography内のKey Vaultへ復元して利用します。(Microsoft Learn)
バックアップ権限は、単なる読み取り権限より強い意味を持ちます。backupやrestoreを持つIDは、キーやシークレットの複製に関わる操作ができるため、常時付与ではなく、必要な担当者・自動化IDに限定し、監査ログで検知できるようにしておきます。(Microsoft Learn)
よくある誤解と正しい判断基準
| 誤解 | 正しい見方 |
|---|---|
| Private EndpointにしたのにDNS解決できるので公開状態だ | DNS解決は残る設計。実際のデータプレーン要求が拒否されるかを確認する |
| Key Vault Contributorならシークレットも読める | Key Vault Contributorは主に管理プレーン向け。データアクセスには別ロールが必要 |
| アクセスポリシーはすぐ廃止される | 既存のアクセスポリシーは引き続きサポートされる。ただし新規作成ではRBAC既定に注意する |
| キー侵害時は元のキーをすぐ無効化すればよい | 復元済みコピーは止まらず、依存サービス停止の恐れがある。置換キーへ移行してから無効化する |
| Soft deleteだけで十分 | 完全削除対策にはPurge protectionも重要 |
| Key Vaultに設定値を全部入れると安全 | 秘密情報以外はApp ConfigurationやStorageなどへ分ける |
すぐに実施したい確認チェックリスト
既存環境では、次の順番で確認すると効率的です。
- Key Vault一覧を取得し、
enableRbacAuthorization、Public network access、Soft delete、Purge protectionの状態を棚卸しする - 本番Key Vaultがアプリケーション、環境、リージョン、テナントの単位で適切に分離されているか確認する
- アクセスポリシーを使っているKey Vaultを特定し、Azure RBACへ移行するか、アクセスポリシーを継続するかを決める
- APIバージョン
2026-02-01以降を使うIaCやスクリプトで、アクセスモデルが明示されているか確認する - Private Endpoint利用環境では、DNS解決ではなく、実際のパブリック経由アクセス拒否とプライベート経由接続を検証する
- マネージドIDを使っていないアプリケーションを洗い出し、クライアントシークレットのハードコードを解消する
- キー、シークレット、証明書のローテーション方針を決め、旧バージョンを無効化するタイミングを運用手順に入れる
KeyBackup、KeyRestore、削除、完全削除、権限変更のログアラートを設定する- バックアップ権限を持つユーザー、グループ、サービスプリンシパル、マネージドIDを最小限に絞る
- キー侵害時の対応手順を、旧キー無効化からではなく、置換キー作成と依存サービス移行から始める形に更新する
まとめ：Secure your Azure Key Vaultは「作成後の安全運用」を見直す合図
Secure your Azure Key Vaultで押さえるべき本質は、Key Vaultを単なる秘密情報の保管場所ではなく、ネットワーク、ID、権限、削除保護、ローテーション、監査、復旧まで含めて守る重要インフラとして扱うことです。
2026年5月時点の公式情報では、Private Endpoint利用時のパブリックDNSの見え方、バックアップ復元キーの独立性、Azure RBAC前提のアクセス管理が特に重要です。管理者はKey Vaultの設定を棚卸しし、開発者はマネージドIDと最小権限、バージョンレスキーURI、ローテーション後の旧キー扱いを確認してください。
最初の一歩は、すべてのKey Vaultを一覧化し、RBAC状態、ネットワーク公開範囲、削除保護、ログ、バックアップ権限を表にまとめることです。そこまでできれば、移行すべきKey Vault、すぐに閉じるべき公開範囲、事故時に危険な権限が見えるようになります。
コメント