Utilize requestContext().identity para devolver a identidade do autor da chamada no Azure Policy

Se quiseres que o Azure Policy se comporte de forma diferente consoante quem (ou o quê) faz um pedido, usa a requestContext().identity função.

Esta função permite-lhe inspecionar a informação de identidade do chamador no momento da avaliação da política, para que possa escrever políticas como:

  • Permitir apenas alterações iniciadas pelo utilizador para tipos de recursos sensíveis
  • Bloqueia atualizações de aplicações de clientes não aprovadas
  • exigir um contexto de autenticação mais robusto (por exemplo, indicadores de MFA) antes de determinadas operações

Por que esta função é importante

A maioria das regras de políticas avalia a carga útil de recurso alvo. Essa abordagem funciona bem para impor a configuração, mas não fornece qualquer informação sobre quem chama.
requestContext().identity preenche essa lacuna ao expor metadados de identidade do pedido em expressões de regras de política.

A um nível geral, pode avaliar:

  • idtyp: tipo de identidade do chamador (app, user, ou null)
  • appid: ID da aplicação cliente usado para o pedido
  • acrs: referências de classe de contexto de autenticação (usadas para inspecionar o contexto de início de sessão, como valores relacionados com MFA)
  • http://schemas.microsoft.com/identity/claims/objectidentifier: identificador de objeto do chamador (identificador de objeto principal de utilizador ou serviço)

Importante

Quando usa requestContext().identity, a aplicação de políticas do Azure Policy continua a ocorrer aquando do pedido (por exemplo, deny, modify e deployIfNotExists). No entanto, as verificações de conformidade dessa política estão assinaladas como NotApplicable. Este padrão é melhor quando o objetivo é a aplicação em tempo real das operações de criação/atualização que chegam, e não relatórios de conformidade pós-implementação.

Padrão: ler com segurança campos de identidade com tryGet

Algumas solicitações poderão não incluir declarações de identidade. Usa tryGet() para que a tua expressão não falhe quando falta uma tecla.

Example:

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

Exemplo 1: permitir apenas aplicações de cliente aprovadas

Este exemplo restringe as operações de escrita a pedidos provenientes de uma lista conhecida de autorizações de IDs de aplicações 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"
		}
	}
}

Esta restrição é útil para proteger limites de automação, de modo que apenas ferramentas de implementação aprovadas podem modificar fornecedores de recursos selecionados.

A acrs reivindicação pode incluir múltiplos valores separados por vírgulas. Use split() para os avaliar.

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

Os valores exatos acrs dependem da sua identidade e do design do acesso condicional, por isso valide os valores esperados no seu tenant antes de uma implementação abrangente.

Exemplo 3: âmbito com base em IDs de objetos específicos do chamador

Pode inspecionar declarações de identificador de objeto para aplicar uma lógica precisa de permissão ou negação:

{
	"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 padrão é rigoroso e explícito, mas requer boa higiene operacional para manter as listas de identidade atualizadas.

Dicas de design antes do lançamento em produção

  • Comece com audit ou atribua com a imposição desativada para validar o comportamento antes de impor deny.
  • Teste num contexto limitado (grupo de recursos único ou subscrição isolada) antes de uma aplicação alargada. Para saber mais sobre as melhores práticas de implementação por etapas, consulte Implementação segura de atribuições de Azure Policy.
  • Comunique claramente com as equipas da plataforma e de segurança que o estado de conformidade é NotApplicable para estas políticas.
  • Emparelhar regras baseadas em identidade com políticas de configuração de recursos para governação em camadas.

Concluir

requestContext().identityconfere ao Azure Policy visibilidade, no momento do pedido, da identidade do autor da chamada, para que possa controlar quem pode efetuar alterações, e não apenas o que o recurso deve ser.

Usado com cuidado, é um controlo forte para operações de alto impacto, especialmente quando combinado com políticas de configuração padrão e práticas de implementação em etapas.

  • Last updated on