Cloud Usage Policy: 12 Governance-Domänen

Was eine Cloud Usage Policy leistet

Die Cloud Governance Policy definiert strategische Leitplanken und Grundsätze. Die Cloud Usage Policy übersetzt diese Richtlinien in verbindliche, operative Vorgaben — konkrete Regeln, die für jede Person und jedes Team gelten, die Cloud-Ressourcen bereitstellen, konfigurieren oder betreiben.

Eine Nutzungsrichtlinie ohne strukturierte Domänen ist schwer durchzusetzen: Sie wächst zu einem undurchsichtigen Regelwerk heran, das niemand vollständig kennt und das mit neuen Anforderungen uneinheitlich erweitert wird. Die Aufteilung in zwölf Domänen schafft Klarheit — jede Anforderung gehört zu einer klaren Domäne und Stakeholder wissen sofort, welche Domäne für ihr Thema zuständig ist.

Domäne 1: Asset Management (AST)

Das Asset Management ist die Grundlage aller anderen Governance-Domänen. Wer nicht weiß, welche Cloud-Ressourcen existieren, kann diese weder absichern noch kosteneffizient betreiben noch compliance-konform halten. Eine vollständige Inventur aller Cloud-Ressourcen ist daher keine optionale Maßnahme, sondern die Voraussetzung für eine funktionierende Governance.

Kernpflichten: Jede Ressource wird in einem zentralen Inventar erfasst und aktuell gehalten; jeder Ressource ist ein verantwortliches Team oder eine verantwortliche Person zugeordnet; alle Ressourcen folgen definierten Namenskonventionen; eine vollständige Kennzeichnung nach Standard ist verpflichtend. Ressourcen ohne definierten Eigentümer und ohne vollständige Tags sind per Definition nicht konform und müssen sofort behoben oder entfernt werden.

Domäne 2: Cloud Cost Management (FIN)

Unkontrollierter Cloud-Konsum führt zu erheblichen und unerwarteten Kosten. Eine transparente Kostenzuordnung und aktives Management sind daher zwingende Anforderungen an alle Cloud-Nutzenden — nicht nur an das FinOps-Team.

Jede Ressource muss mit obligatorischen Kostenzuordnungs-Tags gekennzeichnet sein, Budgetalarme müssen konfiguriert werden, maximale Ausgabengrenzen werden technisch durchgesetzt und ungenutzte oder verwaiste Ressourcen müssen regelmäßig identifiziert und entfernt werden. Ressourcen mit erheblichen Kostenauswirkungen — GPU-Instanzen, große Datenbankcluster — müssen vor der Bereitstellung explizit genehmigt werden.

Das Chargeback- und Showback-Prinzip stellt sicher, dass Cloud-Kosten transparent auf die verursachenden Teams verteilt werden. Kostenverantwortung ohne Kostentransparenz ist ineffektiv.

Domäne 3: Identity & Access Management (IAM)

Identitäten und Zugriffsberechtigungen sind der primäre Angriffsvektor in Cloud-Umgebungen. Die IAM-Domäne definiert verbindliche Vorgaben zur Verwaltung von Benutzer-, Service- und Systemidentitäten sowie zur Governance von Zugriffsrechten.

Alle Zugriffsrechte werden ausschließlich über Rollen oder Gruppen vergeben — niemals direkt an einzelne Personen. Jede Person hat eine individuelle, identifizierbare Nutzeridentität; gemeinsame Konten sind untersagt. Die Multifaktor-Authentifizierung ist für alle Cloud-Ressourcen verpflichtend, ausnahmslos für privilegierte Konten. Der Zugriff erfolgt ausschließlich über den zentralen Identity Provider — lokale Cloud-Accounts außerhalb des IdP sind nicht zulässig. Der privilegierte Zugriff wird zeitlich begrenzt und just-in-time gewährt und regelmäßig überprüft.

Domäne 4: Key & Secret Management (KSM)

