Azure Landing Zones: Effektiver Schutz kritischer Ressourcen – Lösungsansätze und Best Practices

27. September 2024

Nick Schmeiter

Christian Pino

In einer Azure Landing Zone gibt es zahlreiche Herausforderungen, insbesondere wenn es um den Schutz kritischer Infrastruktur geht. Dieser Blogbeitrag untersucht verschiedene Ansätze, die von Plattform-Teams zur Sicherstellung der Stabilität und Sicherheit der Azure-Umgebungen verwendet werden.

Problemstellung

Eine Azure Landing Zone ist eine Umgebung, welche die wichtigsten Azure-Entwurfsprinzipien zusammenfasst und so ein bewährtes Deployment einer Azure-Umgebung entsprechend des von Microsoft empfohlenen Cloud Adoption Frameworks ermöglicht.

Auch wenn das Cloud Adoption Framework versucht alle Aspekte einer Azure Landing Zone zu berücksichtigen, gibt es dennoch Punkte, für die es keine konkrete Handlungsanweisung gibt.

Das CAF verwendet zwei Typen von Landing Zones (LZ), die Platform LZ und die Application LZ:

• Platform Landing Zones werden vom „Plattform-Team“ verwaltet.
• Application Landing Zones werden von „Application-Teams“ verwaltet.

Eine Herausforderung, die dadurch für das Plattform-Team entsteht, ist: Wie schaffe ich es die kritische Azure-Infrastruktur vor Änderungen des Application-Teams zu schützen, die gravierende Auswirkungen auf die Azure Landing Zone haben könnten. Dazu gehört beispielsweise das Hinzufügen eines CIDR-Blocks zu einem bestehenden Azure Virtual Network.

Wenn das Plattform-Team eine Subscription für das Application-Team bereitstellt, bekommt der Mitarbeitende des Application-Teams die Azure-Rolle Owner. Falls dieser Mitarbeitende jetzt das Virtual Network erweitert und einen CIDR-Block hinzufügt, kann es zu Konflikten kommen.

Microsoft stellt verschiedene Optionen zur Verfügung, um diese Ressourcen zu schützen. Dazu zählen unter anderem Custom Roles, Deployment Stacks und Deny Action Policies.

Sobald das Plattform-Team die Azure Landing Zone bereitgestellt hat, liegt die Administration jedoch in den Händen des Application-Teams. Aus diesem Grund geht jedes Plattform-Team mit dieser Problemstellung anders um, was zu vielen verschiedenen Lösungen für das Schützen kritischer Ressourcen führt. Als Grundlage für diesen Blogartikel, habe ich daher mit verschiedenen Kunden Interviews geführt, um so ein differenziertes Bild zu den verschiedenen Lösungen zu bekommen.

Verschiedene Lösungswege von Kunden

Custom Roles

Eine Lösung, die viele Plattform-Teams implementiert haben, ist die Nutzung von Custom Roles. Das bedeutet, dass jedes Mitglied des Application-Teams, das die Azure-Umgebung nutzen will, einer eigenen Rollengruppe zugeordnet wird.

Der Vorteil ist hier, dass wenn alle Rollen und User richtig gepflegt sind, alle kritischen Ressourcen, welche vom Plattform-Team bereitgestellt wurden, sicher sind. Jeder User kann dann nur die Ressourcen ändern, für die er berechtigt ist.

Ein Kunde hatte während des Interviews auf die Frage, wieso das Plattform-Team keine Custom Roles verwendet, diese Antwort gegeben: „Die Custom Roles müssen im Standard da sein.“ Die Designentscheidung keine Custom Roles zu nutzen, wurde weiter damit begründet, dass der Pflegeaufwand zu hoch ist und sich individuell mit jedem User von Azure auseinandergesetzt werden muss.

Azure Deployment Environments

Einzelne Plattform-Teams arbeiten mit einem Konzept vergleichbar zum Azure Deployment Environment. Bei diesem Konzept wird dem Application-Team nur erlaubt, den eigentlichen Application Code selbst bereitzustellen. Alle Azure Infrastructure Services werden durch das Plattform-Team bereitgestellt und verwaltet. Das hat sich im Kontext von Azure Kubernetes Services als sehr praktikabel erwiesen.

Jedoch birgt dieses Modell auch die Gefahr, dass das Plattform Team überlastet wird, falls sehr viele individuelle Lösungen von den verschiedenen Application-Teams benötigt werden.

Azure Policy

Als Alternative zu Custom Roles und Azure Deployment Environments werden Custom Azure Policies verwendet. Diese ermöglichen es ebenfalls, die kritischen Azure-Ressourcen vor unerwünschten Modifikationen durch die Application-Teams zu schützen. Einer der befragten Kunden verwendet aktuell ausschließlich 15 Custom Azure Policies, um dieses Ziel zu erreichen. Es wird dabei komplett auf den Einsatz von Custom Roles verzichtet. Durch die geringe Zahl an benötigten Azure Custom Policies hält sich der Pflegeaufwand ebenfalls in Grenzen.

