Sovereign Cloud auf Azure: Datenresidenz, Verschluesselung und EU-Compliance-Muster

Datensouveraenitaet ist kein Compliance-Haekchen mehr — sie ist ein Thema auf Vorstandsebene, das die Cloud-Strategie jedes europaeischen Unternehmens praegt. Die Kombination aus DSGVO-Durchsetzungsmassnahmen, Schrems-II-Auswirkungen und neuen Regelungen wie dem EU Data Act hat eine Landschaft geschaffen, in der "wir nutzen Azure in West Europe" keine ausreichende Antwort auf die Frage der Datensouveraenitaet ist.

Dieser Leitfaden bietet eine praktische Architektur fuer den Aufbau souveraener Cloud-Loesungen auf Azure. Wir behandeln das gesamte Spektrum: Datenresidenzkontrollen, Verschluesselung mit kundenverwalteten Schluesseln, Confidential Computing fuer Verarbeitungssouveraenitaet und das Compliance-Framework, das alles zusammenhaelt.

Das Souveraenitaets-Spektrum

Souveraenitaet ist nicht binaer. Sie existiert auf einem Spektrum, und das Verstaendnis, wo Ihre Organisation sein muss, ist die erste Architekturentscheidung.

Level 1 — Datenresidenz: Kundendaten im Ruhezustand und bei der Uebertragung bleiben innerhalb einer definierten Geographie. Dies ist das Minimum fuer DSGVO-Compliance.

Level 2 — Operationelle Souveraenitaet: Zusaetzlich zur Datenresidenz wird der operative Zugriff durch den Cloud-Anbieter kontrolliert, protokolliert und kann verweigert werden. Microsofts Customer Lockbox faellt hierunter.

Level 3 — Kryptographische Souveraenitaet: Sie kontrollieren die Verschluesselungsschluessel, und ohne Ihre explizite Freigabe sind Daten nicht zugaenglich — selbst fuer den Cloud-Anbieter nicht. Azure Key Vault Managed HSM ermoeglicht dies.

Level 4 — Verarbeitungssouveraenitaet: Selbst waehrend der Berechnung sind Daten vor dem Cloud-Betreiber geschuetzt durch hardwarebasierte Trusted Execution Environments. Azure Confidential Computing liefert dies.

Level 5 — Vollstaendige Souveraenitaet: Die Infrastruktur wird von einer souveraenen Entitaet betrieben, nicht direkt vom Hyperscaler. Azure Stack HCI vor Ort erreicht dieses Level.

Die meisten europaeischen Unternehmen benoetigen Level 2-3. Regulierte Branchen (Gesundheitswesen, Finanzen, oeffentlicher Sektor) erfordern zunehmend Level 4.

Azure EU Data Boundary: Was abgedeckt ist und was nicht

Microsofts EU Data Boundary ist die Grundlage. 2022 angekuendigt und schrittweise erweitert, verpflichtet sie sich, EU-Kundendaten innerhalb der EU zu halten.

Was abgedeckt ist

• Kern-Plattformdienste: Compute, Storage, Datenbanken, Networking fuer in EU-Regionen bereitgestellte Ressourcen
• Professional-Services-Daten: Support-Ticket-Daten bleiben in der EU
• Entra ID Authentifizierungsprotokolle: Werden innerhalb der EU-Boundary verarbeitet
• Microsoft 365 Inhaltsdaten: E-Mails, Dokumente, Teams-Nachrichten fuer EU-Mandanten

Was nicht vollstaendig abgedeckt ist

• Globale Netzwerktelemetrie: Einige operative Daten ueber Netzwerk-Routing koennen die EU verlassen
• Missbrauchserkennung und Sicherheitssignale: Threat-Intelligence-Korrelation kann globale Verarbeitung beinhalten
• Drittanbieter-Marketplace-Apps: Souveraenitaet haengt vom ISV ab, nicht von Microsoft
• Azure DevOps: Regionseinstellungen explizit ueberpruefen; Standardverhalten variiert

Kritische Ueberpruefungsschritte

# Ressourcenstandort programmatisch ueberpruefen
az resource list --query "[].{Name:name, Location:location, Type:type}" \
  --output table | grep -v "westeurope\|northeurope\|germanywestcentral\|francecentral\|swedencentral"

# Azure Policy fuer erlaubte Standorte pruefen
az policy assignment list --query "[?contains(policyDefinitionId, 'allowedLocations')]" \
  --output table

Datenklassifizierung und Souveraenitaetszonen

Bevor Sie technische Kontrollen auswaehlen, klassifizieren Sie Ihre Daten. Nicht alle Daten erfordern dasselbe Souveraenitaetsniveau, und alles uebermaessig zu schuetzen ist teuer.

