Freigeben über

Struktur von Azure Policy-Definitionsgrundlagen

Azure Policy-Definitionen beschreiben Bedingungen für die Ressourcencompliance und die Maßnahmen, die ergriffen werden, wenn eine Bedingung erfüllt ist. Eine Bedingung vergleicht ein Feld oder einen Wert einer Ressourceneigenschaft mit einem erforderlichen Wert. Der Zugriff auf Ressourceneigenschaftsfelder erfolgt über Aliase. Wenn ein Ressourceneigenschaftsfeld ein Array ist, kann ein spezieller Arrayalias verwendet werden, um Werte aus allen Arraymembern auszuwählen und auf jedes eine Bedingung anzuwenden. Erfahren Sie mehr über Bedingungen.

Mithilfe von Richtlinienzuweisungen können Sie Kosten steuern und Ihre Ressourcen verwalten. Sie können beispielsweise angeben, dass nur bestimmte Typen virtueller Computer zulässig sind. Sie können auch festlegen, dass Ressourcen ein bestimmtes Tag aufweisen müssen. Zuweisungen in einem Bereich gelten für alle Ressourcen in und unter diesem Bereich. Wenn eine Richtlinienzuweisung auf eine Ressourcengruppe angewandt wird, gilt sie für alle Ressourcen in dieser Ressourcengruppe.

Sie verwenden JSON zum Erstellen einer Richtliniendefinition, die Elemente enthält für:

  • displayName
  • description
  • mode
  • version
  • metadata
  • parameters
  • policyRule
    • Logische Bewertungen
    • effect

Die folgende JSON-Datei zeigt beispielsweise eine Richtlinie, die einschränkt, wo Ressourcen bereitgestellt werden:

{
  "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"
      }
    }
  }
}

Weitere Informationen hierzu finden Sie im Richtliniendefinitionsschema. Integrierte Richtlinien und Muster von Azure Policy finden Sie unter Azure Policy-Beispiele.

Anzeigename und Beschreibung

Sie verwenden displayName und description, um die Richtliniendefinition zu identifizieren und den Kontext für ihre Verwendung anzugeben. Die displayName hat eine maximale Länge von 128 Zeichen und description eine maximale Länge von 512 Zeichen.

Hinweis

Während der Erstellung oder Aktualisierung einer Richtliniendefinition werden id, type, und name durch Eigenschaften außerhalb der JSON-Datei definiert und sind in der JSON-Datei nicht erforderlich. Wenn Sie die Richtliniendefinition über das SDK abrufen, werden die Eigenschaften id, type und name als Teil des JSON-Codes zurückgegeben. Diese Eigenschaften sind jedoch schreibgeschützte Informationen im Zusammenhang mit der Richtliniendefinition.

Richtlinientyp

Die policyType-Eigenschaft kann zwar nicht eingestellt werden, aber es gibt drei Werte, die vom SDK zurückgegeben werden und im Portal sichtbar sind:

  • Builtin: Microsoft stellt diese Richtliniendefinitionen bereit und verwaltet sie.
  • Custom: Alle von Kunden erstellten Richtliniendefinitionen haben diesen Wert.
  • Static: Gibt eine Richtliniendefinition zur Einhaltung gesetzlicher Bestimmungen mit Microsoft Ownership an. Die Konformitätsergebnisse für diese Richtliniendefinitionen sind die Ergebnisse von externen Überprüfungen der Microsoft-Infrastruktur. Im Azure-Portal wird dieser Wert manchmal als Von Microsoft verwaltet angezeigt. Weitere Informationen dazu finden Sie unter Gemeinsame Verantwortung in der Cloud.

Mode

Der mode wird abhängig davon konfiguriert, ob die Richtlinie für eine Azure Resource Manager- oder eine Ressourcenanbieter-Eigenschaft gilt.

Ressourcen-Manager-Modi

Der mode bestimmt, welche Ressourcentypen für eine Richtliniendefinition ausgewertet werden. Unterstützte Modi:

  • all: Ressourcengruppen, Abonnements und alle Ressourcentypen werden ausgewertet.
  • indexed: Nur Ressourcentypen, die Tags und Speicherort unterstützen, werden ausgewertet.

Beispielsweise unterstützt die Ressource Microsoft.Network/routeTables Tags und Standort und wird in beiden Modi ausgewertet. Es ist jedoch nicht möglich, die Ressource Microsoft.Network/routeTables/routes mit einem Tag zu versehen, und sie wird nicht im Modus indexed ausgewertet.

