Use requestContext().identity para devolver la identidad del autor de la llamada en Azure Policy

Si desea que Azure Policy se comporten de forma diferente en función de quién (o qué) realice una solicitud, use la requestContext().identity función .

Esta función le permite inspeccionar la información de identidad del autor de la llamada en el tiempo de evaluación de directivas, por lo que puede escribir directivas como:

  • permitir solo los cambios iniciados por el usuario para los tipos de recursos confidenciales
  • bloquear actualizaciones de aplicaciones cliente no aprobadas
  • requerir un contexto de inicio de sesión más seguro (por ejemplo, indicadores de MFA) antes de operaciones específicas

¿Por qué es importante esta función?

La mayoría de las reglas de directiva evalúan la carga de recursos de destino. Ese enfoque funciona bien para aplicar la configuración, pero no proporciona información sobre el autor de la llamada.
requestContext().identity cubre esa carencia al exponer metadatos de identidad de la solicitud en expresiones de reglas de directiva.

En un nivel alto, puede evaluar:

  • idtyp: tipo de identidad del llamador (app, usero null)
  • appid: identificador de aplicación cliente usado para la solicitud.
  • acrs: referencias de clase del contexto de autenticación (usadas para inspeccionar el contexto de inicio de sesión, como valores relacionados con MFA)
  • http://schemas.microsoft.com/identity/claims/objectidentifier: ID del objeto de llamada (identificador de objeto de usuario o de entidad de servicio)

Importante

Cuando se usa requestContext().identity, la aplicación de Azure Policy sigue produciéndose en el momento de la solicitud (por ejemplo, deny, modify y deployIfNotExists). Sin embargo, los análisis de cumplimiento de esa directiva se marcan como NotApplicable. Este patrón es mejor cuando el objetivo es la aplicación en tiempo real en las operaciones entrantes de creación y actualización, no en los informes de cumplimiento posteriores a la implementación.

Patrón: leer campos de identidad de forma segura con tryGet

Es posible que falten declaraciones de identidad para algunas solicitudes. Use tryGet() para que la expresión no produzca un error cuando falte una clave.

Ejemplo:

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

Ejemplo 1: permitir solo aplicaciones cliente aprobadas

En este ejemplo, las operaciones de escritura se restringen a las solicitudes que provienen de una lista conocida de identificadores de aplicaciones cliente permitidas.

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

Esta restricción es útil para proteger los límites de automatización, por lo que solo las herramientas de implementación aprobadas pueden modificar los proveedores de recursos seleccionados.

La acrs claim puede incluir varios valores separados por comas. Usa split() para evaluarlos.

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

Los valores exactos de acrs dependen de su identidad y del diseño del acceso condicional, por lo que debe validar los valores esperados en su inquilino antes de una implementación generalizada.

Ejemplo 3: ámbito por identificadores de objeto de llamada específicos

Puede inspeccionar las declaraciones del identificador de objeto para aplicar una lógica precisa de permiso o denegación:

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

Este patrón es estricto y explícito, pero requiere una buena higiene operativa para mantener actualizadas las listas de identidades.

Sugerencias de diseño antes del lanzamiento de producción

  • Comience con audit o asigne con el cumplimiento deshabilitado para validar el comportamiento antes de aplicar deny.
  • Haga una prueba piloto con un alcance reducido (un único grupo de recursos o una suscripción aislada) antes de realizar una asignación amplia. Para obtener más información sobre los procedimientos recomendados para el despliegue por fases, consulte Implementación segura de asignaciones de Azure Policy.
  • Comunique claramente a los equipos de plataforma y de seguridad que el estado de cumplimiento es NotApplicable para estas políticas.
  • Empareja las reglas basadas en identidades con directivas de configuración de recursos para la gobernanza por capas.

Conclusión

requestContext().identity proporciona a Azure Policy visibilidad en tiempo de solicitud sobre la identidad de quien realiza la llamada, para que pueda gobernar quién puede realizar cambios, no solo cómo debe ser el recurso.

Si se usa con cuidado, es un control sólido para operaciones de alto impacto, especialmente cuando se combina con políticas de configuración estándar y prácticas de despliegue gradual.

  • Last updated on