Cloud-Sicherheitsarchitektur 2026: Angriffsflächen, Zero-Trust-Implementierung und messbare Abwehrwirkung in Multi-Cloud- und AI-nativen Umgebungen

1. Introduction

Die Cloud ist 2026 nicht mehr nur ein Betriebsmodell, sondern ein sicherheitsrelevantes Ökosystem aus Identitätsdiensten, Policy-Engines, containerisierten Workloads, verwalteten Datenbanken, serverlosen Funktionen, SaaS-Integrationen und zunehmend KI-nativen Komponenten. Diese Entwicklung hat die klassische Vorstellung von „Netzwerkgrenze“ weitgehend obsolet gemacht, weil Angriffe heute häufig über Identitäten, API-Zugriffe, CI/CD-Pipelines und Fehlkonfigurationen erfolgen und nicht mehr primär über offene Ports oder perimeternahe Exploits. Die Sicherheitsfrage lautet daher nicht mehr, ob ein Cloud-Stack „abgesichert“ ist, sondern wie belastbar die kontinuierliche Kontrolle von Konfiguration, Berechtigung, Laufzeit und Datenfluss tatsächlich funktioniert. In der Praxis ist genau diese kontinuierliche Kontrolle die zentrale Schwachstelle vieler Organisationen, weil Cloud-Umgebungen sich schneller verändern, als Governance- und Prüfprozesse nachziehen können.

Der Begriff „Cloud“ umfasst dabei 2026 mindestens drei unterschiedliche, aber eng gekoppelte Ebenen. Erstens die Infrastruktur- und Plattformebene mit IaaS, PaaS und containerisierten Runtime-Umgebungen. Zweitens die Kontroll- und Verwaltungs-Ebene mit IAM, Org Policies, Security Posture Management, Logging, Schlüsseldiensten und Automation. Drittens die Anwendungs- und Datenebene mit SaaS-Integrationen, APIs, Event-Streams, Data Lakes, ML-Pipelines und LLM-basierten Diensten. Die Mehrzahl relevanter Sicherheitsvorfälle nutzt heute Übergänge zwischen diesen Ebenen aus. Ein typisches Szenario ist die Kompromittierung einer Entwickleridentität, gefolgt von Missbrauch von CI/CD-Geheimnissen, anschließender Token-Exfiltration und lateralem Zugriff auf Cloud-Ressourcen. Ein anderes Muster ist die Fehlkonfiguration von Speicherzugriffen oder Rollenbindungen, die zu Datenabfluss führt, ohne dass ein klassischer Exploit erforderlich wäre.

Diese Arbeit behandelt Cloud-Sicherheit deshalb als ein Zusammenspiel aus Prävention, Detektion, Reaktion und Verifikation. Prävention bedeutet hier nicht nur Härtung, sondern vor allem die Reduktion der erreichbaren Angriffsoberfläche durch minimale Rechte, segmentierte Trust-Zonen und policy-gestützte Provisionierung. Detektion erfordert Telemetrie, die nicht nur Netzwerkdaten, sondern auch Control-Plane-Aktionen, Identitätsereignisse, Container- und Syscall-Verhalten sowie Veränderung an Policies erfasst. Reaktion umfasst automatisierte Isolation, Schlüsselrotation, Token-Revocation und forensisch belastbare Artefakt-Erhaltung. Verifikation wiederum ist die Fähigkeit, Sicherheitszustände kontinuierlich gegen intendierte Policies und regulatorische Anforderungen zu prüfen, beispielsweise mithilfe von Policy-as-Code, Konfigurationsscans und drift detection.

Besondere Bedeutung erhält 2026 die Integration von KI-Workloads in Cloud-Umgebungen. LLM-basierte Anwendungen erzeugen neue Bedrohungen wie Prompt Injection, Datenexfiltration über Tool-Interfaces, unsichere Retrieval-Pipelines und unkontrollierte Weitergabe sensibler Kontexte an externe Modelle. Gleichzeitig verschärfen generative Systeme das Social-Engineering-Risiko, da Angriffe auf Cloud-Administratoren, DevOps-Teams und FinOps-Prozesse hochgradig personalisiert und sprachlich fehlerfrei erstellt werden können. Cloud-Sicherheit muss daher nicht nur klassische Workloads, sondern auch AI Governance und Modellzugriffe einbeziehen. Das verändert die Prioritäten: Nicht die Existenz einzelner Schwachstellen ist entscheidend, sondern die Frage, ob eine Organisation die Kopplung von Identität, Konfiguration, Daten und Modellzugriff in Echtzeit beherrscht.

Der methodische Beitrag dieser Arbeit besteht in der Verbindung einer formalen Bedrohungsmodellierung mit einer umsetzbaren Kontrollarchitektur. Wir zeigen, wie sich typische Cloud-Angriffsvektoren operational in Angriffsphasen abbilden lassen und welche Kombination aus technischen und organisatorischen Kontrollen ihre Erfolgswahrscheinlichkeit senkt. Dabei wird ausdrücklich die Praxis 2026 berücksichtigt: Zero Trust ist kein Schlagwort mehr, sondern ein ausgereiftes Architekturprinzip; CNAPP und CSPM sind etablierte Kategorien; eBPF-basierte Laufzeitkontrollen sind produktionsreif; und post-quantensichere Migration ist ein reales Planungsproblem für Schlüsselmanagement und langfristig vertrauliche Daten. Diese Arbeit positioniert Cloud-Sicherheit daher als ein messbares, ingenieurwissenschaftliches Problem und nicht als Sammlung isolierter Produkte oder Best Practices.

2. Background and Related Work

Die wissenschaftliche und industrielle Literatur zu Cloud-Sicherheit ist bis 2026 breit, aber in ihrer praktischen Umsetzbarkeit häufig fragmentiert. Frühe Arbeiten fokussierten vor allem Virtualisierung, Multi-Tenancy-Risiken und Isolation zwischen VMs. Mit der Verlagerung auf Container, Kubernetes und Managed Services verlagerte sich der Fokus zu Orchestrierung, Supply Chain, Secrets Management und Identity Federation. In den letzten Jahren rückte dann die übergreifende Sicherheitslage von Cloud-Posture, DevSecOps und Cloud-Native Application Protection Platforms in den Mittelpunkt. Parallel dazu entstanden neue Angriffsflächen durch SaaS-Ökosysteme, Workload-Identitäten und automatisierte Integrationen zwischen Cloud-Diensten. Der Stand 2026 ist deshalb nicht durch eine einzelne Technik, sondern durch die Konvergenz vieler Teilgebiete geprägt.

Ein zentraler Strang der Literatur behandelt Shared Responsibility Models und deren operationales Versagen in der Praxis. Organisationen interpretieren diese Modelle oft zu grob und nehmen an, der Cloud-Anbieter sichere „die Cloud“, während sie selbst nur Applikationen verwalten müssten. Tatsächlich ist die Sicherheitsverantwortung stark abhängig vom Servicemodell. Bei IaaS verbleiben Härtung, Patch-Management und Netzwerkdesign weitgehend beim Kunden, während bei PaaS und SaaS vor allem Identität, Datenklassifikation, Integrationen und Governance kontrolliert werden müssen. Studien und Post-Mortems zeigen regelmäßig, dass Vorfälle aus Konfigurationsfehlern entstehen, nicht aus Infrastrukturkompromittierungen beim Provider. Die Literatur des Cloud Security Alliance, NIST und ENISA hat diese Trennung klar beschrieben, doch viele Umsetzungen bleiben unvollständig (NIST, 2020; CSA, 2024; ENISA, 2023).

Ein weiterer Schwerpunkt ist die Sicherheit von Kubernetes und containerisierten Umgebungen. Hier hat sich gezeigt, dass Clusterkompromittierung häufig über API-Zugriffe, falsch konfigurierte RBAC-Rollen, exponierte Dashboards, unsichere Admission-Policies oder ausnutzbare Images erfolgt. Die Forschung und Praxisberichte von Kubernetes-Härtungsprojekten wie kube-bench, Falco, Aqua und Sysdig haben die Bedeutung von Pod Security Standards, NetworkPolicies und Runtime Detection hervorgehoben. Bis 2026 ist insbesondere die Kombination aus kontrollierter Image-Herkunft, signierten Artefakten, minimalen Rollen und eBPF-gestützter Laufzeitüberwachung als wirksames Muster etabliert. Die Literatur zeigt jedoch auch, dass viele Organisationen zwar Scans durchführen, aber Drift, Ausnahmegenehmigungen und produktive Workarounds nicht konsequent schließen.

Parallel dazu hat sich die Sicherheitsforschung zur Cloud-Supply-Chain stark ausgeweitet. Der Fokus liegt auf CI/CD-Pipelines, Artefaktvertrauen, Abhängigkeitsmanagement, SBOMs und Signaturen. Die Angriffsserie auf Software-Lieferketten der Jahre 2020 bis 2025 hat gezeigt, dass der Erstzugang oft über Build-Systeme, Token oder kompromittierte Entwicklerumgebungen erfolgt. Deshalb wurden Frameworks wie SLSA, Sigstore und in-toto in der Praxis relevant, weil sie Provenienz und Integrität über den gesamten Build- und Deploy-Prozess hinweg adressieren. Zugleich bleibt das Problem bestehen, dass Signaturen nur so stark sind wie die Schlüsselverwaltung und die Vertrauensanker, auf denen sie beruhen. Die Forschung der letzten Jahre hat deshalb zunehmend auf „verifiable delivery“ und kontinuierliche Attestierung gesetzt.

Die Sicherheitslage von Identitäten ist in der Cloud-Forschung ebenfalls zentral. Im Unterschied zu klassischen Netzwerken ist Identität das eigentliche Perimeter. IAM-Fehlkonfigurationen, überprivilegierte Rollen, unkontrollierte Service Principals und unzureichend geschützte Zugriffstokens sind häufigere Erfolgsfaktoren als technische Exploits. Dies gilt sowohl für AWS IAM und Organizations als auch für Azure Entra ID und Google Cloud IAM. Der Missbrauch von STS-Tokens, OAuth-Apps, Workload Identity Federation und temporären Credentials hat die Angriffsökonomie grundlegend verändert. Die Literatur belegt, dass kurze Lebensdauern allein nicht genügen, wenn Token exfiltriert und automatisiert genutzt werden können. Daher betonen moderne Ansätze Conditional Access, device posture, just-in-time privilege elevation und Token-Bindung an Kontextsignale.

Ein zusätzlicher 2026-relevanter Forschungsstrang betrifft AI Security und LLM-Governance. Während frühe Arbeiten vor allem adversariale Beispiele und Model Inversion analysierten, liegt der operative Schwerpunkt inzwischen auf Prompt Injection, Datenabfluss über RAG-Systeme, unzureichend kontrollierten Tool-Aufrufen, Modell- und Agentenmissbrauch sowie Policy-Umgehung durch sprachliche Manipulation. Cloud-Umgebungen sind davon besonders betroffen, weil LLM-Dienste oft direkt an Speicher, Vektor-Datenbanken, Ticket-Systeme, Code-Repositorys und ChatOps angebunden werden. Damit entstehen neue Datenpfade, die klassische Cloud-Sicherheitskontrollen nicht automatisch erfassen. Die einschlägigen Empfehlungen von NIST, OWASP und CSA betonen daher Zugriffsminimierung, Content Isolation, sichere Tool-Orchestrierung und umfassende Auditierbarkeit.

Die historische Entwicklung der Cloud-Sicherheitsstandards zeigt eine Verschiebung von Compliance zu operativer Wirksamkeit. ISO/IEC 27017 und 27018 liefern Orientierung, aber keine runtime-nahen Steuerungsmechanismen. NIST SP 800-53 und 800-207 formalisierten Kontroll- und Zero-Trust-Prinzipien, müssen jedoch durch konkrete Automatisierung ergänzt werden. ENISA und CISA publizierten Cloud- und Identity-Härtungsleitfäden, die in vielen reifen Programmen als Referenz dienen. In der Praxis ist die Herausforderung aber nicht Wissensmangel, sondern Umsetzungsdisziplin unter hoher Änderungsrate. Genau hier setzt die vorliegende Arbeit an: Sie verbindet die Literatur mit einer umsetzbaren Architektur und bewertet deren Wirkung anhand realistischer Metriken.

3. Threat Model and Problem Formalization

Das Bedrohungsmodell dieser Arbeit betrachtet eine Organisation, die mindestens eine Multi-Cloud-Umgebung mit IaaS-, PaaS- und Kubernetes-Komponenten betreibt und zusätzlich SaaS- sowie KI-Dienste integriert. Der Angreifer kann extern, intern oder als Lieferkettenakteur auftreten. Externe Angreifer nutzen öffentlich erreichbare Verwaltungsoberflächen, gestohlene Zugangsdaten, Phishing, Session Hijacking oder Fehlkonfigurationen. Interne Angreifer verfügen über legitime, aber missbrauchbare Zugänge. Lieferkettenakteure umfassen kompromittierte Repositories, Build-Agenten, Paketabhängigkeiten oder Managed-Service-Integrationen. Für alle Angreifer gilt, dass ihr Ziel nicht zwingend die vollständige Infrastrukturkontrolle ist, sondern häufig der stillschweigende Zugriff auf Daten, Schlüssel, Modelle oder Persistenzmechanismen.

Wir modellieren den Sicherheitszustand einer Cloud-Umgebung als Menge $$S = {I, C, D, R, L}$$, wobei $I$ für Identitäten und Rechte, $C$ für Konfigurationen und Policies, $D$ für Datenobjekte und Datenpfade, $R$ für Runtime- und Laufzeitumgebungen sowie $L$ für Logging- und Telemetriesysteme steht. Ein Vorfall tritt dann ein, wenn ein Angreifer eine Kette von Zustandsübergängen erzeugt, die zu unautorisiertem Zugriff, Persistenz, Exfiltration oder Sabotage führt. Formal kann der Eintrittswahrscheinlichkeitsschätzer als Funktion geschrieben werden: $$P(\text{Incident}) = f(P_I, P_C, P_D, P_R, P_L, A, T)$$ wobei $P_I$ bis $P_L$ die jeweiligen Schwachstellen- und Kontrollversagenswahrscheinlichkeiten darstellen, $A$ die Angreiferfähigkeiten und $T$ die Zeit bis zur Detektion und Eindämmung repräsentiert. Je größer $T$ ist, desto höher wird die erwartete Schadensfläche, weil Cloud-Angriffe häufig seitwärts und schrittweise eskalieren.

Die Kernprobleme lassen sich in fünf Klassen einteilen. Erstens Identitätsmissbrauch, etwa durch Phishing, Token-Diebstahl, überprivilegierte Rollen oder ungesicherte föderierte Trust-Beziehungen. Zweitens Fehlkonfiguration, etwa offene Storage-Buckets, zu breite Security Groups, ungeschützte Management-APIs oder fehlerhafte Kubernetes-RBAC. Drittens Supply-Chain-Kompromittierung, zum Beispiel manipulierter Build-Output, kompromittierte Abhängigkeiten oder unsichere GitHub Actions. Viertens Laufzeitmissbrauch, beispielsweise Container-Escape, Misuse privilegierter Pods, eBPF-Umgehung oder Ausnutzung von Serverless-Umgebungen. Fünftens Daten- und KI-Missbrauch, etwa prompt injection, RAG-Leaks, unkontrollierte Tool-Nutzung und Schatten-API-Zugriffe.

Bedrohungsklasse	Typische Eintrittspunkte	Primäre Ziele	Häufige Kontrollversäumnisse
Identitätsmissbrauch	Phishing, OAuth, STS, API Keys	Persistenz, Privilegien, Datenzugriff	MFA-Lücken, überbreite Rollen, fehlende Kontextbindung
Fehlkonfiguration	Storage, Security Groups, IAM, K8s RBAC	Datenexfiltration, Exposure, laterale Bewegung	Drift, manuelle Ausnahmen, mangelnde Validierung
Supply Chain	CI/CD, Build-Agent, Dependencies, Artefakte	Code-Injektion, Backdoors, Datenfluss-Manipulation	Fehlende Signaturen, schwache Provenienz, Token-Hygiene
Laufzeitmissbrauch	Container, Serverless, Managed Nodes	Privilege Escalation, Persistenz, Netzwerkpivot	Fehlende Runtime-Detection, zu hohe Rechte, fehlende Segmentierung
Daten- und KI-Missbrauch	RAG, Agents, APIs, SaaS-Integrationen	Exfiltration, Manipulation, Policy-Umgehung	Unkontrollierte Toolzugriffe, fehlende Content Isolation

Die Formalisierung muss auch den Effekt von Kontrollen berücksichtigen. Wir definieren eine Kontrollfunktion $g$ mit $g \in [0,1]$, wobei $g=1$ vollständige Wirksamkeit und $g=0$ völliges Versagen bedeutet. Der Rest-Risikoindex ergibt sich dann näherungsweise als $$R_{res} = R_0 \cdot \prod_{i=1}^{n}(1-g_i)$$ wobei $R_0$ das Basisrisiko ohne Kontrollen ist. Diese Multiplikativität ist wichtig, weil Cloud-Kontrollen nicht additiv wirken. Wenn Identitätskontrollen versagen, können technische Härtungen wertlos werden; wenn Logging fehlt, ist Detektion trotz guter Prävention eingeschränkt; wenn Runtime-Controls fehlen, ist ein erfolgreicher Initialzugriff schwerer einzudämmen. Daher muss die Sicherheitsarchitektur mehrere, sich überlappende Ebenen aufweisen.

4. Proposed Methodology

Die vorgeschlagene Methodik ist als Cloud Security Assurance Loop strukturiert und verbindet Prävention, Verifikation, Detektion und Reaktion in einem kontinuierlichen Zyklus. Der zentrale Gedanke ist, dass in Cloud-Umgebungen keine einmalige Härtung ausreicht. Stattdessen müssen Konfiguration, Berechtigung, Laufzeit und Datenpfade kontinuierlich gegen beabsichtigte Sicherheitszustände geprüft werden. Die Methode besteht aus sechs Bausteinen: Identity-Centric Access Control, Policy-as-Code, Cloud-Native Posture Management, Runtime Telemetry, Supply-Chain Attestation und Incident Automation. Diese Bausteine werden so verknüpft, dass jedes Kontrollversagen durch andere Ebenen zumindest teilweise kompensiert werden kann.

Die erste Säule ist Identity-Centric Access Control. Hier werden menschliche und maschinelle Identitäten gleichermaßen als hochkritische Sicherheitsobjekte behandelt. Für Menschen werden starke MFA, Gerätebindung, conditional access, just-in-time elevation und administrative Trennung verlangt. Für Workloads werden kurzlebige, gebundene und kontextabhängige Token, Workload Identity Federation und minimale Rollen verwendet. Lang lebige API Keys gelten nur als Ausnahme und müssen mit strengem Secrets Management, Rotation und Überwachung versehen sein. Entscheidend ist, dass Identität nicht nur zur Authentisierung dient, sondern auch als Steuerungsparameter für Autorisierung, Netzwerkrouting und Datenzugriff.

Die zweite Säule ist Policy-as-Code. Sicherheitsanforderungen werden in maschinenlesbare Richtlinien übersetzt und in den Provisionierungs- und Deploy-Prozess integriert. Open Policy Agent, HashiCorp Sentinel und cloud-native Policy Engines können genutzt werden, um Ressourcenanfragen zu blockieren, wenn sie gegen Härtungsregeln verstoßen. Beispiele sind: keine öffentlichen Buckets, keine Administratorrollen ohne Begründung, keine unverschlüsselten Volumes, keine unsicheren Kubernetes-Deployments, keine ungeprüften externen Images. Damit werden Sicherheitsentscheidungen reproduzierbar und auditierbar. Zugleich können Ausnahmen versioniert und zeitlich befristet werden, was den üblichen Wildwuchs manueller Sonderfreigaben reduziert.

Die dritte Säule ist Cloud-Native Posture Management. Dazu gehören CSPM, CIEM, KSPM und CNAPP als integrierte Kontrolle über Konfiguration, Identitäten, Kubernetes und Workloads. Diese Systeme sollen jedoch nicht isoliert als Report-Tools verstanden werden, sondern als Quellen für automatische Durchsetzung. Im Reifegradmodell der Arbeit ist ein Posture-Problem erst dann behoben, wenn es nicht nur gemeldet, sondern durch IaC-Änderung, Policy-Härtung oder Ressourcen-Neuprovisionierung nachhaltig beseitigt wurde. Die Abbildung von Fehlkonfigurationen auf konkrete Remediation Playbooks ist daher essenziell.

Die vierte Säule ist Runtime Telemetry. Hier werden eBPF-basierte Sensorik, Syscall- und Prozessbeobachtung, Kubernetes-Audit-Logs, CloudTrail- und Control-Plane-Events, NetFlow-ähnliche Telemetrie und SaaS-Audit-Streams kombiniert. Ziel ist die Erkennung von Anomalien wie unerwarteten Reverse Shells, Credential-Dumping-Verhalten, verdächtigen API-Aufrufen, lateralem Zugriff oder exfiltrationsähnlichen Muster. Wichtig ist die Korrelation auf mehreren Ebenen. Ein einzelnes Signal ist oft nicht ausreichend; erst die Kombination von Identitätswechsel, ungewöhnlicher Ressourcenanfrage und Runtime-Aktivität erzeugt belastbare Detektionsqualität.

Die fünfte Säule ist Supply-Chain Attestation. Jedes Artefakt, das in Cloud-Umgebungen ausgerollt wird, benötigt Herkunftsnachweis, Integritätsbeweis und möglichst reproduzierbare Erzeugung. Sigstore, SLSA-konforme Build-Pipelines, SBOMs und signierte Container-Images bilden hier die technische Basis. Die Methodik verlangt außerdem, dass Deployments nur aus vertrauenswürdigen Registry-Quellen und mit gültigen Signaturen akzeptiert werden. Zusätzlich werden Build-Identitäten, Secrets und Runner isoliert, damit die Pipeline selbst nicht zum Angriffsvektor wird.

Die sechste Säule ist Incident Automation. Reaktionsmechanismen müssen so gestaltet sein, dass bei Erkennung eines Vorfalls Tokens sofort widerrufen, Rollen temporär gesperrt, betroffene Workloads isoliert und forensische Daten gesichert werden können. Automatisierte Response ist nur dann sinnvoll, wenn sie reversible und abgestufte Maßnahmen erlaubt. Ein zu aggressives Auto-Remediation kann Produktionsausfälle verursachen; ein zu zögerliches erhöht die Schadensausbreitung. Deshalb wird ein Schweregradmodell eingesetzt, das Handlungen nach Vertrauensstufe und potenzieller Auswirkung ordnet.

Kontrollsäule	Beispielwerkzeuge	Primärer Nutzen	Typische Grenzen
Identity-Centric Control	Entra ID, AWS IAM, Okta, PAM	Verhindert Missbrauch legitimer Zugänge	Abhängigkeit von MFA- und Token-Schutz
Policy-as-Code	OPA, Sentinel, Kyverno	Verhindert Fehlkonfiguration bei Provisionierung	Komplexität und Pflegeaufwand
Posture Management	Wiz, Prisma Cloud, Defender for Cloud	Findet Drift und Exposure	Risiko von Alarmmüdigkeit, fehlende Remediation
Runtime Telemetry	Falco, Cilium Tetragon, CloudTrail, eBPF	Erkennt Laufzeitangriffe und Anomalien	Sichtbarkeitslücken in Managed Services
Supply-Chain Attestation	Sigstore, SLSA, in-toto, Trivy	Sichert Artefaktintegrität und Herkunft	Schlüssel- und Vertrauensankerproblem
Incident Automation	SOAR, Lambda, Azure Functions, Terraform	Schnelle Eindämmung und Rotation	Falsche Positives und Betriebsrisiken

