Cloud-Souveränität nach BSI: Architektur schlägt Anbieter

Cloud-Souveränität ist eines der meistdiskutierten Themen in der IT und gleichzeitig eines der am häufigsten missverstandenen. Viele Anbieter werben mit „souveränen Clouds“ und setzen sie mit sicheren Rechenzentren oder europäischen Standoten gleich. Doch ein genauer Blick zeigt, dass die wenigsten die Anforderungen erfüllen, die tatsächlich notwendig sind.

Mit den C3A-Kriterien (Criteria enabling Cloud Computing Autonomy) hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) erstmals einen klaren Rahmen geschaffen, um Cloud-Souveränität messbar zu machen.

Was bedeutet Cloud-Souveränität wirklich?

Cloud-Souveränität beschreibt nicht den Standort einer Infrastruktur und auch nicht einzelne Sicherheitsmerkmale. Sie beschreibt die Fähigkeit, Cloud-Systeme unter eigener Kontrolle betreiben, steuern und im Bedarfsfall unabhängig weiterführen zu können. Das BSI zerlegt Cloud-Souveränität in sechs konkrete Dimensionen:

1. Strategische Souveränität (SOV-1)

Strategische Souveränität bedeutet, dass ein Cloud-Anbieter nicht direkt oder indirekt durch Akteure außerhalb der EU kontrolliert wird. Entscheidend ist dabei die Eigentümerstruktur und Governance, denn selbst wenn Infrastruktur in Europa betrieben wird, kann Einfluss durch Drittstaaten bestehen. Ziel ist es, strukturelle Abhängigkeiten zu vermeiden, die sich langfristig auf Entscheidungen, Betrieb oder Verfügbarkeit auswirken können.

2. Rechtliche Souveränität (SOV-2)

Rechtliche Souveränität stellt sicher, dass für den Cloud-Betrieb ausschließlich europäisches bzw. deutsches Recht gilt und keine extraterritorialen Zugriffe möglich sind. Das umfasst insbesondere den Schutz vor Gesetzen wie dem US CLOUD Act, die Unternehmen zur Herausgabe von Daten verpflichten können. Gleichzeitig müssen klare vertragliche und auditierbare Regelungen bestehen, die Transparenz und Durchsetzbarkeit gewährleisten.

3. Datensouveränität (SOV-3)

Datensouveränität bedeutet, dass der Nutzer jederzeit die volle Kontrolle über seine Daten behält. Dazu gehört insbesondere die Hoheit über Verschlüsselung, Schlüsselmanagement sowie Identitäts- und Zugriffssysteme. Entscheidend ist nicht nur, wo Daten gespeichert werden, sondern wer technisch in der Lage ist, darauf zuzugreifen oder diese zu entschlüsseln.

4. Operative Souveränität (SOV-4)

Operative Souveränität beschreibt die Kontrolle über den laufenden Betrieb der Cloud-Infrastruktur. Dazu zählen der physische Standort der Rechenzentren, das eingesetzte Betriebspersonal (z.B. EU-basiert) sowie administrative Zugriffsmöglichkeiten. Ziel ist es, sicherzustellen, dass Betrieb und Wartung innerhalb eines kontrollierbaren Rechts- und Einflussraums erfolgen.

5. Lieferketten-Souveränität (SOV-5)

Lieferketten-Souveränität fordert Transparenz und Kontrolle über alle eingesetzten Software- und Hardware-Komponenten. Unternehmen müssen nachvollziehen können, welche Drittanbieter beteiligt sind und welche Abhängigkeiten bestehen. Dazu gehört auch die kontinuierliche Analyse der Supply Chain, um Risiken frühzeitig zu erkennen und zu minimieren.

6. Technologische Souveränität (SOV-6)

Technologische Souveränität ist der tiefgreifendste Aspekt und beschreibt die Fähigkeit, die eingesetzte Cloud-Technologie unabhängig betreiben und weiterentwickeln zu können. Dafür sind Zugriff auf Quellcode, nachvollziehbare und reproduzierbare Build-Prozesse sowie der Verzicht auf nicht kontrollierbare Blackbox-Komponenten erforderlich. Ziel ist es, den Betrieb auch ohne den ursprünglichen Anbieter fortführen zu können.

Dieser Kriterien-Katalog macht eins deutlich: Cloud-Souveränität ist kein Produktmerkmal, sondern das Ergebnis aus rechtlichen, organisatorischen und technischen Voraussetzungen.

Warum viele Organisationen daran scheitern

Die größte Hürde ist nicht die Technologie, sondern das zugrunde liegende Verständnis. Viele Unternehmen versuchen, Souveränität durch die Auswahl eines „geeigneten“ Cloud-Anbieters zu erreichen. Dieser Ansatz greift zu kurz. Wer die eigene Infrastruktur nicht selbst betreiben und unabhängig reproduzieren kann, erfüllt die grundlegenden Anforderungen der Souveränität nicht.