Es wird empfohlen, mode in den meisten Fällen auf all zu setzen. Alle über das Portal erstellten Richtliniendefinitionen verwenden für „mode“ die Option all. Wenn Sie PowerShell oder die Azure CLI verwenden, können Sie den mode-Parameter manuell angeben. Wenn die Richtliniendefinition keinen Wert für mode enthält, wird dieser in Azure PowerShell standardmäßig auf all und in der Azure CLI auf null festgelegt. Der Modus null entspricht dem Verwenden von indexed, um Abwärtskompatibilität zu unterstützen.

indexed sollte beim Erstellen von Richtlinien verwendet werden, die Tags oder Speicherorte erzwingen. Dies ist nicht erforderlich, verhindert aber, dass Ressourcen, die keine Tags und Speicherorte unterstützen, bei der Konformitätsprüfung als nicht konform angezeigt werden. Ausgenommen hiervon sind Ressourcengruppen und Abonnements. Richtliniendefinitionen, die einen Speicherort oder Tags für eine Ressourcengruppe oder ein Abonnement erzwingen, sollten mode auf all und insbesondere den Typ Microsoft.Resources/subscriptions/resourceGroups oder Microsoft.Resources/subscriptions als Ziel festlegen. Ein Beispiel finden Sie unter Azure Policy-Muster: Tags – Beispiel 1. Eine Liste der Ressourcen, die Tags unterstützen, finden Sie unter Tagunterstützung für Azure-Ressourcen.

Ressourcenanbietermodi

Die folgenden Resource Provider-Modi werden vollständig unterstützt:

  • Microsoft.Kubernetes.Data für die Verwaltung von Kubernetes-Clustern und Komponenten wie Pods, Containern und eingehenden Elementen. Wird für Azure Kubernetes Service-Cluster und Kubernetes-Cluster mit Azure Arc-Unterstützung unterstützt. Definitionen, die diesen Ressourcenanbietermodus nutzen, verwenden die Auswirkungen audit, deny und disabled.
  • Microsoft.KeyVault.Data zur Verwaltung von Tresoren und Zertifikaten in Azure Key Vault. Weitere Informationen zu diesen Richtliniendefinitionen finden Sie unter Integrieren von Azure Key Vault in Azure Policy.
  • Microsoft.Network.Data zum Verwalten von benutzerdefinierten Azure Virtual Network Manager-Mitgliedschaftsrichtlinien mit Azure Policy.

Die folgenden Ressourcenanbietermodi werden derzeit als Vorschau unterstützt:

  • Microsoft.ManagedHSM.Data zum Verwalten von HSM-Schlüsseln (Managed Hardware Security Module) mithilfe von Azure Policy.
  • Microsoft.DataFactory.Data für die Verwendung von Azure Policy, um Azure Data Factory-Domänennamen für ausgehenden Datenverkehr zu untersagen, die nicht in einer Zulassungsliste angegeben sind. In der öffentlichen Vorschauversion dient dieser Ressourcenanbietermodus nur zum Erzwingen und nicht zum Melden der Konformität.
  • Microsoft.MachineLearningServices.v2.Data zum Verwalten von Azure Machine Learning-Modellimplementierungen. Dieser Resource Provider-Modus meldet die Compliance neu erstellter und aktualisierter Komponenten. Während der öffentlichen Vorschau bleiben Compliancedatensätze 24 Stunden lang erhalten. Modellbereitstellungen, die vor der Zuweisung dieser Richtliniendefinitionen existieren, melden keine Konformität.
  • Microsoft.LoadTestService.Data zur Beschränkung von Azure Load Testing-Instanzen auf private Endpunkte.

Hinweis

Sofern nicht ausdrücklich angegeben, unterstützen die Modi des Ressourcenanbieters nur integrierte Richtliniendefinitionen, und Ausnahmen werden auf Komponentenebene nicht unterstützt.

Wenn die Versionsverwaltung für Azure Policies freigegeben wird, werden die folgenden Resource Provider-Modi die integrierte Versionsverwaltung nicht unterstützen:

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

Version

