Governance-Richtlinien umsetzen und überwachen mit Azure Policy?
Dieser Beitrag zeigt dir, wie du es in der Azure Cloud erreichst, dass du virtuelle Maschinen nur in Deutschland erstellen kannst, um damit z. B. gesetzlichen oder eigenen Compliance-Anforderungen gerecht zu werden. Verantwortlich hierfür ist der Dienst Azure Policy, mit dem du auch beliebige andere Steuerungsszenarien umsetzen kannst, etwa die Beschränkung auf deutsche RZs nicht nur in Bezug auf VMs, sondern beliebige andere Azure-Ressourcen oder nicht nur auf den Ort des Rechnungszentrums, sondern auch auf die zulässigen Größen der VMs oder Beides auszudehnen.
Wenn du noch den Einstieg in Azure suchst, empfehlen wir dir unsere Schulung AZ-900 – Microsoft Azure Fundamentals.
Außerdem kannst du mit Azure Policy bestimmen, auf welchen „Bereich“ innerhalb eines Azure-AD-Mandanten sich diese Regeln auswirken sollen, etwa nur ein oder mehrere Azure Abonnements oder gar nur auf spezielle Ressourcen-Gruppen.
Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!
Die Grundstruktur von Azure unter der Governance-Perspektive in der folgende Abbildung offenbart: was auch immer du in Azure tust, etwa über das Portal, die Azure-CLI oder via ARM-Template mit einem Infrastructure-as-Code-Ansatz, für die eigentliche technische Umsetzung ist immer der Azure Ressource Manager verantwortlich (ARM), der letztendlich mit den „Resource Providern“ der eigentlichen Azure-Dienste „spricht“.
Dazu muss jeder Aufruf aber auch an der Azure Policy Engine vorbei, die damit eine Art Echtzeit-Durchsetzung von Compliance-Bewertungen und falls nötig eine automatische Standardisierung von nicht mit einer Policy-Zuweisung übereinstimmenden Erstellungsanforderungen an den zu erstellenden Ressourcen durchführt.
Was ist Azure Policy?
Die Azure Policy-Engine regelt damit, ob eine Änderung, die durch den Azure Resource Manager erfolgen soll überhaut erlaubt ist oder nicht und falls nicht, ob etwaige Ressource in Echtzeit angepasst werden können und sollen, d. h. mit Hilfe von Azure-Policy lassen sich eine Vielzahl von Dingen in Azure steuern. Schaut man z. B. im Azure-Portal im Blade „Richtlinie“ (bei deutscher Lokalisierung) unter „Einstellungen / Definitionen“ erkennt man, dass Azure bereits hunderte von solchen Definitionen mitliefert.
Diese sind übrigens auch auf dem https://github.com/Azure/azure-policy Github-Repository von Microsoft Azure zu finden sind. Wirfst du einen genaueren Blick auf die Richtlinien-Definitionen, kannst du schon am Namen eine Menge für den vorgesehenen Verwendungszweck ablesen.
Übrigens unterscheidet Microsoft noch einmal zwischen Einzel-Definitionen und sogenannten Initiativen. Letztere bündeln viele, mitunter hunderte von Einzeldefinitionen zu einem komplexen Richtlinien-Katalog, der Nutzer, Dienste und Vorgänge unter Azure dazu zwingt, sich an solche Regelwerke – sei es unternehmenseigene oder gesetzliche Vorschriften – zu halten. Folgende Abbildung zeigt die Initiative „ISO 27001:2013“. Ich habe die Auflistung der Einzel-Richtlinien nach „Auswirkungstyp“ (Effect) sortiert. Hier gibt es z. B. „Audit“ „AuditIfNotExits“, „DeployIfNotExists“ oder „Modifiy“.
Daraus lässt sich schon ableiten, dass Azure Richtlinien sowohl die Konfiguration bestimmter Azure-Ressourcen bei deren Erstellung überwachen, als auch anpassen (standardisieren) können, wozu die betreffende Azure-Richtlinie allerdings auch die erforderlichen Berechtigungen haben muss, z. B. in Form einer verwalteten Identität.
Strukturell werden Azure Richtlinien genau wie Azure RBAC-Rollen in JSON-Dokumente verpackt. Folgendes Beispiel zeigt eine Richtlinie, die überprüft, bzw. verbietet, dass jegliche Azure-Ressourcen nur in der angegebenen Region erstellt werden dürfen. Definiert wird dies im Array „allowedLocations“. Hier kannst du beim späteren Zuweisen dieser Richtliniendefinition an einen bestimmten Gültigkeitsbereich in der Azure-Ressource-Hierarchie (Scope), wie z. B. ein Azure Abonnement dann einen oder auch mehrere Parameter angeben, etwa zusätzlich zudem fest verdrahteten „defaultValue („germanywestcentral“) noch „westeurope“.
{
"properties": {
"displayName": "erlaubte locations für alle Azure-Ressourcen",
"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": [ "germanywestcentral" ]
}
},
"policyRule": {
"if": {
"not": {
"field": "location",
"in": "[parameters('allowedLocations')]"
}
},
"then": {
"effect": "deny"
}
}
}
}
Diese Regel „verhindert“ übrigens, dass eine beliebige Azure-Ressource überhaupt erstellt wird, wenn der Nutzer sie nicht in der angegebenen Region erstellt. Im If-Zweig der Policy-Rule wird dazu geprüft wird, ob sich der beim Erstellen angegebene Wert für „location“ im Parameter-Array befindet das bei der Zuweisung der Richtlinie definiert wurde. Dass es sich um einer Verweigerungsrichtlinie handelt ist am then-Zweig der Policy-Rule an der Auswirkung „effect“:“deny“ zu erkennen.
Für den Einstieg genügt es, wenn du dich mit dem umfangreichen Katalog der mitgelieferten Richtlinien begnügst und sowohl Zuweisung als auch Compliance-Prüfung oder Standardisierung im Azure Portal vornimmst. Lasst uns nun das eingangs skizzierte Beispiel praktisch umsetzen.
VMs nur in Deutschland starten
Möchtet du verbieten, dass VMs anderswo als in Deutschland gestartet werden dürfen, musst du dich zunächst über den Gültigkeitsbereich im Klaren sein. Hast du mehrere Azure Abonnements in deinem Mandanten, kannst du eine entsprechende Policy-Zuweisung für jede Subscription einzeln vornehmen, oder du bündelst vorher mehrere Subscriptions mit Hilfe einer Verwaltungsgruppe (Management Group). Außerdem kannst du die Gültigkeit auch auf einzelnen Ressourcengruppen beschränken.
Starte dazu im Portal für den Dienst „Richtlinien“ unter „Einstellung / Zuweisungen“ mit einem Klick auf „Richtlinie zuweisen“. Bei „Bereich“ kannst du dann das gewünschte Abonnement auswählen. Klicke dazu auf die das Icon mit den drei kleinen Punkten. Möchtest du innerhalb der Subscription nur eine bestimmte Ressourcengruppe wählen, wähle diese im Feld „Ressourcengruppe“ aus:
Du kannst den Scope außerdem noch präziser eingrenzen indem du bei „Ausschlüsse“ im Feld darunter Elemente der Azure-Ressource-Hierarchie auswählst, die von der oben getroffenen Auswahl für den Scope nicht betroffen sein soll.
Dann wählst du bei „Richtliniendefinitionen“ ebenfalls mit einem Klick auf das blaue Icon aus der Liste der Buildin-Definitionen die Passenden aus. Hierbei kannst du auch volltextfiltern. Suche im deutsch lokalisierten azure-Portal nach „Zulässige Standorte“.
Wirksam wird eine Policy erst durch das Zuweisen. Vergib daher nun bei „Zuweisungsname“ einen Namen für die Zuweisung. Das Azure Portal leitet per Default diesen Namen aus der Definition ab. Außerdem kannst du einen beliebigen Beschreibungstext hinterlegen:
Setze die Richtlinienerzwingung mit dem Schiebeschalter auf „Aktiviert“ (Default), wenn du die Richtlinie sofort beim Erstellen scharf schalten möchtest. Mit „Deaktiviert“ erhältst du dann nur ein Monitoring im Compliance-Dashboard von Azure Policy. Das bietet sich z. B. für eine Übergangszeit an, wenn du das Feature im eigenen Unternehmen verpflichtend einführen möchtest.
Klicke jetzt NICHT auf „Überprüfen und erstellen“ sondern auf „Weiter“ um zum Tab „Parameter“ zu gelangen. Hier kannst du dann die gewünschten erlaubten Werte für das Parameter-Array (s. o) bequem auswählen, wenn du möchtest auf „Mehrere“.
Nun hast du alle obligatorischen Angaben beisammen und kannst auf „Überprüfen + erstellen“ klicken. Einen Widerherstellungs-Task (Tab Wiederherstellung) kannst du nämlich in diesem Fall nicht erstellen, weil diese einfache Richtlinie nur eine „deny“-Auswirkung hat (s. o).
Wenn du möchtest, kannst du noch eine „Nichtkonformitätsmeldung“ selbst formulieren und dann auf „Überprüfen + erstellen“ klicken.
Ob die Richtlinien den gewünschten Effekt hat, kannst du an zwei Stellen sehen. Erstellst du z. B. eine VM in einer nicht erlaubten Region, wird die Erstellung schon entweder beim Konfigurieren der VM ablehnt …
… oder spätestes beim Versuch, die Ressource vom Ressource Manager erstellen zu lassen. Das sieht dann aus, wie in folgender Abbildung:
Alle übrigen zum Zeitpunkt der Erstellung der Zuweisung (hier „erlaubte Standorte) bereits bestehenden Azure-Ressourcen, die nicht in Deutschland sind, werden dann im Compliance-Dashbord (Menü „Übersicht“) als nicht konform geführt.
Wenn du nun mit dem Workflow grundlegend vertraut bist, experimentierst du mit weiteren einfachen Richtlinie-Definitionen wie
- Zulässige SKUs für VM-Größen: Über diese Richtlinie kannst du einen Satz von SKUs für VM-Größen angeben, die deine Organisation bereitstellen kann.
- Azure Backup muss für Virtual Machines aktiviert sein: Stelle den Schutz deiner Azure-VMs durch Aktivieren von Azure Backup sicher. Azure Backup ist eine sichere und kostengünstige Datenschutzlösung für Azure.
Oder
- Tag und zugehöriger Wert für Ressourcen erforderlich: Erzwingt ein erforderliches Tag und dessen Wert. Gilt nicht für Ressourcengruppen.
In einem Folgebeitrag werden wir zeigen, wie du auch komplexere Richtlinien erstellen und auch vorhandene Ressourcen standardisieren kannst, entweder bei der Erstellung oder aber auch „rückwirkend“.
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie