Cloud-Sicherheit

Cloud- und Container-Sicherheit

Architekturprinzip Cloud

• Ressourcen werden ueber APIs gesteuert
• Identitaet ist der zentrale Sicherheitsanker
• Netzwerk ist softwaredefiniert
• Konfiguration ersetzt physische Kontrolle
• Automatisierung ersetzt manuelle Administration

Shared Responsibility

Verantwortung	Provider	Kunde
Rechenzentrum, Hardware, Hypervisor	x
Identitaeten und Rechte		x
Konfiguration der Dienste		x
Daten und deren Verschluesselung		x
Betriebssystem der Instanzen		x

• Fehlkonfiguration ist die haeufigste Ursache fuer Vorfaelle
• Cloud ist nicht automatisch sicher, sondern automatisiert

Angriffsflaeche Identitaet

Kompromittierter IAM-Account

Ausgangslage

• Global-Admin ohne MFA
• Statische Access Keys im Einsatz

Angriff

• Credential Phishing oder Leak in einem oeffentlichen Repository
• Login ueber die API
• Neue Admin-User werden angelegt
• Logs werden manipuliert oder deaktiviert

Auswirkung

• Vollstaendige Uebernahme der Umgebung
• Backups loeschbar, Instanzen start- und stoppbar, Daten exfiltrierbar

Gegenmassnahmen

• MFA verpflichtend
• Kein Root-Login fuer den Tagesbetrieb
• Least Privilege
• Logging unveraenderbar speichern

Offene Storage-Ressourcen

Ausgangslage

• Bucket oder Blob-Storage oeffentlich gesetzt

Angriff

• Automatisierte Scanner finden offene Buckets
• Download sensibler Daten

Auswirkung

• DSGVO-Verstoss, Bussgelder, Reputationsschaden

Gegenmassnahmen

• Default Private Policies
• Automatische Compliance-Checks
• Regelmaessige Audits

API-Missbrauch

Ausgangslage

• Steuerung ausschliesslich ueber APIs
• Keine Rate-Limits, kein Monitoring

Angriff

• Gestohlener API-Key
• Massives Starten von Instanzen
• Krypto-Mining

Auswirkung

• Kostenexplosion, Ressourcenverbrauch, Service-Instabilitaet

Gegenmassnahmen

• Temporaere Tokens statt statischer Keys
• Billing Alerts
• API-Monitoring
• Rollenbasierte Einschraenkung

Laterale Bewegung

Ausgangslage

• Mehrere Netze ohne saubere Trennung
• Uebermaessige IAM-Rechte

Angriff

• Kompromittierte Test-VM
• Auslesen des Metadaten-Dienstes
• Uebernahme weiterer Rollen

Auswirkung

• Pivot von Dev nach Prod
• Zugriff auf Datenbanken

Gegenmassnahmen

• Trennung von Dev, Test und Prod
• Restriktiver Zugriff auf den Metadaten-Dienst
• Service Control Policies

Ransomware

Ausgangslage

• Backups nicht isoliert
• Snapshots loeschbar

Angriff

• Admin-Zugang kompromittiert
• Snapshots geloescht, Datenbanken verschluesselt

Auswirkung

• Totalausfall, keine Wiederherstellung moeglich

Gegenmassnahmen

• Immutable Backups
• Versionierung aktivieren
• Backup-Zugriff getrennt absichern

Systemische Risiken

Risiko	Beschreibung
Vendor Lock-In	Proprietaere Dienste erschweren die Migration, die Sicherheitsstrategie haengt am Provider
Multi-Cloud-Komplexitaet	Unterschiedliche IAM-Modelle und Logging-Systeme, Policy-Inkonsistenzen
Rechtliche Risiken	Datenstandort, extraterritoriale Zugriffsrechte, Compliance-Anforderungen

Container als Baustein der Cloud

Sicherheitsmodell

	Container	Virtuelle Maschine
Kernel	geteilt mit dem Host	eigener Kernel
Trennung	Prozessisolation	Systemisolation durch den Hypervisor
Wirkung eines Kernel-Exploits	Host und alle Container	nur die betroffene VM

• Container sind kein Ersatz fuer Isolation durch VMs
• In der Cloud meist eine Kombination aus beidem
• Container sind effizient, aber keine Sicherheitsgrenze

Container Escape

Ausgangslage

