Cloud-Native Breaches (CNB) Gefährliche Sicherheitslücken im Cloud-Code

Von Paul Schöber |

Anbieter zum Thema

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.
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.
(Bild: gemeinfrei / Pixabay)

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 Hotels Hacker 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
  • Öffentlich zugängliche Cloud-Ressourcen
  • VPC-Flussprotokolle sind deaktiviert

Cloud-Fehler erhöhen die Risiken

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

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

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.

(ID:46922226)