Azure Policy のアイデンティティに基づく適用除外を検証し隊

本記事は GitHub Copilot を活用して作成しています。

はじめに

Azure Policy の Deny 効果は、組織のルールに合わないリソース作成や更新を拒否するための強力なガードレールです。
一方で、承認済みの管理者や自動化用 ID に限って、一時的にポリシーの強制を回避させたい場合があります。

Azure Policy の適用除外では、リソースセレクターの userPrincipalId と groupPrincipalId を使い、Azure Resource Manager へ要求した ID に基づいて適用除外を制御できます。

本記事では、組み込みポリシー Allowed virtual machine size SKUs を使い、次の動作を検証します。

通常のユーザーが許可されていない VM SKU を作成すると拒否される
userPrincipalId で指定したユーザーは同じ VM SKU を作成できる
groupPrincipalId で指定したグループの直接所属ユーザーは同じ VM SKU を作成できる

要約

アイデンティティベースの適用除外は、対象 VM のマネージド ID ではなく、Azure Resource Manager へ要求した主体を評価します
userPrincipalId はユーザー、サービスプリンシパル、マネージド ID を指定でき、groupPrincipalId はセキュリティグループを指定できます
適用除外は Azure Policy の強制を外すだけで、Azure RBAC の権限は付与しません
グループ所属の変更後は、反映待ちと再試験が必要です
適用除外は最小スコープ、短い有効期限、承認情報、定期レビューを組み合わせて運用します

適用除外とスコープ除外の違い

ポリシー割り当ての 除外スコープ (notScopes) と 適用除外 (policyExemptions) は目的が異なります。

項目	除外スコープ	適用除外
評価	対象外となり評価されない	適用除外として追跡される
有効期限	なし	`expiresOn` を設定可能
承認情報	専用のメタデータなし	要求者、承認者、チケットなどを記録可能
イニシアティブ	スコープ単位で除外	定義参照 ID 単位の適用除外が可能
ID による制御	できない	`userPrincipalId`、`groupPrincipalId` を利用可能

一時的または承認済みの例外を記録し、コンプライアンス上も追跡したい場合は、適用除外が適しています。

アイデンティティベースの適用除外

適用除外の resourceSelectors では、次の ID セレクターがサポートされています。

kind	対象
`userPrincipalId`	ユーザー、サービスプリンシパル、マネージド ID のオブジェクト ID
`groupPrincipalId`	Microsoft Entra ID セキュリティグループのオブジェクト ID

重要なのは、評価対象がリソースに設定された ID ではなく、作成または更新要求を送信した主体である点です。

flowchart LR
    U[ユーザーまたは<br>サービス プリンシパル] -->|ARM 要求| P[Azure Resource Manager]
    P --> E{Policy 適用除外の<br>ID セレクターに一致するか}
    E -->|一致| R{Azure RBAC 権限が<br>あるか}
    E -->|不一致| D[Azure Policy の<br>Deny を評価]
    R -->|あり| A[要求を処理]
    R -->|なし| F[AuthorizationFailed]
    D -->|非準拠| X[RequestDisallowedByPolicy]

    classDef identity fill:#7fba00,color:#fff,stroke:none;
    classDef azure fill:#0078d4,color:#fff,stroke:none;
    classDef decision fill:#ffb900,color:#222,stroke:none;
    classDef deny fill:#e81123,color:#fff,stroke:none;

    class U identity;
    class P,A azure;
    class E,R decision;
    class D,F,X deny;

たとえば、VM に system-assigned managed identity を有効化しても、その ID が userPrincipalId に指定されているだけでは、Portal から VM を作成したユーザーの要求は免除されません。

検証環境

項目	設定
検証日	2026 年 8 月 20 日
スコープ	検証専用リソースグループ
リージョン	Southeast Asia (`southeastasia`)（SKU とクォータを事前確認）
ポリシー	Allowed virtual machine size SKUs
効果	Deny
許可 SKU	`Standard_D2s_v5`、`Standard_D4s_v5`
禁止 SKU	`Standard_D2s_v3`、`Standard_D4s_v3`
group の対象	セキュリティグループへの直接所属のみ
VM ネットワーク	Public IP なし、不要な受信ポートなし
適用除外カテゴリ	Waiver
有効期限	検証終了予定時刻までの短い期限

SKU の提供状況や vCPU クォータ不足による失敗を Policy Deny と誤認しないよう、許可 SKU と禁止 SKU はどちらも対象リージョンで作成可能なものを選びます。

必要な ID

検証管理者兼 user 免除対象ユーザー
比較用ユーザー兼 group 追加・削除対象ユーザー
group 免除の検証用セキュリティグループ

