Eine Landing Zone für den Mittelstand, in Terraform oder Bicep: die Teile, die zählen

Eine Landing Zone ist der vorbereitete Boden, auf dem Ihre Cloud-Workloads landen: die Konto- und Subscription-Struktur, Leitplanken, Identität, Netzwerk, Logging und Kostenkontrolle, alles eingerichtet, bevor die erste Anwendung kommt. Referenzarchitekturen für Konzerne sehen aus, als bräuchten sie ein Plattformteam von zwanzig Leuten. Ein mittelständisches Unternehmen braucht dieselben Ideen in kleinerer Grösse, als Code geschrieben, damit ein Team von zwei Personen sie betreiben kann. Hier ist die Version, die ich baue.

Dominik Heinrich

8. November 202611 Min. Lesezeit

1. Was eine Landing Zone abdeckt

Das Cloud Adoption Framework von Microsoft teilt die Azure Landing Zone in acht Gestaltungsbereiche: Abrechnung und Entra-Tenant, Identität und Zugriff, Ressourcenorganisation, Netzwerktopologie und Konnektivität, Sicherheit, Betrieb, Governance sowie Plattformautomatisierung mit DevOps. Diese Liste ist eine gute Checkliste, auch wenn Sie etwas viel Kleineres bauen als die Referenzarchitektur.

Der Sinn des Ganzen ist einfach: Teams sollen eine neue Subscription für eine Anwendung anlegen können und Sicherheit, Netzwerk, Logging und Kostenkontrolle schon vorfinden, statt dass jedes Team sein eigenes erfindet. Für den Mittelstand heisst das: eine Handvoll Management Groups und Policies, ein Hub-Netzwerk, zentrale Logs und Budgets, alles von einer Pipeline ausgerollt.

2. Management Groups nach Zweck, nicht nach Abteilung

Mit Management Groups wenden Sie Policies und Zugriffsrechte auf viele Subscriptions gleichzeitig an. Ein Baum kann bis zu sechs Ebenen tief sein, ohne Root und Subscriptions, aber ein mittelständisches Unternehmen braucht selten mehr als zwei oder drei. Ich verwende: oben eine Gruppe für das Unternehmen, darunter Plattform (Identität, Betrieb, Konnektivität), Landing Zones (aufgeteilt in intern und aus dem Internet erreichbar, wenn deren Regeln sich unterscheiden), Sandbox für Experimente mit Budgetgrenze und Decommissioned für Subscriptions, die verschwinden.

Vermeiden Sie es, das Organigramm abzubilden. Abteilungen werden umorganisiert; der Unterschied zwischen einer internen und einer öffentlichen Anwendung bleibt. Gruppen nach Zweck halten Policies stabil, wenn sich das Unternehmen verändert.

Tipp aus der Praxis

Eine Subscription pro Anwendung und Umgebung ist ein guter Standard: Sie ist die sauberste Grenze für Zugriff, Netzwerk und Kosten und macht die Rechnung lesbar, ganz ohne Tag-Zauberei.

3. Leitplanken als Policy, ganz oben

Azure Policy ist der Ort, an dem eine Landing Zone ihren Wert zeigt. Weisen Sie die Regeln der Unternehmens-Management-Group zu, damit sie für alles darunter gelten: erlaubte Regionen, Pflicht-Tags, keine öffentlichen IP-Adressen, wo sie nicht nötig sind, Diagnoseeinstellungen an den zentralen Workspace, Mindeststandards für Verschlüsselung und TLS. Neue Regeln starten im Audit-Modus, Sie beheben, was sie finden, und schalten dann auf Deny.

In einem Automotive-Projekt setzten Azure Policies und Blueprints Sicherheits-Baselines und Netzwerkregeln über alle Teams durch, und eine regulierte Anwendung zog nach Azure Kubernetes Service, ohne dass eine einzige Kontrolle gelockert wurde. Die Teams mussten sich die Regeln nicht merken; die Plattform lehnte ab, was sie verletzte.

hcl

# Allowed regions for everything under the company management group
resource "azurerm_management_group_policy_assignment" "allowed_locations" {
  name                 = "allowed-locations"
  management_group_id  = azurerm_management_group.company.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c" # built-in: Allowed locations

  parameters = jsonencode({
    listOfAllowedLocations = { value = ["switzerlandnorth", "westeurope"] }
  })
}

Landing Zone für ein mittelständisches Unternehmen auf Azure: Terraform oder Bicep in Git, von einer Pipeline ausgerollt; unter dem Entra-ID-Tenant-Root eine Unternehmens-Management-Group mit Policies für Regionen, Tags und keine öffentlichen IPs; eine Gruppe Plattform mit Identität (Gruppen, PIM), Betrieb (Logs, Defender), Konnektivität (Hub-Netzwerk, Firewall), Budgets mit Alarmen pro Subscription und Tags für Owner, Kostenstelle und Umgebung; eine Gruppe Landing Zones mit Subscriptions Corp und Online und Spoke-Netzwerken, die mit dem Hub gepeert sind; dazu Gruppen Sandbox und Decommissioned. — Die Landing-Zone-Struktur, die ich im Mittelstand verwende: Plattform, Landing Zones, Sandbox und Decommissioned, alles als Code ausgerollt. Klicken für volle Grösse.

4. Eine Identität, keine dauerhaften Admin-Rechte