5. Implementation

Die Implementierung wird als Referenzarchitektur für eine Organisation mit AWS-, Azure- und Kubernetes-Umgebungen beschrieben. Die Architektur ist bewusst providerübergreifend, weil 2026 die Mehrheit reifer Unternehmen nicht monokulturell arbeitet. Sie kombiniert zentrale Governance mit lokalen Provider-spezifischen Kontrollen. Die Implementierung basiert auf Infrastructure as Code, zentralen Policy-Repositories, Telemetrie-Korrelation und einem abgestuften Reaktionspfad. Dadurch wird die Sicherheitslage nicht manuell, sondern deklarativ verwaltet.

Ein zentrales Element ist die Nutzung von Terraform für die Provisionierung und von OPA/Kyverno für policy-getriebene Freigaben. Sicherheitsrelevante Ressourcen wie S3-Buckets, IAM-Rollen, Security Groups, Azure Storage Accounts, Key Vaults und Kubernetes-Deployments werden nur noch über geprüfte Module erlaubt. Jede Änderung erzeugt einen Review- und Validierungspfad, der sowohl syntaktische als auch semantische Prüfungen umfasst. Für Kubernetes werden Pod Security Standards, NetworkPolicies, read-only root filesystems, drop capabilities und minimal privilege ServiceAccounts vorausgesetzt. Für AWS und Azure werden identitätsbasierte Zugriffe bevorzugt, während statische Zugangsdaten auf ein Minimum reduziert werden.

Ein zweites Element ist die Telemetrie-Infrastruktur. CloudTrail, AWS Config, Azure Activity Logs, Entra ID Sign-in Logs und Kubernetes Audit Logs werden in ein zentrales SIEM geleitet. Ergänzt wird dies durch Runtime-Events aus Falco oder Cilium Tetragon sowie Host- und Container-Metriken. Die Korrelation erfolgt anhand einer einheitlichen Ereignisstruktur mit Zeitstempel, Identität, Ressource, Aktion, Kontext und Vertrauenswert. Diese normalisierte Sicht ist notwendig, weil Cloud-Logs ansonsten fragmentiert und nur schwer korrelierbar sind. Besonders wichtig ist die Speicherung in einem manipulationsresistenten Archiv, damit forensische Nachverfolgung möglich bleibt.

Ein drittes Element ist die Automatisierung der Response. Wenn etwa eine verdächtige Identität in einem Management-Account ungewöhnliche CreateRole- oder PassRole-Aktionen durchführt, wird nicht nur alarmiert, sondern auch die Session beendet, die betroffene Rolle gesperrt und eine forensische Kopie relevanter Logs erzeugt. Für Kubernetes können kompromittierte Pods isoliert, Deployments skaliert oder Namespaces gesperrt werden. Entscheidend ist die Vorabdefinition von Reaktionspfaden, damit im Ernstfall nicht improvisiert werden muss. Die Automatisierung darf jedoch nie blind sein; deshalb ist eine Genehmigungsstufe für irreversible Maßnahmen vorgesehen.

# AWS-CloudTrail- und Config-basierte Baseline-Analyse mit Prowler
git clone https://github.com/prowler-cloud/prowler.git
cd prowler
python3 -m pip install -r requirements.txt
python3 prowler.py aws --profile prod-security --services iam s3 ec2 eks kms cloudtrail --output-formats html json csv

# Trivy zur Container- und IaC-Prüfung
trivy config ./terraform/
trivy image --severity HIGH,CRITICAL ghcr.io/org/app:1.4.2
trivy fs --scanners vuln,misconfig,secret ./repo/

Die Implementierung berücksichtigt auch AI-native Komponenten. LLM-gestützte Anwendungen werden nur über streng kontrollierte Tool-Interfaces angebunden. Prompt- und Kontextdaten werden klassifiziert, sensibel markiert und bei Bedarf pseudonymisiert. Retrieval-Systeme erhalten getrennte Zugriffsschichten, und externe Modellaufrufe werden auf Datenminimierung und Protokollierbarkeit geprüft. Besonders wichtig ist die Verhinderung von unkontrollierter Tool-Exekution durch Agenten. Jeder Tool-Aufruf benötigt eine explizite Policy, die Datentypen, erlaubte Ziele und Ausgabebegrenzungen festlegt. Dadurch werden Prompt Injection und Tool Abuse nicht vollständig eliminiert, aber deutlich eingeschränkt.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-secure-pods
spec:
  validationFailureAction: Enforce
  rules:
    - name: disallow-privileged
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Privilegierte Pods sind nicht erlaubt."
        pattern:
          spec:
            =(hostNetwork): false
            =(hostPID): false
            containers:
              - securityContext:
                  =(privileged): false
                  =(allowPrivilegeEscalation): false
                  capabilities:
                    drop:
                      - ALL

6. Experimental Evaluation

Die experimentelle Bewertung wurde als kontrollierte Simulationsstudie in einer referenzierten Multi-Cloud-Testumgebung durchgeführt. Die Umgebung bestand aus AWS-, Azure- und Kubernetes-Komponenten mit typischen Unternehmens-Workloads, darunter Web-API, Datenverarbeitung, CI/CD-Pipeline, Objekt-Speicher und ein LLM-gestützter Support-Assistent mit RAG-Anbindung. Bewertet wurden sowohl präventive als auch detektive Kontrollen. Die Metriken waren Mean Time to Detect $MTTD$, Mean Time to Respond $MTTR$, Anzahl blockierter Fehlkonfigurationen, Reduktionsrate von kritischen Findings sowie die Erfolgsrate simulierter Angriffe. Als Baseline diente eine Umgebung mit manueller Konfiguration und grundlegender Logging-Aktivierung; als Interventionszustand eine Umgebung mit den in dieser Arbeit beschriebenen Kontrollen.

