Azure Governance Starter – Teil 1: Grundlagen, Risiken und Frameworks verstehen

Warum Cloud Governance mehr als Richtlinien ist

Beim Einstieg in Azure wird oft primär auf Geschwindigkeit und Flexibilität gesetzt. Schnell sind Subscriptions angelegt, Ressourcen bereitgestellt, Workloads migriert. Doch ohne strukturierte Governance kommt es früher oder später zu Sicherheitsrisiken, Kostenexplosionen und operativen Problemen. Governance ist kein nachträglicher Kontrollmechanismus, es ist das Fundament eines nachhaltigen Cloud-Betriebs. Microsoft bietet mit dem Cloud Adoption Framework (CAF) und dem Well-Architected Framework (WAF) zwei strukturierte Leitfäden, um Governance strategisch, operativ und technisch zu verankern.

Während klassische IT-Infrastrukturen in der Vergangenheit stark zentralisiert betrieben wurden, bringen Cloud-Plattformen wie Azure eine Demokratisierung der Infrastruktur mit sich. Entwickler, Projektteams oder Fachbereiche können selbstständig Ressourcen provisionieren. Das ermöglicht Flexibilität, aber bringt auch potenzielles Chaos mit sich. Genau hier setzt Governance an.

Wichtig ist die Unterscheidung zwischen:

• Governance: Festlegung und Durchsetzung von Richtlinien, Standards und Strukturen (Was darf wie, wo und von wem?)
• Management: Operative Verwaltung und Überwachung bestehender Ressourcen (Wie werden Ressourcen betrieben und überwacht?)
• Compliance: Sicherstellung regulatorischer und gesetzlicher Anforderungen (Sind wir auditierbar, regelkonform und dokumentiert?)

Governance ist somit die strategische Klammer, die sowohl Management als auch Compliance strukturiert.

Reale Probleme aus der Praxis ohne Governance

Viele Unternehmen, die ohne ein Governance-Modell starten, stoßen innerhalb weniger Monate auf folgende Herausforderungen:

• Security Incidents durch öffentlich erreichbare Ressourcen wie Storage Accounts oder Key Vaults
• Kostenexplosionen durch fehlende Shutdown-Automatisierung, fehlende Reservations oder mangelnde Ressourcenkontrolle
• Regionale Fehlverteilungen von Daten bspw. die Speicherung personenbezogener Daten in Drittstaaten
• Fehlende Verantwortlichkeiten: Wer darf was löschen, wer ist für welche Kosten verantwortlich?
• Unklare Architektur: Netzwerke mit überlappenden IP-Ranges, fragmentierte Infrastruktur, manuelle Deployments

Cloud Adoption Framework (CAF): Der methodische Rahmen

Microsofts Cloud Adoption Framework (CAF) ist ein umfassender Leitfaden, der Organisationen dabei unterstützt, den Weg in die Cloud strukturiert, sicher und geschäftsorientiert zu gestalten. Es richtet sich an strategische Entscheider, Architekten und Plattformteams gleichermaßen und deckt alle Phasen der Cloud-Einführung ab. Von der ersten strategischen Planung bis zur kontinuierlichen Optimierung im Betrieb. Governance ist dabei kein isolierter Bestandteil, sondern umfasst jede Phase als Querschnittsthema.

Strategy (Strategie-Phase)

In dieser Phase wird der geschäftliche Nutzen der Cloud definiert. Es geht um die Identifikation von Business-Drivern (bspw. Innovationsdruck, Skalierung, Kostenoptimierung) und um die Priorisierung von Cloud-Initiativen. Stakeholder werden eingebunden, KPIs werden festgelegt und die strategische Zielsetzung der Cloud-Adoption dokumentiert. Ziel ist es, eine klare strategische Ausrichtung für die Cloudadoption zu schaffen und diese mit den übergeordneten Geschäftszielen in Einklang zu bringen.

Mission und Zieldefinition: Eine übergeordnete Cloud-Mission wird formuliert, die den langfristigen Nutzen und die Rolle der Cloud im Unternehmen beschreibt. Auf Basis dieser Mission werden messbare Ziele (KPIs) definiert, die als Orientierung für alle weiteren Schritte dienen. Diese Ziele unterstützen die Erfolgsmessung und schaffen Transparenz gegenüber Stakeholdern.

Business Case Entwicklung: Analyse der erwarteten wirtschaftlichen Vorteile der Cloud-Adoption auf Basis konkreter Use Cases. Hierbei werden Investitionskosten, laufende Betriebskosten sowie potenzielle Einsparungen und Innovationspotenziale gegenübergestellt. Der Business Case dient als Entscheidungsgrundlage auf Management-Ebene und hilft, den erwarteten Mehrwert der Cloud strategisch zu bewerten.

Risikobewertung: Identifikation technischer, rechtlicher und betrieblicher Risiken beim Wechsel in die Cloud. Dazu zählen unter anderem Datenresidenz, regulatorische Anforderungen, technische Schulden, Abhängigkeiten von Legacy-Systemen und Skill-Gaps im Team. Die Risiken werden kategorisiert, bewertet und mit geeigneten Gegenmaßnahmen versehen. Ziel ist es, Modernisierungsrisiken frühzeitig zu minimieren.