Alles meldet sich über Entra ID an. Vergeben Sie Rechte an Gruppen, nie an einzelne Personen, damit Ein- und Austritte an einem Ort erledigt sind. Owner und andere hohe Rollen werden nicht dauerhaft vergeben: Mit Privileged Identity Management beantragen Personen sie für ein paar Stunden, mit Begründung, und es wird protokolliert.

Anwendungen verwenden Managed Identities statt gespeicherter Secrets, wo immer der Dienst es erlaubt, und die übrigen Secrets liegen in Key Vault mit Zugriff über Identitäten. Halten Sie zwei Notfallkonten ausserhalb des normalen Ablaufs, stark geschützt und mit Alarm bei jeder Anmeldung, damit Sie eine kaputte Identitätskonfiguration nicht aus Ihrer eigenen Cloud aussperrt.

5. Netzwerk: ein Hub, ein Spoke pro Workload

Hub-and-Spoke ist für die meisten mittelständischen Unternehmen der richtige Standard. Der Hub enthält die gemeinsamen Teile: die Firewall, die Verbindung zum Büro oder Rechenzentrum (VPN oder ExpressRoute), DNS. Jeder Workload bekommt sein eigenes Spoke-Netzwerk, mit dem Hub gepeert, und der Verkehr zwischen Spokes und ins Internet läuft über die Firewall, wo Sie ihn sehen und steuern.

Planen Sie Adressbereiche einmal, für Jahre, und schreiben Sie sie auf; überlappende Bereiche gehören zu den teuersten Fehlern, die man später beheben muss. Nutzen Sie Private Endpoints für Datenbanken und Speicher, damit sie aus dem Internet gar nicht erreichbar sind, und lassen Sie eine Policy öffentliche Endpunkte ablehnen, wo sie nicht vorgesehen sind.

6. Logs, Sicherheit und ein Budget auf jeder Subscription

Die Management-Subscription enthält den zentralen Log Analytics Workspace, Defender for Cloud und die Alarmierung. Eine Policy sorgt dafür, dass jede neue Ressource ihre Diagnosedaten dorthin schickt, damit niemand daran denken muss. Alarme gehen an Personen, die handeln können, nicht an ein gemeinsames Postfach, das niemand liest.

Kostenkontrolle ist Teil der Landing Zone, kein Nachgedanke. Jede Subscription bekommt ein Budget mit Alarmen auf die Prognose, und jede Ressource die Tags Owner, Kostenstelle und Umgebung, per Policy durchgesetzt. Im Automotive-Projekt sorgten Kostenkontrollen und eine Tagging-Strategie dafür, dass jeder Euro einen Owner hatte; das macht aus einer Cloud-Rechnung statt einer Überraschung ein Gespräch.

7. Alles als Code, von einer Pipeline ausgerollt

Eine Landing Zone, die im Portal zusammengeklickt wurde, driftet innert Wochen ab. Schreiben Sie sie als Code in Git und lassen Sie eine Pipeline sie ausrollen, mit einem Plan, den vor jeder Änderung jemand prüft. Sie müssen nicht bei null beginnen: Microsoft pflegt fertigen Code für die Azure Landing Zone, für Terraform und für Bicep (das Terraform-Modul gehört zu den Azure Verified Modules), der die Referenzstruktur umsetzt und Teile an- und abschalten lässt.

Für ein mittelständisches Unternehmen nehme ich meist diese Module, kürze sie auf das, was jetzt gebraucht wird, und halte die Konfiguration in einem kleinen Repository: Management Groups, Policy-Zuweisungen, das Hub-Netzwerk, Budgets und Rollenzuweisungen. Neue Anwendungsteams bekommen dann eine Subscription per Pull Request, mit allem darüber bereits eingerichtet.

8. Dieselbe Struktur auf AWS und Google Cloud

Auf AWS heissen die Bausteine anders, erfüllen aber dieselben Aufgaben. Accounts übernehmen die Rolle der Subscriptions, Organizational Units die der Management Groups, und Service Control Policies setzen Leitplanken über alle hinweg. Beachten Sie, wie SCPs funktionieren: Sie gewähren nie Rechte, sie legen das Maximum fest, das Rollen in diesen Accounts haben können. AWS Control Tower richtet mit diesen Teilen eine Landing Zone ein, wendet Controls an (auch Guardrails genannt) und legt über Account Factory neue Accounts aus Vorlagen an.

Google Cloud veröffentlicht einen eigenen Leitfaden für Landing Zones mit Ordnern, Richtlinien auf Ordnerebene und einem Shared VPC pro Umgebung. Auf welcher Cloud Sie auch sind, die fünf Entscheidungen bleiben dieselben: Struktur nach Zweck, Leitplanken ganz oben, eine Identität ohne dauerhafte Admin-Rechte, ein zentrales Netzwerk und zentrale Logs, und alles als Code.

Fazit
Eine gute Landing Zone ist klein, unspektakulär und als Code geschrieben: Struktur nach Zweck, Leitplanken als Policy ganz oben, eine Identität, ein Hub-Netzwerk, zentrale Logs und ein Budget auf jeder Subscription.

Echte Projekte dazu

Eine regulierte Anwendung zieht nach Azure, komplett in Terraform

Selbst ausprobieren

Cloud-Rechnung schätzen

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden