Cloud-Governance-Framework: Policies automatisieren auf AWS

Warum manuelle Governance nicht skaliert

Viele Unternehmen starten ihre Cloud-Journey mit manuellen Governance-Prozessen: Excel-Checklisten für Sicherheitsreviews, monatliche Audit-Meetings, händische Tag-Überprüfungen und reaktive Compliance-Prüfungen nach Incidents. Dieser Ansatz funktioniert bei einem Dutzend Workloads. Er kollabiert bei hundert.

Die Zahlen sind eindeutig: Gartner prognostiziert, dass bis 2025 über 99 % aller Cloud-Sicherheitsvorfälle durch Fehlkonfigurationen verursacht werden — nicht durch Schwachstellen in AWS-Services selbst.^[1] Eine Studie von IBM Security beziffert die durchschnittlichen Kosten eines Cloud-basierten Datenschutzvorfalls in Deutschland auf 4,9 Millionen Euro.^[2] Der überwiegende Teil dieser Vorfälle wäre durch automatisierte Compliance-Prüfungen erkennbar und verhinderbar gewesen.

Die Ursache liegt im Wachstum selbst: Jeder neue Account, jede neue Region, jedes neue Team multipliziert den Governance-Aufwand. Drei Mechanismen machen manuelle Governance bei Skalierung zum Problem:

1. Konfigurationsdrift: Ressourcen werden deployed und danach nicht mehr mit Sicherheitsstandards abgeglichen. Ein S3-Bucket, der nach dem Deployment öffentlich konfiguriert wird, fällt wochenlang nicht auf.
2. Inkonsistente Durchsetzung: Manuelle Reviews sind per Definition lückenhaft. Teams mit hohem Delivery-Druck umgehen Prozesse, nicht aus böser Absicht, sondern weil der Weg des geringsten Widerstands nicht der compliant-konforme ist.
3. Fehlende Auditierbarkeit: Wenn Regulatoren Nachweise fordern, müssen Logs manuell zusammengestellt werden. Ohne kontinuierliche Aufzeichnung fehlen die Belege für vergangene Compliance-Zustände.

Die Alternative ist Governance-as-Code: Policies werden maschinenlesbar definiert, automatisch durchgesetzt und kontinuierlich ausgewertet. AWS stellt dafür ein kohärentes Toolset bereit.

Begriffsklärung: Das Governance-Vokabular auf AWS

Service Control Policy (SCP)

Eine JSON-basierte Policy in AWS Organizations, die als Obergrenze für Berechtigungen innerhalb von Organizational Units (OUs) und Accounts wirkt. SCPs können Aktionen grundsätzlich verbieten — unabhängig davon, welche IAM-Berechtigungen einem Nutzer oder einer Rolle zugewiesen sind. Sie sind das stärkste Governance-Instrument auf Organisationsebene und bilden den äußeren Rahmen aller Guardrails.

Config Rule

Eine Regel in AWS Config, die einen gewünschten Konfigurationszustand für AWS-Ressourcen definiert. Config Rules werden kontinuierlich oder bei Konfigurationsänderungen ausgewertet. Bei Abweichung wird die Ressource als "non-compliant" markiert. AWS stellt über 250 Managed Rules bereit; Custom Rules ermöglichen beliebig spezifische Prüflogik via Lambda.

Guardrail

Ein Sicherheitsmechanismus, der entweder präventiv (verhindert eine nicht-compliant Aktion von vornherein, z. B. SCP) oder detektiv (erkennt einen nicht-complianten Zustand und meldet ihn, z. B. Config Rule) wirkt. Der Begriff entstammt dem AWS Control Tower Framework. Gute Governance kombiniert präventive und detektive Guardrails.

Compliance-as-Code

Der Ansatz, Compliance-Anforderungen als versionierte, maschinenlesbare Regeln zu definieren — in Git gespeichert, automatisch deployed und kontinuierlich gegen die Infrastruktur geprüft. Compliance-as-Code macht den Compliance-Status messbar, reproduzierbar und auditierbar. Es ersetzt statische Dokumente durch lebende, verifizierbare Artefakte.

Tag-Policy

