Governance-Assessment¶

Wie das Plattform-Team herausfindet, welche Governance eine Organisation braucht, sie in eine durchgesetzte Baseline überführt und jeden Monat prüft, ob die Baseline hält, einschließlich der finanziellen Risiken der Cloud-Nutzung. Die Seite beschreibt zwei Dinge:

das Assessment: eine wiederholbare Methode, um den aktuellen Governance-Zustand und den gewünschten Zielzustand zu ermitteln, einschließlich regulatorischer Anforderungen;
die Umsetzung: die Baseline, die die Plattform als Azure-Policy-Initiatives mitliefert, konfiguriert mit den Antworten des Assessments.

Wer was entscheidet, steht unter Governance und Entscheidungsfindung. Den Umgang mit Policies im Alltag beschreiben Policy-Zuweisungen und Policies und Ausnahmen.

Methode: der Governance-Zyklus des Cloud Adoption Framework¶

Die Methode folgt der Methodik Govern des Microsoft Cloud Adoption Framework. Governance ist ein kontinuierlicher Zyklus: Baue einmal ein Cloud-Governance-Team auf und wiederhole dann Bewerten, Dokumentieren, Durchsetzen und Überwachen, damit die Governance aktuell bleibt, wenn sich Risiken und Anforderungen ändern.

flowchart LR
    T["1. Governance team"] --> A["2. Assess risks<br/>(workshop)"]
    A --> D["3. Document policies<br/>(initiatives as code)"]
    D --> E["4. Enforce<br/>(deployed with the platform)"]
    E --> M["5. Monitor compliance and cost<br/>(monthly check)"]
    M --> A

Schritt	Aktivität auf der Plattform	Rhythmus
Ein Governance-Team aufbauen	Ein Team, das die Baseline verantwortet und mit der Organisation darüber spricht (siehe Rollen)	Kontinuierlich
Risiken bewerten	Ein Discovery- oder Design-Workshop während der Implementierung	Beim Onboarding und bei jeder Änderung der Anforderungen
Policies dokumentieren	Policy-Definitionen und Initiatives als Infrastructure as Code	Versioniert, pro Release
Policies durchsetzen	Initiatives, die vom Plattform-Deployment zugewiesen werden	Bei jedem Deployment
Compliance überwachen	Der monatliche Health Check und das Service Review	Monatlich
Kosten und finanzielle Risiken überwachen	Ein monatliches Kosten-Review	Monatlich

1. Das Governance-Team¶

Jemand muss die Baseline verantworten: die Policy-Definitionen, die Initiatives und die Standards, denen sie folgen. Im Managed- Modell ist das ein Team beim betreibenden Partner, das die Baseline für alle seine Kunden verantwortet, während die eigenen Security- und Architektur-Funktionen des Kunden die Entscheidungen verantworten (Betriebsmodelle). Im Eigenbetrieb ist es eine Rolle in deiner Organisation.

2. Die Anforderungen bewerten¶

Jede Implementierung beginnt mit einem strukturierten Workshop. Er ist bewusst für jede Organisation gleich:

ein Discovery-Workshop, wenn die Standardplattform unverändert übernommen wird;
ein Design-Workshop, wenn es individuelle Anforderungen gibt. Sein Ergebnis ist ein schriftliches High-Level Design.

Der Workshop hält den Ist-Zustand fest (bestehender Azure-Footprint, Billing-Setup, management groups, Konnektivität, Identität und jede Umgebung, die übernommen wird) und den Soll-Zustand über die Domänen, die die Plattform deployt: Identität, Netzwerk und Konnektivität, Security-Baseline, Datenschutz und Aufbewahrung, Ressourcenorganisation und Namensgebung, Monitoring und Kostenmanagement.

