Azure Policy definicji inicjatywy

Inicjatywy umożliwiają grupowanie kilku powiązanych definicji zasad w celu uproszczenia przypisań i zarządzania, ponieważ pracujesz z grupą jako pojedynczym elementem. Na przykład można zgrupować powiązane definicje zasad tagowania w jedną inicjatywę. Zamiast przypisywać poszczególne zasady indywidualnie, należy zastosować inicjatywę.

Aby utworzyć definicję inicjatywy zasad, należy użyć danych JSON. Definicja inicjatywy zasad zawiera elementy dla:

  • nazwa wyświetlana
  • description (opis)
  • metadane
  • parameters
  • definicje zasad
  • grupy zasad (ta właściwość jest częścią funkcji zgodności z przepisami (wersja zapoznawcza))

Poniższy przykład ilustruje sposób tworzenia inicjatywy do obsługi dwóch tagów: costCenter i productName . Używa dwóch wbudowanych zasad, aby zastosować domyślną wartość tagu.

{
    "properties": {
        "displayName": "Billing Tags Policy",
        "policyType": "Custom",
        "description": "Specify cost Center tag and product name tag",
        "metadata": {
            "version": "1.0.0",
            "category": "Tags"
        },
        "parameters": {
            "costCenterValue": {
                "type": "String",
                "metadata": {
                    "description": "required value for Cost Center tag"
                },
                "defaultValue": "DefaultCostCenter"
            },
            "productNameValue": {
                "type": "String",
                "metadata": {
                    "description": "required value for product Name tag"
                },
                "defaultValue": "DefaultProduct"
            }
        },
        "policyDefinitions": [{
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",
                "parameters": {
                    "tagName": {
                        "value": "costCenter"
                    },
                    "tagValue": {
                        "value": "[parameters('costCenterValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
                "parameters": {
                    "tagName": {
                        "value": "costCenter"
                    },
                    "tagValue": {
                        "value": "[parameters('costCenterValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",
                "parameters": {
                    "tagName": {
                        "value": "productName"
                    },
                    "tagValue": {
                        "value": "[parameters('productNameValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
                "parameters": {
                    "tagName": {
                        "value": "productName"
                    },
                    "tagValue": {
                        "value": "[parameters('productNameValue')]"
                    }
                }
            }
        ]
    }
}

Azure Policy wbudowane i wzorce znajdują się w Azure Policy przykładach.

Metadane

Opcjonalna metadata właściwość przechowuje informacje o definicji inicjatywy zasad. Klienci mogą definiować dowolne właściwości i wartości przydatne w organizacji w programie metadata . Istnieją jednak pewne typowe właściwości używane przez Azure Policy i wbudowane.

Typowe właściwości metadanych

  • version (ciąg): śledzi szczegółowe informacje o wersji zawartości definicji inicjatywy zasad.

  • category (ciąg): określa, w której kategorii w Azure Portal jest wyświetlana definicja zasad.

    Uwaga

    W przypadku inicjatywy Zgodność z przepisami musi to być zgodność z category przepisami.

  • preview (wartość logiczna): flaga prawda lub fałsz dla, jeśli definicja inicjatywy zasad jest w wersji zapoznawczej.

  • deprecated (wartość logiczna): flaga true lub false dla , jeśli definicja inicjatywy zasad została oznaczona jako przestarzała.

Uwaga

Usługa Azure Policy używa właściwości , i w celu przekazania poziomu zmian do wbudowanej definicji zasad lub version preview inicjatywy i deprecated stanu. Format pliku version to: {Major}.{Minor}.{Patch} . Określone stany, takie jak przestarzałe lub w wersji zapoznawczej, są dołączane do właściwości lub innej właściwości version jako wartość logiczna. Aby uzyskać więcej informacji na temat sposobu Azure Policy wbudowanych wersji, zobacz Wbudowane wersje.

Parametry

Parametry ułatwiają zarządzanie zasadami przez zmniejszenie liczby definicji zasad. Parametry można myśleć jak o polach w formularzu — name , address , , city state . Te parametry zawsze pozostają takie same, jednak ich wartości zmieniają się w zależności od osoby wypełniającej formularz. Parametry działają tak samo podczas tworzenia inicjatyw zasad. Uwzględniając parametry w definicji inicjatywy zasad, można ponownie użyć tego parametru w uwzględnionych zasadach.

Uwaga

Po przypisaniu inicjatywy nie można zmienić parametrów na poziomie inicjacyjnym. W związku z tym zaleca się ustawienie wartości defaultValue podczas definiowania parametru.

Właściwości parametru

Parametr ma następujące właściwości, które są używane w definicji inicjatywy zasad:

  • name: nazwa parametru. Używany przez parameters funkcję wdrażania w ramach reguły zasad. Aby uzyskać więcej informacji, zobacz używanie wartości parametru.
  • type: określa, czy parametr jest ciągiem , tablicą, obiektem, wartością logiczną, liczbą całkowitą, zmiennoprzecinkową lub datą/godziną.
  • metadata: definiuje właściwości podrzędne używane głównie przez Azure Portal do wyświetlania przyjaznych dla użytkownika informacji:
    • description: wyjaśnienie, do czego służy parametr . Może służyć do podania przykładów dopuszczalnych wartości.
    • displayName: przyjazna nazwa parametru wyświetlana w portalu.
    • strongType: (Opcjonalnie) Używany podczas przypisywania definicji zasad za pośrednictwem portalu. Zawiera listę z kontekstem. Aby uzyskać więcej informacji, zobacz strongType.
  • defaultValue: (Opcjonalnie) Ustawia wartość parametru w przypisaniu, jeśli nie zostanie podana żadna wartość.
  • allowedValues: (Opcjonalnie) Dostarcza tablicę wartości, które parametr akceptuje podczas przypisywania.

Na przykład można zdefiniować definicję inicjatywy zasad, aby ograniczyć lokalizacje zasobów w różnych uwzględnionych definicjach zasad. Parametrem dla tej definicji inicjatywy zasad może być allowedLocations. Parametr jest następnie dostępny dla każdej dołączonej definicji zasad i definiowany podczas przypisywania inicjatywy zasad.

"parameters": {
    "init_allowedLocations": {
        "type": "array",
        "metadata": {
            "description": "The list of allowed locations for resources.",
            "displayName": "Allowed locations",
            "strongType": "location"
        },
        "defaultValue": [ "westus2" ],
        "allowedValues": [
            "eastus2",
            "westus2",
            "westus"
        ]
    }
}

Przekazywanie wartości parametru do definicji zasad

Deklaruj parametry inicjatywy, które są do nich dołączone definicje zasad w tablicy policyDefinitions definicji inicjatywy. Chociaż nazwa parametru może być taka sama, użycie innych nazw w inicjatywach niż w definicjach zasad upraszcza czytelność kodu.

Na przykład zdefiniowany wcześniej init_allowedLocations inicjatywy może zostać przekazany do kilku dołączonych definicji zasad i ich parametrów, sql_locations i vm_locations, w ten sposób:

"policyDefinitions": [
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/0ec8fc28-d5b7-4603-8fec-39044f00a92b",
        "policyDefinitionReferenceId": "allowedLocationsSQL",
        "parameters": {
            "sql_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    },
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/aa09bd0f-aa5f-4343-b6ab-a33a6a6304f3",
        "policyDefinitionReferenceId": "allowedLocationsVMs",
        "parameters": {
            "vm_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    }
]

Ten przykład odwołuje się do init_allowedLocations, który został zademonstrowany we właściwościach parametru.

strongType

W ramach metadata właściwości można użyć strongType, aby podać listę opcji wielokrotnego wyboru w Azure Portal. StrongType może być obsługiwanym typem zasobu lub dozwoloną wartością. Aby określić, czy typ zasobu jest prawidłowy dla strongType, użyj get-AzResourceProvider.

Obsługiwane są niektóre typy zasobów, które nie są zwracane przez get-AzResourceProvider. Te typy zasobów to:

  • Microsoft.RecoveryServices/vaults/backupPolicies

Dozwolone wartości strongType typu innego niż typ zasobu to:

  • location
  • resourceTypes
  • storageSkus
  • vmSKUs
  • existingResourceGroups

Definicje zasad

Część policyDefinitions definicji inicjatywy to tablica, której istniejące definicje zasad są uwzględnione w inicjatywie. Jak wspomniano w tece Przekazywanie wartości parametru do definicjizasad , ta właściwość służy do przekazywania parametrów inicjatywy do definicji zasad.

Właściwości definicji zasad

Każdy element tablicy reprezentujący definicję zasad ma następujące właściwości:

  • policyDefinitionId (ciąg): identyfikator niestandardowej lub wbudowanej definicji zasad do dołączyć.
  • policyDefinitionReferenceId (ciąg): krótka nazwa dołączonej definicji zasad.
  • parameters: (Opcjonalnie) Pary nazwa/wartość do przekazywania parametru inicjatywy do dołączonej definicji zasad jako właściwość w tej definicji zasad. Aby uzyskać więcej informacji, zobacz Parametry.
  • groupNames (tablica ciągów): (opcjonalnie) Grupa, do których należy definicja zasad. Aby uzyskać więcej informacji, zobacz Grupy zasad.

Oto przykład, który zawiera dwie dołączone definicje zasad, z policyDefinitions których każda ma ten sam parametr inicjatywy:

"policyDefinitions": [
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/0ec8fc28-d5b7-4603-8fec-39044f00a92b",
        "policyDefinitionReferenceId": "allowedLocationsSQL",
        "parameters": {
            "sql_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    },
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/aa09bd0f-aa5f-4343-b6ab-a33a6a6304f3",
        "policyDefinitionReferenceId": "allowedLocationsVMs",
        "parameters": {
            "vm_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    }
]

Grupy definicji zasad

Definicje zasad w definicji inicjatywy można grupować i kategoryzować. Azure Policy zgodności z przepisami (wersja zapoznawcza) używa tej właściwości do grupowania definicji w kontrolki i domeny zgodności. Te informacje są zdefiniowane we właściwości policyDefinitionGroups tablicy . Więcej szczegółów grupowania można znaleźć w obiekcie policyMetadata utworzonym przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz obiekty metadanych.

Parametry grup definicji zasad

Każdy element tablicy policyDefinitionGroups w elemencie musi mieć obie następujące właściwości:

  • name (ciąg) [ required: ] krótka nazwa grupy. W kontrolce Zgodność z przepisami . Wartość tej właściwości jest używana przez w groupNames . policyDefinitions

  • category (ciąg): hierarchia, do której należy grupa. W kontrolce Zgodność z przepisami jest to domena zgodności.

  • displayName (ciąg): przyjazna nazwa grupy lub kontrolki. Używany przez portal.

  • description(ciąg): opis grupy lub kontrolki.

  • additionalMetadataId (ciąg): lokalizacja obiektu policyMetadata, który zawiera dodatkowe szczegóły dotyczące domeny kontroli i zgodności.

    Uwaga

    Klienci mogą wskazać istniejący obiekt policyMetadata. Jednak te obiekty są tylko do odczytu i tworzone tylko przez firmę Microsoft.

Przykład właściwości z wbudowanej definicji inicjatywy policyDefinitionGroups NIST wygląda następująco:

"policyDefinitionGroups": [
    {
        "name": "NIST_SP_800-53_R4_AC-1",
        "additionalMetadataId": "/providers/Microsoft.PolicyInsights/policyMetadata/NIST_SP_800-53_R4_AC-1"
    }
]

Obiekty metadanych

Wbudowane funkcje zgodności z przepisami utworzone przez firmę Microsoft zawierają dodatkowe informacje o każdej kontrolce. Te informacje są:

  • Wyświetlane w Azure Portal w przeglądzie kontrolki dotyczącej inicjatywy zgodność z przepisami.
  • Dostępne za pośrednictwem interfejsu API REST. Zobacz dostawcę Microsoft.PolicyInsights zasobów i grupę operacji policyMetadata.
  • Dostępne za pośrednictwem interfejsu wiersza polecenia platformy Azure. Zobacz polecenie az policy metadata.

Ważne

Obiekty metadanych dla zgodności z przepisami są tylko do odczytu i nie mogą być tworzone przez klientów.

Metadane grupowania zasad zawierają następujące informacje w properties węźle:

  • metadataId: identyfikator kontrolki, z którego jest powiązane grupowanie.
  • category (wymagane): domena zgodności, do której należy kontrolka.
  • title (wymagane): przyjazna nazwa identyfikatora kontrolki.
  • owner (wymagane): określa, kto jest odpowiedzialny za kontrolę na platformie Azure: Klient, Microsoft, Udostępnione.
  • description: dodatkowe informacje o kontrolce.
  • requirements: szczegółowe informacje o odpowiedzialności za implementację kontrolki.
  • additionalContentUrl: link do dodatkowych informacji o kontrolce. Ta właściwość jest zazwyczaj linkiem do sekcji dokumentacji dotyczącej tej kontroli w standardzie zgodności.

Poniżej znajduje się przykład obiektu policyMetadata. Te przykładowe metadane należą do kontrolki NIST SP 800-53 R4 AC-1.

{
  "properties": {
    "metadataId": "NIST SP 800-53 R4 AC-1",
    "category": "Access Control",
    "title": "Access Control Policy and Procedures",
    "owner": "Shared",
    "description": "**The organization:**    \na. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:  \n1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and  \n2. Procedures to facilitate the implementation of the access control policy and associated access controls; and  \n  
\nb. Reviews and updates the current:  \n1. Access control policy [Assignment: organization-defined frequency]; and  \n2. Access control procedures [Assignment: organization-defined frequency].",
    "requirements": "**a.**  The customer is responsible for developing, documenting, and disseminating access control policies and procedures. The customer access control policies and procedures address access to all customer-deployed resources and customer system access (e.g., access to customer-deployed virtual machines, access to customer-built applications).  \n**b.**  The customer is responsible for reviewing and updating access control policies and procedures in accordance with FedRAMP requirements.",
    "additionalContentUrl": "https://nvd.nist.gov/800-53/Rev4/control/AC-1"
  },
  "id": "/providers/Microsoft.PolicyInsights/policyMetadata/NIST_SP_800-53_R4_AC-1",
  "name": "NIST_SP_800-53_R4_AC-1",
  "type": "Microsoft.PolicyInsights/policyMetadata"
}

Następne kroki