Die Integration von AWS bietet große Chancen für Skalierung und Agilität, bringt aber spezifische Sicherheitsrisiken mit sich. Dieser Artikel erklärt verständlich die häufigsten Schwachstellen bei der Cloud‑Integration, zeigt typische Angriffswege und gibt prägnante Hinweise zur Risikominderung. Ideal für Entscheiderinnen und Entscheider sowie IT‑Verantwortliche, die ihre AWS‑Umsetzung sicherer machen wollen.

Die Nutzung von Amazon Web Services (AWS) ermöglicht Unternehmen, IT-Ressourcen flexibel zu betreiben und schnell auf Geschäftsanforderungen zu reagieren. Gleichzeitig verändert die Cloud die Art und Weise, wie Systeme gesichert werden müssen. Beim Übergang von On-Premise-Infrastrukturen zu AWS entstehen spezifische Sicherheitsrisiken, die in der Praxis immer wieder zu Problemen führen. Dieser Artikel erläutert die typischen Schwachstellen bei der AWS-Integration, legt dar, wie Angreifer diese Schwachstellen ausnutzen, und beschreibt praxisnahe Schutzmaßnahmen.


Typische Sicherheitsrisiken

Verwaltung von Identitäten und Zugriffsrechten

Zu den größten Schwachstellen in AWS-Umgebungen gehören schlecht konfigurierte Zugriffsrechte. Werden Berechtigungen zu großzügig vergeben, Zugangsdaten geteilt oder langlebige API-Schlüssel nicht rotiert, entsteht eine Angriffsfläche, die von Kriminellen systematisch ausgenutzt wird. Ohne konsequente Aufgabentrennung und fehlende Durchsetzung des Prinzips der minimalen Rechtevergabe reicht ein einziges kompromittiertes Konto aus, um weitreichenden Schaden anzurichten, beispielsweise durch Rechteausweitung oder Datenabfluss. Cyber-Kriminelle verbleiben dabei z. T. über sehr lange Zeiträume unbemerkt im System.

Konfigurationsfehler bei Cloud-Ressourcen

Fehlkonfigurationen von Cloud-Ressourcen gehören zu den häufigsten und folgenreichsten Sicherheitslücken in AWS-Umgebungen. Falsch gesetzte Zugriffsrechte auf S3-Buckets (Speicher), öffentlich zugängliche Verwaltungsoberflächen oder zu weitreichende Firewall-Regeln legen Systeme und Daten ungewollt offen. Dies geschieht in der Regel, weil einheitliche Konfigurationsstandards und automatisierte Kontrollen fehlen. Bereits ein einzelner falsch gesetzter Parameter genügt, um sensible Daten öffentlich zugänglich oder kritische Systeme von außen erreichbar zu machen.

Verwaltung von Geheimnissen

Die Konfiguration der Verwaltung von Geheimnissen stellt ein oft übersehenes Sicherheitsrisiko dar. Zugangsdaten für Dienstkonten, Zertifikate oder Schlüssel landen häufig im Quellcode, in Konfigurationsdateien oder in öffentlichen Repositorien und bieten Angreifern damit eine einfache Eintrittsmöglichkeit. Hinzu kommt häufig das Fehlen zentraler Mechanismen zum Rotieren und Entziehen von Berechtigungen. Werden Geheimnisse nicht geschützt und regelmäßig erneuert, ermöglichen kompromittierte Zugangsdaten potenziell einen zeitlich unbegrenzten Zugriff für Angreifer.

Netzstruktur

Oft sind Cloud-Netzwerke nicht logisch voneinander getrennt, sodass fehlende Unterscheidung zwischen Produktions-, Entwicklungs- und Managementnetzwerken dazu führen kann, dass ein erfolgreicher Angriff in einer weniger geschützten Umgebung schnell auf kritische Bereiche übergreift. Unzureichend abgesicherte Verbindungen zwischen Cloud und lokalen Systemen, etwa über VPN, erhöhen dieses Risiko zusätzlich. Erhält ein Angreifer zunächst nur Zugang zu einer Testumgebung, ermöglicht die fehlende Netztrennung häufig ein Vorrücken in andere Teile des Systems und kann damit weitaus größere Schäden zur Folge haben.