必要なユーザーは 2 ID に集約します。両方へ同じ VM 作成権限を付与し、各ケースの前後で
適用除外とグループ所属の状態を記録して、前のケースの状態を持ち越さないようにします。

必要なアクセス許可

適用除外の作成者には、少なくとも次の両方が必要です。

適用除外を作成するスコープの Microsoft.Authorization/policyExemptions/write
対象のポリシー割り当てに対する Microsoft.Authorization/policyAssignments/exempt/action

一方、免除対象ユーザーには VM、ディスク、NIC などを作成する Azure RBAC 権限が別途必要です。

Policy 適用除外は RBAC の代替ではありません。適用除外の対象になっても権限昇格は発生せず、RBAC が不足する要求は AuthorizationFailed になります。

ざっくり手順

検証用リソースグループとテスト ID を準備する
Allowed virtual machine size SKUs を割り当てる
適用除外なしで許可 SKU と禁止 SKU の動作を確認する
userPrincipalId の適用除外を作成して確認する
groupPrincipalId の適用除外を作成して確認する
グループ所属の追加・削除と反映を確認する
RBAC、有効期限、適用除外削除後の動作を補足する
検証リソースを削除する

手順 1: 検証環境を準備する

Azure Portal で検証専用リソースグループと Microsoft Entra ID セキュリティグループを作成します。
本番環境のリソースを含むスコープにはポリシーを割り当てません。

手順 2: ポリシーを割り当てる

Azure Portal で ポリシー > 定義を開き、Allowed virtual machine size SKUs を検索します。
検証用リソースグループをスコープにして割り当て、許可する VM SKU を 1 つ以上指定します。

割り当てスコープ: 検証用リソースグループ
除外: なし
Enforcement mode: Enabled
パラメーター: 許可 SKU のみ

今回は割り当てスコープに検証用リソースグループを指定し、除外は設定しません。

Allowed virtual machine size SKUs の割り当てで検証用リソースグループを指定し、除外を設定していない画面 — **ポリシー割り当ての基本情報**: 検証用リソースグループをスコープに指定し、除外は設定しない

パラメーターでは、許可する VM SKU として Standard_D2s_v5 と Standard_D4s_v5 を選択します。

Allowed virtual machine size SKUs のパラメーターで Standard_D2s_v5 と Standard_D4s_v5 を選択した画面 — **許可する VM SKU**: Standard_D2s_v5 と Standard_D4s_v5 を許可する

割り当て直後は反映に時間がかかることがあります。禁止 SKU の作成が明確に Policy Deny になるまで待ってから、適用除外の比較へ進みます。

手順 3: 適用除外なしの基準を確認する

同じ Azure RBAC 権限を持つ非免除ユーザーで、次の 2 ケースを確認します。

許可 SKU の VM を作成し、成功すること
禁止 SKU の VM を作成し、RequestDisallowedByPolicy で拒否されること

許可 SKU の Standard_D2s_v5 を指定した場合は、検証に成功して VM を作成できます。

Azure Portal の仮想マシン作成画面で Standard_D2s_v5 を選択し、検証に成功している画面 — **許可 SKU の VM 作成**: Standard_D2s_v5 はポリシーで許可されているため検証に成功する

許可リストに含めていない Standard_D2s_v3 を指定した場合は、
RequestDisallowedByPolicy によって VM 作成が拒否されます。

Azure Portal の仮想マシン作成画面で Standard_D2s_v3 を選択し、RequestDisallowedByPolicy が表示された画面 — **禁止 SKU の VM 作成拒否**: Standard_D2s_v3 は許可リストに含まれないため Azure Policy に拒否される

手順 4: userPrincipalId の適用除外を作成する

適用除外は検証用リソースグループを対象に作成します。
表示名、説明、有効期限、要求者、承認者、チケットなど、後から判断できる情報を記録します。

Azure Portal で次のように作成します。

ポリシー > 割り当て を開く
手順 2 で作成した Allowed virtual machine size SKUs のポリシー割り当てを開く
ポリシー割り当ての詳細画面で 適用除外の作成 を選択する
対象スコープに検証用リソースグループを指定する
適用除外カテゴリに 免除 (Waiver) を選択する
適用除外名、表示名、説明、有効期限を入力する
リソースセレクター でセレクターを追加する
セレクターの種類に ユーザープリンシパル ID (userPrincipalId) を選択する
含むを選び、対象ユーザーのオブジェクト ID を指定する
確認および作成 で適用除外を作成する

Allowed virtual machine size SKUs のポリシー割り当て詳細画面にある適用除外の作成ボタン — **ポリシー割り当てから適用除外を作成**: 対象のポリシー割り当てを開き、適用除外の作成を選択する

