Struktura przypisań usługi Azure Policy

Przypisania zasad są używane przez usługę Azure Policy do definiowania, które zasoby są przypisywane do zasad lub inicjatyw. Przypisanie zasad może określić wartości parametrów dla tej grupy zasobów w czasie przypisania, dzięki czemu można ponownie użyć definicji zasad, które odpowiadają tym samym właściwościom zasobu z różnymi potrzebami w zakresie zgodności.

Uwaga

Aby uzyskać więcej informacji na temat zakresu usługi Azure Policy, zobacz Omówienie zakresu w usłudze Azure Policy.

Aby utworzyć przypisanie zasad, należy użyć notacji obiektów Języka JavaScript (JSON). Przypisanie zasad zawiera elementy dla:

Na przykład poniższy kod JSON przedstawia przypisanie zasad w trybie DoNotEnforce z parametrami dynamicznymi:

{
    "properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "metadata": {
            "assignedBy": "Cloud Center of Excellence"
        },
        "enforcementMode": "DoNotEnforce",
        "notScopes": [],
        "policyDefinitionId": "/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyDefinitions/ResourceNaming",
        "nonComplianceMessages": [
            {
                "message": "Resource names must start with 'DeptA' and end with '-LC'."
            }
        ],
        "parameters": {
            "prefix": {
                "value": "DeptA"
            },
            "suffix": {
                "value": "-LC"
            }
        },
        "identity": {
            "type": "SystemAssigned"
        },
        "resourceSelectors": [],
        "overrides": []
    }
}

Wszystkie przykłady usługi Azure Policy znajdują się w przykładach usługi Azure Policy.

Nazwa wyświetlana i opis

Nazwa displayName i opis służą do identyfikowania przypisania zasad i udostępniania kontekstu do użycia z określonym zestawem zasobów. displayName ma maksymalną długość 128 znaków i opis maksymalnie 512 znaków.

Metadane

Opcjonalna metadata właściwość przechowuje informacje o przypisaniu zasad. Klienci mogą definiować dowolne właściwości i wartości przydatne dla swojej organizacji w programie metadata. Istnieją jednak pewne typowe właściwości używane przez usługę Azure Policy. Każda metadata właściwość ma limit 1024 znaków.

Typowe właściwości metadanych

  • assignedBy (ciąg): przyjazna nazwa podmiotu zabezpieczeń, który utworzył przypisanie.

  • createdBy (ciąg): identyfikator GUID podmiotu zabezpieczeń, który utworzył przypisanie.

  • createdOn (ciąg): uniwersalny format daty i godziny utworzenia przypisania ISO 8601.

  • parameterScopes(obiekt): kolekcja par klucz-wartość, w których klucz pasuje do nazwy parametru skonfigurowanego strongType, a wartość definiuje zakres zasobów używany w portalu w celu udostępnienia listy dostępnych zasobów przez dopasowanie strongType. Portal ustawia tę wartość, jeśli zakres jest inny niż zakres przypisania. W przypadku ustawienia edytuj przypisanie zasad w portalu automatycznie ustawia zakres parametru na tę wartość. Jednak zakres nie jest zablokowany dla wartości i można go zmienić na inny zakres.

    Poniższy przykład dotyczy parametru parameterScopesstrongType o nazwie backupPolicyId , który ustawia zakres wyboru zasobów, gdy przypisanie jest edytowane w portalu.

    "metadata": {
        "parameterScopes": {
            "backupPolicyId": "/subscriptions/{SubscriptionID}/resourcegroups/{ResourceGroupName}"
        }
    }
    
  • updatedBy (ciąg): przyjazna nazwa podmiotu zabezpieczeń, który zaktualizował przypisanie, jeśli istnieje.

  • updatedOn (ciąg): uniwersalny format daty i godziny aktualizacji przydziału ISO 8601, jeśli istnieje.

  • evidenceStorages (obiekt): zalecane domyślne konto magazynu, które powinno być używane do przechowywania dowodów na potrzeby zaświadczania do przypisań zasad z manual efektem. Właściwość displayName jest nazwą konta magazynu. Właściwość evidenceStorageAccountID jest identyfikatorem zasobu konta magazynu. Właściwość evidenceBlobContainer to nazwa kontenera obiektów blob, w którym planujesz przechowywać dowody.

    {
      "properties": {
        "displayName": "A contingency plan should be in place to ensure operational continuity for each Azure subscription.",
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/{definitionId}",
        "metadata": {
          "evidenceStorages": [
            {
              "displayName": "Default evidence storage",
              "evidenceStorageAccountId": "/subscriptions/{subscriptionId}/resourceGroups/{rg-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name}",
              "evidenceBlobContainer": "evidence-container"
            }
          ]
        }
      }
    }
    

