Die Public Cloud der Hyperscaler ist sowohl bei Entwicklern als auch Finanzchefs der Unternehmen beliebt. Die einen versprechen sich mehr Geschwindigkeit und Verlässlichkeit, die anderen niedrigere Kosten bei der Entwicklung und Bereitstellung von Apps. Gefährlich wird es jedoch, wenn fehlerhaft programmiert wird oder es keine durchdefinierten Prozesse gibt.
Fehlerhafte Konfigurationen bei Public-Cloud-Services können zu sogenannten Cloud-Native Breaches (CNB) führen und stellen ein massives Risiko für die unternehmensinterne Datensicherheit dar.
Den 6. August 2020 wird das Management von Capital One so schnell nicht vergessen. Das Office of the Comptroller of the Currency (OCC), eine Behörde des Finanzministeriums der USA, verhängte an diesem Tag eine zivilrechtliche Geldstrafe in Höhe von 80 Millionen Dollar gegen den US-amerikanischen Finanzdienstleister. Eine Hackerin hatte Capital One im Juli 2019 100 Millionen Kreditkartendaten gestohlen. Die Urteilsbegründung: Die Bank habe es versäumt, vor der Migration der IT in eine Public-Cloud-Umgebung wirksame Risikobewertungsprozesse einzurichten und Mängel nicht rechtzeitig behoben.
Datenverluste stark zunehmend
Auch wenn derart drastische Strafen eher selten sind: Datenverluste sind längst kein Einzelfall mehr. Die Liste der Unternehmen, die 2019 und 2020 von Datendiebstahl betroffen waren, liest sich wie das Who is Who der internationalen Wirtschaft: unter anderem EasyJet, Nintendo oder Marriott Hotel in 2020, Facebook, Microsoft oder Toyota im Jahr 2019. Entweder waren wie bei EasyJet oder MGM HotelsHacker am Werk oder einfach nur unzureichende Sicherheitsvorkehrungen implementiert, wodurch Externe auf ungeschützte Daten zugreifen konnten. Was aber auffällt: Die Zahl der Datenverluste hat seit 2020 massiv zugenommen. Und daran hat auch die Public Cloud einen signifikanten Anteil.
Es sind aber meist nicht die Public-Cloud-Anbieter selbst, die Hackern Tür und Tor öffnen. Eine Studie von McAfee zur Sicherheit von IaaS-Umgebungen: Ein großes Einfallstor für Hacker sind von den Cloud-Nutzern selbst fehlerhaft konfigurierte Systeme, die zudem auch noch über längere Zeiträume zu 99 Prozent unentdeckt bleiben. Noch gefährlicher: Selbst wenn Entwickler Fehlkonfigurationen identifizieren, bleibt mehr als ein Viertel der Probleme ungelöst, so die Ergebnisse der Studie – wobei die Fehlkonfigurationen von Infrastruktur ein höheres Risiko mit sich bringt als SaaS. Da der Anteil von Public-Cloud-Services beim IT-Sourcing der Unternehmen zunimmt, fehlt es ihnen häufig an ausreichendem Know-how, die Entwickler stehen unter hohem Zeitdruck, was die Fehlerquote in die Höhe treibt, oder es fehlt ihnen schlichtweg an Kapazitäten.
Typische Fehlkonfigurationen von IaaS-Nutzern bei AWS, die Cloud-native Breaches ermöglichen:
EBS-Datenverschlüsselung ist nicht aktiviert
Es gibt uneingeschränkten Zugang nach außen
Der Zugriff auf Ressourcen wird nicht über Identity and Access Management (IAM)-Rollen bereitgestellt
Erhöhte IAM-Privilegien für Benutzer oder Cloud-Ressourcen
Unverschlüsseltes Amazon Machine Image (AMI) wird entdeckt
Diese fehlerhaften Konfigurationen können zu sogenannten Cloud-Native Breaches (CNB) führen und stellen ein massives Risiko für die unternehmensinterne Datensicherheit dar. Die Täter nutzen native Funktionen der Cloud-Infrastruktur, um sich Zugriff zu verschaffen, den Angriff auf benachbarte Cloud-Instanzen auszuweiten und letztendlich auch wertvolle Daten abzugreifen. So ist laut McAfee-Studie die Anzahl der Datendiebstähle in IaaS-Umgebungen im vergangenen Jahr um 248 Prozent gestiegen.
Die Cloud-nativen Angriffe basieren also nicht auf Malware, sondern es handelt sich um gezielte Aktionen von Hackern, die Fehler oder Schwachstellen in einer Cloud-Umgebung ausnutzen. Sie nutzen schlecht konfigurierte Infrastruktur, dringen weiter in die Infrastruktur ein, lokalisieren wertvolle Daten, und ziehen diese Daten ab. Unter anderem sind laut einer Studie von Accurics schlecht konfigurierte Cloud-Storage-Dienste in 93 Prozent der Fälle an der Tagesordnung. Die meisten haben auch mindestens eine fehlerhafte Netzwerkkonfiguration, bei der eine Sicherheitsgruppe weit offengelassen wird.
Qualifiziertes Personal ist Mangelware
Unternehmen scheinen oft in die Wolke zu „stolpern“, ohne einen konkreten Sicherheitsansatz zu definieren. Ein weiterer Grund, neben zu wenig technischem Verständnis, ist der hohe Zeitdruck. Wer „Lift-and-Shift“-Migrationen durchführt und bestehende Sicherheitspraxis willkürlich anwendet, stößt meist auf Schwierigkeiten. In der Tat sind Cloud-Plattformen für viele Organisationen so neu, dass ihnen das Wissen und die Fähigkeiten fehlen, Konfigurationen zu implementieren, die denen in ihrer bestehenden Umgebung nahekommen. Oder ihre Praktiken sind möglicherweise einfach nicht für die Cloud geeignet. Ein dritter Grund ist, dass die Cloud sehr dynamisch ist, sich daher Konfigurationsoptionen sowie Implementierung kontinuierlich ändern und mehr Sorgfalt erfordern.
„Viele Organisationen wollen bei der Integration von IaaS möglichst wenig Zeit verlieren. Dabei vergessen sie oft, dass Cloud-Sicherheit auf einem Shared-Responsibility-Model basiert. Das bedeutet, dass nicht der Cloud-Provider allein für das Thema Sicherheit verantwortlich ist, sondern auch der Nutzer“, sagt Rolf Haas, Senior Enterprise Technology Specialist bei McAfee. „Wer sensible Daten in die Cloud bringt, muss sich selbst um deren Schutz kümmern. Im Hinblick auf die immer häufiger vorkommenden Cloud-Native Breaches müssen Organisationen daher Security-Tools in Stellung bringen, die selbst cloud-nativ sind und speziell für den Einsatz in Cloud-Umgebungen konzipiert wurden.“
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
Sicherheit durch automatisierte Konfigurationsskripte
Um diese offensichtliche Sicherheitsmisere zu beenden, bieten sich mehrere Strategien an. Ein leistungsstarkes Werkzeug ist die Automatisierung durch Standard-Konfigurationen und die Verwendung von Bereitstellungs- sowie Konfigurationsskripte, die die Möglichkeit von Fehlkonfigurationen verringern und die Implementierungs- sowie Qualitätsprüfungsrate verbessern. Die Automatisierung ermöglicht auch zusätzliche Überprüfungen und Audits, um Fehler zu reduzieren und die Sicherheit zu verbessern.
Entwickler sollten sich mit Sicherheitswerkzeugen befassen, die mit Jenkins, Kubernetes usw. integriert werden können, um die Audit- und Korrekturprozesse zu automatisieren. Durch die Überprüfung der Sicherheitspraktiken mit einem Rahmenwerk wie Land-Expand-Exfiltrate in Bezug auf die gesamte Angriffskette haben Unternehmen eine Chance, einen Cloud-native-Breach zu verhindern, bevor er außer Kontrolle gerät.
Was tun gegen Cloud-native Breaches:
1. Frühzeitige Integration einer IaaS-Konfigurationsprüfung - vorzugsweise beim Einchecken des Codes -, um Fehlkonfigurationen vor dem "Go-Live" zu minimieren.
2. Nutzung von Sicherheitswerkzeugen, die sich mit Jenkins, Kubernetes und anderen integrieren lassen, um den Prüfungs- und Korrekturprozess zu automatisieren.
3. Bewertung der IaaS-Sicherheitspraxis mit einem Framework wie "Land-Expand-Exfiltrate". Dies hilft, Kontrollen gegen die gesamte Angriffskette zu überprüfen.
4. Investition in Cloud-native Sicherheitswerkzeuge und Schulungen für Sicherheitsteams, da Sicherheitstools wie Cloud Access Security Brokers (CASBs) zusätzliches Wissen erfordern.
5. Einbindung externer IaaS- und Security-Experten, um das Know-how auch intern zu erweitern.
Spezielle Sicherheits-Tools für die Cloud
Ein weiterer Ansatz ist der Einsatz von Sicherheitstools. Allerdings funktionieren traditionelle Sicherheitswerkzeuge in Cloud-Umgebungen entweder überhaupt nicht oder nur mit eingeschränkten Funktionen. Hier bietet sich die Kombination von Cloud Access Security Brokers (CASBs), Cloud Security Posture Management (CSPM) und Cloud Workload Protection Platforms (CWPP) an. Alle genannten Tools sind so konzipiert, dass sie innerhalb von DevOps und CI/CD-Prozessen funktionieren, ohne die Sicherheit im Rechenzentrum vor Ort zu duplizieren. Eine weitere wichtige Sicherheitstechnologie ist die Verschlüsselung, die zusammen mit sicheren Schlüsselverwaltungsprozessen eine zusätzliche Schutzebene bieten kann.
Damit ließen sich dann Datenverluste wie die mehr als 275 Millionen Datensätze von Einwohnern Indiens im Mai 2019 verhindern. Sie waren ungeschützt auf einer MongoDB-Datenbank in der AWS-Cloud gespeichert. Oder die 380 Millionen Datensätze mit den Namen, E-Mail-Adressen, Telefonnummern, LinkedIn- und Facebook-Profilen von mehr als 1,3 Milliarden Personen, die auf ungeschützten Elasticsearch-Servern lagen.
Über den Autor: Paul Schöber ist Portfoliomanager Cloud Security bei T-Systems.