Security-Architektur für souveräne Cloud-Plattformen

Souveräne Cloud-Plattformen adressieren regulatorische Anforderungen, geopolitische Risiken und strukturelle Abhängigkeiten von globalen Plattformanbietern. In der Praxis zeigt sich jedoch ein wiederkehrendes Muster: Souveränität wird mit Standort gleichgesetzt. Rechenzentren in der EU, angepasste Vertragsmodelle oder neue Produktlabels gelten als ausreichende Maßnahme.

Technisch greift diese Sichtweise zu kurz. Fehlende Souveränität entsteht überwiegend durch Architekturentscheidungen – etwa durch zentralisierte Control Planes außerhalb der Jurisdiktion, unklare Identitätsdomänen, globale API-Abhängigkeiten oder unkontrollierte Schlüsselverwaltung.

Entscheidend ist nicht allein der Speicherort von Daten, sondern die strukturelle Kontrollierbarkeit der gesamten Plattformarchitektur.

Souveränität entsteht durch konsequent jurisdiktionsgetrennte Architektur. Architektur, Betrieb und Governance müssen so gestaltet sein, dass klar definierte Kontrollzonen technisch durchgesetzt werden können.

Im Kern lassen sich die sicherheitsrelevanten Architekturentscheidungen souveräner Cloud-Plattformen in fünf strukturelle Dimensionen gliedern:

1. Jurisdiktion und Datenflussarchitektur
2. Identitäts- und Vertrauensmodelle
3. Kryptografische Hoheit und Schlüsselkontrolle
4. Netzwerk- und API-Governance
5. Steuerungshoheit über Control Plane und Lieferkette

Erst das konsistente Zusammenspiel dieser Ebenen reduziert strukturelle Abhängigkeiten nachhaltig.

Jurisdiktion als Architekturparameter – Datenflussarchitektur statt Standortlogik

Data Residency beschreibt den physischen Speicherort von Daten innerhalb einer definierten Jurisdiktion. Ob dieser Zustand dauerhaft durchsetzbar bleibt, entscheidet sich auf Architekturebene.

Rechenzentren innerhalb der EU sind eine notwendige Voraussetzung. Souveränität erfordert darüber hinaus die Kontrolle über Control Planes, Identitätsdomänen und Schlüsselverwaltung.

Zentrale operative Fragen sind:

• Wo verlaufen Datenflüsse?
• Wo werden Backups repliziert?
• Wo operiert die Control Plane?
• Wo entstehen Metadaten, Telemetrie und Administrationsprotokolle?

Workloads benötigen klar definierte Speichergrenzen, technisch erzwungenes Geo-Fencing im Netzwerk und streng kontrollierte Replikationspfade. Management- und Orchestrierungsdienste sind dabei besonders sensibel. Wird die Control Plane außerhalb der definierten Jurisdiktion betrieben, entsteht ein strukturelles Abhängigkeitsverhältnis – selbst bei lokal gespeicherten Nutzdaten.

Multi-Region-Architekturen erhöhen die Verfügbarkeit, können jedoch regulatorische Zuständigkeitsgrenzen überschreiten. Disaster-Recovery-Strategien müssen daher rechtlich und technisch konsistent ausgelegt sein.

Identitäts- und Vertrauensmodelle – Trust Boundary Enforcement

Die Jurisdiktion definiert den äußeren Kontrollrahmen. Das Identitätsmodell bestimmt die interne Durchsetzung von Zugriffen und Berechtigunge. Souveräne Plattformen erfordern klar definierte und technisch erzwungene Vertrauensgrenzen.

Zentrale Fragestellungen sind:

• Wer authentifiziert wen?
• Wer kontrolliert die Authentifizierungsinstanz?
• Unter welcher rechtlichen Hoheit steht der Identity Provider?
• Wie sind Betreiberzugriffe von Kundendomänen technisch isoliert?

Ein belastbares Design trennt Human Identities, Non-Human Identities, Betreiber-Accounts und Kunden-Workload-Identitäten konsequent voneinander. Zero-Trust-Prinzipien, minimale Privilegien sowie kontrollierte administrative Zugriffe mit Just-in-Time-Mechanismen und vollständiger Auditierbarkeit bilden die Grundlage.

Unzureichend segmentierte IAM-Strukturen oder persistente Plattform-Accounts erzeugen interne Angriffsflächen – unabhängig vom Standort.

Kryptografische Hoheit und Schlüsselkontrolle – Kontrolle über den Schlüssel-Lifecycle

Kryptografische Kontrolle ist ein zentraler Indikator für Datensouveränität. Werden Schlüssel durch den Plattformanbieter verwaltet, verbleibt ein indirektes Zugriffsrisiko.

Architekturen sollten daher Customer Managed Keys oder Hold Your Own Key Modelle priorisieren. Hardware Security Modules innerhalb der definierten Jurisdiktion bilden die technische Basis.