Klassifizierungsrahmen

Implementierung von Souveraenitaetszonen in Azure

// Souveraenitaetszone via Management Groups
targetScope = 'managementGroup'

// Zone 1: Standard-EU-Workloads (Level 1-2)
resource mgStandardEU 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-sovereign-standard-eu'
  properties: {
    displayName: 'Standard EU Workloads'
  }
}

// Zone 2: Vertrauliche Workloads (Level 3-4)
resource mgConfidentialEU 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-sovereign-confidential-eu'
  properties: {
    displayName: 'Confidential EU Workloads'
  }
}

// Policy: Regionen auf EU beschraenken
resource policyAllowedLocations 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'restrict-to-eu-regions'
  properties: {
    policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c'
    parameters: {
      listOfAllowedLocations: {
        value: [
          'westeurope'
          'northeurope'
          'germanywestcentral'
          'francecentral'
          'francesouth'
          'swedencentral'
          'swedensouth'
          'norwayeast'
          'norwaywest'
          'switzerlandnorth'
          'switzerlandwest'
          'polandcentral'
          'italynorth'
          'spaincentral'
        ]
      }
    }
  }
}

Verschluesselungsarchitektur: Kundenverwaltete Schluessel

Standard-Azure-Verschluesselung verwendet Microsoft-verwaltete Schluessel. Dies erfuellt grundlegende Compliance, bietet aber keine kryptographische Souveraenitaet — Microsoft kontrolliert die Schluessel und koennte theoretisch unter einem US-Gerichtsbeschluss gezwungen werden, Zugang zu gewaehren.

Key Vault Hierarchie fuer Souveraenitaet

Implementierung mit Managed HSM

// Managed HSM Deployment - erfordert 3 RSA-Schluesselinhaber zur Aktivierung
resource managedHsm 'Microsoft.KeyVault/managedHSMs@2023-07-01' = {
  name: 'hsm-sovereign-${environment}'
  location: 'germanywestcentral'
  properties: {
    tenantId: subscription().tenantId
    initialAdminObjectIds: [securityTeamObjectId]
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    networkAcls: {
      bypass: 'None'
      defaultAction: 'Deny'
      ipRules: [
        { value: corporateEgressIp }
      ]
      virtualNetworkRules: [
        { id: managementSubnetId }
      ]
    }
  }
  sku: {
    family: 'B'
    name: 'Standard_B1'
  }
}

Dienste mit Unterstuetzung fuer kundenverwaltete Schluessel

Confidential Computing: Verarbeitungssouveraenitaet

Verschluesselung im Ruhezustand und bei der Uebertragung ist Standard. Confidential Computing fuegt Verschluesselung waehrend der Verarbeitung hinzu — Daten sind selbst vor dem Cloud-Betreiber, Hypervisor und anderen Mandanten geschuetzt.

Azure Confidential Computing Optionen

DCasv5 / ECasv5 VMs (AMD SEV-SNP): Hardwarebasierte Speicherverschluesselung. Der gesamte VM-Speicher wird mit einem Schluessel verschluesselt, der vom AMD Secure Processor verwaltet wird und fuer den Hypervisor nicht zugaenglich ist. Optimal fuer Lift-and-Shift-Szenarien.

DCsv3 / DCdsv3 VMs (Intel SGX): Enclaves auf Anwendungsebene. Granularer als vollstaendige VM-Verschluesselung, erfordert aber Codeanpassungen mit dem Open Enclave SDK oder Intel SGX SDK.

Confidential Containers auf AKS: Container in hardwarebasierten Trusted Execution Environments ausfuehren. Die Kubernetes Control Plane kann den Container-Speicher nicht inspizieren.

Wann Confidential Computing gerechtfertigt ist

Confidential Computing fuegt Kosten (10-30 % Aufschlag auf Compute) und Komplexitaet hinzu. Verwenden Sie es wenn:

• Sie Gesundheitsdaten verarbeiten (Art. 9 DSGVO besondere Kategorien)
• Multi-Party-Computation-Szenarien, bei denen Parteien einander nicht vertrauen
• Sie Regulierern demonstrieren muessen, dass nicht einmal Ihr Cloud-Anbieter auf Daten waehrend der Verarbeitung zugreifen kann
• Finanzdienstleistungsverarbeitung unter BaFin- oder EZB-Aufsicht

DSGVO und Schrems II: Praktische Compliance-Architektur

Schrems-II-Auswirkungen fuer Azure

Das Schrems-II-Urteil (2020) hat den EU-US Privacy Shield fuer ungueltig erklaert und die Anforderungen an Datentransfers in Laender ohne angemessenen Datenschutz erhoeht. Fuer Azure-Kunden bedeutet das:

