Użyj requestContext().identity, aby zwrócić tożsamość obiektu wywołującego w usłudze Azure Policy

Jeśli chcesz, aby zasady Azure Policy zachowywały się inaczej w zależności od tego, kto (lub tego, co) wysyła żądanie, użyj funkcji requestContext().identity.

Ta funkcja umożliwia inspekcję informacji o tożsamości wywołującej w czasie oceny zasad, dzięki czemu można pisać zasady, takie jak:

  • Zezwalaj tylko na zmiany inicjowane przez użytkownika dla poufnych typów zasobów
  • blokowanie aktualizacji niezatwierdzonych aplikacji klienckich
  • wymagaj silniejszego kontekstu uwierzytelniania (na przykład oznak użycia uwierzytelniania wieloskładnikowego) przed wykonaniem określonych operacji

Dlaczego ta funkcja ma znaczenie

Większość reguł zasad ocenia ładunek zasobu docelowego. Takie podejście dobrze sprawdza się przy wymuszaniu konfiguracji, ale nie dostarcza żadnych informacji o kodzie wywołującym.
requestContext().identity wypełnia tę lukę, udostępniając metadane tożsamości żądania w wyrażeniach reguł polityk.

Na wysokim poziomie można ocenić:

  • idtyp: typ tożsamości wywołującego (app, userlub null)
  • appid: identyfikator aplikacji klienckiej używany dla żądania
  • acrs: odwołania do klas kontekstu uwierzytelniania (używane do sprawdzania kontekstu logowania, takich jak wartości związane z MFA)
  • http://schemas.microsoft.com/identity/claims/objectidentifier: identyfikator obiektu elementu wywołującego (identyfikator obiektu użytkownika lub nazwy głównej usługi)

Ważna

Gdy używasz requestContext().identity, wymuszanie zasad przez usługę Azure Policy nadal odbywa się w momencie wysłania żądania (na przykład deny, modify i deployIfNotExists). Jednak skany zgodności dla tej zasady są oznaczone jako NotApplicable. Ten wzorzec jest najlepszy, gdy celem jest wymuszanie w czasie rzeczywistym przychodzących operacji tworzenia/aktualizacji, a nie raportowania zgodności po wdrożeniu.

Wzorzec: bezpieczny odczyt pól identyfikacyjnych za pomocą tryGet

W przypadku niektórych żądań może brakować oświadczeń tożsamości. Użyj tryGet(), aby wyrażenie nie kończyło się błędem, gdy brakuje klucza.

Example:

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

Przykład 1: zezwalanie tylko na zatwierdzone aplikacje klienckie

Ten przykład ogranicza operacje zapisu do żądań pochodzących z zdefiniowanej listy dozwolonych identyfikatorów aplikacji klienckich.

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

To ograniczenie jest przydatne w przypadku ochrony granic automatyzacji, dzięki czemu tylko zatwierdzone narzędzia wdrażania mogą modyfikować wybranych dostawców zasobów.

Oświadczenie acrs może zawierać wiele wartości rozdzielonych przecinkami. Użyj split(), aby je ocenić.

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

Dokładne wartości acrs zależą od konfiguracji tożsamości i dostępu warunkowego, dlatego przed szerokim wdrożeniem zweryfikuj oczekiwane wartości w dzierżawie.

Przykład 3: zakres według określonych identyfikatorów obiektów wywołujących

Oświadczenia identyfikatora obiektu można sprawdzić pod kątem precyzyjnej logiki zezwalania lub odmowy:

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

Ten wzorzec jest rygorystyczny i wyraźny, ale wymaga dobrej higieny operacyjnej, aby zachować bieżące listy tożsamości.

Porady dotyczące projektowania przed wdrożeniem produkcyjnym

  • Zacznij od audit lub przypisz przy wyłączonym wymuszaniu, aby zweryfikować działanie przed wymuszeniem deny.
  • Przeprowadź pilotaż w wąskim zakresie (pojedyncza grupa zasobów lub izolowana subskrypcja) przed przypisaniem na szeroką skalę. Aby dowiedzieć się więcej na temat najlepszych rozwiązań dotyczących wdrażania etapowego, zobacz Bezpieczne wdrażanie przypisań Azure Policy.
  • Jasno komunikuj zespołom ds. platformy i zabezpieczeń, że stan zgodności dla tych zasad to NotApplicable.
  • Połącz reguły oparte na tożsamości z zasadami konfiguracji zasobów, aby uzyskać wielowarstwowy nadzór.

Podsumowanie

requestContext().identityzapewnia Azure Policy rozpoznawanie tożsamości osoby wywołującej w czasie żądania, dzięki czemu można zarządzać tym, kto może wykonywać zmiany, a nie tylko jak powinien wyglądać zasób.

Stosowana rozważnie, stanowi skuteczny mechanizm kontroli w przypadku operacji o dużym wpływie, zwłaszcza w połączeniu ze standardowymi zasadami konfiguracyjnymi i praktykami etapowego wdrażania.

  • Last updated on