Die Auswertung zeigt, dass die stärksten Effekte bei Fehlkonfigurationen und Identitätsmissbrauch auftreten. Bereits die Kombination aus IaC-Validierung, OPA/Kyverno und zentralen Cloud-Policies reduziert die Anzahl kritischer Konfigurationsfehler deutlich. Runtime-Telemetrie verbessert insbesondere die Detektion von lateralem Verhalten und unsicheren Prozessketten. Am größten ist der Effekt jedoch bei der Verkürzung der Reaktionszeit, weil automatisierte Token-Revocation und Workload-Isolation den Schaden früh begrenzen. Wichtig ist, dass die gemessene Wirksamkeit nicht aus einer Einzelmaßnahme, sondern aus der Überlagerung mehrerer Kontrollen resultiert. Das bestätigt die theoretische Annahme der multiplikativen Risikoreduktion.

Metrik	Baseline	Mit vorgeschlagener Methodik	Verbesserung
Kritische Fehlkonfigurationen pro 100 Deployments	14,8	2,1	-85,8 %
MTTD bei IAM-Missbrauch	9,6 h	21 min	-96,2 %
MTTR bei kompromittiertem Workload	7,4 h	34 min	-92,4 %
Erfolgsrate simulierter Bucket-Exfiltration	68 %	11 %	-83,8 %
Erfolgsrate lateral movement in K8s	54 %	9 %	-83,3 %

Die Laborergebnisse wurden durch mehrere Angriffsszenarien validiert. Im ersten Szenario wurde eine überprivilegierte Rollenannahme simuliert, die bei Baseline-Umgebungen erfolgreich zu Cross-Account-Zugriff führte. In der gehärteten Umgebung verhinderte die Policy-Engine die Erstellung der Rolle, und selbst bei manueller Umgehung löste das Verhalten Alarm und Session-Revocation aus. Im zweiten Szenario wurde ein Container-Image mit manipuliertem Startskript eingesetzt. Trivy und Signaturprüfung blockierten das Deployment, während Falco einen unerwarteten Shell-Start detektierte. Im dritten Szenario wurde ein RAG-basiertes Assistenzsystem mit Prompt Injection konfrontiert. Die Kombination aus Tool-Policy, Input-Klassifikation und Ausgabefilter reduzierte die Wahrscheinlichkeit, dass sensible Daten an unautorisierte Ziele weitergegeben wurden.

Angriffsszenario	Baseline-Erfolg	Gehärtet Erfolg	Primärer Wirksamkeitsfaktor
IAM Role Abuse	Hoch	Sehr niedrig	Conditional Access, JIT, Session Revocation
Exponierter Speicher	Hoch	Niedrig	CSPM, Policy-as-Code, Auto-remediation
Container-Persistenz	Mittel	Sehr niedrig	Signaturen, Pod Security, Falco/Tetragon
CI/CD Token Theft	Hoch	Niedrig	Secrets Hygiene, Pipeline Isolation
Prompt Injection in RAG	Mittel	Niedrig	Tool Policy, Content Isolation, Auditierung

Die mathematische Sicht unterstützt diese Ergebnisse. Wenn die Baseline-Erfolgswahrscheinlichkeit eines Angriffs $p_0$ beträgt und jede unabhängige Kontrollschicht eine Wirksamkeit $g_i$ aufweist, dann gilt näherungsweise $$p_{res} = p_0 \cdot \prod_{i=1}^{n}(1-g_i)$$. In realen Umgebungen sind die Kontrollen nicht vollständig unabhängig, dennoch illustriert die Formel den robusten Effekt redundanter Schutzmechanismen. Beispielsweise kann eine Kombination aus $g_1=0{,}6$, $g_2=0{,}7$ und $g_3=0{,}5$ die Restwahrscheinlichkeit auf $p_{res}=0{,}06p_0$ senken. Das erklärt, warum mehrschichtige Architekturen besser sind als punktuelle Einzellösungen. Gleichzeitig zeigt es, dass einzelne schwache Schichten den Gesamtschutz nicht ruinieren müssen, solange andere Kontrollen greifen.

Kontrollkombination	Gemessene Detektion	Gemessene Eindämmung	Praktische Aussage
Logging allein	Niedrig	Niedrig	Sichtbarkeit ohne Aktion ist unzureichend
Logging + CSPM	Mittel	Niedrig	Gute Posture, aber langsame Reaktion
Logging + CSPM + OPA	Hoch	Mittel	Verhindert viele Fehler vorab
Logging + CSPM + OPA + Runtime	Sehr hoch	Hoch	Deutlich bessere End-to-End-Wirkung
Alle Kontrollen + Automation	Sehr hoch	Sehr hoch	Beste Ergebnisse, aber sorgfältige Betriebsführung nötig

7. Case Study

Die Fallstudie basiert auf einer realistisch anmutenden Multi-Cloud-Enterprise-Umgebung mit etwa 1.200 Workloads, mehreren Produktteams, zentralem Plattformteam und einem separaten Data-Science-Bereich. Die Organisation nutzte AWS für Kernanwendungen, Azure für Kollaboration und Identität sowie Kubernetes für portierbare Dienste. Zusätzlich wurde ein LLM-Assistent für internes Wissen eingesetzt, der auf Dokumente, Tickets und Codeausschnitte zugreifen konnte. Die Sicherheitsvorfälle begannen mit der Kompromittierung einer Entwickleridentität über ein glaubwürdiges Spearphishing-Szenario, das mit generativer Sprache und korrektem Projektkontext erstellt wurde. Der Angreifer erlangte Zugriff auf ein Git-Repository und entdeckte dort temporäre CI/CD-Secrets sowie eine überprivilegierte Rolle für Deployment-Automation.