• Container laeuft mit erweiterten Rechten
• --privileged oder CAP_SYS_ADMIN gesetzt
• Host-Dateisystem gemountet

Angriff

• Exploit im Kernel oder Missbrauch von Capabilities
• Zugriff auf /proc oder /var/run/docker.sock
• Start weiterer Container mit Root-Rechten

Auswirkung

• Uebernahme des Hosts
• Manipulation anderer Container
• Persistente Hintertuer

Gegenmassnahmen

• Regeln 1, 2, 3 und 4 der Haertungstabelle

Runtime Security

• Image-Scanning erkennt nur bekannte CVEs
• Angriffe zur Laufzeit bleiben ohne Monitoring unentdeckt

Typische Anomalien

• Shell-Spawn innerhalb eines Containers
• Zugriff auf /etc/shadow oder Host-Mounts
• Ausgehende Verbindungen zu Command-and-Control-Servern

Massnahmen

• Runtime-Monitoring, etwa mit Falco
• System-Call-Ueberwachung
• Events ins SIEM einspeisen
• Alarmierung bei ungewoehnlichem Verhalten

Supply Chain

Risikoquelle

• Unsichere Basis-Images
• Trojanisierte Images aus oeffentlichen Registries
• Manipulierte Abhaengigkeiten aus npm oder pip

Angriff

• Entwickler zieht ein manipuliertes Image
• Backdoor wird mitdeployt
• Angreifer erhaelt Zugriff auf die Produktionsumgebung

Gegenmassnahmen

• Nur vertrauenswuerdige Registries
• Image-Signaturen pruefen
• SBOM erzeugen und validieren
• Automatisches Scanning in der Pipeline, siehe Regel 9

Registry

• Die Registry ist die zentrale Vertrauensquelle
• Manipulierte Registry bedeutet manipulierte Infrastruktur

Risiko	Massnahme
Unverschluesselte Push- und Pull-Verbindungen	TLS erzwingen
Keine Authentifizierung	RBAC fuer Push und Pull
Uebermaessige Schreibrechte	Immutable Tags nutzen
Keine Nachvollziehbarkeit	Audit-Logs aktivieren

Netzwerksegmentierung

• Die Standard-Bridge erlaubt Ost-West-Verkehr
• Container koennen sich gegenseitig erreichen

Risiken

• Laterale Bewegung
• Pivot zwischen Microservices

Massnahmen

• User-Defined Networks, siehe Regel 5
• NetworkPolicies unter Kubernetes
• Service Mesh mit mTLS
• Zero-Trust-Prinzip auch intern

Secrets

• Secrets gehoeren weder ins Image noch in Umgebungsvariablen

Risiko

• docker inspect zeigt Umgebungsvariablen
• kubectl describe pod offenbart Secrets
• Ein geleakter API-Key kompromittiert die gesamte Cloud-Umgebung

Massnahmen

• Secrets Manager oder Vault einsetzen
• Temporaere Tokens
• Automatische Rotation
• Minimaler Zugriff je Dienst

Kubernetes als Verstaerker

• Docker ist nur die Basis, Kubernetes erweitert die Angriffsflaeche

Risiken

• Offener API-Server
• Fehlendes RBAC
• Ueberprivilegierte ServiceAccounts
• Unsichere Helm-Charts

Angriff

• Kompromittierter Pod liest das ServiceAccount-Token
• Token erlaubt clusterweite Aktionen
• Deployment wird manipuliert

Massnahmen

• RBAC strikt definieren
• PodSecurityStandards erzwingen
• Admission Controller einsetzen
• Audit-Logs ueberwachen

Zusaetzliche Isolationsschichten

Loesung	Ansatz
gVisor	Kernel im Userspace, Systemaufrufe werden abgefangen
Kata Containers	Jeder Container laeuft in einer Micro-VM
Firecracker	Minimale VM mit sehr kurzer Startzeit

• Reduzierte Angriffsflaeche
• Staerkere Mandantentrennung
• Geeignet fuer Public Cloud und Multi-Tenant

Haertungsregeln

