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:

Interchanging effects (Interchanging effects)

Czasami wiele efektów może być prawidłowych dla danej definicji zasad. Parametry są często używane do określania dozwolonych wartości efektów, dzięki czemu pojedyncza definicja może być bardziej wszechstronna. Należy jednak pamiętać, że nie wszystkie efekty są wymienne. Właściwości zasobów i logika w regule zasad mogą określić, czy określony efekt jest uznawany za prawidłowy dla definicji zasad. Na przykład definicje zasad z efektem AuditIfNotExists wymagają dodatkowych szczegółów w regule zasad, które nie są wymagane dla zasad z efektem Inspekcja. Efekty zachowują się również inaczej. Zasady inspekcji ocenią zgodność zasobu na podstawie własnych właściwości, a zasady AuditIfNotExists ocenią zgodność zasobu na podstawie właściwości zasobu podrzędnego lub rozszerzenia.

Poniżej przedstawiono kilka ogólnych wskazówek dotyczących wymiennych efektów:

  • Inspekcja, Odmów i Modyfikowanie lub Dołączanie są często zamienne.
  • AuditIfNotExists i DeployIfNotExists są często zamienne.
  • Instrukcja nie jest wymienna.
  • Wyłączone jest zamienne z każdym skutkiem.

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 ograniczeniaprogramu Open Policy Agent (OPA) Gatekeeper v3.

  • 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 uwzględnia wszystkie przestrzenie nazw niezdefiniowane w wykluczonych przestrzeniach nazw.
  • 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.

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.

Uwaga

Definicje zasad używające efektu Wyłączone mają domyślny stan zgodności Zgodne po przypisaniu.

Alternatywą dla efektu Wyłączone jest wymuszanieMode, które jest ustawione w przypisaniu zasad. Gdy funkcja enforcementMode ma wartość Disabled_**, 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.

Ręczne (wersja zapoznawcza)

Nowy manual efekt (wersja zapoznawcza) umożliwia samodzielne potwierdzanie zgodności zasobów lub zakresów. 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ść zasobu lub zakresu objętego zasadami ręcznymi, należy utworzyć zaświadczenie. Najlepszym rozwiązaniem jest zaprojektowanie zasad ręcznych przeznaczonych dla zakresu definiującego granicę zasobów, których zgodność wymaga zaświadczania.

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 ustawić stany zgodności docelowych zasobów lub zakresów za pomocą niestandardowych zaświadczeń. Zaświadczania umożliwiają również podawanie opcjonalnych informacji uzupełniających za pośrednictwem postaci metadanych i linków do dowodów towarzyszących wybranemu stanowi zgodności. Osoba przypisując zasady ręczne może zalecić domyślną lokalizację przechowywania dowodów, określając evidenceStorages właściwość metadanych przypisania zasad.

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 Virtual Machine Scale Sets.
  • 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 wpływ na odmowę, żądanie zostanie odrzucone jako konflikt. Jeśli wszystkie definicje zasad mają inspekcję, żadne operacje definicji zasad powodujących konflikt nie są przetwarzane.
      • Jeśli w przypadku istniejących zasobów więcej niż jedna definicja zasad ma efekt odmowy, stan zgodności to Konflikt. Jeśli co najmniej jedna definicja zasad ma efekt odmowy, 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 operacji umożliwia zmianę kilku tagów na różne sposoby z 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 dla 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 tagu:

  • 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: Usuń env tag i dodaj environment tag lub zastąp istniejące environment tagi 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 Modyfikuj jest stosowana tylko podczas oceniania żądań z wersją interfejsu API większą lub równą "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 warstwowania

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 wpływ. 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 "eastus"
    • Przypisano do grupy zasobów B w subskrypcji A
    • Efekt inspekcji

Ta konfiguracja spowoduje następujący wynik:

  • Każdy zasób 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 zarówno zasady 1, jak i zasady 2 miały wpływ na odmowę, sytuacja zmieni się na:

  • Każdy zasób już w grupie zasobów B w "eastus" nie jest zgodny z zasadami 2
  • Żaden zasób już w grupie zasobów B w "westus" nie jest zgodny z zasadami 1
  • Każdy nowy zasób w subskrypcji A nie w "westus" jest odrzucany przez zasady 1
  • Odmowa dowolnego nowego zasobu w grupie zasobów B subskrypcji A

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. Na przykład jeśli 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