Souveränität operationalisieren: Was sich für IT und Legal ändert

Executive Summary

Souveräne Cloud ist kein einmaliges Projekt — sie ist dauerhafter Betrieb. Nach der Migration zur AWS European Sovereign Cloud beginnt die eigentliche Arbeit: neue Routineprozesse für IT-Teams, veränderte Pflichten für Rechtsabteilung und Datenschutzbeauftragte, Einschränkungen bei Drittanbietern und neue Governance-Anforderungen. Dieser Artikel erklärt konkret, was sich im Alltag ändert: Zugriffsprotokollierung, Schlüsselmanagement-Lifecycle, Drittanbieter-Compliance und welche Governance-Templates und Runbooks DACH-Unternehmen brauchen. Zielgruppe: IT-Betriebsleiter, CISOs, Datenschutzbeauftragte und Rechtsabteilungen, die verstehen wollen, was souveräne Cloud im Regelbetrieb bedeutet — nicht nur beim Aufbau.

Der Unterschied zwischen Aufbau und Betrieb

In Migrationsprojekten liegt der Fokus auf der Technologie: Landing Zone aufbauen, Workloads migrieren, Controls konfigurieren. Das ist der aufregendere Teil — und der, über den die meisten Artikel und Präsentationen berichten. Aber Souveränität ist kein Zustand, der einmal erreicht wird und dann stabil bleibt.

Souveräne Cloud erfordert kontinuierliche Bewirtschaftung. Schlüssel müssen rotiert werden. Zugriffsrechte müssen regelmäßig überprüft werden. Neue Drittanbieter müssen auf ESC-Kompatibilität geprüft werden, bevor sie eingebunden werden. Behördenanfragen müssen nach einem definierten Prozess bearbeitet werden. BSI-Audits erfordern aktuelle Evidenz — nicht Evidenz aus dem Migrations-Sprint vor 18 Monaten.

Was genau ändert sich im Regelbetrieb? Dieser Artikel teilt die Antwort in vier Dimensionen auf: Zugriffsprotokollierung und -kontrolle, Schlüsselmanagement-Lifecycle, Drittanbieter-Einschränkungen und Governance-Framework.

Dimension 1: Zugriffsprotokollierung und -kontrolle

CloudTrail als souveränes Gedächtnis

AWS CloudTrail protokolliert jeden API-Aufruf, jeden Management-Console-Zugriff und jeden Ressourcenzugriff in der ESC. Im souveränen Betrieb ist CloudTrail nicht optional — es ist die Grundlage aller Compliance-Nachweise. CloudTrail-Logs müssen in einem S3-Bucket mit Object Lock (Compliance Mode) aufbewahrt werden, der vor versehentlichem oder böswilligem Löschen schützt. Aufbewahrungsdauer: mindestens 3 Jahre (BSI C5-Anforderung), für NIS2 empfohlen 7 Jahre.

Privilegierter Zugriff (Privileged Access Management)

Jeder administrative Zugriff auf ESC-Ressourcen muss durch AWS IAM Identity Center mit Just-in-Time-Privilegierung (JIT) erfolgen. Das bedeutet: kein dauerhaft offener Admin-Zugriff. Stattdessen wird jede privilegierte Sitzung explizit beantragt, genehmigt, zeitlich begrenzt und vollständig protokolliert. Nach Ablauf der Sitzung werden die Berechtigungen automatisch entzogen. PAM-Protokolle sind die wichtigsten Nachweisdokumente bei BSI-Audits.

Anomalie-Erkennung und -reaktion

AWS GuardDuty überwacht alle ESC-Aktivitäten auf Anomalien: ungewöhnliche Zugriffszeiten, geografische Anomalien (Zugriff aus nicht-EU-Regionen), Massendownloads, API-Aufrufe außerhalb des normalen Betriebsmusters. GuardDuty-Findings müssen in den SOC-Workflow integriert sein — nicht nur als E-Mail-Alert, sondern als ticketbasierter Eskalationsprozess mit definierten SLAs (z.B. Critical Finding: Reaktion in 4 Stunden).

Vierteljährliches Access Review

Alle IAM-Berechtigungen in ESC-Konten müssen mindestens vierteljährlich überprüft werden. Prozess: automatisierter Bericht über alle aktiven Berechtigungen via AWS IAM Access Analyzer, manuelles Review durch den Datenschutzbeauftragten und den verantwortlichen System-Owner, Entzug aller nicht mehr benötigten Berechtigungen innerhalb von 5 Werktagen. Dieser Prozess ist in der Betriebsvereinbarung zu dokumentieren.

Behördenanfragen-Prozess

