requestContext().identity を使用して、Azure Policyで呼び出し元 ID を返す

だれが (または何が) リクエストを行うかに応じて Azure Policy の動作を変えるには、 関数を使用します。

この関数を使用すると、ポリシー評価時に呼び出し元 ID 情報を検査できるため、次のようなポリシーを記述できます。

  • 機密性の高いリソースの種類に対してユーザーが開始した変更のみを許可する
  • 承認されていないクライアント アプリケーションからの更新をブロックする
  • 特定の操作の前に、より強力なサインイン コンテキスト (MFA インジケーターなど) が必要

この関数が重要な理由

ほとんどのポリシー ルールでは、ターゲット リソース ペイロードが評価されます。 この方法は構成を適用する場合に適していますが、呼び出し元に関する情報は提供されません。
requestContext().identity は、ポリシー ルール式で要求 ID メタデータを公開することで、そのギャップを埋めます。

大まかに言うと、次の内容を評価できます。

  • idtyp: 呼び出し元 ID の種類 (app、 user、または null)
  • appid: 要求に使用されるクライアント アプリケーション ID
  • acrs: 認証コンテキスト クラス参照 (MFA 関連の値など、サインイン コンテキストを検査するために使用)
  • http://schemas.microsoft.com/identity/claims/objectidentifier: 呼び出し元オブジェクト ID (ユーザーまたはサービス プリンシパル オブジェクト識別子)

Important

requestContext().identityを使用する場合、要求時 (deny、modify、deployIfNotExistsなど) にAzure Policy適用が引き続き発生します。 ただし、そのポリシーのコンプライアンス スキャンは NotApplicableとしてマークされます。 このパターンは、デプロイ後のコンプライアンス レポートではなく、受信作成/更新操作に対するリアルタイムの適用が目標である場合に最適です。

パターン: tryGet を使用して ID フィールドを安全に読み取る

一部のリクエストでは、ID クレームが含まれない場合があります。 キーがない場合に式が失敗しないように、 tryGet() を使用します。

Example:

{
	"value": "[tryGet(requestContext().identity, 'idtyp')]",
	"equals": "user"
}

例 1: 承認されたクライアント アプリのみを許可する

この例では、クライアント アプリ ID の既知の許可リストからの要求への書き込みを制限します。

{
	"mode": "All",
	"parameters": {
		"allowedClientAppIds": {
			"type": "Array",
			"metadata": {
				"displayName": "Allowed client application IDs",
				"description": "List of Entra app IDs permitted to perform write operations."
			}
		}
	},
	"policyRule": {
		"if": {
			"allOf": [
				{
					"value": "[tryGet(requestContext().identity, 'appid')]",
					"notIn": "[parameters('allowedClientAppIds')]"
				}
			]
		},
		"then": {
			"effect": "deny"
		}
	}
}

この制限は、承認されたデプロイ ツールのみが選択したリソース プロバイダーを変更できるように、自動化境界を保護する場合に役立ちます。

acrs要求には、複数のコンマ区切り値を含めることができます。 split()を使用して評価します。

{
	"if": {
		"allOf": [
			{
				"field": "type",
				"equals": "Microsoft.Authorization/roleAssignments"
			},
			{
				"value": "p1",
				"notIn": "[split(tryGet(requestContext().identity, 'acrs'), ',')]"
			}
		]
	},
	"then": {
		"effect": "deny"
	}
}

正確な acrs 値は ID と条件付きアクセスの設計によって異なります。そのため、広範なロールアウトの前に、テナントで想定される値を検証します。

例 3: 特定の呼び出し元オブジェクト ID によるスコープ

オブジェクト識別子の要求で、正確な許可または拒否ロジックを調べることができます。

{
	"if": {
		"allOf": [
			{
				"field": "type",
				"equals": "Microsoft.Resources/subscriptions/resourceGroups"
			},
			{
				"value": "[tryGet(requestContext().identity, 'http://schemas.microsoft.com/identity/claims/objectidentifier')]",
				"notIn": "[parameters('approvedObjectIds')]"
			}
		]
	},
	"then": {
		"effect": "deny"
	}
}

このパターンは厳密で明示的ですが、ID リストを最新の状態に保つには適切な運用上の検疫が必要です。

運用ロールアウト前の設計に関するヒント

  • auditから開始するか、強制を無効にして割り当てて、denyを適用する前に動作を検証します。
  • 広範囲に割り当てる前に、限定された範囲（単一のリソース グループまたは分離されたサブスクリプション）で試験導入します。 段階的なロールアウトのベスト プラクティスの詳細については、「Azure Policy割り当ての安全なデプロイ」を参照してください。
  • コンプライアンスの状態がこれらのポリシーに対して NotApplicable されていることをプラットフォームおよびセキュリティ チームと明確に伝えます。
  • 階層型ガバナンスのリソース構成ポリシーと ID ベースの規則をペアにします。

まとめ

requestContext().identityでは、呼び出し元 ID をAzure Policy要求時に認識できるため、リソースの外観だけでなく、変更を実行できるユーザーを管理できます。

これは、特に標準の構成ポリシーや段階的なロールアウトプラクティスと組み合わせた場合に、影響の大きい操作を強力に制御するために慎重に使用されます。

  • Last updated on