Können Nicht-EU-Anbieter digitale Souveränität garantieren?

Was bedeutet digitale Souveränität eigentlich?

Im EU-Kontext (PDF) geht es dabei nicht nur um Sicherheit oder Compliance, sondern um Kontrolle:

• Wer hat Zugriff auf die Daten?
• Unter wessen Rechtshoheit steht die Infrastruktur?
• Kann die EU beziehungsweise der Kunde den Betrieb auch dann weiterführen, wenn der Anbieter plötzlich politisch oder wirtschaftlich wegfällt?
• Kann ich jederzeit wechseln (Vendor-Lock-in vermeiden)?

Mit anderen Worten geht es um technologische, operative und juristische Unabhängigkeit – es reicht nicht aus, dass „unsere Daten in Frankfurt liegen“.

Der Hauptkonflikt mit Nicht-EU-Anbietern

Extraterritoriale Gesetze

Der US CLOUD Act erlaubt US-Behörden, von US-Unternehmen Zugriff auf Kundendaten zu verlangen – auch dann, wenn diese Daten physisch in der EU gespeichert werden. Damit wirkt US-Recht extraterritorial in europäische Umgebungen hinein.

Microsoft hat in Anhörungen und öffentlichen Stellungnahmen bestätigt, dass das Unternehmen einer rechtmäßigen US-Anordnung grundsätzlich folgen müsste, selbst wenn betroffene Daten laut EU-Data-Boundary-Modell innerhalb der EU verarbeitet werden. Zwar betont Microsoft, dass unrechtmäßige oder zu weit gehende Anfragen angefochten werden, räumt aber ein, dass sich ein absoluter Ausschluss nicht garantieren lässt. Das gilt nicht nur für Microsoft, sondern für alle US-Anbieter.

Auch chinesische Anbieter dürften mit den Vorgaben in ihrem Heimatland zu kämpfen haben: Nach chinesischen Sicherheits- und Nachrichtendienstgesetzen sind Unternehmen verpflichtet, staatliche Stellen bei Informations- und Geheimdiensttätigkeiten zu unterstützen und auf Anforderung Daten oder technische Unterstützung bereitzustellen – auch wenn die Daten im Ausland liegen.

Das ist der Kern der Souveränitätsdebatte: Entscheidend ist nicht nur der Speicherort der Daten, sondern auch die anwendbare Jurisdiktion über den Anbieter.

Governance/Admin-Zugriff

Auch wenn Workloads in einer EU-Region laufen, stellt sich die Frage, wer operativ Zugriff hat. Wer darf auf Managementebenen eingreifen? Wer betreibt SOCs? Wer verwaltet Zertifikate? Wer sieht Metadaten und Support-Dumps? Aus Sicht europäischer Regulierer reicht eine reine EU-Region nicht aus, wenn die operative Kontrolle, die Schlüsselverwaltung oder die Incident Response außerhalb des EU-Rechtsraums stattfinden.

Genau deshalb versprechen Sovereign-/EU-Cloud-Modelle inzwischen, dass nur Personal mit Wohnsitz (und zunehmend sogar mit Staatsbürgerschaft) in der EU kritische Admin-Tätigkeiten ausführen darf. Dazu gehört auch der Zugang zu Rechenzentren, technischem Support und Kundendaten-Metadaten. Neu ist das allerdings nicht, IBM versuchte das schon 2018 und Microsoft nutzte 2016 die Deutsche Telekom als Datentreuhänder.

Strategische Abhängigkeit

Digitale Souveränität wird in Brüssel nicht mehr nur als Datenschutzthema verstanden, sondern als Teil der europäischen strategischen Autonomie: Die EU soll kritische digitale Dienste auch dann weiterbetreiben können, wenn Exportkontrollen, Sanktionen oder Lizenzauflagen aus Drittstaaten greifen würden.