Kryptografische Schlüssel, Secrets und Zertifikate sind kritische Sicherheitsassets, deren unsachgemäße Verwaltung schwerwiegende Sicherheitsvorfälle verursachen kann. Secrets werden ausschließlich in einem dedizierten, von der Plattform bereitgestellten Secret-Management-Service gespeichert — nicht in Quellcode, Konfigurationsdateien oder Versionskontrollsystemen.

Vom System verwaltete Identitäten sind statischen Anmeldeinformationen vorzuziehen. Secrets und kryptografische Schlüssel rotieren in definierten Intervallen automatisch. Zertifikate werden zentral mit kontinuierlich überwachten Ablaufdaten verwaltet. Jeder Zugriff auf Secrets und Schlüssel ist lückenlos zu protokollieren.

Domäne 5: Netzwerksicherheit (NET)

Die Netzwerkarchitektur bildet die Grundlage für eine sichere und kontrollierte Kommunikation zwischen Cloud-Ressourcen und externen Systemen. Das Grundprinzip ist Deny-by-Default: Jeglicher Netzwerkverkehr wird standardmäßig verweigert. Eine Kommunikation ist nur über explizit definierte Regeln zulässig.

Cloud-Ressourcen werden in logisch unterschiedliche Netzwerksegmente unterteilt. Der Zugriff von außen erfolgt nur über definierte und kontrollierte Zugangspunkte. Öffentlich zugängliche Webservices und APIs müssen durch eine Web Application Firewall geschützt werden. Der Netzwerkverkehr wird kontinuierlich auf Auffälligkeiten überwacht.

Domäne 6: Data Classification & Protection (DATA)

Alle in der Cloud verarbeiteten Daten müssen klassifiziert werden — die Klassifizierung ist die Grundlage für alle nachgelagerten Schutzmaßnahmen. Daten dürfen nur in freigegebenen Cloud-Regionen gespeichert und verarbeitet werden.

Alle gespeicherten Daten müssen verschlüsselt werden — Datenbanken, Speicherkonten und Backups ausnahmslos. In Nicht-Produktionsumgebungen dürfen keine Produktionsdaten verwendet werden, sondern es sind synthetische oder anonymisierte Datensätze zu verwenden. Sensible Daten sind in Protokollen, Ausgaben und Schnittstellen zu maskieren. Cloud-Workloads, die personenbezogene Daten verarbeiten, müssen im Verarbeitungsverzeichnis erfasst werden.

Domäne 7: Vulnerability Management (VUL)

Schwachstellen in Cloud-Ressourcen, Abhängigkeiten und Konfigurationen stellen ein kontinuierliches Sicherheitsrisiko dar. Alle Cloud-Ressourcen werden regelmäßig und automatisch auf Schwachstellen gescannt. Identifizierte Schwachstellen werden nach CVSS klassifiziert und priorisiert.

Verbindliche Behebungsfristen nach Schweregrad: Kritische Schwachstellen (CVSS 9,0–10,0) müssen innerhalb von 72 Stunden behoben werden. Hohe Schwachstellen (CVSS 7,0–8,9) innerhalb von 14 Tagen. Mittlere Schwachstellen (CVSS 4,0–6,9) innerhalb von 30 Tagen. Geringe Schwachstellen im nächsten regulären Patchzyklus. Container und VM-Images mit kritischen oder hohen Schwachstellen dürfen nicht in Produktivumgebungen bereitgestellt werden.

Domäne 8: Security Monitoring (MON)

Eine kontinuierliche Überwachung aller Cloud-Ressourcen ist unerlässlich, um Sicherheitsvorfälle, Fehlkonfigurationen und anomales Verhalten frühzeitig zu erkennen. Alle Cloud-Ressourcen und Workloads müssen protokolliert werden — die Deaktivierung der Protokollierungsfunktionen ist nicht zulässig.

