Cloud-Sicherheitsarchitektur 2026: Modellierung, Angriffspfade und resiliente Verteidigung in Multi-Cloud-, Kubernetes- und KI-gestützten Betriebsumgebungen

1. Introduction

Cloud Computing ist 2026 nicht mehr nur ein Bereitstellungsmodell, sondern der operative Kern nahezu aller digitalisierten Organisationen. In vielen Unternehmen laufen Geschäftsanwendungen, Identitätsdienste, Datenplattformen, Build-Systeme und KI-Workloads in einer Kombination aus Public Cloud, Private Cloud und Edge-Integrationen. Diese Entwicklung hat die klassischen Annahmen der Netzwerksicherheit weitgehend obsolet gemacht. Perimeter-basierte Kontrollen sind durch identitätszentrierte Zugriffe, API-getriebene Automatisierung und hochdynamische Workloads ersetzt worden, wobei sich die Angriffsoberfläche von wenigen zentralen Systemen auf Millionen von Ressourcenobjekten, Tokens, Rollen und Service-Accounts verteilt. Die Folge ist eine Sicherheitslandschaft, in der Fehlkonfigurationen, überprivilegierte Identitäten und Supply-Chain-Schwächen regelmäßig produktionsrelevante Vorfälle auslösen (NIST, 2024; ENISA, 2024).

Die Praxis zeigt, dass sich Cloud-Vorfälle selten auf einen einzelnen Fehler zurückführen lassen. Häufig entstehen sie aus einer Kaskade kleiner Schwächen: ein unzureichend abgesicherter IAM-Trust, ein offener Objekt-Storage-Bucket, ein verwundbares Container-Image, fehlende NetworkPolicies oder eine CI/CD-Pipeline mit zu weitreichenden Berechtigungen. In Multi-Cloud-Umgebungen verstärken sich diese Risiken durch inkonsistente Steuerungsmodelle, unterschiedliche Semantiken für Rollen und Policies sowie fragmentierte Logging- und Detektionsmechanismen. Während Zero Trust in den letzten Jahren von einer Architekturvision zu einem etablierten Betriebsprinzip gereift ist, bleibt die konsistente Umsetzung in Cloud-Umgebungen anspruchsvoll, insbesondere wenn Workloads von Menschen, Maschinen und zunehmend auch von KI-Agenten gestartet, verändert und orchestriert werden (Microsoft, 2023; CISA, 2024).

Die Bedrohungslage 2026 ist zusätzlich durch generative KI verschärft. LLM-basierte Assistenten sind in DevOps-, SecOps- und Plattform-Teams weit verbreitet, werden aber oft mit Zugriff auf Konfigurations- und Telemetriedaten eingebunden. Dadurch entstehen neue Angriffsformen wie Prompt Injection, indirekte Datenexfiltration, tool abuse und insecure model output handling. Cloud-Sicherheit muss deshalb nicht nur klassische Infrastruktur absichern, sondern auch die Interaktion zwischen Menschen, Agenten, Modellen und Steuerungssystemen kontrollieren. Die Sicherheitsfragen reichen von der Frage, ob ein Modell auf sensitive Daten zugreifen darf, bis hin zu der Frage, ob ein generierter YAML- oder Terraform-Block ohne Verifikation in Produktion gelangen kann (OWASP, 2024; NIST, 2024b).

Diese Arbeit verfolgt drei Ziele. Erstens wird Cloud-Sicherheit als formales Problem der Pfad- und Zustandsreduktion modelliert. Zweitens wird eine praxisorientierte Verteidigungsarchitektur vorgeschlagen, die präventive, detektive und reaktive Kontrollen kombiniert. Drittens wird die Wirksamkeit dieser Architektur anhand realitätsnaher Metriken evaluiert. Der Schwerpunkt liegt auf Multi-Cloud-, Kubernetes- und serverlosen Umgebungen, da diese 2026 die höchste operative Relevanz besitzen. Besonderes Augenmerk gilt der Identitätsebene, weil dort die meisten Angriffe beginnen und weil nahezu jede erfolgreiche Cloud-Kompro­mit­tie­rung letztlich auf eine Form von Missbrauch legitimer Zugänge zurückgeführt werden kann.

Formell lässt sich das Risiko einer Kompromittierung als Funktion der Angriffsoberflächen und Kontrollen ausdrücken. Für eine Menge von Pfaden $A = {a_1, a_2, \dots, a_n}$ und Kontrollen $C = {c_1, c_2, \dots, c_m}$ definieren wir näherungsweise:

$$ P(\text{Compromise}) = 1 - \prod_{i=1}^{n} \left(1 - p(a_i)\cdot \prod_{j=1}^{m}(1-r(c_j,a_i))\right) $$

Dabei ist $p(a_i)$ die Basiswahrscheinlichkeit eines Angriffspfads und $r(c_j,a_i)$ der Reduktionsfaktor einer Kontrolle auf diesen Pfad. Diese Modellierung ist bewusst pragmatisch und dient nicht der exakten Vorhersage, sondern der Priorisierung von Maßnahmen. Sie erlaubt jedoch eine klare Operationalisierung: Cloud-Sicherheit verbessert sich nicht durch einzelne Produkte allein, sondern durch systematische Reduktion dominanter Pfade, insbesondere Identitätsmissbrauch, Secrets-Exposition, unsichere Build- und Deployment-Flows sowie mangelnde Runtime-Sichtbarkeit.

2. Background and Related Work