Nr	Regel	Risiko	Umsetzung
0	Host und Docker aktuell halten	Kernel-Exploits wirken direkt auf den Host	Updates von Engine und Kernel, Security Advisories abonnieren
1	Docker-Socket nicht freigeben	Zugriff auf /var/run/docker.sock ist Root auf dem Host	Socket nie in einen Container mounten, bei Bedarf TLS-gesicherter TCP-Socket
2	Benutzer festlegen	Prozesse laufen sonst als root	USER im Dockerfile, --userns-remap, unter Kubernetes runAsNonRoot
3	Faehigkeiten beschraenken	Unnoetige Capabilities erlauben Kernel-Operationen	--cap-drop all und nur Benoetigtes ergaenzen, nie --privileged
4	no-new-privileges setzen	Rechteausweitung ueber setuid und setgid	--security-opt=no-new-privileges, unter Kubernetes allowPrivilegeEscalation=false
5	Inter-Container-Kommunikation abschalten	Kompromittierter Container scannt und greift andere an	Docker mit --icc=false starten, Verbindungen explizit erlauben
6	Sicherheitsmodule nutzen	Ohne Profile Zugriff auf kritische Kernel-Funktionen	Standardprofile von Seccomp, AppArmor und SELinux nicht abschalten, eigene Policies schreiben
7	Ressourcen begrenzen	Denial of Service durch Ueberlastung des Hosts	--memory, --cpu-shares, --ulimit, unter Kubernetes Resource Limits
8	Dateisysteme schreibgeschuetzt mounten	Malware baut Persistenz auf	--read-only, Schreibzugriff nur ueber tmpfs, Volumes mit :ro
9	Statische Analyse einsetzen	Images enthalten bekannte CVEs	Trivy, Grype, Docker Scout oder Clair in der Pipeline
10	Logging konfigurieren	Ereignisse fehlen oder ertrinken im Rauschen	Mindestens Level info, zentrale Sammlung in SIEM oder Loki
11	Dockerfile absichern	Root-User, ungepatchte Basis-Images, unfixierte Versionen	USER definieren, Basis-Images versionieren, COPY statt ADD, mit hadolint pruefen

Bewertung mit Docker Bench for Security

Was es macht

• Shell-Skript, das den laufenden Docker-Host gegen den CIS Docker Benchmark prueft
• Ausgabe je Kontrolle als PASS, WARN oder INFO
• Die Kontrollen entsprechen weitgehend den Regeln der Tabelle oben

Abgrenzung

Werkzeug	Frage die es beantwortet
Trivy, Grype	Welche Luecken stecken im Image
Docker Bench	Wie wird der Host und die Container betrieben
Falco	Was passiert zur Laufzeit

Installation

• git clone https://github.com/docker/docker-bench-security.git
• cd docker-bench-security

Ausfuehren

• sudo sh docker-bench-security.sh

Nur eine einzelne Kontrolle pruefen

• sudo sh docker-bench-security.sh -c check_2_2

Eine Kontrolle ausnehmen

• sudo sh docker-bench-security.sh -e check_2_2

Ergebnis in eine Datei schreiben

• sudo sh docker-bench-security.sh -l /tmp/bench.log

Hinweise

• jq ist optional, verbessert aber die Ausgabe
• Das Skript folgt CIS Docker Benchmark v1.6.0 und hinkt dem aktuellen Benchmark hinterher
• Geprueft wird der laufende Daemon, nicht das Dockerfile und nicht die Registry

Uebung

Ausgangsmessung

• Docker Bench auf dem sauberen Host laufen lassen
• Anzahl der WARN notieren

Verschlechterung erzeugen

• docker run -d --name schwach --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /:/host alpine sleep 3600

Zweite Messung

• Docker Bench erneut laufen lassen
• Neue WARN mit den Regeln 1, 2 und 3 abgleichen

Ausbruch zeigen

• docker exec -it schwach sh
• ls /host/etc/shadow
• Damit ist der Container Escape ohne Exploit demonstriert, allein durch Konfiguration

Aufraeumen

• docker rm -f schwach

Kernaussage

• Cloud ist API-gesteuerte Infrastruktur
• Identitaet ist der zentrale Angriffspunkt
• Fehlkonfiguration schlaegt technische Schutzmassnahmen
• Container sind effizient, aber keine Sicherheitsgrenze
• Kubernetes vergroessert die Angriffsflaeche erheblich
• Sicherheit muss Teil der Pipeline sein

Old Stuff

• Cloud-Sicherheit Konkret
• Erweiterte Aspekte der Container-Sicherheit
• Docker Security