Zielarchitektur skizzieren: Erstellung eines ersten High-Level-Zielbilds für die künftige Cloud-Umgebung. Diese enthält die erwarteten Workload-Typen, Netzwerksegmentierung, Regionsstrategie, Identitätsmodell und Integrationspunkte mit On-Premises-Systemen. Der Fokus liegt nicht auf technischen Details, sondern auf einer strategischen Vision der Zielarchitektur.

Stakeholder Map erstellen: Systematische Erfassung und Analyse aller relevanten internen und externen Stakeholder. Dies umfasst Fachbereiche, IT-Teams, Sicherheitsbeauftragte, Finanzabteilungen, Compliance-Beauftragte, aber auch externe Partner und Regulatoren. Ziel ist es, Erwartungen, Einfluss und Verantwortlichkeiten klar zu erfassen und Kommunikationswege frühzeitig zu definieren, um funktionsübergreifende Zusammenarbeit zu fördern.

Strategieteam etablieren & Organisationsbereitschaft bewerten: Ein dediziertes, interdisziplinäres Strategieteam wird definiert, das die Cloudstrategie entwirft und die Umsetzung steuert. Parallel wird die organisatorische Bereitschaft zur Cloudadoption analysiert. Insbesondere das Engagement der Führungskräfte, die technologische Reife der bestehenden Systeme, Change-Fähigkeit der Organisation und die Bereitschaft bestehende Prozesse zu modernisieren, sind dabei zu bewerten.

Plan (Planungsphase)

In der Planungsphase des Azure Cloud Adoption Framework (CAF) werden die strategischen Entscheidungen aus der vorherigen Strategiephase konkretisiert und in einen umsetzbaren, technisch und organisatorisch belastbaren Plan überführt. Die bestehende IT-Landschaft wird im Detail analysiert, Zielarchitekturen werden verfeinert und das technische sowie organisatorische Fundament für die spätere Umsetzung wird gelegt.

Ziel dieser Phase ist es, eine belastbare Ausgangsbasis für die Bereitstellung von Azure-Workloads zu schaffen, die sowohl geschäftlichen als auch regulatorischen Anforderungen genügt.

Erfassen des Application Inventory: Alle bestehenden Workloads inklusive ihrer Abhängigkeiten zu Datenbanken, APIs, externen Systemen, Integrationen und Identitäten werden abgebildet. Tools wie Azure Migrate, Application Insights oder Drittanbieterlösungen helfen dabei, Datenflüsse und technische Schulden sichtbar zu machen. Diese Bestandsaufnahme ist Grundlage für Migrationsentscheidungen und Priorisierungen.

Prüfung der Cloud Readiness: Für jeden Workload wird bewertet, ob die aktuellen Hostingmethoden noch sinnvoll sind. Dabei fließen Kriterien wie Latenzanforderungen, Datenresidenz, Modernisierungsaufwand und Lizenzmodelle ein. Basierend darauf wird entschieden, ob ein Rehost-, Refactor-, Rearchitect- oder Rebuild-Ansatz angemessen ist und welche Service-Modelle (IaaS, PaaS, SaaS) zum Einsatz kommen.

Definition von Architekturprinzipien: Im Architektur-Leitfaden oder Cloud Strategy Paper werden übergeordnete Designprinzipien festgelegt bspw. für Sicherheit, Skalierbarkeit, Wiederverwendbarkeit, Automatisierung und Integration. Diese Prinzipien bilden die Grundlage für die detaillierte Architekturplanung in der Ready-Phase.

Erstellung der Cloud-Roadmap: Basierend auf dem Application Inventory wird eine zeitlich und technisch abgestimmte Roadmap für Migration und Neuentwicklung erstellt. Dabei werden Migrationswellen (Waves), technische Abhängigkeiten, Geschäftsprioritäten, Budgetzyklen, Schulungskapazitäten und externe Abhängigkeiten. Sie dient als Koordinationsgrundlage für alle beteiligten Teams.

Budget- und Lizenzplanung: Kalkulation der erwarteten Kosten für Migration, Lizenzen, sowie des laufenden Betriebs. Empfehlungen zu Reservations, Savings Plans und Azure Hybrid Benefit werden berücksichtigt, um Kosteneffizienz zu gewährleisten.

Design der Management Group Struktur: Die Root-Struktur der Management Groups wird so gestaltet, dass sie die organisatorische Realität abbildet. Typischerweise werden Geschäftsbereiche, Regionen und Umgebungen (bspw. Produktion, Test, Entwicklung) als Grundlage verwendet. Subscriptions werden klar diesen Management Groups zugeordnet und mit definierten Verantwortlichkeiten versehen. Bereits in dieser Phase kommen erste Azure Policy-Initiativen zum Einsatz, die grundlegende Standards technisch absichern wie etwa die Einschränkung erlaubten Azure-Regionen, Namenskonventionen für Ressourcen und verpflichtende Tags zur Kostenzuordnung oder Automatisierung.

