Используйте requestContext().identity для получения идентификатора вызывающего объекта в Политика Azure

Если вы хотите, чтобы Политика Azure вести себя по-разному в зависимости от того, кто (или что) делает запрос, используйте функциюrequestContext().identity.

Эта функция позволяет проверять сведения об удостоверениях вызывающего абонента во время оценки политики, чтобы можно было писать такие политики, как:

  • разрешить только изменения, инициированные пользователем для типов конфиденциальных ресурсов
  • блокировать обновления из неутвержденных клиентских приложений
  • Требовать более строгий контекст входа в систему (например, признаки многофакторной аутентификации (MFA)) перед выполнением определённых операций

Почему эта функция имеет значение

Большинство правил политики оценивают полезную нагрузку целевого ресурса. Этот подход хорошо подходит для принудительного применения конфигурации, но не предоставляет сведений о вызывающей стороне.
requestContext().identity заполняет этот пробел, предоставляя идентификационные метаданные запроса в выражениях правил политики.

На высоком уровне можно оценить следующее:

  • idtyp: тип идентификатора вызывающего абонента (app, user, или null)
  • appid: идентификатор клиентского приложения, используемый для запроса
  • acrs: ссылки на класс контекста проверки подлинности (используется для проверки контекста входа, например значений, связанных с MFA)
  • http://schemas.microsoft.com/identity/claims/objectidentifier: идентификатор объекта вызывающей стороны (идентификатор объекта пользователя или субъекта-службы)

Important

При использовании requestContext().identity принудительное применение политик Политика Azure по-прежнему выполняется во время обработки запроса (например, deny, modify и deployIfNotExists). Однако для этой политики проверки соответствия помечены как NotApplicable. Этот шаблон лучше всего подходит, когда ваша цель — контроль в реальном времени при входящих операциях создания и обновления, а не формирование отчетов о соответствии после развертывания.

Шаблон: безопасное чтение идентификационных полей с помощью tryGet

Для некоторых запросов могут отсутствовать утверждения о субъекте. Используйте tryGet(), чтобы выражение не выдавало ошибку, если ключ отсутствует.

Пример:

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

Пример 1. Разрешить только утвержденные клиентские приложения

В этом примере запись разрешена только для запросов, поступающих из известного списка разрешённых идентификаторов клиентских приложений.

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

Это ограничение полезно для защиты границ автоматизации, поэтому только утвержденные средства развертывания могут изменять выбранных поставщиков ресурсов.

Утверждение acrs может включать несколько разделенных запятыми значений. Используйте split() для их оценки.

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

Точные значения acrs зависят от конфигурации удостоверений и условного доступа, поэтому перед широким развертыванием проверьте ожидаемые значения в вашем арендаторе.

Пример 3: область действия для конкретных идентификаторов объектов вызывающей стороны

Можно проверить утверждения идентификатора объекта для точной логики разрешения или запрета:

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

Этот подход строгий и явный, но для поддержания списков идентификаторов в актуальном состоянии требуется высокая операционная дисциплина.

Советы по проектированию перед вводом в эксплуатацию

  • Начните с audit или назначьте с отключённым применением, чтобы проверить поведение перед применением deny.
  • Сначала проведите пилотное внедрение в ограниченном масштабе (в одной группе ресурсов или в изолированной подписке), прежде чем выполнять широкое развертывание. Дополнительные сведения о рекомендациях поэтапного развертывания см. в статье Безопасное развертывание назначений Политика Azure.
  • Четко сообщите командам платформы и безопасности, что состояние соответствия для этих политик — NotApplicable.
  • Сочетайте правила на основе удостоверений личности с политиками конфигурации ресурсов для многоуровневого управления.

Подведение итогов

requestContext().identity предоставляет Политика Azure сведения о том, кто выполняет запрос, во время его обработки, чтобы можно было контролировать, кто может вносить изменения, а не только то, как должен выглядеть ресурс.

При осторожном использовании это эффективная мера контроля для операций с серьезными последствиями, особенно в сочетании со стандартными политиками управления конфигурацией и практиками поэтапного развертывания.

  • Last updated on