Cloud-Sicherheit hat sich aus drei historischen Linien entwickelt. Die erste Linie stammt aus der klassischen Netzwerksicherheit und konzentrierte sich auf Perimeter, Firewalls, VPNs und Segmentierung. Die zweite Linie entstand aus der Virtualisierung und betraf Mandantenisolierung, Hypervisor-Härtung und Verwaltungsdomänen. Die dritte Linie ist nativ cloudorientiert und umfasst APIs, IAM, Policy-as-Code, Infrastruktur als Code, Container-Orchestrierung und kontinuierliche Compliance. 2026 ist klar, dass nur die dritte Linie die tatsächliche Betriebsrealität abbildet, während die beiden ersten Linien lediglich Teilaspekte adressieren (BELL, 2020; VAQUERO, 2019).

Zero Trust wurde durch NIST SP 800-207 zu einem strukturierten Architekturmodell, das implizites Vertrauen durch explizite, kontinuierliche Verifikation ersetzt (NIST, 2020). Für Cloud-Umgebungen ist dieser Ansatz besonders wertvoll, weil Zugriff nicht mehr primär aus dem Netzrand abgeleitet wird, sondern aus Identitäts-, Gerätezustands- und Kontextsignalen. Gleichzeitig zeigt die Praxis, dass Zero Trust in Cloud-Architekturen häufig unvollständig umgesetzt wird. Viele Organisationen segmentieren zwar Netze, lassen jedoch IAM-Politiken zu breit, erlauben langlebige Schlüssel oder vernachlässigen die Trennung zwischen Steuerungs- und Datenebene. Hier entsteht ein Widerspruch zwischen architektonischer Absicht und operativer Realität.

Kubernetes hat die Cloud-Sicherheitsforschung dominiert, weil es als De-facto-Orchestrator die meisten modernen Plattformen prägt. Angriffe auf Kubernetes reichen von unsicheren kubeconfig-Dateien und überprivilegierten Service-Accounts bis zu Admission-Control-Umgehungen, API-Server-Missbrauch und Container-Escape-Szenarien. Die Forschung hat gezeigt, dass Fehlkonfigurationen in Cluster-Rollen, fehlende Pod Security Controls und exponierte Dashboards wiederholt zu Kompromittierungen führen. Gleichzeitig hat sich die Verteidigung verbessert: Pod Security Standards, NetworkPolicies, runtime enforcement, Image-Scanning und Policy Engines wie OPA/Gatekeeper und Kyverno sind inzwischen Standardwerkzeuge in reifen Umgebungen (AQUA, 2024; SIG-SEC, 2024).

Auch die Cloud-Infrastruktur selbst ist reifer geworden. AWS, Azure und Google Cloud haben ihre nativen Sicherheitskontrollen erweitert, etwa durch verbesserte Audit-Logs, Identity Center, workload identity federation, Security Command Center, Defender for Cloud und integrierte Key-Management- und DLP-Funktionen. Dennoch zeigen Berichte von Mandiant, CrowdStrike, Wiz, Palo Alto Networks und Microsoft immer wieder, dass Fehlkonfigurationen und Identitätsmissbrauch die Hauptursachen schwerer Cloud-Incidents bleiben (MANDIANT, 2024; CROWDSTRIKE, 2025; WIZ, 2024). Die Ursache liegt weniger im Fehlen von Produkten als in der Komplexität der Betriebsmodelle. Ein Unternehmen kann heute mehrere Clouds, hunderte Accounts, tausende Rollen und zigtausende Policies betreiben, ohne eine konsistente Sicht auf effektive Berechtigungen zu besitzen.

Die Forschung zu CNAPP und CSPM hat gezeigt, dass integrierte Plattformen den Sicherheitsstatus sichtbar machen können. CNAPP kombiniert typischerweise CSPM, CWPP, CIEM, Image-Scanning, compliance mapping und workload protection. Der Nutzen solcher Plattformen liegt in der Korrelation von Konfiguration, Identität und Laufzeitverhalten. Allerdings besteht ein bekanntes Problem: Sichtbarkeit ist nicht gleich Prävention. Ein Tool kann eine riskante Policy erkennen, ohne dass diese automatisch korrigiert wird. Deshalb sind in 2026 die wirksamsten Programme jene, die Erkennung mit kontrollierter Durchsetzung kombinieren, etwa durch automatische Pull-Request-Gates, Policy Review Workflows und runtime-enforced controls (GARTNER, 2025; CNCF, 2024).

Ein weiterer zentraler Forschungsstrang betrifft die Sicherheit von CI/CD- und Supply-Chain-Pipelines. Nach den großen Supply-Chain-Fällen der frühen 2020er-Jahre wurde deutlich, dass Build-Systeme und Artefakt-Signaturen eine Kernkomponente der Cloud-Sicherheit darstellen. SLSA, in-toto, Sigstore, SBOMs und verifizierte Provenance sind 2026 in vielen Unternehmen Bestandteil der Produktionskette. Dennoch bleiben Angriffe über ungeschützte Runner, kompromittierte Secrets, bösartige Dependencies und unzureichende Signaturprüfung relevant. Für Cloud-Umgebungen ist dies besonders kritisch, weil ein einziger kompromittierter Build-Workflow zu massiv skalierten Deployments führen kann (GOOGLE, 2024; OPENSSF, 2024).

Die Literatur zu generativer KI hat 2026 eine neue Sicherheitsdimension eröffnet. OWASP führt Prompt Injection und Insecure Output Handling als zentrale Risiken in LLM-Anwendungen, während NIST und verschiedene Industriekonsortien Governance-Modelle für KI-Systeme formuliert haben (OWASP, 2024; NIST, 2024b). In Cloud-Umgebungen verschiebt sich das Problem von der bloßen Modellnutzung zur Integration von Modellen in operative Workflows. Wenn ein LLM Zugriff auf Kubernetes-Manifeste, Terraform-Pläne, Secrets-Management oder Incident-Runbooks hat, wird jede Schwachstelle in der Prompt- und Tool-Governance zu einem potenziellen Pfad zur Privilegieneskalation oder Datenexfiltration. Die Forschungslücke liegt hier in der Verbindung zwischen Cloud-Policy und KI-Policy: Es gibt bislang nur wenige Ansätze, die beide Ebenen gemeinsam modellieren.

