Azure Front Door と Azure Key Vault を組み合わせて証明書を管理しようとすると、「Key Vault は RBAC なのに、AFD から証明書一覧が見えない」「証明書追加でアルゴリズム不一致エラーになる」「Web App から Key Vault にアクセスできない」といった問題に頻繁にぶつかります。本記事では、Access Policies を使わず RBAC だけでこれらを解決するための考え方と、実際の設定手順・チェックポイントを詳しく解説します。
Azure Front Door から Key Vault の証明書にアクセスできない典型パターン
まず、よくあるトラブルのシナリオを整理します。次のような状態になっていないでしょうか。
- Key Vault は「RBAC モデル」で構成済み（Access Policies は無効）。
- Azure ポータルの Azure Front Door（AFD）ブレードで、[セキュリティ] > [シークレット] から Key Vault を選択。
- 証明書を選択しようとすると、「ポータルのログイン アカウントに List 権限を割り当ててください」 という趣旨のメッセージが出て一覧が表示されない。
- とりあえず Key Vault Reader をログインユーザーに付けてみたが、状況は変わらない。
- ようやく証明書を選べたと思ったら、AFD への追加時に “public key algorithm mismatch with signature algorithm” と表示され、証明書を取り込めない。
- さらに、同じ Key Vault を参照する Web App（App Service）側では「サービスにアクセス権がない」と怒られる。
どれもバラバラの事象に見えますが、根っこにあるのは Key Vault RBAC とネットワーク制限の理解不足 と、AFD が扱える証明書の要件 です。順番に整理していきます。
Key Vault の RBAC を正しく理解する：管理プレーンとデータプレーン
RBAC でつまずきやすいポイントは、管理プレーン（Management Plane） と データプレーン（Data Plane） が明確に分かれていることです。
- 管理プレーン：Key Vault リソース自体の作成・削除、設定変更、タグ、ネットワーク設定など。
- データプレーン：Key Vault に格納された 秘密鍵・証明書・シークレット の list/get/set など。
RBAC ロールも、どちら向きの権限かで役割が分かれています。代表的なロールを表にまとめると次の通りです。
| ロール名 | 対象プレーン | 主な権限 | 典型的な用途 |
|---|---|---|---|
| Owner / Contributor | 管理プレーン | Key Vault の作成・削除・設定変更が可能。中身のデータへは直接アクセスできない。 | インフラ管理者、IaC（Bicep / Terraform）でのリソース管理。 |
| Key Vault Reader | 管理プレーン | Key Vault の構成を閲覧のみ。証明書・シークレットの list/get は不可。 | 監査・設定レビュー用。 |
| Key Vault Secrets User | データプレーン | シークレットの list/get が可能。 | アプリケーションから接続文字列や API Key を読み取る。 |
| Key Vault Certificate User | データプレーン | 証明書オブジェクトの list/get が可能。 | AFD や App Service が TLS 証明書を取得する。 |
重要なのは、Key Vault Reader は「中身（証明書・シークレット）が見えるロールではない」という点です。AFD や Web App が必要としているのは データプレーンの list/get 権限 なので、Key Vault Certificate User などのデータプレーン ロールを割り当てる必要があります。
ポータルで「List 権限が必要」と表示される理由
AFD ブレードの [セキュリティ] > [シークレット] 画面で証明書一覧を取得しようとすると、次のようなメッセージが表示されることがあります。
- 「Key Vault に対する List 権限がありません」
- 「ポータルのログイン アカウントに List 権限を割り当ててください」
このメッセージのポイントは、Key Vault へ一覧取得を要求しているのは AFD ではなく、あなた自身のサインイン アカウントであるという点です。ポータルの UI が、あなたの権限で Key Vault の証明書一覧を list しようとし、その権限が不足しているためエラーになっています。
したがって、次の 2 つの主体に RBAC ロールを割り当てる必要があります。
| 主体 | 必要なロール | スコープ | 目的 |
|---|---|---|---|
| Azure ポータルにログインしているユーザー | Key Vault Certificate User | 対象の Key Vault（リソースレベル） | ポータルから証明書一覧を list / get できるようにする。 |
| 実際に Key Vault から証明書を取得するリソース (AFD / Web App のマネージド ID 等) | Key Vault Certificate User | 同じく対象の Key Vault | サービスが実行時に証明書を取得できるようにする。 |
ログインユーザーに Key Vault Certificate User を付与する手順
- Azure ポータルで対象の Key Vault を開く。
- 左側メニューから [アクセス制御 (IAM)] を選択。
- [ロールの割り当てを追加] をクリック。
- ロールの一覧から [Key Vault Certificate User] を選択し、[次へ] をクリック。
- [メンバーを選択] から、自分自身のユーザーアカウントを検索して追加。
- [確認および割り当て] をクリックして完了。
数分待ってから再度 AFD の画面で証明書一覧を開くと、エラーが消え、Key Vault 内の証明書が参照できるようになります。
Azure Front Door に必要な RBAC 設定：サービスにもロールを付ける
AFD から Key Vault の証明書を利用するには、AFD 自身（のマネージド ID やサービス プリンシパル）にも Key Vault Certificate User を付与する必要があります。UI で一覧が見えていても、実際に証明書を取り込むのは AFD 本体であり、AFD が Key Vault にアクセスできなければ運用時に失敗します。
ここでは、AFD 側にマネージド ID があるケースを例にします。
AFD の ID を確認する
- AFD（Standard/Premium）のリソースを開く。
- 左メニューから [ID]（もしくは [マネージド ID]）を選択。
- システム割り当て が有効になっていることを確認し、有効でなければ有効化する。
- 表示されている オブジェクト ID を控えておく（ロール割り当ての際に利用）。
AFD のマネージド ID に Key Vault Certificate User を付与
- 対象の Key Vault の [アクセス制御 (IAM)] を開く。
- [ロールの割り当てを追加] をクリック。
- ロールに [Key Vault Certificate User] を選択。
- [メンバーを選択] から [マネージド ID] を選択し、AFD リソースを検索して選択。
- [確認および割り当て] で完了。
スクリプトや IaC で管理している場合は、以下のように Azure CLI を用いてロール割り当てを自動化しておくと運用が安定します。
az role assignment create \
--assignee <AFD のプリンシパル ID> \
--role "Key Vault Certificate User" \
--scope <Key Vault のリソース ID>
ここまで設定すると、「見る人（あなた）」と「取得するサービス（AFD）」の両方に必要な権限が揃い、AFD からの証明書参照が RBAC のみで完結します。
Key Vault ネットワーク設定が原因で UI が失敗するケース
RBAC を正しく設定しても、Key Vault の ネットワーク制限（ファイアウォール） が原因で証明書一覧が取得できないことがあります。特に以下のような構成の場合にハマりがちです。
- Key Vault が 「プライベート エンドポイントのみ許可」 または 「選択したネットワーク（VNet/IP）のみ許可」 になっている。
- Azure ポータルからのアクセス（バックエンドの管理プレーン呼び出し）と、AFD / Web App からのアクセスの経路が異なる。
実際の事例では、次の操作を行ったことで UI 上のエラーが解消したケースがあります。
- Key Vault の [ネットワーク] 設定を開く。
- 一時的に 「すべてのネットワークを許可」 に変更して保存。
- 数分後、再度 「選択したネットワークのみ許可」 に戻し、必要な VNet / IP を再設定。
この操作によって、Key Vault のネットワーク設定が再適用され、ポータルからの一覧取得が正常に動作するようになりました。実運用では、恒久的に「すべてのネットワーク」を開くのではなく、一時的なリフレッシュ用途 として使い、最終的には 最小権限のネットワーク制限 に戻すことが重要です。
AFD で “public key algorithm mismatch with signature algorithm” が出る理由
RBAC とネットワークを整えても、AFD に証明書を追加する際に次のようなエラーに遭遇することがあります。
public key algorithm mismatch with signature algorithm
これは、証明書の 公開鍵アルゴリズム と 署名アルゴリズム の組み合わせが AFD のサポート範囲外であることを意味しています。特に問題になりやすいのが、楕円曲線暗号（EC/ECDSA）証明書を使っているケース です。
AFD は現時点で RSA ベースの証明書 を前提としており、EC/ECDSA 証明書はサポートされていません。そのため、証明書の種類によっては、Key Vault には登録できても AFD へのバインド時に上記のエラーとなります。
解決策：RSA 証明書で再発行する
対処方法はシンプルで、AFD で利用する TLS 証明書を RSA 方式で再発行 することです。
- 証明書発行時に、キータイプ：RSA、鍵長：2048 ビット以上 を選択する。
- ACME / Let’s Encrypt 連携や証明書ベンダーの管理画面で、ECC を選択していないか確認する。
- Key Vault に登録済みの ECDSA 証明書は AFD 用には使えないため、RSA 証明書を別オブジェクトとして登録する。
AFD での TLS ポリシーやセキュリティ要件を踏まえつつ、「AFD 用は RSA 前提」 という運用ポリシーを設計時点で明確にしておくと、後々のトラブルを防止できます。
Web App（App Service）から Key Vault 証明書を参照する際の権限設定
同じ Key Vault を Web App からも利用している場合、次のようなエラーに遭遇することがあります。
- 「Key Vault へのアクセス権がありません」
- HTTP 403 / Forbidden が返却される。
これも原因はシンプルで、Web App のマネージド ID やサービス プリンシパルに Key Vault のデータプレーンロールが付与されていないためです。AFD と同様に、アプリケーション側の ID に Key Vault Certificate User（証明書）や Key Vault Secrets User（シークレット）を付与します。
Web App のマネージド ID を有効化
- 対象の Web App を開き、左メニューから [ID] を選択。
- システム割り当て を [オン] にして保存。
- 表示される オブジェクト ID を控えておく。
Key Vault 側でロールを付与
- Key Vault の [アクセス制御 (IAM)] を開く。
- [ロールの割り当てを追加] をクリック。
- [Key Vault Certificate User]（証明書を使う場合）や [Key Vault Secrets User]（シークレットを使う場合）を選択。
- [メンバーを選択] から [マネージド ID] を選び、先ほどの Web App を検索して選択。
- [確認および割り当て] で完了。
アプリ側では、環境変数やアプリ設定で @Microsoft.KeyVault(SecretUri=...) 形式を使うことで Key Vault の値を参照できますが、その裏側で動いているのは マネージド ID + RBAC ロール です。どの ID にどのロールを付けたかを、必ずドキュメント化しておきましょう。
誰にどのロールを付けるか：設計の早見表
ここまでの内容を、「誰に」「どのロールを」付与すべきかという観点でまとめると次のようになります。
| 主体 | 用途 | 推奨ロール（Key Vault スコープ） | 備考 |
|---|---|---|---|
| インフラ管理者 | Key Vault の作成・設定・監査 | Contributor + Key Vault Reader など | 通常はデータプレーン ロールを付けず、必要最小限に。 |
| 運用担当者（証明書を確認する人） | ポータルで証明書内容や期限を確認 | Key Vault Certificate User | データプレーン専用の閲覧ロール。 |
| Azure Front Door | Key Vault から TLS 証明書を取得し、エンドポイントにバインド | Key Vault Certificate User | AFD のマネージド ID / サービス プリンシパルを対象に割り当てる。 |
| Web App / App Service | アプリから証明書やシークレットを読み取る | 証明書: Key Vault Certificate User シークレット: Key Vault Secrets User | システム割り当て / ユーザー割り当てマネージド ID を利用する。 |
詳細チェックリスト：設定漏れを一つずつ潰す
実際にトラブルシュートする際は、次のチェックリストに沿って確認すると整理しやすくなります。
| カテゴリ | 確認項目 | ポイント |
|---|---|---|
| Key Vault モード | Key Vault が RBAC モデルになっているか | Access Policies と RBAC を混在させない。新規構築では RBAC 推奨。 |
| ユーザー権限 | ログインユーザーに Key Vault Certificate User が付いているか | UI の一覧取得はあなたの権限で行われる。 |
| AFD 権限 | AFD の ID に Key Vault Certificate User が付いているか | マネージド ID / SPN を間違えないこと。 |
| Web App 権限 | Web App のマネージド ID に適切なロールがあるか | 証明書とシークレットでロールが違う点に注意。 |
| ネットワーク | Key Vault ファイアウォール設定の整合 | 必要に応じて「すべてのネットワークを許可」→元に戻す、でリフレッシュ。 |
| 証明書種別 | AFD 用証明書が RSA で発行されているか | EC/ECDSA は AFD では使えない。RSA 2048 以上を基本とする。 |
| 動作確認 | AFD / Web App から実際に証明書・シークレットを取得できるか | ポータルのテストだけでなく、実際の動作ログも確認する。 |
よくある誤解とつまずきポイントを詳しく解説
「Key Vault Reader を付けたのに中身が見えない」
Key Vault Reader は名前から「中身が読めそう」な印象を与えますが、実際には 管理プレーン専用の閲覧ロール です。Key Vault の構成情報（SKU、エンドポイント、ネットワーク設定など）は閲覧できますが、証明書・シークレットの list/get は一切できません。
証明書やシークレットの一覧を取得したい場合は、必ず Key Vault Certificate User / Key Vault Secrets User などのデータプレーンロールを併用してください。
「ポータルのメッセージが『ログイン アカウントに List を…』と言っている意味」
これは、AFD や Web App の権限ではなく、あくまで あなた自身のサインイン アカウント に対する要求です。実際の運用では、次の 2 段階に分けて考えると整理しやすくなります。
- 設計・運用者のための閲覧権限：ポータルで Key Vault の証明書内容を確認するためのロール（Certificate User）。
- サービスのための実行時権限：AFD / Web App が実行時に証明書・シークレットを取得するためのロール。
この 2 つを混同して「サービス側にだけロールを付けたから大丈夫」と考えると、UI での操作ができずにハマる原因になります。
「ロールを付けたのに反映されない」
RBAC ロールの変更は即時反映されることもありますが、実際には数分程度の伝播遅延が発生します。また、Key Vault のネットワーク設定が不整合な状態になっていると、権限は正しくても UI 側でエラーになることがあります。
そのため、次の順番で切り分けるのがおすすめです。
- ロール割り当てが正しいプリンシパルに付いているかを再確認。
- 数分待ってポータルをリロード。
- Key Vault のネットワーク設定を見直し、一時的なリフレッシュ（すべて許可 → 元に戻す）を試す。
- それでもダメな場合は、Activity Log や診断ログで 403 / ネットワーク関連のエラーを確認。
「Web App / AFD 本体にも権限が必要」という当たり前を忘れる
実際に Key Vault から証明書・シークレットを取得するのは、人ではなく サービス（AFD / Web App） です。そのため、どれだけ人にロールを付けても、サービス側の ID にロールを付け忘れていれば動作しません。
特に、ステージング／本番など複数の Web App を使っている場合は、それぞれのマネージド ID に対してロールが付いているか を環境単位でチェックすることが重要です。
再発防止のための設計パターンと運用のコツ
同じ問題を繰り返さないためには、最初の設計段階で 役割の分離 と ポリシー化 を行っておくことが効果的です。
人とサービスでロールを分ける
- 人（運用者）は 閲覧専用のデータプレーンロール（Key Vault Certificate User / Secrets User）を付ける。
- サービス（AFD / Web App）には 実行時に必要な最小権限のみ を付与し、できれば環境ごとに ID を分離する。
- 管理プレーンの権限（Contributor など）は、できるだけ限定されたメンバーに絞る。
証明書要件を先に固定しておく
- 「AFD で使う証明書は RSA のみ」「鍵長は 2048 以上」といったルールをチーム内で共有する。
- 証明書ベンダーや ACME クライアントの設定テンプレートとして保存し、毎回同じ条件で発行できるようにする。
- Key Vault 内のオブジェクト命名規則を決め、RSA / ECC の区別が名前で分かるようにする（例：
myapp-tls-rsa）。
変更手順を標準化し、チェックリスト化する
証明書や Key Vault の設定を変更する際は、次の流れを標準手順としてドキュメント化しておくと安全です。
- RBAC の確認：ログインユーザーと対象サービスに必要なロールが付いているか。
- ネットワーク設定の確認：Key Vault のファイアウォールと Private Endpoint の状態。
- 証明書種別の確認：AFD 用の場合は RSA かどうか。
- UI でのテスト：AFD / Web App から証明書を選択・参照できるか。
- 本番リリース：切替後のログ・メトリクス監視。
この一連の流れをチェックリストとして運用チームに共有しておけば、「どこから見直せばよいか分からない」という事態を防げます。
まとめ：AFD × Key Vault をシンプルに動かすポイント
Azure Front Door と Key Vault の連携は、理解してしまえば難しくありませんが、RBAC とネットワーク、そして証明書要件が絡むため、一箇所でも誤ると「証明書が見えない」「バインドできない」「アプリからアクセスできない」といったトラブルになりがちです。
本記事のポイントをあらためて整理すると、次のようになります。
- ポータルの UI で証明書一覧を引くのは、あなた自身のアカウント。
Key Vault スコープで Key Vault Certificate User を自分に割り当てる。 - 実際に証明書を取得するのは AFD や Web App。
それぞれのマネージド ID / サービス プリンシパルにも Key Vault Certificate User（および必要なら Secrets User）を割り当てる。 - Key Vault のファイアウォール設定が UI の一覧取得を妨げることがある。
必要に応じて「すべてのネットワークを許可」→元に戻す、で設定を再適用する。 - AFD は ECDSA 証明書をサポートしない。
AFD 用の証明書は RSA（2048 ビット以上） で発行し、「public key algorithm mismatch」エラーを回避する。 - Access Policies に頼らず、RBAC だけで完結する設計 にしておくと、役割分離と監査がしやすくなる。
これらのポイントを押さえておけば、Azure Front Door と Key Vault の連携は、セキュアかつ運用しやすい形で構成できます。既存環境で問題が出ている場合も、この記事のチェックリストに沿って一つずつ確認していけば、原因の切り分けと再発防止策の整理に役立つはずです。
コメント