Usare requestContext().identity per restituire l'identità del chiamante in Criteri di Azure

Se si vuole che Criteri di Azure si comporti in modo diverso in base a chi (o cosa) effettua una richiesta, usare la requestContext().identity funzione .

Questa funzione consente di esaminare le informazioni sull'identità del chiamante in fase di valutazione dei criteri, in modo da poter scrivere criteri come:

  • consentire solo le modifiche avviate dall'utente per i tipi di risorse sensibili
  • bloccare gli aggiornamenti dalle applicazioni client non approvate
  • richiede un contesto di accesso più sicuro (ad esempio, indicatori di autenticazione a più fattori) prima di operazioni specifiche

Perché questa funzione è importante

La maggior parte delle regole di policy valuta il payload della risorsa di destinazione. Questo approccio funziona bene per applicare la configurazione, ma non fornisce informazioni sul chiamante.
requestContext().identity colma questa lacuna esponendo i metadati sull'identità delle richieste nelle espressioni delle regole dei criteri.

A livello generale, è possibile valutare:

  • idtyp: tipo di identità chiamante (app, usero null)
  • appid: ID applicazione client usato per la richiesta
  • acrs: riferimenti alla classe di contesto di autenticazione (usati per esaminare il contesto di accesso, ad esempio i valori correlati all'autenticazione a più fattori)
  • http://schemas.microsoft.com/identity/claims/objectidentifier: ID oggetto del chiamante (identificatore dell'oggetto utente o dell'entità servizio)

Importante

Quando si usa requestContext().identity, l'applicazione di Criteri di Azure avviene comunque al momento della richiesta (ad esempio, deny, modify e deployIfNotExists). Tuttavia, le analisi di conformità per tale criterio vengono contrassegnate come NotApplicable. Questo modello è più indicato quando l'obiettivo è far rispettare in tempo reale le operazioni di creazione/aggiornamento in entrata, non la reportistica di conformità post-distribuzione.

Modello: leggere in modo sicuro i campi Identity con tryGet

Le attestazioni di identità potrebbero non essere presenti per alcune richieste. Usare tryGet() per evitare che l'espressione vada in errore se manca una chiave.

Esempio:

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

Esempio 1: consentire solo le app client approvate

Questo esempio limita le operazioni di scrittura alle richieste provenienti da un elenco consentiti noto di ID delle app client.

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

Questa restrizione è utile per proteggere i limiti di automazione in modo che solo gli strumenti di distribuzione approvati possano modificare i provider di risorse selezionati.

L'attestazione acrs può includere più valori delimitati da virgole. Usare split() per valutarli.

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

I valori esatti di acrs dipendono dalla configurazione dell'identità e dell'accesso condizionale, quindi è necessario convalidare i valori previsti nel tenant prima di una distribuzione su larga scala.

Esempio 3: ambito per ID di oggetti chiamanti specifici

È possibile esaminare le attestazioni dell'identificatore di oggetto per ottenere una logica di autorizzazione o negazione precisa:

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

Questo modello è rigoroso ed esplicito, ma richiede una buona igiene operativa per mantenere aggiornati gli elenchi di identità.

Suggerimenti per la progettazione prima dell'implementazione di produzione

  • Iniziare con audit o assegnare con l'applicazione disabilitata per convalidare il comportamento prima di applicare deny.
  • Esegui un progetto pilota in un ambito limitato (un singolo gruppo di risorse o una sottoscrizione isolata) prima di un'assegnazione su larga scala. Per altre informazioni sulle procedure consigliate per l'implementazione a fasi, vedere Distribuzione sicura delle assegnazioni di Criteri di Azure.
  • Comunicate chiaramente ai team della piattaforma e della sicurezza che lo stato di conformità è NotApplicable per queste policy.
  • Associare regole basate sull'identità ai criteri di configurazione delle risorse per la governance a più livelli.

Conclusa

requestContext().identityoffre Criteri di Azure consapevolezza in fase di richiesta dell'identità del chiamante, in modo da poter gestire chi può eseguire modifiche, non solo come dovrebbe apparire la risorsa.

Usato con attenzione, è un controllo sicuro per le operazioni ad alto impatto, soprattutto se combinato con i criteri di configurazione standard e le procedure di implementazione a fasi.

  • Last updated on