Dokumentation der Subscription-Strategie: Jede Subscription erhält ein klares Rollen- und Nutzungskonzept. Aspekte wie RBAC, Budgetgrenzen, Ressourcengrenzen und Naming Conventions werden dokumentiert und mit zentralen Richtlinien abgestimmt.

Festlegung des Cloudbetriebsmodells: Es wird definiert, ob ein zentrales, gemeinsam verwaltetes oder dezentrales Betriebsmodell verwendet wird. Dabei wird berücksichtigt, wie Governance, Sicherheit und Betrieb zwischen Plattform- und Workload-Teams aufgeteilt werden. Für viele Unternehmen empfiehlt sich ein hybrides Modell, das unterschiedliche Reifegrade und Anforderungen berücksichtigt.

Aufbau des Governance-Teams: Ein dediziertes Cloud Governance Team wird etabliert, das Richtlinien definiert, Risiken bewertet und deren Umsetzung technisch absichert. Das Team steuert Themen wie Identity & Access Management, Compliance, Policy-Design und Ressourcen-Kontrolle.

Sicherheitsplanung (Security by Design): Sicherheit wird frühzeitig in alle Architekturentscheidungen eingebettet. Dazu gehören Zero-Trust-Ansätze, IAM (mit Entra ID), Netzwerksicherheit, Schutz sensibler Daten, Monitoring und Bedrohungserkennung. Die Zusammenarbeit mit Security- und Compliance-Stakeholdern ist dabei zwingend erforderlich.

Tooling-Entscheidungen: Festlegung der zentralen Tools für Deployment, Infrastrukturautomatisierung und Monitoring. Beispiele sind hierfür Azure DevOps, GitHub Actions für CI/CD, GitLab, Bicep oder Terraform für Infrastructure-as-Code, sowie Grafana, KQL Workbooks und Azure Monitor für Observability.

Organisatorische Rollenklärung: Für die Umsetzung der Governance-Strategie müssen zentrale Verantwortlichkeiten klar zugewiesen werden. Zuständigkeitsbereiche wie Cloud Architektur und Governance, Sicherheit und Compliance, Kostenmanagement (FinOps) sowie Deployment und Automatisierung sollten jeweils durch dedizierte Rollen abgedeckt werden. Nur so lassen sich technische Standards, Budgetvorgaben und Sicherheitsmaßnahmen nachhaltig in der Organisation verankern.

Diese Phase endet idealerweise mit einem vollständigen Planungsdokument, das alle oben genannten Punkte adressiert und durch ein Entscheidungsgremium validiert wurde (bspw. durch ein Cloud Governance Board) und als Referenz für die nachfolgende Ready-Phase dient.

Ready (Vorbereitungsphase)

In der Ready-Phase wird die Cloud-Plattform so vorbereitet, dass sie produktionsreif, sicher und skalierbar betrieben werden kann. Ziel ist es, eine robuste, wartbare und compliant-konforme Basisinfrastruktur aufzubauen, die als technische Grundlage für alle nachfolgenden Workloads dient. Diese Phase ist entscheidend, da hier Governance, Sicherheit und Automatisierung erstmals konkret und wirksam umgesetzt werden.

Ein zentrales Konzept ist der Aufbau sogenannter Azure Landing Zones. Diese beinhalten wiederverwendbare und standardisierte Infrastrukturbestandteile wie Netzwerke, Identitäten, Richtlinien und Überwachungstools. Dabei kommen sowohl Microsoft-eigene Landing Zone Accelerators als auch individuell erstellte IaC-Vorlagen zum Einsatz.

Das zentrale Element ist demnach die standardisierte und wiederverwendbare Implementierung von Azure Landing Zones. Eine einzelne Landing Zone kann sich dabei auf eine bestimmte Abteilung, ein spezifisches Projekt oder eine anderweitige logische Trennung konzentrieren. Eine Landing Zone sollte dabei die CAF-Designbereiche wie Identity & Access Management, Netzwerkdesign & Konnektivität, Ressourcenorganisation & Management Groups, Governance & Richtlinien, Sicherheit & Schutzmechanismen, Monitoring & Management, Plattformautomatisierung (IaC) und Hybrid Connectivity & Integration beinhalten. Zur Implementierung einer Landing Zone existieren bereits eine Vielzahl an Accelerator Modulen von Microsoft, jedoch erlebe ich oft, dass nur eigene Infrastructure-as-Code Vorlagen die unternehmensspezifischen Anforderungen abbilden können.

Management Groups & Policies: Die zuvor entworfene Management Group Struktur wird nun in Azure implementiert. Zugehörige Azure Policy-Initiativen wie Allowed Locations, Tag Enforcement und Blueprint Assignment werden technisch ausgerollt. Ideallerweise zunächst im Audit-Modus, dann mit Deny- oder Modify-Effekt.

Identity & Access: Entra ID dient als zentrale Identitätsplattform. RBAC wird gemäß dem CAF RACI-Modell zugewiesen. Privileged Identity Management (PIM), Conditional Access und Multi-Faktor-Authentifizierung (MFA) werden für privilegierte Konten aktiviert. Standardrollen und Berechtigungsgruppen werden über automatisierte Deployments eingeführt.

