Azure-Landing-Zone für EVU

Wer als Energieversorger ernsthaft in die Cloud geht, baut keinen einzelnen Workload. Er baut ein Fundament, auf dem Jahre oder Jahrzehnte von Systemen laufen werden. Die Azure Landing Zone ist dafür Microsofts Referenzarchitektur – aber sie muss für die Besonderheiten der Energiewirtschaft angepasst werden.

Was eine Landing Zone ist

Die Azure Landing Zone ist ein vordefiniertes Set an Bausteinen für Netzwerk, Identität, Sicherheit, Governance und Operations, das als sichere Basis für alle nachfolgenden Cloud-Workloads dient. Ohne Landing Zone beginnt jedes Projekt mit Netzwerk-Diskussionen, Identity-Debatten und Policy-Festlegungen. Mit Landing Zone beginnt es mit der eigentlichen Arbeit.

Microsoft bietet mit dem Cloud Adoption Framework und den Enterprise-Scale Templates eine Referenzimplementierung. Die Kunst liegt darin, diese sinnvoll an die eigene Organisation anzupassen.

EVU-spezifische Anforderungen

Energieversorger haben Anforderungen, die über den Mainstream-Mittelstand hinausgehen:

• BSI IT-Grundschutz oder ISO 27001-konforme Umgebungen
• KRITIS-Vorgaben bei Netzbetreibern – insbesondere für SCADA-nahe Systeme
• Unbundling – technisch durchgesetzte Trennung zwischen Netz, Vertrieb und Erzeugung
• BDEW-Whitepaper-Anforderungen für Energieinformationsnetze
• Datenschutz nach DSGVO für Kundendaten in Vertriebsgesellschaften

Das ist nicht mit einer Standard-Landing-Zone abbildbar – aber mit einer gut angepassten.

Netzwerk und Konnektivität

Die typische EVU-Landing-Zone hat eine Hub-and-Spoke-Topologie: ein Hub-VNet für geteilte Services (Firewall, DNS, Monitoring, VPN/ExpressRoute-Verbindungen), Spoke-VNets für einzelne Workloads.

Wichtige Entscheidungen:

• ExpressRoute für produktive Workloads statt VPN – höhere Verfügbarkeit, niedrigere Latenz
• Private Endpoints für PaaS-Dienste (Storage, SQL, Key Vault) – keine Public Exposure
• Azure Firewall oder Third-Party NGFW je nach Compliance-Niveau
• Separation zwischen Netz-IT, Vertriebs-IT und Erzeugungs-IT über eigene Landing Zones oder strikte Management-Group-Struktur

Unbundling ist keine Netzwerkfrage. Aber wenn die Netzwerkgrenze nicht stimmt, nutzt auch die beste organisatorische Regelung nichts.

Identity und Access Management

Microsoft Entra ID (ehemals Azure AD) ist das Fundament. In der EVU-Praxis bewähren sich:

• Conditional Access Policies – MFA-Pflicht, Device-Compliance, Risk-based Access
• Privileged Identity Management – Just-in-time-Rechte für Admin-Operationen, mit Audit-Protokoll
• Entra Domain Services für Legacy-Systeme, die Kerberos/LDAP brauchen
• Service Principals statt User-Accounts für automatisierte Deployments

Governance und Policies

Ohne Policies ist eine Landing Zone ein großer Spielplatz. Mit Policies ist sie ein kontrollierter Betrieb. Essenzielle Policies für EVU:

• Region Restrictions – nur EU/West Europe zulassen (DSGVO)
• SKU Restrictions – keine Ressourcen ohne Redundanz, keine Public IPs ohne Firewall
• Tagging Enforcement – jede Ressource muss Kostenstelle, Umgebung, Ownership tragen
• Encryption at Rest – für alle Storage- und Datenbank-Ressourcen
• Diagnostic Settings – Logs und Metriken automatisch an zentrales Log Analytics senden

Operations und Monitoring

Microsoft Sentinel als SIEM, Azure Monitor als Observability-Layer, Defender for Cloud als Security-Posture-Management. Für KRITIS-Umgebungen sind das keine optionalen Extras, sondern regulatorische Basics.

In der Praxis empfehlen wir:

• Dediziertes Management-Subscription für zentrale Services (Log Analytics, Sentinel, Automation)
• Azure Monitor Workbooks für EVU-spezifische Dashboards – Netzleitstellen-Anbindung, MaKo-SLA, Backup-Erfolg
• Automatisierte Runbooks für typische Vorfälle – Zertifikats-Rotation, Failover-Tests, Patch-Deployments

Deployment und IaC

Eine Landing Zone, die per Klick gebaut wird, ist keine Landing Zone – sie ist eine Sammlung von Klicks, die niemand mehr reproduzieren kann. Bicep oder Terraform sind Pflicht. Microsoft liefert ALZ-Bicep und Azure Verified Modules als Startpunkt.

Infrastructure as Code ist keine Entwickler-Vorliebe. Es ist die einzige Möglichkeit, in einer Prüfung nachzuweisen, was wie konfiguriert wurde – und warum.

Typische Fehler

• Zu früh zu komplex – 15 Management Groups für 2 Workloads erzeugen Overhead ohne Nutzen
• Zu spät Standards setzen – nach den ersten Projekten wird jede Policy-Änderung zum Migrationsprojekt
• Unbundling als Organigramm statt Technik – separate Teams, aber gleiche Management Group
• Security als Add-on – wenn Sentinel erst nach dem ersten Incident eingeführt wird, ist es zu spät

Fazit

Eine Azure Landing Zone für ein EVU ist kein Standardprodukt. Sie ist ein angepasstes Fundament, das regulatorische, organisatorische und technische Anforderungen verbindet. Der Aufwand für ein solides Setup liegt typischerweise bei 3-6 Monaten – und zahlt sich jahrelang aus.

Der alternative Weg – jedes Projekt baut seine eigene Umgebung – produziert Inkonsistenz, Sicherheitslücken und am Ende höhere Gesamtkosten. Eine Landing Zone ist keine Bequemlichkeit, sondern eine Investition in Skalierbarkeit und Auditfähigkeit.