Weitere Alternativen

Im Folgenden möchten ich zwei Azure-Lösungen vorstellen, die aktuell in der Dokumentation zu den Azure Landing Zones noch nicht erwähnt werden, jedoch das Potenzial haben, die hier besprochene Anforderung zu erfüllen.

Deployment Stacks

Azure Deployment Stacks sind eine Funktion von Azure, die es ermöglicht, eine Gruppe von Azure-Ressourcen als eine einzelne, zusammenhängende Einheit zu verwalten. Dies wird durch das Einreichen einer Bicep-Datei oder einer ARM JSON-Vorlage an den Deployment Stack erreicht, wodurch die zu verwaltenden Ressourcen definiert werden.

Einige der Hauptvorteile der Deployment Stacks sind:

• Vereinfachte Bereitstellung und Verwaltung: Ressourcen können über verschiedene Bereiche hinweg als eine Einheit verwaltet werden.
• Schutz vor unerwünschten Änderungen: Durch Einstellungen, die Änderungen verhindern.
• Effiziente Bereinigung von Umgebungen: Ressourcen können durch einfache Updates des Stacks entfernt werden.

Deployment Stacks nutzen Standardvorlagen wie Bicep, ARM-Vorlagen oder Template-Spezifikationen und können über die Azure CLI, Azure PowerShell oder das Azure Portal erstellt und aktualisiert werden.

Wenn ein Deployment Stack zum Beispiel auf einer Ressourcen-Gruppen-Ebene angelegt wird, können die enthaltenen Ressourcen von niemandem innerhalb der Ressourcen-Gruppe gelöscht werden. Es sei denn, es wird die gesamte Ressourcen-Gruppe gelöscht.

Der Activity Log-Eintrag im folgenden Screenshot zeigt, wie die Ressourcen im Deployment Stack geschützt sind und dass sie nicht einfach gelöscht werden können:

Die Vorteile der Deployment Stacks sind sowohl das einfache Schützen von kritischen Ressourcen sowie das einfache Verwalten von mehreren Ressourcen. Eine hilfreiche Einführung zu den Deployment Stack bietet das Training „Introduction to Deployment Stacks“ auf Microsoft Learn.

Deny Action Policies

Deny Action Policies sind ein weiterer Weg kritische Ressourcen zu schützen. Hierzu müssen Custom Policies erstellt und dem denyAction-Effekt hinzufügt werden. Man kann dann die Custom Policy so anpassen, wie man möchte. Zum Beispiel Ressourcen mit bestimmen Tags, bestimmte Ressourcenarten oder Ressourcen von bestimmten Locations schützen.

Im folgenden Screenshot sehen wir, wie die Ressource, die durch die denyAction-Policy geschützt wurde, und daher nicht gelöscht werden konnte:

denyAction-Policies können sehr granular genutzt werden. Daher sind sie sehr nützlich für spezielle Use Cases. Auch kann man großflächig eine hohe Anzahl an Ressourcen mit nur einer Policy schützen. Leider unterstützt denyAction aktuell einzig den HTTP DELETE Request an Azure Resource Manager (ARM):

Die Auswirkung denyAction wird verwendet, um Anforderungen basierend auf der beabsichtigten Aktion für Ressourcen im großen Stil zu blockieren. Die einzige unterstützte Aktion ist derzeit DELETE. Dieser Effekt und die Bezeichnung der Aktion tragen dazu bei, ein versehentliches Löschen wichtiger Ressourcen zu verhindern.

Damit ist es aktuell leider mit dieser Methode noch nicht möglich, Änderungen in ARM durch andere HTTP-Methoden (z.B. PUT, UPDATE, GET) zu verhindern.

Fazit

Abschließend lässt sich sagen, dass es aktuell keine klare Vorgabe von Microsoft gibt, auf welche Weise man diese Anforderung umsetzen sollte. Jedoch stellen die hier genannten Lösungen (Policy Deny Action und Deployment Stacks) vielversprechende Konzepte dar, die zum gewünschten Ergebnis führen.

Weiterführende Ressourcen

• Dokumentation zu den Azure Landing Zones
• Bereitstellung von Azure Landing Zones
• Video: Azure Landing Zones Q&A
• Dokumentation zu den Deployment Stacks
• Training: Einführung zu den Azure Deployment Stacks
• Dokumentation zu Deny Action
• Azure Innovation: Ressourcen zu den Infrastruktur-Diensten von Azure
• Aktuelle Events rund um die Nutzung von Azure