Tagging-Standard & Naming-Conventions: Ein konsistentes Tagging- und Namensschema wird über Policies, Deployment Scripts und Pipelines technisch durchgesetzt. Policy-Verletzungen lösen einen definierten Review- und Eskalationsprozess aus. Tags werden verpflichtend für Governance, Automatisierung und Kostenzuordnung verwendet.

Netzwerkdesign & Region Governance: Die gewählte Netzwerkarchitektur (bspw. Hub-Spoke, vWAN) wird technisch implementiert inklusive DNS, Private Endpoints, VPN Gateways oder ExpressRoute für Hybridverbindungen. Es wird sichergestellt, dass nur freigegebene Azure-Regionen für Workloads verwendet werden (Region Governance per Policy).

Sicherheitskonfiguration: Azure Defender wird über alle Subscriptions hinweg aktiviert, inklusive der Integration in Microsoft Sentinel oder zentrale SIEM-Systeme. Ideallerweise werden zudem Mechanismen zur automatisierten Schwachstellenanalyse implementiert und ein dazugehöriges Alerting etabliert.

Zentrales Monitoring: Azure Monitor, Log Analytics und Application Insights werden mandantenweit über eine zentrale Plattform verbunden. Diagnostic Settings werden per Policy auf allen Ressourcen automatisiert aktiviert.

Cloud Center of Excellence (CCoE): Das CCoE wird als Governance- und Enablement-Team etabliert. Es übernimmt die Steuerung der technischen Standards, veröffentlicht Referenzarchitekturen, verwaltet Policies, schult Stakeholder und moderiert den Governance-Prozess über Gremienarbeit (Cloud Governance Board).

Onboarding-Prozesse: Neue Projekte und Teams werden über ein strukturiertes Onboarding-Verfahren an Azure herangeführt inklusive Template-Auswahl, Berechtigungsvergabe, Budgetzuweisung und Policy-Verpflichtung. Ziel ist es, Shadow-IT zu vermeiden und Dev-Teams zur aktiven Governance-Compliance zu befähigen.

Backup und Disaster Recovery: Strategien für Business Continuity und Desaster Recovery werden in die Plattform integriert. Dies umfasst Geo-Replikation, automatische Backups, Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO).

Die Phase endet mit der Readiness-Validierung durch das Cloud Governance Board. Eine vollständige CAF Ready-Checkliste wird zur Absicherung genutzt, um sicherzustellen, dass alle Voraussetzungen für die nächste Phase Adopt erfüllt sind.

Adopt (Migrations- und Innovationsphase)

In der Adopt-Phase des Azure Cloud Adoption Framework beginnt die operative Umsetzung der Cloudstrategie. Ziel ist die Migration bestehender Workloads und die Entwicklung cloudnativer Anwendungen unter Nutzung der zuvor etablierten Governance- und Plattformstandards. Die Phase markiert den Übergang vom Aufbau zur produktiven Nutzung von Azure.

Zentrale Grundlage ist der Cloud Adoption Plan, der alle Migrationsziele, Abhängigkeiten, Strategien, Workload-Priorisierungen, Zeitfenster und Erfolgskriterien dokumentiert.

Die zwei Hauptszenarien in dieser Phase sind:

• Migration bestehender Workloads: Auswahl einer geeigneten Migrationsstrategie pro Anwendung (Rehost, Refactor, Rearchitect, Rebuild, Replace oder Retain) basierend auf technischer Eignung, Kritikalität und Geschäftsanforderungen.
• Neuentwicklung cloudnativer Lösungen: Aufbau neuer Anwendungen mit Azure-eigenen Diensten wie Functions, App Services, Logic Apps, Event Grid, Cosmos DB oder AKS, oft unter Einsatz moderner Architekturmuster wie Microservices und Event-driven Design.

Planung und Durchführung deines Migrationsvorhabens

Vor der Migration werden technische und geschäftliche Abhängigkeiten zwischen Workloads identifiziert. Diese fließen in die Bildung von Migrationswellen („Waves“) ein, um Engpässe und Ausfallzeiten zu vermeiden. Jede Welle enthält logisch gruppierte Workloads auf Basis gemeinsamer Datenbanken, APIs, Identitäten oder Netzwerkverbindungen.

Je nach SLA-Anforderungen und Kritikalität kommen verschiedene Methoden zum Einsatz. Für weniger kritische Systeme mit geplanten Wartungsfenster kann eine Downtime-Migration verwendet werden. Für hochverfügbare Workloads mit Replikationsmechanismen ist dagegen eine Near-Zero-Downtime-Migration in Frage kommen.

Cloudnative Entwicklung & CI/CD

Alle Infrastrukturkomponenten (bspw. Netzwerke, Identitäten, Policies) werden über IaC-Ansätze wie Bicep, Terraform oder ARM Templates bereitgestellt. Azure Policies und RBAC-Zuweisungen werden versioniert, getestet und über Pipelines ausgerollt (Policy as Code).

Anwendungsbereitstellungen erfolgen über automatisierte Pipelines in Azure DevOps, GitHub Actions oder GitLab. Sicherheitsprüfungen, Policy-Compliance-Checks und automatisierte Tests (bspw. mit KQL, SonarQube) sind Bestandteil jeder Pipeline.

