Cloud Vision & Strategie

Aktuelle Trends, Insights und praxisnahe Tipps

Fundiertes Fachwissen aus der Praxis für Sie zusammengefasst

Strategische Leitfäden und Insights aus der Praxis

Lift & Shift war gestern: Warum einfaches Migrieren oft nicht reicht

Viele Unternehmen starten ihren Weg in die Cloud mit einem Wunsch: schnelle Migration, günstige Umsetzung und unkomplizierter Einstieg. Alle Workloads sollen einfach in die Cloud übertragen werden und schon ist die Migration abgeschlossen. Danach folgt dann jedoch oft die Ernüchterung: Die Kosten steigen, die Systeme laufen langsamer als erwartet und wirklich flexibel ist das neue Modell auch nicht. Hintergrund dafür ist oft die Migration nach dem Lift & Shift Ansatz. Was es damit auf sich hat, wo der Ansatz an seine Grenzen kommt und wie eine durchdachtere Strategie aussehen kann, erklären wir in diesem Artikel.

Was ist Lift & Shift und warum setzen so viele Unternehmen darauf?

Die Lift & Shift Methode beschreibt eine Cloud-Migrationsstrategie, bei der bestehende IT-Systeme ohne größere Änderungen aus der On Premises Umgebung in die Cloud übertragen werden. Das System bleibt wie es ist und wird einfach verschoben. Damit ist dieser Ansatz der unkomplizierteste und schnellste in der Cloud-Migration. In einigen Szenarien ist es durchaus sinnvoll, Workloads mit dem Lift & Shift Ansatz zu migrieren:

Workloads ähneln den Cloud-nativen Alternativen.
Ein System läuft nur noch kurze Zeit und die Investition in eine Modernisierung würde sich nicht rentieren.
Ein Rechenzentrum wird abgeschaltet und es bleibt wenig Zeit für eine Modernisierung der Workloads.
Das Unternehmen möchte erste Erfahrungen mit der Cloud sammeln, ohne sofort viel umzubauen.

Vor allem als temporäre Lösung oder bei sehr simplen Workloads kann Lift & Shift sinnvoll sein. Als dauerhafter Zustand entstehen dadurch jedoch fast immer Probleme. Die Cloud ist kein eins zu eins Ersatz für ein Rechenzentrum, sondern zeigt ihre Vorteile dann, wenn Cloud-native Ansätze zum Einsatz kommen.

Cloud-Migration ohne Strategie: diese Probleme können entstehen

Verschieben Unternehmen ihre IT-Infrastruktur unverändert in die Cloud, verschieben sie auch alle Probleme mit. In der Cloud können diese Probleme jedoch deutlich teurer werden als noch zuvor in der On Premises Umgebung.

Höhere Betriebskosten als erwartet

Im eigenen Rechenzentrum läuft der Server rund um die Uhr, die Kosten dafür sind in der Regel fix. In der Cloud sind die Kostenmodelle meist komplexer: Oft handelt es sich um Pay-as-you-go-Modelle oder monatliche Abonnements, deren Kosten von der tatsächlichen Nutzung abhängen. Systeme, die nicht auf die Cloud ausgelegt sind, lassen sich jedoch nicht abhängig von der Nutzung skalieren und laufen dauerhaft auf Hochtouren. Daraus ergibt sich am Monatsende eine höhere Rechnung als die vorherige Servermiete.

Alte Strukturen in moderner Umgebung

Cloud-Umgebungen bieten zahlreiche Möglichkeiten: automatisches Hoch- und Runterskalieren bei Lastspitzen, integrierte Sicherheitsfunktionen und einfaches Testen neuer Features. Übertragen Unternehmen ihre Infrastruktur per Lift & Shift jedoch unverändert in die Cloud, entfallen häufig einige der zentralen Vorteile:

Anwendungen reagieren bei hoher Last nicht flexibel, weil sie dafür nie gebaut wurden.
Sicherheitslücken und mögliche Schwachstellen werden aus dem alten Rechenzentrum mit migriert und erhöhen das Risiko in der Cloud.
Kostenvorteile der Cloud entfallen, da Anwendungen mehr Ressourcen verbrauchen als native Infrastruktur.

