Um Ressourcen in Azure sicher und optimiert zu nutzen, sind einheitliche Einstellungen, definierte Berechtigungsstrukturen und Infrastrukturvorlagen notwendig. Diese gestalten Admins automatisiert mit den Azure Policies und Azure Blueprints. Damit lassen sich die Verwaltung und das Erstellen der eigenen Cloud sehr viel einfacher, sicherer und einheitlicher gestalten.
Ohne einheitliche Standards versinken Netzwerke und natürlich auch Cloudumgebungen schnell im Chaos. Nur Standards stellen sicher, dass alle relevanten Einstellungen beim Anlegen von neuen Objekten richtig gesetzt sind. Hier bietet es sich natürlich an, nicht bei jeder Objektanlage in Azure manuell zu arbeiten, sondern die Konfiguration automatisiert durchzuführen. Und eben dies erlauben Azure Policies und Azure Blueprints. Schlussendlich ist es damit möglich IT-Governance und Compliance im Netzwerk umzusetzen, sodass die Cloud einem rechtlichen und faktischen Ordnungsrahmen entspricht.
Im deutschen Portal finden Sie Azure Blueprints über "Blaupausen". Über den Menüpunkt "Erstellen" können Sie im Portal auf Basis vorhandener Vorlagen ein Azure Blueprint anlegen oder Sie nutzen eigene Vorlagen. Wir zeigen in diesem Beitrag beide Möglichkeiten auf.
Ressourcengruppen als zentrale Basis
Für Azure Blueprints sind Ressourcengruppen unerlässlich. Dabei handelt es sich, einfach ausgedrückt, um einen Container für unterschiedliche Ressourcen in Azure. Gruppen wiederum fassen die Ressourcen, die einem gemeinsamen Zweck dienen, zusammen für eine einheitliche Verwaltung. Die meisten Objekte in Azure sind kompatibel mit Ressourcengruppen, sodass sich bereits eine gewisse Grundordnung erreichen lässt, wenn die logische Unterteilung einer Cloud auf dieser Basis erfolgt. Beim Erstellen der meisten Ressourcen ist es mittlerweile sogar so, dass diese einer Ressourcengruppe zugewiesen sein müssen. Jede Ressource kann in Azure nur Mitglied einer einzelnen Ressourcengruppe sein und es ist nicht möglich, diese Gruppen zu verschachteln.
Ohne einheitliche Standards versinken Netzwerke und natürlich auch Cloudumgebungen schnell im Chaos. Nur Standards stellen sicher, dass alle relevanten Einstellungen beim Anlegen von neuen Objekten richtig gesetzt sind. Hier bietet es sich natürlich an, nicht bei jeder Objektanlage in Azure manuell zu arbeiten, sondern die Konfiguration automatisiert durchzuführen. Und eben dies erlauben Azure Policies und Azure Blueprints. Schlussendlich ist es damit möglich IT-Governance und Compliance im Netzwerk umzusetzen, sodass die Cloud einem rechtlichen und faktischen Ordnungsrahmen entspricht.
Im deutschen Portal finden Sie Azure Blueprints über "Blaupausen". Über den Menüpunkt "Erstellen" können Sie im Portal auf Basis vorhandener Vorlagen ein Azure Blueprint anlegen oder Sie nutzen eigene Vorlagen. Wir zeigen in diesem Beitrag beide Möglichkeiten auf.
Ressourcengruppen als zentrale Basis
Für Azure Blueprints sind Ressourcengruppen unerlässlich. Dabei handelt es sich, einfach ausgedrückt, um einen Container für unterschiedliche Ressourcen in Azure. Gruppen wiederum fassen die Ressourcen, die einem gemeinsamen Zweck dienen, zusammen für eine einheitliche Verwaltung. Die meisten Objekte in Azure sind kompatibel mit Ressourcengruppen, sodass sich bereits eine gewisse Grundordnung erreichen lässt, wenn die logische Unterteilung einer Cloud auf dieser Basis erfolgt. Beim Erstellen der meisten Ressourcen ist es mittlerweile sogar so, dass diese einer Ressourcengruppe zugewiesen sein müssen. Jede Ressource kann in Azure nur Mitglied einer einzelnen Ressourcengruppe sein und es ist nicht möglich, diese Gruppen zu verschachteln.
Oft nutzen Organisationen Ressourcengruppen auf Basis des Lebenszyklus bestimmter Ressourcen, zum Beispiel einer Webanwendung. Somit finden sich zugehörige Netzwerke, VMs, Datenspeicher, Datenbanken, Apps und was sonst noch alles notwendig ist, in einer gemeinsamen Ressourcengruppe. Eine andere Aufteilung geht den agilen Weg und strukturiert die Gruppen auf Basis von Microservices oder Deployment-Layern. Wichtig ist zunächst, dass Sie vor dem Erzeugen oder der Neustrukturierung der Cloudumgebung definieren, nach welcher Logik schlussendlich die Nutzung der Ressourcengruppen erfolgen soll, da dies direkte Auswirkung auf Azure Blueprints und die Azure Policies hat.
In Ressourcengruppen lassen sich einheitliche Richtlinien für die enthaltenen Ressourcen umsetzen, Ereignisse und Protokolle anlegen und verwalten sowie zentrale Metriken, Warnungen, Diagnoseeinstellungen und sogar Konfigurationsempfehlungen steuern. Ressourcengruppen, Azure Policies und Azure Blueprints arbeiten dazu zusammen. Die drei wichtigsten Werte einer Ressourcengruppe ist deren Name, das zugeordnete Abonnement und die Region (Location). Jedes dieser Werte kann nur einen Eintrag haben.
Die Region spielt für den Datenschutz eine wesentliche Rolle, da sich dadurch auch sicherstellen lässt, dass die Ressourcen in einer Gruppe, die "West Europe" zugewiesen ist, automatisch ebenfalls in dieser Region gespeichert sind. Allerdings dient das vor allem den Management-Optionen. Es ist innerhalb von Ressourcengruppen möglich, dass Ressourcen Teil einer anderen Region sind. Diese haben unter Umständen dann aber keinen Zugriff auf die anderen Ressourcen in der Gruppe, die anderen Regionen zugeordnet sind. Außerdem kann es in diesem Fall passieren, dass die Ressource, zum Beispiel eine Azure-VM, sich nicht mehr über diese Ressourcengruppe verwalten lässt. Es ist jedoch mit Richtlinien und Azure Blueprints möglich, dies zu umgehen und automatisiert zu steuern.
Richtlinien in Azure
Die eben erwähnten Azure Resource Policies sind ein zentraler Bereich der Azure Blueprints. Dabei handelt es sich um Regeln, die für das ganze Abonnement oder Ressourcengruppen und alle enthaltenen Ressourcen gelten. Sie beeinflussen das Nutzungsverhalten der Ressourcen im jeweiligen Abonnement und Sie steuern darüber zum Beispiel Remotezugriffe auf VMs, aktivieren die Protokollierung und vieles mehr. Dazu liefert Microsoft über "Richtlinien" im Azure-Portal bereits verschiedene Definitionen zur Verfügung oder Sie erzeugen individuelle Policies.
Sobald Richtlinien im Abonnement vorhanden und mit Ressourcengruppen verknüpft sind, arbeiten sie nach dem Wenn-Dann-Ansatz. Das heißt, "wenn" eine bestimmte Ressource mit definierten Bedingungen besteht, "dann" führt die Richtlinie auf dieser Basis Aktionen aus, zum Beispiel das Aktivieren der Überwachung für Azure-VMs oder das Überprüfen auf die erlaubten Regionen. Das Erstellen der Richtlinien erfolgt über JSON, was sie sehr flexibel und universell macht.
Über diese Policies ist es zudem möglich, bestimmte Aktionen im Abonnement zu überwachen und in Protokolle zu schreiben. Dadurch lassen sich fest definierte Szenarien in den Logs nachprüfen. Häufige Policies dienen der Überwachung oder Steuerung der jeweiligen Regionen, der Kostensteuerung und Einschränkung bestimmter Ressourcen, die auf Dauer zu teuer wären, zum Beispiel bestimmte VM-Vorlagen oder Speichergrößen. Ein Beispiel: "Wenn" eine Ressource in der Region "East US" erstellt werden soll, "dann" erfolgt auf Basis einer Richtlinie ein "Deny" – der Vorgang wird also untersagt. Das ist eine nützliche Methode, um sicherzugehen, dass die Ressourcen einer Ressourcengruppe nur in der definierten Region angelegt werden.
Die entsprechenden Richtlinien lassen sich über den Bereich "Richtlinie" im Azure-Portal anlegen und mit dem Abonnement oder einzelnen Ressourcengruppen verknüpfen. Das erledigen Sie über den Menüpunkt "Zuweisungen" und die Schaltfläche "Richtlinie zuweisen" in der Steuerung der Richtlinien. Die von Microsoft bereits erstellten Vorlagen finden Sie bei "Definitionen". Bei "Konformität" sind Sie in der Lage, in der zentralen Konfiguration der Richtlinien die Compliance zu überwachen. Das stellt sicher, dass die gesetzten Richtlinien auch Anwendung finden. Hier sehen Sie zudem, ob bestimmte Ressourcen oder ganze Gruppen von den Richtlinien abweichen. Alle Policies können Sie über Azure Blueprints automatisiert Objekten zuweisen, die Sie mit den Blueprints wiederum automatisiert erstellen. Dazu gleich mehr.
Bild 1: Ressourcengruppen sind eine wichtige Basis für Blueprints in Azure.
Rollenbasierter Zugriff
Role Based Access Control (RBAC) ist eine wichtige Grundlage für Azure Blueprints und auch für die Sicherheit der Umgebung. Während die Ressourcengruppen die Ressourcen in geordneten Containern zusammenfasst und die Richtlinien für die Einhaltung der jeweiligen Regeln sorgen, legt RBAC fest, wie die Rechte der einzelnen Benutzer auf die definierten Ressourcen geregelt sind, und steuert die Zugriffe. In Azure erfolgt nach Empfehlung von Microsoft die Zuweisung von Rechten nicht direkt an Benutzer, sondern nur an Benutzerrollen. Soll ein Benutzer bestimmte Rechte für eine Ressource erhalten, dann muss er Mitglied der entsprechenden Benutzerrolle sein.
Das funktioniert im Grunde genauso wie bei der Zuteilung von Rechten im Active Directory. Empfehlenswert ist hierbei der "Least Privilege"-Ansatz. Dabei erhält jede Rolle nur genau die Rechte, die sie braucht, und jeder Benutzer sollte nur den Rollen zugewiesen sein, die er benötigt. Das RBAC-Modell arbeitet eng mit Azure AD zusammen, wo vordefinierte Rollen zur Verfügung stehen. Um eigene zu nutzen, ist allerdings ein Abonnement von Azure AD Premium P1 oder P2 notwendig.
Jedes Abonnement ist mit einem Azure AD verbunden und kann Benutzer, Rollen und Berechtigungen aus diesem nutzen, um Rechte für Azure-Ressourcen im jeweiligen Abonnement zu steuern. Für die meisten Ressourcen gibt es Rollen für deren Steuerung inklusive Anlegen, Löschen oder Ändern sowie für den rein lesenden Zugriff. Darüber hinaus können Sie die Rechte natürlich sehr granular vergeben. Rollen, die das Recht haben, bestimmte Ressourcen oder auch Rollenberechtigungen zu verwalten, müssen nicht identisch sein. Es gibt Rollen, denen es erlaubt ist, eine Ressource zu verwalten, und solche, die dazu berechtigt sind, die Rechte für die Verwaltung zu steuern. Das sollte einer Rolle vorbehalten sein, die explizit dafür definiert ist. Die komplexe Steuerung dieser Rechte und die Zuordnung von Rollen lässt sich ebenfalls mit Azure Blueprints steuern.
Bild 2: Das Zuweisen von Richtlinien im Azure-Portal erfolgt an komplette Azure-Abonnements oder einzelne Ressourcengruppen.
Aufgaben von Azure Blueprints
Azure Blueprints haben die Aufgabe, beim Anlegen von Cloudumgebungen die vorangegangenen Bereiche von Ressourcen umfassend zu steuern und weitgehend zu automatisieren. Blueprints fassen die Optionen aller Tools und Bereichen in Azure, die der IT-Governance dienen, zu gemeinsamen Blaupausen zusammen. Im Fokus steht dabei das Bereitstellen einer kompletten Arbeitsumgebung, in der alle Konfigurationen, Rechte, Ressourcen, Gruppen und Funktionen automatisiert so konfiguriert werden, dass diese einem vorgegebenen Standard entsprechen. Blueprints können daher nicht nur Ressourcen anlegen, sondern auch Ressourcengruppen mit den definierten Optionen und allen Berechtigungen sowie Richtlinien. Dazu kommt die Zuweisung von Richtlinien und das Erteilen von Rechten.
Dadurch lässt sich mit wenigen Klicks eine komplette Azure-Umgebung aufbauen, zum Beispiel für Entwickler oder für Tests. Was üblicherweise recht aufwendig ist, vereinfacht Azure Blueprints deutlich. Einmal definierte Umgebungen lassen sich in kurzer Zeit reproduzieren. Dazu gehört das Erstellen und Anpassen von Netzwerken, die Definition von VPN-Verbindungen, das Konfigurieren von Firewall-Regeln und vieles mehr. Sie können alle Konfigurationen im Blueprint definieren und auf dieser Basis eine komplette Azure-Umgebung mit allen notwendigen Konfigurationen hochziehen.
Blueprints inkludieren in Azure alle notwendigen Ressourcen, Anforderungen, Rechte, Richtlinien, Optionen und die damit verbundenen Ressourcengruppen. Mit einem Blueprint standardisieren Sie die Bereitstellung einer Ressourcen mit allen Settings und Richtlinien. Dazu kommt die Wiederholbarkeit des Deployment: Ist ein Blueprint vorhanden, lassen sich die Ergebnisse jederzeit wiederholen, auch in anderen Abonnements. Das ermöglicht das sehr schnelle Skalieren von kompletten Azure-Cloudumgebungen oder den Neuaufbau einer Umgebung auf Basis fest definierter Regeln. Die Anwendung von Blueprints ist regionsübergreifend möglich und Sie sind daher in die Lage, diese auf mehrere Abonnements, Umgebungen und Regionen zu verteilen.
Bild 3: Die korrekte Umsetzung der definierten Richtlinien lässt sich im Azure-Portal bei "Übersicht" in den "Richtlinien" überprüfen.
Hierarchien nutzen
Beim Anlegen einer Blaupause können Sie diese entweder einem einzelnem Abonnement zuweisen oder gleich eine Management Group verwenden, in der mehrere Abonnements zusammengefasst sind. Bei der ersten Vorgehensweise ist das jeweilige Blueprint nur für dieses Abonnement verfügbar. In beiden Fällen müssen Sie zunächst einen Namen und eine Beschreibung eintragen und bei "Speicherort der Definition" wählen Sie die Management Group oder das Abonnement aus.
Innerhalb eines Blueprints können Sie eine Hierarchie definieren und Objekte darin konfigurieren. Dies erlaubt Ihnen zum Beispiel, zunächst Ressourcengruppen zu erzeugen und in den Gruppen danach die Ressourcen. Arbeiten Sie hier parallel mit ARM-Templates und erzeugen diese über Blueprints, folgen solche Ressourcen den Vorgaben der hinterlegten ARM-Templates. In der Hierarchie können Sie außerdem Richtlinienzuweisungen nutzen. Die Richtlinien wendet Azure an, sobald das Blueprint die in ihm definierten Ressourcen aufbaut. Das gilt parallel für die Berechtigungen über RBAC.
Erzeugen und Verwalten von Blueprints
Im Portal finden Sie über "Erste Schritte" einen Einstieg in die Verwaltung und legen über "Blaupausendefinitionen" eigene Blaupausen an beziehungsweise nutzen die Vorlagen von Microsoft. Bereits angelegt und zugeordnete Blueprint finden Sie bei "Zugewiesene Blaupausen". Blueprints lassen sich auch über eine Rest-API steuern, auch über die PowerShell. Details dazu liefert [1].
Wie schon erwähnt, starten Sie unter "Blaupausendefinitionen / Blaupause erstellen" ihre Standardisierung. Sie haben die Wahl, eine "Leere Blaupause" oder eine der zahlreichen Vorlagen zu nutzen. Beliebt sind zum Beispiel die Definitionen "Gängige Richtlinien", bei denen die am häufigsten verwendeten Policies ebenso voreingestellt sind wie die "Zielzone für CAF-Migration" für das Microsoft Cloud Adoption Framework für Azure. Wählen Sie die Definition aus, startet der Einrichtungsassistent der Blaupause. Nachdem Sie Name und Reichweite definiert haben, wechseln Sie in die "Artefakte". Hier legen Sie die Objekte fest, die Sie auf Basis der oben erwähnten Hierarchie anlegen und steuern deren Parameter.
Auf Ebene der Abonnements können Sie Ressourcengruppen unterteilen und darin die einzelnen Objekte und Rollen eingliedern. Via "Artefakt hinzufügen" integrieren Sie weitere Bereiche in den Blueprint und legen den Namen der einzelnen Objekte fest beziehungsweise arbeiten mit Platzhaltern. Anschließend erledigen Sie mit "Entwurf speichern" genau dies und die Blaupause ist einsatzbereit. Jetzt finden Sie sie auch im Menü "Blaupausendefinitionen", wo jederzeit Anpassungen möglich sind. Die bereits vorhandenen Artefakte sind abhängig von Ihrer Definition.
Bei einem leeren Blueprint müssen Sie alle Artefakte beziehungsweise Bereiche manuell vorgeben. Klicken Sie in diesem Fall auf "Artefakt hinzufügen", können Sie bei "Artefakttyp" auswählen, ob Sie eine Richtlinienzuweisung, Rollenzuweisung, ARM-Vorlage oder Ressourcengruppe benötigen. Haben Sie das Artefakt hinzugefügt, klicken Sie es an und definieren die gewünschten Werte.
Bild 4: Die "Artefakte" definieren, welche Objekte ein Blueprint steuert.
Blaupausen veröffentlichen
Haben Sie Ihre Blueprints angelegt, weisen Sie diesen Abonnements zu. Damit das funktioniert, müssen die Blaupausen veröffentlicht sein. Dazu klicken Sie in den Einstellungen auf "Blaupause veröffentlichen", geben eine Version ein und eine Beschreibung, was diese Version enthält. Sie können mit "JSON-Ansicht" auch die Definition im JSON-Format anschauen. Ist die Veröffentlichung erfolgt, klicken Sie im Bereich "Blaupausendefinitionen" auf eine Ihrer Blaupausen und aktivieren diese mit "Blaupause zuweisen" im jeweiligen Abonnement.
Im Fenster geben Sie der Zuweisung einen Namen und wählen den Standort aus, in dem die Ressourcen auf dieser Basis erstellt werden sollen. Mit "Zuweisen" wenden Sie die Blaupause an. Sie legen auch fest, ob die Blaupause einen Systemaccount für das Deployment der Ressourcen nutzen soll oder dies über einen Benutzer erfolgt, der Administratorrechte in der Umgebung hat. Erfordert Ihr Blueprint noch das Ausfüllen von Parametern, sehen Sie das im unteren Bereich des Bereitstellungsfensters und erledigen das auch gleich hier. Geben Sie die Parameter bereits über die Blaupause vor, sind diesbezüglich keine Eingaben notwendig. Sobald Sie die Zuweisung abgeschlossen haben, legt Azure die Ressourcen auf Basis der Vorgaben in der Blaupause an.
Fazit
Azure Blueprints sind eine ideale Möglichkeit, die Bereitstellung von umfangreichen Cloudumgebungen in Azure zu automatisieren und zu vereinheitlichen. So profitieren Sie von identisch konfigurierten und fehlerfreien Landschaften. Dadurch lassen sich Entwicklungs- und Testumgebungen in kurzer Zeit aufbauen.