Use requestContext().identity para retornar a identidade do chamador no Azure Policy

Se você quiser que Azure Policy se comporte de forma diferente com base em quem (ou o que) faz uma solicitação, use a requestContext().identity função.

Essa função permite inspecionar as informações de identidade do chamador no momento da avaliação da política, para que você possa escrever políticas como:

  • permitir somente alterações iniciadas pelo usuário para tipos de recursos confidenciais
  • bloquear atualizações de aplicativos cliente não aprovados
  • exigir um contexto de entrada mais forte (por exemplo, indicadores de MFA) antes de operações específicas

Por que essa função importa

A maioria das regras de política avalia a carga útil do recurso de destino. Essa abordagem funciona bem para impor a configuração, mas não fornece nenhuma informação sobre o chamador.
requestContext().identity preenche essa lacuna expondo metadados de identidade da solicitação em expressões de regras de política.

Em um alto nível, você pode avaliar:

  • idtyp: tipo de identidade do chamador (appou usernull)
  • appid: ID do aplicativo cliente usada para a solicitação
  • acrs: referências de classe de contexto de autenticação (usadas para inspecionar o contexto de autenticação, como valores relacionados à autenticação multifator (MFA))
  • http://schemas.microsoft.com/identity/claims/objectidentifier: ID do objeto do chamador (identificador do objeto do usuário ou da entidade de serviço)

Importante

Quando você usa requestContext().identity, a aplicação da Azure Policy ainda ocorre no momento da solicitação (por exemplo, deny, modify e deployIfNotExists). No entanto, as verificações de conformidade para essa política são marcadas como NotApplicable. Esse padrão é mais adequado quando seu objetivo é aplicar regras em tempo real nas operações recebidas de criação/atualização, e não gerar relatórios de conformidade após a implantação.

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

As declarações de identidade podem estar ausentes para algumas solicitações. Use tryGet() para que sua expressão não falhe quando uma chave estiver ausente.

Exemplo:

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

Exemplo 1: permitir somente aplicativos cliente aprovados

Este exemplo restringe gravações a solicitações obtidas de uma lista de permissões conhecida com IDs do aplicativo 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"
		}
	}
}

Essa restrição é útil para proteger os limites de automação, portanto, somente as ferramentas de implantação aprovadas podem modificar provedores de recursos selecionados.

A acrs declaração pode incluir vários valores separados por vírgulas. Use split() para avaliá-los.

{
	"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 de acesso condicional; portanto, valide os valores esperados no seu locatário antes da ampla distribuição.

Exemplo 3: escopo por IDs de objetos de chamada específicas

Você pode inspecionar declarações de identificador de objeto para 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"
	}
}

Esse padrão é estrito e explícito, mas requer uma boa higiene operacional para manter as listas de identidade atuais.

Dicas de projeto antes da implantação em produção

  • Comece com audit ou atribua com a aplicação desativada para validar o comportamento antes de aplicar deny.
  • Faça um piloto em um escopo limitado (um único grupo de recursos ou uma assinatura isolada) antes da ampla atribuição. Para saber mais sobre as práticas recomendadas de distribuição em etapas, consulte a implantação segura de atribuições de Azure Policy.
  • Comunique claramente às equipes de plataforma e segurança que o estado de conformidade é NotApplicable para essas políticas.
  • Emparelhar regras baseadas em identidade com políticas de configuração de recursos para governança em camadas.

Finalização

requestContext().identity fornece ao Azure Policy visibilidade, no momento da solicitação, da identidade do chamador para que você possa controlar quem pode realizar alterações, não apenas qual deve ser a configuração do recurso.

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

  • Last updated on