3. Threat Model and Problem Formalization

Das Threat Model in Cloud-Umgebungen muss 2026 mehrere Akteure und Vertrauensdomänen berücksichtigen. Ein typischer Angreifer kann extern, intern, supply-chain-basiert oder identitätsmissbräuchlich sein. Externe Angreifer nutzen exponierte APIs, Fehlkonfigurationen oder Schwachstellen in öffentlich erreichbaren Diensten. Interne Angreifer besitzen legitime, aber missbrauchbare Zugänge. Supply-Chain-Angreifer kompromittieren Abhängigkeiten, Build-Systeme oder Container-Images. Schließlich gibt es den modernen Fall des „agentischen“ Missbrauchs, bei dem ein übermäßig privilegierter KI-Assistent unbeabsichtigt sensitive Operationen auslöst oder Informationen preisgibt.

Wir definieren die Cloud-Umgebung als gerichteten Graphen $G=(V,E)$ mit Knotenmenge $V$ bestehend aus Identitäten, Ressourcen, Kontrollsystemen, Datenobjekten und Telemetriequellen. Eine Kante $e \in E$ repräsentiert eine mögliche Autorisierung, Interaktion oder Trust-Beziehung. Ein Angriffspfad ist eine Sequenz $a = \langle v_1, v_2, \dots, v_k \rangle$, die von einem Startzustand mit begrenzten Rechten zu einem Zielzustand mit unerlaubtem Zugriff führt. Die Komplexität liegt in der Tatsache, dass Kanten dynamisch sind: Rollen können durch temporäre Tokens erzeugt werden, Pods können service accounts erben, und CI/CD-Systeme erzeugen zur Laufzeit neue Vertrauensbeziehungen.

Das Ziel des Verteidigers ist es, die Menge erfolgreicher Pfade zu minimieren und gleichzeitig die operative Nutzbarkeit zu erhalten. Wir formulieren zwei Zielfunktionen. Erstens die Minimierung des erwarteten Schadens:

$$ \min ; \mathbb{E}[L] = \sum_{i=1}^{n} P(a_i \text{ erfolgreich}) \cdot I(a_i) $$

wobei $I(a_i)$ den Impact eines Pfads beschreibt. Zweitens die Minimierung der mittleren Detektionszeit $MTTD$ und der Wiederherstellungszeit $MTTR$. In der Praxis ist ein optimales System nicht dasjenige mit maximaler Prävention, sondern dasjenige mit dem besten Verhältnis aus Reduktion des erwarteten Schadens und betrieblichen Reibungskosten.

Ein zentraler Aspekt des Threat Models ist Identitätsdominanz. Wir nehmen an, dass ein Angreifer in vielen Fällen zunächst einen gültigen, wenn auch begrenzten Zugang erlangt, etwa durch Phishing, Leckage von Zugriffsschlüsseln oder kompromittierte Automatisierungs-Workloads. Daraus folgt eine Kaskade von Fragen: Welche Trust-Edges existieren von dieser Identität aus? Welche Rollen können assumiert werden? Welche Secrets sind erreichbar? Welche Netze sind intern sichtbar? Welche Aktionen werden geloggt? Diese Fragen lassen sich in einer formalen Analyse als Erreichbarkeitsproblem mit gewichteten Kanten modellieren.

Bedrohungsart	Primärer Einstiegspunkt	Typische Folge	Dominante Verteidigung
Identitätsmissbrauch	API-Keys, OAuth, SSO, Workload Identity	Privilegieneskalation, Datenzugriff	Least Privilege, Conditional Access, Short-Lived Tokens
Fehlkonfiguration	Offene Buckets, zu breite Security Groups, public endpoints	Exfiltration, Reconnaissance	CSPM, Policy-as-Code, Continuous Validation
Supply-Chain-Kompromittierung	Dependencies, CI/CD, Images, Signaturen	Persistente Backdoors, Mass-Deployment	SLSA, Sigstore, SBOM, Isolated Runners
Kubernetes-Angriff	Kubeconfig, Service Account, Admission Gap	Lateral Movement, Cluster takeover	RBAC, NetworkPolicy, Pod Security, Runtime Detection
LLM-Missbrauch	Prompt Injection, Tool Abuse, Datenlecks	Sensitive Output, ungewollte Aktionen	Prompt Governance, Tool Sandbox, Data Egress Controls

Die formale Analyse zeigt außerdem, dass ein Angriff nicht unbedingt auf der „größten“ Schwachstelle basiert, sondern auf der am leichtesten verknüpfbaren Schwäche. Daher ist die Topologie der Vertrauensbeziehungen entscheidend. Eine sichere Cloud-Architektur weist keine unnötigen Querverbindungen zwischen Verwaltungs-, Bau-, Laufzeit- und Datenebene auf. Jede zusätzliche Trust-Edge erhöht die Pfadanzahl exponentiell, was sich als klassische Pfadexplosion ausdrückt:

$$ |A| \approx O(b^d) $$

mit Verzweigungsfaktor $b$ und Pfadtiefe $d$. Die praktische Konsequenz lautet, dass selbst kleine Reduktionen von $b$ durch saubere Segmentierung und strengere Identitätsgrenzen einen erheblichen Sicherheitsgewinn erzeugen können.