Eine Policy in AWS Organizations, die verbindliche Tagging-Standards für AWS-Ressourcen durchsetzt. Sie definiert erlaubte Tag-Keys, Groß-/Kleinschreibungsregeln und optional erlaubte Werte. Tag-Policies sind Grundlage für Kostenallokation, Sicherheitskontrollen und automatisiertes Lifecycle-Management.

AWS Config Rules im Detail

AWS Config ist der Kern jedes detektiven Governance-Frameworks. Es zeichnet kontinuierlich den Konfigurationszustand aller AWS-Ressourcen auf und ermöglicht es, Änderungen nachzuvollziehen und gegen Soll-Zustände zu prüfen.

Funktionsweise

AWS Config sendet bei jeder Konfigurationsänderung einen Snapshot in einen S3-Bucket und triggert optional Evaluierungen. Config Rules werden entweder änderungsgetriggert (bei jeder Ressource-Änderung) oder periodisch (alle 1, 3, 6, 12 oder 24 Stunden) ausgeführt. Das Ergebnis ist ein binärer Compliance-Status: COMPLIANT oder NON_COMPLIANT.

Managed Rules vs. Custom Rules

AWS stellt über 250 Managed Rules für häufige Compliance-Prüfungen bereit — etwa:

• s3-bucket-public-read-prohibited — S3-Buckets dürfen nicht öffentlich lesbar sein
• encrypted-volumes — EBS-Volumes müssen verschlüsselt sein
• root-account-mfa-enabled — Root-Account muss MFA aktiviert haben
• vpc-flow-logs-enabled — VPC Flow Logs müssen aktiv sein
• iam-password-policy — IAM-Passwort-Policy muss Mindestanforderungen erfüllen

Custom Rules erlauben beliebig spezifische Prüflogik via AWS Lambda. Damit lassen sich unternehmensspezifische Standards durchsetzen — etwa dass alle EC2-Instances ein bestimmtes Tag tragen oder alle Sicherheitsgruppen bestimmte Portfreigaben verbieten.

Conformance Packs

AWS bündelt thematisch zusammengehörige Config Rules in Conformance Packs. Für DACH-Unternehmen besonders relevant:

• CIS AWS Foundations Benchmark v1.4 — Baseline-Sicherheitskontrollen
• NIST SP 800-53 Rev. 5 — Mapping auf US-Bundesstandards (häufig als BSI C5-Proxy verwendet)
• AWS Operational Best Practices for ISO 27001 — ISO-27001-Kontrollen

Conformance Packs lassen sich per CloudFormation oder AWS Control Tower organisationsweit ausrollen — ein einzelner Deploy konfiguriert Governance für alle Accounts.

Automatische Remediation

Config Rules können mit Remediation Actions verknüpft werden: Wenn eine Ressource als non-compliant erkannt wird, triggert AWS Systems Manager Automation einen Korrekturschritt — etwa das automatische Deaktivieren eines öffentlichen S3-Buckets oder das Hinzufügen eines fehlenden Tags. Damit wird aus detektiver Governance teilweise präventive Governance.

Service Control Policies (SCPs): Leitplanken für Accounts

SCPs sind das mächtigste Governance-Werkzeug in AWS Organizations. Sie wirken als Zugriffsfilter auf Organisationsebene: Auch wenn einem IAM-Nutzer eine Berechtigung explizit gewährt wurde, verhindert eine SCP die Ausführung, wenn diese die Aktion nicht zulässt.

Präventive vs. detektive Governance

Der entscheidende Vorteil von SCPs gegenüber Config Rules: Sie sind präventiv. Sie verhindern nicht-compliant Aktionen, bevor sie ausgeführt werden — Config Rules erkennen sie erst im Nachhinein. Für kritische Sicherheitsanforderungen sollten immer SCPs als erste Verteidigungslinie eingesetzt werden.

Typische SCP-Muster für DACH-Unternehmen

OU-Hierarchie und SCP-Vererbung

SCPs vererben sich die OU-Hierarchie hinunter. Eine auf der Root-OU definierte SCP gilt für alle Accounts in der gesamten Organisation. SCPs auf OU-Ebene können den Scope weiter einschränken — aber nie erweitern. Diese Vererbungslogik erlaubt eine mehrstufige Governance:

1. Root-OU: Absolut unveränderliche Guardrails (z. B. keine AWS-Region außerhalb EU)
2. Umgebungs-OU (Prod/NonProd): Umgebungsspezifische Einschränkungen (z. B. kein Public-Internet-Zugang in Prod)
3. Workload-OU: Workload-spezifische Constraints (z. B. nur bestimmte Instance-Typen)

Tag-Policies und Kostenallokation

Tags sind das Metadaten-Rückgrat jeder AWS-Umgebung. Sie ermöglichen Kostenallokation nach Teams, Projekten und Cost-Centern, Sicherheitskontrollen via Attribute-Based Access Control (ABAC), automatisiertes Lifecycle-Management und Inventory-Auswertungen für Compliance-Nachweise.

Ohne durchgesetzte Tag-Standards ist Cloud-FinOps unmöglich: Wenn ein Drittel der Ressourcen nicht getaggt ist, können 30–40 % der Kosten nicht zugeordnet werden — ein typisches Problem in gewachsenen Multi-Account-Umgebungen.

Tag-Policies einrichten

Tag-Policies in AWS Organizations definieren verbindliche Standards. Eine einfache Policy könnte lauten:

• Tag Environment ist Pflicht, erlaubte Werte: prod, staging, dev
• Tag CostCenter ist Pflicht, Freitext
• Tag Owner ist Pflicht, Format: E-Mail-Adresse
• Tag DataClassification ist Pflicht, erlaubte Werte: public, internal, confidential, restricted

Tag-Policies allein erzwingen keine Tags — sie definieren nur die erlaubten Werte. Die Durchsetzung der Pflichtigkeit erfolgt über ergänzende Config Rules (z. B. required-tags).

ABAC: Tags als Sicherheitskontrollen

Attribute-Based Access Control (ABAC) erweitert Tag-Policies um eine Sicherheitsdimension: IAM-Policies können so formuliert werden, dass ein Nutzer nur auf Ressourcen zugreifen darf, die denselben DataClassification-Tag tragen wie seine IAM-Session. Damit reduziert sich der Schaden im Fall kompromittierter Credentials erheblich.

AWS Security Hub und Audit Manager für Compliance

AWS Security Hub

AWS Security Hub aggregiert Sicherheitsbefunde aus allen AWS-nativen Services (GuardDuty, Inspector, Macie, Config, IAM Access Analyzer) und Third-Party-Tools in einer zentralen Ansicht. Es bewertet den Sicherheitsstatus anhand standardisierter Frameworks:

• AWS Foundational Security Best Practices (FSBP) — über 350 automatisierte Kontrollen
• CIS AWS Foundations Benchmark v1.4 / v3.0
• NIST SP 800-53 Rev. 5
• PCI DSS v3.2.1

Jeder Befund erhält einen normalisierten Severity-Score (CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL) und ein AWS Security Finding Format (ASFF)-konformes JSON. EventBridge-Regeln können auf Befunde reagieren — etwa automatisch ein Jira-Ticket erstellen oder eine Lambda-Remediation triggern.

AWS Audit Manager

Während Security Hub den operativen Sicherheitsstatus überwacht, ist AWS Audit Manager auf die Anforderungen regulatorischer Audits ausgerichtet. Es bildet Compliance-Frameworks (BSI C5, ISO 27001, SOC 2, DSGVO) auf AWS-Kontrollen ab und sammelt automatisch Belege:

• CloudTrail-Events als Nachweis für Zugriffskontrollen
• Config-Snapshots als Nachweis für Konfigurationsstandards
• IAM-Policy-Dokumente als Nachweis für Berechtigungsmanagement

Das Ergebnis ist ein Audit-Paket, das direkt an Wirtschaftsprüfer oder interne Revision übergeben werden kann — ohne manuelle Zusammenstellung über Wochen. AWS Audit Manager reduziert den Aufwand für die Vorbereitung eines BSI C5-Audits nach Erfahrungswerten von Storm Reply um 40–60 %.

Cloud-Governance in der Storm Road.MAP-Methodik

Die Storm Road.MAP strukturiert Cloud-Transformationen in vier Phasen. Governance ist kein einmaliges Setup, sondern wird über alle Phasen hinweg aufgebaut und verfeinert.

Phase 1: Assess