Monitoring

Fehlendes oder unzureichendes Monitoring erschwert die rechtzeitige Erkennung und Reaktion auf Sicherheitsvorfälle. Ohne zentrale Protokollierung und sinnvolle Alarmierungen werden Vorfälle oft erst bemerkt, wenn bereits erheblicher Schaden entstanden ist. Eine unveränderbare Ablage von Logs sowie automatische Analysen erleichtern die Aufklärung und beschleunigen Gegenmaßnahmen. Ebenso wichtig ist ein erprobtes Incident-Response-Konzept, das spezifische Cloud-Szenarien berücksichtigt.

 

Angriffsszenarien

Angreifer bedienen sich verschiedener Methoden, um Schwachstellen in der Konfiguration der AWS Cloud Umgebung auszunutzen. Anhand von konkreten Ereignissen der Vergangenheit sollen hier verschiedene Angriffsszenarien und die daraus resultierenden Konsequenzen beispielhaft dargestellt werden.

Bekannte Sicherheitsvorfälle mit weitreichenden Folgen waren unter anderem: 

Capital-One

Der Capital-One-Vorfall von 2019 gilt als einer der bekanntesten Cloud-Sicherheitsvorfälle überhaupt. Eine ehemalige Mitarbeiterin eines Cloud-Dienstleisters nutzte eine Fehlkonfiguration in einer Web Application Firewall aus (Konfigurationsfehler bei Cloud-Ressourcen), um auf temporäre AWS-Zugangsdaten zuzugreifen. Mit diesen Berechtigungen konnte sie Daten aus mehreren AWS-S3-Speichern auslesen. Dabei wurden personenbezogene Informationen von rund 106 Millionen Kundinnen und Kunden sowie Kreditkartenantragstellern in den USA und Kanada offengelegt, darunter Namen, Adressen, Bonitätsinformationen und teilweise Bankdaten. Der Vorfall führte zu hohen Bußgeldern, erheblichen Reputationsschäden für Capital One und machte deutlich, wie kritisch die sichere Konfiguration von Cloud-Diensten und Berechtigungen in AWS-Umgebungen ist. Die AWS-Plattform selbst wurde dabei nicht kompromittiert. Die Ursache lag in einer Fehlkonfiguration und dem Missbrauch gültiger Berechtigungen. (Referenz: Capital One Breach 2019: 106M Records | Cloudskope)

Code Spaces

Der Fall Code Spaces aus dem Jahr 2014 zählt zu den bekanntesten Beispielen dafür, welche Folgen die vollständige Übernahme eines AWS-Kontos haben kann. Ein Angreifer verschaffte sich Zugriff auf die Administrationskonsole des Unternehmens bei AWS und forderte anschließend Lösegeld. Die genaue Art wie der Angreifer Zugriff erlangte ist unbekannt. Es wird aber davon ausgegangen, dass gestohlene Zugangsdaten in Kombination mit fehlender MFA die wahrscheinlichste Ursache für den Zugriff waren.

Als das Unternehmen nicht auf die Forderungen einging, begann der Angreifer systematisch, virtuelle Server, Datenträger, Snapshots und Backups zu löschen. Obwohl Code Spaces über Sicherungsmechanismen verfügte, befanden sich viele dieser Sicherungen ebenfalls innerhalb des kompromittierten AWS-Kontos und konnten daher ebenfalls entfernt werden (Netzstruktur, Monitoring). Innerhalb weniger Tage verlor das Unternehmen einen Großteil seiner geschäftskritischen Infrastruktur und Kundendaten. Da eine Wiederherstellung nicht mehr möglich war, stellte Code Spaces den Geschäftsbetrieb vollständig ein. Der Vorfall gilt bis heute als Lehrbeispiel dafür, wie wichtig die Absicherung privilegierter Cloud-Konten (Verwaltung von Identitäten und Zugriffsrechten), eine strikte Rechteverwaltung sowie getrennte und unveränderbare Backups in Cloud-Umgebungen sind. (Referenz: AWS console breach leads to demise of service with “proven” backup plan - Ars Technica)

