Die souveräne Cloud ist kein Nischenthema mehr. Vorgaben der EU-Mitgliedstaaten, Souveränitätsklauseln auf dem Beschaffungsportal Kasachstans und mehrere Initiativen im asiatisch-pazifischen Raum haben Souveränität zu einer eigenen Marktkategorie gemacht. Die „souveränen“ Regionen der Hyperscaler versuchen, darauf zu antworten, stoßen aber an strukturelle Grenzen (Bindung an US-Anbieter, Abhängigkeiten in der Control Plane).
Die Chance für eigens gebaute souveräne Cloud-Produkte ist real — doch der Aufwand für Engineering, Zertifizierung und Betrieb ist erheblich.
Was Souveränität wirklich bedeutet
Souveränität ist mehr als Datenresidenz. Die vollständigen Anforderungen:
- Datenresidenz auf jeder Ebene — Produktion, Backup, Observability, CI/CD, Telemetrie
- Verschlüsselung mit vom Kunden kontrollierten Schlüsseln — HSM, dokumentierte Rotation, Verfahren für den Notfallzugriff
- Open-Source-Fundament der Plattform — Transparenz und Ausstiegsfähigkeit
- Transparente Lieferkette — mindestens bis zur zweiten Stufe
- Air-Gap-Option für die sensibelsten Workloads
- Vollständiger Audit-Trail in Formaten, die die Aufsicht verarbeiten kann
- Keine Phone-Home-Telemetrie — nur Opt-in
- Betriebliche Unabhängigkeit — das Team der souveränen Cloud untersteht einer souveränen Rechtsordnung
Ein „souveränes Cloud“-Produkt, das nicht alle diese Punkte substanziell erfüllt, scheitert beim Audit der Aufsicht.
Konkrete Regelwerke zur Souveränität
Jede Rechtsordnung hat ihr eigenes Regelwerk:
EU
- EUCS (EU Cybersecurity Certification Scheme for Cloud Services) — vorgeschlagenes EU-weites Schema (Annahme ausstehend)
- SecNumCloud (Frankreich) — strenge französische Souveränitätsanforderung
- BSI C5 (Deutschland) — deutscher Kriterienkatalog für Cloud-Sicherheit
- DORA — speziell für Finanzdienstleistungen, gilt für Cloud-Provider, die Banken bedienen
- NIS2 — breitere Cybersicherheit; Cloud-Anbieter gehören zu einem Sektor nach Anhang I (wesentliche oder wichtige Einrichtungen, je nach Größe)
Zentralasien
- Kasachstan — durch die Beschaffung vorgeschriebene Souveränität für Workloads des öffentlichen Sektors.
- Weitere GUS-Staaten — verschiedene nationale Regelwerke im Entstehen
Andere Regionen
- Französisches SecNumCloud außerhalb Frankreichs: wird zunehmend als Referenz herangezogen
- Asien-Pazifik — Singapur IM8, Indien MeitY, Australien IRAP usw.
Architekturmuster für die souveräne Cloud
Muster 1: vollständig On-Premises betriebene souveräne Cloud
Hardware des Kunden, vom Kunden betrieben, auf jeder Ebene vom Kunden kontrolliert. Maximale Souveränität bei maximalem Betriebsaufwand. Richtig für die sensibelsten Workloads (Verschlusssachen, Kernbankensysteme).
Muster 2: verwaltete souveräne Cloud
Hardware des Cloud-Providers + souveräne Rechtsordnung + vom Kunden kontrollierte Schlüssel + transparente Lieferkette. Vereinfachter Betrieb bei substanzieller Souveränität. Richtig für die meisten regulierten Unternehmens-Workloads.
Muster 3: Hybrid aus souveräner und nicht souveräner Cloud
Workloads mit kritischen Funktionen auf der souveränen Cloud, unkritische beim Hyperscaler. Ein verbreitetes Muster bei Finanzdienstleistern.
Muster 4: souveräne Edge-Cloud
Die souveräne Cloud wird auf Edge-Standorte innerhalb der Rechtsordnung verteilt. Richtig für Workloads, die sowohl Souveränität als auch Nähe zum Edge brauchen (IoT, Telco).
Cozystack als Fundament der souveränen Cloud
Cozystack ist Open Source (Apache 2.0), wird als CNCF-Projekt gesteuert (die Roadmap bestimmt die Community), unterstützt Air-Gap-Installationen, Volume-Verschlüsselung mit Schlüsseln beim Kunden (Opt-in) und Audit-Logs, die sich in Systeme des Kunden ausleiten lassen.
Speziell für Betreiber souveräner Clouds:
- Mandantenmodell mit dem Tenant CRD — für ein souveränes Cloud-Produkt für Endkunden
- Cozystack Dashboard — Self-Service-Oberfläche für Kunden
- Integration der WHMCS-Abrechnung — für ein Abonnement-Angebot an Endkunden (ein Ænix-Produkt auf Basis von Cozystack, keine Upstream-Komponente)
- Air-Gap-Installation unterstützt und dokumentiert
- VictoriaMetrics + VictoriaLogs — selbst gehostete Observability (keine SaaS-Abhängigkeit)
- Cilium-Netzwerk — souveränitätsfreundlich, keine Abhängigkeit von einer proprietären Netzwerkplattform
Zeitplan der Umsetzung
Ein souveränes Cloud-Produkt aufzubauen dauert länger als eine nicht souveräne Cloud:
- Discovery + Assessment: kostenloses 30-minütiges Discovery-Gespräch, danach ein Platform Readiness Assessment zum Festpreis (14 oder 28 Tage)
- Einzelner Anbieter im Providermaßstab: Plattform mit dem produktisierten Installer wenige Wochen nach Bereitstellung der Hardware live
- Nationales oder Betreiberprogramm: 3–6 Monate Pilot, danach 9–18 Monate bis zum vollen Multi-Region-Betrieb
- Zertifizierung: läuft parallel zum Aufbau; ihr Umfang kann den Termin des ersten zertifizierten Dienstes verschieben
- Onboarding der Kunden: fortlaufend
Zusammenarbeit mit Ænix
Ænix baut souveräne Cloud-Produkte von Anfang bis Ende, mit einem Team von rund 20 Personen in der EU und in Zentralasien. Open-Source-Fundament. Dokumentation, die für die Beschaffung bereit ist.
Details finden Sie auf der Seite zum Sovereign Cloud Builder und bei der Ænix Public Cloud Platform.
Wissens-Check: eine souveräne Cloud aufbauen
5 questions · ~2 min