Protokolle werden zentral gesammelt und aufbewahrt — eine dezentrale oder isolierte Protokollspeicherung ist nicht zulässig. Protokolle sind manipulationssicher aufzubewahren. Sicherheitsrelevante Protokolle sind mindestens 12 Monate vorzuhalten. Für sicherheitsrelevante Ereignisse müssen automatisierte Alarme konfiguriert werden.

Domäne 9: Incident Response (IR)

Ein dokumentierter Incident-Response-Plan für Cloud-Umgebungen ist obligatorisch. Sicherheitsvorfälle müssen klassifiziert, priorisiert und nach definierten Verfahren behandelt werden. Kritische Sicherheitsvorfälle erfordern eine Meldung an das Cloud-Team innerhalb von 4 Stunden.

Alle Vorfälle werden lückenlos dokumentiert — mit Ursachen, Auswirkungen und ergriffenen Maßnahmen. Nach jedem signifikanten Incident ist ein strukturiertes Post-Incident-Review mit dokumentierten Lessons Learned durchzuführen. Die forensische Untersuchbarkeit von Vorfällen ist durch eine ausreichende Protokollierung und Vorfalldokumentation sicherzustellen.

Domäne 10: Business Continuity & Disaster Recovery (BCD)

Für kritische Anwendungen sind Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) zu definieren. Diese Werte sind die Grundlage für die Backup-Strategie und die Disaster-Recovery-Architektur — ohne sie kann kein angemessenes Recovery-Design erstellt werden.

Backup-Konzepte müssen den definierten RPO-Anforderungen entsprechen. Disaster-Recovery-Pläne müssen regelmäßig getestet werden — ungetestete Pläne sind keine Sicherheitsgarantie. Abhängigkeiten zwischen Systemen müssen erkannt und bei der Wiederherstellungsplanung berücksichtigt werden.

Domäne 11: Configuration Management (CFG)

Jede Cloud-Infrastruktur muss als Code definiert und versioniert werden. Manuelle Konfigurationsänderungen an Produktionsressourcen sind nicht zulässig — alle Änderungen erfolgen über den definierten IaC-Prozess. Konfigurationsänderungen durchlaufen einen formalen Prüf- und Genehmigungsprozess.

Konfigurationsabweichungen (Drift) zwischen Soll- und Ist-Zustand müssen automatisch erkannt werden. Alle Konfigurationsänderungen werden versioniert und sind nachvollziehbar.

Domäne 12: Platform Security (PSC)

Alle Cloud-Ressourcen müssen gemäß definierter Security Baselines gehärtet werden. Die von der Plattform bereitgestellten Sicherheitsdienste — Endpoint Protection, Vulnerability Scanning, Log Collection — müssen auf allen Ressourcen aktiviert werden. Nicht konforme Ressourcen müssen identifiziert, behoben oder entfernt werden.

Es gilt das Defense-in-Depth-Prinzip: mehrere unabhängige Sicherheitsschichten statt einer einzelnen Maßnahme. Sicherheitsbewertungen für Cloud-Umgebungen werden regelmäßig und bei signifikanten Architekturänderungen durchgeführt.

Die Nutzungsrichtlinie in der Praxis

Die zwölf Domänen sind hinsichtlich ihres Gefährdungspotenzials nicht gleich. IAM, KSM und NET bilden den sicherheitskritischen Kern — Verstöße in diesen Domänen können unmittelbar zu Security Incidents mit erheblichem Schadenspotenzial führen. AST und FIN bilden das Governance-Fundament — ohne vollständige Bestands- und Kostentransparenz kann keine der anderen Domänen wirksam durchgesetzt werden.

Der CCoE ist für die Aufrechterhaltung, Kommunikation und Durchsetzung der Nutzungsrichtlinie verantwortlich. Durch eine regelmäßige Überprüfung — mindestens jährlich — wird sichergestellt, dass die Richtlinie aktuell ist und neue Cloud-Services und Risiken berücksichtigt.