Utilisez requestContext().identity pour retourner l’identité de l’appelant dans Azure Policy

Si vous souhaitez Azure Policy se comporter différemment en fonction de qui (ou de quoi) effectue une requête, utilisez la requestContext().identity fonction.

Cette fonction vous permet d’inspecter les informations d’identité de l’appelant au moment de l’évaluation de la stratégie, afin de pouvoir écrire des stratégies telles que :

  • autoriser uniquement les modifications initiées par l’utilisateur pour les types de ressources sensibles
  • bloquer les mises à jour des applications clientes non approuvées
  • exiger un contexte de connexion plus fort (par exemple, des indicateurs MFA) avant des opérations spécifiques

Pourquoi cette fonction est importante

La plupart des règles de stratégie évaluent la charge utile de ressource cible. Cette approche fonctionne bien pour l’application de la configuration, mais elle ne fournit aucune information sur l’appelant.
requestContext().identity comble cette lacune en exposant les métadonnées d’identité de la requête dans les expressions des règles de stratégie.

À un niveau élevé, vous pouvez évaluer :

  • idtyp: type d’identité de l’appelant (app, userou null)
  • appid: ID d’application cliente utilisé pour la requête
  • acrs: références de classe de contexte d’authentification (utilisées pour inspecter le contexte de connexion, telles que les valeurs liées à l’authentification multifacteur)
  • http://schemas.microsoft.com/identity/claims/objectidentifier: ID d’objet de l’appelant (identificateur d’objet utilisateur ou principal de service)

Important

Lorsque vous utilisez requestContext().identity, l’application d’Azure Policy s’effectue toujours au moment de la requête (par exemple, deny, modify et deployIfNotExists). Toutefois, les analyses de conformité pour cette stratégie sont marquées comme NotApplicable. Ce modèle est préférable lorsque votre objectif est l’application en temps réel des opérations de création/mise à jour entrantes, et non pas des rapports de conformité post-déploiement.

Modèle : lire en toute sécurité les champs d’identité avec tryGet

Des informations d’identification peuvent manquer dans certaines requêtes. Utilisez tryGet() cette option pour que votre expression ne échoue pas lorsqu’une clé est manquante.

Exemple :

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

Exemple 1 : autoriser uniquement les applications clientes approuvées

Cet exemple limite les écritures aux requêtes provenant d’une liste d’autorisation connue d’identifiants d’application cliente.

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

Cette restriction est utile pour protéger les limites d’automatisation afin que seuls les outils de déploiement approuvés puissent modifier les fournisseurs de ressources sélectionnés.

La acrs revendication peut inclure plusieurs valeurs séparées par des virgules. Utilisez split() pour les évaluer.

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

Les valeurs exactes acrs dépendent de votre conception de l’identité et de l’accès conditionnel ; validez donc les valeurs attendues dans votre locataire avant un déploiement à grande échelle.

Exemple 3 : portée par identifiants d’objet d’appelant spécifiques

Vous pouvez examiner les revendications de type identificateur d’objet pour appliquer une logique précise d’autorisation ou de refus :

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

Ce modèle est strict et explicite, mais il nécessite une bonne hygiène opérationnelle pour maintenir les listes d’identités en cours.

Conseils de conception avant le déploiement de production

  • Commencez avec audit ou attribuez-le avec la mise en application désactivée afin de valider le comportement avant d’appliquer deny.
  • Effectuez un test pilote dans un périmètre restreint (un seul groupe de ressources ou un abonnement isolé) avant tout déploiement à grande échelle. Pour en savoir plus sur les meilleures pratiques de déploiement progressif, consultez Déploiement sécurisé des affectations Azure Policy.
  • Communiquez clairement aux équipes de plateforme et de sécurité que l’état de conformité est NotApplicable pour ces stratégies.
  • Associez des règles basées sur des identités avec des stratégies de configuration des ressources pour la gouvernance en couches.

En conclusion

requestContext().identityconfère à Azure Policy une visibilité sur l’identité de l’appelant au moment de la requête, afin de contrôler qui peut effectuer des modifications, et pas seulement à quoi la ressource doit ressembler.

Utilisé avec soin, il s’agit d’un contrôle fort pour les opérations à impact élevé, en particulier lorsqu’ils sont combinés avec des stratégies de configuration standard et des pratiques de déploiement intermédiaires.

  • Last updated on