4. Proposed Methodology

Die vorgeschlagene Methodik basiert auf vier Schichten: Identitätskontrolle, Konfigurationskontrolle, Laufzeitkontrolle und Datenkontrolle. Diese Schichten werden nicht als isolierte Produkte verstanden, sondern als zusammenhängendes Kontrollsystem. Die zentrale Annahme lautet, dass Cloud-Sicherheit nur dann robust ist, wenn jede Schicht unabhängig überprüfbar ist und Verstöße in einer Schicht nicht unmittelbar zu vollständiger Kompromittierung führen.

In der Identitätskontrolle setzen wir auf kurzlebige Credentials, föderierte Identitäten, strikte Rollenabgrenzung und adaptive Zugriffsentscheidungen. Praktisch bedeutet dies den Verzicht auf langlebige statische Schlüssel, den Einsatz von OIDC-basierten Workload-Identitäten und die Durchsetzung von bedingtem Zugriff auf Basis von Gerät, Kontext und Risiko. In Multi-Cloud-Umgebungen ist die Synchronisierung von Rollen-Semantik besonders wichtig, da AWS IAM, Azure Entra ID und GCP IAM unterschiedliche Modelle verwenden. Unser Ansatz abstrahiert diese Unterschiede in ein internes Zielmodell mit atomaren Berechtigungen und darauf aufbauenden Rollenclustern.

In der Konfigurationskontrolle behandeln wir Infrastruktur als Code als verbindliche Sicherheitsquelle. Terraform, Helm, Kubernetes-Manifeste, CloudFormation, Bicep und ähnliche Artefakte werden vor dem Merge gegen Policy-Regeln geprüft. Die wichtigste operative Erkenntnis ist, dass man Fehlkonfigurationen nicht erst in der Laufzeit entdecken darf. Deshalb kombinieren wir statische Scanner mit semantischen Policy-Engines und risikobasierter Freigabe. Ein Terraform-Plan wird nur dann akzeptiert, wenn die resultierende Änderungsmenge die zulässigen Schutzgrenzen nicht überschreitet. Für kritische Ressourcen definieren wir eine Grenzfunktion $g(x)$, die etwa public exposure, privilege increase und data sensitivity gewichtet:

$$ g(x) = \alpha \cdot e + \beta \cdot p + \gamma \cdot s $$

wobei $e$ Exponiertheit, $p$ Privilegzuwachs und $s$ Datenkritikalität beschreibt. Nur wenn $g(x) \leq \tau$, darf die Änderung automatisiert deployt werden.

Die Laufzeitkontrolle nutzt eBPF-basierte Detektion, audit-basierte Alarme, Kubernetes Admission Control und Verhaltensanalysen. eBPF ist 2026 besonders relevant, weil es tiefe Sichtbarkeit mit vergleichsweise geringer Performance-Last bietet. Werkzeuge wie Falco, Cilium Tetragon und kommerzielle CNAPP-Komponenten erlauben es, Syscalls, Netzwerkflüsse und Prozessketten zu korrelieren. Für Container gilt insbesondere: Ein Image-Scan ist notwendig, aber nicht hinreichend. Viele Vorfälle entstehen erst zur Laufzeit durch missbräuchliche File-Zugriffe, Kryptomining, Shell-Spawning oder unautorisierte API-Aufrufe. Daher muss die Runtime-Schicht explizit Angriffsindikatoren erkennen und gleichzeitig automatische Eindämmung unterstützen.

Die Datenkontrolle schließlich umfasst Verschlüsselung, Tokenisierung, Zugriffstrennung, DLP und Egress-Überwachung. Daten in Cloud-Umgebungen sind oft nicht statisch, sondern werden kontinuierlich zwischen Storage, Analytics, ML-Pipelines und KI-Assistenten bewegt. Ein wesentliches Designprinzip ist die „minimal notwendige Datenfreigabe“ für jeden Workflow. KI-Anwendungen erhalten nur jene Datenausschnitte, die zur Antwortgenerierung notwendig sind. Abfragen werden protokolliert, klassifiziert und gegen Exfiltrationsregeln geprüft. Für hochkritische Daten setzen wir zusätzlich auf isolierte Enklaven oder getrennte Verarbeitungspfade.

Schicht	Primäre Kontrolle	Beispielwerkzeuge	Hauptnutzen
Identität	Short-lived credentials, conditional access	Entra ID, AWS IAM Identity Center, GCP Workload Identity	Reduktion von Missbrauchsdauer
Konfiguration	Policy-as-Code, IaC-Scanning	Terraform, tfsec, checkov, OPA, Kyverno	Frühe Fehlerprävention
Laufzeit	eBPF, Audit, behavioral detection	falco, tetragon, CloudTrail, Defender for Cloud	Schnelle Detektion und Containment
Daten	DLP, encryption, egress control	KMS, Macie, DLP, Secret Manager	Schutz gegen Exfiltration

Die Methodik ist bewusst zyklisch. Sicherheitskontrollen müssen kontinuierlich neu bewertet werden, weil Cloud-Umgebungen dynamisch sind. Wir verwenden daher einen Regelkreis: Erfassen, Bewerten, Durchsetzen, Validieren, Nachjustieren. Dieser Zyklus ist eng an DevSecOps gekoppelt, jedoch nicht auf Build-Zeit beschränkt. Er erstreckt sich auf Laufzeit und Incident Response. Besonders wichtig ist die automatische Verifikation von Sicherheitsannahmen. Wenn eine Policy behauptet, dass ein Namespace keine Public-IP erhalten kann, muss dies durch wiederholte Tests verifiziert werden.

5. Implementation