Halte die Antworten in einem strukturierten Fragebogen fest. Jede Antwort entspricht einer Plattform-Einstellung, zum Beispiel der Log-Aufbewahrung in Tagen, der Soft-Delete-Aufbewahrung des Key Vault, DDoS-Schutz, der firewall-SKU, der WAF-Policy, VPN- oder ExpressRoute- Konnektivität und Bastion. Das Assessment ist dann nachvollziehbar: Zu jeder deployten Governance-Einstellung kannst du auf die Frage und die Antwort verweisen, die sie erzeugt hat.

Regulatorische und Compliance-Anforderungen sind Teil des Assessments. Die Verpflichtungen der Organisation bestimmen, welche Standards du zuweist und über die du berichtest. Die Plattform weist standardmäßig den CIS Microsoft Azure Foundations Benchmark, den Microsoft cloud security benchmark und ISO 27001 zu, und du kannst die Auswahl erweitern (Plattformübersicht). Behandle die Risiken, die du findest, wie jedes andere Risiko: Trage sie in eine Risikoliste ein und gib jedem einen Owner.

Wiederhole das Assessment, wenn sich die Anforderungen ändern, und liefere das Ergebnis als Änderung der Plattform-Konfiguration (Änderungs-Workflow).

3. Die Policies dokumentieren: Die Baseline wird mit der Plattform geliefert¶

Die Governance-Baseline ist Teil der Plattform. Sie ist kein Dokument, das jede Organisation selbst umsetzen muss, und sie wird nicht pro Kunde von Hand konfiguriert.

Policy-Definitionen und Initiatives gehören zum layer foundation. Policy-Zuweisungen gehören zum layer postdeployment (Deployment-Layer).
Alles ist Infrastructure as Code und wird von pipelines deployt. Die Baseline ist versioniert, wird von einer zweiten Person geprüft und ist wiederholbar. Verbesserst du sie einmal, verbessert das jede Plattform auf dem Code.
Die Initiatives basieren auf anerkannten Standards, nicht auf selbst erfundenen Regeln.
Wo du Templates anbietest, validiere sie gegen dieselben Standards, indem du das Template deployst und Azure Policy auswertest. Fixiere Werte, die Policies prüfen, möglichst im Modul auf konforme Werte.

Weil die Baseline Teil des Produkts ist, hat eine neue Plattform ab Tag eins ein Governance-Minimum. Die Antworten des Assessments werden als Konfiguration darauf angewendet.

4. Die Policies durchsetzen¶

Policies werden durchgesetzt, sie sind nicht nur Empfehlungen. Initiatives nutzen, wo es passt, die Effekte Deny und DeployIfNotExists, sodass eine nicht konforme Ressource beim Deployment blockiert oder automatisch korrigiert wird, statt nur nachträglich markiert zu werden. Ausnahmen sind explizite Azure-Policy-Exemptions in der deployten Konfiguration, sodass eine Ausnahme eine sichtbare, geprüfte Entscheidung ist und keine stille Lücke (Ausnahmen).

Die Zuweisungen und ihre Wirkung sind im Azure-Portal sichtbar, unter Azure Policy und in der Ansicht für regulatorische Compliance von Microsoft Defender for Cloud.

5. Compliance überwachen und darauf reagieren¶

Die Compliance wird jeden Monat im monatlichen Health Check bewertet und an den Kunden oder die Stakeholder berichtet. Ein geplanter Lauf in den ersten Tagen des Monats kann die Daten sammeln. Die Daten stammen aus den Azure-Resource- Graph-Policy-States: pro Subscription, wie viele Controls jedes zugewiesenen Benchmarks konform und nicht konform sind, mit den Namen der nicht konformen Controls. Der Bericht enthält außerdem den Secure Score und die Security-Empfehlungen.

Weil der Bericht jeden Monat dasselbe Format hat, sieht der Leser den Trend und kann prüfen, ob sich die Lage verbessert.

5b. Kosten und finanzielle Risiken überwachen¶

