Warum 'Lift and Shift' in regulierte Clouds meist scheitert
Was "Lift and Shift" verspricht — und wo das Versprechen bricht
Die Rechnung klingt einfach: Server-Images abziehen, in der Cloud neu starten, Rechenzentrum abschalten. "Lift and Shift" verspricht schnelle Migration ohne Umbau der Anwendungen, ohne teure Refactorings, ohne monatelange Projekte. Für viele IT-Leitungen in regulierten Unternehmen ist das der pragmatische Einstieg — und genau dort beginnt das Problem.
In regulierten Umgebungen — Banken, Versicherungen, KRITIS-Betreiber — scheitert die 1:1-Migration selten an der Technik. Sie scheitert daran, dass sie das gewachsene Risiko- und Kontrollmodell unverändert übernimmt. Was on-prem funktioniert hat, trägt in der Cloud nicht automatisch. Und was in Ihren Audits als Nachweis galt, existiert in der Cloud in dieser Form oft gar nicht mehr.
Risiko wandert mit — es verschwindet nicht
Eine 1:1-Migration reduziert kein Risiko. Sie verlagert es. Die Fehlkonfiguration, die im eigenen Rechenzentrum hinter mehreren Netzwerkschichten kaum ausnutzbar war, liegt in der Cloud plötzlich an einer ganz anderen Angriffsfläche. Der veraltete Dienst, der on-prem nie öffentlich erreichbar war, hängt nach dem Umzug an einer Umgebung, deren Standardannahmen anders sind.
Hinzu kommt: Sie fügen neue Angriffsflächen hinzu. Cloud-Steuerungsebene, Identitäts- und Zugriffsmanagement, API-Endpunkte, Konfiguration von Netzwerk und Speicher — all das existierte on-prem so nicht oder lag in anderer Verantwortung. Nicht die Cloud-Plattform selbst ist die häufigste Schwachstelle, sondern deren Konfiguration durch die Kunden. Branchenprognosen gehen seit Jahren davon aus, dass ein Großteil der Cloud-Sicherheitsvorfälle auf kundenseitige Fehlkonfigurationen zurückgeht, nicht auf Fehler des Anbieters. Wer sein System unverändert hinüberhebt, ohne die neue Kontrolllogik zu verstehen, migriert seine Schwachstellen mit — und ergänzt sie um neue.
Compliance greift in der Cloud anders
Seit dem 6. Dezember 2025 ist das deutsche NIS-2-Umsetzungsgesetz in Kraft. § 30 BSIG setzt Artikel 21 der NIS-2-Richtlinie um und verpflichtet besonders wichtige und wichtige Einrichtungen zu technischen und organisatorischen Risikomanagementmaßnahmen, die geeignet, verhältnismäßig und wirksam sein müssen. Der Katalog nennt mindestens zehn Maßnahmenbereiche — unter anderem Risikoanalyse, Bewältigung von Sicherheitsvorfällen, Backup- und Krisenmanagement, Zugriffskontrolle und die Sicherheit der Lieferkette einschließlich der Beziehungen zu Dienstleistern und Anbietern.
Genau dieser letzte Punkt ist in der Cloud entscheidend. Denn mit dem Umzug übernehmen Sie nicht die vollständige Kontrolle über die Infrastruktur — Sie teilen sie. Im Modell der geteilten Verantwortung liegt die Sicherheit der zugrundeliegenden Infrastruktur beim Anbieter, während Sie als Kunde für Betriebssystem, Anwendungen und die Konfiguration der bereitgestellten Sicherheitsmechanismen verantwortlich bleiben. AWS beschreibt das ausdrücklich so: Wer eine EC2-Instanz betreibt, verantwortet das Gast-Betriebssystem samt Updates und Patches, die installierte Software und die Konfiguration der bereitgestellten Firewall — der Security Group — je Instanz (AWS Shared Responsibility Model).
Für die Nachweisführung heißt das: Ihre gewohnten Artefakte verschieben sich. Der Nachweis der Netzwerksegmentierung war on-prem vielleicht ein Firewall-Regelwerk und ein Netzplan. In der Cloud wird daraus eine Kombination aus Konfigurationszuständen, Identitätsrichtlinien und automatisiert erfassten Belegen. Auch die Meldepflichten sind konkret: Sicherheitsvorfälle sind dem BSI innerhalb enger Fristen zu melden — eine frühe Erstmeldung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und ein Abschlussbericht nach spätestens einem Monat. Diese Fristen setzen voraus, dass Sie Vorfälle in der Cloud überhaupt zeitnah erkennen und belegen können — was ohne angepasste Protokollierung und Überwachung nicht gegeben ist. Details zu den Pflichten führt das BSI auf seiner Seite für NIS-2-regulierte Unternehmen aus.
Ein konzeptionelles Beispiel: Netzwerksegmentierung
Nehmen Sie die Netzwerksegmentierung. On-prem denken Sie in Zonen: ein DMZ-Segment, ein internes Segment, ein hochsicheres Backend-Segment, getrennt durch Firewalls und teils durch physische Grenzen. Die Kontrolle ist topologisch — der Standort eines Systems im Netz bestimmt, womit es sprechen darf.
Übertragen Sie diese Logik 1:1 in die Cloud, bilden Sie die Zonen als Subnetze nach und versuchen, dieselbe topologische Trennung zu erzwingen. Das funktioniert oberflächlich — führt aber in die Irre. In der Cloud ist die primäre Kontrolle nicht mehr der Standort im Netz, sondern die Identität und die Konfiguration. Security Groups arbeiten pro Instanz und lassen sich an Identitäten und Ressourcen-Merkmale koppeln, nicht nur an Subnetzgrenzen. Wer die alte Zonen-Logik nachbaut, verschenkt genau die Kontrolltiefe, die die Cloud bietet — und behält zugleich die Sprödigkeit der alten Struktur. Segmentierung, die on-prem als starres Regelwerk gepflegt wurde, wird in der Cloud zu einer Frage sauberer, überprüfbarer Konfiguration.
Dieselbe Verschiebung gilt für Workloads, die Sie containerisiert oder orchestriert betreiben. Wer bestehende Anwendungen in Container packt und in einen verwalteten Kubernetes-Cluster hebt, überträgt oft implizite Annahmen über Netzwerk, Rechte und Isolation, die im neuen Kontext nicht mehr gelten. Auch hier reduziert der reine Umzug kein Risiko — er verlagert es auf eine Ebene, deren Kontroll- und Nachweismechanismen neu verstanden werden müssen.
Vorgehens-Heuristik: vier Schritte vor der Migration
Statt zu diagnostizieren, was schiefgeht, hier eine nüchterne Reihenfolge, die sich in der Praxis bewährt:
1. Kontrollmodell vor Workload klären. Bestimmen Sie zuerst, welche Kontrollen (Segmentierung, Zugriff, Protokollierung, Nachweis) in der Zielumgebung wie umgesetzt werden — bevor die erste Instanz migriert. Das Kontrollmodell ist die Blaupause, nicht die Anwendung.
2. Nachweispflichten auf Cloud-Artefakte abbilden. Gehen Sie Ihre § 30 BSIG-relevanten Maßnahmen durch und legen Sie je Maßnahme fest, welches Cloud-Artefakt künftig als Nachweis dient. Was Sie nicht belegen können, gilt im Zweifel als nicht umgesetzt.
3. Geteilte Verantwortung explizit machen. Ziehen Sie für jede migrierte Komponente die Grenze zwischen Anbieter- und Kundenverantwortung. Dokumentieren Sie, welche Konfiguration in Ihrer Hand liegt — und wer sie prüft.
4. Fehlkonfiguration als Standardrisiko behandeln. Etablieren Sie vor dem Umzug automatisierte Prüfungen der Konfiguration gegen etablierte Baselines (etwa CIS Benchmarks). So fangen Sie den häufigsten Vorfalltyp ab, bevor er produktiv wird.
Wo Sie ansetzen können
Der erste Schritt ist keine Migration, sondern eine ehrliche Standortbestimmung: Wie reif sind Ihre Kontrollen für Software-Entwicklung und containerisierte Workloads wirklich? Unser kostenloser SDLC & Kubernetes Security Selbst-Check führt Sie durch 64 gewichtete Kontrollen und liefert einen Reifegrad von 0 bis 4. Der Check läuft vollständig lokal in Ihrem Browser, es verlassen keine Daten Ihr Gerät, und das Ergebnis lässt sich als Bericht exportieren.
Wer vor oder mitten in einer Cloud-Migration steht, gewinnt damit eine belastbare Ausgangslage — bevor aus verschobenem Risiko ein meldepflichtiger Vorfall wird.