Im souveränen Betrieb muss ein definierter Prozess für den Fall existieren, dass eine Behörde — inländisch oder ausländisch — Zugang zu ESC-Daten fordert. Dieser Prozess umfasst: unverzügliche Benachrichtigung des Datenschutzbeauftragten und der Rechtsabteilung, juristische Bewertung der Rechtmäßigkeit der Anforderung, Eskalation an die Geschäftsleitung, Dokumentation der Entscheidung. Ohne diesen Prozess ist die Antwort auf eine behördliche Anfrage improvisiert — mit hohem Haftungsrisiko.

Dimension 2: Schlüsselmanagement-Lifecycle

Schlüsselmanagement ist das technische Herzstück souveräner Cloud. Customer Managed Keys (CMKs) geben Kunden die volle Kontrolle — aber sie erzeugen auch volle Verantwortung. Ein verlorener oder korrumpierter Schlüssel bedeutet dauerhafter Datenverlust. Ein abgelaufener Schlüssel kann Produktionssysteme lahmlegen.

Schlüsselrotations-Policy

Alle CMKs müssen eine automatische Rotation haben — mindestens jährlich, für hochsensible Systeme halbjährlich. AWS KMS unterstützt automatische Schlüsselrotation nativ. Die Rotation muss in CloudTrail nachweisbar sein und in das interne Schlüsselverzeichnis eintragen werden. Wichtig: Rotation bedeutet, dass altes Schlüsselmaterial für die Entschlüsselung alter Daten weiterhin verfügbar bleibt — es gibt kein Datenverlustrisiko durch Rotation.

Schlüssel-Lifecycle-Management

Jeder Schlüssel hat einen definierten Lebenszyklus: Erstellung (Creation), Aktivierung, Rotation, Deaktivierung, Löschung. Das Löschen eines CMKs hat eine Mindest-Wartezeit von 7 bis 30 Tagen in AWS — Sicherheitspuffer gegen versehentliche Löschungen. Schlüssel-Löschungen müssen durch einen Vier-Augen-Prozess genehmigt werden und im ITSM-System ticketbasiert dokumentiert sein.

CloudHSM-Wartung

Wer CloudHSM einsetzt, trägt zusätzliche Betriebsverantwortung: HSM-Cluster-Management, Key Ceremony-Dokumentation, regelmäßige Backup-Tests des HSM-Inhalts. CloudHSM-Backups müssen verschlüsselt in deutschen S3-Buckets (ESC) mit Object Lock aufbewahrt werden. Die Key-Ceremony-Dokumentation (Schlüsselerzeugung unter Zeugen) ist ein BSI-Auditrequirement für Hochsicherheits-Schlüsselmaterial.

Schlüssel-Zugriffskontrolle (Key Policies)

Key Policies in AWS KMS definieren, wer einen Schlüssel nutzen, wer ihn verwalten und wer ihn löschen darf. Im souveränen Betrieb müssen Key Policies restriktiv sein: nur explizit genannte IAM-Rollen dürfen auf CMKs zugreifen, kein Account-Root-Zugriff auf Schlüsselmaterial. Key-Policy-Änderungen müssen über einen Change-Management-Prozess mit mindestens Zwei-Personen-Autorisierung laufen.

Schlüssel-Notfallprozess

Was passiert, wenn ein Schlüssel kompromittiert wurde? Der Notfallprozess muss definiert sein: sofortige Deaktivierung des betroffenen Schlüssels, Rotation auf neues Schlüsselmaterial, Re-Encryption aller betroffenen Datensätze (AWS KMS bietet hierfür den ReEncrypt-API-Call), Incident-Dokumentation für den BSI-Auditbericht. Dieser Prozess muss mindestens jährlich getestet werden — als "Key Compromise Drill".

Dimension 3: Drittanbieter-Einschränkungen

Souveräne Cloud gilt nicht nur für eigene Infrastruktur — sie gilt auch für jeden Drittanbieter, der auf souveräne Workloads zugreift. Hier liegt einer der häufigsten operativen Stolpersteine: Unternehmen migrieren ihre eigene Infrastruktur auf die ESC, vergessen aber, dass eingebundene SaaS-Dienste, Monitoring-Tools und Support-Systeme oft eigene Datenpfade außerhalb der EU haben.

Kategorien problematischer Drittanbieter

US-basierte SaaS-Dienste mit EU-Daten

Kategorien: CRM-Systeme (Salesforce, HubSpot), Collaboration (Slack, Teams US-Instance), ITSM (ServiceNow US), Support-Systeme (Zendesk US). Problem: Diese Systeme verarbeiten oft Kundendaten oder Systemdaten, die unter DSGVO fallen. Sie müssen entweder durch EU-konforme Varianten ersetzt oder durch technische Maßnahmen so konfiguriert werden, dass keine personenbezogenen Daten außerhalb der EU gespeichert werden.

Monitoring- und Observability-Tools