Kosten sind eine Governance-Disziplin, nicht nur ein kaufmännisches Thema. Unkontrollierte Ausgaben, ungenutzte oder überdimensionierte Ressourcen und unerwarteter Verbrauch sind Risiken, die du wie jedes andere Risiko identifizierst und behandelst. Wo das Plattform-Team Zugriff auf die Verbrauchsdaten hat, führe neben dem Compliance-Check ein monatliches Kosten-Review durch:

analysiere den Verbrauch auf Anomalien und unerwartetes Wachstum, ungenutzte oder überdimensionierte Ressourcen und verpasste Möglichkeiten für Reservations oder Savings Plans;
validiere den erzeugten Bericht und bespreche die Ergebnisse, damit ein finanzielles Risiko wie ein Compliance-Finding zu einer Entscheidung führt;
entscheide, wann ein tieferes Kosten-Assessment angebracht ist.

Siehe Kosten und Reservations. Weil das Review jeden Monat auf denselben Daten läuft, zeigen sich Kostenbewegungen früh und nicht erst am Ende eines Vertragsjahres. Die hub-layers deployen keine Budgets (Betriebsverantwortlichkeiten).

Folgemaßnahmen¶

Der Bericht ist die Grundlage für eine Entscheidung, nicht das Ende des Prozesses. Besprich die Ergebnisse mit den Stakeholdern und vereinbare Folgemaßnahmen:

Finding	Behandelt als
Das Plattform-Team kann es beheben	Ein Work Item im Backlog, das in einem Sprint bearbeitet wird
Es braucht eine Entscheidung oder Maßnahme der Organisation	Besprochen im Service Review oder in der Steuerungsgruppe (Meetings)
Ein finanzielles Risiko	Dasselbe Review, mit einem Optimierungsvorschlag oder einem tieferen Kosten-Assessment
Ein strukturelles Finding	Eine Änderung der Baseline selbst, von der jede Plattform auf dem Code profitiert

Damit schließt sich der Zyklus: Das Monitoring speist das nächste Assessment.

Wie der Zyklus in der Praxis aussieht¶

Die Methode ist überall dieselbe. Das Gespräch unterscheidet sich:

Wo die Organisation ein eigenes Cloud-Team oder Cloud Center of Excellence hat, werden die Anforderungen mit diesem Team vereinbart und in den wiederkehrenden Service-Meetings geprüft. Die Baseline kann um Templates erweitert werden, die gegen dieselben Standards validiert werden.
Wo die Plattform zusammen mit einem internen Plattform-Team geliefert wird, werden die Anforderungen mit diesem Team festgelegt und neu betrachtet, wenn sich seine Plattform weiterentwickelt.

In beiden Fällen ist die Kette von Anfang bis Ende nachvollziehbar: das Workshop-Ergebnis, das die Konfiguration erzeugt hat, die deployten Policy- Zuweisungen im Portal und eine Reihe monatlicher Berichte mit dem Trend und den ergriffenen Folgemaßnahmen.

Rollen und Verantwortlichkeiten¶

Rolle	Verantwortung
Owner der Baseline (Solution Lead)	Die Policy-Definitionen, Initiatives und die Standards, denen sie folgen
Service Manager	Das Governance-Assessment und das monatliche Review mit der Organisation
Delivery- oder Kosten-Owner	Das monatliche Kosten-Review und das Berichten finanzieller Risiken
Technische Leitung (Architekt)	Die technische Richtung der Baseline
Plattform-Engineers	Führen die Folgemaßnahmen aus dem Monatsbericht aus

Kontrolle¶

Die Compliance gegenüber den zugewiesenen Initiatives wird monatlich verifiziert und dort festgehalten, wo die Stakeholder sie lesen können. Das finanzielle Risiko wird monatlich verifiziert, wo Verbrauchsdaten verfügbar sind. Die Baseline selbst wird geprüft, wenn sich die zugrunde liegenden Standards ändern und wenn ein Assessment eine neue Anforderung hervorbringt.