Die acht SOV-Kriterien: Betrachtungen zur Cloud-Souveränität
„Cloud-Souveränität" wurde lange unscharf verwendet. Das Cloud Sovereignty Framework (EU CSF) der Europäischen Kommission gibt dem Begriff eine Struktur: acht Souveränitätsziele, bezeichnet als SOV-1 bis SOV-8. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat davon sechs in einen Katalog überprüfbarer Kriterien überführt, die Criteria enabling Cloud Computing Autonomy (C3A), der C5-Konformität voraussetzt und die übrigen beiden Domänen anderen Rahmenwerken überlässt.
Was folgt, ist keine Zusammenfassung dieses Katalogs. Es ist ein Gang durch die acht Kriterien selbst, was jedes tatsächlich verlangt, mit einer Betrachtung, wie sich jedes für eine Plattform wie openEduSuite liest: einen selbst betriebenen, Open-Source-Stack, den die einsetzende Einrichtung selbst betreibt. Stellt man die Kriterien an einen Anbieter, ist das Beschaffung; stellt man sie an sich selbst, wird es interessanter.
| # | Domäne | Kernfrage |
|---|---|---|
| SOV-1 | Strategische Souveränität | Wer kontrolliert die strategischen Entscheidungen des Anbieters? |
| SOV-2 | Rechtliche und gerichtliche Souveränität | Unter wessen Recht operiert der Dienst effektiv? |
| SOV-3 | Daten- und KI-Souveränität | Wer hält die Schlüssel, und wo liegen die Daten wirklich? |
| SOV-4 | Operationale Souveränität | Kann der Dienst ohne seine Nicht-EU-Lebensadern laufen? |
| SOV-5 | Souveränität der Lieferkette | Wissen wir, woraus der Dienst besteht? |
| SOV-6 | Technologische Souveränität | Können wir das System selbst bauen, patchen und ändern? |
| SOV-7 | Sicherheits- und Compliance-Souveränität | Erfüllt er die anerkannte Sicherheitsbasis? |
| SOV-8 | Umweltliche Nachhaltigkeit | Lässt er sich so über Jahrzehnte betreiben? |
SOV-1: Strategische Souveränität
Das erste Kriterium fragt, ob der Anbieter in der EU ansässig ist und von dort aus effektiv kontrolliert wird: Eigentumsstruktur, Governance und strategische Entscheidungen müssen dort sitzen, wo europäische Kunden sie im äußersten Fall beeinflussen können. Die C3A operationalisieren dies über Anforderungen zu Sitz, Kontrolle und Vorankündigung von Eigentümerwechseln.
Betrachtung. Für eine selbst betriebene Plattform kehrt sich SOV-1 um: Die Einrichtung ist der Anbieter. Das Kriterium verschwindet dadurch nicht; es wird zur Governance-Frage. Wer entscheidet über die Roadmap der Plattform? Wessen Prioritäten steuern sie? Ein Open-Source-Projekt mit öffentlichem Repository und einer Community von Beitragenden macht diese Kontrolle nachvollziehbar, wie es eine Unternehmenshierarchie nicht kann; doch es bedeutet auch, dass die Einrichtung die Kontrolle, die sie hat, tatsächlich ausüben muss. Souveränität, die man nicht nutzt, ist keine Souveränität.
SOV-2: Rechtliche und gerichtliche Souveränität
Das zweite Kriterium fragt, unter wessen Recht der Dienst effektiv operiert. Der praktische Test ist die extraterritoriale Exposition: Ein Anbieter, der einem Nicht-EU-Rechtsregime unterliegt, kann zur Herausgabe von Daten verpflichtet werden, egal wo die Server stehen. Die C3A verlangen eine jährliche, strukturierte Bewertung dieser Exposition sowie Auditrechte für nationale Behörden und für den Verteidigungsfall die Fähigkeit, den Betrieb an Bundesbehörden zu übergeben, einschließlich Material und Personal.
Betrachtung. Dies ist die Domäne, in der Selbstbetrieb am stärksten ist: Eine Infrastruktur, die eine deutsche Hochschule nach deutschem und EU-Recht betreibt, hat kein ausländisches Mutterunternehmen, über das Pflichten ankommen könnten. Doch die Betrachtung sollte nicht bei der Zufriedenheit stehen. Daten selbst sind gleichgültig gegen Jurisdiktion; es zählt jeder Weg, der zu ihnen führt. Identitätsföderation (DFN-AAI), Supportverträge, Monitoring-Dienste, selbst ein vergessener Subprozessor in einer Datenschutzerklärung: jedes ist eine kleine Öffnung. Jurisdiktion Souveränität ist weniger ein Zustand als eine Disziplin, diese Wege kurz zu halten.
SOV-3: Daten- und KI-Souveränität
Das dritte Kriterium fragt, ob Kunden die Kontrolle über ihre Daten im technischen Sinne behalten: nachvollziehbare Speicher- und Verarbeitungsorte, Verschlüsselungsschlüssel außerhalb der Anbieterumgebung, Integration externer Identity-Provider über offene Standards und wo nötig Client-seitige Verschlüsselung. Das „KI" im Namen der Domäne ist keine Dekoration; Training und Inferenz auf institutionellen Daten stellen dieselbe Frage: Wer entscheidet, was mit ihnen geschieht?
Betrachtung. openEduSuite beantwortet das strukturell. Die Daten verlassen den Speicher der Einrichtung nie; die Schlüssel liegen im eigenen Secret-Management; der Identity-Provider (Keycloak, föderiert über DFN-AAI) gehört der Einrichtung. Es gibt keine Verhandlung über Export oder Subprozessierung, weil es keine Gegenseite gibt. Die ehrliche Einschränkung: Nachvollziehbarkeit ist Arbeit. Zu wissen, wo jeder Dienst seinen Zustand ablegt (MariaDB-Volumes, Object-Storage-Buckets, Backups), ist eine fortlaufende Kartierungsübung, und das Kriterium verlangt stillschweigend, dass die Karte aktuell bleibt.
SOV-4: Operationale Souveränität
Das vierte Kriterium machen die C3A am konkretesten: Der Dienst muss innerhalb der EU betreibbar sein, durch Personal mit EU-Wohnsitz, mit EU-SOC und EU-Konnektivität, und muss laut Kriterium SOV-4-09-C eine Disconnect von Nicht-EU-Infrastruktur ohne Verlust von Verfügbarkeit, Integrität, Authentizität oder Vertraulichkeit überstehen, mindestens jährlich getestet.
Betrachtung. Eine selbst betriebene Plattform hängt nicht von einer ausländischen Betreiber-Cloud ab, daher ist der wörtliche Disconnect-Test trivial. Die sinnvolle Übersetzung des Kriteriums lautet: Upstream. Der Stack zieht Container-Images, Sicherheitspatches und Upstream-Releases weiterhin aus einem globalen Ökosystem. Disconnect bedeutet bei Open Source, auf dem sicher betreiben zu können, was bereits auf der Platte liegt, und zwar über einen längeren Zeitraum. Das ist ein härterer Test als jedes Anbieter-Audit, und hier zählen Praktiken mehr als Erklärungen: gespiegelte Images, vendored Dependencies, ein dokumentiertes Freeze-and-Operate-Verfahren. Die ehrliche Antwort ist, dass openEduSuite eine begrenzte Version dieses Tests heute bestehen könnte und die unbegrenzte nicht für sich beanspruchen sollte.
SOV-5: Souveränität der Lieferkette
Das fünfte Kriterium fragt, ob der Betreiber weiß, woraus der Dienst besteht: Software- und Hardwarekomponenten, ihre Herkunftsländer, idealerweise dokumentiert als Software Bill of Materials (SBOM), mit Mitigationsstrategien für kritische Abhängigkeiten.
Betrachtung. Hier ist das Open-Source-Modell nicht automatisch überlegen; es ist lediglich audierbar. Die Lieferkette einer proprietären Plattform ist eine Vertragsfrage; die einer offenen ist eine Datei, die man lesen kann. Der Nix-basierte Build von openEduSuite macht den Abhängigkeitsgraphen konstruktionsbedingt deterministisch und prüfbar; der größte Teil des Wegs zu einer SBOM. Die verbleibende Betrachtung gilt der Konzentration: Ein großer Teil der Open-Source-Welt konvergiert auf eine kleine Zahl von Upstream-Projekten und Registries. Transparenz über Abhängigkeiten ist noch nicht Unabhängigkeit von ihnen, aber sie ist die Voraussetzung, um überhaupt dorthin zu gelangen.
SOV-6: Technologische Souveränität
Das sechste Kriterium fragt, ob der Betreiber das System unabhängig bauen, patchen und weiterentwickeln kann: Die C3A verlangen Quellcode- und Dokumentationsbackups in der EU, aktuell gehalten innerhalb von 24 Stunden, mit unabhängiger Patch-Fähigkeit im Notfall.
Betrachtung. Dies ist die Domäne, in der Open Source aufhört, ein Argument zu sein, und Tatsache wird. Der Quellcode ist nicht bloß verfügbar; das Build-System, das ihn in eine laufende Plattform verwandelt, ist Teil des Repositorys. Ein Sicherheitspatch erfordert keinen Release-Zyklus eines Anbieters, sondern eine wartende Person und eine Pipeline, und beides existiert. Die 24-Stunden-Backup-Anforderung des Kriteriums liest sich von dieser Seite fast ironisch: Der schwierige Teil ist nicht, den Code zu behalten, sondern das Wissen: Runbooks, Architekturentscheidungen, die Gründe hinter Konfigurationswahl. Technologische Souveränität schwindet lautlos, wenn die Person geht, die das System verstanden hat.
SOV-7: Sicherheits- und Compliance-Souveränität
Das siebte Kriterium fragt, ob der Dienst anerkannte europäische Sicherheitsanforderungen erfüllt, etwa Zertifizierungsrahmen wie NIS2, DORA und das entstehende EUCS. Die C3A decken diese Domäne bewusst nicht ab: Sie wird bereits durch etablierte BSI-Instrumente bedient, vor allem C5:2026 und IT-Grundschutz.
Betrachtung. Die Ausklammerung ist eine nützliche Erinnerung daran, dass Souveränität und Sicherheit unterschiedliche Achsen sind. Ein souveräner, aber unsicherer Dienst ist eine Gefahr mit besserer Rhetorik; ein sicherer Dienst unter ausländischer Jurisdiktion ist ein Dienst, den man eines Tages verlieren kann. openEduSuite behandelt diese Domäne über seine ZKI-IT-Grundschutz-Ausrichtung, die Hochschullektüre der BSI-Basis, erzwungen als Policy-Code. Die Betrachtung, die bleibt: Das EU CSF stellt SOV-7 in eine Liste von Souveränitätskriterien, aber es ist in Wahrheit das Eintrittsticket. Alles darüber setzt es voraus.
SOV-8: Umweltliche Nachhaltigkeit
Das achte Kriterium fragt nach dem langen Zeitraum: energieeffiziente Infrastruktur, kreislaufwirtschaftliche Hardwarepraktiken und transparente Messung von Emissionen und Ressourcenverbrauch. Es ist die Domäne, die die C3A ausdrücklich ausklammern, nicht weil sie unwichtig wäre, sondern weil sie außerhalb des Auftrags einer Cybersicherheitsbehörde liegt.
Betrachtung. Ihre Ausklammerung aus dem Katalog sagt etwas darüber, wie Souveränität üblicherweise gerahmt wird: als Eigenschaft rechtlicher und technischer Beziehungen, nicht physischer Ressourcen. Doch die Langfristperspektive ist dieselbe Perspektive. Eine Plattform, die sich energetisch oder materiell nicht über Jahrzehnte tragen lässt, ist nicht souverän, was auch immer ihr Vertrag sagt; die Abhängigkeit kommt dann bloß als Kosten und Hardwareknappheit an statt als Schreiben eines ausländischen Gerichts. Die Dienste eines Campus auf einen bescheidenen, gut ausgelasteten Kubernetes-Cluster zu konsolidieren ist unter anderem eine Antwort auf dieses Kriterium, die in keinem Beschaffungsdokument steht.
Was der Gang durch die Kriterien zeigt
Drei Beobachtungen bleiben nach allen acht Kriterien übrig:
- Die Kriterien bilden eine Leiter, und die meisten „souveränen" Angebote bleiben an der ersten Sprosse stehen. Daten-Residenz beantwortet SOV-3 teilweise und sonst nichts. Die Domänen bauen aufeinander auf: rechtlicher Schutz (SOV-2) ist wenig wert ohne operationale Unabhängigkeit (SOV-4), und operationale Unabhängigkeit ist fragil ohne Lieferketten- und technologische Souveränität (SOV-5, SOV-6).
- Für eine selbst betriebene Plattform sind die Kriterien kein Filter, sondern ein Spiegel. An einen Anbieter gerichtet sind es Beschaffungsfragen mit Audit-Antworten. An uns selbst gerichtet werden sie unbequem und nützlich: Könnten wir wirklich ohne Upstream disconnected betreiben (SOV-4)? Kennen wir unsere Lieferkette (SOV-5)? Überlebt das Wissen seine Wartenden (SOV-6)? Die ehrlichen Antworten lauten meist „zunehmend ja, beweisbar nein", eine bessere Ausgangslage als ein Compliance-Abzeichen für einen Dienst, den wir nicht kontrollieren.
- Die beiden ausgeschlossenen Domänen sind die interessanten. SOV-7 zeigt, dass Souveränität ohne Sicherheit eine Pose ist; SOV-8 zeigt, dass Souveränität ohne Nachhaltigkeit temporär ist. Die Grenzen des Katalogs sind so viel wert wie sein Inhalt.
Die acht SOV-Kriterien werden vermutlich dort am meisten wirken, wo sie in Ausschreibungen und Gesetze Eingang finden; doch ihr leiserer Wert liegt im Vokabular. Sie ermöglichen einer Einrichtung, präzise zu sagen, was sie unter Souveränität versteht, und dann zu messen, ob ihre Plattform, gekauft oder gebaut, das tatsächlich erfüllt.
Mitwirken
Wenn Ihre Einrichtung C5-Audits, EU-CSF-Bewertungen oder eigene Disconnect- und SBOM-Praktiken durchlaufen hat, wäre die Perspektive der openEduSuite-Community wertvoll, besonders die unbequemen Befunde.
Besuchen Sie openedusuite.org für Architektur-Dokumentation und Deployment-Guides
Souveränität an einen Anbieter gerichtet ist Beschaffung. An sich selbst gerichtet, ist sie ein Spiegel; die acht SOV-Kriterien sind der Rahmen, der ihn ruhig hält.
Hinweise und Quellen
- Behandelte Rahmenwerke: EU Cloud Sovereignty Framework (Europäische Kommission), Quelle der SOV-1-bis-SOV-8-Struktur und der Vergabegewichtung; BSI C3A (Criteria enabling Cloud Computing Autonomy) (Katalog-PDF; Ankündigung), Quelle der konkreten Kriterien (SOV-4-09-C, SOV-4-01-C1/C2 und weitere) und der bewussten Ausklammerung von SOV-7 und SOV-8.
- Interpretation: Die Betrachtungen zu openEduSuite sind Selbsteinschätzungen des Projektteams, keine Audit-Befunde. Aussagen dazu, was der C3A-Katalog verlangt, folgen den veröffentlichten Kriterien; wo Berichterstattung (heise online, Computer Weekly, April 2026) in die Lektüre einging, wird sie hier genannt.
- Keine Zusammenarbeit: openEduSuite ist nicht mit dem BSI, der Europäischen Kommission oder einem Cloud-Anbieter verbunden. Dieser Artikel ist keine Rechtsberatung.
- Marken-Hinweis: Alle genannten Produkt- und Standardnamen (C5, C3A, IT-Grundschutz, NIS2, DORA, EUCS, Kubernetes, Keycloak, DFN-AAI, Nix, MariaDB) werden ausschließlich zur Identifikation und informationellen Beschreibung verwendet.
