Datenresidenz vs. Datensouveränität: Wo der Unterschied wirklich liegt

Viele Teams glauben, sie seien auf der sicheren Seite, weil ihre Daten in Frankfurt liegen. Warum das eine gefährliche Cloud-Illusion ist, zeigt sich bei genauerem Hinsehen. Was sie übersehen: Datenresidenz und Datensouveränität sind zwei verschiedene Dinge und nur eine davon schützt dich wirklich vor unerwünschtem Fremdzugriff. Wer die Begriffe verwechselt, trifft Infrastrukturentscheidungen auf einer falschen Grundlage.

Was ist Datenresidenz?

Datenresidenz beschreibt schlicht den physischen oder geografischen Ort, an dem Daten gespeichert werden. Wenn du in deinem Cloud-Dashboard „Region: eu-central-1 (Frankfurt)" auswählst, stellst du damit sicher, dass deine Daten in deutschen Rechenzentren liegen, nicht in den USA, nicht in Asien.

Das ist kein unwichtiges Detail. Viele regulierte Branchen, wie Finanzdienstleister, Gesundheitswesen, öffentliche Verwaltung, haben explizite Anforderungen daran, wo Daten physisch gespeichert sein müssen. Die DSGVO selbst schreibt zwar keinen konkreten Speicherort vor, legt aber hohe Hürden für die Übermittlung in Drittländer fest (Art. 44 ff. DSGVO). Datenresidenz hilft dabei, diese Anforderungen zu erfüllen.

Das Problem: Datenresidenz sagt nichts darüber aus, wer rechtlich auf diese Daten zugreifen kann. Und genau hier endet die Schutzwirkung.

Was ist Datensouveränität?

Datensouveränität geht einen Schritt weiter. Sie beschreibt, wer die rechtliche und operative Kontrolle über Daten hat, wer entscheiden kann, wer Zugriff bekommt, wer sie verarbeiten darf, und vor allem: wer sie herausgeben muss.

Datensouveränität ist keine technische Eigenschaft eines Rechenzentrums, sondern eine rechtliche und architektonische Eigenschaft deines gesamten Setups. Sie hängt ab von:

• der Rechtsgrundlage, unter der dein Anbieter operiert
• der Konzernstruktur des Anbieters (Muttergesellschaft in welchem Land?)
• dem Verschlüsselungsmodell und wer die kryptografischen Schlüssel hält
• den Zugriffsprotokollen und wer diese einsehen kann

Ein Unternehmen kann vollständige Datensouveränität haben, ohne dass die Daten im eigenen Land liegen und umgekehrt kann ein Unternehmen Daten in Deutschland speichern, ohne irgendeine Souveränität darüber zu haben.

Warum EU-Regionen kein Freifahrtschein sind

Das ist der Punkt, an dem viele Teams falsch abbiegen. Die Annahme lautet: „Wir nutzen AWS Frankfurt, also sind wir DSGVO-konform und souverän." Beides stimmt nicht automatisch.

AWS, Google Cloud und Microsoft Azure sind US-amerikanische Unternehmen. Ihre europäischen Tochtergesellschaften und Rechenzentren unterliegen trotzdem dem Zugriff ihrer amerikanischen Mutterkonzerne und damit dem US-amerikanischen Recht.

Das Cloud-Act-Problem konkret

Der CLOUD Act (Clarifying Lawful Overseas Use of Data Act) von 2018 verpflichtet US-Unternehmen, auf Anordnung amerikanischer Behörden Daten herauszugeben – auch wenn diese Daten physisch in Europa gespeichert sind. Eine Behörde in Washington kann theoretisch Zugriff auf Daten verlangen, die in einem Frankfurter Rechenzentrum von AWS liegen, weil AWS Inc. ein US-Unternehmen ist.

Das Schrems-II-Urteil des EuGH von 2020 hat diese Problematik auf den Punkt gebracht: Der EuGH kippte den Privacy Shield genau deshalb, weil US-Geheimdienstgesetze (FISA Section 702, Executive Order 12333) einen Schutzstandard ermöglichen, der dem der DSGVO nicht entspricht. Datenresidenz in der EU schützt nicht vor Zugriff durch US-Behörden, wenn der Anbieter ein US-Unternehmen ist.

Das ist kein theoretisches Problem. Es trifft jeden, der personenbezogene Daten von EU-Bürgern bei US-Hyperscalern verarbeitet, unabhängig davon, welche Region er gewählt hat.

Datensouveränität technisch umsetzen

Wenn du echte Datensouveränität anstrebst, reicht die Wahl der richtigen Region nicht aus. Du brauchst eine Architektur, die Souveränität strukturell absichert.

Wer hält die Schlüssel?

Verschlüsselung ist der erste Baustein, aber sie schützt nur dann, wenn du die Kontrolle über die kryptografischen Schlüssel behältst.