Entwicklungsteams werden in DevSecOps-Prinzipien geschult (bspw. Secrets Management mit Key Vault, Managed Identities, Least Privilege). Technische Leitplanken wie Policy-gestützte Einschränkungen (bspw. keine öffentlichen IPs, verschlüsselte Daten) sichern die Einhaltung zentraler Sicherheitsstandards.

Rollback-Strategie

Für jeden einzelnen Workload und Migrationsaufwand existiert ein Rollback-Plan inkl. der Definition der Auslösebedingungen wie Performance-Einbrüche oder Fehlerraten. Zusätzlich bestehen automatisierte Wiederherstellungsmaßnahmen in CI/CD-Pipelines. Dazu werden Snapshots, IaC-Backups und Image-Rollbacks gespeichert und regelmäßig getestet, um im Katastrophenfall eine funktionierende Infrastruktur und Anwendungslandschaft garantieren zu können.

Betriebsübergabe & Erfolgsmessung

Nach der Migration von Workloads ist die Zuweisung klarer Verantwortlichkeiten notwendig. Ergänzend wird die Verfügbarkeit, Performance und das Feedback der Anwender gemessen, um Missstände nach der Migration aufzudecken. Als Grundlage hierfür sind die bereits geschaffenen Observability- und Monitoring-Maßnahmen zu nutzen.

In dieser Phase zeigt sich, ob Governance im Alltag funktioniert, nicht als Hindernis, sondern als integrierter Bestandteil des Entwicklungs- und Betriebsprozesses. Nur wenn Teams durch Self-Service und Automation befähigt werden, gleichzeitig aber im Rahmen der Governance handeln, entsteht ein produktives und sicheres Cloud Operating Model.

Govern (Governance-Phase)

In der Govern-Phase wird sichergestellt, dass alle Aktivitäten in Azure kontrolliert, nachvollziehbar und regelkonform ablaufen. Es geht nicht nur um technische Steuerung, sondern auch um organisatorische Verankerung. Im Fokus steht dabei die automatisierte Durchsetzung und kontinuierliche Monitoring von Governance Strukturen.

Die CAF-Governance-Strategie basiert auf einem fünfstufigen Zyklus, der iterativ durchlaufen wird:

1. Aufstellen eines Governance-Teams
2. Bewerten von Cloud-Risiken
3. Dokumentieren von Governance-Richtlinien
4. Durchsetzen der Richtlinien mittels Automatisierung
5. Kontinuierliches Monitoring und Optimierung

Weiterhin werden Governance-Tätigkeiten in die folgenden sieben Kernbereiche unterteilt:

1. Sicherheit (Zugriff, Identity Protection)
2. Compliance (DSGVO, ISO 27001)
3. Kostenmanagement (Budgetierung, Reservations)
4. Betrieb (Change- und Incident-Management)
5. Ressourcenmanagement (Naming, Tagging, Lokationen)
6. Datenkontrolle (Data Residency, Klassifizierung)
7. KI-Governance (ethische KI-Nutzung, Datenquellenkontrolle)

In der Govern-Phase werden technische Kontrollmechanismen eingesetzt, um Richtlinien automatisiert durchzusetzen, Risiken zu überwachen und Compliance sicherzustellen. Die folgenden Bausteine sind dabei zentral.

Azure Policy & Initiative Definitions: Mittels Azure Policy werden Regeln für Naming, Tagging, Regionen, Ressourcentypen und Sicherheit durchgesetzt. Initiative Definitions (Policy Sets) bündeln diese in thematische Gruppen (bspw. Security Baseline, Cost Control) und ermöglichen konsistente Anwendung über Management Groups hinweg. Policies mit Deny verhindern direkte Regelverstöße, während Audit und DeployIfNotExists Korrekturmechanismen automatisieren.

Budgetierung & Reservations: Azure Budgets ermöglichen das Festlegen von Schwellenwerten für Subscriptions oder Ressourcengruppen. Bei Überschreitung werden automatisierte Alerts oder automatisierte Maßnahmen ausgelöst. Reservations und Savings Plans sorgen zusätzlich für langfristige Kosteneinsparungen.

Access Reviews & Privileged Identity Management (PIM): Über Azure AD Access Reviews werden periodisch alle Zugriffsrechte auf kritische Ressourcen überprüft. PIM sorgt für temporäre Rollenzuweisungen mit Genehmigungsworkflows und Logging. So wird übermäßige Berechtigung und Rollen-Drift verhindert.

Compliance-Integration & ITSM-Anbindung: Alle Policy-Verstöße, Ressourcenzustände und Konfigurationsabweichungen werden über Azure Monitor, Log Analytics und Resource Graph ausgewertet. Die Integration in bestehende ITSM-Systeme (bspw. ServiceNow, Jira, BMC) ermöglicht ein zentrales Ticketing und Eskalationsmanagement. Zusätzlich werden Compliance-Reports (bspw. für DSGVO, ISO 27001) über Azure Blueprints oder Microsoft Defender for Cloud bereitgestellt.