1. Standardvertragsklauseln (SCCs) sind notwendig, aber nicht hinreichend. Microsoft bietet SCCs an, aber Sie muessen eine Transfer Impact Assessment (TIA) fuer alle Daten durchfuehren, auf die theoretisch von ausserhalb der EU zugegriffen werden koennte.

2. US CLOUD Act Risiko. Als US-amerikanisches Unternehmen unterliegt Microsoft dem CLOUD Act. Kundenverwaltete Schluessel mit Managed HSM mildern dies — Microsoft kann Daten ohne Ihre Schluessel nicht entschluesseln.

3. EU-US Data Privacy Framework. Der Angemessenheitsbeschluss von 2023 bietet eine Rechtsgrundlage, aber seine Bestaendigkeit ist unsicher. Bauen Sie Ihre Souveraenitaetsstrategie nicht allein auf das DPF.

Defence-in-Depth Compliance-Architektur

Souveraenitaets-Audit-Workbook-Abfragen

// Erkennung von Ressourcen-Deployments ausserhalb der EU-Regionen
AzureActivity
| where OperationNameValue has "Microsoft.Resources/deployments/write"
| where ActivityStatusValue == "Success"
| extend resourceLocation = tostring(parse_json(Properties).targetResource.resourceLocation)
| where resourceLocation !in (
    "westeurope", "northeurope", "germanywestcentral",
    "francecentral", "swedencentral", "norwayeast",
    "switzerlandnorth", "polandcentral", "italynorth", "spaincentral"
  )
| project TimeGenerated, Caller, resourceLocation, ResourceGroup

Vergleich der Azure Sovereign-Angebote

Umsetzungs-Roadmap

Wochen 1-2: Bewertung. Alle Daten klassifizieren. Regulatorische Anforderungen auf Souveraenitaetslevel abbilden. Luecken zwischen Ist-Zustand und Ziel identifizieren.

Wochen 3-4: Fundament. Managed HSM deployen. Azure Policy fuer Regionsbeschraenkungen implementieren. Customer Lockbox mandantenweit aktivieren.

Wochen 5-8: Migration. Verschluesselung auf kundenverwaltete Schluessel umstellen, Dienst fuer Dienst. Private Endpoints aktivieren. Souveraenitaets-Audit-Workbook deployen.

Wochen 9-12: Vertrauliche Workloads. Workloads mit Einstufung "Eingeschraenkt" auf Confidential Computing migrieren. Mit Penetrationstests und Compliance-Audit validieren.

Fortlaufend: Monatliche Souveraenitaets-Posture-Reviews. Vierteljaehrliche TIA-Updates. Jaehrliches Drittanbieter-Compliance-Audit.

Kompromisse und ehrliche Bewertung

Sovereign Cloud auf Azure ist erreichbar, bringt aber Kompromisse mit sich:

• Kosten: Managed HSM beginnt bei ca. EUR 3.500/Monat. Confidential VMs sind 10-30 % teurer. Die Souveraenitaets-Praemie betraegt typischerweise 15-25 % auf Compute- und Storage-Kosten.
• Feature-Einschraenkungen: Nicht jeder Azure-Dienst unterstuetzt CMK oder Confidential Computing. Sie muessen moeglicherweise bestimmte PaaS-Dienste meiden.
• Operationelle Komplexitaet: Key-Management, Rotationsrichtlinien und Break-Glass-Prozeduren erhoehen den operativen Aufwand.
• Performance: Confidential Computing kann 5-15 % Latenz bei speicherintensiven Workloads hinzufuegen.

Diese Kompromisse sind fuer Organisationen mit echten regulatorischen Anforderungen gerechtfertigt. Sie sind uebertrieben fuer Organisationen, die keine sensiblen europaeischen personenbezogenen Daten verarbeiten.

Naechste Schritte

Souveraenitaetsarchitektur erfordert die Balance zwischen regulatorischer Compliance und operationellem Pragmatismus. Ueber-Engineering verschwendet Budget. Unter-Engineering riskiert regulatorische Strafen und Kundenvertrauen.

Wenn Sie Hilfe bei der Bewertung Ihrer Souveraenitaetsanforderungen, dem Design Ihrer Verschluesselungsarchitektur oder der Implementierung von Confidential-Computing-Workloads auf Azure benoetigen, kontaktieren Sie uns unter mbrahim@conceptualise.de. Wir helfen europaeischen Unternehmen, Cloud-Architekturen zu bauen, die Regulierer zufriedenstellen, ohne Agilitaet zu opfern.