Datenschutz & Sicherheit
BSI definiert, wann eine Cloud wirklich souverän ist
Nicht erst seit dem Beginn der zweiten Amtszeit Donald Trumps wird diskutiert, ob die Abhängigkeit von nichteuropäischen Cloud-Anbietern zu groß ist – von Hyperscalern wie AWS und Azure ebenso wie von Alibaba oder Huawei Cloud. Insbesondere für sicherheitskritische Anwendungen der öffentlichen Verwaltung und für Betreiber kritischer Infrastrukturen und Dienstleistungen gilt: Auf der Suche nach performanten und unabhängigen Lösungen gibt es viele Versprechungen – doch bei den Kriterien gibt es oft wenig Klarheit. Ist eine Cloudlösung souverän, wenn sie technisch sicher in der EU betrieben wird? Unabhängig von der Infrastruktur eines US-Unternehmens? Ohne Abhängigkeit von Instanzen außerhalb? Technische IT-Sicherheit ist das eine, technische Souveränität ein nicht immer deckungsgleiches Anforderungsprofil.
Weiterlesen nach der Anzeige
Die engeren Sicherheitseigenschaften von Cloud-Diensten definiert bereits der kürzlich aktualisierte Cloud Computing Compliance Criteria Catalogue (C5). Der nun vorgestellte Vorschlag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) setzt beim zweiten Begriff an: Die Fachleute der Bonner Bundesbehörde haben mit ihren heute veröffentlichten „Criteria Enabling Cloud Computing Autonomy“ (C3A) einen Vorschlag vorgelegt. Nutzer sollen damit von vornherein prüfen können, ob ein Dienst tatsächlich zu ihrem jeweiligen Souveränitäts-Risiko passt. Die Behörde begleitet die Diskussionen seit vielen Jahren als IT-Sicherheitsdienstleister der Bundesverwaltung. Sie will damit vor allem eines leisten: „Es geht uns um technisch tragfähige Lösungen, die konkrete Bedingungen formulieren“, sagt Thomas Caspers, Vizepräsident des BSI.
Für den IT Summit 2026 suchen wir praxisnahe Berichte von Menschen, die Projekte zur digitalen Souveränität planen, leiten oder umsetzen. Vorträge und Keynotes auf dem IT Summit dauern 45 Minuten inklusive 5 Minuten Fagen und Antworten. Idealerweise kombinieren sie praktische Erfahrungen mit technischer Tiefe, sodass die Zuhörer und Zuhörerinnen konkrete Learnings mit nach Hause nehmen. Reichen Sie Ihre Vortragsideen bis zum 17. Mai 2026 ein.
Weniger diplomatisch interpretiert: Statt politisch lange über die Unabhängigkeit eines Anbieters zu diskutieren, will die Behörde mit einem konkreten Vorschlag in die Debatte um die Folgen des Cloud and AI Development Act (CADA) einsteigen. Den CADA will die EU-Kommission nach aktueller Zeitplanung am 27. Mai vorlegen; anschließend beraten ihn Mitgliedstaaten und Europaparlament. Denn Beobachter erwarten, dass EU-Vizekommissionspräsidentin Henna Virkkunen mit dem CADA klarere Kriterien für Cloud-Souveränität vorgibt – und Diskussion und Lobbying mit der Vorstellung des Vorhabens im Mai erst richtig beginnen.
Praxiserfahrungen und EU-Kriterien
Dabei baut das BSI unter anderem auf sechs der acht Kriterien auf, die die eigentlich nur für die EU-Kommissions-eigene IT zuständige Generaldirektion DIGIT im vergangenen Jahr definiert hatte und konkretisiert diese um breitere Erfahrungen. Vor allem die französische IT-Sicherheitsbehörde ANSSI und das BSI haben umfangreiche Erfahrungen mit verschiedenen Abhängigkeitsvariationen gesammelt – in Deutschland zum Beispiel mit der SAP-Microsoft-Kooperation DelosCloud, mit Stackit von Schwarz-Digits oder der T-Systems-Sovereign-Cloud in Kooperation mit Google, mit Anforderungen etwa für „Polizei 2020“ (P20) oder für Amazons European Sovereign Cloud-Angebot. Parallel testete die dem französischen Premierminister unterstellte Behörde einen anderen Pfad, bei dem für die öffentliche Verwaltung stets französische Unternehmen beteiligt sind – beispielsweise der Rüstungskonzern Thales beim im Dezember nach den französischen SecNumCloud-Anforderungen zertifizierten S3NS, das zusammen mit Google betrieben wird oder etwa SAP auf OVH-Hardware.
Genau solche Erfahrungen sollen nun für die Zukunft relevant werden. Dass das BSI die C3A-Systematik nicht im luftleeren Raum entwickelt hat, sondern auch mit Anbietern gesprochen hat, zeigen auch eng daran angelehnte eigene Bewertungsstandards aus der Branche. „Wir haben unter anderem am Beispiel der AWS European Sovereign Cloud gesehen, wie viele Mechanismen eine Rolle spielen, um eine Cloud betriebsfähig zu halten“, erklärt Caspers. „Komplett entkoppelt wird man solche Angebote aber nicht über Jahre weiterbetreiben können.“
Kriterien vom Disconnect bis zum Verteidigungsfall
Weiterlesen nach der Anzeige
In den C3A sieht das dann beispielsweise so aus: SOV-4-09-C der C3A definiert, was bei einem Disconnect – also der Abkopplung von der außereuropäischen Betreibercloud – gewährleistet sein muss: Im Kern muss der Betrieb weiterlaufen, ohne dass Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit leiden. Zudem muss es einen dokumentierten Prozess für das Vorgehen und die Durchführung der Abkopplung geben und der Betreiber muss dies mindestens einmal jährlich getestet und dokumentiert haben, inklusive der Ergebnisse des Tests. Wer das weitergehende Kriterium SOV-4-09-AC erfüllen will, muss zudem seine Dokumentation mit den zuständigen IT-Sicherheitsbehörden am Ort des Rechenzentrums auf deren Verlangen hin teilen.
Ähnlich konkret sind auch die Vorgaben in juristischer Hinsicht, etwa wenn es darum geht, dass die Anbieter keiner Nicht-EU-Jurisdiktion unterliegen dürfen oder bei der Frage, von wo aus Mitarbeiter die wesentlichen IT-Pflegemaßnahmen durchführen. Und auch bei der Auswahl der Mitarbeiter gibt es entsprechend gestufte Kriterien: So verlangt SOV-4-01-C1, dass alle Mitarbeiter, die logischen oder physischen Zugang zu Betriebsmitteln des Clouddienstleisters haben, eine EU-Staatsbürgerschaft und einen EU-Wohnsitz haben müssen – noch schärfer ist die Anforderung nach SOV-4-01-C2: dann müssen alle Mitarbeiter nicht nur EU-Bürger sein, sondern auch ihren Wohnsitz innerhalb der Bundesrepublik haben.
Dieses Kriterium kommt insbesondere für Hochsicherheitsanwendungen in Frage, etwa für Sicherheitsbehörden oder auch die Bundeswehr. Für die hat das BSI zwar keine direkte gesetzliche Zuständigkeit. Doch für den Fall der Fälle enthalten die C3A ebenfalls Prüfkriterien. Denn was im grundgesetzlich geregelten Verteidigungsfall erfüllt sein sollte, wird nun auch klar definiert: entsprechend dem Muster aller Notstandsgesetzgebung müssen Clouddienstleister in der Lage sein, den Betrieb an die Bundesbehörden zu übergeben – „inklusive des notwendigen Materials und Personals“.
Potenziell weitreichende Auswirkungen
So wie ursprünglich auch beim C5-Katalog, der zwischenzeitlich jedoch etwa im Sozialgesetzbuch für die Gesundheits-IT qua Gesetz für verbindlich erklärt wurde, ist das bei den C3A ebenfalls nicht direkt der Fall. „Die Criteria Enabling Cloud Computing Autonomy sind aus sich heraus nicht verbindlich“, erklärt Caspers. „Sie können aber natürlich im Rahmen von Gesetzgebung oder bei Ausschreibungen zu Mindestanforderungen erklärt werden.“ Die C3A können jedoch, meint der Vizepräsident des Bundesamtes für Sicherheit in der Informationstechnik, „zur Benchmark der Bundesverwaltung werden.“
Das kommt auch durch eine Wechselwirkung der Vorgaben. „Stellen des Bundes sind verpflichtet, den IT-Grundschutz des BSI umzusetzen“, erklärt Martin Bierwirth, Referatsleiter Cloud-Sicherheit beim BSI. „Sofern sie externe Cloud-Dienste nutzen, müssen sie in diesem Rahmen auch den Baustein OPS 2.2 anwenden und erfüllen.“ Auf diesem baue auch der Mindeststandard zur Nutzung externer Cloud-Dienste (MST-NCD) auf. Die C3A wiederum würden auf dem C5 aufbauen und dessen Kriterien zur Informationssicherheit mit dem Thema digitale Souveränität ergänzen. Wer also nicht nur sichere, sondern auch souveräne Vorgaben erfüllen muss, wird darum in der Bundesrepublik absehbar schwer herumkommen. Ob große Hyperscaler diese erfüllen können, dürfte vom jeweiligen Anforderungsprofil der Kunden abhängen – und vom Druck, souveräne Lösungen wählen zu müssen.
Je nachdem, wie sich die europäische Diskussion weiterentwickelt, könnten die neuen Kriterien aber auch jenseits von Rhein und Oder eine maßgebliche Rolle spielen. Sollten mit dem Cloud and AI Development Act der EU solche Kriterien Einzug in die Anhänge der IT-Sicherheitsgesetze wie NIS2 oder Cybersecurity Act finden, würde wohl kaum ein Weg an dem deutschen Vorschlag vorbeiführen.
Lesen Sie auch
(fo)