Rollenmodelle & Eskalationspfade: Governance definiert klare Zuständigkeiten für Richtlinienfreigaben, Kostenverantwortung, Sicherheitsbewertungen und Betriebsprozesse. Ein Governance Board bewertet Eskalationen bei Policy-Konflikten, neuen Anforderungen oder Rollout-Entscheidungen.

Reporting & Dashboards: Über Azure Workbooks, Kusto-basierte Abfragen und Power BI werden Dashboards für Management, Security und FinOps bereitgestellt. Sie visualisieren Policy-Compliance, Kostenentwicklung, Sicherheitszustände und Deployment-Muster.

Governance ist in dieser Phase kein starres Regelwerk, sondern ein dynamisches Kontrollsystem, das kontinuierlich angepasst und technisch skaliert wird und das immer im Einklang mit Sicherheitsanforderungen, Unternehmensstrategie und regulatorischem Umfeld.

Secure (Absicherungsphase)

Die Secure-Phase stellt sicher, dass Sicherheit nicht als einmalige Maßnahme, sondern als fortlaufender, ganzheitlicher Prozess verstanden und in alle Phasen der Cloud-Einführung eingebettet wird. Basierend auf dem Zero Trust-Modell verfolgt sie die Prinzipien Assume Breach, Least Privilege und Explicit Verification.

Ziel ist es, Risiken proaktiv zu adressieren und Organisationen resilient gegen Angriffe, Fehlkonfigurationen und Datenverlust aufzustellen.

Ganzheitlicher Sicherheitsansatz:

Die Secure-Phase adressiert die Sicherheit aus technischer, prozessualer und organisatorischer Perspektive. Technische Sicherheit umfasst Aspekte wie Identitäts- und Zugriffsverwaltung (IAM), Netzwerkschutz, den Schutz einzelner Workloads sowie eine durchgängige Verschlüsselung sensibler Daten.

Auf Prozessebene stehen vor allem die effektive Incident-Reaktion und ein umfassendes Schwachstellenmanagement im Vordergrund. Ergänzt wird dies durch organisatorische Maßnahmen wie die Definition klarer Rollen, eine durchgängige Security Governance sowie kontinuierliche Awareness- und Schulungsprogramme. Das Cloud Adoption Framework empfiehlt, Sicherheit als eine gemeinsame Verantwortung über alle Teams, Plattformen und Phasen des Cloud-Lebenszyklus hinweg zu leben.

Modernisierung des Sicherheitsstatus:

CAF Secure richtet sich nach dem Microsoft Zero Trust Adoption Framework und empfiehlt, die Sicherheit im Projekt iterativ zu verstärken. Dies umfasst die Einführung von Multi-Faktor-Authentifizierung (MFA) und bedingtem Zugriff zur Sicherstellung identitätsbasierter Zugriffskontrolle. Ergänzend dazu erfolgt die Integration zentraler Sicherheitslösungen wie Microsoft Defender for Cloud, Entra ID und Microsoft Sentinel, die ein umfassendes Monitoring sowie Schutzfunktionen auf verschiedenen Ebenen bieten. Die Implementierung von Security Baselines sowie eine automatisierte Compliance-Überwachung mittels Azure Policy helfen dabei, Sicherheitsstandards konsequent umzusetzen. Schließlich wird der Einsatz von Infrastructure as Code (IaC) zur Abbildung sicherheitsrelevanter Konfigurationen empfohlen, um Wiederholbarkeit, Transparenz und Automatisierung in der Sicherheitsarchitektur zu gewährleisten.

Vorbereitung und Reaktion auf Sicherheitsvorfälle:

Es ist zudem erforderlich, dass belastbare Prozesse zur Erkennung, Bewertung und Behebung von Sicherheitsvorfällen existieren. Dazu gehört ein automatisiertes SIEM-Monitoring, etwa durch Microsoft Sentinel, um sicherheitsrelevante Ereignisse schnell zu identifizieren und zu analysieren. Ergänzt wird dies durch den Einsatz von SOAR-Playbooks (Security Orchestration, Automation and Response), die automatisierte Reaktionen auf Vorfälle ermöglichen.

Ebenso wichtig sind klar definierte Eskalationspfade und Incident Runbooks, die auch Kommunikationsrichtlinien beinhalten, um im Ernstfall zielgerichtet reagieren zu können. Testszenarien und Simulationen, beispielsweise in Form von Red Team/Blue Team-Übungen, helfen, die Wirksamkeit der Prozesse regelmäßig zu überprüfen und zu verbessern.

Vertraulichkeit, Integrität und Verfügbarkeit:

Die Vertraulichkeit kann durch Maßnahmen wie Verschlüsselung, Zugriffskontrollen und Data Loss Prevention (DLP) gewährleistet werden, sodass nur autorisierte Personen auf sensible Informationen zugreifen können.

Die Integrität wird durch Versionskontrolle, Code Signing und den Schutz vor Manipulation sichergestellt, um die Genauigkeit und Unverfälschtheit der Daten zu wahren.

Die Verfügbarkeit dagegen wird durch den Einsatz skalierbarer Architekturen, regelmäßiger Backups, Redundanzen sowie DDoS-Schutzmaßnahmen gewährleistet, damit Dienste auch bei Störungen zugänglich bleiben.

