Cloud-Sicherheit

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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
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

Abgerufen von „https://www.xinux.net/index.php?title=Cloud-Sicherheit&oldid=73131“