Solange der Kernstack – also die Codebasis, Updates, Security-Patches und die Produkt-Roadmap – einem außereuropäischen Mutterkonzern gehört, bleibt ein geopolitisches Abhängigkeitsrisiko bestehen. Dieses Risiko wird inzwischen offen angesprochen, zum Beispiel unter dem Punkt strategische Autonomie in der digitalen Infrastruktur.

Wie Nicht-EU-Anbieter die Vorgaben erfüllen wollen

US-Hyperscaler bauen für Europa eigene souveräne Cloud-Angebote auf. Diese sollen technisch, organisatorisch und rechtlich vom globalen Standardbetrieb abgetrennt werden. Zielgruppe sind Behörden, kritische Infrastrukturen und regulierte Branchen in der EU. Ein prominentes Beispiel ist die AWS European Sovereign Cloud: eine eigenständige Cloud-Umgebung ausschließlich innerhalb der EU, physisch und logisch getrennt von anderen AWS-Regionen, mit dem Anspruch, dass es keine kritischen Abhängigkeiten von nicht-europäischer Infrastruktur gibt.

Technisch liefern auch chinesische Anbieter heute Konzepte, die formal wie Sovereign Cloud aussehen. Huawei bewirbt zum Beispiel seine Sovereign-Cloud- beziehungsweise National-Sovereign-Cloud-Modelle, bei denen die Cloud-Umgebung im jeweiligen Land betrieben wird. Daten „dürfen das Land nicht verlassen“, der operative Betrieb soll durch ein lokales (nationales) Team erfolgen und Huawei nur noch technischen Support leistet. Für besonders kritische Umgebungen wird ein Air-gapped-Betriebsmodell angeboten, also physisch vom Huawei-Backend abgetrennt.

In der Debatte wird fast immer nur über USA und China gesprochen. Auch Anbieter aus dem Vereinigten Königreich oder Israel können viele operative Anforderungen an digitale Souveränität formal erfüllen. Dazu gehören Datenhaltung in der EU, Betrieb durch EU-Personal, getrennte Verwaltungs- und Abrechnungssysteme, europäische Schlüsselkontrolle sowie eine eigene Vertrauens- und Zertifikatsinfrastruktur. Technisch unterscheiden sie sich damit nicht grundlegend von US-Anbietern und können für viele regulierte Einsatzbereiche ein souveränes Betriebsmodell bereitstellen, das prüf- und auditierbar ist.

Auf der juristischen Ebene bleibt jedoch das gleiche Grundproblem bestehen: Sowohl das Vereinigte Königreich (Investigatory Powers Act) als auch Israel (nationale Sicherheits- und Nachrichtendienstgesetze) können Anbieter verpflichten, Daten oder Zugänge bereitzustellen – auch dann, wenn sich diese Daten physisch in der EU befinden und durch EU-Personal betrieben werden. Diese extraterritorialen Zugriffsbefugnisse sind aus europäischer Sicht nicht vertraglich vollständig ausschließbar. Das bedeutet: Anbieter aus dem Vereinigten Königreich und Israel können Souveränität nach dem operativen/compliance-orientierten Verständnis liefern, aber sie können – genauso wie Anbieter aus den USA oder China – keine absolute Garantie geben, dass kein externer staatlicher Zugriff erfolgt.

Ein weiterer wichtiger Technologielieferant ist Taiwan. Das Land kann technisch gesehen durchaus souveräne Betriebsmodelle anbieten, zu denen lokale Datenhaltung, lokale Kontrolle, regulatorische Aufsicht und starke Datenschutzvorgaben gehören. Aus Sicht der digitalen Souveränität Europas bleiben jedoch zwei Einschränkungen bestehen: Erstens liegt die letztliche Rechts- und Eingriffshoheit nicht bei der EU, sondern bei den taiwanischen Behörden. Zweitens besteht ein geopolitisches Kontinuitätsrisiko, da Taiwan als politisch verwundbar gilt, insbesondere was zentrale Technologie- und Lieferkettenpunkte betrifft. Damit ist Taiwan – ähnlich wie die USA, das Vereinigte Königreich oder Israel, jedoch aus anderen Gründen – kein Anbieterstandort, der eine garantierte Souveränität im engeren Sinne der EU zusichern könnte, insbesondere für hochkritische beziehungsweise staatlich sensible Workloads.

