Omówienie efektów usługi Azure Policy

Każda definicja zasad w usłudze Azure Policy ma odzwierciedlenie w pojedynczym efekcie. Ten efekt określa, co się stanie, gdy reguła zasad zostanie oceniona jako zgodna. Efekty zachowują się inaczej, jeśli dotyczą nowego zasobu, zaktualizowanego zasobu lub istniejącego zasobu.

Te efekty są obecnie obsługiwane w definicji zasad:

Następujące efekty są przestarzałe:

Ważne

Zamiast efektów EnforceOPAConstraint lub EnforceRegoPolicy należy używać inspekcji i odmowy z trybem Microsoft.Kubernetes.Datadostawcy zasobów. Definicje zasad wbudowanych zostały zaktualizowane. Po zmodyfikowaniu istniejących przypisań zasad tych wbudowanych definicji zasad należy zmienić parametr efektu na wartość na zaktualizowanej liście allowedValues .

Kolejność obliczania

Żądania utworzenia lub zaktualizowania zasobu są najpierw oceniane przez usługę Azure Policy. Usługa Azure Policy tworzy listę wszystkich przydziałów, które mają zastosowanie do zasobu, a następnie zasób jest oceniany względem każdej definicji. W przypadku trybu Resource Manager Azure Policy przetwarza kilka efektów przed przekazaniem żądania do odpowiedniego dostawcy zasobów. Ta kolejność zapobiega niepotrzebnemu przetwarzaniu przez dostawcę zasobów, gdy zasób nie spełnia zaprojektowanych mechanizmów kontroli ładu Azure Policy. W trybie dostawcy zasobów dostawca zasobów zarządza oceną i wynikiem oraz raportuje wyniki z powrotem do Azure Policy.

  • Ustawienie Wyłączone jest sprawdzane jako pierwsze, aby określić, czy reguła zasad powinna być oceniana.
  • Następnie są oceniane wartości Dołączenia i Modyfikowania. Może to spowodować zmianę żądania, dlatego wprowadzona zmiana może uniemożliwić wyzwolenie efektu inspekcji lub odmowy. Te efekty są dostępne tylko w trybie Resource Manager.
  • Odmowa jest następnie oceniana. Ocena odmowy przed inspekcją zapobiega podwójnemu rejestrowaniu niepożądanego zasobu.
  • Inspekcja jest oceniana jako ostatnia.

Gdy dostawca zasobów zwróci kod powodzenia dla żądania trybu Resource Manager, auditIfNotExists i DeployIfNotExists ocenić, czy jest wymagane dodatkowe rejestrowanie zgodności, czy akcja.

Ponadto żądania, które modyfikują tags tylko powiązane pola, PATCH ograniczają ocenę zasad do zasad zawierających warunki, które sprawdzają tags powiązane pola.

Append

Dołączanie służy do dodawania dodatkowych pól do żądanego zasobu podczas tworzenia lub aktualizowania. Typowym przykładem jest określenie dozwolonych adresów IP dla zasobu magazynu.

Ważne

Funkcja Append jest przeznaczona do użytku z właściwościami niebędącymi tagami. Chociaż funkcja Append może dodawać tagi do zasobu podczas tworzenia lub aktualizowania żądania, zaleca się zamiast tego użycie efektu Modyfikuj dla tagów.

Dołączanie oceny

Dołączanie ocenia przed przetworzeniem żądania przez dostawcę zasobów podczas tworzenia lub aktualizowania zasobu. Dołączanie dodaje pola do zasobu, gdy warunek if reguły zasad jest spełniony. Jeśli efekt dołączania zastąpi wartość w oryginalnym żądaniu z inną wartością, działa jako efekt odmowy i odrzuca żądanie. Aby dołączyć nową wartość do istniejącej tablicy, użyj wersji aliasu [*].

Gdy definicja zasad używająca efektu dołączania jest uruchamiana w ramach cyklu oceny, nie wprowadza zmian w już istniejących zasobach. Zamiast tego oznacza każdy zasób spełniający warunek if jako niezgodny.

Dołączanie właściwości

Efekt dołączania ma tylko tablicę szczegółów , która jest wymagana. Ponieważ szczegóły są tablicą, może ona przyjmować pojedynczą parę pól/wartości lub wielokrotnych. Zapoznaj się z strukturą definicji , aby uzyskać listę dopuszczalnych pól.

Dołączanie przykładów

Przykład 1: Para pojedynczego pola/wartości używająca aliasu innego niż[*]z wartością tablicy w celu ustawienia reguł adresów IP na koncie magazynu. Gdy alias inny niż[*] jest tablicą, efekt dołącza wartość jako całą tablicę. Jeśli tablica już istnieje, zdarzenie odmowy występuje z konfliktu.

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
        "value": [{
            "action": "Allow",
            "value": "134.5.0.0/21"
        }]
    }]
}

Przykład 2: Para pojedynczego pola/wartości przy użyciu aliasu[*]z wartością tablicy w celu ustawienia reguł adresów IP na koncie magazynu. Za pomocą aliasu [*] efekt dołącza wartość do potencjalnie istniejącej tablicy. Jeśli tablica jeszcze nie istnieje, zostanie utworzona.

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]",
        "value": {
            "value": "40.40.40.40",
            "action": "Allow"
        }
    }]
}

Inspekcja

Inspekcja służy do tworzenia zdarzenia ostrzegawczego w dzienniku aktywności podczas oceniania niezgodnego zasobu, ale nie zatrzymuje żądania.

Ocena inspekcji

Inspekcja to ostatni efekt sprawdzany przez Azure Policy podczas tworzenia lub aktualizowania zasobu. W przypadku trybu Resource Manager Azure Policy następnie wysyła zasób do dostawcy zasobów. Podczas oceniania żądania utworzenia lub aktualizacji zasobu Azure Policy dodaje operację Microsoft.Authorization/policies/audit/action do dziennika aktywności i oznacza zasób jako niezgodny. Podczas standardowego cyklu oceny zgodności jest aktualizowany tylko stan zgodności zasobu.

Właściwości inspekcji

W przypadku trybu Resource Manager efekt inspekcji nie ma żadnych dodatkowych właściwości do użycia w warunku ówczesnej definicji zasad.

