Podstawy struktury definicji usługi Azure Policy

Definicje usługi Azure Policy opisują warunki zgodności zasobów i efekt, jaki należy zastosować, jeśli warunek zostanie spełniony. Warunek porównuje pole lub wartość właściwości zasobu z wartością wymaganą. Dostęp do pól właściwości zasobu można uzyskać przy użyciu aliasów. Gdy pole właściwości zasobu jest tablicą, można użyć specjalnego aliasu tablicy, aby wybrać wartości ze wszystkich elementów członkowskich tablicy i zastosować warunek do każdego z nich. Dowiedz się więcej o warunkach.

Za pomocą przypisania zasad można kontrolować koszty i zarządzać swoimi zasobami. Można na przykład określić, że dozwolone są tylko niektóre typy maszyn wirtualnych. Możesz też wymagać, aby zasoby miały określony tag. Przypisania w zakresie mają zastosowanie do wszystkich zasobów w tym zakresie i poniżej. Jeśli przypisanie zasad jest stosowane do grupy zasobów, jest ono stosowane do wszystkich zasobów w tej grupie zasobów.

Kod JSON służy do tworzenia definicji zasad zawierającej elementy dla:

• displayName
• description
• mode
• version
• metadata
• parameters
• policyRule
  • oceny logiczne
  • effect

Na przykład poniższy kod JSON przedstawia zasady ograniczające miejsce wdrażania zasobów:

