2026.07.23 インフラ

Azure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説

Azure Key Vaultは、パスワード・接続文字列・APIキーといったシークレット、暗号鍵、TLS証明書を1か所に集約し、Microsoft Entra IDの認証と認可のもとで安全に受け渡すMicrosoft Azureのマネージドサービスです。実装で最初に押さえるべきは、管理対象がシークレット・キー・証明書の3種類に分かれること、操作面がコントロールプレーンとデータプレーンの2層に分かれること、そしてStandard・Premium・Managed HSMというSKUで鍵の保護強度が変わることです。この記事では定義から、認可モデル（Azure RBACとアクセスポリシー）、論理削除やパージ保護といった保護機能、AWSのSecrets Manager／KMSとの対応関係、そして「どんなシステムで採用し、どこでは別サービスにするか」の判断基準までを、2026年時点の公式ドキュメントに基づいて整理します。

目次

まとめ：Azure Key Vaultの要点と採用判断の分岐

Azure Key Vaultは、アプリのコードや構成ファイルに機密情報を直書きしないための「秘密の金庫」として、Azure上のシステムで第一候補になるマネージドサービスです。シークレット・キー・証明書を金庫（ボールト）に格納し、アプリはMicrosoft Entra IDのマネージドIDで認証したうえで、ボールト名.vault.azure.netというエンドポイントから必要な値だけを取得します。運用設計の中心は、誰が何を操作できるかを決める認可モデル（Azure RBAC推奨）と、削除事故から守る論理削除・パージ保護、そして到達経路を絞るネットワーク制御の3点になります。

採用が合理的なのは、Azure中心のシステムで資格情報をコードから排除し、鍵のローテーションや証明書の更新を集中管理したい場合です。逆に、鍵の管理に単一テナント専有かつFIPS 140-2レベル3相当の要件があるならManaged HSMを、AWS中心の構成ならSecrets ManagerやKMSを検討します。自社システムでシークレット管理をどう設計するか迷う段階なら、クラウド全体の構成から相談できる開発会社に早めに当たると、後戻りの少ない設計にたどり着けます。

Azure Key Vaultの仕組みと3種類の管理対象データ

Key Vaultは「ボールト」という論理的な金庫を単位に、機密データを暗号化して保管するサービスです。何を格納するかによって扱いが変わるため、まず3種類の管理対象を区別するところから設計が始まります。

シークレット・キー・証明書を一元管理するマネージドサービスという位置づけ

Key Vaultが扱う対象は3種類です。シークレットは、データベースの接続文字列やAPIキーのような任意の文字列を暗号化して保管する枠で、1件あたり最大25KBまで格納できます。キーは、RSAや楕円曲線などの暗号鍵そのもので、鍵を外部に出さずに署名・暗号化・復号といった演算をKey Vault内で実行できる点が特徴です。証明書は、TLS/SSL証明書のライフサイクル（発行・更新・失効）を管理する枠で、対応する認証局と連携すれば自動更新も設定できます。暗号鍵と暗号方式そのものの前提は、暗号化の仕組みと共通鍵・公開鍵の違いを解説した記事で確認しておくと、キー管理の話が読み解きやすくなります。

コントロールプレーンとデータプレーンという2つの操作面の分離

Key Vaultの操作は、性質の異なる2つの面に分かれます。コントロールプレーンは、ボールトそのものを作成・削除し、SKUやアクセス構成を変更する管理面で、Azure Resource Managerを通じて操作します。データプレーンは、ボールトの中身であるシークレット・キー・証明書を実際に読み書きする面で、専用のRESTエンドポイントやSDK経由でアクセスする仕組みです。この2面は認可も別々に効くため、「ボールトは作れるが中の値は読めない」「値は読めるがボールト設定は変えられない」といった分離した権限設計が可能になります。実装では、この境界を意識して運用担当と開発担当の権限を切り分けるのが定石です。

StandardとPremiumの2つのSKUとManaged HSMの位置づけ

