Risikoanalyse für Cloud-Migrationen: Wie wir kritische Infrastruktur in Österreich absichern

Wer die Stromversorgung für hunderttausende Haushalte oder die Patientenaufnahme im AKH Wien in die Cloud verlagert, ohne vorher systematisch Risiken zu bewerten, fliegt blind. Genau das beobachten wir in der Praxis immer wieder: Cloud-Migrationen werden als IT-Projekt behandelt, nicht als sicherheitskritische Transformation. Dabei entstehen neue Angriffsflächen, Abhängigkeiten und regulatorische Pflichten, die ohne strukturierte Risikoanalyse schlicht übersehen werden. In diesem Beitrag zeigen wir, wie wir bei seccrit.eu Risikoanalysen für Cloud-Migrationen kritischer Infrastruktur in Österreich aufsetzen – von der Bedrohungsmodellierung über Anomalieerkennung bis zur Resilienzmessung.

Warum eine Risikoanalyse vor jeder Cloud-Migration unverzichtbar ist

Kritische Infrastruktur in Österreich – etwa die Stromnetze der Austrian Power Grid oder Krankenhäuser wie das AKH Wien – ist historisch gewachsen, stark reguliert und auf hohe Verfügbarkeit ausgelegt. Eine Cloud-Migration verändert dieses Fundament grundlegend: Daten und Prozesse verlassen das eigene Rechenzentrum, Abhängigkeiten zu Hyperscalern entstehen, und die Angriffsfläche verschiebt sich von der Perimeter-Sicherheit hin zu Identitäten, APIs und Konfigurationen.

Seit 2024 fordert die NIS2-Richtlinie von Betreibern kritischer Infrastruktur deutlich strengere Sorgfaltspflichten – insbesondere im Risikomanagement, in der Lieferkettensicherheit und bei der Meldung von Vorfällen. Ohne dokumentierte Risikoanalyse fehlt nicht nur die Grundlage für technische Schutzmaßnahmen, sondern auch der Nachweis gegenüber der Aufsicht. Im schlimmsten Fall drohen Betriebsunterbrechungen, Bußgelder und der Verlust der Versorgungssicherheit.

Neue Bedrohungen durch Cloud-Abhängigkeiten

Mit der Cloud kommen Bedrohungen, die es im klassischen Rechenzentrum so nicht gab: fehlkonfigurierte S3-Buckets, kompromittierte API-Schlüssel, Identitätsdiebstahl über föderierte Anmeldungen oder Angriffe über die Supply Chain eines SaaS-Anbieters. Fällt ein Cloud-Region-Rechenzentrum aus oder ändert ein Anbieter seine AGB, hat das unmittelbare Auswirkungen auf die Verfügbarkeit kritischer Dienste.

NIS2-Anforderungen an österreichische Betreiber kritischer Infrastruktur

Die NIS2-Richtlinie verlangt ein risikobasiertes Management von Cybersicherheit, regelmäßige Schulungen der Geschäftsleitung, die Absicherung von Lieferketten und klare Meldefristen bei Vorfällen. Für österreichische Betreiber bedeutet das: Wer Cloud-Dienste einkauft, muss deren Risiko bewerten, vertraglich absichern und in das eigene Sicherheitsmanagement integrieren – nicht nur technisch, sondern auch organisatorisch und rechtlich.

Die fünf Schritte unserer Risikoanalyse-Methodik

Wir arbeiten mit einem praxisnahen, wiederholbaren Ablauf, der sich an bewährten Frameworks wie ISO 27005 und dem BSI-Standard 200-3 orientiert. Der Ablauf lässt sich in fünf Schritte gliedern:

1. Asset-Inventar und Datenklassifizierung
2. Bedrohungsmodellierung (STRIDE)
3. Schwachstellenanalyse
4. Risikobewertung nach Eintrittswahrscheinlichkeit und Auswirkung
5. Maßnahmenplanung mit Verantwortlichkeiten und Fristen

Asset-Inventar und Datenklassifizierung