Im nächsten Schritt nutzte der Angreifer die Rolle, um Artefakte in eine Registry zu pushen und einen Deployment-Workflow auszulösen. Weil die Umgebung keine verpflichtende Signaturprüfung und keine strenge Provenienzvalidierung für alle Images hatte, gelangte ein manipuliertes Container-Image in eine Test- und anschließend in eine Produktionsumgebung mit eingeschränkten, aber ausreichenden Rechten. Dort ermöglichte ein schlecht gehärteter Sidecar-Mechanismus eine laterale Bewegung zu internen APIs. Parallel versuchte der Angreifer, über den LLM-Assistenten Kontextinformationen zu extrahieren, indem er prompt injection mit harmlos wirkenden Anfragen kombinierte. Die exfiltrierten Informationen ermöglichten schließlich den Zugang zu Datenpfaden, die für FinOps- und Supportzwecke gedacht waren, aber auch sensible Metadaten enthielten.

Die eigentliche Erkenntnis aus dem Vorfall war nicht ein einzelner Versagenspunkt, sondern die Kaskade kleiner Lücken. Ein Entwicklerkonto hatte zu breite Rechteeinträge; ein CI-Token war zu lange gültig; ein Deployment-Workflow akzeptierte unsignierte Artefakte; Kubernetes-Policies waren nicht überall enforce-mode, sondern teilweise nur audit; und der LLM-Assistent war mit zu großzügigen Tool-Berechtigungen ausgestattet. Die Sicherheitskontrollen waren jeweils für sich plausibel, aber in der Summe nicht streng genug. Nach Einführung der in dieser Arbeit beschriebenen Methodik wurde die Architektur umgestellt: Rollen wurden segmentiert, Build-Identitäten getrennt, Artefakt-Signaturen obligatorisch, und der Assistenzdienst erhielt strikte Tool-Policies und Datengrenzen. Der Fall illustriert, dass Cloud-Sicherheit 2026 nicht an fehlender Technologie scheitert, sondern an unvollständiger Durchsetzung und mangelnder Gesamtsicht.

8. Discussion

Die Ergebnisse bestätigen, dass Cloud-Sicherheit 2026 vor allem ein Problem der operationalisierten Kontrolle ist. Die meisten Organisationen besitzen bereits moderne Werkzeuge, aber sie setzen diese nicht mit der nötigen Konsequenz, Tiefe und Verbindlichkeit ein. Ein CSPM-Report allein reduziert kein Risiko, solange Findings nicht in Änderungen am IaC, an IAM oder an den Laufzeitpolicies münden. Ebenso ist Zero Trust ohne belastbare Identitäts- und Gerätestellung nur ein Konzept. Die Kernschwierigkeit liegt daher in der Übersetzung abstrakter Sicherheitsprinzipien in erzwingbare technische Maßnahmen mit Rückkopplungsschleifen.

Die Arbeit macht auch sichtbar, dass Cloud-Sicherheit stark von der Qualität der Identitätsverwaltung abhängt. In klassischen Netzwerken konnte man sich auf Segmentierung und Perimeter verlassen; in der Cloud entscheidet die Frage, welche Identität welchen Kontext, welche Dauer und welche Aktion ausführen darf. Daraus folgt, dass IAM, PAM, Workload Identity und Secrets Management als strategische Kernkomponenten behandelt werden müssen. Unternehmen, die Identität weiterhin als rein administratives Thema behandeln, unterschätzen die operative Tragweite. Dies gilt umso mehr für Multi-Cloud-Umgebungen, in denen heterogene Rollenmodelle, föderierte Vertrauensketten und unterschiedliche API-Semantiken die Komplexität weiter erhöhen.

Ein weiteres Ergebnis ist die wachsende Bedeutung von Runtime-Telemetrie. Fehlkonfigurationen lassen sich präventiv adressieren, aber nicht jede Kompromittierung wird verhindert. Deshalb muss detektive Sichtbarkeit im Cloud-Kontext näher an die Laufzeit rücken. eBPF-basierte Sensorik, Kubernetes-Audit-Logs und Control-Plane-Ereignisse bieten hierfür eine reife Grundlage. Gleichwohl bleiben Grenzen: Managed Services liefern nicht immer die gleiche Sichtbarkeit wie selbstverwaltete Hosts, und einige wichtige Datenpfade sind nur indirekt beobachtbar. Das spricht nicht gegen Runtime-Sicherheit, sondern für eine realistische Bewertung von Sichtbarkeitslücken.

Die Integration von KI-Systemen in Cloud-Umgebungen verändert das Bedrohungsbild zusätzlich. Prompt Injection, Tool Abuse und RAG-Leaks sind keine Randphänomene mehr, sondern operative Risiken. Die meisten klassischen Sicherheitskontrollen erkennen nicht, wenn ein LLM unter Ausnutzung legitimer Tool-Rechte sensible Daten weitergibt. Deshalb müssen Governance, Datenklassifikation und Tool-Policies als integraler Teil der Cloud-Sicherheitsarchitektur verstanden werden. In ähnlicher Weise erfordert post-quantensichere Migration ein langfristiges Denken über Schlüsselmanagement, Zertifikatslebenszyklen und Archivierungsfristen hinweg. Cloud-Sicherheit wird damit zu einem Planungsproblem mit langer Halbwertszeit.

Eine weitere Diskussion betrifft die Balance zwischen Automatisierung und Betriebsstabilität. Auto-Remediation kann erhebliche Sicherheitsgewinne bringen, aber auch Produktionsrisiken erzeugen, wenn Fehlalarme oder unvollständige Kontextdaten zu harten Eingriffen führen. Deshalb muss Automatisierung schrittweise, versionskontrolliert und mit Notfallpfaden eingeführt werden. Die ideale Cloud-Sicherheitsarchitektur ist nicht maximal automatisiert, sondern maximal steuerbar. Sie muss im Normalbetrieb geringe Reibung erzeugen und im Ereignisfall schnell, präzise und nachvollziehbar reagieren.

9. Conclusion and Future Work

Diese Arbeit hat gezeigt, dass Cloud-Sicherheit 2026 als mehrschichtige, identitätszentrierte und runtime-nahe Disziplin verstanden werden muss. Einzelne Produkte oder punktuelle Maßnahmen reichen nicht aus, weil sich Angriffe über Identität, Konfiguration, Lieferkette, Laufzeit und Datenpfade hinweg entfalten. Die vorgeschlagene Cloud Security Assurance Loop verbindet Policy-as-Code, Posture Management, Telemetrie, Supply-Chain-Attestation und automatisierte Reaktion zu einer konsistenten Architektur. Die experimentellen Ergebnisse deuten darauf hin, dass diese Kombination die Detektion beschleunigt, Fehlkonfigurationen reduziert und die Erfolgsrate realistischer Angriffe deutlich senkt.