ボールトのSKUは2種類で、鍵をどこで保護するかが変わります。Standardはソフトウェアで鍵を保護し、多くの用途はこちらで足ります。Premiumは、専用のハードウェアセキュリティモジュール（HSM）を背後に持つ鍵を扱え、FIPS 140-2レベル2で検証されたモジュールで鍵を保護します（2026年時点）。さらに要件が厳しい場合は、Key Vaultとは別サービスのManaged HSMがあり、単一テナント専有のHSMクラスターでFIPS 140-2レベル3相当の保護を提供します。次の表に位置づけを整理します。

種別 鍵の保護 主な用途
Standard ソフトウェア保護 一般的なシークレット・鍵管理
Premium HSM保護（共有・レベル2） HSM要件のある鍵
Managed HSM 専有HSM（レベル3相当） 単一テナント要件・高規制

StandardとPremiumは同じボールトの延長で使える一方、Managed HSMは料金体系も運用も異なる別プロダクトです。まずはStandardで始め、HSM保護や単一テナントの規制要件が出た段階でPremiumやManaged HSMへ引き上げる、という段階設計が現実的でしょう。

認可モデル：Azure RBACとアクセスポリシーモデルの違い

Key Vaultの設計で最もつまずきやすいのが、誰が何にアクセスできるかを決める認可の部分です。認証はMicrosoft Entra IDが担い、その先の認可に2つのモデルが用意されています。

Microsoft Entra IDによる認証とマネージドIDでの資格情報レス接続

Key Vaultへのアクセスは、まずMicrosoft Entra ID（旧Azure Active Directory）でIDを認証するところから始まります。アプリからの接続で推奨されるのは、マネージドIDを使う方法です。仮想マシンやApp Service、Functionsなどに割り当てたマネージドIDでKey Vaultにアクセスすれば、接続用の資格情報をアプリ側に一切持たずに済みます。つまり「Key Vaultにアクセスするためのパスワードをどこに保管するか」という循環問題を、マネージドIDが断ち切る形です。IDと認証の全体像は、認証・ID管理の仕組みとMFA・SSO・IDaaSの違いを整理した記事と合わせて見ると、Entra IDがKey Vaultの入口をどう守るかが立体的に見えてきます。

Azure RBACとレガシーなアクセスポリシーモデルの2系統

認可にはAzure RBACとアクセスポリシーの2系統があります。Azure RBACは、Azure全体で統一されたロールベースのアクセス制御で、コントロールプレーンとデータプレーンの両方に適用でき、権限をサブスクリプションやリソースグループ単位で継承・一元管理できるのが利点です。もう一方のアクセスポリシーモデルは、データプレーン専用の旧来方式で、ボールトごとに「このプリンシパルにシークレットのget/listを許可」といった許可を個別に列挙します。現在はセキュリティと運用の一貫性の観点からAzure RBACの利用が推奨されており、新規に構築するなら原則RBACを選ぶのが妥当な判断です。

Key Vault管理者・シークレットユーザーなど組み込みロールの粒度

Azure RBACには、Key Vault専用の組み込みロールが用意されています。代表的なものは、ボールトの管理も中身の操作もできるKey Vault管理者、シークレットの読み取りに絞ったKey Vaultシークレットユーザー、証明書を扱うKey Vault証明書責任者、暗号演算を担うKey Vault暗号化担当者などです。運用では、アプリのマネージドIDには「シークレットユーザー」のように最小権限のロールだけを割り当て、鍵の作成や削除は管理者ロールを持つ限られた担当だけが行う、という最小権限の原則で設計します。次の表に主なロールと想定付与先を整理します。

ロール できること 想定付与先
Key Vault管理者 管理と全データ操作 運用管理者
シークレットユーザー シークレットの読み取り アプリのマネージドID
証明書責任者 証明書の管理 基盤担当
Key Vault閲覧者 メタデータの参照 監査・確認用途

保護機能：論理削除とパージ保護・ネットワークによるアクセス制御

金庫である以上、誤削除や不正な到達からの防御が設計の要になります。Key Vaultは、削除事故に備える論理削除・パージ保護と、到達経路を絞るネットワーク制御を備えています。

既定で有効な論理削除（ソフトデリート）と7〜90日の保持期間

論理削除（ソフトデリート）は、削除したボールトやシークレット・キー・証明書を即座には消さず、一定期間は復元可能な状態で保持する仕組みです。この機能はボールトで既定有効になっており、無効化はできません。保持期間は7〜90日の範囲で設定でき、指定しない場合の既定値は90日です。この期間内であれば、誤って削除したシークレットや、削除されたボールトそのものを復元できます。うっかり消したことがそのまま本番障害に直結しないための、最初の安全網といえます。

