Alte Schwachstellen in neuer Umgebung – was Cloud-Apps unsicher macht

Lift-and-Shift mit Risiken: Cloud-Migration ohne Sicherheitsstrategie

Viele Unternehmen migrieren bestehende Anwendungen unreflektiert in die Cloud („Lift-and-Shift“), in der Hoffnung auf mehr Sicherheit durch die neue Umgebung. Doch ein ungünstig konfiguriertes oder verwundbares System bleibt auch in der Cloud verwundbar. Wird eine Applikation unverändert in die Cloud gehoben, nimmt man alle ungepatchten Schwachstellen gleich mit. Laut Experten können solche übersehenen Lücken in der Cloud sogar größeren Schaden anrichten, da dort oft höhere Vernetzung besteht. Ein Beispiel: Ein unentdeckter SQL-Injection-Bug in einer On-Premise-Datenbank ist in einer isolierten Umgebung vielleicht begrenzt – in der Cloud, mit direkter Web-Exponierung und Anbindung an weitere Dienste, kann derselbe Bug zum Einfallstor mit weitreichenden Folgen werden. Daher gilt: Vor der Cloud-Migration sollten Anwendungen sicherheitstechnisch überprüft und modernisiert werden. Einfaches Lift-and-Shift ohne Refactoring kann dazu führen, dass man Altlasten in neuer Umgebung mit sich schleppt – ein trügerisches Sicherheitsgefühl, das im Ernstfall teuer werden kann.

Geteilte Verantwortung: Was Cloud-Anbieter und Kunde jeweils absichern

Ein verbreiteter Irrglaube ist, der Cloud-Provider erledige schon alle Security – dem ist nicht so. Die großen Cloud-Anbieter (AWS, Azure, Google) verfolgen das Modell der Shared Responsibility: Sie sichern die Cloud-Infrastruktur ab (Rechenzentren, Netzwerk, Hardware, Hypervisor usw.), während der Kunde für alles verantwortlich bleibt, was in der Cloud betrieben wird – also eigene Daten, Anwendungen, Betriebssysteme und Zugänge. Diese Aufgabenteilung wird oft missverstanden. Manche Kunden wiegen sich in falscher Sicherheit und glauben, „die Cloud ist so sicher, ich muss nichts mehr tun“. Tatsächlich bleiben aber wesentliche Aspekte – etwa Konfiguration der Zugriffsrechte, Verschlüsselung der gespeicherten Daten, Absicherung von VMs oder Containern – voll in Kundenhand. Werden diese Pflichten vernachlässigt, entstehen gefährliche Lücken. Cloud-Sicherheitsvorfälle gehen häufig auf Kundenfehler zurück, etwa öffentlich zugängliche Speichercontainer oder schwache Passwörter für Cloud-Accounts. Um Cloud-Apps sicher zu betreiben, muss man die geteilte Verantwortung verstehen und aktiv wahrnehmen. Der Cloud-Anbieter bietet viele Security-Werkzeuge an – nutzen muss sie der Kunde.

DevSecOps: Sicherheit von Anfang an mitdenken

Anwendungen für die Cloud sollten nicht erst am Schluss auf Sicherheit geprüft werden, sondern vom ersten Entwicklungsschritt an. Genau hier setzt DevSecOps an: Sicherheitsprüfungen und -tools werden in jede Phase der Softwareentwicklung und des Deployments integriert. So werden Schwachstellen früh erkannt und behoben, bevor die Anwendung produktiv geht. Der Vorteil: Findet man einen Fehler in der Code-Phase, ist er viel einfacher und günstiger zu fixen als nach dem Rollout. DevSecOps bedeutet praktisch z.B., dass Code-Repositorys automatisiert auf Sicherheitslücken gescannt werden, Container-Images vor dem Einsatz geprüft und Infrastruktur-Konfigurationen (IaC) lückenfrei gestaltet sind. Studien betonen, dass ein Shift-Left-Ansatz – also Testen und Absichern so weit links (früh) wie möglich in der Pipeline – Entwicklungsabläufe beschleunigen und sicherer machen kann. Denn ein später Sicherheitstest birgt das Risiko von Verzögerungen oder umfangreichen Nacharbeiten. Mit DevSecOps dagegen werden Sicherheitstests parallel zum Entwickeln durchgeführt, oft automatisiert in CI/CD-Pipelines. Dies führt zu einem kontinuierlichen Feedback über den Sicherheitsstatus eines Projekts. Die Dev- und Ops-Teams erhalten frühzeitige Warnungen und können nachjustieren, bevor ein Problem groß wird. Kurz: Sicherheit wird integraler Bestandteil der agilen Entwicklung – Quality Gates beinhalten Sicherheitskriterien – und nicht mehr als lästige Hürde am Ende gesehen.

Fehlkonfigurationen: Das unsichtbare Einfallstor in der Cloud