W przypadku trybu dostawcy zasobów efekt inspekcji Microsoft.Kubernetes.Datama następujące dodatkowe podwłaściwości szczegółów. Użycie elementu templateInfo jest wymagane w przypadku nowych lub zaktualizowanych definicji zasad, ponieważ constraintTemplate są przestarzałe.

  • templateInfo (wymagane)
    • Nie można używać z programem constraintTemplate.
    • sourceType (wymagane)
      • Definiuje typ źródła dla szablonu ograniczenia. Dozwolone wartości: PublicURL lub Base64Encoded.

      • Jeśli właściwość PublicURL została połączona z właściwością url w celu udostępnienia lokalizacji szablonu ograniczenia. Lokalizacja musi być publicznie dostępna.

        Ostrzeżenie

        Nie używaj identyfikatorów URI sygnatur dostępu współdzielonego, tokenów adresów URL ani żadnych innych elementów, które mogą uwidaczniać wpisy tajne w postaci zwykłego tekstu.

      • Jeśli Kodowanie Base64 jest sparowane z właściwością content w celu udostępnienia szablonu ograniczenia zakodowanego algorytmem base 64. Zobacz Tworzenie definicji zasad na podstawie szablonu ograniczenia, aby utworzyć definicję niestandardową na podstawie istniejącego szablonu ograniczenia programu GateKeeper v3 programu Open Policy Agent (OPA).

  • ograniczenie (przestarzałe)
    • Nie można używać z programem templateInfo.
    • Implementacja CRD szablonu ograniczenia. Używa parametrów przekazywanych za pośrednictwem wartości jako {{ .Values.<valuename> }}. W poniższym przykładzie 2 te wartości to {{ .Values.excludedNamespaces }} i {{ .Values.allowedContainerImagesRegex }}.
  • przestrzenie nazw (opcjonalnie)
    • Tablicaprzestrzeni nazw kubernetes, do których należy ograniczyć ocenę zasad.
    • Pusta lub brakująca wartość powoduje, że ocena zasad obejmuje wszystkie przestrzenie nazw, z wyjątkiem tych zdefiniowanych w wartości excludedNamespaces.
  • excludedNamespaces (wymagane)
  • labelSelector (wymagane)
    • Obiekt, który zawiera właściwości matchLabels (object) i matchExpression (tablica), aby umożliwić określenie, które zasoby Platformy Kubernetes mają być uwzględniane do oceny zasad pasujących do podanych etykiet i selektorów.
    • Pusta lub brakująca wartość powoduje, że ocena zasad obejmuje wszystkie etykiety i selektory, z wyjątkiem przestrzeni nazw zdefiniowanych w obszarze excludedNamespaces.
  • apiGroups (wymagane w przypadku korzystania z elementu templateInfo)
    • Tablica zawierająca grupy interfejsów API, które mają być zgodne. Pusta tablica ([""]) jest podstawową grupą interfejsów API.
    • Definiowanie ["*"] dla grup apiGroups jest niedozwolone.
  • rodzaje (wymagane podczas korzystania z szablonuInfo)
    • Tablica zawierająca rodzaj obiektu Kubernetes, do którego ma być ograniczona ocena.
    • Definiowanie ["*"]rodzajów jest niedozwolone.
  • wartości (opcjonalnie)
    • Definiuje wszystkie parametry i wartości, które mają być przekazywane do ograniczenia. Każda wartość musi istnieć w szablonie ograniczenia CRD.
  • constraintTemplate (przestarzałe)
    • Nie można używać z programem templateInfo.
    • Należy zastąpić elementem templateInfo podczas tworzenia lub aktualizowania definicji zasad.
    • Szablon ograniczenia CustomResourceDefinition (CRD), który definiuje nowe ograniczenia. Szablon definiuje logikę Rego, schemat ograniczenia i parametry ograniczenia przekazywane za pośrednictwem wartości z Azure Policy.

Przykład inspekcji

Przykład 1. Używanie efektu inspekcji dla trybów Resource Manager.

"then": {
    "effect": "audit"
}

Przykład 2. Użycie efektu inspekcji dla trybu dostawcy zasobów .Microsoft.Kubernetes.Data Dodatkowe informacje w pliku details.templateInfo deklarują użycie biblioteki PublicURL i ustawiają url lokalizację szablonu ograniczenia do użycia w usłudze Kubernetes w celu ograniczenia dozwolonych obrazów kontenerów.