Diese drei Prinzipien sind übergreifend im gesamten CAF zu berücksichtigen und müssen sowohl in technischen als auch in prozessualen Mechanismen verankert werden.

Aufrechterhaltung der Sicherheitsmaßnahmen: Das CAF empfiehlt eine kontinuierliche Bewertung und Verbesserung des Sicherheitsniveaus, um den Sicherheitsstatus der Cloud-Umgebung langfristig zu stärken. Dazu gehört der Einsatz moderner Werkzeuge wie Defender CSPM, Microsoft Entra Permissions Management und Secure Score, die eine zentrale Transparenz über Risiken und Verbesserungspotenziale bieten.

Ergänzt wird dies durch regelmäßige Security Reviews und Benchmark-Vergleiche, die es ermöglichen, Fortschritte objektiv zu messen und mit branchenspezifischen Standards abzugleichen. Die Überwachung des Sicherheitsniveaus wird durch Security Governance Teams übernommen, die unter anderem mithilfe von Key Performance Indicators (KPIs), wie etwa Time-to-Detect oder dem prozentualen Grad der Policy-Compliance, fundierte Einblicke gewinnen.

Schulungsmaßnahmen und sogenannte Security Champions in den Workload-Teams sorgen zusätzlich dafür, dass Sicherheitsbewusstsein und Best Practices in den Entwicklungsalltag integriert werden.

Manage (Betriebsphase)

Die Phase Manage im Azure Cloud Adoption Framework (CAF) bildet den operativen Regelkreis der Cloud-Governance und -Betriebsführung. Sie stellt sicher, dass Azure-Umgebungen dauerhaft sicher, effizient und konform betrieben werden und im Einklang mit den Geschäftszielen sind.

Die Grundlage bildet dabei der sogenannte RAMP-Prozess:

• Ready: Einrichtung des Betriebsmodells und der zentralen Plattformverantwortlichkeiten
• Administer: Ausführen von Betriebsaufgaben wie Deployment, Incident-, Change- und Access Management
• Monitor: Überwachen von Gesundheit, Leistung, Sicherheit und Compliance
• Protect: Schutz vor Bedrohungen, Fehlkonfigurationen und Datenverlust

Ein zentrales Element dieser Phase ist die Wahl und Etablierung eines geeigneten Betriebsmodells. Je nach Reifegrad und Organisationsstruktur kann dies zentralisiert, dezentral oder in Form eines geteilten Betriebsansatzes (Shared Operations Model) erfolgen. In Enterprise-Umgebungen bewährt sich insbesondere das geteilte Modell. Ein zentrales Plattformteam betreibt dabei die Infrastruktur und stellt Betriebsstandards bereit, während die Workload-Teams für den Betrieb ihrer Anwendungen innerhalb definierter Leitplanken verantwortlich sind. Dies ermöglicht sowohl Governance-konformes Arbeiten als auch flexible Weiterentwicklung durch die Fachbereiche.

Überwachung und Betriebsdaten: Azure Monitor, Log Analytics, Application Insights und Diagnostic Settings sind das Rückgrat der technischen Überwachung und liefern Metriken, Logs und Traces aus zentralen und workloadspezifischen Quellen. Alle Datenflüsse sind über Azure Policies standardisiert, gesammelt über Data Collection Rules und gespeichert in einem zentralisierten Log Analytics Workspace. Alerts (metrisch, log-basiert, dynamisch) sind beispielsweise mit ITSM-Systemen oder SIEM-Lösungen wie Microsoft Sentinel gekoppelt. Ergänzt wird dies durch Change Tracking, Agent Health Monitoring und Update Management.

FinOps & Kostenoptimierung: Die laufende Bewertung von Azure Cost Management, Budgets, Reservations, Savings Plans und Azure Hybrid Benefit ist integraler Bestandteil dieser Phase. Über Custom Dashboards werden Kosten aufgeschlüsselt nach Tags, Subscriptions, Applikationen und Umgebungen dargestellt. Azure Advisor und Microsoft Cost Management Recommendations liefern zusätzlich konkrete Optimierungsvorschläge, etwa zur Abschaltung unterausgelasteter VMs, Skalierung von App Services oder Nutzung günstigerer SKUs.

Change & Incident Management: Alle Änderungen an Infrastrukturkomponenten und Policies erfolgen über ein Change Advisory Board (CAB), integriert in ein zentrales ITSM-System. Durchgängige Change-Nachvollziehbarkeit ist durch Infrastructure-as-Code und GitOps sichergestellt. Incident-Workflows sind über Azure Alerts und Webhooks an ITSM- oder SIEM-Systeme gekoppelt. Eskalationspfade für kritische Ressourcen können dabei über definierte Runbooks oder Automatisierungen umgesetzt werden.

Security Monitoring & Compliance Tracking: Microsoft Defender for Cloud erkennt Bedrohungen und Fehlkonfigurationen in Echtzeit. Sicherheitsbewertungen werden als Secure Score pro Subscription oder Management Group ausgewiesen und monatlich durch das CCoE überprüft. Über Regulatory Compliance Dashboards (ISO 27001, NIST, CIS, DSGVO) wird der Konformitätsstatus überwacht. Verstöße gegen Policies oder Kontrollziele lösen automatisierte Tasks aus bspw. die Erstellung eines Tickets, Initiierung eines Access Reviews oder Eskalation ans Governance Board.

