Souveräne Cloud: Welche Angebote es gibt und was Souveränität wirklich bedeutet

Die fünfte Zeile ist die einzige, die sich vollständig technisch beweisen lässt. Alle anderen beruhen auf Verträgen, Zertifikaten und Organisationsstrukturen. Deshalb lohnt es sich, die Schlüsselhoheit als Rückfallebene ernst zu nehmen: Wenn der Anbieter Daten technisch nicht lesen kann, verlieren die Stufen zwei bis vier einen Teil ihrer Schärfe. Umgekehrt gilt: Wenn der Anbieter eure Schlüssel verwaltet, ist jede Souveränitätszusage eine organisatorische Zusage und keine technische.

Der Markt bewegt sich hier schneller als jede Übersicht. Neue souveräne Regionen werden angekündigt, verschieben sich, starten mit einem eingeschränkten Dienstekatalog und wachsen danach. Prüfe deshalb kurz vor der Entscheidung drei Dinge selbst: Welche Region ist tatsächlich verfügbar, welche Dienste sind dort freigeschaltet, und welche Gesellschaft steht im Vertrag. Ein Anbietervergleich aus dem Vorjahr taugt in diesem Segment nur als Einstieg. Für die vertragliche Seite des Wechsels lohnt zusätzlich der Blick auf die Pflichten aus dem EU Data Act.

SUB=$(az account show --query id -o tsv)

# Welche Regionen stehen ueberhaupt in Deutschland zur Verfuegung?
az account list-locations \
  --query "[?contains(name,'germany')].{Name:name, Anzeige:displayName}" -o table

# Eingebaute Richtlinie 'Allowed locations' zuweisen
az policy assignment create \
  --name nur-deutsche-regionen \
  --display-name "Ressourcen nur in deutschen Regionen" \
  --scope "/subscriptions/$SUB" \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations":{"value":["germanywestcentral","germanynorth"]}}'

Die Richtlinie wirkt beim Anlegen neuer Ressourcen und nicht rückwirkend. Führe deshalb einmal eine Bestandsaufnahme durch, bevor du sie zuweist, sonst hältst du eine saubere Umgebung für gegeben, die es nicht ist. Beachte außerdem, dass einige Dienste global registriert werden und deshalb ausgenommen werden müssen.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NurEuropaeischeRegionen",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "sts:*", "organizations:*", "account:*",
        "support:*", "health:*", "budgets:*", "ce:*", "cur:*",
        "cloudfront:*", "route53:*", "waf:*", "shield:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
        }
      }
    }
  ]
}

Die Ausnahmen in NotAction sind kein Nachlassen, sondern notwendig: Diese Dienste sind global und würden sich sonst selbst sperren, inklusive der Anmeldung. Hinterlege die Richtlinie auf der Ebene der Organisationseinheit, damit sie auch für neu angelegte Konten sofort greift. Wichtig: Auch Abrechnung und Kostenanalyse melden sich in us-east-1 an. Wer budgets und ce in der Ausnahmeliste vergisst, verliert nach dem Ausrollen den Blick auf die eigene Rechnung.

Ergänze beide Leitplanken um eine Prüfung der Nebenwege. Sicherungen, Protokollweiterleitung, Verwaltungswerkzeuge und Überwachungsdienste haben eigene Zielregionen, die häufig unabhängig von der Ressource konfiguriert werden. Wer nur die Rechenleistung prüft, findet später Protokolldaten in einer Region, die niemand ausgewählt hat. Diese Prüfung gehört in dieselbe Bestandsaufnahme, die ohnehin für ein C5-Testat nötig ist.

# Verwaltetes HSM in einer deutschen Region anlegen
az keyvault create \
  --hsm-name cmt-hsm-de \
  --resource-group rg-souveraen \
  --location germanywestcentral \
  --retention-days 7 \
  --administrators "$(az ad signed-in-user show --query id -o tsv)"

# Schluessel erzeugen, der das HSM nie verlaesst
az keyvault key create \
  --hsm-name cmt-hsm-de \
  --name daten-kek \
  --kty RSA-HSM --size 3072 \
  --ops wrapKey unwrapKey

Ein im HSM erzeugter Schlüssel kann nicht exportiert werden. Damit ist technisch belegbar, dass nur eure Anwendung Daten entschlüsseln kann. Plane den Wiederherstellungsfall mit: Ein verlorener Schlüssel bedeutet verlorene Daten, und genau das ist der Preis echter Schlüsselhoheit.

# Externer Schluesselspeicher: das Schluesselmaterial bleibt im eigenen HSM
aws kms create-custom-key-store \
  --custom-key-store-name souveraen-de \
  --custom-key-store-type EXTERNAL_KEY_STORE \
  --xks-proxy-connectivity PUBLIC_ENDPOINT \
  --xks-proxy-uri-endpoint https://xks.beispiel.de \
  --xks-proxy-uri-path /kms/xks/v1

# Zustand pruefen: ohne erreichbaren Proxy ist der Speicher nicht nutzbar
aws kms describe-custom-key-stores \
  --query 'CustomKeyStores[].{Name:CustomKeyStoreName,Status:ConnectionState}'

Der zweite Befehl zeigt zugleich das Betriebsrisiko: Ist euer Proxy nicht erreichbar, kann AWS nichts mehr entschlüsseln. Das ist der gewünschte Effekt und gleichzeitig ein Einzelfehlerpunkt, der Hochverfügbarkeit und einen geübten Wiederanlauf braucht.

Eine eigene Plattform auf OpenStack oder Kubernetes erfüllt alle vier Stufen, weil Technologie, Betrieb, Standort und Rechtsraum vollständig bei euch liegen. Der Preis dafür ist Betriebsverantwortung: Kapazitätsplanung, Hardwarebeschaffung, Speicher, Netz, Aktualisierungen und Bereitschaft gehören dann euch. Diese Rechnung geht ab einer bestimmten Größe auf und darunter nicht. Ehrlich ist sie nur, wenn ihr die Personalkosten über drei Jahre und den Aufbau von Fachwissen mit einrechnet, nicht nur die Hardware.

# Welche Dienste sind im Katalog freigeschaltet?
openstack catalog list

# Verfuegbarkeitszonen und ihre Trennung
openstack availability zone list --compute --volume

# Was steht an Rechenprofilen und Abbildern bereit?
openstack flavor list
openstack image list --status active

# Quoten des Projekts, damit die Kapazitaetsplanung stimmt
openstack quota show --detail

Der Dienstekatalog ist der schnellste Realitätsabgleich, auch bei einem Anbieter, der OpenStack betreibt. Was dort nicht steht, gibt es nicht, unabhängig davon, was auf der Produktseite beschrieben ist.