AWS öffnet die Sovereign Cloud für kurzlebige Identitäten statt Dauerschlüssel

AWS öffnet die Sovereign Cloud für einen ersten Blick nach außen

Seit dem 18. August 2026 können Workloads in der AWS European Sovereign Cloud (Germany) Region erstmals mit externen Diensten kommunizieren, ohne dafür einen dauerhaft gespeicherten Zugangsschlüssel anzulegen. Wie AWS in seiner Ankündigung zur IAM-Identitätsföderation beschreibt, ermöglicht AWS Identity and Access Management (IAM) den Workloads in dieser Region jetzt, sich mit externen Services über kurzlebige JSON Web Tokens (JWTs) zu authentifizieren. Das ist mehr als eine technische Fußnote: Die AWS European Sovereign Cloud ist als eigenständige, vollständig innerhalb der Europäischen Union betriebene Cloud konzipiert, und bislang bedeutete das für viele Integrationen nach außen vor allem Mehraufwand.

Der Zeitpunkt ist kein Zufall. Sovereign-Cloud-Kunden mussten für Verbindungen zu Drittanbietern bislang eigene Workarounds bauen oder auf klassische, langlebige Zugangsschlüssel zurückgreifen – genau jene Schlüssel, die in praktisch jeder Sicherheitsanalyse als Risikofaktor Nummer eins für kompromittierte Cloud-Konten auftauchen. AWS IAM Sovereign Cloud löst dieses Problem nicht durch eine neue Ausnahmeregel, sondern durch einen Mechanismus, der in anderen AWS-Regionen längst etabliert ist: Federation statt Credentials. Für Unternehmen, die aus regulatorischen Gründen ohnehin in die Sovereign-Region gewechselt sind, war die fehlende Möglichkeit einer sauberen externen Anbindung bislang ein handfester Nachteil gegenüber den globalen AWS-Regionen.

Wer die Marketingsprache von AWS liest, könnte den Eindruck gewinnen, damit sei das Sovereignitätsproblem gelöst. Das ist es nicht. AWS öffnet lediglich einen kontrollierten Kanal nach außen – die Frage, ob ein Unternehmen diesen Kanal überhaupt nutzen darf oder soll, bleibt eine regulatorische und keine technische Entscheidung. Wer AWS IAM Sovereign Cloud als Freibrief für beliebige Drittanbieter-Integrationen missversteht, verwechselt eine technische Möglichkeit mit einer rechtlichen Erlaubnis.

OIDC ersetzt langlebige Zugangsschlüssel durch Wegwerf-Token

Technisch handelt es sich um sogenannte Outbound Identity Federation: AWS-Workloads tauschen ihre IAM-Credentials gegen kryptografisch signierte, kurzlebige JWTs, mit denen sie sich bei Drittanbieter-Clouds, SaaS-Diensten oder selbst gehosteten Anwendungen ausweisen. Damit können AWS-Workloads sich sicher gegenüber Drittanbieter-Cloud-Providern, SaaS-Anbietern und selbst gehosteten Anwendungen authentifizieren, ohne langfristige Zugangsdaten zu verwenden oder komplexe Workarounds zu implementieren – so beschreibt es AWS selbst. Das zugrunde liegende Protokoll ist dabei kein Neuland: OIDC-basierte Vertrauensbeziehungen zwischen Cloud-Anbietern und externen Parteien sind ein etablierter Standard, den AWS lediglich auf eine Region übertragen hat, die zuvor keinen Zugriff darauf hatte.

Der Unterschied zu einem klassischen API-Key ist der Lebenszyklus: Ein API-Key liegt so lange irgendwo in einer Konfigurationsdatei oder einem Secrets-Manager, bis ihn jemand rotiert – oft Monate, manchmal Jahre. Ein JWT aus dieser Föderation verfällt dagegen innerhalb von Minuten bis Stunden. Wird ein solches Token abgefangen, ist der Schaden zeitlich begrenzt; ein gestohlener Langzeitschlüssel dagegen bleibt gültig, bis jemand ihn aktiv widerruft – und das setzt voraus, dass der Diebstahl überhaupt auffällt. Genau diese Erkennungslücke ist in der Praxis oft das größere Problem als die technische Gültigkeitsdauer selbst.

Für AWS IAM Sovereign Cloud ist das der eigentliche Fortschritt: nicht der Zugriff nach außen an sich, sondern die Verkürzung des Zeitfensters, in dem ein gestohlenes Credential Schaden anrichten kann. Wer glaubt, kurzlebige Token seien allein deshalb sicherer, weil sie kurzlebig sind, unterschätzt allerdings, wie viel von der tatsächlichen Sicherheit an der Konfiguration der ausstellenden IAM-Richtlinien hängt – dazu gleich mehr. Ein kurzlebiges Token mit zu weit gefassten Rechten ist am Ende nicht sicherer als ein langlebiger Schlüssel mit engen Rechten.

