Was eine Ausnahme kostet
Eine Landing Zone wird einmal entworfen und danach im Betrieb erweitert, und genau dort beginnt ihre eigentliche Geschichte. Das erste Projekt mit einer harten Deadline bekommt seine Subscription außerhalb der Hierarchie, weil der Policy-Review länger gedauert hätte als der Sprint. Der Dienstleister, der an einem Freitagnachmittag mit Contributor-Rechten nicht weiterkam, erhält Owner auf der Management Group und behält ihn, weil nach dem Go-live niemand mehr daran denkt. Und wenn die Firewall im Hub den Durchsatz eines Spokes drückt, bekommt der Spoke sein Peering direkt, am Hub vorbei. Jede dieser Entscheidungen war in ihrem Moment vernünftig, und jede ist bis heute in Kraft.
Die Folgen sind konkret. Eine Subscription außerhalb der Hierarchie erbt keine Policy, also schützt die Policy sie auch nicht. Ein Owner auf Management-Group-Ebene vererbt sich auf jede Subscription darunter, auch auf die, die es damals noch nicht gab. Ein Peering ohne Route zur Firewall ist ein Netzpfad, den euer SOC nicht sieht. Der Azure Landing Zone Review legt den Entwurf und den Ist-Zustand übereinander, entlang der acht Design Areas des Cloud Adoption Framework, und sortiert die Abweichungen nach ihren Folgen, nicht nach ihrem Alter.
Die acht Design Areas des Cloud Adoption Framework
Microsoft hat die Entscheidungen einer Landing Zone in acht Design Areas sortiert, weil sich die meisten Fehler sonst in den Lücken zwischen den Teams verstecken: Das Netzwerkteam baut den Hub, das Identity-Team vergibt die Rollen, und wer die Policy-Ausnahme genehmigt hat, steht in keinem der beiden Protokolle. Wir gehen alle acht durch, jede mit derselben Frage: Was war vorgesehen, was ist gebaut, und was folgt aus der Differenz.
Azure Billing und Entra-Tenant
Enrollment, Billing-Hierarchie und der Tenant, auf dem alles sitzt. Ein zweiter Tenant aus einer Übernahme ist selten ein Problem, bis jemand Lizenzen, Identitäten und Rechnungen zusammenführen muss.
Identity und Access Management
Rollen auf Plattformebene, Service Principals und PIM. Ein Owner auf der Root Management Group vererbt sich lautlos auf jede Subscription, die später entsteht.
Resource Organization
Management-Group-Hierarchie, Subscription-Design, Namen und Tags. Workloads in der falschen Management Group erben die falschen Policies, und das fällt erst auf, wenn ein Audit nachfragt.
Network Topology und Connectivity
Hub-and-Spoke oder Virtual WAN, Hybridanbindung, DNS, Firewall, Private Endpoints. Ein Peering am Hub vorbei ist technisch sauber und für das SOC unsichtbar.
Security
Defender for Cloud, Verschlüsselung, Key Vaults und alles, was auf der Plattform liegt statt im Workload. Ein Defender-Plan, der auf einem Teil der Subscriptions aktiv ist, schützt genau diesen Teil.
Management
Monitoring, Logging, Backup und Recovery. Fehlende Diagnostic Settings fallen nicht im Betrieb auf, sondern im Incident, wenn die Logs gebraucht werden, die nie geschrieben wurden.
Governance
Azure Policy, Initiativen, Ausnahmen und Kostenkontrolle. Eine Exemption hat ein Ablaufdatum, wenn jemand eines gesetzt hat. Die meisten haben keines.
Platform Automation und DevOps
Infrastructure as Code, Pipelines, Azure Verified Modules. Eine Plattform, die per Portal geändert wird, hat zwei Wahrheiten, die im Repository und die in Azure. Es gilt die zweite.
So läuft es ab
- Team befragenTeam befragenWir beginnen mit den Leuten, die die Plattform betreiben, nicht mit dem Tool: Architektur, Werkzeuge, Betriebsprozesse, Strategie. Die meisten Befunde, die ein Scan später liefert, haben eine Vorgeschichte, und wer sie kennt, bewertet sie richtig. Eine bewusste Entscheidung ist etwas anderes als ein vergessenes Provisorium.
- Umgebung auslesenUmgebung auslesenDann lesen wir die Umgebung mit Tooling aus: Management Groups, Policies und Exemptions, Rollenzuweisungen, Netzwerkpfade, Diagnostic Settings, Kosten. Automatisiert und gegen den aktuellen Stand des Cloud Adoption Framework, nicht gegen den von vor drei Jahren.
- Befunde sortierenBefunde sortierenDas Tool findet die Abweichung, das Interview erklärt sie, und erst beide zusammen ergeben eine Priorität. Oben steht, was Rechte vererbt oder Logs verhindert, unten, was ein Namensschema verletzt. Ein Befund ohne Folge ist eine Notiz, kein Auftrag.
- Report durchsprechenReport durchsprechenIhr bekommt den Report mit Reifegrad je Design Area, Befunden und Empfehlungen, und wir gehen ihn gemeinsam durch. Nicht, damit ihr hundert Befunde kennt, sondern damit ihr am Montag wisst, mit welchem ihr anfangt.
Ein Report mit Reihenfolge
Ihr bekommt einen Report, der eure Landing Zone entlang der acht Design Areas einordnet: Reifegrad je Bereich, priorisierte Befunde und Empfehlungen, die ein Plattformteam umsetzen kann, ohne uns zu fragen. Dazu die Unterscheidung, die kein Scanner leistet: welche Abweichung vom Framework eine Entscheidung war und welche ein Versehen. Gedacht ist er für Plattformteams und IT-Leitung, die eine Landing Zone seit einigen Jahren betreiben und wissen wollen, was sich seitdem verändert hat, an der Umgebung und am Framework. Wer vor einer Migration steht, prüft besser das Fundament als den Umzug. Wer die Plattform von einem Dienstleister übernommen hat, braucht ein zweites Augenpaar, das nicht gebaut hat, was es bewertet. Die Umsetzung ist nicht enthalten. Sie läuft als eigenes Projekt, mit uns, mit einem Partner oder mit eurem Team.
Und danach
Was uns vorab gefragt wird
Die Fragen aus den ersten Gesprächen, beantwortet so, wie wir sie dort beantworten.
Brauchen wir dafür eine Landing Zone von glueckkanja?
Nein. Wir prüfen jede Landing Zone, ob aus dem Enterprise-Scale-Template, von einem anderen Dienstleister oder im Portal gewachsen. Der Maßstab ist das Cloud Adoption Framework, nicht unsere Azure Foundation. Dass wir sie empfehlen, wenn der Report es hergibt, ist keine Überraschung, aber auch keine Bedingung.
Was unterscheidet den Review vom Modul Azure der Preventive Services?
Die Frage, die gestellt wird. Das Modul Azure fragt, wie ein Angreifer von einer Subscription zur Kontrollebene kommt, und endet in einer Härtungs-Roadmap. Der Landing Zone Review fragt, ob die Plattform als Ganzes trägt: Organisation, Netz, Governance, Betrieb, Automatisierung, Kosten. Security ist dabei eine von acht Design Areas. Wer beides will, beginnt mit dem Review, weil er die Landkarte liefert, auf der das Modul die Wege einzeichnet.
Welche Rechte braucht ihr?
Lesende. Für die Analyse reicht eine Reader-Rolle auf der obersten Management Group, ergänzt um Leserechte auf Cost Management. Wir ändern nichts, und die Zugänge werden nach dem Review entfernt. Dass sich der Review mit Reader-Rechten durchführen lässt, ist selbst schon ein Befund: Eine Landing Zone, bei der das nicht geht, hat ihr erstes Thema gefunden.
Prüft ihr auch die Kosten?
Ja, weil sie in einer Landing Zone dieselben Ursachen haben wie die Governance-Befunde. Ohne Tags lässt sich eine Rechnung keinem Team zuordnen, ohne Budget-Alerts fällt eine vergessene VM erst am Monatsende auf, und eine Reservierung, die niemand pflegt, bezahlt Kapazität, die niemand nutzt. Was dort auffällt, steht im Report, mit Zahl.
Wie lange dauert der Review?
Interview und Analyse brauchen wenige Tage. Auf eurer Seite kostet er einen Interviewtermin, die Freigabe der Leserechte und den Termin, in dem wir den Report durchgehen. Der aufwendigere Teil ist das, was ihr danach mit der Liste macht, und der gehört euch.
Ist die Umsetzung enthalten?
Nein, mit Absicht. Ein Review, der seine eigenen Folgeaufträge priorisiert, wäre keiner. Ihr bekommt Reihenfolge und Empfehlungen, die Umsetzung läuft als eigenes Projekt, mit uns, mit einem Partner oder mit eurem Team. Wer die Landing Zone danach neu aufsetzen will, findet in der Azure Foundation den Weg dorthin.