Die meisten Hyperscaler bieten standardmäßig Managed Encryption an: Der Anbieter verwaltet die Schlüssel, der Anbieter könnte sie auf Anordnung herausgeben. Das ist besser als keine Verschlüsselung, aber keine echte Souveränität.

Bring Your Own Key (BYOK) ist ein Schritt weiter: Du bringst deinen eigenen Schlüssel mit, der Anbieter nutzt ihn zur Verschlüsselung. Das Problem: Der Schlüssel liegt in der Infrastruktur des Anbieters und kann dort theoretisch kompromittiert oder herausgegeben werden.

Hold Your Own Key (HYOK) ist die konsequenteste Variante: Die Schlüssel verlassen zu keinem Zeitpunkt deine eigene Infrastruktur. Entschlüsselung findet nur in deiner Kontrolle statt. Das bedeutet, dass der Cloud-Anbieter technisch keine Möglichkeit hat, die Daten im Klartext herauszugeben – selbst wenn er dazu verpflichtet würde.

Weitere technische Maßnahmen für Datensouveränität:

• Zugangskontrolle und IAM: Strikte Trennung von Berechtigungen, keine weitreichenden Admin-Zugänge für Anbieter-Support-Teams
• Audit-Logs: Vollständige, unveränderliche Protokollierung aller Zugriffe – auch durch den Anbieter
• Mandantentrennung: Physische oder kryptografische Trennung von Kundendaten, keine gemeinsame Infrastruktur auf Datenbankebene
• Netzwerksegmentierung: Kubernetes-Namespaces und Network Policies, die ungewollten Datenfluss verhindern

Sovereign Cloud als Lösung

Das Konzept der Sovereign Cloud adressiert genau diese Lücke zwischen Datenresidenz und echter Souveränität. Eine souveräne Cloud ist nicht einfach eine europäische Region eines US-Hyperscalers, sie ist eine Infrastruktur, die vollständig unter europäischem Recht und ohne Abhängigkeit von US-Konzernen betrieben wird.

Initiativen wie Gaia-X versuchen, einen europäischen Datenraum mit definierten Souveränitätsstandards zu schaffen. Das EU Cloud Sovereignty Framework definiert erstmals prüfbare Kriterien für diese Anforderungen. Dabei geht es nicht nur um den Speicherort, sondern um technische und rechtliche Zertifizierungen: Wer betreibt die Infrastruktur? Wer hat Zugriff? Welche Behörden können welche Anforderungen stellen?

Für Kubernetes-Workloads auf souveräner Infrastruktur bedeutet das konkret: Ein Managed Kubernetes auf einem europäischen Anbieter ohne US-Muttergesellschaft bietet eine andere Ausgangslage als EKS oder GKE, auch wenn beide technisch ähnliche Features haben. Die Frage ist, welchem Rechtssystem der Anbieter unterliegt und welche vertraglichen und technischen Garantien er geben kann.

lowcloud ist als Kubernetes-DevOps-as-a-Service-Plattform explizit für diesen Anwendungsfall gebaut: Betrieb in deutschen Rechenzentren, ohne US-Konzernmutter, mit klaren Datenschutzverträgen nach DSGVO. Das adressiert nicht nur die Datenresidenz, sondern auch die strukturelle Souveränität – welche Behörden Zugriff fordern könnten und welche rechtlichen Hebel einem Anbieter zur Verfügung stehen oder eben nicht.

Entscheidungshilfe für Architekten

Nicht jede Anwendung braucht denselben Souveränitätsgrad. Hier eine pragmatische Orientierung:

Datenresidenz reicht, wenn:

• du keine personenbezogenen Daten oder lediglich unkritische interne Daten verarbeitest
• deine Compliance-Anforderungen sich auf den physischen Speicherort beschränken
• du in einem Sektor tätig bist, der keine besonderen Anforderungen an Zugriffshoheit stellt

Datensouveränität ist notwendig, wenn:

• du sensible personenbezogene Daten von EU-Bürgern verarbeitest (Gesundheit, Finanzen, Behörden)
• du Daten verarbeitest, die unter NIS2, KRITIS oder ähnliche Regulierungen fallen
• dein Threat-Model staatliche Zugriffe durch Drittlandsbehörden einschließt
• deine Kunden oder Partner explizit Souveränitätsnachweise verlangen

Die entscheidende Frage ist nicht nur „Wo liegen meine Daten?" sondern: „Wer könnte theoretisch Zugriff auf meine Daten erzwingen und auf welchem rechtlichen Weg?"

Kubernetes-Workloads auf einer souverän betriebenen Plattform zu betreiben, ist technisch kein Mehraufwand. Die Frage ist, auf welcher Infrastruktur man deployt. lowcloud bietet Managed Kubernetes auf europäischer Infrastruktur ohne US-Abhängigkeiten. Wenn du konkrete Anforderungen an Datensouveränität hast, lohnt sich ein Blick auf die Plattform und ein direktes Gespräch über dein Setup.