Governance-Iteration & Benchmarking: Über das CAF Governance Benchmark Tool lässt sich der Governance-Reifegrad regelmäßig evaluieren. Basierend auf KPIs wie Policy-Abdeckung, Access Review-Quote, FinOps-Compliance und Incident-Recovery-Zeit werden gezielte Maßnahmen für die Weiterentwicklung der Governance abgeleitet. Diese Benchmarks können bspw. in eine halbjährliche Governance-Roadmap eiunfließen, koordiniert vom Cloud Center of Excellence.

Ein ausgereiftes Cloud Management Setup ist eng an das Well-Architected Framework angebunden. Es unterstützt nicht nur Security und Compliance, sondern fördert gezielt die Säulen operative Exzellenz, Kostenoptimierung und Zuverlässigkeit. Die technische Plattform wird damit zu einem lernenden System, das sich proaktiv an neue Anforderungen und Risiken anpasst.

In dieser Phase zeigt sich, ob Governance nicht nur eingeführt, sondern auch nachhaltig verankert wurde – technisch automatisiert, organisatorisch verankert und kontinuierlich verbessert.

Azure Governance Building Blocks laut CAF

Das Microsoft Cloud Adoption Framework empfiehlt den Aufbau einer skalierbaren Governance-Architektur entlang dieser vier Pfeiler:

• Richtlinien und Compliance (Azure Policy, Regulatory Blueprints)
• Sicherheitsbaseline (Defender for Cloud, IAM, Conditional Access)
• Kostenkontrolle (Azure Cost Management, Budgets, Reservations)
• Rollen, Verantwortlichkeiten, Prozesse (Cloud Owner, CoE, Change Management)

Verbindung zum Well-Architected Framework

Die zuvor beschriebenen CAF-Governance-Bausteine lassen sich nahtlos auf das Microsoft Well-Architected Framework (WAF) übertragen. Dieses unterteilt eine robuste Cloud-Architektur in fünf Säulen: Kostenoptimierung, Zuverlässigkeit, Sicherheit, Leistungseffizienz und betriebliche Exzellenz. Governance wirkt in jeder dieser Säulen als verbindendes Element.

Kostenoptimierung: Durch konsistente Tagging-Strategien, Azure Budgets, Reservations und FinOps-Rollen wird die Cloud-Nutzung nachvollziehbar und wirtschaftlich steuerbar. Governance schafft hier die Grundlage für Kostenkontrolle und -transparenz.

Sicherheit: Die Kombination aus Role Based Access Control, PIM, Conditional Access und Policy-gesteuerten Richtlinien sorgt dafür, dass Sicherheitsstandards nicht nur definiert, sondern auch technisch durchgesetzt werden.

Zuverlässigkeit: Azure Policies, Deployment Pipelines und zentrale Logging-/Monitoring-Standards sorgen dafür, dass Infrastruktur konsistent, reproduzierbar und resilient betrieben werden kann. Unbeabsichtigte Abweichungen werden erkannt und korrigiert, bevor sie zum Ausfall führen.

Operative Exzellenz: Governance verankert Verantwortlichkeiten, Change-Prozesse und Automatisierung in der Organisation. So werden Änderungen nachvollziehbar, Betriebsfehler reduziert und die Wartbarkeit erhöht.

Leistungseffizienz: Über Governance lässt sich auch sicherstellen, dass nur zugelassene Services und Größenklassen verwendet werden. Beispielsweise können VM-SKUs mit schlechterem Preis-/Leistungsverhältnis durch Policies blockiert werden.

Governance ist damit nicht nur ein Compliance-Werkzeug, sondern ein strukturgebendes Prinzip für jede einzelne Säule im WAF. Der entscheidende Mehrwert entsteht dann, wenn CAF und WAF kombiniert eingesetzt werden. Das Microsoft Cloud Adoption Framework als methodischer Rahmen, Well-Architected Framework als technischer Referenzpunkt. Genau diese Verbindung bildet den Ausgangspunkt für das operative Design in Azure.

Fazit

Mit der Verbindung zwischen Cloud Adoption Framework und Well-Architected Framework hast du nun eine belastbare Grundlage für den Aufbau einer regelkonformen, sicheren und skalierbaren Azure-Umgebung erhalten. Doch wie übersetzt man diese Prinzipien konkret in Zielarchitekturen, Toolchains und technische Entscheidungsprozesse?

Genau hier setzt Teil 2 dieser Blog-Reihe an. Dieser Teil liefert dir das methodische Wissen, um die Weichen für eine zukunftsfähige Azure-Plattform richtig zu stellen. In den nächsten Beiträgen dieser Reihe werden wir uns konkrete Umsetzungsvorschläge und weitere relevante Inhalte im Kontext der Cloud Governance anschauen.

Weiterführende Ressourcen

• Microsoft Cloud Adoption Framework
• Well-Architected Framework
• Enterprise-scale Landing Zone
• Azure Cloud Adoption Unterstützung