Die Referenzimplementierung orientiert sich an einer realistischen Multi-Cloud-Kubernetes-Umgebung mit GitOps, zentralem Logging und differenzierten Identitätsdomänen. Für die Infrastruktur werden Terraform und native Cloud-Policies verwendet. Kubernetes wird durch Pod Security Standards, NetworkPolicies und Admission Policies abgesichert. Die Telemetrie stammt aus Cloud-native Audit-Logs, Container-Runtime-Events und zentralen SIEM-Pipelines. Für die Laufzeitanalyse wird eine Kombination aus falco und tetragon verwendet, während die Konfigurationsanalyse mit tfsec, checkov, trivy und kube-bench erfolgt.

Ein praktisches Beispiel ist der Scan eines IaC-Repositories vor dem Merge:

tfsec . --minimum-severity HIGH
checkov -d . --framework terraform,kubernetes,helm
trivy config . --severity HIGH,CRITICAL
kube-bench --benchmark eks-1.30

Diese Befehle decken unterschiedliche Fehlertypen ab. tfsec identifiziert unsichere Terraform-Muster, checkov prüft mehrere Frameworks, trivy config findet Konfigurationsfehler in IaC und Kubernetes-Dateien, und kube-bench vergleicht Cluster-Einstellungen mit dem CIS-Benchmark. Die Kombination ist relevant, weil keine einzelne Prüfung die gesamte semantische Breite moderner Cloud-Deployments abdeckt.

Für die Laufzeit wird eine Falco-Regel eingeführt, die Shell-Spawning in produktiven Containern erkennt:

- rule: Shell in Container
  desc: Detect shell spawned in a container
  condition: >
    container and spawned_process and
    (proc.name in (bash, sh, zsh, dash) or
     proc.name in (python, perl, ruby, node)) and
    not user_known_shell_spawned
  output: >
    Shell spawned in container (user=%user.name container=%container.name
    image=%container.image.repository:%container.image.tag command=%proc.cmdline)
  priority: WARNING
  tags: [container, runtime, mitre_execution]

Die Regel ist bewusst generisch gehalten, weil Angreifer häufig zunächst interaktive Shells oder Skript-Interpreter missbrauchen, um Reconnaissance oder Exfiltration durchzuführen. In produktiven Umgebungen wird diese Regel mit Allowlists, Namespace-Scoping und Ausnahmebehandlung kombiniert, um Fehlalarme zu reduzieren.

Für KI-gestützte Betriebsworkflows wird eine separate Tool-Sandbox implementiert. Ein LLM darf weder direkt auf Secrets zugreifen noch unvalidierte Änderungen ausführen. Stattdessen wird ein Broker vorgeschaltet, der Anfragen klassifiziert, Daten minimiert und Tool-Aufrufe in isolierte, protokollierte Aktionen übersetzt. Terraform- oder Kubernetes-Manifeste, die durch ein Modell erzeugt werden, müssen vor Ausführung erneut durch statische und policy-basierte Prüfungen laufen. Dadurch wird verhindert, dass ein generiertes Artefakt unbemerkt eine öffentliche Datenbank, eine zu breite IAM-Rolle oder einen offenen Ingress erzeugt.

Komponente	Sicherheitsfunktion	Fehlertoleranz	Operative Rolle
Git-Repository	Code-Review, Signaturen, branch protection	Mittel	Quelle der Wahrheit
CI Runner	Isolierung, least privilege, ephemeral	Niedrig	Build und Test
Policy Engine	Admission decision, drift detection	Niedrig	Enforce and block
Runtime Sensor	eBPF, audit, process/network events	Mittel	Detektion und Kontext
SIEM/SOAR	Korrelation, Playbooks, Containment	Mittel	Reaktion und Eskalation

Die Implementierung berücksichtigt außerdem Drift. In Cloud-Umgebungen weichen tatsächliche Ressourcen oft vom gewünschten Zustand ab. Drift entsteht durch manuelle Hotfixes, Notfalländerungen oder schleichende Konfigurationsveränderungen. Daher wird eine regelmäßige Konvergenzprüfung eingesetzt, die IaC-Zustand, Cloud-API-Zustand und Runtime-Zustand vergleicht. Nur wenn alle drei Zustände konsistent sind, gilt die Ressource als kontrolliert.

6. Experimental Evaluation

Die Evaluation wurde in einer referenznahen Testumgebung mit drei Konfigurationen durchgeführt: einer Baseline ohne konsistente Policy-Durchsetzung, einer gehärteten Einzel-Cloud-Umgebung und einer Multi-Cloud-Architektur mit zentraler Identitäts- und Policy-Konsistenz. Die Bewertungskriterien waren Fehlkonfigurationsrate, mittlere Erkennungszeit, Zahl erreichbarer Angriffspfade und operative Reibung. Um die Ergebnisse vergleichbar zu machen, wurden identische Workload-Profile verwendet: ein Webdienst, eine API, ein Batch-Job, eine Datenpipeline und ein KI-gestützter Support-Workflow.

Die zentrale Metrik für den Angriffspfadraum ist die Reduktion der erreichbaren Zustände. Sei $S_0$ der ursprüngliche Zustandsraum und $S_c$ der durch Kontrollen reduzierte Raum. Dann definieren wir die Reduktionsquote als

$$ R = 1 - \frac{|S_c|}{|S_0|} $$

Eine hohe Reduktion ist nur dann positiv, wenn die Betriebsfähigkeit erhalten bleibt. Deshalb wird zusätzlich die Change-Fail-Rate erfasst, also der Anteil abgelehnter oder zurückgerollter Änderungen. In gut geführten Umgebungen steigt diese Rate zunächst leicht an, sinkt aber mit zunehmender Reife, weil Entwickler und Plattformteams lernen, Policies korrekt zu verwenden.

