Cloud Governance - Steuerung und Kontrolle in der Cloud - Definition & Erklärung

Cloud Governance verhindert, dass Cloud-Umgebungen über Zeit zur “Cloud-Sprawl” werden - unkontrollierte, teure und unsichere Infrastruktur ohne klare Verantwortlichkeiten. Ohne Governance entstehen in Enterprise-Umgebungen innerhalb von Monaten hunderte von Accounts, Tausende von Ressourcen und niemand weiß mehr, welche davon kritisch sind.

Governance-Dimensionen

1. Sicherheits-Governance

Wer darf was in der Cloud tun? (IAM, RBAC)
Welche Konfigurationen sind verboten? (Policy-as-Code)
Monitoring und Alerting (CSPM, CloudTrail/Monitor)
Datenschutz: wo dürfen Daten gespeichert werden? (Data Residency)

2. Kosten-Governance

Budgets und Alerts (AWS Budgets, Azure Cost Management)
Tagging für Kostenzuordnung (Abteilung, Projekt, Umgebung)
Reserved Instances vs. On-Demand Optimierung
Zombie-Ressourcen identifizieren und löschen

3. Compliance-Governance

Regulatory Requirements umsetzen (DSGVO, ISO 27001, NIS2)
Compliance-Frameworks als Code (CIS Benchmarks, NIST)
Audit-Trails und Nachweiserbringung

4. Operations-Governance

Naming-Konventionen (einheitliche Ressourcennamen)
Infrastructure-as-Code (kein manuelles Clickops!)
Change Management für Cloud-Ressourcen
Disaster Recovery und Backup-Richtlinien

5. Organisatorische Governance

Verantwortlichkeiten: Cloud Center of Excellence (CCoE)
Account/Subscription-Hierarchie
Onboarding neuer Teams in die Cloud
Self-Service vs. zentrale Kontrolle

Landing Zone Architektur

Landing Zone = vorkonfigurierte, sichere Cloud-Ausgangsbasis: Statt jedes Team seine eigene Cloud-Umgebung von Grund auf aufbaut, erhalten Teams “frische” Accounts/Subscriptions mit Guardrails und können Self-Service innerhalb definierter Grenzen nutzen.

AWS Landing Zone (AWS Control Tower)

Account-Hierarchie (AWS Organizations):

Root Management Account
├── Security OU
│   ├── Security Tooling Account (SIEM, Config, GuardDuty)
│   └── Log Archive Account (CloudTrail, alle Logs zentral)
├── Sandbox OU (kein Produktionszugang, freiere Regeln)
│   └── Developer-Sandbox Accounts
├── Workloads OU
│   ├── Production Accounts
│   └── Staging Accounts
└── Infrastructure OU
    ├── Network Account (Transit Gateway, VPNs)
    └── Shared Services Account (AD, CI/CD)

AWS Control Tower Guardrails:

Preventive Guardrails (SCPs - blockieren):

Deaktivieren von CloudTrail verboten
Root-Account-Nutzung verboten
Kein Verlassen der Organization erlaubt
S3-Block-Public-Access erzwingen

Detective Guardrails (Config Rules - alarmieren):

MFA für Root-Account aktiviert?
Offene Security Groups (0.0.0.0/0) erkannt?
Unverschlüsselte EBS-Volumes?

Azure Landing Zone

Management Group Hierarchie:

Root (Tenant)
├── Platform Management Group
│   ├── Management Subscription (Monitor, Security Center)
│   ├── Identity Subscription (AD DS, PKI)
│   └── Connectivity Subscription (Hub vNet, ExpressRoute, VPN)
├── Landing Zones Management Group
│   ├── Corp (verbunden mit Corp-Netzwerk)
│   └── Online (Internet-facing Apps, kein Corp-Connect)
└── Decommissioned (stillgelegte Subscriptions)

Azure Policy (als Guardrail):

Require TLS 1.2+ auf App Services
Restrict Locations to West Europe, North Europe
Require Tags (environment, owner, costcenter)
Deny Public IP on VMs (außer explizit erlaubte)
Deploy if not exists: automatisch korrigieren!

GCP Landing Zone

Resource Hierarchy: Organization → Folders → Projects
Org Policies: ähnlich AWS SCPs und Azure Policy
VPC Service Controls: Datenzugang zwischen Projekten einschränken

Policy-as-Code

Warum Policy-as-Code

Manuelle Checks: fehleranfällig, nicht skalierbar
Policy-as-Code: versioniert, testbar, automatisch durchgesetzt
Änderungen über Git nachvollziehbar (Who, What, When)