適用除外の基本情報では、対象スコープ、適用除外名、カテゴリ、有効期限などを設定します。
リソースセレクターを使用するため、リソースセレクターを展開します。

Azure Policy の適用除外作成画面でスコープ、適用除外名、Waiver カテゴリを設定し、リソースセレクターを展開する画面 — **適用除外の基本情報**: 適用除外のスコープとカテゴリを設定し、リソースセレクターを展開する

リソースセレクターに名前を付け、userPrincipalId を有効にします。演算子は in を選択し、
値には免除対象ユーザーの Microsoft Entra ID オブジェクト ID を入力します。

Azure Policy のリソースセレクターで userPrincipalId を有効化し、ユーザーのオブジェクト ID を入力した画面 — **userPrincipalId の設定**: userPrincipalId に免除対象ユーザーのオブジェクト ID を指定する

作成後は適用除外の JSON ビュー を開き、policyAssignmentId、expiresOn、
resourceSelectors、userPrincipalId が意図した値になっていることを確認します。
指定する値は Microsoft Entra ID のオブジェクト ID であり、アプリケーション ID や
ユーザープリンシパル名ではありません。

適用除外対象ユーザーと比較用ユーザーの両方で禁止 SKU を作成し、対象ユーザーだけが成功することを確認します。

適用除外対象ユーザーで、許可リストに含まれていない Standard_D4s_v3 を指定したところ、
Azure Policy に拒否されず、VM 作成の検証に成功しました。

Azure Portal の仮想マシン作成画面で適用除外対象ユーザーが Standard_D4s_v3 を選択し、検証に成功している画面 — **適用除外対象ユーザーの VM 作成成功**: userPrincipalId で適用除外されたユーザーは、許可リスト外の Standard_D4s_v3 を選択しても VM を作成できる

手順 5: groupPrincipalId の適用除外を作成する

user 免除を削除するか無効な状態にしてから、同じポリシー割り当てに group 免除を作成します。

Azure Portal の ポリシー > 割り当て から同じポリシー割り当てを開き、
適用除外の作成 を選択します。

適用除外名、表示名、説明、有効期限を入力する
適用除外カテゴリに 免除 (Waiver) を選択する
リソースセレクター でセレクターを追加する
セレクターの種類に グループプリンシパル ID (groupPrincipalId) を選択する
含むを選び、対象セキュリティグループのオブジェクト ID を指定する
確認および作成 で適用除外を作成する
作成後に JSON ビュー で groupPrincipalId とグループ ID を確認する

リソースセレクターでは groupPrincipalId を有効にし、演算子に in、値に免除対象となる
Microsoft Entra ID セキュリティグループのオブジェクト ID を指定します。

Azure Policy のリソースセレクターで groupPrincipalId を有効化し、セキュリティグループのオブジェクト ID を入力した画面 — **groupPrincipalId の設定**: groupPrincipalId に免除対象セキュリティグループのオブジェクト ID を指定する

本検証で保証する範囲は、セキュリティグループへの直接所属です。
ネストされたグループ、動的グループ、Privileged Identity Management (PIM) グループは対象外とします。

手順 6: グループ所属の変更と反映を確認する

グループ所属を変更した直後は、Microsoft Entra ID と Azure Policy の評価へ反映されるまで時間差が生じる可能性があります。

次の順序で確認します。

非所属ユーザーが禁止 SKU を作成できないことを確認する
ユーザーを検証グループへ直接追加する
反映を待って禁止 SKU を再試行する
作成成功を確認する
ユーザーをグループから削除する
反映待ちの後、Policy Deny に戻ることを確認する

実測では、変更時刻、各試行時刻、成功へ切り替わるまでの待機時間を記録します。

まず、検証ユーザーが適用除外対象グループに所属していない状態で、許可リスト外の
Standard_D4s_v3 を指定しました。この場合は適用除外の対象にならないため、
RequestDisallowedByPolicy によって VM 作成が拒否されます。

Azure Portal の仮想マシン作成画面でグループ非所属ユーザーが Standard_D4s_v3 を指定し、RequestDisallowedByPolicy が表示された画面 — **グループ非所属ユーザーの VM 作成拒否**: 適用除外対象グループに所属していないユーザーは、禁止 SKU の VM を作成できない

次に、同じ検証ユーザーを適用除外対象のセキュリティグループへ直接追加しました。

Microsoft Entra ID のグループメンバー追加画面で検証ユーザーを選択している画面 — **検証ユーザーを適用除外対象グループへ追加**: 禁止 SKU で拒否された検証ユーザーを、groupPrincipalId で指定したセキュリティグループへ直接追加する