Zentrale Elemente souveräner Cloud-Ansätze sind:

• Betrieb und Zugriff (Operations Control): Der laufende Betrieb, also Zugang zu Rechenzentren, technischer Support, Incident Response und Kundenservice, soll ausschließlich von in der EU ansässigem Personal erbracht werden. Dadurch soll sichergestellt werden, dass operative Eingriffe nicht außerhalb des EU-Rechtsraums stattfinden.
• Metadaten- und Verwaltungsisolation: Neben den Nutzdaten (Workloads, Dateien, Datenbanken) sollen auch Betriebs- und Nutzungsmetadaten – also beispielsweise Logs, IAM-Informationen, Abrechnungs- und Support-Daten – innerhalb der EU verbleiben und eigenständig abgerechnet, verwaltet und auditiert werden.
• Vertrauens- und Zertifikatsinfrastruktur in der EU: Für die europäische Sovereign Cloud wird ein eigener europäischer Trust Service Provider (TSP) aufgebaut. Dieser betreibt die Zertifizierungsstelle (Certificate Authority, CA) sowie das zugehörige Root-Schlüsselmaterial vollständig innerhalb der EU und unterliegt damit dem EU-Recht. Das Ziel besteht darin, die kryptografische Vertrauensbasis – also die Frage, wer Zertifikate ausstellen und damit gesicherte Verbindungen autorisieren darf – nicht mehr von außerhalb steuern zu lassen.
• Verschlüsselung und Schlüsselkontrolle: Souveräne Cloud-Angebote koppeln Datenverschlüsselung technisch an europäische Kontrolle über die Schlüssel. Das umfasst Modelle wie External Key Management/BYOK und Confidential Computing, bei denen der Kunde oder ein europäischer Dienstleister die Schlüssel verwaltet und der Cloud-Anbieter ohne diese Schlüssel theoretisch keinen Klartextzugriff hat. Diese Anforderung – Ende-zu-Ende-Verschlüsselung plus ausschließliche europäische Kontrolle über die Schlüsselverwaltung – findet sich in nationalen Vorgaben wie der französischen SecNumCloud-Spezifikation (Version 3.2). Diese verlangt explizit, dass Verschlüsselungs-Keys und Administrator-Keys strikt kontrolliert und ausschließlich innerhalb europäischer Jurisdiktion gehalten werden.

Im Ergebnis versuchen die Anbieter, drei Kernkritikpunkte europäischer Aufsichtsbehörden auszuräumen: erstens den operativen Zugriff von außerhalb der EU, zweitens die Abwanderung von Metadaten und Vertrauensankern und drittens die faktische Schlüsselhoheit über verschlüsselte Daten. Mit dieser Architektur soll demonstriert werden, dass der Betrieb der Cloud, der Support und die Kryptografie vollständig im EU-Rechtsraum stattfinden können – und nicht nur die Serverhardware.

Das Cloud Sovereignty Framework der EU definiert acht messbare Souveränitätsziele (SOV-1 bis SOV-8) für Cloud-Dienste. Anbieter müssen für jedes Ziel ein Mindest-Schutzniveau (SEAL) nachweisen. Zusätzlich wird ein Souveränitätsscore gebildet, um Angebote zu bewerten und je nach Risiko passende Workloads zuzuordnen:

