Souveränität vs. Sicherheit: Warum beides zusammengehört

Executive Summary

Datensouveränität und Datensicherheit werden oft verwechselt — sie sind aber zwei verschiedene Schutzebenen, die beide notwendig sind. Souveränität schützt vor legalem Zugriff: Wer hat das Recht, auf meine Daten zuzugreifen? Sicherheit schützt vor technischem Zugriff: Kann jemand faktisch auf meine Daten zugreifen? Unternehmen, die nur auf Sicherheit setzen, aber Souveränität ignorieren, sind regulatorisch exponiert — umgekehrt ist juristische Souveränität ohne technische Härtung eine Illusion. Die AWS European Sovereign Cloud ist die erste Hyperscaler-Lösung, die beide Dimensionen gleichzeitig auf Plattformebene adressiert. Dieser Artikel zeigt den Unterschied an konkreten Beispielen aus dem Finanzsektor und der öffentlichen Verwaltung.

Die Kernfrage: Zwei verschiedene Bedrohungsmodelle

Wenn ein CISO oder CIO über "Datenschutz in der Cloud" spricht, meint er in der Regel technische Sicherheit: Verschlüsselung, Zugriffskontrollen, Intrusion Detection, Penetrationstests. Das ist richtig und notwendig. Aber es ist nur die Hälfte des Problems.

Die andere Hälfte ist eine juristische Frage: Wer hat das Recht, auf meine Daten zuzugreifen — auch ohne meine Zustimmung? Ein gut abgesicherter Server in einem US-amerikanischen Rechenzentrum kann technisch exzellent geschützt sein und trotzdem per Gerichtsbeschluss offengelegt werden. Eine Anwendung auf einem deutschen Server kann aus juristischer Sicht souverän sein und trotzdem durch eine Sicherheitslücke kompromittiert werden.

Vollständiger Datenschutz erfordert beide Ebenen: die juristische Kontrolle über Zugriffsrechte (Souveränität) und die technische Verhinderung unbefugter Zugriffe (Sicherheit). Wer nur eine Ebene abdeckt, hat ein unvollständiges Sicherheitsmodell.

Definition: Souveränität vs. Sicherheit

Warum Sicherheit ohne Souveränität nicht ausreicht

Das CLOUD Act-Szenario

Stellen Sie sich vor: Ein deutsches Pharmaunternehmen speichert klinische Studiendaten bei einem US-amerikanischen Hyperscaler in der Region eu-central-1. Die Daten sind verschlüsselt, der Zugang ist MFA-gesichert, das SOC überwacht rund um die Uhr — technische Sicherheit auf hohem Niveau.

Nun fordert ein US-Bundesgericht im Rahmen eines Kartellverfahrens den Hyperscaler auf, diese Studiendaten herauszugeben. Der Hyperscaler ist US-amerikanischem Recht unterstellt. Er kann technisch auf die Daten zugreifen — die Verschlüsselung liegt in seinen Schlüsselverwaltungssystemen. Das Pharmaunternehmen hat keinen rechtlichen Mechanismus, diesen Zugriff zu verhindern.

Technische Sicherheit: vorhanden. Souveränität: nicht vorhanden. Ergebnis: Datenverlust durch legalen Zwang.

Das Insider-Threat-Szenario ohne Sicherheit

Umgekehrt: Eine Behörde entscheidet sich für eine on-premises-Lösung in Deutschland, weil sie Datensouveränität maximal sicherstellen will. Die Infrastruktur ist auf deutschem Boden, wird von deutschen Beamten betrieben — juristische Souveränität ist gegeben.

Aber: keine konsequente MFA, kein Privileged Access Management, keine automatische Anomalie-Erkennung. Ein Insider mit übermäßigen Zugriffsrechten exfiltriert über Monate hinweg Personaldaten.

Souveränität: vorhanden. Technische Sicherheit: nicht vorhanden. Ergebnis: Datenverlust durch Insider-Bedrohung.

Beide Szenarien illustrieren denselben Grundsatz: Souveränität und Sicherheit sind keine Alternativen, sondern komplementäre Schutzebenen.

Wie die AWS ESC beide Dimensionen adressiert

Die AWS European Sovereign Cloud ist die erste Hyperscaler-Lösung, die nicht zwischen Souveränität und Sicherheit wählen lässt, sondern beide systematisch auf Plattformebene kombiniert.

Souveränitäts-Ebene der ESC

• EU-only Operatoren: Kein AWS-Mitarbeiter außerhalb der EU hat Zugang zu ESC-Systemen. Damit ist die Grundvoraussetzung für CLOUD-Act-Resistenz strukturell gegeben — nicht nur vertraglich versprochen.
• Eigenständige Cloud-Partition: Die ESC operiert als vollständig separierte Infrastruktur. US-amerikanisches Recht gilt für die ESC-Partition nicht, weil AWS hier eine eigenständige europäische Rechtsverantwortung aufgebaut hat.
• Dauerhafter Datenspeicherort Deutschland: Technisch erzwungen durch Service Control Policies — Daten verlassen die ESC nicht, selbst wenn ein Administrator dies manuell versuchen würde.

