Cloud-Abhängigkeit neu bewerten Warum der Serverstandort allein Unternehmen nicht schützt

Anbieter zum Thema

DSwiss AG

Cloudgermany.de GmbH

STACKIT - Schwarz Digits Cloud GmbH & Co. KG

Yorizon GmbH & Co. KG

78 Prozent der deutschen Unternehmen halten ihre Abhängigkeit von US-Cloud-Anbietern für zu hoch. Doch ein europäischer Serverstandort allein ist kein Schutz vor dem US CLOUD Act. Entscheidend für echte digitale Souveränität sind Jurisdiktion, Schlüsselhoheit und eine konsequente Zero-Knowledge-Architektur.

Die Konzentration kritischer IT-Infrastruktur bei wenigen globalen Hyperscalern ist in den vergangenen zehn Jahren explodiert. AWS, Microsoft Azure und Google Cloud kontrollieren gemeinsam den Großteil des globalen Cloud-Marktes. Eine aktuelle Bitkom-Erhebung bestätigt, dass 78 Prozent der deutschen Unternehmen ihre Abhängigkeit von US-Cloud-Anbietern als zu hoch einschätzen.

Strukturell gefährlich wird das durch die Kombination aus technischer Tiefe und juristischer Reichweite. Wer kritische Geschäftsprozesse – ERP-Systeme, Identitätsverwaltung, Verschlüsselungsdienste, Backups – in eine Public Cloud ausgelagert hat, hat nicht nur Rechenkapazität eingekauft, sondern faktisch auch Teile seiner rechtlichen Handlungsfähigkeit übertragen.

Die falsche Konsequenz zu ziehen, wäre jedoch ebenso riskant. Wer kritische Systeme reflexhaft selbst betreiben will, überschätzt die eigene Organisation: Eigenbetrieb skaliert schlecht, bindet knappe Fachkräfte und erhöht die Sicherheit selten. Entscheidend ist nicht, Kontrolle um jeden Preis im Haus zu halten, sondern die richtige Kontrolle zu behalten.

Der US CLOUD Act: Was er technisch und rechtlich bedeutet

Der US CLOUD Act („Clarifying Lawful Overseas Use of Data Act“) trat 2018 in Kraft und erlaubt US-Bundesbehörden, von amerikanischen Unternehmen die Herausgabe von Daten zu verlangen – unabhängig davon, in welchem Land diese physisch gespeichert sind. Einzige Voraussetzung: Der Betreiber muss seinen Firmensitz oder wesentliche operative Strukturen in den USA haben.

Für IT-Verantwortliche bedeutet das: Ein Rechenzentrum in Frankfurt oder Dublin, das von einem US-amerikanischen Anbieter betrieben wird, bietet keinen wirksamen Schutz vor behördlichem Zugriff. Europäische Datenschutzgesetze – DSGVO eingeschlossen – kollidieren hier systemisch mit US-Bundesrecht.

Hinzu kommt eine operative Schwachstelle: die Schlüsselverwaltung. Die meisten Hyperscaler bieten „Encryption-as-a-Service“ an – erzeugen, verwalten und rotieren kryptografische Schlüssel also als Teil ihres Service-Portfolios. Dann kontrolliert der Anbieter sowohl die verschlüsselten Daten als auch die Schlüssel zu ihrer Entschlüsselung. Im Falle einer behördlichen Anforderung nach dem Cloud Act liegt die Entscheidungsgewalt nicht beim Dateneigentümer, sondern beim Betreiber.

Verstärkt wird das durch die modulare Verschachtelung moderner Architekturen. Ein SaaS-Produkt eines europäischen Anbieters kann auf AWS oder Azure als Substrat aufsetzen, von dortigen CDN-Diensten abhängig sein oder Log-Daten in US-amerikanische Observability-Plattformen schreiben. Die tatsächliche Jurisdiktion ist damit für die IT-Abteilung häufig nicht mehr vollständig nachvollziehbar – selbst wenn der Vertragspartner eine europäische GmbH ist.

Vorsicht vor „Sovereignty Washing“: Warum der Speicherort allein kein Sicherheitsargument ist

Mit dem wachsenden Bewusstsein für Cloud-Abhängigkeiten hat ein Phänomen Konjunktur, das man als „Sovereignty Washing“ bezeichnen kann: Anbieter positionieren sich als souveräne Alternative, weil sie Rechenzentren in Deutschland, der Schweiz oder einem anderen europäischen Land betreiben – ohne dass sich an der technischen und rechtlichen Architektur dahinter grundlegend etwas ändert.

Zur Beurteilung, ob ein Anbieter tatsächlich einen souveränen Betrieb ermöglicht, sind mindestens drei Fragen relevant:

• Wer kontrolliert die Schlüssel? Werden kryptografische Schlüssel auf der Infrastruktur des Anbieters erzeugt und verwaltet, behält dieser technischen Zugriff auf Klartextdaten.

• Welcher Rechtsrahmen gilt? Entscheidend ist nicht die Postadresse des Rechenzentrums, sondern die Jurisdiktion, unter der der Anbieter operiert.

• Wer hat administrativen Zugriff? Eine souveräne Betriebsarchitektur erfordert, dass privilegierte Zugriffe regional eingegrenzt sind, dem Vier-Augen-Prinzip unterliegen und vollständig auditiert werden.

Bitkom Cloud Report 2026

Cloud „Made in Germany“ dringend gesucht

Schlüsselhoheit und Verschlüsselung: Die Stellschrauben für technische Souveränität

Digitale Souveränität ist das Ergebnis konkreter Architektur- und Betriebsentscheidungen in drei Dimensionen:

