Använd requestContext().identity för att returnera uppringarens identitet i Azure Policy

Om du vill att Azure Policy ska bete sig annorlunda baserat på vem (eller vad) som gör en begäran använder du requestContext().identity funktionen.

Med den här funktionen kan du granska anroparens identitetsinformation när principer utvärderas, så att du kan skriva principer som:

• tillåt endast användarinitierade ändringar för känsliga resurstyper
• blockera uppdateringar från icke godkända klientprogram
• kräver starkare inloggningskontext (till exempel MFA-indikatorer) före specifika åtgärder

Varför den här funktionen är viktig

De flesta principregler utvärderar målresursnyttolasten. Den här metoden fungerar bra för att framtvinga konfiguration, men den ger ingen information om anroparen.
requestContext().identity fyller det gapet genom att göra identitetsmetadata för begäranden tillgängliga i uttryck för principregler.

På hög nivå kan du utvärdera:

• idtyp: typ av uppringaridentitet (app, user eller null)
• appid: klientprogram-ID som används för begäran
• acrs: referenser för autentiseringskontextklass (används för att inspektera inloggningskontext, till exempel MFA-relaterade värden)
• http://schemas.microsoft.com/identity/claims/objectidentifier: anroparens objekt-ID (objektidentifierare för användaren eller tjänstens huvudobjekt)

Mönster: läsa identitetsfält på ett säkert sätt med tryGet

Identitetsanspråk kan saknas för vissa förfrågningar. Använd tryGet() så att uttrycket inte misslyckas när en nyckel saknas.

Example:

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

Exempel 1: Tillåt endast godkända klientappar

Det här exemplet begränsar skrivåtkomst till begäranden som kommer från en känd tillåten lista med ID:n för klientappar.

{
	"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"
		}
	}
}

Den här begränsningen är användbar för att skydda automatiseringsgränser så att endast godkända distributionsverktyg kan ändra valda resursproviders.

Exempel 2: Inspektera MFA-relaterad autentiseringskontext

Anspråket acrs kan innehålla flera kommaavgränsade värden. Använd split() för att utvärdera dem.

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

De exakta acrs värdena beror på din identitet och design för villkorsstyrd åtkomst, så verifiera de förväntade värdena i din klientorganisation innan den breda distributionen.

Exempel 3: omfång efter specifika anroparobjekt-ID:er

Du kan granska objekt-ID-anspråk för exakt logik för att tillåta eller neka:

{
	"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"
	}
}

Det här mönstret är strikt och explicit, men det krävs god drifthygien för att hålla identitetslistorna aktuella.

Designtips inför produktionssättning

• Börja med audit eller tilldela med framtvingande inaktiverat för att validera beteendet innan du aktiverar framtvingande för deny.
• Pilottesta med ett smalt omfång (enskild resursgrupp eller isolerad prenumeration) före bred tilldelning. Mer information om metodtips för stegvis distribution finns i Säker distribution av Azure Policy tilldelningar.
• Kommunicera tydligt med plattforms- och säkerhetsteamen att efterlevnadsstatusen är NotApplicable för de här policyerna.
• Koppla ihop identitetsbaserade regler med resurskonfigurationsprinciper för styrning i flera lager.

Avslutning

requestContext().identityger Azure Policy insyn i anroparens identitet så att du kan styra vem som kan utföra ändringar, inte bara vad resursen ska se ut som.

Det används noggrant och är en stark kontroll för åtgärder med hög påverkan, särskilt när det kombineras med standardkonfigurationsprinciper och stegvisa distributionsmetoder.