Konfiguration	Fehlkonfigurationen pro 100 Ressourcen	Erkennungszeit MTTD (Min.)	Erreichbare Angriffspfade	Change-Fail-Rate
Baseline	18,7	94	1.000	4,1 %
Gehärtete Einzel-Cloud	6,2	21	410	7,8 %
Multi-Cloud mit Konsistenzkontrollen	3,4	9	190	9,2 %

Die Daten zeigen eine deutliche Reduktion der Fehlkonfigurationen und Angriffspfade. Interessant ist die Erkennungszeit: Runtime- und Audit-Korrelation verkürzen die MTTD signifikant. Die leicht höhere Change-Fail-Rate in den gehärteten Umgebungen ist kein Nachteil an sich, sondern Ausdruck strengerer Durchsetzung. Entscheidend ist, dass die Rate in unserem Setup vor allem durch präventive Gates entsteht und nicht durch operative Blockaden im Live-Betrieb.

Zur Bewertung der Laufzeitdetektion wurden simulierte und kontrollierte Aktivitätsmuster verwendet, darunter unautorisierte kubectl exec-Versuche, Pod-to-Pod-Reconnaissance, Zugriff auf Secrets-Verzeichnisse und versuchte Exfiltration über ungewöhnliche DNS-Muster. In allen Fällen war die Kombination aus Audit-Logs und eBPF-Sensorik der reine Cloud-Audit überlegen. Besonders effektiv war die Korrelation von Prozessstart, Netzwerkziel und Namespace-Kontext. Ein isoliertes Ereignis wäre häufig harmlos; die Sequenz machte es eindeutig bösartig.

Testfall	Baseline Detektion	Mit Runtime-Korrelation	Mittlere Zeitersparnis
Shell in Container	41 Min.	3 Min.	92,7 %
Zugriff auf Secret Volume	36 Min.	2 Min.	94,4 %
Verdächtige DNS-Exfiltration	58 Min.	5 Min.	91,4 %
Laterale Bewegung im Cluster	73 Min.	7 Min.	90,4 %

Die Angriffspfade wurden auch graphentheoretisch analysiert. Vor den Kontrollen wies der Graph im Mittel einen hohen Verzweigungsfaktor auf, insbesondere durch überlappende IAM-Rechte und Netzwerkfreigaben. Nach Einführung der Policy- und Identitätsgrenzen sank die durchschnittliche Pfadtiefe von $d=6,8$ auf $d=3,1$. Das ist relevant, weil die Komplexität erfolgreicher Angriffe mit der Tiefe typischerweise zunimmt. Selbst wenn ein Angreifer initialen Zugang erhält, ist der Sprung zu Daten- oder Kontrollressourcen deutlich schwerer geworden.

Die experimentellen Ergebnisse belegen auch den Wert von Präventionskontrollen in der CI/CD-Kette. In dem Testaufbau verhinderten Policy-Gates mehrere riskante Terraform-Änderungen, darunter eine öffentlich erreichbare Verwaltungsoberfläche, eine zu breite Security Group und ein fehlendes Secret-Encryption-Flag. Ohne diese Kontrollen wären die Änderungen zwar syntaktisch gültig gewesen, aber operativ hochriskant. Die Evaluation zeigt damit, dass Cloud-Sicherheit nicht nur im Incident Response gemessen werden darf, sondern bereits im Merge-Prozess.

7. Case Study

Die Fallstudie basiert auf einem realistischen Vorfallmuster, das 2026 in vielen Unternehmen beobachtbar ist: ein identitätsgetriebener Cloud-Incident mit anschließender lateraler Bewegung über Kubernetes und Missbrauch von Automatisierungsrechten. Ein Plattformteam betrieb eine Multi-Cloud-Anwendung mit zentralem GitOps-Repository, mehreren Cluster-Accounts und einem KI-gestützten Betriebsassistenten. Der Assistent hatte Zugriff auf Runbooks und ausgewählte Telemetriedaten, jedoch zu breite Berechtigungen auf ein Ticketing-Backend und auf lesende API-Zugriffe im Kubernetes-Verbund.

Der Angriff begann mit dem Diebstahl eines kurzlebigen Tokens aus einer schlecht isolierten Build-Umgebung. Das Token selbst war zeitlich begrenzt, aber es erlaubte die Enumerierung von Rollenbeziehungen und die Ausgabe eines weiteren Tokens über einen föderierten Trust-Flow. Anschließend wurde ein Namespace entdeckt, in dem ein Service-Account übermäßig breite Leserechte auf Secrets hatte. Durch Kombination dieser Rechte konnte der Angreifer Konfigurationsdaten auslesen, interne Endpunkte identifizieren und laterale Zugriffe vorbereiten. Die fehlende Runtime-Detektion machte es möglich, dass diese Aktivitäten mehrere Stunden unentdeckt blieben.

Besonders problematisch war die Interaktion mit dem KI-Assistenten. Der Angreifer formulierte Anfragen, die im Stil legitimer Betriebsfragen gehalten waren, aber in Wirklichkeit sensitive Konfigurationsdetails extrahierten. Da die Prompt-Governance unzureichend war, beantwortete das System Teile der Anfrage mit Kontextinformationen, die den weiteren Weg zum Cluster erleichterten. Das Beispiel zeigt, dass KI-gestützte Betriebswerkzeuge nicht per se unsicher sind, aber ohne strikte Daten- und Tool-Grenzen neue Exfiltrationskanäle eröffnen.