Am Anfang steht die Frage: Was migrieren wir überhaupt? Wir erfassen Anwendungen, Datenbestände, Schnittstellen und Abhängigkeiten – und klassifizieren sie nach Schutzbedarf. Patientendaten im Krankenhaus unterliegen anderen Anforderungen als Telemetriedaten eines Netzleitsystems. Diese Klassifizierung bestimmt später, welche Daten überhaupt in die Cloud dürfen und welche on-premises bleiben müssen.

Bedrohungsmodellierung mit STRIDE

Mit STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) modellieren wir systematisch, welche Angriffe auf die migrierten Komponenten realistisch sind. Für einen Netzbetreiber bedeutet das etwa, gezielt Szenarien wie Man-in-the-Middle auf Steuerungsprotokolle oder Denial-of-Service auf Cloud-APIs durchzuspielen.

Schwachstellenanalyse und Risikobewertung

Wir kombinieren technische Scans, Konfigurationsprüfungen und Architektur-Reviews, um Schwachstellen zu identifizieren. Anschließend bewerten wir jedes Risiko nach Eintrittswahrscheinlichkeit und Auswirkung – und priorisieren Maßnahmen dort, wo die Versorgungssicherheit am stärksten gefährdet ist.

Anomalieerkennung als Frühwarnsystem für Cloud-Sicherheit

Eine Risikoanalyse ist die Grundlage, aber sie wirkt nur, wenn wir laufend erkennen, wenn etwas aus dem Rahmen fällt. Genau hier kommt Anomalieerkennung ins Spiel: KI- und ML-basierte Systeme lernen normale Zugriffs- und Nutzungsmuster in der Cloud und schlagen Alarm, wenn Abweichungen auftreten – etwa ein nächtlicher Massenexport von Patientendaten oder ein ungewöhnlicher API-Zugriff aus einer fremden Region.

Wie Anomalieerkennung in der Cloud funktioniert

Moderne Cloud-Plattformen liefern umfangreiche Telemetrie: Login-Ereignisse, API-Aufrufe, Netzwerkflüsse, Konfigurationsänderungen. Anomalieerkennung analysiert diese Datenströme kontinuierlich und erkennt Abweichungen vom Normalverhalten. Für österreichische KRITIS-Betreiber sind Tools wie Microsoft Sentinel oder AWS GuardDuty besonders relevant, weil sie sich in bestehende Cloud-Umgebungen integrieren und Bedrohungen wie kompromittierte Identitäten oder Datenexfiltration frühzeitig melden.

Integration in bestehende SIEM-Lösungen

Viele Betreiber kritischer Infrastruktur in Österreich betreiben bereits ein SIEM. Wir integrieren Anomalieerkennung als zusätzliche Detektionsschicht und korrelieren Cloud-Ereignisse mit Ereignissen aus dem eigenen Rechenzentrum. So entsteht ein einheitliches Lagebild, das auch für NIS2-Meldewege nutzbar ist.

Resilienz messen: Kennzahlen und Tests für Cloud-Migrationen

Resilienz ist keine Eigenschaft, die man behauptet, sondern eine, die man messen muss. Wir definieren klare Kennzahlen und validieren sie durch kontrollierte Tests – bevor der Ernstfall eintritt.

RTO, RPO und MTTR richtig interpretieren

RTO (Recovery Time Objective) beschreibt, wie lange ein System maximal ausfallen darf. RPO (Recovery Point Objective) legt fest, wie viel Datenverlust akzeptabel ist. MTTR (Mean Time To Repair) misst die durchschnittliche Wiederherstellungsdauer. Für einen Netzbetreiber wie die Austrian Power Grid sind diese Werte nicht theoretisch, sondern bestimmen, ob die Versorgung aufrechterhalten werden kann.

Chaos Engineering und Notfallübungen

Mit Chaos-Engineering-Tests simulieren wir kontrolliert Ausfälle – etwa das Abschalten einer Cloud-Region oder das Blockieren eines Netzwerkpfads – und prüfen, ob die definierten RTO- und RPO-Werte tatsächlich eingehalten werden. Für österreichische KRITIS-Betreiber sind regelmäßige Notfallübungen nach NIS2 verpflichtend, und wir dokumentieren die Ergebnisse so, dass sie gegenüber der Aufsicht belastbar sind.