Zwar erscheint der Lift & Shift Ansatz anfangs oft günstiger als Neuentwicklungen oder Anpassungen, der Weg sorgt allerdings häufig für höheren Kosten und dafür, dass Vorteile der Cloud nicht ausgeschöpft werden können.

Vom Lift & Shift Ansatz zur nachhaltigen Cloud-Strategie

Eine funktionierende Cloud-Migrationsstrategie beginnt mit einer Frage: Was soll die Cloud für das Unternehmen leisten? Je nach Antwort unterscheiden sich die nächsten Schritte stark.

Drei Wege in die Cloud

In der Praxis kommen meist verschiedene Wege zum Einsatz, abhängig vom jeweiligen Workload und den Zielen. Diese drei finden besonders häufig Anwendung.

Lift & Shift: Das System wandert unverändert in die Cloud. Dieser Weg ist der schnellste und günstigste, bringt aber die thematisierten Einschränkungen mit sich.
Replatforming: Das System wird leicht modernisiert, um grundlegende Cloud-Vorteile nutzen zu können, zum Beispiel automatische Datensicherung oder bessere Skalierung.
Refactoring: Die Anwendung wird grundlegend überarbeitet oder neu entwickelt, damit sie die Vorteile der Cloud vollständig ausnutzen kann.

Welcher Weg der richtige ist, hängt vom jeweiligen System, dem Zeitrahmen und dem Budget ab. Nicht jede Anwendung muss vollständig neu gebaut werden, aber Unternehmen sollten jede Anwendung bewusst einordnen.

Was eine gute Cloud-Strategie ausmacht

Unabhängig vom gewählten Migrationspfad braucht es einige Grundlagen, damit die Cloud langfristig Vorteile schafft:

Klare Verantwortlichkeiten: Wer darf was in der Cloud tun, wer hat welche Zugriffsrechte? Ohne Regeln entstehen schnell Sicherheitslücken und zusätzliche Kosten.
Kostentransparenz: Cloud-Kosten sind variabel. Frameworks wie FinOps sind sinnvoll, um die Kosten im Blick zu halten, sie zu steuern und zu optimieren.
Souveränität: Achten Unternehmen von Anfang an darauf, souveräne Lösungen einzusetzen, bleiben sie unabhängiger von einzelnen Anbietern und Veränderungen in Leistungen oder geopolitischen Gegebenheiten.

Fazit: Lift & Shift ist Start und Ergänzung, keine vollständige Strategie

Lift & Shift ist grundsätzlich kein falscher Ansatz, sondern ein guter Weg für simple Anwendungen oder den ersten Start in der Cloud. Grundsätzlich gilt aber: Verschieben Unternehmen Systeme einfach in die Cloud, ohne ihre Eignung zu prüfen und sie anzupassen, entgehen ihnen die Vorteile nativer Cloud-Anwendungen und die Kosten können in die Höhe schnellen. Für eine bedachte Migration sollten Systeme deshalb immer bewusst eingeordnet, klare Ziele definiert und Schritt für Schritt modernisiert werden. Dieser Weg braucht zwar Planung, sorgt aber am Ende für eine saubere Cloud-Infrastruktur, in der die Vorteile voll ausgenutzt werden können.

Kerberos Authentifizierung Änderungen 2026

2026 verschärft Microsoft die Standards für Kerberos in Active Directory: Die veraltete RC4-Verschlüsselung wird schrittweise deaktiviert. Ziel ist es, bekannte Risiken zu reduzieren und die Sicherheitslücke CVE-2026-20833 zu adressieren. Mit den Sicherheitsupdates des ersten Halbjahres im Jahr 2026 wird das Standardverhalten am Key Distribution Center (KDC) phasenweise angepasst. Ohne saubere Vorbereitung kann das zu Authentifizierungsfehlern und Zugriffsproblemen führen.

Der Artikel gibt Ihnen einen kompakten Überblick und zeigt, wie Sie Ihr Unternehmen rechtzeitig dafür prüfen und vorbereiten können.

Was wird sich bei Kerberos ändern?

