Microsoft Entra の PIM（Privileged Identity Management）を触っていると、「サービス プリンシパルにも JIT で権限を付けられないか？」という疑問が必ず出てきます。本記事では、現時点の仕様で何ができて何ができないのか、そして代わりにどのようなアーキテクチャを取るべきかを、実運用に落とし込めるレベルで整理します。
サービス プリンシパルに PIM は使えるのか？結論から整理
まず結論です。
- サービス プリンシパル（アプリケーション ID）やマネージド IDに対して、PIM の「適格（Eligible）割り当て」を直接付けることはできません。
- そのため、「必要なときだけサービス プリンシパルのロールを昇格させる JIT 運用」は現状の PIM では実現できません。
Microsoft の公式 Q&A でも、「PIM はサービス プリンシパルに対して PIM-eligible ロールを直接割り当てることはサポートしていない」と明言されています。
また、Azure RBAC と PIM の統合に関する解説では、Azure リソース ロールの PIM 対象はユーザー（および人がメンバーのグループ）であり、アプリケーション / サービス プリンシパル / マネージド ID は Eligible ロールの対象外であることが説明されています。
ここで混乱しやすいポイントをまとめると次のとおりです。
| 対象 | PIM の Eligible/JIT 対象？ | 備考 |
|---|---|---|
| ユーザー アカウント | 〇 | MFA・承認・理由入力などの JIT ワークフローが利用可能 |
| PIM 対象グループ（ロール割り当て可能グループ） | 〇（グループ メンバーシップに対して） | 人がグループに JIT 参加することで間接的にロールを得る |
| サービス プリンシパル（アプリ登録） | × | Eligible ロール割り当てや JIT 昇格は不可。Active な恒久ロールのみ |
| マネージド ID（システム/ユーザー割り当て） | × | 同じく PIM の JIT 対象外。RBAC の恒久ロールのみ |
| Agent ID（エージェント ID） | 一部のシナリオで可 | Entra Agent Platform 向けの新しい概念で、一般的なサービス プリンシパルとは別枠 |
PIM が設計上ターゲットにしているのは「人の特権」
PIM は、もともと 「人間の管理者に対して、時間制限付き・承認ベースで特権ロールを付ける」ためのサービスとして設計されています。Microsoft 公式ドキュメントでも、PIM は Microsoft Entra や Azure、Microsoft 365 などの重要なリソースに対して、時間ベース・承認ベースのロールアクティベーションを提供し、過剰な特権を抑制する目的であると説明されています。
そのため、PIM が前提としているのは次のようなフローです。
- 人がサインインする
- MFA や承認フローを通過する
- 一定時間だけロールをアクティブにする
- 有効期限切れ or 人が明示的にロールを解除する
一方、サービス プリンシパルやマネージド ID は「サインインしない / MFA できない / 承認画面に答えられない」タイプの ID です。この「インタラクティブ操作ができない」という根本的な性質により、PIM の JIT ワークフローに乗せることがそもそもできない、というのが仕様上の理由になります。
PIM で割り当てられるロールとプリンシパルの関係
Microsoft Entra ロールや Azure リソース ロールは、通常、ユーザー・グループ・一部のエージェント ID（agent identities）に割り当てることができます。PIM を有効にすると、これらのロール割り当てに対して、「Active（恒久）」「Eligible（適格）」といった属性を付与し、JIT でアクティブ化できるようになります。
しかし、Azure RBAC 側の PIM 統合の記事や Q&A に繰り返し記載されているように、Eligible ロールを作成できるのは「ユーザー（およびグループ）」のみであり、サービス プリンシパルやマネージド ID は対象外です。
つまり：
- PIM = 「人間（＋その人が入るグループ）」の特権コントロール
- サービス プリンシパル・マネージド ID = ワークロード ID（アプリ向け ID） であり、PIM の JIT 対象ではない
という役割分担を理解しておく必要があります。
「PIM for Groups を経由すればアプリも JIT できるのでは？」という誤解
よくある誤解の 1 つが、PIM for Groups を使えば、グループ メンバーとしてのサービス プリンシパルも JIT で権限を得られるのでは？という考え方です。
しかし、PIM for Groups の JIT 対象はあくまで 「人がそのグループに一時的に参加する」 というメンバーシップ操作であり、サービス プリンシパルが「今から 1 時間だけこのグループに入りたい」と自分でリクエストする仕組みは存在しません。
- サービス プリンシパルをグループ メンバーにしておけば、グループに割り当てたロールを恒久的に持つことはできます。
- ただし、そのメンバーシップを JIT でオン・オフする API や UI は提供されていません。
したがって、PIM for Groups を経由してもサービス プリンシパルの JIT 昇格は実現できない、という整理になります。
現実的な代替パターン：4 つのアプローチ
「PIM でサービス プリンシパルを JIT できないなら、どう守ればよいのか？」という問いに対する、現実的なパターンを 4 つに分けて整理します。
1. 人に PIM を適用し、サービス プリンシパルのロール付与／剥奪を人がトリガーする
もっとも素直なパターンは、「権限操作をする人」だけを PIM で JIT 化し、その人が必要に応じてサービス プリンシパルへのロール割り当てをオン・オフするやり方です。
運用フロー例
- 管理者 A は、PIM で「Privileged Role Administrator」や「User Access Administrator」などに Eligible として登録されている。
- 作業の直前に、管理者 A が PIM でロールを Activate（MFA や承認付き）。
- 有効な権限を使って、サービス プリンシパルに対して最小スコープのロール（例：特定リソース グループの
Contributor）を付与する。 - 作業が終わり次第、管理者 A（もしくは自動化スクリプト）がサービス プリンシパルからロールを削除する。
- PIM の有効時間が切れたら、管理者 A も特権を失う。
このとき、「手作業だと漏れそう」という懸念が出るため、スクリプトや IaC（Bicep/ARM/Terraform）でロール付与～削除までを一括実行するのがおすすめです。
# 例: Azure CLI によるロール付与・削除（擬似コード）
# 事前に PIM で昇格済みの人間アカウントでログインしている前提
# 一時的にロールを付与
az role assignment create \
--assignee <SERVICE_PRINCIPAL_ID> \
--role "Contributor" \
--scope "/subscriptions/<SUB_ID>/resourceGroups/<RG_NAME>"
# （ここで自動化ジョブを実行）
# 作業完了後すぐにロールを剥奪
az role assignment delete \
--assignee <SERVICE_PRINCIPAL_ID> \
--role "Contributor" \
--scope "/subscriptions/<SUB_ID>/resourceGroups/<RG_NAME>"
このようなスクリプトを、「PIM で昇格した人だけが実行できるパイプライン」に載せると、人的ミスもかなり軽減できます。
| 観点 | メリット | デメリット / 注意点 |
|---|---|---|
| セキュリティ | 人の特権は JIT。サービス プリンシパルのロールも作業時間中だけ有効にできる | スクリプトの運用をちゃんと標準化しないと「消し忘れ」が発生しうる |
| 実装難易度 | 単純。既存のロール割り当てスクリプトを流用可能 | PIM 昇格 → スクリプト実行という二段階のオペレーションが必要 |
| 可監査性 | PIM のアクティビティ ログ + ロール割り当ての監査ログでトレーサビリティが高い | ロール付与・削除の自動化パイプラインにもログ保存を仕込むとベター |
2. Azure 上のワークロードなら「マネージド ID」を最優先で使う
Azure VM / App Service / Functions / AKS など、Azure 上で動くワークロードであれば、サービス プリンシパルではなくマネージド ID を使うのが、Microsoft 公式でも推奨されているベストプラクティスです。
- マネージド ID は Azure リソースに紐づく ID で、資格情報（シークレットや証明書）の発行・ローテーションを Azure 側が完全に管理します。
- コードや設定にクライアント シークレットを書き込む必要がなく、漏えいリスクを大幅に低減できます。
もちろん、マネージド ID 自体に対しても PIM JIT はできませんが、そもそもシークレット管理リスクをほぼゼロにできるため、「長期シークレットを持つサービス プリンシパルに PIM をかけたい」という動機の大部分を解消できます。
| 項目 | サービス プリンシパル | マネージド ID |
|---|---|---|
| 資格情報の管理 | シークレット／証明書を自分で発行・保管・ローテーションする必要 | Azure が自動管理。アプリ側はトークン取得 API を呼ぶだけ |
| 漏えいリスク | コード／設定ファイル／Git リポジトリ等に埋め込みがち | 資格情報を持たないため、漏えい面積が小さい |
| スコープ設計 | 任意のリソースに対してロール割り当て可能 | 基本的にはマネージド ID を持つリソースからのアクセス用途で利用 |
| PIM との関係 | PIM Eligible は不可。人に PIM をかけてロール割り当てを管理する | 同上。ただしシークレット管理が不要な分、運用がシンプル |
マネージド ID を使う場合も、どのリソースにどのロールを付けるかは人間が決める必要があります。ここに PIM を組み合わせて、
- 「マネージド ID に新しいロールを付けられるのは、PIM で昇格した管理者だけ」
- 「そのロールは定期的にアクセス レビューの対象にする」
といったガバナンスを効かせると、よりセキュアな運用になります。
3. ワークロード ID フェデレーション（OIDC）で CI/CD を「シークレットレス」化
GitHub Actions や Azure DevOps、その他の CI/CD プラットフォームから Azure にデプロイする場合は、ワークロード ID フェデレーション（OIDC）を使うことで「GitHub にシークレットを置かない運用」が可能です。
概要は次のとおりです。
- Microsoft Entra ID で、ユーザー割り当てマネージド IDもしくはアプリ登録を作成する。
- その ID に対して、外部 IdP（例：GitHub OIDC）との「フェデレーテッド資格情報」を設定する。
- GitHub Actions のワークフローで
azure/loginなどのアクションを用い、OIDC トークンを使って Entra ID からアクセストークンを取得する。 - 取得したトークンを用いて、Azure リソースへデプロイを実行する。
この方式では、CI/CD 側にクライアント シークレットを保存する必要がなく、フェデレーテッド資格情報に記載した条件（対象リポジトリ・ブランチ・環境など）を満たすトークンだけを信頼するため、「どのリポジトリからでも同じクレデンシャルが使える」といったリスクを避けられます。
ここでも PIM は直接ワークロード ID を JIT にはできませんが、
- ワークロード ID（アプリ / マネージド ID）にどの RBAC ロールを付けるかを決める管理者に PIM を適用
- フェデレーテッド資格情報の設定変更権限を PIM 管理下に置く
といった形で、「ワークロード ID を管理する人」を PIM で守るのが現実的なパターンです。
4. どうしても恒久権限が必要なサービス プリンシパルのベストプラクティス
レガシーなアプリケーションや、どうしても Azure 外のシステムから接続しなければならないなど、サービス プリンシパルに恒久的な権限を持たせざるを得ないケースもあります。その場合は、以下のようなベストプラクティスを徹底することで、リスクを一定レベルまで抑え込むことができます。
① 最小権限・最小スコープ
- サブスクリプション全体に
Ownerを付けるのではなく、可能な限りリソース グループや個別リソース単位で必要最小のロール（例：Storage Blob Data Contributor）を付与。 - 「読み取り専用」と「書き込み」のロールを分離し、アプリが本当に必要な方だけを付ける。
② 短命な資格情報 + Key Vault での保護
- クライアント シークレットではなく、短期間有効な証明書ベース認証を優先する。
- 証明書の秘密鍵は Azure Key Vault などに格納し、アプリからは Key Vault 経由で参照（この際の認証はマネージド ID などを利用）。
- 証明書の有効期限は 1 年以上に伸ばさず、自動ローテーションの仕組みを用意する。
③ Workload ID ライセンスと条件付きアクセスの活用
Microsoft Entra には、「Microsoft Entra Workload ID」ライセンスが追加されており、アプリケーション ID やサービス プリンシパルに対する高度な保護・監査機能を提供します。
- ワークロード ID 単位でライセンスを割り当て、異常なサインインやリスク検知を行う。
- 条件付きアクセスをワークロード ID にも適用し、許可された場所・ネットワークからのアクセスだけを認めるといった制御を行う。
④ 監査ログとアクセス レビュー
- サービス プリンシパルのロール割り当て変更は必ず監査ログを確認し、誰が・いつ・どの権限を付けたかが追跡できるようにする。
- Privileged Identity Management や Entra ID Governance のアクセス レビュー機能を使って、サービス プリンシパルに付いているロールが本当に必要かを定期的に棚卸しする。
| 対策 | 目的 | ポイント |
|---|---|---|
| 最小スコープの RBAC 設計 | 侵害時の被害範囲を狭める | 「サブスクリプション全体の Owner」は最後の最後の手段 |
| 短命な証明書 + Key Vault | 資格情報の漏えいリスクを低減 | 自動ローテーションと失効テストを忘れない |
| Workload ID ライセンス + CA | ワークロード ID 自体の保護 | 高リスク検知やサインイン制限を有効化 |
| アクセス レビュー | 不要な権限の除去 | レビュー対象にサービス プリンシパルも含める |
具体的な設計例でイメージする
例1：GitHub Actions から Terraform で Azure を操作する
よくあるケースとして、「GitHub Actions から Terraform を使って Azure の構成管理を行う」パターンを考えてみます。
悪い例（やりがちなパターン）
- Entra ID にアプリ登録を作成し、サービス プリンシパルにサブスクリプション全体の
Ownerを付与。 - クライアント シークレットを発行し、GitHub のシークレットに保存。
- 全ての Terraform 実行でこのクレデンシャルを使い回す。
この場合、シークレットが漏えいすれば サブスクリプション全体を破壊できる万能鍵 を外部にばらまいているのと同じです。
推奨パターン
- Terraform 用のユーザー割り当てマネージド ID もしくはアプリ登録を作成。
- その ID に対して、ワークロード ID フェデレーション（GitHub OIDC）を設定。
- ロールは、対象のリソース グループ単位に
Contributorなど必要最小限を付与。 - ロールの付与・変更を行う管理者は PIM で JIT 昇格させる。
こうすることで、
- GitHub には一切シークレットを保存しなくてよい
- 使える権限は特定のリポジトリ／ブランチのみに限定
- ロール設計を変更できるのは PIM によって守られた管理者のみ
という構成になり、「サービス プリンシパルに PIM をかけたい」と考えなくても、十分にリスクを抑えた運用が実現できます。
例2：運用担当者が一時的に自動化バッチ用サービス プリンシパルの権限を引き上げる
もう少しレガシーな例として、オンプレ サーバー上のバッチから Azure に対してメンテナンス操作を行う、というシナリオを考えます。
- 平常時、サービス プリンシパルには 読み取り専用のロールのみが付与されている。
- メンテナンス日だけ、運用担当者が PIM で昇格し、特定 RG に対して
Contributorを一時的に付与。 - メンテナンス バッチを実行し、完了後にロールを削除。
- この一連の操作を PowerShell / CLI スクリプト化し、PIM 昇格した担当者のみが実行できるようにする。
ここでも PIM はあくまで 「人間の権限」に対して働きますが、人をハブにしてサービス プリンシパルの権限をオン・オフすることで、実質的に「JIT っぽい運用」を実現できます。
将来的な仕様変更の可能性について
Entra の世界では、近年 Workload ID や Agent ID など、ワークロード向けの ID 管理・保護機能が急速に拡充しています。
今後、サービス プリンシパルやマネージド ID 自体に対して、よりきめ細かい JIT や承認フローが提供される可能性はゼロではありませんが、2025 年 12 月時点の公式ドキュメントと Q&A では、「サービス プリンシパルに PIM の Eligible ロールを直接割り当てることはできない」と明確に示され続けています。
そのため、今設計するシステムでは、
- PIM は「人」に対する JITのために使う
- ワークロード ID には、マネージド ID・ワークロード ID フェデレーション・最小権限・短命資格情報・監査とレビューの組み合わせで防御を張る
という前提でアーキテクチャを考えておくのが現実的です。
まとめ：サービス プリンシパルに PIM は使えないが、守る方法はある
最後に、本記事のポイントを整理します。
- サービス プリンシパルやマネージド ID には、PIM の「Eligible」割り当てや JIT 昇格は現状サポートされていない。
- PIM はあくまで 「人の特権ロール」を時間制限・承認・MFA 付きで管理するためのサービスである。
- 代わりにとるべきアプローチは次の 4 つ：
- 人に PIM をかけ、サービス プリンシパルへのロール付与・剥奪を人（＋自動化）で制御する。
- Azure 上のワークロードにはマネージド ID を優先し、そもそもシークレットを持たない構成にする。
- ワークロード ID フェデレーション（OIDC）で CI/CD をシークレットレスにし、信頼できるリポジトリ・ブランチからだけアクセスさせる。
- どうしても恒久権限が必要なサービス プリンシパルには、最小権限・短命な証明書・Key Vault 保管・Workload ID ライセンス・アクセス レビューを組み合わせる。
- 「アプリに直接 PIM をかける」のではなく、「アプリを管理する人とプロセス」を PIM で固めるのが、現行仕様におけるベストプラクティス。
サービス プリンシパルに PIM をそのまま適用できないことは制約に見えますが、その分、人・プロセス・ワークロード ID の三つ巴で防御線を重ねる設計が求められているとも言えます。この記事をベースに、自社の運用に合った組み合わせを検討してみてください。
コメント