Gebruik requestContext().identity om de identiteit van de aanroeper in Azure Policy te retourneren

Als u wilt dat Azure Policy zich anders gedraagt op basis van wie (of wat) een aanvraag doet, gebruikt u de requestContext().identity functie.

Met deze functie kunt u identiteitsgegevens van de aanroeper controleren op het tijdstip van de beleidsevaluatie, zodat u beleidsregels kunt schrijven, zoals:

• alleen door de gebruiker geïnitieerde wijzigingen toestaan voor gevoelige resourcetypen
• updates van niet-goedgekeurde clienttoepassingen blokkeren
• een sterkere aanmeldingscontext vereisen (bijvoorbeeld MFA-indicatoren) voor specifieke bewerkingen

Waarom deze functie belangrijk is

De meeste beleidsregels evalueren de payload van de doelresource. Deze aanpak werkt goed voor het afdwingen van configuratie, maar biedt geen informatie over de beller.
requestContext().identity vult die kloof door de metagegevens van de aanvraagidentiteit bloot te stellen in beleidsregelexpressies.

Op hoog niveau kunt u het volgende evalueren:

• idtyp: type belleridentiteit (app, userof null)
• appid: clienttoepassings-id die wordt gebruikt voor de aanvraag
• acrs: verwijzingen naar verificatiecontextklassen (gebruikt om aanmeldingscontext te inspecteren, zoals MFA-gerelateerde waarden)
• http://schemas.microsoft.com/identity/claims/objectidentifier: object-ID van de aanroeper (object-id van de gebruiker of service-principal)

Patroon: identiteitsvelden veilig lezen met tryGet

Identiteitsclaims ontbreken mogelijk voor sommige aanvragen. Gebruik tryGet() deze functie zodat uw expressie niet mislukt wanneer een sleutel ontbreekt.

Example:

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

Voorbeeld 1: alleen goedgekeurde client-apps toestaan

In dit voorbeeld worden schrijfbewerkingen beperkt tot aanvragen die afkomstig zijn van een bekende acceptatielijst met client-app-id's.

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

Deze beperking is handig voor het bewaken van automatiseringsgrenzen, zodat alleen goedgekeurde implementatiehulpprogramma's geselecteerde resourceproviders kunnen wijzigen.

Voorbeeld 2: MFA-gerelateerde verificatiecontext inspecteren

De acrs claim kan meerdere door komma's gescheiden waarden bevatten. Gebruik split() om deze te evalueren.

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

De exacte acrs waarden zijn afhankelijk van uw identiteits- en ontwerp voor voorwaardelijke toegang, dus valideer de verwachte waarden in uw tenant vóór de brede implementatie.

Voorbeeld 3: beperken tot object-id's van specifieke aanroepers

U kunt object-id-claims inspecteren voor nauwkeurige logica voor toestaan of weigeren:

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

Dit patroon is strikt en expliciet, maar vereist een goede operationele hygiëne om identiteitslijsten actueel te houden.

Ontwerptips vóór de productie-implementatie

• Begin met audit of wijs toe met afdwingen uitgeschakeld om het gedrag te valideren voordat u deny afdwingt.
• Testfase voor een beperkt bereik (één resourcegroep of geïsoleerd abonnement) vóór een brede toewijzing. Zie Veilige implementatie van Azure Policy toewijzingen voor meer informatie over aanbevolen procedures voor gefaseerde implementatie.
• Communiceer duidelijk naar platform- en beveiligingsteams dat de nalevingsstatus voor deze beleidsregels NotApplicable is.
• Koppel op identiteit gebaseerde regels met resourceconfiguratiebeleid voor gelaagde governance.

Afsluiten

requestContext().identitygeeft Azure Policy op het moment van de aanvraag inzicht in de identiteit van de aanroeper, zodat u kunt beheren wie wijzigingen kan aanbrengen, en niet alleen wat de resource moet zijn.

Het is zorgvuldig gebruikt, het is een sterke controle voor bewerkingen met een hoge impact, met name in combinatie met standaardconfiguratiebeleid en gefaseerde implementatieprocedures.