{
  "properties": {
    "displayName": "Allowed locations",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
    "mode": "Indexed",
    "metadata": {
      "version": "1.0.0",
      "category": "Locations"
    },
    "parameters": {
      "allowedLocations": {
        "type": "array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources",
          "strongType": "location",
          "displayName": "Allowed locations"
        },
        "defaultValue": [
          "westus2"
        ]
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Aby uzyskać więcej informacji, przejdź do schematu definicji zasad. Wbudowane zasady i wzorce Azure Policy znajdują się w przykładach Azure Policy.

Nazwa wyświetlana i opis

Używasz funkcji displayName i description do identyfikowania definicji zasad i podaj kontekst, dla którego jest używana definicja. Element displayName ma maksymalną długość 128 znaków i description maksymalną długość 512 znaków.

Typ zasad

policyType Chociaż nie można ustawić właściwości, w portalu widoczne są trzy wartości zwracane przez zestaw SDK.

• Builtin: firma Microsoft udostępnia i utrzymuje te definicje zasad.
• Custom: wszystkie definicje zasad utworzone przez klientów mają tę wartość.
• Static: wskazuje definicję zasad zgodności z przepisami z własnością firmy Microsoft. Wyniki zgodności tych definicji zasad są wynikami inspekcji infrastruktury firmy Microsoft innych firm. W witrynie Azure Portal ta wartość jest czasami wyświetlana jako zarządzana przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz Wspólna odpowiedzialność w chmurze.

Tryb

Właściwość mode jest skonfigurowana w zależności od tego, czy zasady są przeznaczone dla właściwości usługi Azure Resource Manager lub właściwości dostawcy zasobów.

Tryby usługi Resource Manager

Określa mode , które typy zasobów są oceniane dla definicji zasad. Obsługiwane tryby to:

• all: ocenianie grup zasobów, subskrypcji i wszystkich typów zasobów
• indexed: ocenianie tylko typów zasobów obsługujących tagi i lokalizację

Na przykład zasób Microsoft.Network/routeTables obsługuje tagi i lokalizację i jest oceniany w obu trybach. Nie można jednak oznaczyć zasobu Microsoft.Network/routeTables/routes, a w trybie indexed nie jest oceniany.

Zalecamy, aby w większości przypadków ustawić mode na all. Wszystkie definicje zasad utworzone za pośrednictwem portalu używają all trybu . Jeśli używasz programu PowerShell lub Interfejsu wiersza polecenia platformy Azure, możesz ręcznie określić parametr. Jeśli definicja zasad nie zawiera wartości mode, domyślnie jest ona ustawiana na all w Azure PowerShell i na null w Azure CLI. Tryb null jest taki sam jak użycie indexed aby zapewnić zgodność wsteczną.

indexed należy używać podczas tworzenia zasad wymuszających tagi lub lokalizacje. Chociaż nie jest to wymagane, zapobiega temu, by zasoby, które nie obsługują tagów i lokalizacji, były wyświetlane jako niezgodne w wynikach zgodności. Wyjątkiem są grupy zasobów i subskrypcje. Definicje zasad, które wymuszają lokalizację lub tagi w grupie zasobów lub subskrypcji, powinny ustawić mode na all i w szczególności adresować typ Microsoft.Resources/subscriptions/resourceGroups lub Microsoft.Resources/subscriptions. Przykład można znaleźć w temacie Pattern: Tags - Sample #1 (Wzorzec: tagi — przykład nr 1). Aby uzyskać listę zasobów, które obsługują tagi, zobacz Obsługa tagów dla zasobów platformy Azure.

Tryby dostawcy zasobów

Następujące tryby dostawcy zasobów są w pełni obsługiwane:

• Microsoft.Kubernetes.Data do zarządzania klastrami Kubernetes i składnikami, takimi jak zasobniki, kontenery i ingressy. Obsługiwane w przypadku klastrów usługi Azure Kubernetes Service i klastrów Kubernetes z obsługą usługi Azure Arc. Definicje korzystające z tego trybu dostawcy zasobów używają efektów inspekcji, odmowy i wyłączenia.
• Microsoft.KeyVault.Data do zarządzania magazynami i certyfikatami w usłudze Azure Key Vault. Aby uzyskać więcej informacji na temat tych definicji zasad, zobacz Integrowanie usługi Azure Key Vault z usługą Azure Policy.
• Microsoft.Network.Data do zarządzania niestandardowymi zasadami członkostwa w usłudze Azure Virtual Network Manager przy użyciu usługi Azure Policy.

Następujące tryby działania dostawcy zasobów są obecnie obsługiwane jako wersja próbna:

• Microsoft.ManagedHSM.Data do zarządzania kluczami zarządzanego sprzętowego modułu zabezpieczeń (HSM) przy użyciu usługi Azure Policy.
• Microsoft.DataFactory.Data w przypadku używania usługi Azure Policy do odrzucania nazw domen ruchu wychodzącego usługi Azure Data Factory, które nie są określone na liście dozwolonych. Ten tryb dostawcy zasobów służy jedynie do wymuszania i nie raportuje zgodności w publicznej wersji zapoznawczej.
• Microsoft.MachineLearningServices.v2.Data do zarządzania wdrożeniami modeli usługi Azure Machine Learning . Ten tryb dostawcy zasobów zgłasza zgodność nowo utworzonych i zaktualizowanych składników. W publicznej wersji zapoznawczej rekordy zgodności pozostają przez 24 godziny. Wdrożenia modelu, które istnieją przed przypisaniem tych definicji zasad, nie zgłaszają zgodności.
• Microsoft.LoadTestService.Data w celu ograniczenia wystąpień testowania obciążenia platformy Azure do prywatnych punktów końcowych.

Po wydaniu wersjonowania w usłudze Azure Policy następujące tryby dostawcy zasobów nie będą obsługiwać wbudowanego wersjonowania.

• Microsoft.DataFactory.Data
• Microsoft.MachineLearningServices.v2.Data
• Microsoft.ManagedHSM.Data

wersja

Wbudowane definicje zasad mogą hostować wiele wersji z taką samą definitionID. Jeśli nie określono numeru wersji, wszystkie środowiska będą wyświetlać najnowszą wersję definicji. Aby wyświetlić określoną wersję wbudowanej, należy ją określić w interfejsie API, zestawie SDK lub interfejsie użytkownika. Aby odwołać się do określonej wersji definicji w ramach przypisania, zobacz wersję definicji w ramach przypisania

Usługa Azure Policy używa właściwości version, preview oraz deprecated do przekazywania stanu i poziomu zmian w wbudowanej definicji zasad lub inicjatywie. Format version jest: {Major}.{Minor}.{Patch}. Gdy definicja zasad jest w stanie podglądu, sufiks podgląd jest dołączany do właściwości version i traktowany jako wartość logiczna. Gdy definicja zasad jest wycofana, wycofanie jest zapisywane jako wartość logiczna w metadanych definicji przy użyciu "deprecated": "true".

• Wersja główna (przykład: 2.0.0): wprowadzanie zmian, które łamią zgodność, np. znaczne zmiany logiki reguł, usuwanie parametrów, domyślne dodawanie efektu wymuszania.
• Wersja pomocnicza (przykład: 2.1.0): wprowadza zmiany, takie jak drobne zmiany logiki reguł, dodawanie nowych wartości dozwolonych parametrów, zmienianie wartości na roleDefinitionIds, dodawanie lub przenoszenie definicji w ramach inicjatywy.
• Wersja poprawki (na przykład: 2.1.4): wprowadzenie zmian ciągu lub metadanych i scenariuszy zabezpieczeń szklenia (rzadko).

Aby uzyskać więcej informacji na temat wbudowanych wersji usługi Azure Policy, zobacz Wersjonowanie wbudowane. Aby dowiedzieć się więcej o znaczeniu zasad określonych jako przestarzałe lub w wersji zapoznawczej, zapoznaj się z sekcją Zasady w wersji zapoznawczej i przestarzałe.

Metadane

Opcjonalna metadata właściwość przechowuje informacje o definicji 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 i wbudowane. Każda metadata właściwość ma limit 1024 znaków.

Typowe właściwości metadanych

• version (ciąg): śledzi szczegóły dotyczące wersji zawartości definicji zasad.
• category (ciąg): określa, w której kategorii w witrynie Azure Portal jest wyświetlana definicja zasad.
• preview (wartość logiczna): flaga wskazująca, czy definicja polityki jest w wersji zapoznawczej.
• deprecated (wartość logiczna): wskaźnik prawdy lub fałszu określający, czy definicja polityki jest oznaczona jako przestarzała.
• portalReview (ciąg): określa, czy parametry mają być przeglądane w portalu, niezależnie od wymaganych danych wejściowych.

Lokalizacja definicji

Podczas tworzenia inicjatywy lub zasad należy określić lokalizację definicji. Miejsce definicji musi być grupą zarządzania lub subskrypcją. Ta lokalizacja określa zakres, do którego można przypisać inicjatywę lub zasady. Zasoby muszą być bezpośrednimi członkami lub elementami podrzędnymi w hierarchii lokalizacji definicji, które są docelowe dla przypisania.

Jeśli lokalizacja definicji to:

• Subskrypcja — do definicji zasad można przypisać tylko zasoby w ramach tej subskrypcji.
• Grupa zarządzania — do definicji zasad można przypisać tylko zasoby w podrzędnych grupach zarządzania i subskrypcjach podrzędnych. Jeśli planujesz zastosować definicję zasad do kilku subskrypcji, lokalizacja musi być grupą zarządzania zawierającą każdą subskrypcję.

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

Następne kroki

• Aby uzyskać więcej informacji na temat struktury definicji zasad, przejdź do parametry, reguła zasad i alias.
• W przypadku inicjatyw przejdź do struktury definicji inicjatywy.
• Zapoznaj się z przykładami w przykładach usługi Azure Policy.
• Przejrzyj zrozumienie skutków polityki.
• Dowiedz się, jak programowo tworzyć zasady.
• Dowiedz się, jak uzyskać dane zgodności.
• Dowiedz się, jak korygować niezgodne zasoby.
• Dowiedz się, czym jest grupa zarządzania z funkcją Organizowanie zasobów przy użyciu grup zarządzania w Azure.