Microsoft Purview でデータソース接続に Azure Key Vault のシークレットを使うとき、権限設定が少しでもズレると接続テストが Error (20500) で失敗します。この記事では「どの ID に」「どの権限を」「どのスコープで」付与すればよいかを、RBAC とアクセス ポリシーの両パターンで具体的に整理します。
結論：シークレット参照の許可を付与する相手は「Purview アカウントのマネージド ID」
まず結論から言うと、Purview が Key Vault のシークレットを読むために権限を付与すべき相手は、一般的な「Purview のサービス プリンシパル（アプリ登録）」ではなく、Purview アカウントに紐づくシステム割り当てマネージド IDです。
ここを取り違えると、Key Vault 側ではロール割り当て済みのように見えるのに、Purview 側の接続テストだけが Error: (20500) で失敗する、という状態になりやすいです。
よくある取り違えパターン
- Integration Runtime (IR) の ID に付与してしまう（Purview の実行主体とズレる）
- Microsoft Purview のアプリ登録（サービス プリンシパル）に付与してしまう（正しくは Purview アカウントのマネージド ID）
- 「それっぽい表示名」の principal を選んでしまい、Object (principal) ID が別物だった
まず理解しておきたい：Purview 周りの “ID” は複数存在する
Purview と Key Vault の権限トラブルは、ほとんどが「どの主体が Key Vault にアクセスするのか」の誤認から始まります。Purview には役割の違う ID が登場するため、最低限の整理が有効です。
| 登場する ID | 見え方（例） | 主な役割 | Key Vault のシークレット読み取り権限を付与すべきか |
|---|---|---|---|
| Purview アカウントのマネージド ID（システム割り当て） | Purview アカウントの「マネージド ID」画面で表示 | Purview が Azure リソースへ安全にアクセスするための実行主体 | 付与する |
| Purview のサービス プリンシパル（アプリ登録） | Entra ID（旧 Azure AD）側でアプリとして見える | コントロール プレーンや管理系の連携で出ることがある | 通常は付与しない（今回のポイント） |
| Integration Runtime（自己ホスト/マネージド）の実行主体 | IR の構成や VM/サービスとして存在 | スキャン/コピーなどの実行経路に関与 | ケースによる（ただし “Purview が Key Vault を読む” の主体と違いがち） |
この記事のテーマである「Purview が Key Vault のシークレットを参照して接続テストをする」場面では、Purview アカウントのマネージド ID を主役として扱うのが基本線です。
手順：Purview アカウントのマネージド ID を確認する
最初に、権限付与の対象となる principal を特定します。表示名ではなく、Object (principal) ID を基準に確認すると事故が減ります。
- Azure ポータルで Microsoft Purview（Purview アカウント）を開く
- 左メニューの マネージド ID を開く
- システム割り当て が「オン」になっていることを確認（オフならオンにする）
- 表示される オブジェクト ID（principal ID） を控える
以降の設定では、このマネージド ID（principal）を Key Vault 側の権限付与先に指定します。
次に重要：Key Vault の権限モデルを確認する（RBAC か アクセス ポリシーか）
Key Vault は大きく 2 つの権限付与モデルがあります。ここを読み違えると「ロール割り当てしたのに効かない」という状態になります。
| モデル | Key Vault 側の設定名 | 権限付与の場所 | よくある落とし穴 |
|---|---|---|---|
| Azure RBAC（推奨されることが多い） | アクセス構成：Azure ロールベースのアクセス制御 | Key Vault の アクセス制御 (IAM) | シークレット単位のスコープ付与だけで済むと思い込む |
| 従来のアクセス ポリシー | アクセス構成：Vault アクセス ポリシー | Key Vault の アクセス ポリシー | RBAC のロール割り当てをしても 無視される |
Azure ポータルで Key Vault を開き、アクセス構成（または「Access configuration」）の項目でどちらのモデルかを確認してください。
Key Vault が RBAC モデルの場合：Purview のマネージド ID に「Key Vault Secrets User」を Vault 全体スコープで付与
Key Vault が RBAC モデルの場合、最小権限でシークレット読み取りに必要な代表的ロールが Key Vault Secrets User です（シークレットの取得/一覧が必要なケースに対応しやすい）。
設定のポイント（ここを外すと Error 20500 につながりやすい）
- 付与先：Purview アカウントのマネージド ID
- ロール：Key Vault Secrets User
- スコープ：Key Vault リソース（Vault 全体）（推奨）
Purview の接続テストや内部処理が「一覧（List）」「メタデータ参照」「バージョン解決」などを行う実装になっていると、特定シークレットだけに付与した権限では不足し、結果として Error (20500) のような形で失敗します。まずは Vault 全体で必要最小限の権限を満たすのが切り分けとしても有効です。
Azure ポータルでの具体手順
- Key Vault を開く
- アクセス制御 (IAM) → 「追加」→「ロール割り当ての追加」
- ロールに Key Vault Secrets User を選択
- メンバーに Purview アカウントのマネージド ID を選択
- スコープが Key Vault（この Vault）になっていることを確認して保存
Azure CLI で付与する例
IaC で統一したい場合や、スコープを明確にしたい場合は CLI も便利です（下記は例です）。
# 変数は環境に合わせて置き換え
SUBSCRIPTION_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
RG_NAME="rg-purview"
KV_NAME="kv-prod"
PURVIEW_MI_OBJECT_ID="yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
SCOPE="/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RG_NAME}/providers/Microsoft.KeyVault/vaults/${KV_NAME}"
az role assignment create \
--assignee-object-id "${PURVIEW_MI_OBJECT_ID}" \
--assignee-principal-type ServicePrincipal \
--role "Key Vault Secrets User" \
--scope "${SCOPE}"マネージド ID は内部的には ServicePrincipal として扱われるため、principal-type は上記のようになります。Object ID を間違えると「付与はできたが効かない」状態になりやすいので、Purview アカウント画面で控えた値と一致しているか必ず確認してください。
Key Vault がアクセス ポリシー モデルの場合：Secrets の Get / List を付与
Key Vault がアクセス ポリシー モデルのままの場合、RBAC のロール割り当ては反映されません。Purview 側の接続テストが落ちる場合、まずはここが原因になっていないか確認してください。
設定のポイント
- 付与先：Purview アカウントのマネージド ID
- 付与するアクセス許可：Secrets – Get と Secrets – List
Azure ポータルでの具体手順
- Key Vault を開く
- アクセス ポリシー → 「作成」または「追加」
- シークレットの権限で Get と List をチェック
- プリンシパルの選択で Purview アカウントのマネージド ID を指定
- 保存
Azure CLI で付与する例
KV_NAME="kv-prod"
PURVIEW_MI_OBJECT_ID="yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
az keyvault set-policy
--name "${KV_NAME}"
--object-id "${PURVIEW_MI_OBJECT_ID}"
--secret-permissions get listGet だけ付与して List を付け忘れると、接続テストや裏側の解決処理で詰まることがあります。最小構成としては Get/List のセットで考えると安定します。
Error (20500) になりやすい原因と、切り分けの優先順位
ここからは、実際に Error (20500) が出る環境でよく当たるポイントを、優先順位が高い順に整理します。特に「付与先 ID」「権限モデル」「スコープ」の 3 点は、原因として非常に多いです。
| 原因 | 症状 | 確認場所 | 対処 |
|---|---|---|---|
| 付与先 ID の間違い | ロール/ポリシーは付いているのに Purview 接続テストだけ失敗 | Purview のマネージド ID（Object ID）と、Key Vault 側に付与した principal が一致しているか | Purview アカウントの マネージド ID を付与先にし直す |
| Key Vault の権限モデル不一致 | RBAC を付けても効かない／アクセス ポリシーを付けても効かない | Key Vault の アクセス構成 | RBAC モデルなら IAM、アクセス ポリシーなら Access policies で付与する |
| スコープが狭すぎる（特定シークレットのみ等） | 一部だけ成功/失敗、または接続テストで落ちる | ロール割り当てのスコープ | まずは Vault 全体スコープ に Key Vault Secrets User を付与して切り分ける |
| Key Vault のネットワーク制限 | 権限は正しいのに、アクセスが 403/タイムアウト相当で失敗 | Key Vault の「ネットワーク」設定、Private Endpoint、Firewall | 「信頼された Microsoft サービス」許可、または Private Endpoint/許可 IP の設計を見直す |
| シークレット名・形式の不整合 | Purview が参照できず失敗（名前違い、格納形式違い） | Purview の接続設定、Key Vault のシークレット名 | シークレット名の一致、値の形式（ユーザー名/パスワード等）を見直す |
ネットワーク制限で詰まるケース：Key Vault の「ファイアウォール」と Private Endpoint を確認
権限が正しくても、Key Vault のネットワーク制限でブロックされればシークレットは読めません。特に以下の構成では要注意です。
- Key Vault の「パブリック ネットワーク アクセス」を無効にしている
- Key Vault を「選択したネットワークのみ許可」にしている
- Purview 側で「Managed virtual network（マネージド仮想ネットワーク）」や managed private endpoint を利用している
まず見るべき Key Vault のネットワーク設定
- パブリック ネットワーク アクセス：有効/無効
- ファイアウォール：許可 IP が必要な構成になっていないか
- 信頼された Microsoft サービスからのアクセスを許可する：状況に応じて検討
- Private Endpoint：使うなら DNS 解決も含めて整合しているか
短時間での切り分けとしては、まず Key Vault 側で「どのアクセス経路を許可する方針か」を明確にし、Purview がそこに乗れているか確認します。セキュリティ要件が厳しい場合は、闇雲に設定を緩めるのではなく、Private Endpoint と DNS を前提に設計した方が長期的に安全です。
「シークレット単位にロールを付けたのにダメ」問題を理解する
RBAC モデルでは、Key Vault の子リソース（特定シークレット）に対してロールを付けられるケースがあります。しかし、Purview の処理が以下のような流れを含む場合、特定シークレットのみ権限を与えても不足します。
- 接続テスト時に「シークレットの存在確認」や「一覧」を行う
- シークレットの最新バージョン解決のためにメタ情報を参照する
- 接続 UI で候補を出すために List が必要になる
そのため、最初の安定解としては Vault 全体スコープで Key Vault Secrets User を付与し、成功を確認した上で必要ならスコープや権限を絞る、という順番がおすすめです（運用設計としてもミスが減ります）。
シークレット名・値の形式で失敗するケース：接続設定と「完全一致」を徹底
権限が合っていても、Purview 側が参照しているシークレット名や、期待している値の形式がズレていると失敗します。特に以下は見落としがちです。
シークレット名の確認ポイント
- 大文字/小文字、ハイフン、アンダースコアが一致しているか
- シークレット名に余計なスペースが入っていないか
- Purview 側で「シークレット名」として入力しているのが、URL 全体ではなく “名前だけ” を要求する UI なのか（画面仕様に合わせる）
値の形式の確認ポイント
- ユーザー名/パスワードを別シークレットで持つ必要があるのに、1つの JSON にしてしまっていないか
- 接続文字列を求めるのに、断片情報だけを入れていないか
- 末尾に改行が入っていて認証に失敗していないか（コピー時に混入することがあります）
「Purview が期待するフォーマット」は接続先（SQL、Storage、SAP、Snowflake 等）と UI に依存します。接続テストで落ちるときは、まずは最も単純な形式（プレーンな文字列、余計な改行なし） に寄せて確認すると原因を絞りやすいです。
チェックリスト：最短で成功まで持っていく確認順
現場で Error (20500) を最速で潰したい場合は、次の順番が効率的です。
| 順番 | チェック項目 | OK の状態 | NG のときのアクション |
|---|---|---|---|
| 1 | Purview のマネージド ID を特定できているか | Purview アカウントのマネージド ID（Object ID）が把握できている | Purview ポータルでマネージド ID をオンにし、Object ID を控える |
| 2 | Key Vault の権限モデルを把握しているか | RBAC かアクセス ポリシーかが判別できている | Key Vault のアクセス構成を確認し、モデルに合う方法で権限付与する |
| 3 | 必要権限が付いているか | RBAC: Key Vault Secrets User / Access policy: Secrets Get & List | 不足分を追加（最小権限で） |
| 4 | スコープが Vault 全体になっているか | Key Vault リソース（Vault）スコープに付与されている | まず Vault 全体に付与して成功確認→必要なら絞る |
| 5 | ネットワークで遮断されていないか | Purview から Key Vault に到達できる設計になっている | ファイアウォール、Private Endpoint、信頼されたサービス許可を見直す |
| 6 | シークレット名/値が正しいか | 名前が一致し、値の形式が接続に合っている | 名前完全一致、改行混入、JSON 化し過ぎ等を是正 |
トラブルシュートを強くする：ログで「権限」か「ネットワーク」かを見分ける
Error (20500) は Purview 側の UI では情報が薄いことがあります。そんなときは、Key Vault 側のログで「拒否されたのか」「到達できていないのか」を見分けると早いです。
Key Vault の診断設定を有効化する
- Key Vault → 診断設定（Diagnostic settings）
- Log Analytics ワークスペースへ送る（推奨）
- カテゴリは AuditEvent など、アクセスの監査に関わるものを有効にする
ログが取れるようになると、403（Forbidden）なら権限、タイムアウトや名前解決ならネットワーク、というように当たりが付けやすくなります。最短の復旧を狙うなら、環境の制約が許す範囲でログ取得を整備しておくのが効果的です。
運用で困らないための設計ヒント
一度接続テストが通っても、運用で「また 20500 が出た」を避けるには、権限と命名、ネットワークの設計を最初から固めておくのが重要です。
権限設計
- まずは Purview アカウントのマネージド ID を中心に権限を組む
- RBAC なら Key Vault Secrets User から始め、必要以上に Administrator を付けない
- 接続先ごとに Key Vault を分けるか、最低でも命名規約で混在を防ぐ
命名規約の例
- purview-接続先-用途-環境 のように、人が見て分かる規則にする
- 例：
pv-sql-prod-username/pv-sql-prod-password - ローテーション運用があるなら、シークレット名は固定し、バージョン更新で回す（UI が最新参照の設計だと管理が楽）
ネットワーク設計
- セキュリティ要件が高いなら、Key Vault は Private Endpoint 前提で設計し、DNS も含めて早期に検証する
- 「とりあえず信頼された Microsoft サービス許可」で通してしまうと、後で方針変更がつらくなることがある
まとめ：Error (20500) の多くは「ID」「権限モデル」「スコープ」のミスで説明できる
Purview から Azure Key Vault のシークレットを参照して接続テストが失敗する場合、まず疑うべきは次の 3 点です。
- 権限付与先が Purview アカウントのマネージド ID になっているか
- Key Vault の権限モデル（RBAC / アクセス ポリシー）に合った付与方法になっているか
- RBAC の場合、ロール割り当てスコープが Vault 全体 になっているか
この 3 点を正しく揃え、あわせて Key Vault のネットワーク制限とシークレットの命名/形式を確認すれば、Key Vault のシークレットを使った Purview の接続テストは成功する可能性が大きく上がります。
コメント