Alexandra - stock.adobe.com
Wenn Cloud-Migrationen zur tickenden Zeitbombe werden
Die Migration in die Cloud gilt als Schlüssel zu mehr Agilität und Effizienz. Doch oft entstehen im Prozess gravierende Sicherheitsdefizite – durch hausgemachte Fehler.
In den letzten Jahren hat sich viel am Bewusstsein für Cloud-Sicherheit getan. Immerhin 64 Prozent der Großkonzerne sehen Cloud-Security mittlerweile als eine ihrer Top 5-Prioritäten, laut einer Thales Studie. Circa 60 Prozent der Unternehmen dafür nutzen bereits mehr als fünf Erkennungs-Tools für Sicherheitsanwendungen, beispielsweise CSPM (Cloud Security Posture Management) und CWPP (Cloud Workload Protection Platform). Das bloße Erkennen von Sicherheitsvorfällen reicht jedoch längst nicht aus, wenn Cloud-Umgebungen komplexer werden.
In der Regel werden Daten in der Cloud standardmäßig bei der Speicherung (Encryption at Rest) verschlüsselt. Dabei ist jedoch oft nicht transparent, dass die Standardverschlüsselung mit Schlüsseln des Cloud-Anbieters erfolgt (provider-managed keys). Solange der Anbieter die Schlüsselhoheit besitzt, kann er – technisch gesehen – Daten grundsätzlich entschlüsseln, etwa im Rahmen von Support-, Betriebs- oder rechtlichen Prozessen.
Um die Vertraulichkeit wirklich unter eigener Kontrolle zu halten, liegt es in der Verantwortung des Unternehmens, eigenes Schlüsselmaterial zu erzeugen und zu verwalten. Nur so bleibt die Schlüsselhoheit und damit die Zugriffskontrolle beim Unternehmen.
Oft unterschätzen Unternehmen dabei die wachsende Komplexität moderner Architekturen. Daten werden durch Replikation, Skalierung und Microservices stärker verteilt, der Aufwand für Konfiguration und Schlüsselmanagement steigt. Mit jeder zusätzlichen Schnittstelle wächst die Angriffsfläche, besonders in hybriden Umgebungen oder bei Multi-Tenant-Strukturen. Wird Sicherheit in diesem Bereich nur als Nebensache betrachtet, öffnet das unbeabsichtigt die Hintertür.
Wo liegt die Verantwortung?
Doch noch bevor eine Cloud-Migration überhaupt startet, gibt es bereits ein häufig übersehenes Risiko. Dieses liegt bereits im Verständnis der Verantwortlichkeiten, wenn Unternehmen das Shared-Responsibility-Model falsch verstehen. Viele gehen davon aus, dass der Cloud-Anbieter auch die Sicherheit von Anwendungen und Daten garantiert. Tatsächlich beschränkt sich die Verantwortung des Providers aber auf die Infrastruktur. Alles darüber hinaus – Zugriffsrechte, Applikationen, Datenverschlüsselung – liegt beim Kunden.
Fehlinterpretationen dieses Modells sind eine der Hauptursachen für Vorfälle wie offene Cloud-Buckets oder ungesicherte APIs. Sie entstehen nicht aus komplexen Angriffsszenarien, sondern aus falschen Annahmen im Projektalltag. Unternehmen, die hier keine klare Governance und Verantwortlichkeiten von Anfang an schaffen, geraten in eine gefährliche Grauzone, in der schließlich niemand Verantwortung übernimmt. Dies ist ein Faktor, der im Vorfeld klar werden muss.
Migration ohne Schutzbedarfsanalyse
Geht es an die Migration, werden viele unter Zeitdruck oder mit einem klaren Kostensparfokus umgesetzt. In dieser Dynamik fällt oft der Schritt weg, der für Sicherheit entscheidend ist: die Schutzbedarfsanalyse. Dabei geht es darum, Daten nach Vertraulichkeit, Integrität, Verfügbarkeit und regulatorischer Relevanz zu klassifizieren.
Jörn Wellniak,
BettercallPaul
Ohne diese Analyse werden kritische Assets nicht sauber identifiziert. Das führt dazu, dass hochsensible Daten mit denselben Maßnahmen behandelt werden wie unkritische Systeme. Eine sichere Migration setzt voraus, dass diese Klassifizierung vor Beginn der technischen Umsetzung abgeschlossen ist. Nur so lassen sich Sicherheitskonzepte wie Zero Trust, Least-Privilege oder Netzsegmentierung gezielt anwenden.
Fehlende Verzahnung von Teams
Vor, während und nach der Migration, müssen CIO, CISO, DevOps, Fachbereiche und Datenschutzverantwortliche zusammenarbeiten, denn Sicherheit entsteht nicht in isolierten Abteilungen. Jeder bringt eine notwendige Perspektive ein: Infrastruktur, Prozesse, regulatorische Anforderungen, Bedrohungslage für das System.
Die Systemanalyse im Überblick
Eine Sicherheitsanalyse erfolgt in mehreren Schritten. Aus dem Fachbereich und der Enterprise Architektur kommen Informationen zur Businesskritikalität der Systeme. In größeren Unternehmen gibt es für die Ermittlung einen eigenen Prozess in dem Fachbereiche CIO, Datenschutzverantwortliche und Enterprise Architektur die zuständigen Stakeholder sind. Aus der Systemarchitektur kommen dann Informationen zu System, Kontext und Umsystemen sowie Schnittstellen der Systeme. Diese Information ist wichtig, um Auswirkungen von Sicherheitsvorfällen abschätzen zu können. Die Applikationsarchitektur steuert weitere Informationen bei, wie interne Strukturen und Schnittstellen. Security-Experten werten diese Informationen aus, erstellen ein Bedrohungspotenzial zum Beispiel unter Verwendung einer Angriffsvektoranalyse und führen Penetrationstests durch. Die Ergebnisse werden dann neben der Applikationsarchitekturebene auch wieder in System und Enterprise-Architektur gespiegelt.
Dies passiert idealerweise über zentrale Architekturdokumentationstools, damit auch weitere Beteiligte in dem Prozess Zugriff auf die Informationen haben. Auf Systemebene werden dann die Auswirkungen auf Umsysteme analysiert, besonders interessant ist hier auch die Analyse von Datenflüssen (Datalineage), um Auswirkungen von korrumpierten Daten abzuschätzen. Auf dieser technischen Risikoeinschätzung wird auf Enterprise-Architekturebene wieder auf die Business-Capabilities gespiegelt. Sowohl auf technischer als auch auf Businessebene beschäftigt sich diese Analyse mit zwei Aspekten: Eintrittswahrscheinlichkeit und Auswirkung. Für Eintrittswahrscheinlichkeit sind Fragen relevant wie:
- Wie lohnend ist der Angriff auf das System?
- Wie einfach ist es möglich, welches Skillset ist erforderlich?
- Wie weit ist das Wissen über den Exploit verbreitet?
- Um Auswirkungen abzuschätzen, beschäftigt man sich mit Fragen wie:
- Werden durch den Angriff Daten geleakt?
-wenn ja: Welche Daten (Datenklassifikation, personenbezogen)? - Welche Services fallen aus?
- Wie aufwendig ist es, Datenmanipulation zu entdecken?
Daraus ergibt sich für jede der beiden Dimensionen eine Einschätzung (Hoch, Mittel, Niedrig). Aus einer Matrix daraus kann man abschätzen, wie kritisch es ist, die Lücke zu schließen.
Hat man Risiken beziehungsweise. Handlungsbedarf in einzelnen Systemen gefunden, so ist der nächste Schritt eine detaillierte Analyse basierend auf den gesammelten Informationen, hierfür bietet sich Threat Modeling als Methode an.
Der Prozess durchläuft sechs Schritte:
- Identifizierung von Systemgrenzen und Shared-Responsibility-Grenzen, denn diese bieten die nötige Angriffsfläche.
- Identifizierung von Systemkomponenten: diese Analyse basiert größtenteils auf Architekturdokumenten wie Komponenten-, Kommunikations- Deployment-Diagrammen, Schnittstellenspezifikationen, Datenflussdiagrammen
- Identifizierung der Angreifer(-gruppen).
- Identifizierung von Bedrohungspotenzialen (Threats): Es gibt hier verschiedene Frameworks: STRIDE, PASTA, MITRE ATT&CK, LINDDUN, Attack Trees. Diese unterscheiden sich im Detailgrad und Fokus, so legt LINDDUN Fokus auf Privacy, MITRE ATTA&CK ist sehr gut für eine detaillierte (low-level) Betrachtung, dagegen sind Attack Trees sehr zielorientiert und strukturiert durch das Herunterbrechen der Angriffsvektoren in einer Baumstruktur.
- Identifizierung von sogenannten Security Controls als Gegenmaßnahmen. Hier gibt es zwei Gruppen Maßnahmen, die eine Erkennung ermöglichen oder vereinfachen und präventive Gegenmaßnahmen. Als Leitlinie können hier Security Control Auflistungen von BSI, CERT oder NIST herangezogen werden.
- Priorisierung der Controls.
Cloud-Hardening und Compliance als Daueraufgabe
Mit dem Go-Live endet die Sicherheitsarbeit nicht. Cloud-Hardening ist ein kontinuierlicher Prozess. Im letzten Abschnitt haben wir gezeigt, wie unterschiedliche Bereiche zusammenarbeiten müssen, um zu einer Risikoeinschätzung zu gelangen, und basierend darauf kann man dann die nächsten Schritte (Verbesserungen, unmittelbarer Inzident Response) festlegen. Voraussetzungen dafür sind ein Change-Management, Rollenmanagement, Shared-Resonsibility-Models, Netzwerksegmentierung, sowie ein identitätsbasierten Zugriffsschutz für die Cloud-Infrastruktur, um die Applikation sicherzustellen. Im laufenden Betrieb sollten einerseits durch kontinuierliches Monitoring, Logging (SIEM), Updates, Secrets-Management und Security-as-Code systeminterne Faktoren verbessert und abgesichert werden, jedoch gerade mit Blick auf Secure-by-Design sollten auch äußere Faktoren miteinbezogen werden: Änderungen am Businessmodell, Änderungen an der Einstufung der Bedrohungslage, Änderung und neue Techniken um Systeme anzugreifen. Um diesen äußeren Faktoren entgegenzuwirken, sollte die Risikoanalyse (siehe oben) periodisch ausgeführt werden.
Leopold Kühschelm,
BettercallPaul
Hinzu kommen regulatorische Anforderungen, die sich je nach Branche unterscheiden. Besonders der Umgang mit personenbezogenen Daten muss sensibel betrachtet werden: Schon eine kleine Lücke kann zu DSGVO-Verstößen und Millionenschäden führen. Hier lohnt sich frühzeitiges Dokumentieren und die nachvollziehbare Implementierung von Sicherheitsmaßnahmen, sodass ein Unternehmen im Ernstfall nicht nur besser geschützt, sondern auch audit-ready ist.
Der Mensch als Schwachstelle und Chance
Neben Technik und Regulierung bleibt der Mensch der entscheidende Faktor. Studien belegen, dass ein Großteil der Sicherheitsvorfälle auf Fehlkonfigurationen, mangelnde Awareness oder unzureichende Schulungen zurückzuführen ist. Während einer Migration steigt dieses Risiko: Prozesse ändern sich, neue Tools müssen beherrscht, alte Systeme parallel weitergeführt werden.
Unternehmen sollten deshalb kontinuierliche Security-Awareness-Programme etablieren, die weit über einmalige E-Learnings hinausgehen. Automatisierte Prüfungen, integrierte Sicherheitsassistenten und klare Verantwortlichkeiten helfen, menschliche Fehler abzufangen. In vielen Cloud-Umgebungen sind bereits entsprechende Tools für Laufzeitanalysen für die Infrastruktur und zur Auswertung von Compliance Regeln integriert. Alternativ können Unternehmen auf Open Source Anbieter setzen. Für Standards wie HIPAA oder PCI DSS existieren vordefinierte Regelsets, manuelle Checklisten wie der NIST Security Control Katalog unterstützten praxisnah. Security muss als Haltung von der Führungsebene bis zum Systemadministrator in der Organisation zu verankert sein. Denn selbst die beste technische Architektur scheitert, wenn sie nicht gelebt wird.
Fazit: Sicherheit als Basis, nicht als Zusatz
Cloud first, Security last: Wer Sicherheit nur als nachgelagerte Aufgabe betrachtet, riskiert nicht nur Systemausfälle, sondern auch langfristige Reputations- und Compliance-Schäden.
Erfolgreiche Migrationen beginnen mit einer konsequenten Schutzbedarfsanalyse, klar definierten Verantwortlichkeiten und einer engen Zusammenarbeit aller Beteiligten. Sie setzen auf kontinuierliches Hardening, berücksichtigen regulatorische Rahmenbedingungen und stärken das Sicherheitsbewusstsein der Mitarbeitenden.
Cloud und Sicherheit sind keine Gegensätze. Sie bedingen einander. Wenn Sicherheit von Anfang an integriert wird, schafft dies nicht nur stabile Systeme, sondern auch die Grundlage für nachhaltige digitale Transformation.
Über die Autoren:
Jörn Wellniak ist Principal Project Manager und Leopold Kühschelm Senior Software Architect bei BettercallPaul. Beide sind auf Cloud-Architekturen spezialisiert und übersetzen komplexe Anforderungen in tragfähige Architekturen sowie praxisnahe Ergebnisse.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