Um die Änderung einordnen zu können, lohnt sich ein Blick ins Jahr 2022: Damals hat Microsoft ein grundlegendes Standardverhalten definiert. Microsoft steuert die zulässigen Kerberos-Verschlüsselungsalgorithmen über zwei Registry-Einträge: Der eine steuert das domänenweite Standardverhalten (DefaultDomainSupportedEncTypes) und der andere (msds-SupportedEncryptionTypes) steuert das Verhalten dezidiert für Computer und Serverdienste. Mit den Updates aus 2022 und 2026 ändert sich jeweils der implizite Standardwert von DefaultDomainSupportedEncTypes. Wenn man einen anderen Wert möchte, muss man ihn explizit setzen. Der KDC orientiert sich immer dann an DefaultDomainSupportedEncTypes, wenn msds-SupportedEncryptionTypes entweder nicht gesetzt oder 0 entspricht. Beide Werte bestimmen den genutzten Verschlüsselungsalgorithmus für die Kerberos Anmeldung. Das Key Distribution Center ist die Steuerzentrale für das Active Directory und übernimmt die Rolle eines Türstehers, der den Einlass kontrolliert.

Vereinfacht gesagt: vor 2022 akzeptierte der KDC entweder RC4 oder AES – je nachdem, was angefragt wurde. Seit 2022 gilt implizit ein Default von 0x27. Ab 2026 wird der Standardwert auf 0x18 gesetzt.

Wert	Übersetzung	Bewertung
0x18	AES-128, AES-256	✅
0x27	DES, RC4, AES-256-SK	❌
0x1C	RC4, AES-128, AES-256	⚠️
0x1F	DES, RC4, AES-128, AES-256	❌

Supported encryption type

Wird der Standard auf 0x18 gesetzt, können ältere Systeme oder alte Konfiguration scheitern, wenn Sie auf RC4 angewiesen sind. Der KDC erlaubt nur Algorithmen, die effektiv erlaubt sind.

Betriebssystem	DES_CBC_CRC	DES_CBC_MD5	RC4_HMAC_MD5	AES128_HMAC_SHA1	AES256_HMAC_SHA1
Windows 2003, Windows XP und älter	Supported	Supported	Supported	No support	No support
Windows Vista	Supported	Supported	Supported	Supported	Supported
Windows 2008	Supported	Supported	Supported	Supported	Supported
Windows 2008R2	Deactivated	Deactivated	Supported	Supported	Supported
Windows 7	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2012	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2012R2	Deactivated	Deactivated	Supported	Supported	Supported
Windows 10	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2016	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2022	Deactivated	Deactivated	Supported	Supported	Supported
Windows 11	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2025	No support	No support	Deactivated	Supported	Supported

Supported Windows versions

Die automatische Umsetzung wird über den im Januar 2026 eingeführten Wert RC4DefaultDisablementPhase gesteuert. Je nachdem, wie dieser eingestellt ist, werden RC4 Versuche zugelassen, blockiert oder protokolliert.
Bei aktiviertem RC4DefaultDisablementPhase wird AES zum Standard und setzt damit DefaultDomainSupportedEncTypes implizit auf den Wert 0x18. Bei einem aktivierten Audit Wert werden Meldungen generiert, die die fehlende Unterstützung kenntlich machen.
Eine vorzeitige Überprüfung Ihrer Umgebung ist daher dringendst zu empfehlen. Nach Abschluss der Umstellung wird RC4 für Kerberos in einer Active Directory Umgebung deaktiviert und daher erstmal nicht mehr nutzbar sein.

Microsoft unterteilt die Umstellung in drei Phasen:

Visualisierung der drei Update Phasen für Kerberos Änderung

Phase 1 (Audit Phase)

Die erste Phase ist die Audit Phase. In dieser Phase werden zusätzliche Telemetriedaten und Events eingeführt, um Probleme zu identifizieren, bevor die Durchsetzung greift. Ziel ist es, die RC4-Abhängigkeiten sichtbar zu machen und erforderliche Anpassungen rechtzeitig umzusetzen. Optional kann die Deaktivierung von RC4 bereits in dieser Phase manuell vorgezogen werden. Eine vorzeitige Deaktivierung sollte dennoch unbedingt vorab geprüft werden, da sie ansonsten zu Authentifizierungsabbrüchen und damit zu Dienstunterbrechungen führen kann. Für die Auswertung der Events bietet sich eine zentrale Stelle zur Protokollanalyse an (bspw. über Windows Eventlog Forwarding oder SIEM). Die Event ID’s 201-209, 4768-4769 sind zu prüfen.