Cryptomining

In einem viel beachteten Fall aus dem Jahr 2021 wurden die Zugangsdaten eines AWS-Kontos kompromittiert (Verwaltung von Geheimnissen) und von Angreifern für Cryptomining missbraucht. Nach dem erfolgreichen Zugriff starteten die Täter zahlreiche leistungsstarke Cloud-Instanzen und betrieben darauf automatisiert das Mining der Kryptowährung Monero. Obwohl der tatsächliche Ertrag der Angreifer vergleichsweise gering war, verursachte die intensive Nutzung der Cloud-Ressourcen beim betroffenen Unternehmen eine AWS-Rechnung von rund 45.000 US-Dollar. Der Vorfall zeigt, dass bereits gestohlene oder unzureichend geschützte AWS-Zugangsdaten ausreichen können, um innerhalb kurzer Zeit erhebliche finanzielle Schäden zu verursachen, selbst wenn keine Daten entwendet oder Systeme zerstört werden. Ein zusätzliches Monitoring der laufenden Kosten (Monitoring) hätte an der Stelle zumindest den Schaden weiter eingrenzen können. (Referenz: Tom's Hardware – Hacker Uses AWS Resources to Mine Cryptocurrency, Leaves Victim With $45,000 Bill)


Maßnahmen

Zur Minimierung der Risiken empfehlen sich kompakte, praxisorientierte Maßnahmen:

  • Berechtigungen sollten konsequent nach dem Prinzip der geringsten Rechte vergeben und regelmäßig geprüft sowie Multi-Faktor-Authentifizierung für privilegierte Konten durchgesetzt werden.
  • Es sollten Automatisierung und Infrastructure-as-Code zur Vermeidung manueller Fehler genutzt, Geheimnisse zentral und sicher verwaltet sowie Logs zentral, unveränderbar ablegt und aktiv überwacht werden.
  • Dazu sollten eine frühe Einbindung von Sicherheit in Entwicklungs‑ und Betriebsprozesse sowie regelmäßige Audits und Penetrationstests eingebunden werden.
  • Organisatorisch sind klare Governance, definierte Verantwortlichkeiten, kontinuierliche Sensibilisierung des Personals und ein getestete Incident‑Response‑Playbooks entscheidend, damit technische Maßnahmen im Ernstfall wirksam greifen.


Zusammenfassung

Kurz gesagt: Die Integration von AWS bietet große Vorteile, erfordert aber ein Umdenken bei Sicherheit und Betrieb. Hauptprobleme sind oft unklare Zugriffsrechte, fehlerhafte Konfigurationen, mangelnde Netzwerktrennung, schwaches Geheimnismanagement und unzureichendes Monitoring. Angreifer nutzen diese Lücken für Kontoübernahmen, Datendiebstahl, seitliches Vorrücken und Ressourcenmissbrauch. Eine Kombination aus technischen Maßnahmen wie Least Privilege, MFA, Automation, zentralem Logging und Geheimnisverwaltung sowie organisatorischen Maßnahmen wie Governance, Schulung und Tests reduziert die Risiken deutlich.


Wir unterstützen Sie gerne bei der Bewertung und Absicherung Ihrer AWS-Umsetzung. Unsere Expertinnen und Experten führen Audits durch, erstellen Risikoanalysen und begleiten die Umsetzung praxisorientierter Maßnahmen, damit Ihre Cloud-Nutzung sicher und zuverlässig bleibt. Kolleginnen und Kollegen aus Ihren Teams können auf unsere Beratung zählen, um Sicherheitsanforderungen effizient umzusetzen.

Dieser Artikel wurde verfasst von