• SOV-1: Strategische Souveränität – Inwieweit ist der Anbieter strukturell in der EU verankert (Eigentum, Steuerung, Investitionssicherheit) und auf EU-Interessen ausgerichtet?
• SOV-2: Rechts- und Jurisdiktionssouveränität – In welchem Rechtsrahmen operiert der Dienst und wie gut ist er vor dem Zugriff ausländischer Behörden geschützt bzw. wie stark unterliegt er europäischem Recht?
• SOV-3: Daten- und KI-Souveränität – Wo und wie werden Daten und KI-Services verarbeitet und gesichert und wie viel Kontrolle und Unabhängigkeit behalten die Kundinnen und Kunden über ihre Daten und KI-Funktionen?
• SOV-4: Operative Souveränität – Können Betrieb, Support, Weiterentwicklung und Kontinuität der Dienste durch EU-Akteure ohne Eingriff oder Abhängigkeit von Dritten außerhalb der EU sichergestellt werden?
• SOV-5: Lieferketten-Souveränität – Herkunft, Transparenz und Resilienz der gesamten technischen Lieferkette, insbesondere hinsichtlich der Frage, ob kritische Komponenten EU-kontrolliert sind oder von Nicht-EU-Abhängigkeiten geprägt sind.
• SOV-6: Technologiesouveränität – Offenheit, Prüfbarkeit und Weiterentwickelbarkeit des Tech-Stacks inklusive Interoperabilität und Vermeidung von Lock-in in proprietäre außereuropäische Systeme.
• SOV-7: Sicherheits- und Compliance-Souveränität: Hier wird geprüft, ob der Sicherheitsbetrieb, die Compliance-Pflichten und die Resilienzmaßnahmen innerhalb der EU gesteuert werden und nicht von fremden Jurisdiktionen abhängen.
• SOV-8: Nachhaltigkeit – Langfristige Betriebssicherheit im Hinblick auf Energie, Ressourcenabhängigkeit und Rohstoffknappheit, also die ökologische Resilienz des Cloud-Dienstes.

Weitere Gründe für Misstrauen

Software kann Fehler enthalten, dass weiß jeder, der schon einmal einen Blick in die Lizenzbestimmungen (EULA) riskiert hat, denen man beim Installationsprozess zustimmen muss. Spätestens wenn es um sicherheitskritische Angelegenheiten handelt, stellt sich aber manchmal die Frage, ob der Fehler versehentlich oder absichtlich passiert ist. In letzterem Fall spricht man von einer Backdoor, also einer Hintertür, die Dritten Zugriff auf den eigentlich zu schützenden sensiblen Bereich erlaubt. Beispiele dafür gibt es reichlich:

• Dual_EC_DRBG (2006–2013): Der von NIST als Standard empfohlene Zufallszahlengenerator Dual_EC_DRBG wies Parameter auf, die es Akteuren mit Kenntnis dieser Parameter erlauben konnten, erzeugte Zufallswerte vorherzusagen. Dadurch wurde Verschlüsselung angreifbar, ohne dass sich das im normalen Betrieb unmittelbar erkennen ließ; dies gilt als Beispiel für eine kryptografische Backdoor auf Protokoll-/Algorithmus-Ebene.
• Belgacom / GCHQ (ab 2010, öffentlich 2013): Der britische Geheimdienst GCHQ kompromittierte über eine mehrjährige, technisch gezielte Operation (Operation Socialist) die Netzwerkinfrastruktur des teils staatlichen belgischen Telekommunikationsanbieters Belgacom, unter anderem durch präparierte Webseiten und Schadsoftware für Administratoren, um Zugriff auf internationale Routing- und Roaming-Knoten zu erhalten.
• Abfang- und Manipulationsprogramme der NSA (2014): Im Zuge der Snowden-Veröffentlichungen wurde 2014 bekannt, dass die NSA Netzwerkhardware – unter anderem Router und Switches von Cisco – während des Transports an internationale Kunden abgefangen, geöffnet, mit zusätzlicher Überwachungs- bzw. Zugriffstechnik versehen und anschließend neu versiegelt wieder in den Versand gegeben hat. Dieses Vorgehen zielte darauf ab, Geräte bereits vor der Inbetriebnahme beim Kunden so zu präparieren, dass später ein verdeckter Fernzugriff möglich war. Der Fall zeigt, dass Risiken für die Integrität von Infrastruktur nicht nur aus Software-Backdoors oder Schwachstellen im Code entstehen, sondern auch aus Eingriffen in die physische Lieferkette vor Auslieferung an den Betreiber.
• Juniper ScreenOS (2015): In Junipers ScreenOS-Firmware wurden zwei nicht autorisierte Veränderungen entdeckt: ein verstecktes Administrationspasswort für Remote-Login sowie eine Manipulation der Zufallszahlengenerierung für VPN-Verbindungen. Diese Kombination ermöglichte sowohl unbefugten Zugriff auf die Geräte als auch potenziell das Entschlüsseln von eigentlich vertraulichem VPN-Datenverkehr.
• Fortinet / FortiGate (2015/2016): In bestimmten FortiOS-/FortiGate-Versionen existierte ein hart kodierter Authentifizierungs-Bypass beziehungsweise Support-Zugang, der Remote-Login außerhalb der üblichen Administratoranmeldung erlaubte. Ob dieser Zugang als Wartungsfunktion gedacht war oder nicht, ist für die Risikoanalyse unerheblich, da er faktisch eine nicht kontrollierte Zugriffsmöglichkeit darstellte.
• Fernwartungs-/Diagnosezugänge in Netzwerktechnik (2019): In Netzwerkinfrastrukturgeräten wurden wiederholt verdeckte oder nicht ausreichend dokumentierte Fernwartungs- und Diagnosekanäle festgestellt, die Herstellern technischen Fernzugriff ermöglichen sollten. Solche Kanäle gelten in sicherheitskritischen Netzen als problematisch, weil sie am Betreiber vorbeiführen und damit dessen alleinige Betriebshoheit einschränken. Ein fragliches Beispiel ist der 2019 bekannt gewordene Telnet-Zugang in Huawei-Software für das 3G-Netz von Vodafone in Italien. Vodafone wies damals darauf hin, es sich ähnlich wie bei Fortinet um einen Support-Zugang gehandelt habe, allerdings ohne Internetzugang.
• Cisco Nexus 9000 (2019): In bestimmten Switches der Nexus-9000-Serie waren fest programmierte, identische SSH-Schlüssel vorhanden, über die ein externer Angreifer mit Root-Rechten auf das System zugreifen konnte – ohne reguläre Authentifizierung. Solche hart kodierten Zugangsdaten werden offiziell oft als Fehler eingeordnet, sind aber technisch gleichbedeutend mit einer dauerhaften, nicht dokumentierten Zugriffsmöglichkeit.
• SolarWinds Orion (2020): Angreifer kompromittierten die Build- beziehungsweise Update-Kette der Netzwerkmanagement-Software Orion und verteilten signierte, formal legitime Software-Updates mit eingebettetem Schadcode an Kunden. Das Ergebnis war ein Fernzugriff auf hochprivilegierte Managementumgebungen beim Kunden, obwohl nur reguläre Updates eingespielt wurden.
• XZ Utils (2024): In neuen Versionen der verbreiteten Kompressionsbibliothek XZ Utils wurde schädlicher Code platziert, der die SSH-Authentifizierung abschwächen und so unautorisierten Fernzugriff ermöglichen sollte. Auffällig ist hier, dass der fragliche Code über einen als vertrauenswürdig auftretenden Maintainer in die Lieferkette eingebracht wurde und nicht über ein direktes Eindringen in eine laufende Zielumgebung.
• Out-of-Band-Management / BMC / Intel / Supermicro (noch relevant): Server verfügen über eigenständige Management-Controller (zum Beispiel Baseboard Management Controller, Intel Management Engine), die unabhängig vom Hauptbetriebssystem laufen und umfassende Hardwarekontrolle besitzen, inklusive Speicherzugriff und Remote-Steuerung. Schwachstellen oder absichtlich eingebaute Zugriffspfade in diesen Controllern ermöglichen potenziell eine vollständige Kompromittierung eines Systems, ohne dass dies in den normalen System-Logs sichtbar werden muss.