AWS Service Control Policies (SCPs)

Gültig für alle Accounts in einer OU
Overrule alle anderen Berechtigungen (auch Admin!)
Nur Einschränkungen (nie Erweiterungen!)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

Azure Policy (deklarativ)

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
      },
      {
        "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
        "notEquals": "true"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Open Policy Agent (OPA / Rego)

Universale Policy Engine, unabhängig von Cloud-Provider
Einsatz: Kubernetes (OPA Gatekeeper), Terraform (Conftest), CI/CD
Kubernetes-Admission-Controller: Pods mit privileged:true blockieren

deny[msg] {
  input.spec.containers[_].securityContext.privileged == true
  msg = "Privileged containers sind nicht erlaubt"
}

Terraform + Checkov (Infrastructure-as-Code Scanning)

checkov -d ./terraform --check CKV_AWS_18,CKV_AWS_54
# CKV_AWS_18: S3 Block Public Access
# CKV_AWS_54: S3 Bucket Policy MFA Delete

Checkov scannt Terraform-Code vor dem Apply
Erkennt: offene S3-Buckets, fehlende Verschlüsselung, schwache IAM-Policies
Integration in CI/CD: Pipeline scheitert bei Policy-Verletzung

Cloud Security Posture Management (CSPM)

CSPM = kontinuierliches Assessment der Cloud-Sicherheitskonfiguration.

Funktionen:

Inventarisierung aller Cloud-Ressourcen
Vergleich mit Security-Benchmarks (CIS, NIST, DSGVO)
Alert bei Misconfigurationen
Remediation-Empfehlungen

AWS Security Hub

Zentrales Dashboard für alle AWS-Security-Findings
Standards: CIS AWS Foundations Benchmark, NIST SP 800-53
Integration: GuardDuty, Inspector, Macie, Config, Access Analyzer
Multi-Account: aggregiert Findings aus allen AWS-Accounts

Microsoft Defender for Cloud

CSPM für Azure + Multi-Cloud (AWS, GCP!)
Secure Score: 0-100 (höher = besser konfiguriert)
Regulatory Compliance: ISO 27001, NIST, DSGVO-Mapping
Defender CSPM: Erweitert mit Attack Path Analysis

Wiz

Multi-Cloud-CSPM (AWS + Azure + GCP + OCI)
Graph-basierte Analyse: “Security Graph” findet komplexe Angriffspfade über mehrere Ressourcen
“Would this resource be publicly exposed?” - Kontextanalyse
Preis: Enterprise, marktführend in Fortune-500

Orca Security

Agentless: liest Cloud-Storage direkt (kein Agent nötig!)
SideScanning: analysiert Cloud-Storage-Snapshots
Erkennt: Secrets in EC2-Images, Schwachstellen in AMIs

Prisma Cloud (Palo Alto)

Vollständige CNAPP-Plattform
CSPM + CWPP + CIEM + IaC Security in einer Plattform
Stärke: Kubernetes Security, Container Image Scanning

Eigene CSPM-Basis (kostenlos)

AWS: AWS Config + AWS Security Hub + CIS Benchmark Standard
Azure: Microsoft Defender for Cloud Free Tier + Azure Policy
Basis-Coverage ohne Extra-Lizenz!

Tagging-Strategie

Pflicht-Tags (JEDE Ressource!)

Tag	Werte
environment	production \| staging \| development \| sandbox
owner	team-name oder email@firma.de
costcenter	123456 (Kostenstelle für Chargeback)
project	projekt-name
created-by	terraform \| manual \| ci-cd-pipeline

Erweiterte Tags

Tag	Werte
data-classification	public \| internal \| confidential \| restricted
backup	daily \| weekly \| none
compliance	iso27001 \| nis2 \| hipaa
expiry-date	2026-12-31 (für temporäre Ressourcen!)

Tag-Enforcement

AWS: Resource Groups + Tag Policies via AWS Organizations
Azure: Azure Policy “Require Tag” (deny wenn fehlend)
GCP: Organization Policy + Resource Labels

Kostenallokation via Tags

AWS Cost Explorer → “Group by Tag: costcenter”
Exakte Kostenzuordnung pro Team/Projekt
Chargeback-Modell: Abteilung A zahlt für ihre Cloud-Nutzung

Automatisches Cleanup via Tags

Lambda-Funktion prüft täglich:
- Ressourcen mit expiry-date in der Vergangenheit → Alert oder Auto-Delete
- Ressourcen ohne owner-Tag seit 30 Tagen → Alert an Team
- Sandbox: Auto-Shutdown nach 72h (kein Produktivbetrieb!)