Blog
Ist eine souveräne Cloud wirklich sicherer?
Warum «souverän» nicht automatisch «sicherer» heisst.
Nachdem wir uns im letzten Blog mit der Frage befasst haben, warum Unternehmen den Schritt in eine souveräne Cloud erwägen, vertiefen wir heute, wie so eine Entscheidung aus der Perspektive Sicherheit und Datenschutz begleitet und bestätigt wird.
Losgelöst von der Frage, ob zwischen den Cloud-Modellen und deren Prüfung überhaupt Unterschiede bestehen, betrachten wir in diesem Beitrag die stets notwendigen Entscheidungsfaktoren.
Dazu betrachten wir einen generischen Entscheidungsprozess, der für die Analyse herangezogen werden kann, ob die Migration auf eine souveräne Cloud notwendig oder sinnvoll ist.
Übersicht Entscheidungsprozess
Die folgende Grafik zeigt die sieben Schritte, die von der Problemformulierung über die Informationsbeschaffung und Bewertung bis hin zur Umsetzung und Kontrolle führen. Wichtig ist dabei: Dieser Prozess ist zyklisch – nach der Kontrolle bzw. in regelmässigen Abständen kann es notwendig sein, den Prozess erneut zu durchlaufen, um auf veränderte Rahmenbedingungen zu reagieren.
In diesem Beitrag haben wir die aus Sicht Informationssicherheit und Datenschutz relevantesten Entscheidungsgrundlagen hervorgehoben und ausgeführt.
Entscheidungsgrundlagen
Im nachfolgenden Abschnitt betrachten wir, ob und wie sich diese, im obigen Prozess hervorgehobenen, Betrachtungen im Falle einer souveränen Cloud vom Fall einer Public Cloud unterscheiden.
Rechtsgrundlagenanalyse
Ein häufiges Missverständnis ist die Gleichsetzung von Data Residency und Data Sovereignty – ein Thema, das wir in unserem Blogpost zu Cloud-Begriffen ausführlich beleuchten. Klar ist jedoch, dass keine der beiden Eigenschaften ein durchdachtes Sicherheitskonzept ersetzen kann, auch wenn sie immer ein Baustein davon sind. Entscheidend ist das anwendbare Recht, das sowohl für den Cloud-Anbieter als auch für den Nutzer gilt.
Blog
Cloud-Begriffe im Klartext
von Patrik Huber
Erfahrungen haben gezeigt, dass die identifizierten Rechtsgrundlagen den Einsatz eines Cloud-Betriebsmodells selten explizit verbieten und vielmehr Rahmenbedingungen aufzeigen. Diese beschränken sich jedoch meist auf generische Aussagen wie das Herbeiführen eines «angemessenen» Schutzniveaus. Nur in bestimmten Fällen, wie z.B. der Bewahrung eines Amtsgeheimnisses, liefert allein die Auflistung der Rechtsgrundlagen bereits einen Hinweis auf die zu treffenden Massnahmen.
Selbst wenn der potentielle Cloud-Anbieter dem heimischen Recht unterliegt, können Subunternehmen ins Spiel kommen, die in anderen Jurisdiktionen operieren – etwa im Rahmen von Follow-the-Sun-Support-Modellen. All diese Konstellationen müssen sorgfältig geprüft werden. Im Schweizer Kontext spielen im Zusammenspiel mit den bekannten amerikanischen Hyperscalern besonders das Swiss-US Data Privacy Framework sowie die FINMA-Rundschreiben 2018/3 (Outsourcing) und 2023/1 (Operationelle Risiken und Resilienz) für den Finanzsektor eine Rolle.
Schutzbedarfsanalyse und Business Impact Analysis
Mit dieser Aktivität wird die Kritikalität der verarbeiteten Daten sowie der Einfluss auf das Geschäft analysiert.
Die Durchführung ist wiederum komplett unabhängig von der Wahl des (Cloud-)Betriebsmodells. In der Regel definiert diese Analyse konkrete Massnahmen für die spezifische Situation, welche als Vorgabe für die Umsetzung der notwendigen TOMs verwendet werden können. Damit können in einem sehr frühen Stadium des Vorhabens bereits potentielle Herausforderungen in der Umsetzung identifiziert werden.
Besonders die potentiellen Reputationsschäden verdienen Aufmerksamkeit. Ein Datenzugriff durch ausländische Behörden kann – selbst wenn er rechtlich zulässig wäre – das Vertrauen von Kunden und Partnern nachhaltig beschädigen. Eine Datenschutz-Folgenabschätzung (DSFA) hilft, die Risiken für Personendaten systematisch zu bewerten und geeignete Gegenmassnahmen zu definieren, während die Business Impact Analysis die gleiche Abschätzung für Geschäftsdaten liefert.
Beurteilung Cloud-Anbieter
Trotz der genannten Einschränkungen ist Data Residency als erstes Filterkriterium potentieller Anbieter aber durchaus sinnvoll. Ob ein Anbieter Daten im gewünschten Land halten kann, ist ein pragmatischer Startpunkt für die weitere Evaluation.
Die Wahrscheinlichkeit eines tatsächlichen Lawful Access oder politisch motivierter Service-Änderungen durch ausländische Staaten ist in den meisten Fällen gering – sie sollte aber dennoch in die Risikobewertung einfliessen. Wesentlich aussagekräftiger als der Standort der Rechenzentren ist die Überprüfung anhand einer strukturierten Checkliste an Kontrollen und Zertifizierungen. Zertifizierungen und Auditberichte wie ISO 27001 oder SOC 2 Type II geben konkrete Auskunft über das tatsächliche Sicherheitsniveau des Anbieters auch ausserhalb jeglicher Lawful Access Szenarien.
Onboarding des Anbieters nach Auswahl
Nach Auswahl eines Anbieters, der die Residency und Souveränitätsanforderungen vollständig einhalten kann, geht es an das Design der eigentlichen Sicherheitsmassnahmen.
Baselining TOMs
Im ersten Schritt müssen die notwendigen technischen und organisatorischen Massnahmen (TOMs) definiert und dokumentiert werden. Das Baselining legt fest, welche Sicherheitskontrollen für den gewählten Anbieter und die spezifischen Workloads gelten. Diese Baseline dient als Referenzpunkt für alle weiteren Prüfungen und Audits.
Initiale Risikoanalyse für Betrieb und Transition
Die Migration in eine Cloud-Umgebung birgt eigene Risiken, die proaktiv adressiert werden müssen. Dazu gehören Migrationsrisiken wie Inkompatibilitäten, Performanceeinbussen oder Serviceunterbrüche während der Transition. Ebenso muss das Risiko eines Datenverlusts bewertet und durch geeignete Massnahmen minimiert werden.
Ein robustes Backup- und Recovery-Konzept ist von Beginn an zwingend erforderlich – nicht erst nach Abschluss der Migration. Darüber hinaus muss ein strukturiertes Testing sicherstellen, dass alle Systeme und Prozesse nach der Migration wie erwartet funktionieren.
Lieferantenmanagement und Exit-Strategie
Gerade in regulierten Branchen sind vertraglich abgesicherte Auditrechte unverzichtbar. Diese müssen bereits vor der Migration vertraglich fixiert werden und sollten nicht erst nachträglich verhandelt werden müssen.
Ein oft unterschätzter, aber kritischer Punkt ist die Exit-Strategie. Diese sollte bereits aufgesetzt und dokumentiert sein, bevor die erste Workload migriert wird. Die Exit-Strategie ist kein statisches Dokument, sondern muss laufend aktualisiert werden, um technologische Veränderungen und neue Abhängigkeiten zu berücksichtigen.
Fazit: Bedürfnis- und Risikoorientierte Entscheidung
Die zentrale Frage lautet also nicht «Souverän oder Public?», sondern: Entspricht die Sicherheitsarchitektur des gewählten Modells den tatsächlichen Bedürfnissen, und kann der Anbieter die erforderlichen Kontrollen nachweislich erfüllen?
Eine weitverbreitete Fehlwahrnehmung muss dabei korrigiert werden: In einer souveränen Cloud sind nicht weniger und nicht grundlegend andere Kontrollen und Massnahmen notwendig als in anderen Cloud-Betriebsmodellen. Wer glaubt, mit der Wahl einer souveränen Cloud automatisch auf der sicheren Seite zu sein, unterliegt einem gefährlichen Trugschluss. Die Sorgfaltspflichten bleiben identisch.
atrete unterstützt Unternehmen als neutraler Berater bei dieser Entscheidung. Da atrete keine Partnerschaften mit Cloud-Anbietern unterhält, empfiehlt sie ausschliesslich den Souveränitätslevel, der tatsächlich notwendig ist – nicht mehr und nicht weniger. Diese Unabhängigkeit ist ein entscheidender Vorteil, den Beratungsunternehmen mit Anbieterpartnerschaften nicht bieten können.
Neben den Sicherheitsaspekten spielen jedoch auch die Kosten eine wichtige Rolle bei der Entscheidung für das richtige Cloud-Modell. Diesem Thema widmen wir uns im nächsten Teil dieser Blogreihe.