Wer im Internet sucht, wird weitere Beispiele finden. Die Frage, ob die Sorge um die eigenen Daten berechtigt ist, lässt sich also eindeutig mit Ja beantworten. Besonders wichtig sind die bekannt gewordenen Schwachstellen und Backdoors hinsichtlich SOV-5 (Lieferketten-Souveränität) des EU Cloud Sovereignty Framework. Transparenz und Resilienz der gesamten technischen Lieferkette sind so nicht gewährleistet.

Fazit

Auch Nicht-EU-Anbieter können heute viele formale Anforderungen an digitale Souveränität erfüllen: Dazu gehören die Daten- und Metadatenhaltung in der EU, der Betrieb durch EU-Personal, die europäische Schlüsselkontrolle sowie eine eigene Trust- und Zertifikatsinfrastruktur. Für viele regulierte Bereiche reicht das aus, um Audits zu bestehen und regulatorisch als souverän zu gelten.

Es bleiben jedoch zwei strukturelle Risiken:

1. Rechtslage: US-Anbieter unterliegen dem CLOUD Act und chinesische sowie andere Nicht-EU-Anbieter ihren nationalen Sicherheits- und Nachrichtendienstgesetzen. Diese Gesetze können Zugriff verlangen, auch auf Systeme, die technisch in der EU isoliert sind. Dies kann kein europäischer Vertrag vollständig ausschließen.
2. Vertrauensebene der Technik: Die dokumentierten Fälle von absichtlichen oder mutmaßlich absichtlichen Hintertüren, manipulierter Kryptografie und kompromittierten Lieferketten zeigen, dass Zugriffsmöglichkeiten auch ohne offiziellen Admin-Zugriff geschaffen werden können. Diese Formen des Zugriffs sind für Kunden praktisch nicht lückenlos prüfbar.

Darum lautet die Antwort auf die in der Überschrift gestellte Frage: Nicht-EU-Anbieter können Souveränität technisch nachbilden und für viele Zwecke ausreichend absichern, aber sie können sie nicht garantieren. Das Restrisiko aus externer Jurisdiktion plus möglicher verdeckter Zugriffe bleibt bestehen – und genau dieses Risiko ist der Kern der europäischen Debatte um echte digitale Souveränität.

Pro: Einsatz von Nicht-EU-Anbietern

Die sogenannten souveränen Cloud-Angebote großer Nicht-EU-Anbieter können viele formale Anforderungen erfüllen.

Empfehlung: Für unkritische und mittelkritische Workloads (etwa Standard-IT, Collaboration, Fachanwendungen ohne sicherheitsrelevante oder politisch brisante Daten) sind solche Angebote vertretbar.

Kontra: Einsatz von Nicht-EU-Anbietern

Für hochkritische Bereiche (zum Beispiel hoheitliche Aufgaben, kritische Infrastruktursteuerung, sicherheitsrelevante Steuerungsdaten oder besonders schutzwürdiges Know-how) bleibt jedoch ein strukturelles Restrisiko bestehen, da fremde Staaten extraterritoriale Zugriffsbefugnisse haben und die Möglichkeit besteht, dass über Hintertüren, Lieferkettenmanipulation oder Fernwartungskanäle technische Eingriffe vorgenommen werden. Dieses Risiko lässt sich vertraglich nicht ausschließen.

Empfehlung: Hochkritische Workloads nur mit europäischen Anbietern unter ausschließlich EU-Recht oder in einer vollständig kontrollierten, eigenen Infrastruktur betreiben.

Die dargelegten Einschätzungen geben die Ansicht des Autors wieder. Technologieanbieter aus der EU und aus Drittstaaten sind eingeladen, ihre Position zur digitalen Souveränität darzustellen. Insbesondere interessiert uns, wie rechtlicher Zugriff durch Nicht-EU-Behörden unterbunden werden soll, wie die operative Kontrolle in Europa gewährleistet wird, wie die Verschlüsselung geschützt wird und wie Lieferketten- sowie Wartungszugriffe abgesichert werden. Wir veröffentlichen diese Sicht der Dinge gerne in einem separaten Beitrag.