Cloud-Souveränität: Was dies tatsächlich für die europäische Softwarearchitektur bedeutet

Die Cloud-Souveränität hat sich von einer politischen Debatte zu einer praktischen Frage der Technologie und Beschaffung entwickelt.

Bei europäischen Unternehmen, insbesondere solchen, die in Deutschland oder in anderen regulierten Branchen der EU tätig sind, möchten Kunden wissen, wo die Systeme gehostet werden, welche Rechtsordnung für ihre Daten gilt, wer Zugriff auf die Produktionsumgebungen hat und was geschieht, falls der derzeitige Cloud-Anbieter ersetzt werden muss.

Doch die Frage der Cloud-Souveränität lässt sich oft auf eine einzige Frage reduzieren:

Werden die Daten in Europa gespeichert?

Das ist zwar wichtig, stellt jedoch nur einen Teil des Gesamtbildes dar.

Ein System kann alle seine Daten in Frankfurt speichern und dennoch in hohem Maße von Technologien, Administratoren oder rechtlichen Strukturen außerhalb der EU abhängig sein. Bei echter Cloud-Souveränität geht es daher weniger um den Standort eines einzelnen Rechenzentrums als vielmehr darum, inwieweit eine Organisation die Kontrolle über ihre Technologie behält.

Datenaufbewahrungsort ist nicht dasselbe wie Datenhoheit

Die Frage nach dem Datenaufbewahrungsort beantwortet eine relativ einfache Frage: Wo werden die Daten physisch gespeichert? Die Frage nach der Datenhoheit geht darüber hinaus.

Wer betreibt die Infrastruktur? Wer verfügt über Administratorrechte? Welche Rechtsordnung gilt? Wo werden die Verschlüsselungsschlüssel verwaltet? Auf welche externen Dienste ist die Anwendung angewiesen? Und wäre es realistisch, die Arbeitslast an einen anderen Standort zu verlagern?

Für viele europäische Projekte ist die Speicherung von Daten innerhalb der EU nach wie vor ein wichtiger erster Schritt. Dies sollte jedoch nicht mit einer umfassenden Souveränitätsstrategie verwechselt werden. Eine Anwendung, die in einer europäischen Cloud-Region gehostet wird, kann dennoch in hohem Maße von proprietären Datenbanken, Identitätssystemen, Überwachungstools, serverlosen Funktionen und KI-Diensten abhängig sein.

Die Anbieterabhängigkeit ist Teil der Debatte um die Souveränität

Moderne Cloud-Plattformen ermöglichen es, komplexe Systeme wesentlich schneller als bisher zu entwickeln. Verwaltete Datenbanken, Warteschlangen, serverloses Computing und spezialisierte Plattformdienste können Entwicklungsteams Monate an Arbeit ersparen.

Der Nachteil ist die Abhängigkeit. Je stärker Ihre Anwendung in anbieterspezifische Technologien eingebunden ist, desto schwieriger wird ein Wechsel. Das bedeutet jedoch nicht, dass Unternehmen Managed-Cloud-Dienste meiden sollten. In vielen Fällen rechtfertigen deren Zuverlässigkeit und Entwicklungsgeschwindigkeit deren Einsatz ohne Weiteres.

Entscheidend ist, dass diese Abhängigkeit verstanden wird und bewusst hergestellt wird.

Architekturteams sollten wissen, welche Teile des Systems übertragbar sind, welche Dienste ersetzt werden müssten, wie Daten exportiert werden könnten und wie viel Aufwand eine Migration realistisch gesehen erfordern würde.

Das EU-Datenschutzgesetz unterstützt diese Entwicklung durch die Einführung von Maßnahmen, die den Wechsel zwischen Datenverarbeitungsanbietern erleichtern sollen.

Regulierungsmaßnahmen können jedoch nur einen Teil der vertraglichen und wirtschaftlichen Hindernisse beseitigen.

Ob eine Anwendung tatsächlich migriert werden kann, hängt nach wie vor stark davon ab, wie sie entwickelt wurde.

„Cloud-unabhängig“ bedeutet nicht zwangsläufig „Multi-Cloud“

Es gibt ein weiteres weit verbreitetes Missverständnis in Bezug auf Souveränität. Cloud-Agnostizismus bedeutet nicht, dass jede Anwendung gleichzeitig auf AWS, Azure, Google Cloud und bei einem europäischen Anbieter ausgeführt werden muss.

Für viele mittelständische Unternehmen würde dies zu unnötiger betrieblicher Komplexität führen. Ein praktikableres Ziel ist die Portabilität. Könnte die Anwendung an einem anderen Ort bereitgestellt werden, ohne das gesamte Produkt neu zu konzipieren?

