Zusammenfassung
Die gefährlichste Annahme in Cloud-Migrationsprojekten ist, dass mit der Infrastruktur auch die Sicherheitsverantwortung an den Anbieter übergeht. Gartners vielzitierte Prognose — „bis 2025 werden 99 % der Cloud-Sicherheitsfehler kundenverursacht sein" — hat sich in der Praxis bestätigt: Die Infrastruktur der großen Cloud-Anbieter wird selten gebrochen; gebrochen werden die Lücken, die der Kunde im eigenen Verantwortungsbereich lässt.[1]
Auch die Kostenseite zeigt in dieselbe Richtung. Laut IBMs Cost of a Data Breach Report 2025 liegen die globalen Durchschnittskosten einer Datenschutzverletzung bei 4,44 Millionen US-Dollar; Verletzungen, die Daten über mehrere Umgebungen hinweg betreffen, liegen über dem Durchschnitt.[2] Der markante Befund aus IBMs Bericht von 2023 schärft das Bild: 82 % der untersuchten Verletzungen betrafen in der Cloud gespeicherte Daten.[3] Nach Flexeras Untersuchung nutzen rund 89 % der Organisationen mehr als eine Cloud — diese Risikofläche ist also kein Problem eines einzelnen Anbieters, sondern der Inkonsistenz zwischen Umgebungen.[4]
Dieser Bericht untersucht die am häufigsten missverstandene Schicht des Shared-Responsibility-Modells: Application Delivery und Schutz. Er öffnet die Verantwortungsmatrix Schicht für Schicht, listet die Konfigurationsfehler der Anwendungsschicht auf, die wir in der Praxis am häufigsten sehen, und analysiert, warum Policy Drift in Hybrid-Umgebungen die am wenigsten bemerkte Lücke ist.
Die Cloud-Sicherheitslücke in Zahlen
Anteil der Kunden an Cloud-Sicherheitsfehlern (Gartner-Prognose)
Globaler Durchschnitt (IBM 2025)
Anteil an den untersuchten Verletzungen (IBM 2023)
Organisationen mit mehr als einer Cloud (Flexera)
Das Modell ist einfach — seine Auslegung nicht
Das Shared-Responsibility-Modell selbst ist nicht komplex: Der Anbieter ist für die Sicherheit der Cloud verantwortlich, der Kunde für die Sicherheit dessen, was in der Cloud liegt. Die Komplexität entsteht daraus, dass sich die Grenze mit dem Servicemodell verschiebt — und dass Organisationen diese Grenze höher vermuten, als sie tatsächlich liegt. In IaaS gehört ab dem Betriebssystem alles dem Kunden; in PaaS geht die Plattform an den Anbieter über, die Anwendungskonfiguration aber nicht; selbst in SaaS bleiben Datenklassifizierung, Zugriffsrichtlinien und Identitätskonfiguration beim Kunden.
Der entscheidende Punkt ist: Unabhängig vom Modell geht die Kontrolle über den Traffic zu Ihrer Anwendung — wer zugreift, welche Anfrage legitim ist, welche Daten nach außen gehen — niemals auf den Anbieter über. Der Anbieter kann Ihnen Werkzeuge bereitstellen; die Verantwortung übernimmt er nicht.
Die Verantwortungsmatrix: Schicht für Schicht
| Schicht | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physische Infrastruktur und Hypervisor | Anbieter | Anbieter | Anbieter |
| Netzwerkkontrollen | Geteilt | Geteilt | Anbieter |
| Betriebssystem und Middleware | Kunde | Anbieter | Anbieter |
| Anwendung und Traffic-Policies | Kunde | Kunde | Geteilt |
| Daten, Identität und Zugriffskonfiguration | Kunde | Kunde | Kunde |
Die häufigsten Fehler der Anwendungsschicht in der Praxis
Die Fehler, die Cloud-Sicherheitsverletzungen speisen, sind nicht exotisch; dieselben Muster wiederholen sich. In den Bedrohungsranglisten der Cloud Security Alliance stehen Fehlkonfiguration und unzureichende Änderungskontrolle seit Jahren weit oben.[5] Was wir in der Praxis am häufigsten sehen:
Im Erkennungsmodus vergessene WAF
WAF-Policies, die während der Migration „zur Beobachtung" in den Erkennungsmodus geschaltet wurden, werden in der Hektik des Go-live nie in den Schutzmodus überführt. Die Organisation glaubt sich geschützt; die WAF erzeugt nur Logs.
Zu weit gefasste Netzwerkregeln
Zur Fehlersuche geöffnete, breite NSG-/Security-Group-Regeln werden dauerhaft. „Vorübergehende" 0.0.0.0/0-Ausnahmen lassen nicht inventarisierte Management-Endpunkte offen im Internet stehen.
Unverschlüsselter Traffic nach der Terminierung
TLS wird am Load Balancer terminiert, im internen Netz fließt der Traffic im Klartext. Das Konzept „internes Netz" ist in der Cloud durchlässiger als im Rechenzentrum; unverschlüsselter Ost-West-Traffic ist die leiseste Lücke in Ihrem Verantwortungsbereich.
API-Endpunkte außerhalb des Inventars
Jeder in die Cloud migrierte Microservice erzeugt neue API-Endpunkte. Unentdeckte Endpunkte ohne Schema bleiben außerhalb der WAF-Abdeckung; Angreifer lieben undokumentierte Endpunkte mehr als dokumentierte.
Regelabweichung zwischen Umgebungen
Das über Jahre on-premises feinjustierte Regelwerk wird in der Cloud „näherungsweise" auf eine andere Engine übersetzt. Zwei Engines entscheiden über dieselbe Anfrage unterschiedlich; welche Umgebung richtig liegt, weiß niemand.
Identität auf Standardwerten
Conditional Access, MFA-Erzwingung und Sitzungsrichtlinien bleiben — „zur späteren Härtung" — auf den Standardwerten. Die Identität hat in der Cloud den Netzwerkperimeter abgelöst; eine Standard-Identitätskonfiguration bedeutet eine Standard-Perimetermauer.
Die häufigste hybride Sicherheitslücke ist kein CVE, sondern ein Prozessfehler: im Rechenzentrum gereift, in der Cloud auf Standardwerten. Während die On-Premises-Kopie derselben Anwendung hinter einer strengen WAF-Policy steht, läuft die Cloud-Kopie monatelang mit dem Basis-Signaturset. Angreifer scannen beide Kopien und dringen über die schwächere ein. Policy Drift korrigiert sich nicht von selbst; solange sie nicht gemessen wird, wächst sie.
Die wahren Kosten hybrider Komplexität
Zwei getrennte WAF-Engines zu betreiben bedeutet nicht nur zwei Lizenzen. Es bedeutet zwei Regelsprachen, zwei Ausnahmelisten, zwei Testprozesse, zwei Sätze von Audit-Nachweisen und zwei getrennte Kompetenzprofile. Das Sicherheitsteam entwirft jede Änderung zweimal, testet sie zweimal, dokumentiert sie zweimal. Diese kognitive Last zeigt sich genau in den kritischsten Momenten — während der Incident Response: Die Antwort auf die Frage, welche Regel in welcher Umgebung aktiv war, kostet dann nicht Minuten, sondern Stunden.
Auf der Audit-Seite sind die Kosten noch sichtbarer. PCI DSS, KVKK/DSGVO und branchenspezifische Regulierungen verlangen für jede Umgebung im Audit-Scope eigene Nachweise. Denselben Schutz in zwei verschiedenen Produkten auf zwei verschiedene Arten nachzuweisen, vervielfacht die Audit-Vorbereitungszeit; Inkonsistenz-Befunde entstehen meist aus Auslegungsunterschieden zwischen den beiden Produkten.
Multi-Cloud vergrößert dieses Bild nicht linear, sondern multiplikativ. Flexeras Daten zeigen, dass die große Mehrheit der Organisationen mehr als eine Cloud nutzt;[4] jede neue Umgebung bringt einen neuen Satz nativer Sicherheitsdienste und eine neue Konfigurationssprache mit. Mit steigender Zahl der Umgebungen wird der Anspruch „derselbe Schutz in jeder Umgebung" unhaltbar, solange er auf Werkzeug-Ebene statt auf Policy-Ebene verankert ist.
Implikationen für die Verteidigung
Erstellen Sie ein Datenfluss-Inventar
Welche Anwendung läuft in welcher Umgebung, berührt welche Daten, und wer kontrolliert den Traffic? Ohne Inventar bleibt die Verantwortungsmatrix Papier.
Halten Sie die Verantwortungsmatrix schriftlich fest
Dokumentieren Sie für jedes Servicemodell die Grenze zwischen Anbieter und Kunde explizit und lassen Sie keine Schicht unbesetzt. Verifizieren Sie die Annahme „das übernimmt der Anbieter" mit einer schriftlichen Zusage.
Etablieren Sie eine einzige Policy-Ebene
Betreiben Sie denselben Kontrollsatz — dieselbe WAF-Engine, dieselbe Regelsprache, denselben Ausnahmeprozess — in jeder Umgebung. Entfällt die Regelübersetzung, ist Policy Drift strukturell ausgeschlossen.
Sorgen Sie für Ende-zu-Ende-Verschlüsselung und Sichtbarkeit
Erzwingen Sie TLS nicht nur am Edge, sondern auch im Ost-West-Traffic; prüfen Sie verschlüsselten Traffic, ohne blinde Flecken zu lassen.
Validieren Sie kontinuierlich
Testen Sie die Policy-Parität nicht einmal im Jahr beim Audit, sondern kontinuierlich: Dieselbe Anfrage muss in jeder Umgebung dieselbe Entscheidung erhalten. Eine Abweichung sollte kein Audit-Befund sein, sondern ein Alarm.
Der TR7-Ansatz: Derselbe Schutz in jeder Umgebung
TR7s Antwort auf dieses Bild ist der Betrieb derselben Plattform in jeder Umgebung:
Dasselbe Image im Azure Marketplace
Die virtuelle TR7-Plattform wird im Azure Marketplace als fertiges Image angeboten; in der Cloud läuft dieselbe Engine wie auf der Hardware.
Policy-Portabilität
WAF-Regeln, SSL/TLS-Profile und Zugriffsrichtlinien wandern ohne Regelübersetzung zwischen den Umgebungen; eine Ausnahmeliste, ein Satz von Audit-Nachweisen.
Lizenzportabilität
Lizenzen sind an die Organisation gebunden, nicht an die Plattform; sie wandern mit dem Workload zwischen Azure, GCP und den unterstützten Hypervisoren.
Hybrides Traffic-Management
GTM routet zwischen On-Premises- und Cloud-Standbeinen auf Basis von Gesundheit, Geografie und Latenz und bildet das Rückgrat einer schrittweisen Migration.
Referenzen & Quellen
Quelle der Prognose „bis 2025 werden 99 % der Cloud-Sicherheitsfehler kundenverursacht sein". https://www.gartner.com/smarterwithgartner/is-the-cloud-secure
Primärquelle für die globalen Durchschnittskosten einer Datenschutzverletzung (4,44 Millionen US-Dollar) und die Kostenaufschlüsselung nach Umgebung. https://www.ibm.com/reports/data-breach
Befund, dass 82 % der untersuchten Verletzungen in der Cloud gespeicherte Daten betrafen.
Jährliche Untersuchung zu Multi-Cloud-Adoptionsraten und Cloud-Strategien von Unternehmen. https://www.flexera.com/blog/cloud/cloud-computing-trends-flexera-state-of-the-cloud-report/
Bedrohungsrangliste, in der Fehlkonfiguration und unzureichende Änderungskontrolle weit oben stehen. https://cloudsecurityalliance.org/research/top-threats
Offizielle Dokumentation der Verantwortungsgrenzen zwischen Anbieter und Kunde nach Servicemodell. https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility
Derselbe Schutz in jeder Umgebung
Sie müssen die Sicherheitsschicht bei der Cloud-Migration nicht neu aufbauen. TR7 überträgt die Schutz- und Delivery-Policies aus Ihrem Rechenzentrum mit derselben Engine nach Azure und liefert eine einzige Policy-Ebene, eine einzige Verwaltung und einen einzigen Satz von Audit-Nachweisen.
WAAP-Lösung entdecken