1. Jurisdiktion als Risikovariable verwalten
IT-Sicherheitsverantwortliche sollten für jeden kritischen Dienst dokumentieren, unter welchem Rechtssystem der Betreiber operiert, wo kryptografische Schlüssel verwaltet werden und welche Drittanbieter über Subprozessoren eingebunden sind. Dieser Prozess muss in das laufende Vendor-Management integriert werden.

2. Zero-Knowledge-Architektur als technisches Prinzip
Das Zero-Knowledge-Prinzip beschreibt eine Architektur, in der der Betreiber einer Infrastruktur technisch ausgeschlossen ist, auf unverschlüsselte Inhalte zuzugreifen. Daten werden clientseitig verschlüsselt, bevor sie die lokale Umgebung verlassen. Der Anbieter verwaltet ausschließlich Chiffrate; die Schlüssel bleiben ausschließlich beim Dateneigentümer. Dann ist auch eine legitime Behördenanfrage gegenüber dem Anbieter ohne Kooperation des Kunden technisch nicht erfüllbar – der Anbieter besitzt schlicht keinen Zugang zu den Klartextdaten.

Praktisch relevant ist dabei die Unterscheidung zwischen Encrypt-at-rest- und Encrypt-in-use-Modellen einerseits und echten Zero-Knowledge-Architekturen andererseits. Erstere schützen Daten im Ruhezustand und bei der Übertragung, lassen aber Zugriffspfade für Betreiber offen. Letztere schließen diese Pfade architektonisch aus.

3. Operative Kontrolle sicherstellen
Die dritte Ebene betrifft den laufenden Betrieb: Wer hat privilegierten Zugriff auf Produktivsysteme, unter welchen Bedingungen und mit welchen Protokollen? Für souveräne Architekturen gilt: Administrativer Zugriff durch den Betreiber darf nur mit expliziter Freigabe des Kunden möglich sein, muss vollständig protokolliert und auf definierte Zeitfenster begrenzt sein.

Multicloud-Strategie: Mit Risikodiversifikation und getrennter Schlüsselverwaltung zur Souveränität

Eine vollständige Rückverlagerung in On-Premises-Infrastrukturen ist für die meisten Organisationen weder wirtschaftlich sinnvoll noch technisch praktikabel. Komplexe, über Jahre gewachsene Systemlandschaften lassen sich nicht schnell migrieren, und die Betriebseffizienz moderner Cloud-Dienste hat natürlich Vorteile.

Der Gegenentwurf zum Eigenbetrieb ist deshalb nicht der eine, vermeintlich souveräne Komplettanbieter, sondern ein bewusst diversifiziertes Vendor-Portfolio nach dem „Best of Breed“-Prinzip. Das verteilt technische, rechtliche und geopolitische Risiken auf mehrere Schultern.

Der realpolitische Ansatz für Unternehmen, die Souveränität und Effizienz verbinden wollen, ist also eine nach Kritikalität differenzierte Multicloud-Strategie. Dabei werden Workloads nicht pauschal in eine Architektur überführt, sondern systematisch nach Datensensitivität und regulatorischer Relevanz klassifiziert:

Hochsensible Prozesse – Identitätsverwaltung, Schlüsselinfrastruktur, regulatorisch relevante Daten – werden in souveräne Umgebungen mit verifizierbarer Schlüsselhoheit und klarer EU/CH-Jurisdiktion ausgelagert. Standardisierte, weniger kritische Workloads können weiterhin in leistungsfähigen globalen Clouds verbleiben, sofern das Risikoprofil es erlaubt.

Bildquelle: Vogel-IT Medien

Neue Sonderpublikation

Digitale Souveränität

Grundlagen, Strategien und Umsetzung

Daten, Anwendungen, Infrastrukturen: Wer die Kontrolle behält, sichert Innovation und Handlungsfähigkeit. Unsere neue Sonderpublikation zeigt, welche Strategien, Technologien und Lösungen Unternehmen auf dem Weg zu mehr digitaler Selbstbestimmung unterstützen – und wie realistisch das Ziel einer souveränen digitalen Zukunft für Europa wirklich ist.

Jetzt Lesen!

Entscheidend für eine funktionale Multicloud-Architektur ist die Portabilität. Lock-in-Effekte entstehen durch technische Abhängigkeiten: proprietäre APIs, anbieterspezifische Managed Services, inkompatible Datenformate. Offene Standards, Container-basierte Deployments und explizit definierte Exit-Strategien sind deshalb operative Notwendigkeiten.

Ein weiterer kritischer Punkt in Multicloud-Szenarien ist die getrennte Schlüsselverwaltung. Werden verschiedene Cloud-Umgebungen genutzt, aber Schlüssel zentral bei einem der beteiligten Anbieter verwaltet, entsteht ein Single Point of Failure – rechtlich wie technisch. Eine souveräne Multi-Cloud-Architektur erfordert eine Schlüsselverwaltung, die unabhängig von allen beteiligten Cloud-Anbietern operiert.

Fazit: Digitale Souveränität ist eine Frage der Architektur, nicht des Standorts

Die Frage nach digitaler Souveränität lässt sich nicht durch die Wahl eines Rechenzentrumstandorts beantworten. Sie erfordert eine systematische Bewertung der Zugriffspfade, Rechtsrahmen und Verschlüsselungsarchitekturen aller eingesetzten Dienste.

Und sie erfordert den Mut, bestehende Abhängigkeiten differenziert zu betrachten – nicht alle Cloud-Dienste sind gleich kritisch, aber die kritischsten müssen entsprechend behandelt werden. Kontrolle abzugeben ist kein Widerspruch zur Souveränität, solange sie an die Richtigen geht und das Vendor-Portfolio breit genug aufgestellt ist, um von keinem einzelnen Anbieter existenziell abhängig zu sein.

(ID:50906255)