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. Oder Sie können festlegen, dass Ressourcen ein bestimmtes Tag aufweisen. Zuordnungen in einem Bereich gelten für alle Ressourcen in diesem Bereich und unterhalb. 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 zurückgegeben, aber es handelt sich jeweils um schreibgeschützte Informationen in Bezug auf die 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 Complianceergebnisse für diese Richtliniendefinitionen sind die Ergebnisse von externen Überprüfungen in 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 zum Erzwingen von Speicherort oder Tags für eine Ressourcengruppe oder ein Abonnement sollten mode auf all festlegen und speziell auf den Typ Microsoft.Resources/subscriptions/resourceGroups oder Microsoft.Resources/subscriptions abzielen. 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, Container und eingehende Elemente. 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. Dieser Ressourcenanbietermodus wird nur erzwungen und meldet die Compliance nicht in der öffentlichen Vorschau.
  • 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.

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 Azure Policy-Versionsverwaltung veröffentlicht wird, unterstützen die folgenden Ressourcenanbietermodi keine integrierte Versionsverwaltung:

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

Version (Vorschau)

Definitionen integrierter Richtlinien können mehrere Versionen mit demselben definitionID-Wert hosten. Wenn keine Versionsnummer angegeben ist, wird in allen Benutzeroberflächen die aktuelle Version der Definition angezeigt. Um eine bestimmte Version einer integrierten Version anzuzeigen, muss sie in der API, dem SDK oder der Benutzeroberfläche angegeben werden. Informationen zum Verweisen auf eine bestimmte Version einer Definition innerhalb einer Zuordnung finden Sie unter Definitionsversion innerhalb einer 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 Richtliniendefinition im Zustand „Vorschau“ befindet, wird das Suffix Vorschau an die version-Eigenschaft angefügt, und sie wird als boolesche Eigenschaft behandelt. Wenn eine Richtliniendefinition veraltet ist, wird dies mit "deprecated": "true" als boolescher Wert in den Metadaten der Definition erfasst.

  • Hauptversion (Beispiel: 2.0.0): Es werden Breaking Changes wie grundlegende Änderungen der Regellogik, weniger Parameter und ein standardmäßig erzwungener Effekt eingeführt.
  • Nebenversion (Beispiel: 2.1.0): Es werden Änderungen wie geringfügige Änderungen der Regellogik, neue zulässige Parameterwerte, eine Änderung an roleDefinitionIds und die Möglichkeit eingeführt, Definitionen innerhalb einer Initiative hinzuzufügen oder zu verschieben.
  • Patchversion (Beispiel: 2.1.4): Es werden Änderungen an Zeichenfolgen oder Metadaten sowie Sicherheitsszenarios für Notfälle (selten) eingeführt.

Weitere Informationen zu den Versionen von integrierten Azure Policy-Richtlinien und -Initiativen finden Sie unter Integrierte 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 (boolescher Wert): Flag mit einem der Werte TRUE oder FALSE für den Fall, dass sich die Richtliniendefinition in der Vorschauphase befindet.
  • deprecated (boolesch): True- oder False-Flag für die Angabe, 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 für die Zuweisung sein.

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