In der Assess-Phase wird der Governance-Ist-Zustand erfasst. Typische Aktivitäten:

1. AWS Config aktivieren und ersten Compliance-Snapshot erstellen
2. Security Hub aktivieren, FSBP-Standard einschalten
3. CloudTrail organisationsweit auf S3 schreiben
4. IAM Access Analyzer für alle Regions aktivieren
5. Findings priorisieren nach Severity und regulatorischer Relevanz

Das Ergebnis ist ein Governance-Gap-Report: eine priorisierte Liste offener Findings mit Aufwandsschätzung und regulatorischer Zuordnung.

Phase 2: Mobilize

In der Mobilize-Phase werden die Grundstrukturen geschaffen:

1. AWS Organizations mit OU-Hierarchie aufsetzen
2. AWS Control Tower deployen (Account Factory, Guardrails, Landing Zone)
3. Erste SCPs definieren und auf Root/OU-Ebene deployen
4. Tag-Policies organisationsweit aktivieren
5. Conformance Pack für CIS Foundations Benchmark ausrollen
6. Audit Manager Framework für BSI C5 / ISO 27001 konfigurieren

Phase 3: Migrate / Build

Governance wird workload-spezifisch verfeinert: Custom Config Rules für spezifische Anwendungsanforderungen, ABAC-Strukturen für Datenlassifizierung, workload-spezifische SCPs in dedizierten OUs.

Phase 4: Operate & Optimize

Governance wird als lebender Prozess betrieben: Regelmäßige Review-Zyklen, Automatisierung von Remediations, Integration in das Change-Management-Prozess und kontinuierliche Anpassung an neue Regulatorik.

Storm Reply Perspektive: Governance als Enabler

In der Praxis erleben wir bei DACH-Kunden drei Governance-Anti-Pattern, die wir in Projekten regelmäßig auflösen müssen:

Anti-Pattern 1: Governance als Nachgedanke. Unternehmen deployen hunderte Workloads und beginnen erst dann, über Governance nachzudenken, wenn der erste Compliance-Audit kommt oder ein Sicherheitsvorfall eintritt. Das Nachrüsten ist immer teurer als das initiale Setup — wir sehen Faktoren von 3x bis 10x im Sanierungsaufwand.

Anti-Pattern 2: Governance als Gatekeeper. Governance-Teams blockieren Deployments durch manuelle Reviews. Das Ergebnis ist Shadow-IT: Teams umgehen die offizielle Cloud-Umgebung und deployen in inoffizielle Accounts. Automatisierte Guardrails eliminieren diesen Anreiz — was compliant-konform ist, kann schnell deployed werden; was gegen die Policy verstößt, wird gar nicht erst ermöglicht.

Anti-Pattern 3: Zu viele Regeln von Anfang an. Unternehmen aktivieren alle 350 FSBP-Kontrollen auf einmal und sind vom Rauschen überfordert. Unser Empfehlung: Mit 40–60 kritischen Controls starten, Findings nach Severity und Regulatorik priorisieren und inkrementell erweitern.

Storm Reply als AWS Premier Consulting Partner mit Kompetenz in Migration, Security und DevOps hat das Governance-Framework bereits für Unternehmen aus Finanzdienstleistung, Life Science und öffentlichem Sektor implementiert. Die Storm Road.MAP liefert den strukturierten Rahmen, der Governance in den Transformationsprozess integriert — nicht als separates Projekt danach.

Regulatorische Aspekte: NIS2, BSI C5, DSGVO und EU AI Act

Cloud-Governance auf AWS ist kein optionales Nice-to-have — es ist für viele DACH-Unternehmen regulatorische Pflicht. Die wichtigsten Rahmenbedingungen im Überblick:

NIS2-Richtlinie (seit Oktober 2024 in nationales Recht umzusetzen)

NIS2 verpflichtet Betreiber kritischer Infrastrukturen und wichtige Einrichtungen zu technischen und organisatorischen Maßnahmen für Risikomanagement, Meldepflichten und Business Continuity. Konkret relevant für Cloud-Governance:

