Verwenden von requestContext().identity zum Zurückgeben der Anruferidentität in Azure Policy

Wenn Azure Policy sich je nachdem, wer (oder was) eine Anforderung stellt, anders verhalten soll, verwenden Sie die requestContext().identity-Funktion.

Mit dieser Funktion können Sie Informationen zur Identität des Aufrufers zum Zeitpunkt der Richtlinienauswertung einsehen, sodass Sie Richtlinien wie folgende schreiben können:

• Nur vom Benutzer initiierte Änderungen für vertrauliche Ressourcentypen zulassen
• Blockieren von Updates von nicht genehmigten Clientanwendungen
• Erfordern eines stärkeren Anmeldekontexts (z. B. MFA-Indikatoren) vor bestimmten Vorgängen

Warum diese Funktion wichtig ist

Die meisten Richtlinienregeln bewerten die Zielressourcennutzlast. Dieser Ansatz eignet sich gut zum Erzwingen der Konfiguration, stellt jedoch keine Informationen zum Aufrufer bereit.
requestContext().identity füllt diese Lücke, indem Metadaten zur Anforderungsidentität in Ausdrücken für Richtlinienregeln verfügbar gemacht werden.

Auf hoher Ebene können Sie Folgendes bewerten:

• idtyp: Anruferidentitätstyp (app, useroder null)
• appid: Clientanwendungs-ID, die für die Anforderung verwendet wird
• acrs: Authentifizierungskontextklassenverweise (wird verwendet, um den Anmeldekontext zu prüfen, z. B. MFA-bezogene Werte)
• http://schemas.microsoft.com/identity/claims/objectidentifier: Aufruferobjekt-ID (Benutzer- oder Dienstprinzipalobjektbezeichner)

Muster: Sicheres Lesen von Identitätsfeldern mit tryGet

Für einige Anforderungen fehlen möglicherweise Identitätsansprüche. Verwenden Sie diese Methode tryGet() , damit ihr Ausdruck nicht fehlschlägt, wenn ein Schlüssel fehlt.

Beispiel:

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

Beispiel 1: Nur genehmigte Client-Apps zulassen

In diesem Beispiel werden Schreibvorgänge auf Anforderungen beschränkt, die von einer bekannten Zulassungsliste von Client-App-IDs stammen.

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

Diese Einschränkung ist nützlich zum Schützen von Automatisierungsgrenzen, sodass nur genehmigte Bereitstellungstools ausgewählte Ressourcenanbieter ändern können.

Beispiel 2: Überprüfen des MFA-bezogenen Authentifizierungskontexts

Der acrs Anspruch kann mehrere durch Kommas getrennte Werte enthalten. Verwenden Sie split(), um sie auszuwerten.

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

Die genauen acrs-Werte hängen von Ihrem Identitätskonzept und Ihrem Konzept für bedingten Zugriff ab. Überprüfen Sie daher vor einer breiten Einführung die erwarteten Werte in Ihrem Mandanten.

Beispiel 3: Bereich nach bestimmten Aufruferobjekt-IDs

Sie können Objektbezeichneransprüche auf präzise Zulassungs- oder Ablehnungslogik prüfen:

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

Dieses Muster ist streng und explizit, erfordert jedoch eine gute Betriebshygiene, um Identitätslisten auf dem aktuellen Stand zu halten.

Entwurfstipps vor dem Produktionsrollout

• Beginnen Sie mit audit oder weisen Sie es bei deaktivierter Erzwingung zu, um das Verhalten zu validieren, bevor Sie deny erzwingen.
• Testen Sie zunächst in kleinem Umfang (einzelne Ressourcengruppe oder separates Abonnement), bevor Sie breit zuweisen. Weitere Informationen zu bewährten Methoden für das mehrstufige Rollout finden Sie unter "Sichere Bereitstellung von Azure Policy Zuweisungen".
• Kommunizieren Sie den Plattform- und Sicherheitsteams klar, dass der Compliance-Status für diese Richtlinien NotApplicable ist.
• Koppeln sie identitätsbasierte Regeln mit Ressourcenkonfigurationsrichtlinien für mehrschichtige Governance.

Nachbereitung

requestContext().identitybietet Azure Policy Anforderungs-Zeit-Bewusstsein für die Anruferidentität, damit Sie steuern können, wer Änderungen ausführen kann, nicht nur wie die Ressource aussehen soll.

Bei sorgfältigem Einsatz ist dies eine wirksame Kontrollmaßnahme für Operationen mit hoher Auswirkung, insbesondere in Kombination mit standardmäßigen Konfigurationsrichtlinien und einem stufenweisen Rollout.