Praxisleitfaden 03 / 05
Eine souveräne Cloud für Behörden muss mehr leisten als einen passenden Rechenzentrumsstandort. Sie soll sichere Nutzung ermöglichen und zugleich die Entscheidungsfähigkeit der Organisation erhalten: beim Zugriff auf Daten, beim Betrieb und bei einem späteren Anbieterwechsel.
Die kurze Antwort: erst Workload, dann Cloud entscheiden
Prüfen Sie einen konkreten Dienst anhand von Schutzbedarf, Abhängigkeiten, Wiederanlauf und Exit-Anforderungen. Erst danach vergleichen Sie Betriebsmodelle. Eine Plattform ist nicht allein deshalb geeignet, weil sie einen bekannten Standard nachweist. Das BSI stellt klar, dass eine C5-Testierung keine BSI-Zertifizierung ist und für sich allein nicht alle Anforderungen seines Mindeststandards zur Nutzung externer Cloud-Dienste erfüllt. [1]
Das Problem zeigt sich oft bei der Verlängerung
Die Anwendung funktioniert. Aber der Vertrag läuft aus, der Export wurde nie getestet und nur der bisherige Dienstleister kennt das Deployment. Ein Wechsel erscheint theoretisch möglich, praktisch jedoch kaum kalkulierbar. Dieses beispielhafte Szenario beschreibt eine Abhängigkeit, die weder eine Standortangabe noch ein Architekturdiagramm allein sichtbar macht.
Souveränität ist deshalb eine nachweisbare Fähigkeit – kein Produktetikett.
Wo Cloud-Abhängigkeiten in der Verwaltung entstehen
Der Container ist portabel, seine Umgebung nicht
Eine Anwendung kann in einem Standardcontainer laufen und dennoch an proprietäre Datenbanken, Identitätsdienste oder Workflow-Funktionen gebunden sein. Prüfen Sie daher die komplette Abhängigkeitskette. Ein anderer Kubernetes-Cluster hilft wenig, wenn wesentliche Funktionen außerhalb des Clusters nicht ersetzt werden können.
Datenexport wird mit betrieblicher Nutzbarkeit verwechselt
Eine Sammlung heruntergeladener Dateien bildet noch kein funktionsfähiges Verfahren. Zu den Daten gehören Beziehungen, Versionen, Berechtigungen, Schlüsselabhängigkeiten und gegebenenfalls Aufbewahrungsinformationen. Auch Exportdauer, Bandbreite und Gebühren beeinflussen den Wechsel. Diese Eigenschaften lassen sich an einem repräsentativen Datenbestand messen.
Schlüsselhoheit wird zu pauschal versprochen
Eigene Schlüssel können bestimmte Zugriffe begrenzen. Ob der Betreiber auf Klartext zugreifen kann, hängt aber von Verarbeitung, Berechtigungen und Betriebsmodell ab. BYOK oder HYOK sind deshalb kein universeller Nachweis für vollständige Zugriffsfreiheit des Providers. Entscheidend ist eine nachvollziehbare Beschreibung der konkreten Daten- und Schlüsselflüsse.
Prüffrage: Können Sie für einen kritischen Dienst benennen, wer Daten lesen, Identitäten ändern, Software ausliefern und das System wiederherstellen darf?
Das Zielbild: sicherer Primärbetrieb mit realistischem Exit
Daten, Identitäten und Betrieb getrennt betrachten
Definieren Sie einen Exportvertrag mit Formaten und Metadaten. Dokumentieren Sie Rollen und maschinelle Identitäten, nicht nur Benutzerkonten. Standards für Anmeldung erleichtern Integration; sie garantieren aber nicht, dass ein anderer Anbieter dieselben Rollen- und Gruppenmodelle versteht. Ein Wechsel braucht deshalb fachliche und technische Zuordnungstests.
Zugriff nach Ressourcenbedarf statt Netzstandort
Eine private Verbindung ersetzt keine differenzierte Autorisierung. NIST beschreibt Zero Trust als ressourcenorientierten Ansatz ohne automatisches Vertrauen allein aufgrund des Netzwerkstandorts. [2] Für das Zielbild bedeutet das: eng begrenzte Rechte, nachvollziehbare Freigaben und wirksame Kontrolle administrativer Zugriffe.
Betrieb reproduzierbar und übernehmbar machen
Infrastrukturdefinitionen, Konfiguration, Build-Artefakte, Monitoring und Wiederherstellungsanleitungen gehören in ein kontrolliertes Übergabepaket. Auch Infrastructure as Code ist nicht automatisch cloudunabhängig: Provider-spezifische Module können weiter Lock-in erzeugen. Dokumentieren Sie deshalb, was wiederverwendbar ist und was bei einem Wechsel neu erstellt werden muss.
Ein primärer Betriebsort mit getesteter Wechselmöglichkeit kann sinnvoller sein als dauerhaft zwei vollständige Plattformen. Multi-Cloud ist eine Option, kein Selbstzweck. Die Entscheidung richtet sich nach Ausfallfolgen, Kosten, Teamkapazität und den Anforderungen des konkreten Dienstes.
So funktioniert ein belastbarer Cloud-Exit-Test
1. Ein realistisches Szenario festlegen
Unterscheiden Sie geplanten Anbieterwechsel und Notfallwiederherstellung. Ein Vertragsende mit Vorlauf ist etwas anderes als ein plötzlich nicht erreichbarer Anbieter. Legen Sie Zielumgebung, Datenumfang, erlaubte Unterbrechung und die angenommene Verfügbarkeit des bisherigen Providers fest. Sonst beweist der Test etwas anderes, als die Leitung erwartet.
2. Export und Abgleich durchführen
Prüfen Sie nicht nur Datensätze, sondern auch Anhänge, Beziehungen und Berechtigungen. Messen Sie Übertragungsdauer und erforderliche Nacharbeiten. Abweichungen werden protokolliert und fachlich bewertet. Die Testumgebung benötigt einen angemessenen Schutz; ein Exit-Test ist kein Grund, sensible Daten unkontrolliert zu kopieren.
3. Auf einem alternativen Ziel wieder anlaufen
Bauen Sie den Dienst aus dokumentierten Artefakten auf. Erzeugen oder rotieren Sie Zugangsdaten kontrolliert, prüfen Sie Zertifikate, Namensauflösung und Schnittstellen. Führen Sie fachliche Referenztests und einen definierten Lasttest aus. Halten Sie fest, welche Schritte ohne Hilfe des bisherigen Betreibers möglich waren.
4. Den Test in eine Beschaffungsentscheidung übersetzen
Das Ergebnis ist eine Liste konkreter Wechselhindernisse mit Aufwand, Verantwortung und Behebungsoption. Diese Liste kann Vertragsanforderungen und die nächste Modernisierungsphase begründen. Sie ist belastbarer als ein pauschaler Souveränitäts-Score.
Wichtig: Wiederanlaufzeit und tolerierbarer Datenverlust beschreiben Notfallziele; sie sind nicht automatisch die Fristen eines vollständigen Cloud-Exits. Beide Szenarien brauchen eigene Annahmen und Abnahmen.
C5, Betriebskosten und Vergabe richtig zusammenbringen
Ein C5-Prüfbericht ist anhand seines Geltungsbereichs, des Prüfzeitraums, der Feststellungen und der beim Kunden verbleibenden Aufgaben zu bewerten. Das BSI stellt dafür einen Auswertungsleitfaden bereit. [3] Ein Logo in einem Vertriebsdeck ersetzt diese Prüfung nicht. Ein Testat ist auch keine pauschale Bestätigung datenschutzrechtlicher Zulässigkeit oder vollständiger Souveränität.
Rechnen Sie den Wechsel mit ein
Die Gesamtkosten umfassen Plattform, Betriebsteam, Lizenzen, Netzwerk, Backup, Sicherheitsnachweise und einen späteren Übergang. Für eine Option mit niedrigeren laufenden Preisen kann ein erheblicher Integrations- und Exit-Aufwand entstehen. Vergleichen Sie Szenarien, statt unterschiedliche Leistungen in einer einzigen Monatsgebühr zu verstecken.
Illustratives Beispiel: Ein Exit benötigt 30 Personentage Anpassung und zehn Tage Tests. Der Ansatz beträgt somit 40 Personentage zuzüglich Parallelbetrieb und Übertragungskosten. Ein erfolgreich getesteter Datenexport allein hätte nur einen Teil davon gezeigt. Dies ist ein Kalkulationsbeispiel, keine Aufwandsschätzung für ein konkretes Projekt.
Ein begrenzter Einstieg mit Insight42
Prüfen Sie einen kritischen Workload vor der nächsten Migration oder Vertragsverlängerung. Insight42 beschreibt ein Sovereign Cloud Assessment als Teil seines Leistungsangebots. [4] Ein sinnvoller Auftrag verbindet Datenfluss, Abhängigkeitsregister, Bewertung der Betriebsnachweise und einen umsetzbaren Exit-Testplan. Umfang, Prüftiefe und Liefergegenstände werden individuell vereinbart.
Kontakt: support@insight42.com. Nennen Sie Dienst, bisheriges Betriebsmodell und den anstehenden Entscheidungspunkt. Für den ersten Austausch reichen abstrahierte Angaben ohne Systemzugänge oder vertrauliche Architekturunterlagen.
Häufige Fragen zur souveränen Cloud
Reicht ein Rechenzentrum in Deutschland aus?
Nein. Der Standort beantwortet nicht vollständig, wer administrative Zugriffe hat, wie Unterauftragnehmer eingebunden sind und ob Daten und Anwendungen übertragbar bleiben. Diese Fragen müssen zum konkreten Service und Vertragsmodell beantwortet werden.
Brauchen wir zwingend Kubernetes?
Nein. Eine gut dokumentierte virtuelle Maschine kann für einen kleinen, stabilen Dienst angemessener sein. Kubernetes ist dann sinnvoll, wenn seine Betriebs- und Automatisierungsvorteile den zusätzlichen Aufwand rechtfertigen. Die Plattformwahl folgt dem Bedarf, nicht umgekehrt.
Ist ein C5-Testat eine BSI-Zertifizierung?
Nein. Das BSI grenzt die unabhängige Testierung ausdrücklich von einer BSI-Zertifizierung ab. Prüfen Sie den konkreten Bericht und die Anforderungen Ihrer Organisation, statt aus dem Vorhandensein eines Testats eine pauschale Freigabe abzuleiten. [1]
Müssen wir permanent zwei Clouds betreiben?
Nicht automatisch. Ein alternativer Wiederanlauf oder ein getesteter Exit kann je nach Ziel ausreichen. Dauerhafter Parallelbetrieb ist nur dann sinnvoll, wenn die zusätzlichen Kosten und die Komplexität durch konkrete Anforderungen gerechtfertigt sind.
Fazit: Gute Cloud-Beschaffung sichert nicht nur den Eintritt in eine Plattform ab. Sie schafft auch die technischen und organisatorischen Voraussetzungen, sie wieder verlassen zu können.
Quellen und fachliche Referenzen
[1] BSI: FAQ zum Mindeststandard Externe Cloud-Dienste
[2] NIST: SP 800-207, Zero Trust Architecture
[3] BSI: Auswertungsleitfaden für C5-Prüfberichte
[4] Insight42: Souveräne Cloud Beratung
Quellenstand: 27.09.2026. Rechenbeispiele und Diagramme dienen der Erläuterung.