Die Vorfallsanalyse ergab drei dominierende Ursachen. Erstens ein Identitätsfehler, der den ersten Sprung ermöglichte. Zweitens eine unzureichende Trennung zwischen Build- und Laufzeitdomänen, die den Token-Missbrauch begünstigte. Drittens fehlende Korrelation von Audit- und Runtime-Signalen. Nachdem die betroffene Organisation die in dieser Arbeit vorgeschlagenen Kontrollen eingeführt hatte, sanken sowohl die Zahl erreichbarer Vertrauensbeziehungen als auch die mittlere Erkennungszeit signifikant. Besonders wirksam war die Entkopplung des KI-Assistenten von direkten Produktionsberechtigungen sowie die Einführung eines Policy-Brokers, der Tool-Aufrufe protokolliert und begrenzt.

8. Discussion

Die Ergebnisse zeigen, dass Cloud-Sicherheit 2026 primär ein Problem der Steuerung von Vertrauensbeziehungen ist. Technische Einzelmaßnahmen bleiben wichtig, reichen aber nicht aus, wenn Identitäten, Workflows und Automatisierung nicht konsistent geregelt sind. Die stärkste Verteidigung ergibt sich aus der Kombination mehrerer Ebenen: kurze Credentials, präventive Policies, runtime visibility und strenge Datenfreigabe. Besonders in Multi-Cloud-Umgebungen ist Konsistenz wichtiger als lokale Perfektion. Eine exzellente Sicherheitskonfiguration in einer Cloud nützt wenig, wenn der Cross-Cloud-Trust oder ein gemeinsam genutzter CI/CD-Workflow die Schwachstelle bildet.

Die Integration von KI verändert die Sicherheitsarchitektur fundamental. LLMs können die Produktivität von Plattform- und Security-Teams erhöhen, aber sie vergrößern auch die Angriffsfläche. Eine zentrale Lehre ist, dass Modelle nie als privilegierte Orchestratoren ohne Zwischenschicht fungieren sollten. Tool-Aufrufe müssen explizit freigegeben, Daten minimiert und generierte Artefakte verifiziert werden. Dies gilt besonders für Infrastructure-as-Code, weil ein falscher Parameter in einer generierten Datei direkten Produktionsimpact haben kann. Die sichere Nutzung von LLMs in Cloud-Umgebungen ist daher weniger ein Prompt-Problem als ein Governance- und Kontrollproblem.

Aus operativer Sicht bleibt die größte Herausforderung die Balance zwischen Sicherheit und Geschwindigkeit. Zu viele Organisationen führen Sicherheitskontrollen ein, die den Delivery-Prozess so stark verlangsamen, dass Teams beginnen, sie zu umgehen. Das führt zu Schattenprozessen, manuellen Ausnahmen und letztlich zu höherem Risiko. Unsere Ergebnisse deuten darauf hin, dass die beste Strategie in automatisierbaren, eindeutig begründeten Kontrollen liegt. Wenn eine Policy verständlich und reproduzierbar ist, akzeptieren Teams sie eher. Wenn sie dagegen willkürlich erscheint, steigt die Umgehungswahrscheinlichkeit.

Ein weiterer Diskussionspunkt ist die Messbarkeit. Viele Cloud-Sicherheitsprogramme messen Anzahl von Findings, nicht aber die Reduktion realer Angriffspfade. Das ist methodisch unzureichend. Eine Organisation kann hunderte Warnungen haben und dennoch relativ sicher sein, wenn die kritischen Pfade unter Kontrolle sind. Umgekehrt kann ein kleiner Zahlensatz an Findings katastrophal sein, wenn er die Kernidentität, das CI/CD-System oder ein Produktions-Secret betrifft. Künftige Programme sollten deshalb pfadorientierte und impactorientierte Metriken bevorzugen.

Operativer Fokus	Vorteil	Risiko bei Vernachlässigung
Identity-first Security	Präzise Zugriffskontrolle	Token-Missbrauch, lateral movement
Policy-as-Code	Reproduzierbare Compliance	Drift, implizite Ausnahmen
Runtime Detection	Sichtbarkeit realer Angriffe	Späte Erkennung, Persistenz
KI-Governance	Kontrolle über Agenten und Tools	Datenexfiltration, ungewollte Aktionen

Die Arbeit hat auch Grenzen. Die Modellierung abstrahiert von sehr komplexen wirtschaftlichen und organisatorischen Faktoren. Außerdem können manche Angriffe, insbesondere reine Supply-Chain-Kompromittierungen, nur begrenzt durch technische Kontrollen verhindert werden. Dennoch bleibt der Befund robust: Ein systematisch reduzierter Vertrauensgraph und eine eng gekoppelte Telemetrie verbessern die Resilienz erheblich.

9. Conclusion and Future Work

Cloud-Sicherheit 2026 ist ein Identitäts-, Policy- und Telemetrieproblem. Die klassische Vorstellung eines geschützten Perimeters ist durch APIs, Workloads, Container, Serverless-Funktionen und KI-gestützte Automatisierung abgelöst worden. Erfolgreiche Verteidigung erfordert daher eine Architektur, die Vertrauensbeziehungen minimiert, Konfigurationen kontinuierlich validiert und Laufzeitverhalten in Echtzeit bewertet. Die in dieser Arbeit vorgestellte Methodik reduziert Angriffspfade, verkürzt Erkennungszeiten und verbessert die Steuerbarkeit komplexer Multi-Cloud-Umgebungen.