Integrierte Richtliniendefinitionen können mehrere Versionen mit demselben definitionID hosten. Wenn keine Versionsnummer angegeben wird, zeigen alle Erfahrungen die neueste Version der Definition an. Um eine bestimmte Version einer integrierten Definition zu sehen, muss diese in der API, dem SDK oder der Benutzeroberfläche angegeben werden. Um auf eine bestimmte Version einer Definition innerhalb einer Zuweisung zu verweisen, siehe Definitionsversion innerhalb der Zuweisung.

Der Azure Policy-Dienst verwendet die Eigenschaften version, preview und deprecated, um den Status und den Grad der Änderung einer integrierten Richtliniendefinition oder Initiative zu übermitteln. Das Format von version ist {Major}.{Minor}.{Patch}. Wenn sich eine Richtlinie im Status Vorschau befindet, wird das Suffix Vorschau an die Eigenschaft version angehängt und als boolesch behandelt. Wenn eine Richtlinie veraltet ist, wird die Abschaffung als boolescher Wert in den Metadaten der Definition unter Verwendung von "deprecated": "true" festgehalten.

  • Major Version (Beispiel: 2.0.0): führt fehlerhafte Änderungen ein, wie z. B. größere Änderungen der Regellogik, Entfernen von Parametern, Hinzufügen einer standardmäßigen Durchsetzungswirkung.
  • Minor Version (Beispiel: 2.1.0): Einführung von Änderungen wie z. B. kleinere Änderungen an der Logik der Regel, Hinzufügen neuer zulässiger Parameterwerte, Änderung auf roleDefinitionIds, Hinzufügen oder Verschieben von Definitionen innerhalb einer Initiative.
  • Patchversion (Beispiel: 2.1.4): Es werden Änderungen an Zeichenfolgen oder Metadaten und Notfallsicherheitsszenarien (selten) eingeführt.

Weitere Informationen über die integrierten Versionen von Azure Policy finden Sie unter Versionsverwaltung. Weitere Informationen dazu, was es bedeutet, dass eine Richtlinie als veraltet oder in der Vorschauversion verfügbar gilt, finden Sie unter Vorschauversionen und veraltete Richtlinien.

Metadaten

In der optionalen metadata-Eigenschaft werden Informationen zur Richtliniendefinition gespeichert. Kunden können alle für ihre Organisation nützlichen Eigenschaften und Werte in metadata definieren. Es gibt jedoch einige allgemeine Eigenschaften, die von Azure Policy und integrierten Richtlinien verwendet werden. Jede metadata-Eigenschaft ist auf 1.024 Zeichen begrenzt.

Allgemeine Metadateneigenschaften

  • version (Zeichenfolge): Verfolgt Details zur Version des Inhalts einer Richtliniendefinition nach.
  • category (Zeichenfolge): Legt fest, unter welcher Kategorie im Azure-Portal die Richtliniendefinition angezeigt wird.
  • preview (boolesch): True- oder False-Flag, das angibt, ob die Richtliniendefinition eine Vorschau ist.
  • deprecated (boolesch): True- oder False-Flag, das angibt, ob die Richtliniendefinition als veraltet markiert ist.
  • portalReview (Zeichenfolge): Bestimmt, ob Parameter unabhängig von der erforderlichen Eingabe im Portal überprüft werden sollen

Definitionsspeicherort

Beim Erstellen einer Initiative oder Richtlinie muss der Speicherort der Definition angegeben werden. Dieser Speicherort muss eine Verwaltungsgruppe oder ein Abonnement sein. Er bestimmt den Bereich, dem die Initiative oder Richtlinie zugewiesen werden kann. Ressourcen müssen direkte Mitglieder oder untergeordnete Elemente innerhalb der Hierarchie des Definitionsspeicherorts sein, damit die Zuweisung erfolgt.

Für den Definitionsspeicherort gilt Folgendes:

  • Abonnement: Der Richtliniendefinition können nur Ressourcen innerhalb dieses Abonnements zugewiesen werden.
  • Verwaltungsgruppe: Der Richtliniendefinition können nur Ressourcen in untergeordneten Verwaltungsgruppen und untergeordneten Abonnements zugewiesen werden. Wenn Sie die Richtliniendefinition auf mehrere Abonnements anwenden möchten, muss der Speicherort eine Verwaltungsgruppe sein, die das jeweilige Abonnement enthält.

Weitere Informationen finden Sie in der Übersicht zu Bereichen in Azure Policy.

Nächste Schritte

  • Last updated on