• Art. 21 lit. a): Risikoanalyse und Sicherheitskonzepte für Informationssysteme — deckend mit AWS Config + Security Hub
• Art. 21 lit. c): Backup-Management und Wiederherstellung — AWS Backup + Config Rule backup-plan-min-frequency-and-min-retention-check
• Art. 21 lit. h): Multi-Faktor-Authentifizierung — Config Rule iam-user-mfa-enabled + SCP gegen Root-Zugriff

BSI C5 (Cloud Computing Compliance Criteria Catalogue)

BSI C5 ist der maßgebliche Sicherheitsstandard für Cloud-Dienste im deutschen Markt, insbesondere für Behörden und regulierte Industrien. AWS ist für alle relevanten Kriteriengruppen zertifiziert. Für Kunden relevant ist das Shared-Responsibility-Model: AWS verantwortet die Infrastruktur (C5-Testat vorhanden), Kunden verantworten die Nutzerschicht (eigenes Testat oder Nachweis erforderlich). AWS Audit Manager bildet BSI C5 als Framework ab und liefert Belege für die Kundenseite.

DSGVO

SCPs zur Region-Einschränkung auf EU-Regionen sind das technische Fundament für DSGVO-konformes Cloud-Computing. Ergänzend relevant: S3-Object-Lock für Aufbewahrungsfristen, CloudTrail für Nachvollziehbarkeit von Datenzugriffen, Macie für automatische Klassifizierung personenbezogener Daten in S3.

EU AI Act

Der EU AI Act verpflichtet Betreiber von Hochrisiko-KI-Systemen zu Governance-Strukturen, die Nachvollziehbarkeit, Auditierbarkeit und Risikomanagement umfassen. AWS Audit Manager und CloudTrail liefern die technische Grundlage für die geforderte Dokumentation von Trainingsdaten, Modellversionen und Entscheidungsprozessen.

Vorteile und Herausforderungen auf einen Blick

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer SCP und einer IAM-Policy?

Eine IAM-Policy gewährt Berechtigungen innerhalb eines Accounts. Eine Service Control Policy (SCP) in AWS Organizations setzt dagegen eine Obergrenze: Sie kann Berechtigungen einschränken, aber nie erweitern. SCPs wirken auf alle Principals eines Accounts — auch auf Account-Administratoren — und sind damit das Fundament organisationsweiter Guardrails.

Wie viele AWS Config Rules braucht ein typisches Unternehmen?

Das AWS Security Hub FSBP-Standard enthält über 350 automatisierte Prüfpunkte. Für einen DACH-Mittelständler ohne besondere Regulatorik empfehlen wir einen Einstieg mit 40–60 Managed Rules, die die CIS AWS Foundations Benchmark abdecken. Bei BSI C5 oder DORA kommen sektorspezifische Pakete hinzu.

Kann Compliance-as-Code bestehende manuelle Audits ersetzen?

Compliance-as-Code automatisiert die kontinuierliche Überwachung technischer Controls und reduziert den manuellen Aufwand erheblich. Regulatorische Audits (z. B. BSI C5-Testate) erfordern jedoch weiterhin menschliche Bewertung organisatorischer Controls sowie die Dokumentation von Ausnahmeprozessen. AWS Audit Manager liefert die technischen Nachweise direkt als Export in das Audit-Paket.

Wie verhält sich AWS Control Tower im Verhältnis zu manuell konfigurierten SCPs?

AWS Control Tower ist ein Managed-Service, der eine Landing Zone mit vordefinierten Guardrails (SCPs + Config Rules) ausrollt und Account-Vending automatisiert. Für neue Umgebungen empfehlen wir Control Tower als Ausgangspunkt. In bestehenden, gewachsenen Umgebungen ist eine manuelle Migration in Control Tower möglich, erfordert aber eine sorgfältige Planung.

Quellen

1. Gartner, "Is the Cloud Secure?", 2019 (Prognose: 99% der Cloud-Vorfälle durch Kundenfehler bis 2025)
2. IBM Security, "Cost of a Data Breach Report 2023" — Durchschnittliche Kosten Deutschland: 4,9 Mio. USD
3. AWS, AWS Config Managed Rules Documentation
4. AWS, Service Control Policies (SCPs) — AWS Organizations
5. BSI, BSI Cloud Computing Compliance Criteria Catalogue (C5)
6. EU, NIS2-Richtlinie (EU) 2022/2555