Resilienz von Cloud-Diensten bewerten: Unser praktischer Leitfaden
Wir beginnen mit einer Frage, die in österreichischen Unternehmen und Behörden längst keine reine IT-Agenden-Frage mehr ist: Warum ist die Bewertung der Cloud-Resilienz für kritische Infrastruktur in Österreich nicht nur eine technische, sondern eine strategische Notwendigkeit? Wer Stromnetze, Krankenhäuser oder Verkehrsleitsysteme betreibt, kann sich nicht darauf verlassen, dass ein Cloud-Anbieter „eh schon alles im Griff“ hat. Wir zeigen in diesem Leitfaden, wie wir Cloud-Resilienz systematisch bewerten – von den regulatorischen Vorgaben über konkrete Kriterien bis hin zur Anomalieerkennung als Frühwarnsystem.
Warum Resilienz von Cloud-Diensten für kritische Infrastruktur entscheidend ist
Immer mehr Betreiber kritischer Infrastruktur in Österreich verlagern Workloads in die Cloud – sei es zu AWS, Microsoft Azure oder Google Cloud. Das bringt Skalierbarkeit und Kostenvorteile, aber auch eine neue Abhängigkeit. Ein Ausfall bei einem großen Hyperscaler kann Energieversorger, Gesundheitseinrichtungen und Verkehrsbetriebe gleichzeitig treffen. Genau deshalb rückt die Frage nach der Resilienz dieser Dienste in den Mittelpunkt unserer Arbeit mit Kunden aus dem KRITIS-Umfeld.
Auswirkungen von Cloud-Ausfällen auf kritische Infrastruktur
Wir haben in den vergangenen Jahren mehrfach gesehen, wie schnell ein regionaler Ausfall einer Cloud-Region weitreichende Folgen haben kann. Wenn ein Identity-Provider oder ein zentraler Speicherdienst nicht erreichbar ist, können Anwendungen zur Netzsteuerung, Patientendokumentation oder Verkehrslenkung ausfallen. In Österreich sind die Sektoren Energie, Gesundheit, Verkehr, Wasser und digitale Infrastruktur besonders sensibel, weil sie stark vernetzt sind. Ein einzelner Cloud-Ausfall kann dort Kettenreaktionen auslösen, die bis zum Endkunden spürbar sind.
NIS2 und die neuen Resilienzanforderungen
Die NIS2-Richtlinie verschärft die Anforderungen an Resilienz und Berichtspflichten erheblich. Betreiber wesentlicher und wichtiger Einrichtungen müssen nicht nur technische Maßnahmen nachweisen, sondern auch Governance-Strukturen, Risikomanagement und Meldewege etablieren. Für uns bedeutet das: Cloud-Resilienz wird zum Teil der Compliance. Wer die NIS2-Richtlinie ernst nimmt, kommt um eine belastbare Bewertung seiner Cloud-Dienste nicht herum – inklusive dokumentierter Tests und klarer Verantwortlichkeiten.
Schlüsselkriterien für die Bewertung der Cloud-Resilienz
Wir orientieren uns bei der Bewertung an vier Kernkriterien: Verfügbarkeits-SLAs, Redundanzarchitekturen, Disaster-Recovery-Pläne und Transparenz der Anbieter. Dabei betonen wir, dass österreichische Betreiber kritischer Infrastruktur oft spezifische Anforderungen haben – etwa datenschutzrechtliche Vorgaben, geografische Nähe zu Rechenzentren oder die Einbindung lokaler Behörden.
Verfügbarkeits-SLAs und tatsächliche Ausfallzeiten
Ein SLA von 99,99 Prozent klingt beeindruckend, bedeutet aber rechnerisch noch immer mehrere Minuten Ausfall pro Monat. Wir prüfen deshalb nicht nur die vertraglich zugesicherten Werte, sondern auch die tatsächlich gemessenen Ausfallzeiten der vergangenen Jahre. Anbieter veröffentlichen diese Daten oft nur teilweise, weshalb wir eigene Monitoring-Daten und unabhängige Quellen heranziehen. Entscheidend ist für uns die Frage: Deckt das SLA jene Dienste ab, die für den Betrieb kritisch sind – oder nur Randbereiche?
Redundanz und geografische Verteilung
Redundanz ist mehr als ein zweites Rechenzentrum. Wir schauen genau hin, ob Daten und Dienste über mehrere Verfügbarkeitszonen und Regionen verteilt sind und ob die Anbindung an das eigene Netz ausfallsicher gestaltet ist. In Österreich ist die geografische Verteilung ein sensibles Thema, weil viele Betreiber aus Compliance-Gründen Daten im Land oder zumindest im EU-Raum halten müssen. Eine sinnvolle Redundanzstrategie berücksichtigt daher sowohl technische als auch rechtliche Rahmenbedingungen.
Disaster Recovery und Business Continuity
Ein Disaster-Recovery-Plan ist nur so gut wie seine regelmäßige Überprüfung. Wir bewerten, ob Wiederherstellungszeiten (RTO) und Datenverlusttoleranzen (RPO) klar definiert sind und ob sie zu den Anforderungen der kritischen Infrastruktur passen. Ebenso wichtig ist die Frage, ob Business-Continuity-Prozesse auch dann funktionieren, wenn der Cloud-Anbieter selbst betroffen ist. Genau hier zeigt sich, ob Resilienz strategisch gedacht wurde oder nur auf dem Papier existiert.
Anomalieerkennung als Frühwarnsystem für Cloud-Resilienz
Anomalieerkennung hilft uns, ungewöhnliche Muster in Cloud-Diensten frühzeitig zu erkennen – bevor daraus ein Ausfall wird. Tools wie AWS GuardDuty, Azure Sentinel oder das Google Cloud Security Command Center liefern uns Signale zu ungewöhnlichem Verhalten, verdächtigen Zugriffen oder plötzlichen Lastspitzen. Diese Signale sind für uns ein wesentlicher Baustein, um die Resilienz laufend zu überwachen.
Wie Anomalieerkennung funktioniert
Moderne Systeme lernen das Normalverhalten eines Cloud-Dienstes – etwa typische Zugriffsmuster, Datenmengen oder API-Aufrufe – und melden Abweichungen. AWS GuardDuty analysiert beispielsweise kontinuierlich Ereignisse im AWS-Konto und erkennt verdächtige Aktivitäten. Azure Sentinel sammelt Sicherheitsdaten aus verschiedenen Quellen und korreliert sie mithilfe von KI. Das Google Cloud Security Command Center bündelt ähnliche Funktionen für Google-Cloud-Umgebungen. Für uns ist entscheidend, dass diese Werkzeuge nicht isoliert betrachtet werden, sondern Teil eines übergreifenden Frühwarnsystems sind.
Integration in bestehende Cloud-Sicherheitsarchitekturen
Wir integrieren Anomalieerkennung direkt in die bestehende Cloud-Sicherheitsarchitektur unserer Kunden. Das bedeutet: Ereignisse aus AWS GuardDuty, Azure Sentinel und dem Google Cloud Security Command Center laufen in einem zentralen SIEM zusammen, werden mit Bedrohungsdaten angereichert und lösen definierte Eskalationsprozesse aus. So entsteht aus einzelnen Warnsignalen ein belastbares Bild der Resilienz – und das Team kann reagieren, bevor Nutzer etwas merken.
Praktische Schritte zur Bewertung der Resilienz
Wir beschreiben einen konkreten Ablauf, den wir in Projekten mit österreichischen Betreibern kritischer Infrastruktur einsetzen: von der Bestandsaufnahme über die Risikoanalyse bis hin zu Tests und kontinuierlicher Überwachung. Als mögliche Anlaufstellen für Abstimmungen und Meldungen nennen wir österreichische Behörden wie das Bundeskanzleramt oder die RTR (Rundfunk und Telekom Regulierungs-GmbH).
Bestandsaufnahme und Risikoanalyse
Am Anfang steht die Frage: Welche Dienste nutzen wir überhaupt in der Cloud, und welche davon sind kritisch? Wir erfassen alle Cloud-Abhängigkeiten, Verträge und Datenflüsse und bewerten anschließend die Risiken. Dabei hilft uns ein strukturierter Ansatz:
- Inventarisierung aller Cloud-Dienste und Anbieter
- Zuordnung zu kritischen Geschäftsprozessen
- Bewertung von Eintrittswahrscheinlichkeit und Auswirkung möglicher Ausfälle
- Abgleich mit den Anforderungen der NIS2-Richtlinie
Resilienztests und Simulationen
Wir testen regelmäßig, ob die theoretischen Annahmen auch in der Praxis halten. Dazu gehören Failover-Tests, Chaos-Engineering-Experimente und Simulationen von Anbieterausfällen. Wichtig ist uns, dass solche Tests dokumentiert und mit den zuständigen Stellen abgestimmt werden – gerade im Hinblick auf die Berichtspflichten der NIS2-Richtlinie. Die RTR (Rundfunk und Telekom Regulierungs-GmbH) und das Bundeskanzleramt sind hier wichtige Ansprechpartner für österreichische Betreiber.
Kontinuierliche Überwachung und Verbesserung
Resilienz ist kein einmaliges Projekt. Wir etablieren daher kontinuierliche Überwachung – technisch durch Monitoring und Anomalieerkennung, organisatorisch durch regelmäßige Reviews. Ergebnisse aus Tests und Vorfällen fließen in die Verbesserung der Architektur und der Prozesse ein. So bleibt die Bewertung aktuell und nachvollziehbar.
Herausforderungen und unsere Empfehlungen
In der Praxis begegnen uns typische Herausforderungen: mangelnde Transparenz der Anbieter, komplexe Verträge und fehlende Fachkräfte. Wir diskutieren diese Punkte offen und geben konkrete Empfehlungen, etwa die Nutzung von Multi-Cloud-Strategien und die Einbindung von Experten.
Mangelnde Transparenz und Vertragskomplexität
Viele Anbieter veröffentlichen nur begrenzt Informationen über ihre tatsächliche Resilienz. Verträge sind oft lang, mehrsprachig und enthalten Klauseln, die im Ernstfall entscheidend sind. Wir empfehlen, SLAs, Haftungsregelungen und Exit-Szenarien genau zu prüfen und mit den eigenen Anforderungen abzugleichen. Wo Transparenz fehlt, sollten Betreiber kritischer Infrastruktur auf Nachweise und Audits bestehen.
Multi-Cloud-Strategien als Resilienzmaßnahme
Eine Multi-Cloud-Strategie kann die Abhängigkeit von einem einzigen Anbieter reduzieren. Wir raten jedoch zu einem realistischen Vorgehen: Nicht jede Anwendung eignet sich für den Parallelbetrieb bei mehreren Hyperscalern. Sinnvoll ist eine selektive Verteilung kritischer Dienste, kombiniert mit klaren Standards und Automatisierung. Wer diesen Weg geht, sollte die damit verbundene Komplexität nicht unterschätzen und frühzeitig Fachkräfte einbinden.
Häufig gestellte Fragen (FAQ)
Was bedeutet Resilienz von Cloud-Diensten konkret?
Resilienz beschreibt die Fähigkeit eines Cloud-Dienstes, Störungen zu widerstehen, sich schnell zu erholen und den Betrieb auch unter widrigen Umständen aufrechtzuerhalten. Für kritische Infrastruktur heißt das: Ausfälle dürfen nicht zu einem Stillstand wesentlicher Prozesse führen.
Warum ist die NIS2-Richtlinie für österreichische Betreiber relevant?
Die NIS2-Richtlinie verschärft die Anforderungen an Resilienz, Risikomanagement und Berichtspflichten. Betreiber wesentlicher und wichtiger Einrichtungen in Österreich müssen nachweisen, dass sie ihre Cloud-Abhängigkeiten im Griff haben – und Vorfälle melden.
Wie hilft Anomalieerkennung bei der Bewertung der Cloud-Resilienz?
Anomalieerkennung erkennt ungewöhnliche Muster frühzeitig, etwa bei AWS GuardDuty, Azure Sentinel oder dem Google Cloud Security Command Center. So können wir reagieren, bevor ein Ausfall oder Sicherheitsvorfall den Betrieb beeinträchtigt.
Welche österreichischen Stellen sind Anlaufstellen?
Für Abstimmungen und Meldungen im Zusammenhang mit kritischer Infrastruktur nennen wir unter anderem das Bundeskanzleramt und die RTR (Rundfunk und Telekom Regulierungs-GmbH). Welche Stelle im konkreten Fall zuständig ist, hängt vom Sektor und der Einstufung ab.
Sollten wir auf Multi-Cloud setzen?
Multi-Cloud kann die Resilienz erhöhen, ist aber kein Allheilmittel. Wir empfehlen eine selektive Verteilung kritischer Dienste, klare Standards und ausreichend Fachkräfte. Die Komplexität sollte dabei nicht unterschätzt werden.
Die Bewertung der Cloud-Resilienz ist ein fortlaufender Prozess, der regelmäßige Überprüfung und Anpassung erfordert, um NIS2-konform zu bleiben. Wir begleiten österreichische Betreiber kritischer Infrastruktur dabei, ihre Cloud-Abhängigkeiten zu verstehen, Risiken zu bewerten und mit Anomalieerkennung, Tests und klaren Prozessen langfristig widerstandsfähig zu bleiben.