Viele beliebte Monitoring-Dienste (Datadog, New Relic, Splunk Cloud US) senden Metriken und Logs an Cloud-Backends außerhalb der EU. Im souveränen Betrieb ist das unzulässig, wenn die Metriken personenbezogene Daten oder Systemkonfigurationen enthalten, die als schutzbedürftig klassifiziert sind. Alternativen: AWS-native Monitoring (CloudWatch, X-Ray), EU-konforme Instanzen dieser Tools oder self-hosted Lösungen auf der ESC.

CDN und Edge-Dienste

Content Delivery Networks mit globaler PoP-Infrastruktur (Cloudflare, Fastly) cachen Inhalte auf Servern außerhalb der EU. Für statische, nicht-personenbezogene Inhalte (CSS, JS, Bilder) ist das meist unkritisch. Für dynamische Inhalte mit Kundendaten oder Session-Tokens ist es ein DSGVO-Drittlandtransfer-Problem. Lösung: AWS CloudFront mit Origin auf der ESC und Restriction auf EU-PoPs.

Support- und Fernzugriffs-Tools

Wenn externe Dienstleister (Software-Hersteller, MSPs) Remote-Support auf ESC-Systeme leisten, muss dieser Zugriff kontrolliert sein: nur über AWS Systems Manager Session Manager (kein direktes SSH/RDP), vollständige Protokollierung in CloudTrail, zeitlich begrenzte Zugriffsfreigabe per JIT-PAM, ausschließlich EU-residente Support-Mitarbeiter des Dienstleisters für souveräne Workloads.

Drittanbieter-Compliance-Prüfung als Dauerprozess

Jeder neue Drittanbieter, der auf ESC-Workloads zugreift oder deren Daten verarbeitet, muss vor der Freigabe eine Compliance-Prüfung durchlaufen. Checkliste für den Prüfprozess:

• Wo speichert der Drittanbieter Daten? (Datenspeicherort-Nachweis erforderlich)
• Welchem Recht unterliegt der Drittanbieter? (CLOUD Act-Risiko bei US-Muttergesellschaft)
• Welche Zertifizierungen hält der Drittanbieter? (ISO 27001, BSI C5 oder äquivalent)
• Gibt es einen Datenverarbeitungsvertrag (DPA) nach DSGVO Art. 28?
• Ist der Support-Zugriff auf EU-residente Mitarbeiter beschränkt?

Dimension 4: Governance-Framework für den Souveränitäts-Regelbetrieb

Souveräner Betrieb ohne Governance-Framework ist instabil. Die technischen Controls sind nur so gut wie die Prozesse, die sie umgeben. Folgende Governance-Elemente sind für den nachhaltigen Betrieb einer souveränen Cloud-Umgebung notwendig:

Operative Governance-Dokumente

Souveränitäts-Policy (Data Sovereignty Policy)

Ein verbindliches Dokument, das die Datensouveränitätsanforderungen der Organisation definiert: welche Daten souverän sein müssen, welche technischen Controls Pflicht sind, welche Drittanbieter-Anforderungen gelten und wer für die Durchsetzung verantwortlich ist. Muss vom Vorstand verabschiedet und mindestens jährlich überprüft werden.

Schlüsselmanagement-Handbuch

Dokumentation aller CMKs und CloudHSM-Schlüssel: Zweck, zugeordnete Workloads, Rotationsfrequenz, Key-Policy, Zuständigkeit, Backup-Prozess und Notfallprozedur. Muss bei jeder Änderung aktualisiert werden. Zugang nur für authorisierte Schlüsselverwalter.

Incident-Response-Plan (Souveränitätsvorfälle)

Separater Incident-Response-Plan speziell für Souveränitätsvorfälle: behördliche Zugriffsanfragen, Schlüsselkompromittierungen, unbeabsichtigte Drittlandtransfers, NIS2-meldepflichtige Vorfälle. Enthält: Eskalationspfade, Kommunikationsvorlagen für die BSI-Meldung (24h/72h-Fristen), Zuständigkeiten (CISO, Legal, DPO, CEO) und Post-Incident-Review-Prozess.

Drittanbieter-Register

Vollständige Liste aller Drittanbieter mit Zugang zu ESC-Workloads oder deren Daten: Anbieter-Name, Leistung, Datenspeicherort, zugelassene Zugriffsart, Compliance-Status (letzte Prüfung), Vertragsablauf. Muss mindestens vierteljährlich überprüft und bei jeder Neuaufnahme aktualisiert werden.

Compliance-Kalender

Jahresplan für alle Compliance-Aktivitäten: BSI-C5-Evidenzsammlung (monatlich via Audit Manager), IAM Access Review (vierteljährlich), Drittanbieter-Compliance-Prüfung (halbjährlich), Schlüsselrotation-Überprüfung (jährlich), NIS2-Selbstbewertung (jährlich), BSI-Audit (nach Bedarf). Der Compliance-Kalender verhindert, dass Aktivitäten vergessen werden und Audit-Readiness zu einem ad-hoc Kraftakt wird.