Fine-Grained Access Control beginnt beim Empfänger, nicht bei AWS

Die ausgestellten Token sind keine anonymen Bearer-Token, sondern tragen laut AWS reichhaltigen Kontext über die AWS-Workloads mit sich – Informationen, mit denen externe Dienste feingranulare Zugriffskontrollen umsetzen können. In der Praxis heißt das: Ein SaaS-Anbieter kann anhand der im Token enthaltenen Attribute entscheiden, ob eine Anfrage aus der erwarteten Kontostruktur stammt, statt pauschal jeder gültigen Signatur zu vertrauen. Dazu zählen typischerweise Angaben zur Konto-ID, zur ausstellenden Rolle und zum aufrufenden Dienst – Metadaten, die eine reine Signaturprüfung allein nicht liefern würde.

Diese Verantwortung verschiebt sich damit teilweise zum Empfänger des Tokens. AWS liefert die kryptografische Grundlage und den Kontext – was der externe Dienst daraus macht, entscheidet er selbst. Ein SaaS-Anbieter, der die im Token enthaltenen Claims ignoriert und pauschal jedes gültige Token akzeptiert, gewinnt durch die Föderation an sich noch keine zusätzliche Sicherheit. Fine-Grained Access Control ist ein Feature, das aktiviert werden muss, kein Automatismus, der mit dem Umstieg auf OIDC von selbst entsteht.

Für AWS IAM Sovereign Cloud bedeutet das: Wer Partner oder Tools per Federation anbindet, sollte vorab klären, ob die Gegenseite die feingranularen Attribute überhaupt auswertet – sonst bleibt von der versprochenen Kontrolle nur die kürzere Gültigkeitsdauer des Tokens übrig, und die ist zwar wertvoll, aber eben nicht das ganze Versprechen. Beschaffungsteams sollten diese Frage künftig in jedes Sicherheitsaudit eines Drittanbieters aufnehmen, der über diesen Kanal angebunden werden soll.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA security hand adjusts concentric trust rings around a temporary glass credential before it enters a separate blue mineral enclave. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed, readable text, labels, numbers, captions, UI, dashboards, screens.

Vertrauen braucht eng gefasste Bedingungen

Damit Föderation nicht zur pauschalen Vertrauenserklärung wird, lässt AWS die Kontrolle bei den Administratoren: Sie können den Zugriff auf die Token-Erzeugung steuern und Token-Eigenschaften wie Lebensdauer, Audience und Signaturalgorithmen über IAM-Richtlinien erzwingen, während CloudTrail-Protokolle die Nutzung der Token nachvollziehbar machen. Diese drei Stellschrauben – Lebensdauer, Zielgruppe, Algorithmus – sind genau die Parameter, die in der Praxis über die tatsächliche Angriffsfläche entscheiden.

Eine kurze Lebensdauer allein schützt wenig, wenn die Audience zu weit gefasst ist und ein Token damit gegenüber mehr Diensten gültig ist als eigentlich nötig. AWS IAM Sovereign Cloud verlangt deshalb von Sicherheitsteams eine bewusste Entscheidung bei jeder dieser drei Einstellungen, statt sich auf die Standardwerte zu verlassen. Wer die Audience zu breit konfiguriert, öffnet effektiv wieder eine Tür, die die kurze Gültigkeitsdauer eigentlich schließen sollte. Ähnlich verhält es sich mit dem Signaturalgorithmus: Veraltete oder schwache Algorithmen unterlaufen den kryptografischen Schutz, den das gesamte Konzept eigentlich verspricht.

CloudTrail-Protokolle sind dabei kein nachträglicher Bonus, sondern die einzige verlässliche Quelle, um im Zweifel zu klären, welcher Workload wann welches Token mit welcher Audience angefordert hat. Ohne aktive Auswertung dieser Logs bleibt die Föderation ein Blackbox-Prozess – Sichtbarkeit entsteht erst, wenn jemand tatsächlich hinschaut. Für Compliance-Teams in regulierten Branchen ist genau diese Nachvollziehbarkeit oft die Voraussetzung dafür, die Föderation überhaupt intern freizugeben.

Die Sovereign-Grenze bleibt trotz Föderation bestehen

Es lohnt sich, an dieser Stelle über den eigentlichen Kern der AWS European Sovereign Cloud nachzudenken: eine unabhängige Cloud für Europa, vollständig innerhalb der Europäischen Union betrieben, konzipiert, um Kunden bei ihren sich entwickelnden Sovereignitätsanforderungen zu unterstützen. Die neue Federation-Funktion ändert daran nichts – sie öffnet lediglich einen kontrollierten, protokollierten Kanal nach außen, während die zugrunde liegende Infrastruktur, Betriebsführung und rechtliche Struktur der Region unverändert bleibt.