Selektory zasobów

Opcjonalna resourceSelectors właściwość ułatwia bezpieczne praktyki wdrażania (SDP), umożliwiając stopniowe wdrażanie przypisań zasad na podstawie czynników, takich jak lokalizacja zasobu, typ zasobu lub czy zasób ma lokalizację. Gdy selektory zasobów są używane, usługa Azure Policy będzie oceniać tylko zasoby, które mają zastosowanie do specyfikacji wykonanych w selektorach zasobów. Selektory zasobów mogą również służyć do zawężania zakresu wykluczeń w ten sam sposób.

W poniższym przykładowym scenariuszu nowe przypisanie zasad jest oceniane tylko wtedy, gdy lokalizacja zasobu to Wschodnie stany USA lub Zachodnie stany USA.

{
    "properties": {
        "policyDefinitionId": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyDefinitions/ResourceLimit",
        "definitionVersion": "1.1",
        "resourceSelectors": [
            {
                "name": "SDPRegions",
                "selectors": [
                    {
                        "kind": "resourceLocation",
                        "in": [ "eastus", "westus" ]
                    }
                ]
            }
        ]
    },
    "systemData": { ... },
    "id": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyAssignments/ResourceLimit",
    "type": "Microsoft.Authorization/policyAssignments",
    "name": "ResourceLimit"
}

Gdy wszystko będzie gotowe do rozwinięcia zakresu oceny dla zasad, wystarczy zmodyfikować przypisanie. W poniższym przykładzie przedstawiono przypisanie zasad z dwoma kolejnymi regionami świadczenia usługi Azure dodanymi do selektora SDPRegions . Należy pamiętać, że w tym przykładzie protokół SDP oznacza Sejf praktyki wdrażania:

{
    "properties": {
        "policyDefinitionId": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyDefinitions/ResourceLimit",
        "definitionVersion": "1.1",
        "resourceSelectors": [
            {
                "name": "SDPRegions",
                "selectors": [
                    {
                        "kind": "resourceLocation",
                        "in": [ "eastus", "westus", "centralus", "southcentralus" ]
                    }
                ]
            }
        ]
    },
    "systemData": { ... },
    "id": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyAssignments/ResourceLimit",
    "type": "Microsoft.Authorization/policyAssignments",
    "name": "ResourceLimit"
}

Selektory zasobów mają następujące właściwości:

  • name: nazwa selektora zasobów.

  • selectors: (Opcjonalnie) Właściwość użyta do określenia, który podzbiór zasobów mających zastosowanie do przypisania zasad powinien zostać oceniony pod kątem zgodności.

    • kind: właściwość selektora, która opisuje, która cecha zawęża zestaw ocenianych zasobów. Każdy rodzaj może być używany tylko raz w jednym selektorze zasobów. Dozwolone wartości to:

      • resourceLocation: Ta właściwość służy do wybierania zasobów na podstawie ich typu. Nie można używać w tym samym selektorze zasobów co resourceWithoutLocation.

      • resourceType: Ta właściwość służy do wybierania zasobów na podstawie ich typu.

      • resourceWithoutLocation: Ta właściwość służy do wybierania zasobów na poziomie subskrypcji, które nie mają lokalizacji. Obecnie obsługuje tylko program subscriptionLevelResources. Nie można używać w tym samym selektorze zasobów co resourceLocation.

    • in: lista dozwolonych wartości dla określonego kindelementu . Nie można używać z notInprogramem . Może zawierać maksymalnie 50 wartości.

    • notIn: lista niedozwolonych wartości dla określonego kindelementu . Nie można używać z inprogramem . Może zawierać maksymalnie 50 wartości.

Selektor zasobów może zawierać wiele selektorów. Aby mieć zastosowanie do selektora zasobów, zasób musi spełniać wymagania określone przez wszystkie jego selektory. Ponadto w jednym przypisaniu można określić maksymalnie 10 selektorów zasobów. Zasoby w zakresie są oceniane, gdy spełniają one jedną z tych selektorów zasobów.

Przesłonięcia