Phase 2 (Enforcement with manual rollback)

In der zweiten Phase wird der Standard von RC4 auf AES automatisch gesetzt. Diese Umstellung kann noch rückgängig gemacht werden. Diese Phase ist die letzte Phase, in der Administratoren noch die Flexibilität haben, RC4DefaultDisablementPhase zurückzudrehen. Bevor es zur dritten Phase geht, sollte sichergestellt werden, dass kein Gerät mehr auf RC4 angewiesen ist, da ansonsten die Authentifizierung fehlschlägt.

Phase 3 (Enforcement)

Die dritte Phase ist die letzte Phase. In dieser Phase gibt es kein einfaches Entrinnen mehr. Die Durchsetzung greift ein und deaktiviert RC4. Eine Reaktivierung über RC4DefaultDisablementPhase ist dann nicht mehr möglich. Wenn Sie diese Phase überstanden haben und Ihre Serverdienste weiterhin laufen, haben Sie gute Arbeit geleistet.

Hintergrund: Kerberos AES und RC4

Beides sind weitverbreitete Verschlüsselungsalgorithmen. RC4 war lange Bestandteil von vielen Softwares, da es im Vergleich zu AES effizienter und eine größere Abwärtskompatibilität gewährleistet.

Der Rivest Cipher 4 (RC4) Verschlüsselungsalgorithmus ist kryptografisch unsicher und kann durch sogenannte „Roasting Attacken“ wie dem Kerberoasting ausgenutzt werden. Hierbei fordert ein Angreifer ein Kerberos Ticket an und „brute forced“ offline das Passwort des Authentifizierungstickets. Gelingt es, das Passwort zu knacken, sind u.a. weitergehende Ticket-Manipulation wie dem Silver Ticket möglich, um sich Zugriff auf Dienste zu verschaffen.

Muss ich bei Kerberos handeln?

Sie müssen handeln, wenn Sie eine Active Directory oder Hybrid-Umgebung nutzen. Sobald sich ein Legacy Gerät im Netzwerk befindet und das Update eingespielt wird, schlägt die Kerberos Authentifizierung fehl und es kommt zu einem Fallback zu NTLM. Bei NTLM gibt es ganz andere Angriffsvektoren, die zu beheben sind. Wenn Sie NTLM bereits erfolgreich unterbunden haben, schlägt die Anmeldung grundlegend fehl. Ggf. müssen Sie regulatorische Anforderungen (wie NIS2, DORA, ISO/IEC 27001 etc.) nachkommen und wollen daher beim Audit glänzen. Das können Sie nur, wenn Sie RC4 deaktivieren und AES die Bühne geben.

Was sollte ich jetzt machen?

Um obiges kurz und knapp zusammenzufassen, hier eine Handlungsempfehlung zu der bevorstehenden technischen Umstellung seitens Microsofts. Es ist wichtig, dass Sie sich unbedingt vorab ein Bild Ihrer Umgebung machen. Die Umstellung findet automatisch statt und kann im schlimmsten Fall den Zugriff auf Serverdienste einschränken.

Prüfen, ob Domain Function Level auf mind. Windows Server 2008 ist. Wenn drunter → unbedingt handeln.
Prüfen, ob Legacy Systeme benutzt werden. Unter Legacy Systemen zählen Windows Server 2003 / Windows XP und älter → unbedingt handeln.
Prüfen, ob Service Accounts (normale User & gMSA) genutzt werden → normale User durch gMSA ersetzen. RC4 bei gMSA ausschalten.
Jeder Domain Controller ist auf dem gleichen Windows Update Stand von Januar 2026.
Auf den Domain Controller sind die Events ID 201-209 im SYSTEM LOG zu prüfen.

Bei Fragen oder Anregen zum Thema Active Directory oder Kerberos Authentfizierung stehen wir Ihnen gerne beratend zur Seite. Wir freuen uns auf Ihre Kontaktaufnahme.