Sicherheits-Ebene der ESC

• AWS KMS mit Customer Managed Keys: Kunden halten die Schlüsselkontrolle vollständig selbst. AWS kann technisch nicht auf verschlüsselte Daten zugreifen, selbst wenn rechtlich ein Zugriff erzwungen würde — der Schlüssel liegt beim Kunden, nicht bei AWS.
• AWS CloudHSM: FIPS 140-2 Level 3 Hardware-Sicherheitsmodule für Hochsicherheits-Schlüsselmanagement — das Schlüsselmaterial verlässt die vom Kunden kontrollierte Hardware nie.
• Zero Trust mit AWS IAM Identity Center: Least-Privilege-Zugriff, MFA-Pflicht, Just-in-Time-Privilegierung, vollständige Session-Aufzeichnung via CloudTrail.
• AWS GuardDuty: ML-basierte Bedrohungserkennung — erkennt ungewöhnliche Zugriffsmuster, Data-Exfiltration-Versuche und Insider-Threats automatisch.
• AWS Security Hub: Zentrales Sicherheits-Dashboard mit automatischen Alerts für DSGVO-, NIS2- und BSI-C5-Verletzungen.

Die Kombination ist entscheidend: Selbst wenn ein US-Behördenakt gegen AWS auf der ESC erwirkt würde (was durch die operative Trennung strukturell bereits erschwert ist), würde AWS keinen Zugang zu den Daten haben — weil die Schlüssel beim Kunden liegen und CloudHSM keinen AWS-Zugang hat.

Branchenbeispiele: Finanzsektor und öffentliche Verwaltung

Finanzsektor: DORA und das doppelte Schutzproblem

Für Finanzinstitute verschärft sich das doppelte Schutzproblem durch DORA (Digital Operational Resilience Act), das ab Januar 2025 für alle EU-Finanzinstitute gilt. DORA stellt explizit beide Anforderungen:

• Souveränität: DORA verlangt, dass Finanzinstitute das Recht haben, IKT-Drittdienstleister zu auditieren und bei Risiken zu wechseln. Ein Dienstleister, der US-Behördenzugriffen unterliegt, ist ein unkontrollierbares Drittparteienrisiko.
• Sicherheit: DORA schreibt technische Resilienz vor — ICT-Systeme müssen Angriffe, Ausfälle und Datenkorruption widerstehen. Business Continuity und Disaster Recovery müssen nachweisbar sein.

Ein typisches DORA-Compliance-Szenario für eine Regionalbank:

• Core-Banking-System auf der ESC — mit kundenverwalteten KMS-Schlüsseln und Multi-AZ-Resilienz
• Zahlungsinfrastruktur auf der ESC — mit CloudHSM für Kryptographieschlüssel im HSM-gesicherten Umfeld
• Reporting und Analytics auf eu-central-1 — für nicht-kritische Daten ohne erhöhten Souveränitätsbedarf
• Lückenloses Audit-Trail via CloudTrail für DORA-Prüfungen durch BaFin
• AWS Audit Manager generiert automatisch DORA-konforme Evidenzpakete für die jährliche Prüfung

Öffentliche Verwaltung: VS-NfD und der doppelte Nachweis

Bundesbehörden stehen vor einer besonders strengen Version des doppelten Schutzproblems: Sie müssen sowohl Verschlusssachen-Schutz (Souveränität) als auch BSI-zugelassene Sicherheit (Technologie) nachweisen.

Für VS-NfD-Daten (Verschlusssache — Nur für den Dienstgebrauch) gelten:

• Souveränitätsanforderung: Ausschließlich Personen mit Sicherheitsüberprüfung und Wohnsitz in Deutschland dürfen Zugang haben. Die ESC erfüllt dies durch das EU-only-Operatoren-Modell.
• Sicherheitsanforderung: BSI-zugelassene Kryptographie, nachweisbare Zugangskontrollen, vollständige Protokollierung aller Zugriffe. Die ESC erfüllt dies durch CloudHSM, IAM Identity Center und CloudTrail.

Die ESC ist die erste Hyperscaler-Lösung, bei der das BSI eine Eignung für VS-NfD-Verarbeitung für prinzipiell möglich hält — eine Eignung, die Standard-Hyperscaler-Regionen nicht erreichen können.

Gesundheitswesen: DSGVO Art. 9 und technische Garantien

Patientendaten unterliegen DSGVO Art. 9 — besondere Kategorien personenbezogener Daten. Die Verarbeitung erfordert:

• Souveränität: Keine Weitergabe an Drittländer ohne angemessenes Schutzniveau. Die ESC eliminiert das Drittlandtransfer-Risiko strukturell — Daten bleiben in Deutschland, Operatoren sind EU-Bürger.
• Sicherheit: Technische Maßnahmen, die unbefugten Zugriff verhindern. Im Gesundheitswesen: end-to-end-Verschlüsselung, strikte Rollentrennung (Arzt vs. Verwaltung vs. Abrechnung), automatische Anomalie-Erkennung.