任意設定のパージ保護と本番環境で有効化を推奨する理由と使い分け

パージ保護は、論理削除された状態のリソースを、保持期間が満了するまで完全削除（パージ）できないよう強制する追加の防御です。論理削除と違ってパージ保護は既定では無効で、有効化するかは運用者の判断に委ねられます。有効にすると、組織内の管理者はもちろんMicrosoft側であっても、保持期間中はパージを実行できなくなります。これは内部からの悪意ある削除や、権限を奪われた際の即時消去に対する備えです。本番環境では、保持期間を長め（最大90日）に取ったうえでパージ保護を有効化するのが堅実な構成になります。一方で、検証環境では作り直しの都合上あえて無効のままにする、といった使い分けも実務では行われます。

プライベートエンドポイント・ファイアウォールによるネットワーク分離

既定のKey Vaultはパブリックなエンドポイントを持ち、認証と認可を通れば理屈上はどこからでも到達できます。到達経路そのものを絞りたい場合は、ボールトのファイアウォールで許可する仮想ネットワークやIP範囲を限定し、さらにプライベートエンドポイントを使えば、Key Vaultへの通信を自社の仮想ネットワーク内の閉じた経路に閉じ込められます。認証・認可・ネットワークの3層で守る考え方は、クラウド全体の守り方と共通です。責任共有モデルを含む土台は、クラウドセキュリティのリスクと責任共有モデルを解説した記事で押さえておくと、Key Vaultをどこまで自社で守るべきかの線引きがはっきりします。

AWSの機密管理サービスとの対応関係とアプリからのシークレット取得

マルチクラウドや移行を検討するなら、AWSの機密管理サービスとの対応関係を押さえておくと設計を横展開できます。また、実装者が最も知りたいのはアプリからどう値を取り出すかでしょう。

AWS Secrets Manager・KMS・ACMとの対応関係

Key Vaultの機能は、AWSでは複数のサービスに分かれています。シークレット管理はAWS Secrets Manager、暗号鍵の管理と演算はAWS KMS、証明書の管理はAWS Certificate Managerが担い、Key Vaultはこれらをおおむね1つのサービスに束ねた位置づけです。認可の考え方も対応しており、AzureのRBACはAWSのIAMポリシーに相当します。クラウド認可の設計思想を対比したい場合は、AWS IAMの仕組みとユーザー・ロール・ポリシーの権限設計を解説した記事と読み比べると、Entra ID＋RBACとIAMの粒度の違いが見えてきます。

Key Vault参照・CSIドライバーによるアプリ／AKSからの取得

アプリからの取り出し方は用途で選びます。App ServiceやFunctionsでは、アプリケーション設定に@Microsoft.KeyVault(...)形式のKey Vault参照を書くだけで、実行時にKey Vaultから値が解決され、コードを書かずに機密を注入できます。AKS（Kubernetes）では、Secrets Store CSIドライバーのAzure Key Vaultプロバイダーを使い、ボールト内のシークレットをPodのボリュームとしてマウントする方式が一般的です。コードから直接扱う場合も、各言語のAzure SDKとマネージドIDを組み合わせれば、接続情報を持たずにシークレットを取得できます。たとえばストレージの接続文字列を安全に渡す場面では、Azure Blob Storageの仕組みと採用判断を解説した記事で扱うストレージアカウントのキーをKey Vaultに預け、アプリはKey Vault参照で受け取る、という組み合わせが定番の設計になります。

Azure Key Vaultを採用すべき場面と見送るべき場面

ここからは判断です。Key Vaultは万能ではなく、真価を発揮する場面と、別サービスに委ねるべき場面がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。

Azure Key Vaultの採用が合理的になる実務上の条件

次のいずれかに該当するなら、Key Vaultが第一候補になります。

  • Azure上のシステムで、接続文字列やAPIキーをコードや構成ファイルから排除したい
  • マネージドIDと組み合わせ、アプリに資格情報を一切持たせずに機密へアクセスさせたい
  • TLS証明書の発行・更新を集中管理し、更新漏れによる失効を防ぎたい
  • 暗号鍵を外部に出さず、署名・暗号化・復号をサービス内で完結させたい