Wer AWS IAM Sovereign Cloud allein als Sicherheitsfeature liest, übersieht damit die eigentliche Pointe: Es handelt sich um ein Kontrollinstrument für einen Datenaustausch, den es vorher auch schon gab, nur eben ungeregelter. Unternehmen, die zuvor überhaupt keine Verbindung nach außen aufbauen konnten oder wollten, sind durch das Feature nicht plötzlich souveräner – sie haben nur eine sicherere Methode bekommen, falls sie sich für eine Verbindung entscheiden. Die Sovereignitätsgrenze der Region selbst verläuft weiterhin dort, wo sie vorher verlief.

Genau in diesem Punkt trennt sich saubere Berichterstattung von PR-Sprache: Nicht jede Sicherheitsverbesserung ist automatisch ein Compliance-Fortschritt. Wer die Föderation nutzt, muss weiterhin selbst prüfen, ob der jeweilige externe Dienst mit den eigenen regulatorischen Anforderungen kompatibel ist – AWS liefert dafür lediglich das technische Werkzeug, nicht die rechtliche Bewertung. Diese Prüfung lässt sich nicht outsourcen, auch nicht an den Cloud-Anbieter selbst.

Föderation ersetzt keinen Compliance-Nachweis

Diese Trennung zwischen technischer Absicherung und regulatorischer Freigabe ist besonders wichtig für Unternehmen, die die Sovereign Cloud gerade wegen strenger Auflagen gewählt haben – etwa aus dem Finanz- oder Gesundheitssektor. Kurzlebige Token machen die Anbindung an einen Drittanbieter sicherer, sie machen die Anbindung selbst aber nicht plötzlich zulässig, wenn sie es vorher nicht war. Ein Datenschutz-Folgenabschätzung entfällt nicht deshalb, weil die Authentifizierung jetzt eleganter gelöst ist.

Ähnliche Muster kennen Sicherheitsteams bereits aus dem Umgang mit kompromittierten Zugangsdaten im Alltag: Wie leicht sich gestohlene Login-Daten über Phishing-Kampagnen verbreiten lassen, zeigt unser Beitrag zum Erkennen gefälschter Amazon-Nachrichten per Mail, SMS und Anruf – genau jenes Risiko, das kurzlebige Token strukturell entschärfen, aber nicht vollständig eliminieren.

Denn ein gestohlenes Token bleibt für seine begrenzte Lebensdauer trotzdem gültig. Wer Phishing-Resistenz allein der Token-Kurzlebigkeit überlässt, ignoriert, dass die eigentliche Schwachstelle oft am Anfang der Kette liegt – bei der Anmeldung selbst, nicht bei der anschließenden Weiterleitung. Multi-Faktor-Schutz am Eingangspunkt bleibt deshalb genauso wichtig wie die kurze Gültigkeitsdauer am Ausgang.

Was Sicherheitsteams jetzt konkret prüfen sollten

Für Teams, die die neue Federation-Funktion in der AWS European Sovereign Cloud (Germany) Region einsetzen wollen, ergeben sich daraus drei konkrete Prüfpunkte: Erstens, welche IAM-Richtlinien Token-Lebensdauer und Audience tatsächlich einschränken – Standardwerte sind selten die sichersten. Zweitens, ob die empfangende Seite die im Token mitgelieferten Attribute für Fine-Grained Access Control auch tatsächlich auswertet. Drittens, ob CloudTrail-Protokolle regelmäßig und nicht erst im Ernstfall überprüft werden.

Automatisierte Auswertung dieser Protokolle wird dabei zunehmend zum Standard, nicht zur Kür – ein Trend, der sich auch in anderen Sicherheitsbereichen zeigt: Wie automatisierte Agenten heute schon Alarmmüdigkeit in Security-Teams reduzieren sollen, beschreibt unser Beitrag zu Microsoft Defender und agentenbasierter Automatisierung in der Cybersicherheit. Für AWS IAM Sovereign Cloud dürfte ähnliches gelten: Ohne automatisierte Auswertung der Audit-Logs bleibt die Kontrolle über Token-Nutzung theoretisch, nicht praktisch. Teams, die bereits Automatisierung im Security-Monitoring einsetzen, können diese Erfahrung direkt auf die neuen CloudTrail-Einträge übertragen.

Am Ende bleibt die Bilanz gemischt positiv: AWS liefert mit der Federation-Funktion einen technisch sauberen, protokollierbaren Ersatz für langlebige Zugangsschlüssel in einer Region, die bislang vergleichsweise isoliert nach außen wirkte. Das ist ein echter Sicherheitsgewinn – vorausgesetzt, die Verantwortlichen konfigurieren Lebensdauer, Audience und Signaturalgorithmen bewusst, statt sich auf Standardwerte zu verlassen, und werten die CloudTrail-Protokolle auch tatsächlich aus. Wer diese drei Hausaufgaben macht, gewinnt echte Kontrolle. Wer es bei der Ankündigung belässt, hat nur ein neues Werkzeug im Schrank, das niemand benutzt.