"then": {
    "effect": "audit",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

AuditIfNotExists

AuditIfNotExists umożliwia inspekcję zasobów związanych z zasobem zgodnym z warunkiem if, ale nie mają właściwości określonych w szczegółachwarunku.

Ocena auditIfNotExists

Funkcja AuditIfNotExists jest uruchamiana po tym, jak dostawca zasobów obsłużył żądanie utworzenia lub aktualizacji zasobu i zwrócił kod stanu powodzenia. Inspekcja występuje, jeśli nie ma powiązanych zasobów lub czy zasoby zdefiniowane przez element ExistenceCondition nie są obliczane na wartość true. W przypadku nowych i zaktualizowanych zasobów Azure Policy dodaje operację Microsoft.Authorization/policies/audit/action do dziennika aktywności i oznacza zasób jako niezgodny. Po wyzwoleniu zasób spełniający warunek if jest zasobem oznaczonym jako niezgodny.

Właściwości AuditIfNotExists

Właściwość szczegółów efektów AuditIfNotExists ma wszystkie podwłaściwości definiujące powiązane zasoby do dopasowania.

  • Typ (wymagany)
    • Określa typ powiązanego zasobu do dopasowania.
    • Jeśli typ jest typem zasobu poniżej zasobu warunku if , zasady wysyłają zapytania dotyczące zasobów tego typu w zakresie ocenianego zasobu. W przeciwnym razie zapytania dotyczące zasad w ramach tej samej grupy zasobów lub subskrypcji co obliczony zasób w zależności od istnieniaScope.
  • Nazwa (opcjonalnie)
    • Określa dokładną nazwę zasobu do dopasowania i powoduje, że zasady pobierają jeden konkretny zasób zamiast wszystkich zasobów określonego typu.
    • Gdy wartości warunku dla parametru if.field.type , a następnie.details.type są zgodne , nazwa staje się wymagana i musi mieć [field('name')]wartość , lub [field('fullName')] dla zasobu podrzędnego. Należy jednak rozważyć efekt inspekcji .
  • ResourceGroupName (opcjonalnie)
    • Umożliwia dopasowanie powiązanego zasobu z innej grupy zasobów.
    • Nie ma zastosowania, jeśli typ to zasób, który znajduje się poniżej zasobu warunku if .
    • Wartość domyślna to jeśli grupa zasobów zasobu warunku.
  • ExistenceScope (opcjonalnie)
    • Dozwolone wartości to Subskrypcja i Grupa zasobów.
    • Ustawia zakres, z którego ma być pobierany powiązany zasób, z którego ma być zgodny.
    • Nie ma zastosowania, jeśli typ to zasób, który znajduje się poniżej zasobu warunku if .
    • W przypadku grupy zasobów należy ograniczyć wartość do grupy zasobów warunku lub grupy zasobów określonej w parametrze ResourceGroupName.
    • W obszarze Subskrypcja wysyła zapytanie do całej subskrypcji powiązanego zasobu. Zakres przydziału należy ustawić w subskrypcji lub wyższej w celu odpowiedniej oceny.
    • Wartość domyślna to ResourceGroup.
  • EvaluationDelay (opcjonalnie)
    • Określa, kiedy należy ocenić istnienie powiązanych zasobów. Opóźnienie jest używane tylko w przypadku ocen, które są wynikiem żądania utworzenia lub aktualizacji zasobu.
    • Dozwolone wartości to AfterProvisioning, , AfterProvisioningFailureAfterProvisioningSuccesslub ISO 8601 czas trwania od 0 do 360 minut.
    • Wartości AfterProvisioning sprawdzają wynik aprowizacji zasobu, który został oceniony w warunku IF reguły zasad. AfterProvisioning uruchamiane po zakończeniu aprowizacji, niezależnie od wyniku. Jeśli aprowizowanie trwa dłużej niż 6 godzin, jest traktowane jako błąd podczas określania opóźnień oceny po aprowizacji .
    • Wartość domyślna to PT10M (10 minut).
    • Określenie długiego opóźnienia oceny może spowodować, że zarejestrowany stan zgodności zasobu nie zostanie zaktualizowany do momentu następnego wyzwalacza oceny.
  • ExistenceCondition (opcjonalnie)
    • Jeśli nie zostanie określony, jakikolwiek powiązany zasób typu spełnia ten efekt i nie wyzwala inspekcji.
    • Używa tego samego języka co reguła zasad dla warunku if , ale jest obliczana dla każdego powiązanego zasobu indywidualnie.
    • Jeśli jakikolwiek pasujący zasób ma wartość true, efekt jest spełniony i nie wyzwala inspekcji.
    • Może użyć [field()] do sprawdzenia równoważności z wartościami w warunku if .
    • Na przykład można użyć do sprawdzenia, czy zasób nadrzędny (w warunku if ) znajduje się w tej samej lokalizacji zasobu co pasujący powiązany zasób.

Przykład auditIfNotExists

Przykład: ocenia Virtual Machines w celu ustalenia, czy rozszerzenie ochrony przed złośliwym kodem istnieje, a następnie przeprowadza inspekcję w przypadku braku.

{
    "if": {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
    },
    "then": {
        "effect": "auditIfNotExists",
        "details": {
            "type": "Microsoft.Compute/virtualMachines/extensions",
            "existenceCondition": {
                "allOf": [{
                        "field": "Microsoft.Compute/virtualMachines/extensions/publisher",
                        "equals": "Microsoft.Azure.Security"
                    },
                    {
                        "field": "Microsoft.Compute/virtualMachines/extensions/type",
                        "equals": "IaaSAntimalware"
                    }
                ]
            }
        }
    }
}

Zablokuj

Odmowa służy do zapobiegania żądaniu zasobu, które nie jest zgodne ze zdefiniowanymi standardami za pomocą definicji zasad i kończy się niepowodzeniem żądania.

Odmowa oceny

Podczas tworzenia lub aktualizowania dopasowanego zasobu w trybie Resource Manager odmowa uniemożliwia wysłanie żądania do dostawcy zasobów. Żądanie jest zwracane jako 403 (Forbidden). W portalu zabronione można wyświetlać jako stan wdrożenia, które zostało zablokowane przez przypisanie zasad. W przypadku trybu dostawcy zasobów dostawca zasobów zarządza oceną zasobu.

Podczas oceny istniejących zasobów zasoby zgodne z definicją zasad odmowy są oznaczone jako niezgodne.

Odmów właściwości

W przypadku trybu Resource Manager efekt odmowy nie ma żadnych dodatkowych właściwości do użycia w warunku następnie definicji zasad.

W przypadku trybu Microsoft.Kubernetes.Datadostawcy zasobów efekt odmowy ma następujące dodatkowe podwłaściwości szczegółów. templateInfo Użycie jest wymagane dla nowych lub zaktualizowanych definicji zasad, ponieważ constraintTemplate jest przestarzałe.

  • templateInfo (wymagane)
    • Nie można używać z programem constraintTemplate.
    • sourceType (wymagane)
      • Definiuje typ źródła dla szablonu ograniczenia. Dozwolone wartości: PublicURL lub Base64Encoded.

      • Jeśli publicURL, w połączeniu z właściwością url w celu udostępnienia lokalizacji szablonu ograniczenia. Lokalizacja musi być publicznie dostępna.

        Ostrzeżenie

        Nie używaj identyfikatorów URI sygnatury dostępu współdzielonego ani tokenów ani url żadnych innych elementów, które mogą ujawnić wpis tajny.

      • Jeśli Kodowanie Base64, w połączeniu z właściwością content w celu udostępnienia szablonu ograniczenia zakodowanego w formacie base 64. Zobacz Tworzenie definicji zasad na podstawie szablonu ograniczenia, aby utworzyć definicję niestandardową na podstawie istniejącego szablonu ograniczeniaopen policy Agent (OPA) GateKeeper v3.

  • ograniczenie (opcjonalnie)
    • Nie można używać z programem templateInfo.
    • Implementacja crD szablonu ograniczenia. Używa parametrów przekazywanych za pośrednictwem wartości jako {{ .Values.<valuename> }}. W przykładzie 2 poniżej te wartości to {{ .Values.excludedNamespaces }} i {{ .Values.allowedContainerImagesRegex }}.
  • przestrzenie nazw (opcjonalnie)
    • Tablicaprzestrzeni nazw Platformy Kubernetes w celu ograniczenia oceny zasad do.
    • Pusta lub brakująca wartość powoduje, że ocena zasad obejmuje wszystkie przestrzenie nazw, z wyjątkiem tych zdefiniowanych w wykluczonych przestrzeniachName.
  • excludedNamespaces (wymagane)
  • labelSelector (wymagane)
    • Obiekt, który zawiera właściwości matchLabels (object) i matchExpression (tablica), aby umożliwić określenie, które zasoby Kubernetes mają być uwzględniane do oceny zasad pasujących do podanych etykiet i selektorów.
    • Pusta lub brakująca wartość powoduje, że ocena zasad obejmuje wszystkie etykiety i selektory, z wyjątkiem przestrzeni nazw zdefiniowanych w wykluczonych przestrzeniachNamespaces.
  • apiGroups (wymagane podczas korzystania z szablonuInfo)
    • Tablica zawierająca grupy interfejsów API do dopasowania. Pusta tablica ([""]) to podstawowa grupa interfejsu API.
    • Definiowanie ["*"] dla grup apiGroups jest niedozwolone.
  • rodzaje (wymagane podczas korzystania z szablonuInfo)
    • Tablica zawierająca rodzaj obiektu Kubernetes, do którego ma być ograniczona ocena.
    • Definiowanie ["*"]rodzajów jest niedozwolone.
  • wartości (opcjonalnie)
    • Definiuje wszystkie parametry i wartości, które mają być przekazywane do ograniczenia. Każda wartość musi istnieć w szablonie ograniczenia CRD.
  • constraintTemplate (przestarzałe)
    • Nie można używać z programem templateInfo.
    • Należy zastąpić elementem templateInfo podczas tworzenia lub aktualizowania definicji zasad.
    • Szablon ograniczenia CustomResourceDefinition (CRD), który definiuje nowe ograniczenia. Szablon definiuje logikę Rego, schemat ograniczenia i parametry ograniczenia przekazywane za pośrednictwem wartości z Azure Policy. Zaleca się użycie nowszego templateInfo elementu w celu zastąpienia elementu constraintTemplate.

Przykład odmowy

Przykład 1. Używanie efektu odmowy dla trybów Resource Manager.

"then": {
    "effect": "deny"
}

Przykład 2. Użycie efektu odmowy dla trybu dostawcy zasobów .Microsoft.Kubernetes.Data Dodatkowe informacje w pliku details.templateInfo deklarują użycie biblioteki PublicURL i ustawiają url lokalizację szablonu ograniczenia do użycia w usłudze Kubernetes w celu ograniczenia dozwolonych obrazów kontenerów.

"then": {
    "effect": "deny",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

DeployIfNotExists

Podobnie jak AuditIfNotExists, definicja zasad DeployIfNotExists wykonuje wdrożenie szablonu po spełnieniu warunku. Przypisania zasad z ustawionym efektem jako DeployIfNotExists wymagają tożsamości zarządzanej do korygowania.

Uwaga

Szablony zagnieżdżone są obsługiwane przy użyciu funkcji deployIfNotExists, ale połączone szablony nie są obecnie obsługiwane.

Ocena deployIfNotExists

Funkcja DeployIfNotExists jest uruchamiana po konfigurowalnym opóźnieniu, gdy dostawca zasobów obsługuje żądanie utworzenia lub aktualizacji subskrypcji lub zasobu i zwrócił kod stanu powodzenia. Wdrożenie szablonu występuje, jeśli nie ma powiązanych zasobów lub jeśli zasoby zdefiniowane przez element ExistenceCondition nie są obliczane na wartość true. Czas trwania wdrożenia zależy od złożoności zasobów zawartych w szablonie.

Podczas cyklu oceny definicje zasad z efektem DeployIfNotExists, które pasują do zasobów są oznaczone jako niezgodne, ale żadne działania nie są podejmowane w tym zasobie. Istniejące niezgodne zasoby można skorygować za pomocą zadania korygowania.

Właściwości DeployIfNotExists

Właściwość szczegółów efektu DeployIfNotExists ma wszystkie podwłaściwości definiujące powiązane zasoby do dopasowania i wdrożenia szablonu do wykonania.

  • Typ (wymagany)

    • Określa typ powiązanego zasobu do dopasowania.
    • Jeśli typ jest typem zasobu poniżej zasobu warunku if , zasady wysyłają zapytania dotyczące zasobów tego typu w zakresie ocenianego zasobu. W przeciwnym razie zapytania dotyczące zasad w ramach tej samej grupy zasobów lub subskrypcji co obliczony zasób w zależności od istnieniaScope.
  • Nazwa (opcjonalnie)

    • Określa dokładną nazwę zasobu do dopasowania i powoduje, że zasady pobierają jeden konkretny zasób zamiast wszystkich zasobów określonego typu.
    • Gdy wartości warunku dla parametru if.field.type , a następnie.details.type są zgodne , nazwa staje się wymagana i musi mieć [field('name')]wartość , lub [field('fullName')] dla zasobu podrzędnego.
  • ResourceGroupName (opcjonalnie)

    • Umożliwia dopasowanie powiązanego zasobu z innej grupy zasobów.
    • Nie ma zastosowania, jeśli typ to zasób, który znajduje się poniżej zasobu warunku if .
    • Wartość domyślna to jeśli grupa zasobów zasobu warunku.
    • Jeśli wdrożenie szablonu zostanie wykonane, zostanie wdrożone w grupie zasobów tej wartości.
  • ExistenceScope (opcjonalnie)

    • Dozwolone wartości to Subskrypcja i Grupa zasobów.
    • Ustawia zakres, z którego ma być pobierany powiązany zasób, z którego ma być zgodny.
    • Nie ma zastosowania, jeśli typ to zasób, który znajduje się poniżej zasobu warunku if .
    • W przypadku grupy zasobów należy ograniczyć wartość do grupy zasobów warunku lub grupy zasobów określonej w parametrze ResourceGroupName.
    • W obszarze Subskrypcja wysyła zapytanie do całej subskrypcji powiązanego zasobu. Zakres przydziału należy ustawić w subskrypcji lub wyższej w celu odpowiedniej oceny.
    • Wartość domyślna to ResourceGroup.
  • EvaluationDelay (opcjonalnie)

    • Określa, kiedy należy ocenić istnienie powiązanych zasobów. Opóźnienie jest używane tylko w przypadku ocen, które są wynikiem żądania utworzenia lub aktualizacji zasobu.
    • Dozwolone wartości to AfterProvisioning, , AfterProvisioningFailureAfterProvisioningSuccesslub ISO 8601 czas trwania od 0 do 360 minut.
    • Wartości AfterProvisioning sprawdzają wynik aprowizacji zasobu, który został oceniony w warunku IF reguły zasad. AfterProvisioning uruchamiane po zakończeniu aprowizacji, niezależnie od wyniku. Jeśli aprowizowanie trwa dłużej niż 6 godzin, jest traktowane jako błąd podczas określania opóźnień oceny po aprowizacji .
    • Wartość domyślna to PT10M (10 minut).
    • Określenie długiego opóźnienia oceny może spowodować, że zarejestrowany stan zgodności zasobu nie zostanie zaktualizowany do momentu następnego wyzwalacza oceny.
  • ExistenceCondition (opcjonalnie)

    • Jeśli nie zostanie określony, dowolny powiązany zasób typu spełnia ten efekt i nie wyzwala wdrożenia.
    • Używa tego samego języka co reguła zasad dla warunku if , ale jest obliczana dla każdego powiązanego zasobu indywidualnie.
    • Jeśli jakikolwiek pasujący zasób ma wartość true, efekt jest spełniony i nie powoduje wyzwolenia wdrożenia.
    • Może użyć [field()] do sprawdzenia równoważności z wartościami w warunku if .
    • Na przykład można użyć do sprawdzenia, czy zasób nadrzędny (w warunku if ) znajduje się w tej samej lokalizacji zasobu co pasujący powiązany zasób.
  • roleDefinitionIds (wymagane)

    • Ta właściwość musi zawierać tablicę ciągów pasujących do identyfikatora roli kontroli dostępu opartej na rolach dostępnego dla subskrypcji. Aby uzyskać więcej informacji, zobacz Korygowanie — konfigurowanie definicji zasad.
  • DeploymentScope (opcjonalnie)

    • Dozwolone wartości to Subskrypcja i Grupa zasobów.
    • Ustawia typ wdrożenia, który ma zostać wyzwolony. Subskrypcja wskazuje wdrożenie na poziomie subskrypcji, grupa zasobów wskazuje wdrożenie w grupie zasobów.
    • Właściwość lokalizacji musi być określona we wdrożeniu podczas korzystania z wdrożeń na poziomie subskrypcji.
    • Wartość domyślna to ResourceGroup.
  • Wdrożenie (wymagane)

    • Ta właściwość powinna zawierać pełne wdrożenie szablonu, ponieważ zostanie przekazane do interfejsu Microsoft.Resources/deployments API PUT. Aby uzyskać więcej informacji, zobacz interfejs API REST wdrożenia.
    • Microsoft.Resources/deployments Zagnieżdżone w szablonie powinny używać unikatowych nazw, aby uniknąć rywalizacji między wieloma ocenami zasad. Nazwa wdrożenia nadrzędnego może być używana jako część nazwy wdrożenia zagnieżdżonego za pomocą metody [concat('NestedDeploymentName-', uniqueString(deployment().name))].

    Uwaga

    Wszystkie funkcje wewnątrz właściwości Deployment są oceniane jako składniki szablonu, a nie zasady. Wyjątkiem jest właściwość parameters , która przekazuje wartości z zasad do szablonu. Wartość w tej sekcji w nazwie parametru szablonu służy do przekazywania tej wartości (zobacz fullDbName w przykładzie DeployIfNotExists).

Przykład deployIfNotExists

Przykład: ocenia SQL Server baz danych w celu określenia, czy funkcja transparentDataEncryption jest włączona. Jeśli nie, zostanie wykonane wdrożenie do włączenia.

"if": {
    "field": "type",
    "equals": "Microsoft.Sql/servers/databases"
},
"then": {
    "effect": "DeployIfNotExists",
    "details": {
        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
        "name": "current",
        "evaluationDelay": "AfterProvisioning",
        "roleDefinitionIds": [
            "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
            "/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
        ],
        "existenceCondition": {
            "field": "Microsoft.Sql/transparentDataEncryption.status",
            "equals": "Enabled"
        },
        "deployment": {
            "properties": {
                "mode": "incremental",
                "template": {
                    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {
                        "fullDbName": {
                            "type": "string"
                        }
                    },
                    "resources": [{
                        "name": "[concat(parameters('fullDbName'), '/current')]",
                        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
                        "apiVersion": "2014-04-01",
                        "properties": {
                            "status": "Enabled"
                        }
                    }]
                },
                "parameters": {
                    "fullDbName": {
                        "value": "[field('fullName')]"
                    }
                }
            }
        }
    }
}

Disabled

Ten efekt jest przydatny w przypadku testowania sytuacji lub gdy definicja zasad sparametryzowała efekt. Ta elastyczność umożliwia wyłączenie pojedynczego przypisania zamiast wyłączania wszystkich przypisań tych zasad.

Alternatywą dla efektu Wyłączone jest wymuszanieMode, które jest ustawione w przypisaniu zasad. Gdy funkcja enforcementMode jest wyłączona, zasoby są nadal oceniane. Rejestrowanie, takie jak dzienniki aktywności, i efekt zasad nie występuje. Aby uzyskać więcej informacji, zobacz przypisywanie zasad — tryb wymuszania.

EnforceOPAConstraint

Ten efekt jest używany z trybem definicji zasad .Microsoft.Kubernetes.Data Służy do przekazywania reguł kontroli dostępu gatekeeper w wersji 3 zdefiniowanej za pomocą platformy OPA Constraint Framework do otwierania agenta zasad (OPA) do klastrów Kubernetes na platformie Azure.

Ważne

Ograniczone definicje zasad w wersji zapoznawczej z efektem EnforceOPAConstraint i powiązana kategoria usługi Kubernetes Serviceprzestarzałe. Zamiast tego użyj efektów inspekcji i odmowy w trybie Microsoft.Kubernetes.Datadostawcy zasobów .

Wymuszanie oceny USŁUGIOPAConstraint

Kontroler wpływu agenta zasad open policy ocenia każde nowe żądanie w klastrze w czasie rzeczywistym. Co 15 minut zostanie ukończone pełne skanowanie klastra i wyniki zgłoszone do Azure Policy.

Wymuszanie właściwościOPAConstraint

Właściwość details efektu EnforceOPAConstraint ma podwłaściwości opisujące regułę kontroli wpływu danych programu Gatekeeper w wersji 3.

  • constraintTemplate (wymagane)
    • Szablon ograniczenia CustomResourceDefinition (CRD), który definiuje nowe ograniczenia. Szablon definiuje logikę Rego, schemat ograniczenia i parametry ograniczenia przekazywane za pośrednictwem wartości z Azure Policy.
  • ograniczenie (wymagane)
    • Implementacja CRD szablonu ograniczenia. Używa parametrów przekazywanych za pośrednictwem wartości jako {{ .Values.<valuename> }}. W poniższym przykładzie te wartości to {{ .Values.cpuLimit }} i {{ .Values.memoryLimit }}.
  • wartości (opcjonalnie)
    • Definiuje wszystkie parametry i wartości, które mają być przekazywane do ograniczenia. Każda wartość musi istnieć w szablonie ograniczenia CRD.

Przykład enforceOPAConstraint

Przykład: Reguła kontroli wpływu bramy w wersji 3 w celu ustawienia limitów zasobów procesora CPU i pamięci kontenera na platformie Kubernetes.

"if": {
    "allOf": [
        {
            "field": "type",
            "in": [
                "Microsoft.ContainerService/managedClusters",
                "AKS Engine"
            ]
        },
        {
            "field": "location",
            "equals": "westus2"
        }
    ]
},
"then": {
    "effect": "enforceOPAConstraint",
    "details": {
        "constraintTemplate": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-resource-limits/template.yaml",
        "constraint": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-resource-limits/constraint.yaml",
        "values": {
            "cpuLimit": "[parameters('cpuLimit')]",
            "memoryLimit": "[parameters('memoryLimit')]"
        }
    }
}

EnforceRegoPolicy

Ten efekt jest używany z trybem definicji zasad .Microsoft.ContainerService.Data Służy do przekazywania reguł kontroli wpływu danych programu Gatekeeper w wersji 2 zdefiniowanej za pomocą programu Rego do otwierania agenta zasad (OPA) w Azure Kubernetes Service.

Ważne

Ograniczone definicje zasad w wersji zapoznawczej z efektem EnforceRegoPolicy i powiązaną kategorią usługi Kubernetes Serviceprzestarzałe. Zamiast tego należy użyć funkcji inspekcji efektów i odmowy w trybie Microsoft.Kubernetes.Datadostawcy zasobów.

Ocena EnforceRegoPolicy

Kontroler wpływu agenta zasad open policy ocenia każde nowe żądanie w klastrze w czasie rzeczywistym. Co 15 minut zostanie ukończone pełne skanowanie klastra i wyniki zgłoszone do Azure Policy.

EnforceRegoPolicy properties (Właściwości EnforceRegoPolicy)

Właściwość details efektu EnforceRegoPolicy ma podwłaściwości opisujące regułę kontroli wpływu danych strażnika w wersji 2.

  • policyId (wymagane)
    • Unikatowa nazwa przekazana jako parametr do reguły kontroli wpływu danych rego.
  • zasady (wymagane)
    • Określa identyfikator URI reguły kontroli wpływu danych rego.
  • policyParameters (opcjonalnie)
    • Definiuje wszystkie parametry i wartości, które mają być przekazywane do zasad rego.

Przykład enforceRegoPolicy

Przykład: reguła kontroli wpływu bramy w wersji 2 zezwalająca tylko na określone obrazy kontenerów w usłudze AKS.

"if": {
    "allOf": [
        {
            "field": "type",
            "equals": "Microsoft.ContainerService/managedClusters"
        },
        {
            "field": "location",
            "equals": "westus2"
        }
    ]
},
"then": {
    "effect": "EnforceRegoPolicy",
    "details": {
        "policyId": "ContainerAllowedImages",
        "policy": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/KubernetesService/container-allowed-images/limited-preview/gatekeeperpolicy.rego",
        "policyParameters": {
            "allowedContainerImagesRegex": "[parameters('allowedContainerImagesRegex')]"
        }
    }
}

Ręczne (wersja zapoznawcza)

manual Nowy efekt (wersja zapoznawcza) umożliwia definiowanie i śledzenie własnych niestandardowych zasobów zaświadczania. W przeciwieństwie do innych definicji zasad, które aktywnie skanują pod kątem oceny, efekt ręczny umożliwia ręczne zmiany stanu zgodności. Aby zmienić zgodność dla zasad ręcznych, należy utworzyć zaświadczenie dla tego stanu zgodności.

Uwaga

W publicznej wersji zapoznawczej obsługa zasad ręcznych jest dostępna za pośrednictwem różnych Microsoft Defender inicjatyw dotyczących zgodności z przepisami w chmurze. Jeśli jesteś Microsoft Defender dla klienta w warstwie Premium w chmurze, zapoznaj się z ich omówieniem.

Obecnie następujące inicjatywy zasad regulacyjnych obejmują definicje zasad zawierające efekt ręczny:

  • FedRAMP High
  • FedRAMP Medium
  • HIPAA
  • HITRUST
  • ISO 27001
  • Microsoft CIS 1.3.0
  • Microsoft CIS 1.4.0
  • NIST SP 800-171 rev. 2
  • NIST SP 800-53 rev. 4
  • NIST SP 800-53 rev. 5
  • PCI DSS 3.2.1
  • PCI DSS 4.0
  • SOC TSP
  • SWIFT CSP CSCF v2022

Poniższy przykład dotyczy subskrypcji platformy Azure i ustawia początkowy stan zgodności na Unknownwartość .

{
  "if": {
    "field":  "type",
    "equals": "Microsoft.Resources/subscriptions"
  },
  "then": {
    "effect": "manual",
    "details": {
      "defaultState": "Unknown"
    }
  }
}

Właściwość defaultState ma trzy możliwe wartości:

  • Nieznany: początkowy, domyślny stan zasobów docelowych.
  • Zgodne: zasób jest zgodny ze standardami zasad ręcznych
  • Niezgodne: zasób jest niezgodny zgodnie ze standardami zasad ręcznych

Aparat zgodności Azure Policy ocenia wszystkie odpowiednie zasoby do stanu domyślnego określonego w definicji (Unknown jeśli nie zostanie określony). Stan Unknown zgodności wskazuje, że należy ręcznie potwierdzić stan zgodności zasobów. Jeśli stan efektu jest nieokreślony, wartość domyślna to Unknown. Stan Unknown zgodności wskazuje, że musisz potwierdzić stan zgodności samodzielnie.

Poniższy zrzut ekranu przedstawia sposób ręcznego przypisania zasad ze stanem Unknown w Azure Portal:

Tabela zgodności zasobów w Azure Portal przedstawiająca przypisane zasady ręczne z przyczyną zgodności

Po przypisaniu definicji zasad z manual efektem można uwzględnić dowody, które odnoszą się do opcjonalnych informacji uzupełniających, które obsługują niestandardowe zaświadczania zgodności. Dowody są przechowywane w usłudze Azure Storage i można określić kontener obiektów blob magazynu w metadanych przypisania zasad w ramach właściwości evidenceStorages. Więcej szczegółów dotyczących pliku dowodowego opisano w zasobie JSON zaświadczania.

Atesty

Microsoft.PolicyInsights/attestations, nazywany zasobem zaświadczania, to nowy typ zasobu serwera proxy, który ustawia stany zgodności dla zasobów docelowych w zasadach ręcznych. Dowiedz się więcej o zasobie zaświadczania, czytając Azure Policy strukturę zaświadczania.

Modyfikowanie

Modyfikowanie służy do dodawania, aktualizowania lub usuwania właściwości lub tagów w subskrypcji lub zasobie podczas tworzenia lub aktualizowania. Typowym przykładem jest aktualizowanie tagów zasobów, takich jak costCenter. Istniejące niezgodne zasoby można skorygować za pomocą zadania korygowania. Pojedyncza reguła Modify może mieć dowolną liczbę operacji. Przypisania zasad z ustawionym efektem jako Modyfikuj wymagają tożsamości zarządzanej w celu skorygowania.

Następujące operacje są obsługiwane przez funkcję Modyfikuj:

  • Dodawanie, zastępowanie lub usuwanie tagów zasobów. W przypadku tagów zasady Modyfikowanie powinny mieć mode ustawioną wartość Indeksowane , chyba że zasób docelowy jest grupą zasobów.
  • Dodaj lub zastąp wartość typu tożsamości zarządzanej (identity.type) maszyn wirtualnych i zestawów skalowania maszyn wirtualnych.
  • Dodaj lub zastąp wartości niektórych aliasów.
    • ZastosowanieGet-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' }w Azure PowerShell 4.6.0 lub nowszej, aby uzyskać listę aliasów, których można używać z funkcją Modify.

Ważne

Jeśli zarządzasz tagami, zaleca się używanie polecenia Modify zamiast Dołączanie jako Modyfikuj zapewnia dodatkowe typy operacji i możliwość korygowania istniejących zasobów. Jednak opcja Append jest zalecana, jeśli nie możesz utworzyć tożsamości zarządzanej lub opcja Modyfikuj nie obsługuje jeszcze aliasu dla właściwości zasobu.

Modyfikowanie oceny

Zmodyfikuj ocenę przed przetworzeniem żądania przez dostawcę zasobów podczas tworzenia lub aktualizowania zasobu. Operacje Modyfikowanie są stosowane do zawartości żądania, gdy warunek reguły zasad jest spełniony. Każda operacja Modyfikowanie może określać warunek, który określa, kiedy jest stosowany. Operacje z ocenami warunku false są pomijane.

Po określeniu aliasu są wykonywane następujące dodatkowe kontrole, aby upewnić się, że operacja Modyfikowanie nie zmienia zawartości żądania w sposób, który powoduje odrzucenie go przez dostawcę zasobów:

  • Właściwość mapowania aliasu na jest oznaczona jako "Modyfikowalna" w wersji interfejsu API żądania.
  • Typ tokenu w operacji Modify jest zgodny z oczekiwanym typem tokenu dla właściwości w wersji interfejsu API żądania.

Jeśli którykolwiek z tych testów zakończy się niepowodzeniem, ocena zasad powróci do określonego konfliktuWynik.

Ważne

Zaleca się zmodyfikowanie definicji zawierających aliasy, które korzystają z efektu konfliktuinspekcji, aby uniknąć niepowodzeń żądań przy użyciu wersji interfejsu API, w których właściwość mapowana nie jest "modyfikowalna". Jeśli ten sam alias zachowuje się inaczej między wersjami interfejsu API, operacje modyfikowania warunkowego mogą służyć do określenia operacji modyfikowania używanej dla każdej wersji interfejsu API.

Jeśli definicja zasad używająca efektu Modyfikuj jest uruchamiana w ramach cyklu oceny, nie wprowadza ona zmian w już istniejących zasobach. Zamiast tego oznacza każdy zasób spełniający warunek if jako niezgodny.

Modyfikowanie właściwości

Właściwość details efektu Modify ma wszystkie podwłaściwości, które definiują uprawnienia wymagane do korygowania i operacji używanych do dodawania, aktualizowania lub usuwania wartości tagów.

  • roleDefinitionIds (wymagane)
    • Ta właściwość musi zawierać tablicę ciągów pasujących do identyfikatora roli kontroli dostępu opartej na rolach dostępnego dla subskrypcji. Aby uzyskać więcej informacji, zobacz Korygowanie — konfigurowanie definicji zasad.
    • Zdefiniowana rola musi zawierać wszystkie operacje przyznane roli Współautor .
  • conflictEffect (opcjonalnie)
    • Określa definicję zasad "wins", jeśli więcej niż jedna definicja zasad modyfikuje tę samą właściwość lub gdy operacja Modify nie działa na określonym aliasie.
      • W przypadku nowych lub zaktualizowanych zasobów pierwszeństwo ma definicja zasad z odmową . Definicje zasad z inspekcją pomijają wszystkie operacje. Jeśli więcej niż jedna definicja zasad ma odmowę, żądanie zostanie odrzucone jako konflikt. Jeśli wszystkie definicje zasad mają inspekcję, żadne operacje definicji zasad powodujących konflikt nie są przetwarzane.
      • W przypadku istniejących zasobów, jeśli więcej niż jedna definicja zasad ma odmowę, stan zgodności to Konflikt. Jeśli co najmniej jedna definicja zasad ma odmowę, każde przypisanie zwraca stan zgodności Niezgodne.
    • Dostępne wartości: inspekcja, odmowa, wyłączone.
    • Wartość domyślna to odmów.
  • operacje (wymagane)
    • Tablica wszystkich operacji tagów, które mają zostać ukończone dla pasujących zasobów.
    • Właściwości:
      • operacja (wymagana)
        • Definiuje akcję do wykonania dla pasującego zasobu. Dostępne opcje to : addOrReplace, Add, Remove. Funkcja Add zachowuje się podobnie do efektu Dołączanie .
      • pole (wymagane)
        • Tag do dodawania, zastępowania lub usuwania. Nazwy tagów muszą być zgodne z tą samą konwencją nazewnictwa dla innych pól.
      • wartość (opcjonalnie)
        • Wartość do ustawienia tagu na .
        • Ta właściwość jest wymagana, jeśli operacja to addOrReplace lub Add.
      • warunek (opcjonalnie)
        • Ciąg zawierający wyrażenie języka Azure Policy z funkcjami zasad, które daje w wyniku wartość true lub false.
        • Nie obsługuje następujących funkcji zasad: field(), resourceGroup(), subscription().

Modyfikowanie operacji

Tablica właściwości operations umożliwia zmianę kilku tagów na różne sposoby od jednej definicji zasad. Każda operacja składa się z właściwości operacji, pola i wartości . Operacja określa, co zadanie korygowania wykonuje do tagów, pole określa, który tag jest zmieniany, a wartość definiuje nowe ustawienie dla tego tagu. Poniższy przykład wprowadza następujące zmiany tagów:

  • environment Ustawia tag na "Test", nawet jeśli już istnieje z inną wartością.
  • Usuwa tag TempResource.
  • Dept Ustawia tag na parametr zasad DeptName skonfigurowany w przypisaniu zasad.
"details": {
    ...
    "operations": [
        {
            "operation": "addOrReplace",
            "field": "tags['environment']",
            "value": "Test"
        },
        {
            "operation": "Remove",
            "field": "tags['TempResource']",
        },
        {
            "operation": "addOrReplace",
            "field": "tags['Dept']",
            "value": "[parameters('DeptName')]"
        }
    ]
}

Właściwość operation ma następujące opcje:

Operacja Opis
addOrReplace Dodaje zdefiniowaną właściwość lub tag i wartość do zasobu, nawet jeśli właściwość lub tag już istnieje z inną wartością.
Dodaj Dodaje zdefiniowaną właściwość lub tag i wartość do zasobu.
Usuń Usuwa zdefiniowaną właściwość lub tag z zasobu.

Modyfikowanie przykładów

Przykład 1: Dodaj environment tag i zastąp istniejące environment tagi ciągiem "Test":

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "operations": [
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "Test"
            }
        ]
    }
}

