Häufige Fehlkonfigurationen in der Cloud

Fehlkonfigurationen sind die häufigste Ursache für Cloud-Datenschutzverletzungen. Im Gegensatz zu herkömmlichen Sicherheitslücken in lokalen Umgebungen, bei denen Softwarefehler ausgenutzt werden müssen, werden Cloud-Fehlkonfigurationen oft selbst verursacht und können von jeder Person im Internet trivial ausgenutzt werden.

S3-Buckets mit öffentlichem Lesezugriff legen alle darin gespeicherten Daten im Internet offen. Angreifer suchen mit Tools wie GrayhatWarfare nach offenen Buckets. Prävention: S3 Block Public Access auf Kontoebene, aktivierte S3 Object Ownership und regelmäßige Überprüfung der Bucket-Richtlinien.

Sicherheitsgruppen mit 0.0.0.0/0 für Port 22 (SSH), 3389 (RDP) oder administrative Ports schaffen eine massive Angriffsfläche. Beschränken Sie eingehende Regeln auf bestimmte CIDR-Bereiche. Verwenden Sie AWS Systems Manager Session Manager anstelle von offenem SSH.

Das versehentliche öffentliche Freigeben von RDS-Snapshots legt den gesamten Datenbankinhalt offen. Automatisierte Snapshots sind standardmäßig privat, manuelle Freigaben können jedoch vertrauliche Daten offenlegen. Überprüfen Sie die Sichtbarkeit von Snapshots mit describe-db-snapshots --include-public.

Entwickler committen AWS-Zugriffsschlüssel, Datenbankpasswörter und API-Tokens in Git-Repositorys. Angreifer durchsuchen GitHub und GitLab mit Tools wie TruffleHog und GitLeaks. Prävention: Verwenden Sie Secret-Manager, git-secrets-Pre-Commit-Hooks und organisationsweit aktivierte Secret-Scans.

Wenn CloudTrail nicht in allen Regionen aktiviert ist, werden API-Aufrufe nicht protokolliert. Angreifer nutzen Lücken in der Protokollierung, um unentdeckt zu bleiben. Aktivieren Sie CloudTrail organisationsweit und senden Sie die Protokolle an einen S3-Bucket in einem separaten Sicherheitskonto, der mit S3 Object Lock vor Manipulation geschützt ist.

IMDSv1 ermöglicht es jedem Prozess auf einer EC2-Instance, den Metadatenservice ohne Authentifizierung abzufragen. Dadurch können SSRF-Angriffe zum Diebstahl von Instance-Anmeldedaten eingesetzt werden. Erzwingen Sie auf allen Instances IMDSv2 (mit erforderlichem Token), um eine sitzungsbasierte Authentifizierung vorauszusetzen.

Sicherheitsgruppen erlauben typischerweise den gesamten ausgehenden Datenverkehr. Dadurch werden Datenexfiltration und C2-Kommunikation von kompromittierten Instances ermöglicht. Verwenden Sie eine Egress-Filterung über Sicherheitsgruppen, NACLs oder eine Firewall-Appliance, um ausgehende Verbindungen auf bekannte Ziele zu beschränken.

Kubernetes-Dashboards, Elasticsearch-Cluster, MongoDB-Instances und Jupyter-Notebooks, die ohne Authentifizierung über öffentliche IP-Adressen erreichbar sind, werden regelmäßig kompromittiert. Jede Verwaltungsschnittstelle muss eine Authentifizierung erfordern und auf bestimmte Netzwerke beschränkt sein.

S3-Datenereignisse und CloudTrail-Verwaltungsereignisse allein erfassen keine Aktionen auf Objektebene (GetObject, PutObject). Aktivieren Sie S3 Server Access Logging und CloudTrail-S3-Datenereignisse für vertrauliche Buckets, um Versuche zur Datenexfiltration zu erkennen.

AWS-Config-Regeln mit automatischer Behebung (über SSM-Automation-Dokumente oder Lambda) können Verstöße automatisch beheben: Buckets privat machen, Regeln von Sicherheitsgruppen schließen oder Anmeldedaten unter Quarantäne stellen. Dadurch lässt sich die Zeit der Gefährdung von Tagen auf Minuten reduzieren.

Welches Hauptrisiko besteht, wenn IMDSv1 auf EC2-Instances aktiviert bleibt?

Cloud-Fehlkonfigurationen – öffentliche Buckets, zu weit gefasste Sicherheitsgruppen, im Code fest codierte Anmeldedaten und fehlende Protokolle – sind die häufigste Ursache für Cloud-Sicherheitsverletzungen. Automatisierte Scans, erzwungene Sicherheitsleitplanken und kontinuierliche Überwachung sind unverzichtbare Schutzmaßnahmen.