反映を待って再試行すると、同じユーザー、同じ禁止 SKU の Standard_D4s_v3 でも
Policy Deny が発生せず、VM 作成のレビュー画面まで進めました。

Azure Portal の仮想マシン作成レビュー画面で Standard_D4s_v3 が選択され、作成ボタンが有効になっている画面 — **グループ追加後の禁止 SKU による VM 作成**: 適用除外対象グループへの追加が反映されると、禁止 SKU の Standard_D4s_v3 でも VM 作成を実行できる

しばらく待っても反映されない場合は、Azure Portal から一度サインアウトし、
再度サインインしてから試行してください。既存セッションの情報が更新され、結果が変わる場合があります。

作成成功を確認した後、対象グループの メンバー 画面で検証ユーザーを選択し、
削除を選んで直接所属から外します。

Microsoft Entra ID のグループメンバー画面で検証ユーザーを選択し、削除ボタンを示している画面 — **適用除外対象グループから検証ユーザーを削除**: 検証ユーザーを選択し、削除を実行して groupPrincipalId の適用除外対象から外す

削除後は反映を待って同じ禁止 SKU を再試行し、Policy Deny に戻ることを確認します。
今回の検証では、ユーザー削除後に Azure Portal からサインアウトして再度サインインすると、
最初の再試行で RequestDisallowedByPolicy が表示されました。

Azure Portal の仮想マシン作成画面で Standard_D4s_v3 が選択され、RequestDisallowedByPolicy が表示された画面 — **グループから削除後の禁止 SKU の拒否**: グループから検証ユーザーを削除し、再サインインすると Standard_D4s_v3 の VM 作成が Azure Policy に拒否された

今回は最初の再試行で反映されましたが、常に即時反映されるとは限りません。
反映されない場合は時間を置いて再試行してください。

補足: RBAC と適用除外の違い

Policy 適用除外は、対象ポリシーの評価から要求を除外する機能であり、Azure RBAC の権限は付与しません。
免除対象のユーザーやグループであっても、VM 作成に必要なロールがなければリソースを作成できません。
適用除外とアクセス権は、別々に設計・管理する必要があります。

補足: 有効期限と削除後

適用除外の expiresOn を過ぎても、適用除外リソース自体は記録のため残りますが、適用除外としては無効になります。
また、適用除外を削除すると、その適用除外による評価回避は行われません。
例外は期限付きで管理し、不要になった適用除外は削除します。

補足: 作成後のコンプライアンス評価

アイデンティティベースの適用除外を使うと、対象ユーザーやグループは Deny の影響を受けずに
リソースを作成・変更できます。ただし、この適用除外は要求主体に対する例外であり、
作成されたリソース自体を継続的なコンプライアンス評価から除外するものではありません。

そのため、ポリシーに準拠していないリソースは、作成後の評価で非準拠として表示されます。
作成したリソースを非準拠として扱わない場合は、そのリソースを対象とする適用除外を別途作成してください。

意思決定時のポイント

選択肢	利点	リスク・運用負荷
user 免除	対象が明確で最小化しやすい	異動や担当交代のたびに更新が必要
group 免除	メンバー管理へ委譲しやすい	グループの誤追加で免除範囲が広がる
除外スコープ	構成が単純	評価・適用除外として追跡されず、ID 単位に制御できない
enforcementMode 無効化	検証には使いやすい	スコープ全体で強制が止まり、限定的な例外にならない

継続的な運用では、個別ユーザーよりも承認・監査された専用グループを使う方が管理しやすい場合があります。
ただし、そのグループを高権限ロールと兼用せず、Policy 適用除外専用の役割として管理することを推奨します。

まとめ

Azure Policy の ID セレクターを使うと、同じリソーススコープでも、Azure Resource Manager へ要求した主体に応じて適用除外を制御できます。

設計で最も重要な点は、次の 4 つです。

評価対象はリソースの ID ではなく要求主体である
Policy 適用除外と Azure RBAC は独立している
グループ変更には伝播時間を考慮する
最小スコープ、有効期限、承認、監査、削除を例外管理プロセスへ組み込む

参考情報

Azure Policy 適用除外の構造（確認日: 2026-08-20）
Azure Policy 割り当ての構造（確認日: 2026-08-20）
Azure Policy の概要（確認日: 2026-08-20）
Microsoft.Authorization policyExemptions resource reference（確認日: 2026-08-20）
Azure RBAC のベストプラクティス（確認日: 2026-08-20）
Microsoft Entra ID のアクセストークン（確認日: 2026-08-20）