Entscheidend ist der vollständige Schlüssel-Lifecycle:

• Kontrolle über Rotation und Revocation
• Technisch abgesicherte Backup-Mechanismen
• Strikt geregelte Exportfähigkeit von Schlüsselmaterial
• Dokumentierte und auditierbare Zugriffspfade

Confidential Computing gewinnt zusätzlich an Bedeutung, insbesondere bei regulierten Analyse-Workloads oder organisationsübergreifenden Datenräumen.

Netzwerk- und API-Governance – Durchsetzung der Kontrollzonen

Identität regelt den Zugriff. Netzwerkarchitektur steuert die tatsächliche Datenbewegung.

Default-Deny-Policies, feingranulare Netzwerksegmentierung und die Trennung interner und externer Datenflüsse sind grundlegende Designprinzipien. Service-Mesh-Architekturen mit Mutual TLS sichern Kommunikationsbeziehungen kryptografisch ab und begrenzen laterale Bewegungen.

Egress-Pfade zählen zu den kritischsten Kontrollpunkten. Unkontrollierte API-Aufrufe oder offene Internet-Routen können Datenflüsse außerhalb der vorgesehenen Jurisdiktion auslösen. Durchsetzbare DNS-Policies, restriktive Egress-Filter, dedizierte Secure Gateways und verbindliche API-Governance sind daher zentrale Architekturmechanismen.

Steuerungshoheit über Control Plane und Lieferketten

Control Plane Ownership ist ein zentrales Kriterium struktureller Unabhängigkeit. Werden administrative Steuerungsmechanismen außerhalb der souveränen Zone betrieben oder bleiben Remote-Zugriffe technisch möglich, entsteht eine dauerhafte Abhängigkeit vom Anbieter.

Erforderlich sind:

• Strikte Trennung von Control Plane und Data Plane
• Separate Authentifizierungsdomänen
• Dedizierte Management-Netzwerke
• Technisch eingeschränkte Remote-Zugriffe

Parallel gewinnt die Absicherung der Software-Lieferkette an Bedeutung. Signierte Artefakte, geprüfte Container-Images und kontrollierte Build-Prozesse sichern Herkunft und Integrität der Plattform.

Die konkrete Bewertung variiert je nach Servicemodell. Auf IaaS-Ebene stehen Infrastruktur- und Replikationspfade im Fokus. Bei PaaS und SaaS verschiebt sich die Aufmerksamkeit auf Managed Control Planes, Telemetriedienste und API-Endpunkte.

Plattform Engineering als Governance-Modell

positioniert Plattform Engineering als zentrales Organisations- und Architekturmodell für kontrollierte Cloud-Umgebungen. Ziel sind standardisierte, policy-gesteuerte Plattformen, die Self-Service ermöglichen und gleichzeitig technische Governance durchsetzen.

Compliance as Code, Security as Code und Continuous Control Monitoring überführen regulatorische Anforderungen wie DSGVO oder NIS2 in überprüfbare technische Kontrollen. Policies werden versioniert, automatisiert validiert und revisionssicher dokumentiert.

Auditierbarkeit bedeutet die vollständige Nachvollziehbarkeit jeder Konfigurationsänderung und bildet die Grundlage belastbarer Compliance.

Operational Security – Souveränität im Krisenfall

Die Belastbarkeit einer souveränen Plattform zeigt sich im Incident-Fall. SIEM-Integration, zentrale Log-Korrelation und klar definierte Incident-Response-Prozesse sind Voraussetzung. Security Monitoring muss innerhalb der souveränen Zone betrieben oder technisch abgesichert sein.

Im Kompromittierungsfall muss die Architektur folgende Fähigkeiten gewährleisten:

• forensische Beweissicherung innerhalb der Jurisdiktion sicherzustellen
• administrative Zugriffe technisch zu begrenzen
• Schlüsselmaterial kontrolliert zu rotieren
• Vertrauenszonen temporär zu isolieren
• Souveränität wird im Krisenfall überprüfbar.

Erst im Krisenfall wird die tatsächliche Durchsetzungsfähigkeit der Architektur überprüfbar.

Souveräne Cloud-Architektur systematisch bewerten

Souveräne Cloud-Architektur erfordert mehr als Vertragsprüfungen oder Standortanalysen. Maßgeblich ist die strukturierte Bewertung der genannten Architekturentscheidungen über Jurisdiktion, Identität, Kryptografie, Netzwerk und Steuerungsebenen hinweg.

Organisationen, die diese Dimensionen konsequent analysieren und technisch umsetzen, reduzieren strukturelle Abhängigkeiten und schaffen eine belastbare Grundlage für regulierte Workloads, KI-Plattformen und kritische Infrastrukturen.