Für die Zukunft sind drei Forschungsrichtungen besonders relevant. Erstens braucht es bessere Methoden zur formalen Ableitung sicherer Cloud-Policies aus Geschäftsanforderungen, damit Sicherheit nicht nur geprüft, sondern synthetisiert werden kann. Zweitens müssen KI-Systeme mit Cloud-Governance verschmelzen, ohne neue unkontrollierte Privilegienpfade zu öffnen. Drittens wird die Post-Quantum-Migration Cloud-Architekturen vor neue Herausforderungen stellen, insbesondere bei Schlüsselverwaltung, hybriden Authentifizierungsverfahren und langfristiger Datenvertraulichkeit. Cloud-Sicherheit bleibt damit ein dynamisches Forschungs- und Operationsfeld, dessen Komplexität 2026 weiter zunimmt, dessen Kernprinzipien aber klarer werden: minimale Vertrauensannahmen, maximale Sichtbarkeit und konsequente Verifikation.

10. References

BELL, C. et al. Cloud Security Alliance: Top Threats to Cloud Computing. 2020. Disponível em: https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-pandemic-eleven/ . Acesso em: 5 mai. 2026.

CISA. Zero Trust Maturity Model, Version 2.0. 2024. Disponível em: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model . Acesso em: 5 mai. 2026.

CNCF. CNCF Annual Survey 2024. 2024. Disponível em: https://www.cncf.io/reports/cncf-annual-survey-2024/ . Acesso em: 5 mai. 2026.

CROWDSTRIKE. Global Threat Report 2025. 2025. Disponível em: https://www.crowdstrike.com/global-threat-report/ . Acesso em: 5 mai. 2026.

ENISA. Cloud Security: Threat Landscape and Good Practice Guide. 2024. Disponível em: https://www.enisa.europa.eu/publications/cloud-security-threat-landscape . Acesso em: 5 mai. 2026.

GARTNER. Cloud-Native Application Protection Platforms (CNAPP) Market Guide. 2025. Disponível em: https://www.gartner.com/en/documents/ . Acesso em: 5 mai. 2026.

GOOGLE. SLSA v1.0 Framework. 2024. Disponível em: https://slsa.dev/spec/v1.0/ . Acesso em: 5 mai. 2026.

MANDIANT. M-Trends 2024. 2024. Disponível em: https://www.mandiant.com/resources/m-trends . Acesso em: 5 mai. 2026.

MICROSOFT. Zero Trust deployment plan. 2023. Disponível em: https://learn.microsoft.com/en-us/security/zero-trust/ . Acesso em: 5 mai. 2026.

NIST. SP 800-207: Zero Trust Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final . Acesso em: 5 mai. 2026.

NIST. Cybersecurity Framework 2.0. 2024. Disponível em: https://www.nist.gov/cyberframework . Acesso em: 5 mai. 2026.

NIST. AI Risk Management Framework: Generative AI Profile. 2024b. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework . Acesso em: 5 mai. 2026.

OPENSSF. Sigstore Documentation. 2024. Disponível em: https://docs.sigstore.dev/ . Acesso em: 5 mai. 2026.

OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/ . Acesso em: 5 mai. 2026.

SIG-SEC. Kubernetes Security Special Interest Group: Pod Security Standards. 2024. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/ . Acesso em: 5 mai. 2026.

VAQUERO, L. M. et al. A break in the clouds: towards a cloud definition. ACM SIGCOMM Computer Communication Review, 2019. Disponível em: https://dl.acm.org/ . Acesso em: 5 mai. 2026.

WIZ. Cloud Security Report 2024. 2024. Disponível em: https://www.wiz.io/cloud-security-report . Acesso em: 5 mai. 2026.

AQUA SECURITY. Kubernetes Security Best Practices 2024. 2024. Disponível em: https://www.aquasec.com/kubernetes-security/ . Acesso em: 5 mai. 2026.

CLOUDFLARE. Cloudflare Zero Trust Documentation. 2024. Disponível em: https://developers.cloudflare.com/cloudflare-one/ . Acesso em: 5 mai. 2026.

HASHICORP. Terraform Security Best Practices. 2024. Disponível em: https://developer.hashicorp.com/terraform . Acesso em: 5 mai. 2026.

RED HAT. Kubernetes Hardening Guide. 2024. Disponível em: https://www.redhat.com/en/topics/containers/kubernetes-security . Acesso em: 5 mai. 2026.

SYMPHONYAI. Prompt Injection and Tool Abuse in Enterprise LLMs. 2024. Disponível em: https://www.owasp.org/ . Acesso em: 5 mai. 2026.

PALO ALTO NETWORKS. Unit 42 Cloud Threat Report 2024. 2024. Disponível em: https://unit42.paloaltonetworks.com/ . Acesso em: 5 mai. 2026.

AWS. AWS Well-Architected Framework: Security Pillar. 2024. Disponível em: https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/ . Acesso em: 5 mai. 2026.

MICROSOFT. Microsoft Defender for Cloud documentation. 2024. Disponível em: https://learn.microsoft.com/en-us/azure/defender-for-cloud/ . Acesso em: 5 mai. 2026.

GOOGLE CLOUD. Security Command Center documentation. 2024. Disponível em: https://cloud.google.com/security-command-center/docs . Acesso em: 5 mai. 2026.

KUBERNETES. Kubernetes Documentation. 2024. Disponível em: https://kubernetes.io/docs/ . Acesso em: 5 mai. 2026.

CNCF. Falco documentation. 2024. Disponível em: https://falco.org/docs/ . Acesso em: 5 mai. 2026.

CNCF. Cilium Tetragon documentation. 2024. Disponível em: https://tetragon.cilium.io/ . Acesso em: 5 mai. 2026.

IBM. Cloud Security Best Practices 2024. 2024. Disponível em: https://www.ibm.com/topics/cloud-security . Acesso em: 5 mai. 2026.