Przykład 2: Usunięcie tagu env i dodanie tagu environment lub zastąpienie istniejących environment tagów wartością sparametryzowaną:

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "conflictEffect": "deny",
        "operations": [
            {
                "operation": "Remove",
                "field": "tags['env']"
            },
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "[parameters('tagValue')]"
            }
        ]
    }
}

Przykład 3: Upewnij się, że konto magazynu nie zezwala na publiczny dostęp do obiektu blob, operacja Modyfikowanie jest stosowana tylko podczas oceniania żądań za pomocą interfejsu API w wersji nowszej lub równej "2019-04-01":

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
        ],
        "conflictEffect": "audit",
        "operations": [
            {
                "condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
                "operation": "addOrReplace",
                "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
                "value": false
            }
        ]
    }
}

Definicje zasad warstw

Na zasób może mieć wpływ kilka przypisań. Te przypisania mogą być w tym samym zakresie lub w różnych zakresach. Każde z tych przypisań może również mieć inny efekt. Warunek i efekt dla każdej zasady są oceniane niezależnie. Przykład:

  • Zasady 1
    • Ogranicza lokalizację zasobu do lokalizacji "westus"
    • Przypisano do subskrypcji A
    • Efekt odmowy
  • Zasady 2
    • Ogranicza lokalizację zasobu do lokalizacji "eastus"
    • Przypisane do grupy zasobów B w subskrypcji A
    • Efekt inspekcji