Typische Schwachstellen sind beispielsweise, dass Verschlüsselungen beim Anbieter bleiben statt beim Kunden, Build- und Deployment-Prozesse nicht reproduzierbar sind und Admin-Zugriffe über providerseitige Kontrollschichten laufen.

Damit wird klar: Cloud-Souveränität entsteht nicht durch Anbieterwahl, sondern durch Architektur, Prozesse und technisches Know-how.

Was echte Souveränität in der Praxis bedeutet

Souveränität bedeutet Wechselfähigkeit

Eines der wichtigsten, aber oft unterschätzten Kriterien ist die Frage, wie leicht sich eine Plattform verlassen lässt. Echte Souveränität bedeutet, dass ein Wechsel des Cloud-Providers keine aufwändige Migrationskampagne erfordert, sondern durch offene Standards und portable Architekturen möglich ist.

Wenn Anwendungen eng an proprietäre Dienste einzelner Anbieter gebunden sind – etwa spezifische PaaS-Services oder nicht standardisierte APIs – entsteht faktisch eine technische Abhängigkeit, die einen Wechsel wirtschaftlich oder operativ nahezu unmöglich macht. Offene Standards, containerisierte Architekturen und klar definierte Schnittstellen sind deshalb eine Grundvoraussetzung für Portabilität.

Supply-Chain-Souveränität reicht tief bis zum Betriebssystem

Ein weiterer kritischer Punkt ist die Frage, auf welcher technologischen Basis eine Cloud überhaupt betrieben wird. Wenn zentrale Komponenten der Infrastruktur auf proprietären Technologien basieren, die unter extraterritorialen Rechtsräumen stehen, bleibt die Kontrolle über die gesamte Plattform eingeschränkt. Das betrifft nicht nur Anwendungen, sondern auch das darunterliegende Betriebssystem und die gesamte Systemsoftware.

Open Source ist keine Ideologie, sondern Anforderung

In diesem Kontext spielt Open Source eine zentrale Rolle, allerdings nicht im Sinne von „kostenlos verfügbar“, sondern im Sinne von vollständig kontrollierbarer Technologie. Entscheidend ist dabei nicht nur der Zugriff auf den Quellcode, sondern auch die Fähigkeit, diesen unabhängig zu bauen, zu verändern und reproduzierbar zu betreiben. Reine „source-available“-Modelle reichen in diesem Zusammenhang nicht aus, da sie häufig Einschränkungen bei Nutzung, Veränderung oder Reproduktion enthalten können. Ohne diese technische Freiheit bleibt die Kontrolle über die Software beim Anbieter, selbst wenn der Code einsehbar ist.

Fazit: Souveränität ist eine Fähigkeit, kein Produkt

Cloud-Souveränität lässt sich nicht einkaufen. Sie entsteht ausschließlich durch eine Architektur, die vollständige Kontrolle technisch ermöglicht.

Die C3A-Kriterien des BSI machen deutlich: Entscheidend ist nicht die äußere Form einer Cloud, sondern die Frage, ob Unternehmen Daten, Systeme und Betrieb tatsächlich unabhängig kontrollieren können. Damit verschiebt sich der Fokus weg von der Auswahl einzelner Anbieter hin zur Frage, welche Architektur echte Unabhängigkeit überhaupt ermöglicht.

Souveränität ermöglichen, nicht versprechen

Cloud-Souveränität im Sinne der C3A-Kriterien ist kein Produkt, das sich als fertige Lösung einkaufen lässt. Sie entsteht erst durch eine konsequent kontrollierte Architektur.

Genau hier setzen wir an. Wir verstehen uns nicht als „souveräner Cloud-Anbieter“, sondern als Enabler für souveräne Cloud-Umgebungen. Unser Infrastruktur-Blueprint schafft die technischen und organisatorischen Voraussetzungen, um die Anforderungen des C3A-Katalogs praktisch umzusetzen.

Im Kern geht es darum, Abhängigkeiten strukturell zu reduzieren und gleichzeitig vollständige Transparenz über Betrieb, Daten und Lieferketten herzustellen. Die Infrastruktur wird in einem europäischen Rechts- und Betriebsrahmen betrieben und auf Nachvollziehbarkeit, Stabilität und Hochverfügbarkeit ausgelegt.

Der entscheidende Unterschied liegt in der technischen Umsetzung: Durch kontrollierbare Build-Prozesse, reproduzierbare Systeme und eine vollständig nachvollziehbare Code-Basis wird es möglich, Cloud-Umgebungen unabhängig vom ursprünglichen Anbieter zu betreiben und weiterzuentwickeln.

So entsteht keine Souveränität als Marketingversprechen, sondern eine real umsetzbare Fähigkeit – verankert in der Architektur, nicht im Produkt eines einzelnen Anbieters.