Cloud-Umgebungen sind flexibel – aber auch komplex. Ein häufiger Fehler sind Fehlkonfigurationen, z.B. versehentlich öffentlich zugängliche S3-Buckets, offene Datenbanken ohne Passwort oder falsch gesetzte Zugriffsrechte. Solche Konfigurationslücken sind ein unsichtbares Einfallstor: Angreifer scannen gezielt Cloud-Ressourcen auf eben solche Schnitzer. Gartner schätzt, dass rund 80% aller Datenpannen auf Fehlkonfigurationen zurückgehen. Zudem wird prognostiziert, dass bis 2025 bis zu 99% aller Cloud-Sicherheitsvorfälle vom Kunden (also durch Fehlbedienung oder Fehlkonfiguration) verursacht werden – nicht durch Versagen des Anbieters. Ein klassisches Beispiel war eine Reihe von Vorfällen, bei denen zig Millionen Datensätze offen im Internet landeten, weil Cloud-Speicher nicht korrekt abgesichert waren. Angriffswerkzeuge dafür sind trivial: Es gibt Suchmaschinen und Skripte, die nach offenen Cloud-Ports und -Buckets suchen und so jedermann zugängliche Daten finden. Cloud Security Alliance nennt Fehlkonfiguration „ein kritisches Risiko in Echtzeit“. Es entsteht oft durch die Komplexität moderner Multi-Cloud-Setups und manuelle Fehler. Ein simpler Konfigurationsfehler – etwa Standardpasswort nicht geändert, oder „öffentlich“ statt „privat“ angeklickt – kann so Hackern den roten Teppich ausrollen. Daher sind strikte Konfigurationsstandards, regelmäßige Audits und automatisiertes Cloud Security Posture Management (CSPM) essenziell, um diese oft unsichtbaren Lücken zu schließen. Fehlkonfigurationen sind tückisch, weil sie keinen „Bug“ im Code darstellen, sondern Bedienfehler – aber eben genauso gefährlich.

APIs und Container: Neue Angriffsflächen moderner Anwendungen

Moderne Cloud-Anwendungen setzen stark auf Microservices, APIs und Containerisierung. Dadurch entstehen neue Angriffsflächen. Öffentliche APIs etwa stellen Einfallstore dar, wenn sie nicht ausreichend abgesichert sind. Tatsächlich berichten nahezu 99% der Unternehmen über Sicherheitsprobleme mit ihren APIs im letzten Jahr – von Schwachstellen bis zu Datenlecks. In einer Umfrage gaben 22% an, sogar eine Datenpanne erlebt zu haben, bei der APIs ausgenutzt wurden. Das zeigt, wie kritisch API-Security ist. Häufige API-Probleme sind unzureichende Authentifizierung, Über-Berechtigungen (APIs geben mehr Daten preis als nötig) oder fehlendes Rate Limiting, was Angriffe erleichtert. Gleichzeitig hat die Nutzung von Containern und Kubernetes stark zugenommen. Doch nicht selten hapert es an deren Absicherung: Container Images enthalten oft bekannte Schwachstellen oder werden ohne neueste Patches betrieben. Eine Sicherheitsstudie 2023 ergab, dass knapp die Hälfte der Unternehmen Sicherheitsvorfälle in ihren Container/Kubernetes-Umgebungen hatte – deutlich mehr als im Vorjahr. Besonders Runtime-Angriffe auf Container nahmen zu. Beispiele dafür sind Container-Escape-Angriffe oder das Einbringen von Malware in öffentliche Container-Registry-Images. Zudem bieten die zahlreichen APIs moderner Applikationen – ob REST, GraphQL etc. – ein weites Feld für Angreifer, von Injection-Attacken bis Account Takeover durch schwache API-Keys. All dies erfordert angepasste Sicherheitsmaßnahmen: Etwa API-Gateways und Web Application Firewalls mit spezialisierten API-Schutzfunktionen, regelmäßiges Container Image Scanning, sowie strikte Netzwerk-Segmentierung zwischen Containern (Zero-Trust-Netzwerk fürs Cluster). APIs und Container sind zweifelsohne Treiber der Digitalisierung – aber eben auch der Bedrohungslandschaft, wenn sie ohne „Security by Design“ eingeführt werden.

 

Relevante Referenzen:

• Gartner (2023): Cloud Misconfigurations responsible for data breaches – Gartner Research, Cloud Security Report (2023)
• Cloud Security Alliance (CSA): Critical Real-time Risks of Cloud Misconfigurations – Cloud Security Alliance – Top Threats to Cloud Computing (2023)
• AWS/Azure/Google Cloud: Shared Responsibility Model explained – Amazon AWS Shared Responsibility Model (2024)
• Microsoft Azure Security Documentation (2024) – Google Cloud Security Whitepaper (2024)
• OWASP: Top Security Risks for APIs and Microservices (2023) – OWASP API Security Top 10 (2023)
• Red Hat / CNCF: Kubernetes Security Trends – CNCF Kubernetes Security Report (2023)
• Sysdig Security Report: Container Security Trends and Risks – Sysdig Cloud-Native Security Report (2023)
• IBM / Ponemon Institute: Cost of Data Breach Report, DevSecOps & Shift-Left Approach – IBM Cost of a Data Breach Report (2023)