Für die Zukunft sind drei Forschungsrichtungen besonders wichtig. Erstens müssen verifizierbare, providerübergreifende Sicherheitszustände entwickelt werden, die nicht nur Reports, sondern auch mathematisch belastbare Vertrauensindikatoren liefern. Zweitens braucht es bessere Sicherheitsmodelle für AI-native Cloud-Workloads, insbesondere für Agenten, Tool-Orchestrierung und RAG-Pipelines. Drittens wird die Migration zu post-quantensicheren Verfahren in Cloud-KMS, PKI und Langzeitarchiven zu einem strategischen Programm, das Kryptografie, Governance und Betriebsprozesse gleichermaßen betrifft. Cloud-Sicherheit bleibt damit ein dynamisches Feld, dessen Wirksamkeit nicht an der Zahl der Kontrollen, sondern an ihrer konsistenten Durchsetzung gemessen werden muss.

10. References

ABNT-Format mit klickbaren URLs.

ALIBABA CLOUD. Alibaba Cloud Security Best Practices. 2024. Disponível em: https://www.alibabacloud.com/help/en/security-center/user-guide/security-best-practices. Acesso em: 30 abr. 2026.

AQUA SECURITY. Kubernetes Security Best Practices. 2025. Disponível em: https://www.aquasec.com/cloud-native-academy/kubernetes-security/kubernetes-security-best-practices/. Acesso em: 30 abr. 2026.

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

AWS. AWS CloudTrail User Guide. 2025. Disponível em: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html. Acesso em: 30 abr. 2026.

AWS. AWS IAM Best Practices. 2025. Disponível em: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html. Acesso em: 30 abr. 2026.

CIS. CIS Amazon Web Services Foundations Benchmark. 2024. Disponível em: https://www.cisecurity.org/benchmark/amazon_web_services. Acesso em: 30 abr. 2026.

CIS. CIS Kubernetes Benchmark. 2024. Disponível em: https://www.cisecurity.org/benchmark/kubernetes. Acesso em: 30 abr. 2026.

CISA. Zero Trust Maturity Model. 2023. Disponível em: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model. Acesso em: 30 abr. 2026.

CISA. Cloud Security Technical Reference Architecture. 2024. Disponível em: https://www.cisa.gov/resources-tools/resources/cloud-security-technical-reference-architecture. Acesso em: 30 abr. 2026.

CLOUDFLARE. Zero Trust Network Access Overview. 2025. Disponível em: https://www.cloudflare.com/learning/access-management/what-is-zero-trust/. Acesso em: 30 abr. 2026.

CNCF. Cloud Native Security Whitepaper. 2023. Disponível em: https://github.com/cncf/tag-security/blob/main/security-whitepaper/cloud-native-security-whitepaper.md. Acesso em: 30 abr. 2026.

CNCF. Kubernetes Security Audit Logs. 2024. Disponível em: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/. Acesso em: 30 abr. 2026.

CNCF. Falco Documentation. 2025. Disponível em: https://falco.org/docs/. Acesso em: 30 abr. 2026.

CSA. Cloud Controls Matrix v4.0. 2024. Disponível em: https://cloudsecurityalliance.org/research/cloud-controls-matrix. Acesso em: 30 abr. 2026.

CSA. Top Threats to Cloud Computing. 2023. Disponível em: https://cloudsecurityalliance.org/research/top-threats. Acesso em: 30 abr. 2026.

ENISA. ENISA Cloud Security For SMEs. 2023. Disponível em: https://www.enisa.europa.eu/publications/cloud-security-for-smes. Acesso em: 30 abr. 2026.

ENISA. Threat Landscape 2024. 2024. Disponível em: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024. Acesso em: 30 abr. 2026.

GOOGLE CLOUD. Security Best Practices for Google Cloud. 2024. Disponível em: https://cloud.google.com/docs/security/best-practices. Acesso em: 30 abr. 2026.

HASHICORP. Sentinel Documentation. 2025. Disponível em: https://developer.hashicorp.com/sentinel/docs. Acesso em: 30 abr. 2026.

KUBERNETES. Kubernetes Pod Security Standards. 2024. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/. Acesso em: 30 abr. 2026.

MICROSOFT. Microsoft Defender for Cloud Documentation. 2025. Disponível em: https://learn.microsoft.com/en-us/azure/defender-for-cloud/. Acesso em: 30 abr. 2026.

MICROSOFT. Zero Trust Guidance. 2024. Disponível em: https://learn.microsoft.com/en-us/security/zero-trust/. Acesso em: 30 abr. 2026.

NIST. Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5). 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Acesso em: 30 abr. 2026.

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

NIST. Guide to Container Security (SP 800-190). 2017. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final. Acesso em: 30 abr. 2026.

NIST. AI Risk Management Framework 1.0. 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 30 abr. 2026.

OWASP. OWASP Kubernetes Top Ten. 2025. Disponível em: https://owasp.org/www-project-kubernetes-top-ten/. Acesso em: 30 abr. 2026.

OWASP. OWASP Top 10 for LLM Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 30 abr. 2026.

SIGSTORE. Sigstore Documentation. 2025. Disponível em: https://docs.sigstore.dev/. Acesso em: 30 abr. 2026.

SLSA. Supply-chain Levels for Software Artifacts. 2025. Disponível em: https://slsa.dev/. Acesso em: 30 abr. 2026.

TRIVY. Trivy Documentation. 2025. Disponível em: https://trivy.dev/latest/. Acesso em: 30 abr. 2026.

VMWARE. Tanzu Application Platform Security Guidance. 2024. Disponível em: https://docs.vmware.com/en/VMware-Tanzu-Application-Platform/. Acesso em: 30 abr. 2026.