Container können dabei helfen. Ebenso wie „Infrastructure as Code“, automatisierte Bereitstellungen, Standarddatenbanken, dokumentierte Netzwerkkonfigurationen, reproduzierbare Umgebungen und klare Sicherungsverfahren.

Ziel ist es, die Flexibilität zu bewahren, falls sich geschäftliche, behördliche oder kundenbezogene Anforderungen ändern sollten.

Die Souveränität hängt auch davon ab, wer Ihre Systeme betreibt

Technologie ist nur ein Teil des Ganzen. Stellen Sie sich vor, Ihre Datenbanken und Sicherungskopien befänden sich vollständig in Deutschland, Administratoren in mehreren anderen Rechtsräumen hätten jedoch uneingeschränkten Zugriff darauf. Der physische Standort der Server gibt nur einen Teil des Gesamtbildes wieder.

Aus diesem Grund überschneidet sich das Thema Cloud-Souveränität zunehmend mit dem Identitäts- und Zugriffsmanagement.

Unternehmen müssen wissen, wer Zugriff auf Produktionssysteme hat, wie Zugriffsrechte vergeben werden, wo sich diese Personen befinden, ob der Zugriff protokolliert wird und wie schnell Zugriffsrechte entzogen werden können.

Für Unternehmen, die mit externen Softwareentwicklungs- oder DevOps-Teams zusammenarbeiten, betreffen diese Fragen unmittelbar ihre Technologiepartner. Der Standort der Entwickler und die Art und Weise, wie sie auf die Infrastruktur des Kunden zugreifen, können sowohl in die Sicherheits- als auch in die Beschaffungsdiskussion einfließen.

Was sollten europäische Unternehmen tun?

Für die meisten Unternehmen bedeutet Cloud-Souveränität nicht, dass eine sofortige Migration erforderlich ist. Der erste Schritt besteht darin, die bereits vorhandene Architektur zu verstehen.

Erstellen Sie eine Übersicht darüber, wo Anwendungen und Daten gehostet werden. Ermitteln Sie, wo sich die Sicherungskopien befinden. Prüfen Sie, wer über Administratorrechte verfügt. Dokumentieren Sie, welche proprietären Cloud-Dienste für das Produkt von entscheidender Bedeutung sind. Verschaffen Sie sich einen Überblick darüber, welche externen Anbieter beteiligt sind, und schätzen Sie ein, was die Verlagerung einer Arbeitslast realistisch gesehen erfordern würde.

Unterscheiden Sie anschließend zwischen beabsichtigten und zufälligen Abhängigkeiten. Der Einsatz einer proprietären Technologie, weil diese einen erheblichen geschäftlichen Mehrwert bietet, ist eine berechtigte architektonische Entscheidung.

Die Erkenntnis, dass Ihr gesamtes Produkt den Anbieter nicht verlassen kann, weil niemand an die Portabilität gedacht hat, ist etwas ganz anderes.

Wo Ascendro zum Einsatz kommt

Bei Ascendro betrachten wir Cloud-Souveränität in erster Linie als eine Frage der technischen und betrieblichen Gestaltung.

Unser Infrastrukturansatz ist bewusst cloudunabhängig. Wir entwickeln Systeme, die auf zuverlässigem Hosting, einer Container-Infrastruktur, Sicherheit, Überwachung, Datensicherung und Wiederherstellung basieren, und vermeiden dabei eine unnötige Abhängigkeit von einem einzelnen Anbieter.

Darüber hinaus arbeiten wir mit in der EU ansässigen Ingenieurteams zusammen, was für europäische Kunden Fragen hinsichtlich der Rechtshoheit, des Zugangs und der Beschaffung vereinfachen kann. Das gleiche Prinzip gilt auch für unsere Softwareentwicklungsarbeit. UnserUnsres Ziel ist es, Systeme zu entwickeln, die dokumentiert, nachvollziehbar und wartbar sind, anstatt von einem einzigen Anbieter oder dem Wissen einer einzelnen Person abhängig zu sein.

Unsere nach ISO 27001, ISO 9001 und TISAX zertifizierten Prozesse bieten eine zusätzliche Grundlage, wenn Informationssicherheit, Zugriffskontrolle und Rückverfolgbarkeit wichtige Anforderungen sind.

Cloud-Souveränität bedeutet nicht, jede Abhängigkeit von externen Faktoren zu beseitigen. Sie bedeutet vielmehr, diese Abhängigkeiten zu verstehen, die damit verbundenen Risiken zu kennen und genügend Kontrolle zu bewahren, um bei veränderten Umständen eine andere Entscheidung treffen zu können.

Für europäische Unternehmen wird dies zunehmend zu einem Bestandteil einer guten Softwarearchitektur.