RACI-Matrix Souveränitätsbetrieb

Klare Zuständigkeiten für alle souveränen Betriebsaktivitäten: Wer ist Responsible (führt durch), Accountable (trägt Verantwortung), Consulted (wird hinzugezogen) und Informed (wird informiert) bei Schlüsselrotation, Behördenanfragen, Drittanbieter-Onboarding, Incident Response und Audit-Vorbereitung. Ohne RACI entstehen Zuständigkeitslücken — besonders an der Schnittstelle zwischen IT und Legal.

Was sich für Legal und Datenschutz konkret ändert

Souveräne Cloud ist keine rein technische Angelegenheit — sie hat erhebliche rechtliche Implikationen, die dauerhafte Aufmerksamkeit der Rechtsabteilung und des Datenschutzbeauftragten erfordern.

Verzeichnis der Verarbeitungstätigkeiten (VVT)

Das VVT nach DSGVO Art. 30 muss aktualisiert werden: für jeden souveränen Workload ist die ESC als Verarbeitungsort einzutragen, AWS als Auftragsverarbeiter mit ESC-Scope, die technischen Schutzmaßnahmen (KMS, CloudHSM, SCPs) als TOMs. Bei jeder Workload-Migration oder Änderung der Datenverarbeitung muss das VVT innerhalb von 30 Tagen aktualisiert werden.

Auftragsverarbeitungsverträge (AVVs)

Der AWS-Standardvertrag (AWS DPA) deckt die ESC-Spezifika ab — aber Anpassungen sind notwendig: der Scope muss explizit auf die ESC-Partition begrenzt sein, die Unterauftragsverarbeiter-Liste muss EU-only sein, die Audit-Rechte müssen den BSI-Anforderungen entsprechen. Für alle anderen Drittanbieter mit ESC-Datenzugang müssen separate AVVs nach DSGVO Art. 28 abgeschlossen werden.

Behördenanfragen-Management

Wenn eine Behörde — inländisch oder ausländisch — Zugang zu ESC-Daten fordert, ist ein definierter juristischer Prüfprozess notwendig. Die Kernfragen: Ist die Anfrage rechtmäßig? Ist sie an die richtige Stelle gerichtet? Welche Daten dürfen herausgegeben werden? AWS hat auf der ESC eine explizite Policy: AWS gibt keine Kundendaten heraus, ohne zuvor die Kunden zu benachrichtigen und ihnen die Möglichkeit zu geben, rechtliche Schritte einzuleiten — es sei denn, die Benachrichtigung ist rechtlich verboten.

NIS2-Meldepflichten im laufenden Betrieb

NIS2 schreibt vor: Sicherheitsvorfälle müssen innerhalb von 24 Stunden als Frühwarnung an das BSI gemeldet werden, die vollständige Meldung folgt innerhalb von 72 Stunden. Dieser Prozess muss vor dem ersten Vorfall definiert sein — nicht danach. Legal, CISO und DPO müssen wissen, was eine NIS2-meldepflichtige Situation ist und wer die BSI-Meldung einreicht.

Storm Reply: Betriebsbegleitung nach der Migration

Storm Reply bietet neben Migrations-Services auch Managed Compliance Services für DACH-Unternehmen, die ihre souveräne Cloud-Umgebung dauerhaft sicher und compliant halten wollen. Das Leistungsportfolio im Regelbetrieb:

• Monatlicher Compliance-Bericht: Automatisierte BSI-C5-Evidenzsammlung via AWS Audit Manager, Security Hub-Posture-Bericht, GuardDuty-Findings-Zusammenfassung
• Vierteljährliches Access Review: IAM-Berechtigungsanalyse, Identifikation von Überberechtigungen, Empfehlungen für Reduktion
• Drittanbieter-Compliance-Check: Bewertung neuer Drittanbieter auf ESC-Kompatibilität vor der Freigabe
• Incident Response Retainer: 24/7-Bereitschaft für Souveränitätsvorfälle, BSI-Meldungsunterstützung, Key-Kompromittierungs-Response
• Jährliches Souveränitäts-Audit: Full-Scope-Review aller souveränen Controls, Gap-Identifikation, Vor-Audit vor dem offiziellen BSI-Prüfer-Termin

Storm Reply ist AWS Premier Consulting Partner DACH mit AWS Security Competency und 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 und weiterführende Dokumentation

1. AWS Dokumentation: AWS Key Management Service
2. AWS Dokumentation: AWS CloudHSM
3. AWS Dokumentation: AWS Audit Manager
4. AWS Dokumentation: AWS IAM Access Analyzer
5. BSI: BSI C5 Kriterienkatalog
6. BSI: NIS-2 in Deutschland
7. AWS: Europe Digital Sovereignty on AWS