Azure Key Vaultを使いはじめて、いちばん最初に「なんで？」と引っかかるのがアクセス制御です。ボールト（Key Vault本体）は作れた、シークレットも入れた。なのに、いざアプリやチームメンバーが読もうとすると「アクセスが拒否されました（Forbidden）」。しかも管理者権限を持っているはずの自分ですら、シークレットの中身が見えない——。
私も最初、まさにこれで数時間溶かしました。Key Vaultの権限は、ふつうのAzureリソースと少しクセが違っていて、「ボールトを触る権限」と「中身を触る権限」がきっちり分かれているんです。ここを知らないと、公式ドキュメントを読んでも「RBAC」「アクセスポリシー」「データプレーン」「コントロールプレーン」という単語の海でおぼれます。
「オーナー権限あるのに、なんでシークレットが読めないの？アクセスポリシーとRBAC、どっちを使えばいいの？」
この記事では、Key Vaultのアクセス制御を、初心者がつまずく順に噛み砕いていきます。具体的には、アクセスポリシーとAzure RBACという2つの権限モデルの違い、用途に応じたロール（Key Vault Secrets Userなど）の割り当て方、そして混乱の元凶であるコントロールプレーンとデータプレーンの権限の違いです。読み終わるころには、「誰に、どの権限を、どこに付ければいいのか」を自分で設計できるようになります。
なお、そもそもKey Vaultが何をするサービスなのか全体像があやふやな方は、先に Azure Key Vaultとは？シークレット・キー・証明書を安全に管理する仕組み に目を通しておくと、この記事の位置づけがはっきりします。本記事はその中の「アクセス制御」を深掘りする子記事です。
まず理解したい「2種類の権限」——金庫のたとえ
細かい設定に入る前に、この1点だけ頭に入れておくと、あとの話が一気に整理されます。Key Vaultの権限には、性質のまったく違う2つのレイヤーがあります。銀行の貸金庫にたとえると分かりやすいです。
1つ目は金庫そのものを管理する権限です。金庫を新しく設置する、金庫を撤去する、金庫の設定（誰が使えるか、防犯カメラを付けるか）を変える——いわば「金庫室の管理人」の権限。Azureではこれをコントロールプレーンと呼びます。ボールトの作成・削除・ネットワーク設定・アクセス制御方式の切り替えなど、Key Vaultリソース自体の管理がここです。
2つ目は金庫の中身を出し入れする権限です。金庫を開けて、書類（シークレット）を取り出す、新しく入れる、印鑑（キー）で判子を押す——「金庫の利用者」の権限。Azureではこれをデータプレーンと呼びます。シークレットの読み取り・書き込み、キーでの暗号化・署名、証明書の取得などがここです。
ここが最大のポイントなのですが、この2つは完全に別モノとして権限が管理されます。「金庫室の管理人」だからといって、勝手に中身を見ていいわけではない。逆に「金庫を使う人」が、金庫の設置場所を勝手に変えられても困る。だから分かれているのです。冒頭の「オーナー権限があるのにシークレットが読めない」という悲劇は、まさにこの分離が原因です。この話は後半で決着をつけます。
アクセスポリシー vs Azure RBAC——2つの権限モデル
では、先ほどの「データプレーン（中身へのアクセス）」を、いったい誰にどう許可するのか。Key Vaultには、これを設定する方法が2つ用意されています。ここが初心者を最初に混乱させる分かれ道です。ボールトを作るとき、あるいは既存ボールトの「アクセス構成」で、どちらか一方を選ぶことになります。
アクセスポリシー方式（旧来の方式）
アクセスポリシー（Access Policy）は、Key Vaultが昔から持っている独自の権限管理方式です。ボールトの「アクセスポリシー」画面で、「このユーザー（またはアプリ）に対して、シークレットは取得・一覧を許可、キーは許可しない、証明書は許可しない」といったように、操作の種類ごとにチェックを付けていくイメージです。
特徴は、権限がそのボールト単位で完結すること。ボールトAのアクセスポリシーは、ボールトAの中でだけ有効です。シンプルではあるのですが、規模が大きくなると弱点が出ます。ボールトが50個あれば、50個それぞれのアクセスポリシーを個別に見て回らないといけない。「このユーザーは結局どのボールトに何の権限を持っているか」を横断的に把握しづらいのです。また、権限を割り当てる相手はユーザー・グループ・アプリのオブジェクトIDで、Azureの他のリソースと同じ仕組みでは管理できません。
Azure RBAC方式（現在の推奨）
もう一方のAzure RBAC（ロールベースアクセス制御）は、Azure全体で使われている標準の権限管理方式を、Key Vaultのデータプレーンにも適用するものです。仮想マシンやストレージと同じ「ロールを割り当てる」というやり方で、シークレットやキーへのアクセスをコントロールできます。
RBACの強みは粒度の細かさとスコープの柔軟さです。アクセスポリシーは基本「ボールト全体」に対する許可でしたが、RBACなら「このボールトの、この特定のシークレットだけ読み取り可」といった個別オブジェクト単位の権限まで設定できます。さらに、サブスクリプション全体・リソースグループ・単一ボールトと、割り当てるスコープを自由に選べるので、「この部署は開発用リソースグループ内の全ボールトを読める」といった設計が、他のAzureリソースと同じ考え方でできます。権限の一覧も「アクセス制御（IAM）」でAzureのどのリソースでも同じ画面から確認できるので、横断的な把握がラクです。
「新しくKey Vaultを作るなら、迷わずAzure RBACを選ぶ」。これが今の公式の推奨です。
結論：新規はRBAC、既存のポリシーからも移行できる
Microsoftの公式ドキュメントでも、アクセスポリシーよりAzure RBACが推奨とされています。理由はこれまで見たとおりで、権限の一元管理・細かい粒度・他リソースとの統一感、そして監査のしやすさです。アクセスポリシーは今も使えますし、いきなり廃止されるわけではありませんが、これから学ぶ・新しく作るならRBACを選んでおけば間違いありません。この記事の以降の説明も、基本的にRBACを前提に進めます。
1点だけ実務の注意を。既存のアクセスポリシー方式のボールトをRBACへ切り替えると、それまでのアクセスポリシーは無視され、代わりにRBACのロール割り当てが効くようになります。つまり切り替えた瞬間、必要なロールをまだ割り当てていないと、これまで動いていたアプリが一斉にアクセスできなくなります。移行するときは「先にRBACのロールを割り当ててから、方式を切り替える」順番を守ってください。ここを逆にやると、本番のアプリが軒並み止まります。
用途に応じたロールを割り当てる
RBACを選んだら、次にやるのはロールの割り当てです。ロールとは「権限のセットに付けた名前」だと思ってください。Key Vault用にあらかじめ用意された（ビルトインの）ロールがいくつもあり、用途に合わせて選んで人やアプリに割り当てます。全部覚える必要はなく、まず押さえるべきは次の3つです。
よく使う3つのロール
Key Vault Secrets Userは、シークレットの中身を読み取るためのロールです。書き込みや削除はできず、値を取得（get）できるだけ。もっとも出番が多いのがこれで、たとえば「WebアプリがDBの接続文字列をKey Vaultから読み込む」といったケースでは、そのアプリのマネージドIDにこのロールを割り当てます。アプリに必要なのは「読む」ことだけなので、最小権限の原則にぴったりです。
Key Vault Secrets Officerは、シークレットの読み取りに加えて、作成・更新・削除までできるロールです。シークレットを実際に登録・管理する運用担当者向け。人がシークレットを入れ替える作業をするならこちらです。
Key Vault Administratorは、シークレットだけでなくキーも証明書も含めた、データプレーン全体の全操作ができる強力なロールです。何でもできるぶん、割り当てる相手は絞るべきです。「とりあえず全部できるようにしておこう」とこれを配りまくると、最小権限からどんどん遠ざかります。読むだけのアプリにはSecrets User、というふうに使い分けるのが鉄則です。
キーを扱うなら Key Vault Crypto User（暗号化・署名などの利用）や Key Vault Crypto Officer（キーの管理）、証明書なら Key Vault Certificates Officer といったように、オブジェクトの種類ごとに専用ロールが分かれているのもRBACの特徴です。「シークレットは読めるがキーは触れない」といった、用途に応じたきめ細かい設計ができます。
実際に割り当てる（ポータルとCLI）
ポータルでの手順はシンプルです。対象のKey Vaultを開き、左メニューの「アクセス制御（IAM）」→「追加」→「ロールの割り当ての追加」を選びます。ロール一覧から「Key Vault Secrets User」などを選び、次の画面で割り当てる相手（ユーザー・グループ・アプリのマネージドID）を指定して保存するだけ。他のAzureリソースでロールを割り当てるのと、まったく同じ画面・同じ操作です。
Azure CLIなら、こう書きます。特定のユーザーに、あるボールトのシークレット読み取り権限を与える例です。
az role assignment create \
--role "Key Vault Secrets User" \
--assignee "user@example.com" \
--scope "/subscriptions/<サブスクリプションID>/resourceGroups/<RG名>/providers/Microsoft.KeyVault/vaults/<ボールト名>"各パラメータの意味はこうです。
--role：割り当てるロール名。ここを「Key Vault Administrator」などに変えれば権限が変わる。--assignee：相手。ユーザーのメールアドレスのほか、アプリのオブジェクトID（マネージドID）も指定できる。--scope：どこまで効かせるか。この例はボールト単体だが、末尾の/providers/...を外してリソースグループまでにすれば、そのRG内の全ボールトが対象になる。
--scope を短くするほど広い範囲に効く、というのがRBACの勘どころです。最初は「必要なボールト1つだけ」に絞って割り当て、広げたくなったらスコープを上げる、という進め方が安全です。
コントロールプレーンとデータプレーン——「読めない/読めてしまう」の正体
さて、冒頭で予告した悲劇に決着をつけます。「管理者権限を持っているのに、シークレットが読めない」——これがKey Vault特有の、いちばん有名なつまずき所です。原因は、前半の金庫のたとえで触れたコントロールプレーンとデータプレーンの分離にあります。
「オーナーなのにシークレットが読めない」のはなぜ
Azureでよく見る「オーナー（Owner）」や「共同作成者（Contributor）」というロールは、実はコントロールプレーンの権限です。つまり「金庫室の管理人」の権限であって、金庫を作ったり削除したり設定を変えたりはできますが、金庫の中身（シークレットの値）を読む権限は含まれていません。
だから、RBAC方式のボールトでは、Ownerロールしか持っていない人がシークレットの値を取得しようとすると、しっかり拒否されます。「え、オーナーだよ？」と思うのですが、これはバグではなく、そう設計されているのです。中身を読みたいなら、コントロールプレーンのOwnerとは別に、データプレーンのロール（Key Vault Secrets User など）を明示的に割り当てる必要があります。この「別々に付ける」を知らないと、延々とハマります。
「Ownerは金庫室の鍵は持っているが、金庫の中身の鍵は別」。この一言を覚えておくだけで、あの悲劇は防げます。
逆に「読めてしまう」危うさ
この分離は、裏を返すとセキュリティ上とても重要な意味を持ちます。もしコントロールプレーンの権限だけで中身も読めてしまうと、ボールトを管理するインフラ担当者が、全員シークレットの中身（パスワードやAPIキー）まで見られてしまうことになります。それは困りますよね。「金庫を設置する業者」に「中の書類も全部見せる」必要はないわけです。
だからこそ、コントロールプレーン（管理）とデータプレーン（中身へのアクセス）を分けることで、「ボールトの管理はできるが、中身は見られない」という担当者をきちんと作れるのです。これは最小権限を実現するうえで、Key Vaultのいちばん大事な設計思想と言えます。「なんで分かれてて面倒なんだ」ではなく、「機密を守るためにわざと分けている」と理解すると腑に落ちます。
整理：どの権限がどちら側か
混乱しやすいので、代表的なものがどちらのプレーンに属するかを整理しておきます。
- コントロールプレーン（ボールトの管理）：ボールトの作成・削除、ネットワーク設定、アクセス方式（RBAC/ポリシー）の切り替え、RBACロールの割り当てそのもの。Owner・Contributorなどが該当。
- データプレーン（中身へのアクセス）：シークレットの取得・登録・削除、キーでの暗号化・署名、証明書の取得。Key Vault Secrets User / Officer / Administrator などが該当。
ざっくり言えば、「Key Vault ○○」という名前のロールはデータプレーン、Owner・Contributorのような汎用ロールはコントロールプレーン、と覚えておけば大きく外しません。実運用では、インフラ担当にはContributor（管理はできるが中身は見えない）、アプリにはSecrets User（中身を読むだけ）、というふうに、両プレーンを意識して権限を分けて渡すのが正しい姿です。
まとめ
この記事では、Key Vaultのアクセス制御を、実務でつまずく順に見てきました。要点を振り返っておきます。
- 2つのプレーン：Key Vaultの権限は「ボールトを管理する（コントロールプレーン）」と「中身にアクセスする（データプレーン）」に分かれている。金庫室の管理人と、中身を出し入れする人は別。
- アクセスポリシー vs RBAC：アクセスポリシーはボールト単位の旧来方式。Azure RBACはロールベースで粒度が細かく、スコープも柔軟。新規は迷わずRBACが推奨。
- 用途別のロール：読むだけならKey Vault Secrets User、登録・管理ならSecrets Officer、データプレーン全部ならAdministrator。最小権限で使い分ける。
- 「オーナーなのに読めない」：Owner/Contributorはコントロールプレーンの権限。中身を読むには、別途データプレーンのロールを割り当てる必要がある。バグではなく仕様。
- この分離のおかげで「管理はできるが中身は見られない担当者」を作れる。セキュリティ上とても大事。
ここまで理解できれば、「アクセスが拒否された」というエラーに出くわしても、「これはコントロール側？データ側？どのロールが足りない？」と切り分けられるようになります。Key Vault運用の最初の壁は、これで越えられたはずです。
あわせて読みたい：