Opcjonalna overrides właściwość umożliwia zmianę efektu definicji zasad bez modyfikowania podstawowej definicji zasad lub przy użyciu sparametryzowanego efektu w definicji zasad.

Najczęstszym przypadkiem użycia przesłonięć są inicjatywy zasad z dużą liczbą skojarzonych definicji zasad. W takiej sytuacji zarządzanie wieloma skutkami zasad może zużywać znaczne nakłady pracy administracyjnej, zwłaszcza gdy efekt musi zostać zaktualizowany od czasu do czasu. Przesłonięcia mogą służyć do jednoczesnego aktualizowania efektów wielu definicji zasad w ramach inicjatywy.

Przyjrzyjmy się przykładowi. Wyobraź sobie, że masz inicjatywę zasad o nazwie CostManagement, która zawiera niestandardową definicję zasad zpolicyDefinitionReferenceId corpVMSizePolicy i jednym efektem audit. Załóżmy, że chcesz przypisać inicjatywę CostManagement , ale nie chcesz jeszcze widzieć zgodności zgłoszonej dla tych zasad. Ten efekt "inspekcji" zasad może zostać zastąpiony przez "disabled" przez zastąpienie przypisania inicjatywy, jak pokazano w poniższym przykładzie:

{
    "properties": {
        "policyDefinitionId": "/subscriptions/{subId}/providers/Microsoft.Authorization/policySetDefinitions/CostManagement",
        "overrides": [
            {
                "kind": "policyEffect",
                "value": "disabled",
                "selectors": [
                    {
                        "kind": "policyDefinitionReferenceId",
                        "in": [ "corpVMSizePolicy" ]
                    }
                ]
            }
        ]
    },
    "systemData": { ... },
    "id": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyAssignments/CostManagement",
    "type": "Microsoft.Authorization/policyAssignments",
    "name": "CostManagement"
}

Przesłonięcia mają następujące właściwości:

  • kind: właściwość, która zostanie zastąpiona przez przypisanie. Obsługiwany rodzaj to policyEffect.

  • value: nowa wartość, która zastępuje istniejącą wartość. Obsługiwane wartości to efekty.

  • selectors: (Opcjonalnie) Właściwość używana do określania zakresu przypisania zasad powinna zostać zastosowana do przesłonięcia.

    • kind: właściwość selektora, która opisuje, jaka cecha zawęzi zakres przesłonięcia. Dozwolona wartość parametru kind: policyEffect to:

      • policyDefinitionReferenceId: Określa, które definicje zasad w ramach przypisania inicjatywy powinny zostać zastosowane w przesłonięcie efektu.
    • in: lista dozwolonych wartości dla określonego kindelementu . Nie można używać z notInprogramem . Może zawierać maksymalnie 50 wartości.

    • notIn: lista niedozwolonych wartości dla określonego kindelementu . Nie można używać z inprogramem . Może zawierać maksymalnie 50 wartości.

Należy pamiętać, że jedno zastąpienie może służyć do zastąpienia efektu wielu zasad przez określenie wielu wartości w tablicy policyDefinitionReferenceId. Pojedyncze przesłonięcia mogą być używane dla maksymalnie 50 zasadDefinitionReferenceIds, a pojedyncze przypisanie zasad może zawierać maksymalnie 10 przesłonięć, obliczonych w kolejności, w której zostały określone. Przed utworzeniem przypisania efekt wybrany w przesłonięciu jest weryfikowany względem reguły zasad i listy dozwolonych wartości parametrów (w przypadkach, gdy efekt jest sparametryzowany).

Tryb wymuszania

Właściwość enforcementMode zapewnia klientom możliwość testowania wyniku zasad dla istniejących zasobów bez inicjowania efektu zasad lub wyzwalania wpisów w dzienniku aktywności platformy Azure.

Ten scenariusz jest często określany jako "What If" i jest zgodny z bezpiecznymi praktykami wdrażania. funkcja enforcementMode różni się od efektu Wyłączone , ponieważ w ogóle uniemożliwia to ocenę zasobów.

Ta właściwość ma następujące wartości:

Tryb Wartość JSON Typ Korygowanie ręczne Wpis dziennika aktywności Opis
Enabled (Włączony) Domyślny ciąg Tak Tak Efekt zasad jest wymuszany podczas tworzenia lub aktualizowania zasobów.
Disabled DoNotEnforce ciąg Tak Nie Efekt zasad nie jest wymuszany podczas tworzenia lub aktualizowania zasobów.