いずれもクラウド上で機密を扱う際の定番要件で、マネージドIDとの組み合わせが効くほど運用負荷が下がります。特に、鍵や証明書のローテーションを人手の運用から自動化へ寄せられる点が、長期的な事故防止につながります。

Azure Key Vaultを選ぶべきでない場面と適切な代替

一方で、次の要件にはKey Vaultをそのまま当てはめません。第一に、鍵の保護に単一テナント専有のHSMやFIPS 140-2レベル3相当が要件化されているなら、共有Premiumではなく別プロダクトのManaged HSMを選びます。第二に、AWSやGoogle Cloud中心の構成なら、Secrets ManagerやSecret Managerなど各クラウドの機密サービスに寄せた方が、認可とネットワークの一貫性を保ちやすいでしょう。第三に、Key Vaultはシークレットの保管には向く一方、アプリの一般設定値（機密でないフラグやパラメーター）まで全部入れる置き場ではなく、そちらはApp ConfigurationやKubernetesのConfigMapが適します。第四に、1秒間に大量のシークレット取得を繰り返す設計はスロットリング（要求制限）に当たりやすいため、取得結果をアプリ側で適切にキャッシュする前提が要ります。

受託開発におけるシークレット管理の設計の勘所と外注先への相談

実際のシステムでは、Key Vault単体ではなく、マネージドID・RBAC・ネットワーク制御・アプリ側のキャッシュ戦略を一体で設計する必要があります。どの機密をどのボールトに置き、どのIDにどのロールを与え、どの経路からアクセスさせるかは、可用性・監査要件・運用体制のトレードオフで決まり、後からの権限再設計にはアプリ改修が伴います。要件定義の段階でシークレット管理の方針まで固めておくほど、開発後半の作り直しを避けられる設計です。Azureを含むクラウドインフラの構築・移行の相談では、Key Vaultを含む認証・認可・機密管理の設計から実装・運用までを一貫して支援できます。

よくある質問

Azure Key Vaultの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

Azure Key VaultとManaged HSMはどう違いますか？

Key Vault（Standard/Premium）は、多くのシステムで使う汎用的な機密管理サービスで、Premiumでも背後のHSMは複数テナントで共有されます。Managed HSMは、単一テナント専有のHSMクラスターを提供する別プロダクトで、FIPS 140-2レベル3相当の保護と専有性が要件になる高規制の用途に向きます。一般的なシークレットや証明書の管理はKey Vault、専有HSMが要件化された鍵はManaged HSMという切り分けです。

RBACとアクセスポリシーはどちらを使うべきですか？

新規構築では原則Azure RBACを選びます。RBACはAzure全体で統一された認可モデルで、権限の継承や一元管理ができ、セキュリティの観点からも推奨されています。アクセスポリシーはデータプレーン専用の旧来方式で、既存のボールトで使われている場合はありますが、これから設計するならRBACに寄せるのが妥当です。

削除したシークレットは元に戻せますか？

戻せます。論理削除（ソフトデリート）が既定で有効なため、削除したシークレットやボールトは保持期間（7〜90日・既定90日）の間は復元が可能です。さらにパージ保護を有効にしておくと、保持期間が満了するまで完全削除そのものを禁止でき、内部からの不正な即時消去にも備えられます。

アプリからKey Vaultにアクセスするパスワードはどこに置きますか？

置きません。仮想マシンやApp Serviceに割り当てたマネージドIDでEntra ID認証を行えば、Key Vaultへの接続用資格情報をアプリに持たせずにアクセスできます。「機密を守る金庫を開けるための機密」を持たずに済むのがマネージドIDの利点で、これがKey Vault利用時の推奨構成です。

AWSのSecrets ManagerやKMSとは何が違いますか？

役割は対応しますが、Key Vaultはシークレット・キー・証明書を1サービスに束ねる点が異なります。AWSではシークレットがSecrets Manager、鍵がKMS、証明書がCertificate Managerと分かれます。認可もAzureのRBACがAWSのIAMに相当する形で対応するため、設計思想は横展開できますが、APIやエンドポイントは別物です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る