Rechtliche und organisatorische Fallstricke in Österreich

Neben der Technik gibt es in Österreich eine Reihe rechtlicher und organisatorischer Besonderheiten, die wir in jeder Cloud-Migration berücksichtigen müssen.

DSGVO und Datenresidenz in der Cloud

Die DSGVO und das österreichische Datenschutzgesetz (DSG) setzen den rechtlichen Rahmen. Bei personenbezogenen Daten – etwa Patientendaten im AKH Wien – ist entscheidend, wo diese verarbeitet werden und wie der Zugriff durch Dritte geregelt ist. Datenresidenz in der EU ist oft Pflicht, nicht Option.

NIS2-Umsetzung in Österreich: NISG und Zuständigkeiten

In Österreich wird NIS2 durch das Netz- und Informationssystemsicherheitsgesetz (NISG) umgesetzt. Die Rundfunk und Telekom Regulierungs-GmbH (RTR) fungiert als zuständige Stelle für NIS2, während das Bundesministerium für Inneres (BMI) in bestimmten Sicherheitsfragen mitwirkt. Ein häufiger Fallstrick: unklare Verantwortlichkeiten zwischen Cloud-Anbietern und Betreibern. Wir helfen, diese Verantwortlichkeiten vertraglich und organisatorisch sauber zu trennen.

Unser Fazit: Risikoanalyse als kontinuierlicher Prozess

Eine einmalige Risikoanalyse vor der Cloud-Migration reicht nicht aus. Bedrohungen verändern sich, Cloud-Dienste werden aktualisiert, regulatorische Anforderungen steigen. Deshalb integrieren wir Risikoanalyse als wiederkehrenden Zyklus in die Unternehmensprozesse – mit regelmäßigen Reviews, aktualisierten Bedrohungsmodellen und kontinuierlicher Anomalieerkennung. Nur so bleibt Cloud-Sicherheit für kritische Infrastruktur in Österreich langfristig gewährleistet.

Risikoanalyse ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Wer ihn ernst nimmt, sichert nicht nur Cloud-Sicherheit, sondern auch NIS2-Konformität und Resilienz – nachhaltig und überprüfbar.

Häufige Fragen (FAQ)

Warum ist eine Risikoanalyse vor einer Cloud-Migration für kritische Infrastruktur verpflichtend?

Weil Cloud-Migrationen neue Angriffsflächen und Abhängigkeiten schaffen und die NIS2-Richtlinie – in Österreich umgesetzt durch das NISG – strenge Sorgfaltspflichten im Risikomanagement vorschreibt. Ohne dokumentierte Analyse fehlt der Nachweis gegenüber der Aufsicht.

Welche Rolle spielt die RTR bei NIS2 in Österreich?

Die Rundfunk und Telekom Regulierungs-GmbH (RTR) ist die zuständige Stelle für NIS2 in Österreich. Sie überwacht die Einhaltung der Pflichten und ist Ansprechpartner für Meldungen und Audits.

Welche Tools zur Anomalieerkennung eignen sich für österreichische KRITIS-Betreiber?

Microsoft Sentinel und AWS GuardDuty sind bewährte Optionen. Sie integrieren sich in Cloud-Umgebungen und liefern Frühwarnungen bei ungewöhnlichen Zugriffsmustern, die auf kompromittierte Identitäten oder Datenexfiltration hindeuten.

Was bedeuten RTO und RPO konkret für einen Netzbetreiber?

RTO legt fest, wie lange ein System maximal ausfallen darf, RPO, wie viel Datenverlust akzeptabel ist. Für einen Netzbetreiber wie die Austrian Power Grid bestimmen diese Werte, ob die Versorgungssicherheit gewährleistet bleibt.

Reicht eine einmalige Risikoanalyse aus?

Nein. Bedrohungen, Cloud-Dienste und regulatorische Anforderungen ändern sich laufend. Risikoanalyse muss als wiederkehrender Zyklus in die Unternehmensprozesse integriert werden, um Cloud-Sicherheit, NIS2-Konformität und Resilienz nachhaltig zu sichern.