Jeśli właściwość enforcementMode nie jest określona w definicji zasad lub inicjatywy, zostanie użyta wartość Domyślna . Zadania korygowania można uruchomić dla zasad deployIfNotExists , nawet jeśli właściwość enforcementMode jest ustawiona na DoNotEnforce.

Wykluczone zakresy

Zakres przypisania obejmuje wszystkie kontenery zasobów podrzędnych i zasoby podrzędne. Jeśli kontener zasobów podrzędnych lub zasób podrzędny nie powinien mieć zastosowanej definicji, każdy z nich można wykluczyć z oceny, ustawiając wartość notScopes. Ta właściwość jest tablicą umożliwiającą wykluczenie co najmniej jednego kontenera zasobów lub zasobów z oceny. notScopes można dodać lub zaktualizować po utworzeniu początkowego przypisania.

Uwaga

Wykluczony zasób różni się od wykluczonego zasobu. Aby uzyskać więcej informacji, zobacz Omówienie zakresu w usłudze Azure Policy.

Identyfikator definicji zasad

To pole musi być pełną nazwą ścieżki definicji zasad lub definicji inicjatywy. policyDefinitionId jest ciągiem, a nie tablicą. Najnowsza zawartość przypisanej definicji lub inicjatywy zasad jest pobierana za każdym razem, gdy przypisanie zasad jest oceniane. Zaleca się, aby zamiast tego użyć inicjatywy , jeśli wiele zasad jest często przypisanych razem.

Komunikaty o niezgodności

Aby ustawić niestandardowy komunikat opisujący, dlaczego zasób jest niezgodny z definicją zasad lub inicjatywy, ustaw nonComplianceMessages w definicji przypisania. Ten węzeł jest tablicą message wpisów. Ten niestandardowy komunikat jest dodatkiem do domyślnego komunikatu o błędzie dla niezgodności i jest opcjonalny.

Ważne

Niestandardowe komunikaty dotyczące niezgodności są obsługiwane tylko w definicjach lub inicjatywach z definicjami trybów usługi Resource Manager.

"nonComplianceMessages": [
    {
        "message": "Default message"
    }
]

Jeśli przypisanie jest przeznaczone dla inicjatywy, różne komunikaty można skonfigurować dla każdej definicji zasad w inicjatywie. Komunikaty używają policyDefinitionReferenceId wartości skonfigurowanej w definicji inicjatywy. Aby uzyskać szczegółowe informacje, zobacz właściwości definicji zasad.

"nonComplianceMessages": [
    {
        "message": "Default message"
    },
    {
        "message": "Message for just this policy definition by reference ID",
        "policyDefinitionReferenceId": "10420126870854049575"
    }
]

Parametry

Ten segment przypisania zasad zawiera wartości parametrów zdefiniowanych w definicji zasad lub definicji inicjatywy. Ten projekt umożliwia ponowne użycie definicji zasad lub inicjatywy z różnymi zasobami, ale sprawdzenie różnych wartości biznesowych lub wyników.

"parameters": {
    "prefix": {
        "value": "DeptA"
    },
    "suffix": {
        "value": "-LC"
    }
}

W tym przykładzie parametry zdefiniowane wcześniej w definicji zasad to prefix i suffix. To konkretne przypisanie zasad ustawia prefix wartość DeptA i suffix -LC. Ta sama definicja zasad jest wielokrotnego użytku z innym zestawem parametrów dla innego działu, co zmniejsza duplikację i złożoność definicji zasad przy jednoczesnym zapewnieniu elastyczności.

Tożsamość

W przypadku przypisań zasad z ustawieniem efektu w celu wdrożenia elementuIfNotExist lub zmodyfikowania wymagane jest posiadanie właściwości tożsamości w celu korygowania niezgodnych zasobów. W przypadku korzystania z tożsamości użytkownik musi również określić lokalizację przypisania.

Uwaga

Pojedyncze przypisanie zasad może być skojarzone tylko z jedną tożsamością zarządzaną przypisaną przez system lub użytkownika. Jednak w razie potrzeby można przypisać tę tożsamość więcej niż jedną rolę.

# System-assigned identity
 "identity": {
    "type": "SystemAssigned"
  }
# User-assigned identity
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/SubscriptionID/resourceGroups/testResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/test-identity": {}
    }
  },

Następne kroki