Die Kombination beider Ebenen erlaubt es Krankenhäusern, Krankenversicherungen und Forschungseinrichtungen, Cloud-Effizienz zu nutzen, ohne DSGVO Art. 9-Risiken einzugehen — ein Gleichgewicht, das in Standard-Hyperscaler-Regionen nur mit erheblichem Zusatzaufwand erreichbar ist.

Das integrierte Schutzmodell: Souveränität + Sicherheit

Das vollständige Schutzmodell kombiniert vier Ebenen, die aufeinander aufbauen:

1. Juristische Ebene (Souveränität): Operative Trennung, EU-Operatoren, eigenständige Partition. Schützt vor staatlichem Zugriff und extraterritorialen Gesetzen.
2. Kryptographische Ebene (Sicherheit): Customer Managed Keys in KMS oder CloudHSM. Schützt vor Zugriff, selbst wenn die juristische Ebene scheitert.
3. Zugriffskontrolle (Sicherheit + Souveränität): Zero-Trust-IAM, MFA-Pflicht, Least Privilege, Session-Logging. Schützt vor Insider-Threats und kompromittierten Zugangsdaten.
4. Monitoring und Compliance (Sicherheit + Souveränität): GuardDuty, Security Hub, Config, Audit Manager. Erkennt Abweichungen, generiert Compliance-Nachweise für Aufsichtsbehörden.

Keine der vier Ebenen allein ist ausreichend. Eine Plattform, die nur Souveränität bietet, aber schlechtes Schlüsselmanagement hat, ist angreifbar. Eine Plattform mit exzellentem Schlüsselmanagement, aber US-Rechtsunterworfenheit, ist regulatorisch exponiert. Nur die Kombination aller vier Ebenen liefert vollständigen Schutz.

Praktische Implikationen für Architekten und Entscheider

Für Architekten

• Jeder Workload braucht eine Risikoklassifizierung in zwei Dimensionen: Souveränitätsbedarf (wer darf rechtlich zugreifen?) und Sicherheitsbedarf (wie stark muss technischer Zugriff verhindert werden?).
• Customer Managed Keys sind Standard — nie AWS-verwaltete Schlüssel für souveränitätsrelevante Daten.
• CloudHSM für Hochsicherheits-Schlüsselmaterial, das auch innerhalb der ESC nicht von AWS-Personal erreichbar sein darf.
• SCPs als letzter Sicherheitsanker — verhindern Fehlkonfigurationen auch bei vollem IAM-Zugang.

Für Entscheider (C-Level)

• Souveränität ist eine juristische Entscheidung — sie muss von Rechtsabteilung, Datenschutzbeauftragtem und Vorstand getragen werden, nicht nur von der IT.
• Sicherheit ist eine operative Entscheidung — sie muss vom CISO mit klaren KPIs (Mean Time to Detect, Mean Time to Respond) gesteuert werden.
• Beide Entscheidungen müssen koordiniert sein: Souveränität ohne Sicherheit ist eine leere Versprechung. Sicherheit ohne Souveränität ist ein regulatorisches Risiko.
• NIS2 macht C-Level persönlich haftbar — sowohl für Souveränitäts- als auch für Sicherheitsversäumnisse.

Storm Reply: Integriertes Souveränitäts- und Sicherheits-Framework

Storm Reply ist AWS Premier Consulting Partner DACH mit AWS Security Competency. Das Storm-Reply-Framework für souveräne Cloud-Architekturen integriert beide Schutzebenen von Anfang an: nicht als separate Projekte, sondern als integriertes Design.

Die Methodik umfasst:

• Dual-Threat-Assessment: Analyse sowohl der Souveränitätsrisiken (extraterritoriale Gesetze, Behördenzugriff) als auch der Sicherheitsrisiken (Insider-Threats, externe Angreifer)
• Integrierte Architektur: Sovereign Landing Zone mit gleichzeitiger Implementierung von Zero-Trust, Schlüsselmanagement und Monitoring
• Gemeinsames Compliance-Reporting: Ein einziges Dashboard für NIS2, DSGVO, BSI C5 und DORA — ohne separate Silo-Berichte für Sicherheit und Souveränität
• Cross-funktionale Workshops: IT, Recht und Compliance gemeinsam in einem Workshop — damit Souveränitäts- und Sicherheitsentscheidungen koordiniert getroffen werden

Storm Reply ist Teil der Reply-Gruppe mit 16 AWS-Kompetenzen, 17 Service Deliveries und 1.500+ AWS-Zertifizierungen. Storm Reply — AWS Premier Consulting Partner DACH. Mehr erfahren: reply.com/storm-reply

Quellen

1. AWS: Europe Digital Sovereignty on AWS
2. AWS Security Blog: AWS Sovereign Reference Framework
3. BSI: BSI C5 Kriterienkatalog
4. EU-Kommission: Digital Operational Resilience Act (DORA)
5. EDPB: Empfehlungen zu Schrems II und Drittlandtransfers
6. AWS Dokumentation: AWS Key Management Service