Taka konfiguracja spowoduje następujący wynik:

  • Każdy zasób już w grupie zasobów B w "eastus" jest zgodny z zasadami 2 i niezgodny z zasadami 1
  • Każdy zasób już w grupie zasobów B nie w "eastus" jest niezgodny z zasadami 2 i niezgodny z zasadami 1, jeśli nie w "westus"
  • Każdy nowy zasób w subskrypcji A nie w "westus" jest odrzucany przez zasady 1
  • Każdy nowy zasób w subskrypcji A i grupie zasobów B w "westus" jest tworzony i niezgodny w zasadach 2

Jeśli obie zasady 1 i zasady 2 miały wpływ na odmowę, sytuacja się zmienia:

  • Każdy zasób już w grupie zasobów B w "eastus" nie jest zgodny z zasadami 2
  • Każdy zasób w grupie zasobów B, który nie znajduje się w "westus", jest niezgodny z zasadami 1
  • Każdy nowy zasób w subskrypcji A nie w "westus" jest odrzucany przez zasady 1
  • Każdy nowy zasób w grupie zasobów B subskrypcji A jest odrzucany

Każde przypisanie jest oceniane indywidualnie. W związku z tym nie ma możliwości, aby zasób prześlizgnął się przez lukę z różnic w zakresie. Wynik netto definicji zasad warstwowych jest uważany za skumulowany najbardziej restrykcyjny. Jeśli na przykład zasady 1 i 2 miały efekt odmowy, zasób zostanie zablokowany przez nakładające się i powodujące konflikt definicje zasad. Jeśli nadal potrzebujesz zasobu do utworzenia w zakresie docelowym, przejrzyj wykluczenia dla każdego przypisania, aby sprawdzić, czy odpowiednie przypisania zasad mają wpływ na odpowiednie zakresy.

Następne kroki