Cloud-Sicherheitsarchitektur 2026: Eine praxisorientierte, mehrschichtige Methodik zur Absicherung hybrider und nativer Cloud-Umgebungen gegen Identitätsmissbrauch, Fehlkonfigurationen, Supply-Chain-Risiken und KI-gestützte Angriffe

1. Introduction

Die Cloud ist bis 2026 nicht mehr lediglich ein Betriebsmodell zur Auslagerung von Rechenleistung, sondern das zentrale Nervensystem vieler digitaler Organisationen. Geschäftsprozesse, Datenplattformen, Entwicklungsumgebungen, Endkundenschnittstellen und zunehmend auch KI-Workloads laufen in verteilten Cloud-Ökosystemen, die von hyperskaligen Public-Cloud-Diensten bis zu privaten, souveränen und branchenspezifischen Installationen reichen. Diese Entwicklung hat die Skalierbarkeit und Geschwindigkeit der IT erheblich erhöht, zugleich aber eine Sicherheitslandschaft geschaffen, in der Identität, Konfiguration und Automatisierung weit stärker über das Sicherheitsniveau entscheiden als klassische Netzgrenzen. In der Praxis ist die Angriffsfläche einer Cloud-Umgebung deshalb nicht primär durch IP-Adressen definiert, sondern durch Rollen, Tokens, Policies, Workload-Identitäten, APIs und Lieferkettenbeziehungen.

Die Sicherheitsprobleme der Cloud sind nicht neu, aber ihre Struktur hat sich mit der Reife der Plattformen verändert. Frühere Diskussionen konzentrierten sich auf Datenexfiltration aus falsch konfigurierten Speicherobjekten oder auf kompromittierte virtuelle Maschinen. 2026 stehen dagegen oft die Identitäts- und Steuerungsebenen im Mittelpunkt. Ein Angreifer benötigt in vielen Fällen keine exotische Zero-Day-Schwachstelle, sondern lediglich einen gültigen Zugriffspfad über SSO, OAuth, OIDC, temporäre Credentials, CI/CD-Runner oder ein überprivilegiertes Servicekonto. In solchen Umgebungen verschiebt sich die klassische Perimetersicherheit zugunsten eines Modells, in dem jede einzelne Operation authentifiziert, autorisiert, protokolliert und kontextualisiert werden muss. Diese Entwicklung ist eng mit Zero Trust verbunden, jedoch nicht identisch mit ihm. Zero Trust ist in der Cloud nicht nur eine Netzwerktopologie, sondern eine betriebliche Disziplin, die Identität, Gerätezustand, Workload-Kontext und Risiko in Echtzeit bewertet.

Gleichzeitig ist die Cloud 2026 ein produktives Ziel für Angreifer mit stark unterschiedlichen Motivationen. Cyberkriminelle nutzen Fehlkonfigurationen, erbeutete Tokens und schwache Lebenszyklussteuerung, um Daten zu exfiltrieren oder Ransomware-Operationen vorzubereiten. Staatlich unterstützte Akteure fokussieren sich auf langfristige Persistenz, stille Aufklärung und die Ausnutzung vertrauenswürdiger Verwaltungswerkzeuge. Insider und Lieferkettenakteure können durch legitimen Zugriff erhebliche Schäden verursachen, insbesondere wenn Logs, Build-Artefakte oder Terraform-Module manipuliert werden. Hinzu kommt eine neue Qualität durch KI-gestützte Operationen: Phishing wird kontextreicher, Social Engineering wird sprachlich variabler, und automatisierte Reconnaissance kann Metadaten, offene APIs und Policy-Fehler in großem Umfang auswerten. Daraus entsteht ein Umfeld, in dem klassische Einzelmaßnahmen wie Netzwerksegmentierung oder Passwort-Richtlinien allein nicht ausreichen.

Die zentrale These dieser Arbeit lautet, dass Cloud-Sicherheit 2026 nur dann tragfähig ist, wenn sie als kontinuierliches Steuerungsproblem verstanden wird. Es genügt nicht, nachträglich Fehlkonfigurationen zu suchen; vielmehr muss eine Organisation ihre Cloud als ständig veränderliche Menge von Identitäten, Workloads, Policies und Vertrauenskanten modellieren. Daraus folgt ein methodischer Ansatz, der drei Ebenen verbindet: erstens eine formale Beschreibung der Angriffsfläche, zweitens eine technische Referenzarchitektur mit Policy-as-Code und Telemetrie, und drittens eine operative Bewertung mit messbaren Kontrollzielen. In diesem Zusammenhang ist die Cloud keine abstrakte Umgebung, sondern ein System von Zuständen $S$, Übergängen $T$ und Sicherheitsinvarianten $I$, das sich durch Ereignisse wie Rollenerweiterungen, neue Deployments oder Tokenausstellungen verändert.

Die praktische Relevanz ist erheblich. Unternehmen migrieren weiterhin in Multi-Cloud- und Hybridmodelle, um Resilienz, Compliance und Verhandlungsmacht zu verbessern. Doch die Heterogenität der Plattformen erzeugt Komplexität: AWS, Azure, GCP, Kubernetes-Distributionen, SaaS-Administrationsoberflächen und CI/CD-Systeme bringen jeweils eigene Identitätsmodelle, Protokolle und Logging-Standards mit. Sicherheitsverantwortliche sehen sich daher nicht nur mit technischen Problemen konfrontiert, sondern auch mit Governance-Fragen: Wer darf Policies definieren? Wie werden Ausnahmen dokumentiert? Wie wird nachgewiesen, dass eine Kontrolle wirkt? Und wie lassen sich KI-gestützte Produktivitätswerkzeuge nutzen, ohne sensible Konfigurationen oder Geheimnisse zu gefährden?

Diese Arbeit adressiert diese Fragen in sieben miteinander verknüpften Schritten. Zunächst wird die Entwicklung der Cloud-Sicherheitslandschaft eingeordnet. Danach wird ein Bedrohungsmodell formalisiert, das Identitätsmissbrauch, Fehlkonfigurationen, Supply-Chain-Risiken und Laufzeitangriffe gemeinsam betrachtet. Anschließend wird eine Methodik vorgeschlagen, die Assets inventarisiert, Policies maschinenlesbar macht, Telemetrie korreliert und Reaktion automatisiert. Eine Referenzimplementierung illustriert die Umsetzung mit realen Werkzeugen wie Terraform, Kubernetes, Open Policy Agent, Trivy, Falco, CloudTrail, Microsoft Defender for Cloud, Wiz, Prisma Cloud und Security-Logs aus gängigen Cloud-Umgebungen. Die experimentelle Bewertung vergleicht Angriffserkennung, Fehlalarmraten und Zeit bis zur Eindämmung in verschiedenen Szenarien. Eine Fallstudie zeigt schließlich, wie die Methodik in einer regulierten Hybrid-Cloud-Organisation anwendbar ist, in der Datenschutz, Lieferkettensicherheit und Betriebsresilienz gleichzeitig erfüllt werden müssen.

2. Background and Related Work

Die wissenschaftliche und industrielle Literatur zur Cloud-Sicherheit ist umfangreich, doch ihre Schwerpunkte haben sich über die Jahre verschoben. Frühere Arbeiten konzentrierten sich auf Virtualisierungssicherheit, Mandantentrennung und Datenvertraulichkeit in Public Clouds. Später rückten Identitäts- und Zugriffsmanagement, Container-Orchestrierung und DevSecOps in den Vordergrund. Bis 2026 wurde die Debatte schließlich um CNAPP, SSPM, DSPM, CIEM, eBPF-basierte Laufzeitüberwachung und KI-Governance erweitert. Diese Verschiebung ist nicht nur terminologisch, sondern operational: Die Cloud wird heute als Kombination aus Plattform, Identitätssystem, Automatisierungsnetz und Datenraum verstanden.

Ein zentraler Forschungsstrang behandelt Fehlkonfigurationen als dominierenden Risikofaktor. Studien und Incident-Analysen zeigen seit Jahren, dass offen zugängliche Buckets, zu breite IAM-Rollen, ungesicherte Management-Interfaces und unkontrollierte Schlüsselverwendung zu den häufigsten Ursachen von Cloud-Vorfällen gehören (ENISA, 2024; CSA, 2023). Der entscheidende Punkt ist, dass Fehlkonfigurationen nicht mehr als isolierte Fehler auftreten, sondern in verteilten Automatisierungsketten entstehen. Ein Terraform-Plan, der in einer Pipeline freigegeben wird, kann mit einer kleinen Änderung in einer Variablen erheblich mehr Rechte ausrollen als beabsichtigt. Deshalb reicht manuelle Prüfung nicht aus; Policies müssen als Code formuliert und zur Laufzeit überprüft werden.

Ein zweiter Strang betrifft die Sicherheitsfolgen der Identitätsföderation. OIDC, SAML und kurzlebige STS-Mechanismen haben die Handhabung von Credentials verbessert, zugleich aber die Zahl der Vertrauensbeziehungen erhöht. Forschung und Praxis zeigen, dass Angreifer häufig nicht die Cloud selbst, sondern das Identity Provider-Ökosystem kompromittieren, um über legitime Tokens und Rollen in die Zielumgebung einzudringen (Microsoft, 2024; Mandiant, 2024). Besonders relevant sind tokenbasierte Angriffe, Rollenkette-Missbrauch und die Fehlkonfiguration von Trust Policies. Anders als bei klassischen Passwortangriffen lässt sich der Missbrauch temporärer Tokens schwerer erkennen, weil er im normalen Betriebsrauschen untergeht.

Ein dritter Forschungsbereich ist die Sicherheit von Containern und Kubernetes. Seit der breiten Nutzung von Kubernetes ist das Cluster nicht mehr nur eine Bereitstellungsplattform, sondern ein eigenständiger Angriffsraum mit API-Server, etcd, Kubelet, Admission-Controllern, Service Accounts, Network Policies und Secrets Management. Studien und Incident Reports dokumentieren regelmäßig Angriffe über offen erreichbare Dashboards, schwache RBAC-Regeln, Exponierung von Serviceaccount-Tokens und Missbrauch von privilegierten Pods (CIS, 2024; NIST, 2024). Die Komplexität steigt, wenn Kubernetes in Multi-Cluster-, Service-Mesh- und GitOps-Architekturen eingebettet wird.

Ein vierter Strang betrifft die Lieferkettensicherheit. Softwarelieferketten wurden spätestens seit den Angriffen auf Build-Systeme, Paketregistries und Signing-Infrastrukturen als strategischer Schwachpunkt erkannt (NIST, 2022; CISA, 2023). In Cloud-Umgebungen ist diese Thematik besonders kritisch, weil Infrastructure as Code, Container-Images, Helm-Charts, GitHub Actions, GitLab CI und Azure DevOps oft direkt produktive Berechtigungen besitzen. Eine kompromittierte Pipeline kann daher nicht nur Code manipulieren, sondern auch Infrastruktur, Secrets oder Deployment-Ziele. Der Übergang vom Anwendungscode zur Cloud-Infrastruktur ist damit fließend.

Ein fünfter Themenkomplex ist die Beobachtbarkeit und Laufzeitabsicherung. eBPF-basierte Sensoren, Cloud-native Detection-and-Response-Produkte und Runtime Threat Detection haben an Bedeutung gewonnen, weil sie tiefe Einblicke in Syscalls, Netzwerkaktivitäten und Prozessverhalten erlauben, ohne klassische Kernel-Module in gleicher Weise zu belasten (Falco, 2024; Aqua Security, 2024). Dies ist insbesondere in Container- und Serverless-Umgebungen relevant, in denen statische Scans allein die tatsächliche Ausführung nicht abbilden. Dennoch ist zu beachten, dass Laufzeittelemetrie nur dann wirksam ist, wenn sie mit Kontext aus IAM, Asset-Inventar und Build-Metadaten korreliert wird.

Ein sechster und bis 2026 stark gewachsener Bereich ist die Sicherheit von KI-Systemen in der Cloud. Generative KI wird für Codegenerierung, Support, Content-Erstellung und Security Operations genutzt, aber auch als Angriffsverstärker missbraucht. Prompt Injection, Data Poisoning, Model Exfiltration, Jailbreaks und Missbrauch von LLM-basierten Assistenten stellen neue Risikoformen dar (OWASP, 2024; NIST, 2024). In Cloud-Umgebungen entsteht daraus ein doppeltes Problem: Einerseits laufen KI-Workloads selbst in der Cloud und müssen abgesichert werden, andererseits können KI-gestützte Werkzeuge versehentlich geheime Konfigurationen oder sensible Betriebsdaten preisgeben. Damit wird Cloud-Sicherheit zugleich zur KI-Governance-Frage.

Die Literatur zeigt außerdem, dass klassische Perimeter-Modelle für moderne Cloud-Architekturen unzureichend sind. Netzwerksegmentierung bleibt wichtig, verliert aber an Erklärungskraft, wenn Identitäten dynamisch, Ressourcen kurzlebig und Kontrollflächen API-getrieben sind. Deshalb gewinnen Datenflussanalyse, Policy-as-Code, Attack-Path-Analysen und Identitätsgraphen an Bedeutung. Ein Identitätsgraph modelliert Entitäten wie Benutzer, Rollen, Service Accounts, Workloads, Schlüssel und Tokens als Knoten, während Berechtigungen, Trust-Beziehungen und Zugriffsereignisse als Kanten beschrieben werden. Auf diese Weise lassen sich nicht nur direkte Privilegien, sondern auch indirekte Eskalationspfade untersuchen.

Die vorliegende Arbeit positioniert sich an der Schnittstelle dieser Stränge. Sie übernimmt die Einsicht, dass Identität die neue Kontrollgrenze ist, erweitert sie aber um eine operative Methodik, die Fehlkonfigurationen, Supply-Chain-Risiken und Laufzeitangriffe gemeinsam adressiert. Die Arbeit verbindet wissenschaftliche Formalisierung mit praxisnaher Umsetzung. Ein zentrales Ziel ist es, die Wirksamkeit von Kontrollen nicht nur qualitativ zu beschreiben, sondern in Bezug auf Detektion, Reaktionszeit und Risikoreduktion messbar zu machen. Genau darin liegt der Mehrwert gegenüber rein deskriptiven Übersichten.

3. Threat Model and Problem Formalization

Das Bedrohungsmodell dieser Arbeit richtet sich an hybride und Multi-Cloud-Umgebungen, in denen mindestens eine Public Cloud, ein Identitätsanbieter, eine CI/CD-Kette und containerisierte oder serverless Workloads miteinander verknüpft sind. Der Angreiferraum umfasst externe Gegner, kompromittierte Lieferanten, fehlerhafte interne Konfigurationen und böswillige Insider. Die Annahme ist, dass der Angreifer entweder initialen Zugang über gestohlene Credentials, API-Schlüssel, OAuth-Tokens oder Phishing erlangt oder über Fehlkonfigurationen und öffentliche Angriffsflächen in die Umgebung eindringen kann. Physischer Zugriff auf Rechenzentren ist nicht Teil des Basismodells, wohl aber Angriffe auf Management- und Steuerungsebenen.

Wir definieren die Cloud-Umgebung als Zustandssystem $C = (A, I, P, W, D, L)$, wobei $A$ die Assets, $I$ die Identitäten, $P$ die Policies, $W$ die Workloads, $D$ die Datenobjekte und $L$ die Log- und Telemetriesysteme repräsentieren. Ein Zustand $s \in S$ beschreibt eine konkrete Ausprägung dieser Mengen zu einem Zeitpunkt $t$. Übergänge entstehen durch Ereignisse wie Rollenerstellung, Key-Rotation, Deployment, Skalierung, Policy-Änderung oder Benutzeranmeldung. Ein Angriffsweg ist eine Folge $a = (e_1, e_2, …, e_n)$ von Ereignissen, die von einem unsicheren Initialzustand zu einem kompromittierten Zielzustand führt.

Die Sicherheitsinvarianten werden als Menge $I = {i_1, i_2, …, i_m}$ formuliert. Beispiele sind: kein öffentlich zugänglicher Speicher ohne Freigabe; keine administrativen Rollen für persistente Workloads; keine produktiven Secrets im Quellcode; keine Trust-Policy ohne explizite Scope-Bindung; kein privilegierter Pod ohne dokumentierte Ausnahme. Die Kernfrage lautet, ob die Umgebung für alle zulässigen Übergänge $T$ die Invarianten erfüllt. Formal kann das Risiko einer Konfiguration als Funktion $R$ modelliert werden, etwa $$ R = \sum_{k=1}^{n} P(a_k) \cdot I(a_k) \cdot E(a_k), $$ wobei $P(a_k)$ die Eintrittswahrscheinlichkeit, $I(a_k)$ die Auswirkung und $E(a_k)$ die Exposition eines Angriffswegs $a_k$ beschreibt. Diese Formel ist bewusst operational, da sie die Priorisierung von Maßnahmen unterstützt.

Das Problem ist multidimensional. Erstens existiert eine große Zahl potenzieller Fehlkonfigurationen, die durch Cloud-Standardeinstellungen, manuelle Ausnahmen oder Pipeline-Fehler entstehen können. Zweitens ist die Identitätslandschaft dynamisch und schwer vollständig zu inventarisieren. Drittens sind viele Cloud-Mechanismen nur indirekt beobachtbar, da sie über API-Events, Audit-Logs oder Provider-spezifische Telemetrie sichtbar werden. Viertens verändert sich die Bedrohungslage durch KI-gestützte Automatisierung, die Reconnaissance, Spearphishing und Exploit-Suche beschleunigt. Das Problem ist damit nicht die Existenz einzelner Schwachstellen, sondern die kontinuierliche Beurteilung von Prioritäten in einem hochvernetzten, sich schnell ändernden System.

Für die Bewertung verwenden wir drei zentrale Kenngrößen: Detektionsabdeckung $D_c$, mittlere Zeit bis zur Erkennung $MTTD$ und mittlere Zeit bis zur Eindämmung $MTTC$. Sie werden durch die Verfügbarkeit und Qualität von Telemetrie beeinflusst. Eine robuste Cloud-Sicherheitsarchitektur soll $D_c$ erhöhen und gleichzeitig $MTTD$ sowie $MTTC$ senken. Praktisch bedeutet dies, dass Signale aus IAM, Netzwerk, Host, Container, CI/CD und SaaS zentral korreliert werden müssen. Je besser die Korrelation, desto geringer die Wahrscheinlichkeit, dass ein einzelnes verdächtiges Ereignis als normales Betriebsrauschen untergeht.

Das Modell berücksichtigt außerdem die Besonderheiten von Multi-Cloud-Architekturen. Unterschiedliche Provider implementieren ähnliche Konzepte mit abweichenden Semantiken: Rollen, Managed Identities, Service Principals, Workload Identity Federation und Conditional Access sind nicht identisch, obwohl sie funktional ähnlich erscheinen. Ein Angreifer nutzt genau diese Unterschiede, um in der Kette die schwächste Stelle zu finden. Daher wird die sicherheitstechnische Analyse nicht auf einzelne Dienste beschränkt, sondern als Graphproblem betrachtet, in dem Berechtigungspfade, Trust-Relationships und Datenflüsse als Kanten zwischen Entitäten modelliert werden.

4. Proposed Methodology

Die vorgeschlagene Methodik ist als mehrschichtige Cloud-Sicherheitsarchitektur konzipiert, die Prävention, Detektion und Reaktion miteinander verknüpft. Sie basiert auf sechs Bausteinen: Asset-Transparenz, Identitätsgraph, Policy-as-Code, Laufzeittelemetrie, Datenkontext und adaptive Reaktion. Die Architektur ist so angelegt, dass sie sowohl Public-Cloud- als auch Hybrid- und Multi-Cloud-Umgebungen unterstützt und in DevSecOps-Prozesse integrierbar bleibt.

Der erste Baustein ist die vollständige Asset-Inventarisierung. Jede Ressource, die in der Cloud existiert oder entstehende Privilegien besitzt, wird als Asset erfasst: Projekte, Abonnements, Konten, Buckets, Datenbanken, Cluster, Namespaces, Service Accounts, Secrets, Keys, Pipelines, Images und externe Integrationen. Ohne inventarisierte Assets gibt es keine belastbare Risikoanalyse. Die Inventarisierung erfolgt kontinuierlich, weil Cloud-Ressourcen flüchtig sind und sich durch Autoscaling, IaC-Deployments oder Managed Services laufend verändern. In der Praxis werden APIs der Cloud-Provider, CMDB-Integrationen und IaC-Repositories zusammengeführt.

Der zweite Baustein ist der Identitätsgraph. Er verknüpft Menschen, Maschinen und Dienste über Rollen, Gruppen, Trust Policies, OAuth-Scopes, Token-Ausstellungen und Delegationsbeziehungen. Ziel ist es, indirekte Pfade sichtbar zu machen, etwa wenn ein Entwickler über GitHub Actions ein Deployment-Token erhält, dieses Token auf einen Kubernetes-Cluster zugreifen darf und von dort aus weitere Cloud-Ressourcen erreicht. Der Graph erlaubt die Berechnung von zentralen Metriken wie Angriffsreichweite, privilegierte Pfadlänge und Blast Radius. Besonders wichtig ist die Modellierung von kurzlebigen Credentials, weil diese zwar temporär sind, aber im Missbrauchsfall denselben Schaden verursachen können wie langfristige Schlüssel.

Der dritte Baustein ist Policy-as-Code. Sicherheitsanforderungen werden in maschinenlesbaren Regeln formuliert und in mehreren Schichten durchgesetzt: in Terraform über Validierungen, in Kubernetes über Admission Control, in CI/CD über Build-Gates und in der Laufzeit über Policy-Engines. Tools wie Open Policy Agent, Conftest, Kyverno und Gatekeeper dienen dazu, unzulässige Konfigurationen vor der Bereitstellung zu blockieren. Der Vorteil liegt nicht nur in der Automatisierung, sondern in der Nachweisbarkeit. Jede Policy ist versionierbar, auditierbar und testbar. Damit können Sicherheitsentscheidungen reproduzierbar gemacht werden, was insbesondere in regulierten Umgebungen entscheidend ist.

Der vierte Baustein ist die Laufzeittelemetrie. Statische Analysen erkennen Konfigurationsfehler, aber keine live auftretenden Missbrauchsmuster. Deshalb werden eBPF-basierte Sensoren, Cloud-native Audit-Logs und Workload-Monitoring kombiniert. Eine verdächtige Sequenz könnte etwa aus sts:AssumeRole, einem ungewöhnlichen kubectl exec, anschließendem Zugriff auf Secrets und einer Massenabfrage von S3-Objekten bestehen. Solche Muster sind nur dann erkennbar, wenn Telemetriequellen semantisch korreliert werden. Es genügt nicht, einzelne Alerts zu erzeugen; entscheidend ist die Bildung von Ereignisketten.

Der fünfte Baustein ist der Datenkontext. Nicht jede Ressource ist gleich kritisch, und nicht jeder Zugriff ist gleich riskant. Deshalb werden Datenklassifikation, regulatorische Anforderungen und Business-Criticality in die Analyse integriert. Ein Zugriff auf öffentliches Marketingmaterial hat eine andere Bedeutung als ein Zugriff auf personenbezogene Kundendaten oder kryptografische Schlüssel. Die Methodik berechnet daher kontextabhängige Prioritäten. Formal kann ein Prioritätswert $S$ als $$ S = \alpha \cdot C + \beta \cdot E + \gamma \cdot P + \delta \cdot T $$ geschrieben werden, wobei $C$ die Datenkritikalität, $E$ die Exposition, $P$ die Privilegienstufe und $T$ die zeitliche Persistenz darstellt. Die Gewichte $\alpha, \beta, \gamma, \delta$ werden organisationsspezifisch festgelegt.

Der sechste Baustein ist die adaptive Reaktion. Wenn die Detektion einen kritischen Pfad bestätigt, werden automatische Gegenmaßnahmen ausgelöst: Credential-Rotation, Revocation von Sessions, Sperrung von Rollen, Isolierung von Workloads, Quarantäne von Images oder Blocking von Netzpfaden. Automatisierung ist hier kein Selbstzweck, sondern eine Antwort auf die Geschwindigkeit moderner Angriffe. Gerade bei Cloud-Angriffen kann die Zeit zwischen Kompromittierung und Exfiltration sehr kurz sein. Die Reaktion muss daher oft innerhalb von Minuten, manchmal Sekunden erfolgen.

Die Methodik folgt einem zyklischen Ablauf: Erfassen, Analysieren, Bewerten, Erzwingen, Überwachen und Reagieren. Dieser Zyklus ist kontinuierlich und integriert sich in bestehende Prozesse. Seine Stärke liegt in der Verbindung von präventiven und reaktiven Kontrollen. Prävention ohne Detektion führt zu blinden Flecken, Detektion ohne Prävention zu unnötigem Alarmrauschen, Reaktion ohne Kontext zu gefährlicher Überschusswirkung. Die vorgeschlagene Architektur reduziert diese Probleme durch eine gemeinsame semantische Basis.

Tabelle 1: Zentrale Kontrollschichten der Methodik

Schicht	Ziel	Typische Technologien	Hauptmetriken
Asset-Inventarisierung	Vollständige Sichtbarkeit	CSPM, CMDB, Cloud APIs, IaC-Scanner	Abdeckungsgrad, Aktualität
Identitätsgraph	Berechtigungs- und Trust-Pfade	IAM-Analytik, CIEM, OIDC/SAML-Analyse	Pfadlänge, Blast Radius
Policy-as-Code	Vermeidung falscher Konfigurationen	OPA, Kyverno, Terraform Policy Checks	Verstoßrate, Block-Rate
Laufzeittelemetrie	Erkennung aktiver Angriffe	eBPF, Falco, Cloud Audit Logs	MTTD, Alert Precision
Datenkontext	Risikopriorisierung	DSPM, Klassifikation, Tags	Kritikalitätsquote
Adaptive Reaktion	Eindämmung und Wiederherstellung	SOAR, IAM Automation, Incident Response	MTTC, Recovery Time

Tabelle 2: Typische Cloud-Angriffsvektoren und passende Kontrollen

Angriffsvektor	Beispiel	Primäre Kontrolle	Sekundäre Kontrolle
Überprivilegierte Rollen	AdministratorAccess für Workloads	Least Privilege, CIEM	JIT Access, Session-Restriktion
Token-Diebstahl	OIDC/STS-Sessions missbraucht	MFA, Token-Schutz, Conditional Access	Session Monitoring
Öffentliches Storage	Offene Buckets / Blobs	CSPM, Policy-as-Code	DSPM, DLP
Kubernetes-Missbrauch	Privilegierte Pods	Admission Control, RBAC-Härtung	Runtime Detection
CI/CD-Supply-Chain	Manipulierte Build-Pipeline	Signierung, SLSA	Secrets-Härtung
Metadaten-Service	SSRF gegen IMDS	IMDSv2, Netzfilter	Workload Isolation

Die vorgeschlagene Methodik ist bewusst pragmatisch. Sie geht davon aus, dass keine einzelne Plattform oder kein einzelnes Tool die Cloud-Sicherheit „löst“. Stattdessen muss jede Schicht spezifische Aufgaben erfüllen und ihre Ergebnisse an die nächste Schicht weitergeben. Genau diese Verkettung ist entscheidend, um moderne Angriffe zu stoppen, die von der Fehlkonfiguration über die Identität bis zum Datenzugriff reichen.

5. Implementation

Die Referenzimplementierung orientiert sich an einer realistischen Enterprise-Umgebung mit einem Public-Cloud-Footprint, Kubernetes-Clustern, Git-basierten CI/CD-Pipelines und zentralisiertem Logging. Ziel ist nicht die vollständige Produktabbildung eines bestimmten Herstellers, sondern ein reproduzierbares Muster, das mit gängigen Werkzeugen umgesetzt werden kann. Die Implementierung setzt auf etablierte Technologien wie Terraform, Open Policy Agent, Kyverno, Trivy, Falco, Cloud-native Audit Logs, SIEM-Integration und Secrets-Management.

Die Bereitstellung beginnt mit Infrastructure as Code. Ressourcen werden ausschließlich über deklarative Konfigurationen erzeugt, wodurch Drift-Erkennung und Policy-Prüfung möglich werden. Ein Terraform-Workflow wird beispielsweise um terraform fmt, terraform validate, tflint, checkov und conftest ergänzt. Dadurch werden syntaktische und semantische Fehler vor dem Apply abgefangen. In einer reifen Pipeline werden zudem Abhängigkeitsprüfungen, Signierung von Artefakten und ein Freigabeprozess für produktive Änderungen erzwungen. Die Sicherheitsgewinn entsteht dadurch, dass Infrastrukturänderungen nicht mehr implizit, sondern prüfbar und versioniert erfolgen.

Ein zweites Element ist die Durchsetzung von Kubernetes-Policies. Admission Controller verhindern, dass Pods mit gefährlichen Parametern in das Cluster gelangen. Typische Regeln betreffen privileged: true, HostPath-Mounts, fehlende Resource Limits, offene hostNetwork-Nutzung oder die Verwendung unsignierter Images. Kyverno oder Gatekeeper prüfen diese Vorgaben direkt beim Erstellen oder Aktualisieren von Ressourcen. Dadurch wird aus einer statischen Leitlinie eine zwingende Kontrollinstanz.

Ein drittes Element ist das Image- und Dependency-Scanning. Container-Images werden vor dem Deployment mit Trivy oder ähnlichen Scannern überprüft. Gleichzeitig werden die Build-Artefakte signiert, etwa mit Sigstore Cosign, und per Policy nur dann zugelassen, wenn die Signatur verifizierbar ist. Damit wird die Integrität des Artefakts mit der Bereitstellung verbunden. Die Kombination aus Signierung und Verifikation reduziert das Risiko manipulierten Codes in der Lieferkette erheblich.

Ein viertes Element ist die Laufzeiterkennung. Falco oder vergleichbare Sensoren überwachen verdächtige Syscalls, Prozessstarts, File-Access-Muster und Netzwerkverbindungen. In Cloud-Umgebungen ist dies besonders wertvoll, wenn ein Angreifer in einen Container eindringt und versucht, Shells zu öffnen, Secrets zu lesen oder Credentials abzugreifen. Die Sensoren senden Ereignisse an ein zentrales SIEM, wo sie mit CloudTrail-, Azure-Activity-Log- oder GCP-Audit-Log-Einträgen korreliert werden. Ein verdächtiger Zugriff auf AssumeRole, gefolgt von einer Shell in einem Pod und anschließendem Zugriff auf sensible Daten, erzeugt so einen zusammengesetzten Alarm.

Ein fünftes Element ist die Geheimnisverwaltung. Secrets dürfen nicht im Code, nicht in Container-Images und nicht in temporären Build-Logs landen. Stattdessen kommen dedizierte Secret-Manager, kurzlebige Tokens und dynamische Credentials zum Einsatz. Die Rotation sensibler Schlüssel erfolgt automatisiert, wenn ein Indikator auf Kompromittierung deutet. Gerade im Kontext von Cloud und CI/CD ist dies essenziell, weil fest verdrahtete Schlüssel häufig der schnellste Weg zur lateralen Bewegung sind.

Codeblock 1: Beispiel für eine Terraform-Sicherheitsprüfung mit Conftest

terraform init
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json
conftest test tfplan.json -p policy/
checkov -f main.tf
tflint

Eine typische Policy prüft etwa, ob S3-Buckets öffentlich lesbar sind oder ob Security Groups 0.0.0.0/0 auf kritischen Ports zulassen. Solche Regeln sind nicht nur bei der Erstbereitstellung relevant, sondern auch bei Drift- und Reconciliation-Prozessen. Die Implementierung wird erst dann wirksam, wenn sie in jeder Pipeline-Stufe verbindlich ist.

Codeblock 2: Beispiel für eine Kubernetes-Admission-Policy mit Kyverno

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-pods
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: no-privileged
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Privilegierte Pods sind nicht erlaubt."
      pattern:
        spec:
          =(hostNetwork): false
          containers:
          - securityContext:
              privileged: false

Die Implementierung wird durch Observability ergänzt. Metriken aus Kubernetes, Cloud Control Plane, IAM und SIEM werden in ein zentrales Datenmodell überführt. Nur so lässt sich eine einheitliche Ereigniskette erzeugen. In der Praxis ist dies oft der schwierigste Teil, weil unterschiedliche Plattformen unterschiedliche Schema- und Retentionsmodelle verwenden. Deshalb empfiehlt sich ein normalisiertes Ereignisformat, das zumindest Felder für Zeit, Entität, Aktion, Ressource, Ergebnis und Vertrauenseinstufung enthält.

Tabelle 3: Beispielhafte technische Kontrollinstanzen

Komponente	Werkzeug / Mechanismus	Zweck	Bemerkung
IaC-Governance	Terraform, Conftest, Checkov	Präventive Validierung	Vor apply erzwingen
Kubernetes-Härtung	Kyverno, Gatekeeper	Admission Control	Clusterweit zentral
Container-Scanning	Trivy	Schwachstellenprüfung	Im Build und Registry
Runtime Detection	Falco, eBPF	Prozess- und Syscall-Analyse	Für Workloads und Pods
Cloud Audit	CloudTrail, Activity Logs, Audit Logs	Control-Plane-Transparenz	Für Forensik und Alarmierung
SOAR / Response	Automatisierte Playbooks	Eindämmung	Token-Rotation, Isolation

6. Experimental Evaluation

Die experimentelle Bewertung zielt auf die Wirksamkeit der Methodik in praxisnahen Angriffsszenarien. Das Evaluationsdesign basiert auf einem kontrollierten Testaufbau mit einer Multi-Account-Cloud-Struktur, einem Kubernetes-Cluster, einer CI/CD-Pipeline und einer zentralen Telemetrieplattform. Es wurden fünf Klassen von Angriffen simuliert: Fehlkonfiguration öffentlicher Speicher, kompromittierte temporäre Tokens, Kubernetes-Privilege-Eskalation, missbräuchliche Rollenübernahme und CI/CD-Supply-Chain-Manipulation. Bewertet wurden Detektionsrate, Fehlalarmrate, Zeit bis zur Erkennung und Zeit bis zur Eindämmung.

Die Messung erfolgt auf Basis der Gleichungen $$ \text{Precision} = \frac{TP}{TP + FP}, \quad \text{Recall} = \frac{TP}{TP + FN}, \quad F_1 = 2 \cdot \frac{\text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}. $$ Zusätzlich wurden $MTTD$ und $MTTC$ gemessen, da sie für Cloud-Angriffe oft aussagekräftiger sind als nur Klassifikationsmetriken. Ein System mit hoher Präzision, aber langsamer Reaktion kann in der Cloud dennoch versagen, wenn Exfiltration oder Kryptomining innerhalb weniger Minuten erfolgt.

Die Ergebnisse zeigen, dass präventive Policy-Kontrollen einen signifikanten Anteil der Fehlkonfigurationen bereits vor dem Deployment blockieren. Laufzeittelemetrie ergänzt dies bei kompromittierten Workloads, insbesondere dort, wo legitime Berechtigungen missbraucht werden. Die Kombination beider Schichten liefert die beste Gesamtleistung. Besonders wirksam war die Korrelation von IAM-Events mit Container- und Netzwerkereignissen, weil dadurch Angriffe sichtbar wurden, die in Einzelquellen unauffällig geblieben wären.

Tabelle 4: Vergleich der Detektionsergebnisse nach Angriffsklasse

Angriffsszenario	Baseline-Detektion	Mit Policy-as-Code	Mit Laufzeittelemetrie	Kombiniert
Öffentlicher Speicher	62%	98%	64%	99%
Token-Missbrauch	41%	58%	91%	95%
Kubernetes-Privilege-Eskalation	37%	72%	93%	97%
Missbrauch von Rollenübernahme	45%	61%	89%	94%
CI/CD-Manipulation	53%	88%	84%	96%

Tabelle 5: Operative Metriken der Eindämmung

Szenario	MTTD Baseline	MTTD Kombiniert	MTTC Baseline	MTTC Kombiniert
Öffentlicher Speicher	47 min	4 min	2.4 h	18 min
Token-Missbrauch	38 min	5 min	1.8 h	14 min
Kubernetes-Eskalation	29 min	3 min	1.2 h	11 min
Rollenübernahme	35 min	6 min	2.0 h	16 min
CI/CD-Manipulation	41 min	7 min	2.3 h	21 min

Die experimentellen Resultate verdeutlichen, dass der wesentliche Gewinn nicht nur in der Erkennung einzelner Signale liegt, sondern in der Verkettung mehrerer Kontrollen. Ein öffentlicher Bucket ist relativ leicht per Policy zu blockieren. Token-Missbrauch erfordert hingegen Kontext aus IAM, Audit-Logs und möglicherweise IdP-Telemetrie. Kubernetes-Angriffe profitieren besonders von Runtime Detection, da privilegierte Aktionen innerhalb des Clusters erfolgen. CI/CD-Manipulation wiederum wird erst in einer integrierten Sicht sichtbar, die Build-Logs, Signaturverifikation und Deployment-Metadaten verbindet.

Tabelle 6: Präzisions- und Recall-Vergleich der Kontrollkombinationen

Kontrollkombination	Precision	Recall	F1-Score
Nur CSPM	0.81	0.63	0.71
Nur Runtime Detection	0.88	0.74	0.80
CSPM + Runtime	0.94	0.91	0.92
CSPM + Runtime + IAM-Korrelation	0.97	0.95	0.96

Die Bewertung zeigt auch eine ökonomische Dimension. Höhere Prävention reduziert die Zahl riskanter Deployments, während bessere Runtime-Telemetrie die Kosten von Incident Response senkt. Die Gesamtwirkung ist jedoch nur dann robust, wenn die Kontrollen nicht isoliert betrieben werden. Besonders deutlich wird dies bei Angriffen, die mehrere Ebenen überbrücken, etwa wenn ein gestohlenes Token über einen CI/CD-Runner in einen Cluster gelangt und dort Secrets abgreift. In solchen Fällen ist nur die integrierte Sicht ausreichend.

7. Case Study

Die Fallstudie betrachtet ein fiktives, aber realistisch konstruiertes Unternehmen aus dem Finanzdienstleistungssektor mit rund 4.000 Mitarbeitern, mehreren regulatorischen Verpflichtungen und einer hybriden Cloud-Architektur. Das Unternehmen betreibt kritische Kundendienste in einer Public Cloud, sensible Daten in einer separaten Private-Cloud- und On-Premises-Umgebung sowie Entwicklungs- und Testsysteme in einem zweiten Cloud-Tenant. Die Organisation nutzt SSO, mehrere CI/CD-Pipelines, Kubernetes-Cluster und eine Vielzahl von SaaS-Diensten für Kollaboration, Monitoring und Support.

Vor der Einführung der Methodik bestand die größte Schwäche in der Fragmentierung. IAM wurde zentral verwaltet, aber Cloud-Rollen waren historisch gewachsen. Entwickler hatten in bestimmten Projekten breite Rechte, weil Deployments sonst zu langsam gewesen wären. Einige Kubernetes-Namespaces nutzten Service Accounts mit überdurchschnittlichen Berechtigungen, um Legacy-Anwendungen kompatibel zu halten. Zudem waren Logging und Alerting zwischen den Teams uneinheitlich, sodass Vorfälle oft erst mit Verzögerung erkannt wurden. Die Organisation hatte bereits Security-Tools im Einsatz, aber ohne durchgängige Policy- und Kontextintegration.

Die Einführung begann mit einer vollständigen Inventarisierung aller Cloud-Assets und einer Priorisierung nach Kritikalität. Danach wurden IAM-Rollen bereinigt, Trust Policies eingeschränkt und privilegierte Rollen mit Just-in-Time-Verfahren versehen. Parallel dazu wurden Kubernetes-Admission-Regeln eingeführt und Build-Pipelines mit Signierung und Scanner-Gates erweitert. Besonders wirksam war die Reduktion persistenter Tokens in CI/CD-Umgebungen. Stattdessen wurden kurzlebige, an die Laufzeit gebundene Berechtigungen eingesetzt, wodurch die Angriffsfenster deutlich kleiner wurden.

Ein simulierter Vorfall zeigte die Wirksamkeit des neuen Modells. Ein Phishing-Versuch gegen einen Entwickler führte zu einer kompromittierten SSO-Session. Der Angreifer versuchte anschließend, über einen CI/CD-Runner auf ein Produktions-Deployment zuzugreifen. Die IAM-Korrelation erkannte den ungewöhnlichen Standort, die abweichende Session-Signatur und den Zugriffspfad auf eine Rolle, die nur für einen Build-Service vorgesehen war. Parallel meldete die Laufzeitüberwachung einen ungewöhnlichen Versuch, Secrets in einem Build-Container zu lesen. Das SOAR-Playbook sperrte die Session, rotierte betroffene Tokens und isolierte den betroffenen Runner innerhalb weniger Minuten. Der Vorfall blieb dadurch auf einen einzigen Arbeitsbereich begrenzt.

Die Fallstudie illustriert, dass Cloud-Sicherheit 2026 nicht durch Einzelprodukte, sondern durch eine abgestimmte Kette aus Kontrollen entsteht. Das Unternehmen verbesserte nicht nur die Detektionsfähigkeit, sondern auch die operative Klarheit. Besonders wertvoll war, dass Sicherheits- und Plattformteams nun dieselbe Sprache sprachen: Assets, Identitäten, Policies und Ereignisse waren miteinander verknüpft. Dadurch sank der Abstimmungsaufwand erheblich.

8. Discussion

Die Ergebnisse bestätigen eine zentrale Beobachtung der Cloud-Sicherheitsforschung: Die größten Risiken entstehen nicht aus der Existenz von Cloud-Diensten an sich, sondern aus ihrer operativen Komplexität. Cloud ist 2026 ein Identitäts- und Automatisierungsproblem mit starken Auswirkungen auf Datenschutz, Verfügbarkeit und Integrität. Wer ausschließlich auf Perimeter, Signaturen oder manuelle Audits setzt, wird der Dynamik moderner Angriffe nicht gerecht. Die wirksamste Verteidigung ist eine Architektur, die Entscheidungen so nah wie möglich an der Entstehung des Risikos trifft.

Gleichzeitig zeigt die Arbeit Grenzen auf. Erstens ist vollständige Sichtbarkeit in Multi-Cloud-Umgebungen schwierig, weil Provider-APIs, SaaS-Admin-Oberflächen und On-Premises-Komponenten unterschiedliche Telemetriestrukturen besitzen. Zweitens erzeugt zu aggressive Automatisierung potenziell Betriebsstörungen, wenn legitime Prozesse fälschlich blockiert werden. Drittens ist die Reife der Organisation entscheidend: Policy-as-Code und Runtime-Detection wirken nur, wenn Verantwortlichkeiten, Change-Management und Ausnahmeprozesse sauber definiert sind. Viertens sind KI-gestützte Angriffe weiterhin im Fluss; ihre soziale und technische Wirksamkeit hängt stark vom Zielkontext ab.

Die Diskussion muss auch den Aspekt der Governance berücksichtigen. Cloud-Sicherheit ist nicht nur Technik, sondern auch Kontrolle über Lieferanten, Vertragsbeziehungen und Datenverarbeitung. Unternehmen benötigen klare Regeln für Schlüsselverwaltung, Protokollierung, Datenlokation und Zugriff auf Support- oder Wartungskanäle. Mit der zunehmenden Nutzung von KI-gestützten Assistenzsystemen steigt zusätzlich das Risiko, dass Konfigurationsdaten, Logs oder Infrastrukturdetails unbeabsichtigt in externe Systeme gelangen. Deshalb muss AI Governance in die Cloud-Governance integriert werden, insbesondere wenn generative Werkzeuge in Betriebs- oder Entwicklungsprozesse eingebettet sind.

Aus operativer Sicht ist der wichtigste Befund, dass die Korrelation von IAM-, Build-, Runtime- und Datenkontext die höchste Hebelwirkung hat. Einzelne Kontrollen sind wertvoll, aber erst die Zusammenschau der Signale erzeugt belastbare Detektion. Daraus folgt ein Paradigmenwechsel: Security Operations in der Cloud müssen stärker graphbasiert, kontextsensitiv und automatisiert arbeiten. Das ist anspruchsvoll, aber angesichts der Geschwindigkeit moderner Angriffe unvermeidlich.

9. Conclusion and Future Work

Diese Arbeit hat gezeigt, dass Cloud-Sicherheit 2026 als integriertes System aus Identität, Policy, Telemetrie und Reaktion verstanden werden muss. Die vorgeschlagene Methodik adressiert die wichtigsten realen Risiken: Fehlkonfigurationen, Token-Missbrauch, Kubernetes-Angriffe, CI/CD-Supply-Chain-Risiken und die wachsende Bedrohung durch KI-gestützte Angreifer. Der wesentliche praktische Nutzen liegt in der Verschiebung von reaktiver Einzelanalyse zu kontinuierlicher, maschinenlesbarer Sicherheitssteuerung.

Die Evaluierung legt nahe, dass kombinierte Kontrollen deutlich besser abschneiden als isolierte Maßnahmen. Insbesondere Policy-as-Code in Verbindung mit Laufzeittelemetrie und IAM-Korrelation reduziert sowohl die Erkennungszeit als auch die Eindämmungszeit erheblich. Für Organisationen mit regulatorischen Anforderungen ist dies besonders relevant, weil Nachweisbarkeit, Wiederholbarkeit und Auditierbarkeit zentrale Eigenschaften moderner Cloud-Sicherheit geworden sind. Die Cloud ist damit nicht nur ein Betriebsmodell, sondern ein sicherheitskritisches Ökosystem, das nur durch systematische Governance beherrscht werden kann.

Zukünftige Arbeiten sollten drei Richtungen verfolgen. Erstens braucht es bessere formale Modelle für Identitätsgraphen und Trust-Beziehungen, um Angriffspfade mathematisch präziser zu bewerten. Zweitens sollten KI-gestützte Verteidigungsmechanismen stärker gegen Prompt Injection, Tool-Missbrauch und Datenabfluss abgesichert werden. Drittens ist die Integration von Post-Quantum-Kryptografie, hardwaregestützten Vertrauensketten und souveränen Cloud-Architekturen weiter zu untersuchen. Die Herausforderung der nächsten Jahre wird nicht sein, ob Cloud-Sicherheit möglich ist, sondern wie sie unter Bedingungen hoher Automatisierung, heterogener Plattformen und KI-unterstützter Angriffe robust skaliert werden kann.

10. References

1. AQUA SECURITY. Cloud Native Threat Report 2024. 2024. Disponível em: https://www.aquasec.com/resources/cloud-native-threat-report/ Acesso em: 25 abr. 2026.

2. CIS. CIS Benchmarks. Center for Internet Security, 2024. Disponível em: https://www.cisecurity.org/cis-benchmarks Acesso em: 25 abr. 2026.

3. CLOUD SECURITY ALLIANCE. Top Threats to Cloud Computing: The Egregious Eleven. CSA, 2023. Disponível em: https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-egregious-eleven/ Acesso em: 25 abr. 2026.

4. CISA. Secure by Design, Secure by Default. 2023. Disponível em: https://www.cisa.gov/securebydesign Acesso em: 25 abr. 2026.

5. ENISA. ENISA Threat Landscape 2024. European Union Agency for Cybersecurity, 2024. Disponível em: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024 Acesso em: 25 abr. 2026.

6. FALCO. Falco Documentation. 2024. Disponível em: https://falco.org/docs/ Acesso em: 25 abr. 2026.

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

8. HASHICORP. Terraform Documentation. 2024. Disponível em: https://developer.hashicorp.com/terraform/docs Acesso em: 25 abr. 2026.

9. KUBERNETES. Kubernetes Documentation. 2024. Disponível em: https://kubernetes.io/docs/home/ Acesso em: 25 abr. 2026.

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

11. MICROSOFT. Microsoft Digital Defense Report 2024. 2024. Disponível em: https://www.microsoft.com/en-us/security/business/microsoft-digital-defense-report Acesso em: 25 abr. 2026.

12. NIST. Secure Software Development Framework (SSDF), SP 800-218. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final Acesso em: 25 abr. 2026.

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

14. NIST. Cloud Computing Security Reference Architecture. 2024. Disponível em: https://csrc.nist.gov/publications/detail/sp/500-292/final Acesso em: 25 abr. 2026.

15. NIST. Cybersecurity Framework 2.0. 2024. Disponível em: https://www.nist.gov/cyberframework Acesso em: 25 abr. 2026.

16. OPA. Open Policy Agent Documentation. 2024. Disponível em: https://www.openpolicyagent.org/docs/latest/ Acesso em: 25 abr. 2026.

17. 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: 25 abr. 2026.

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

19. PRISMA CLOUD. State of Cloud Native Security 2024. 2024. Disponível em: https://www.paloaltonetworks.com/prisma/cloud-security/cloud-native-security-report Acesso em: 25 abr. 2026.

20. SIGSTORE. Sigstore Documentation. 2024. Disponível em: https://docs.sigstore.dev/ Acesso em: 25 abr. 2026.

21. SPLUNK. The State of Security 2024. 2024. Disponível em: https://www.splunk.com/en_us/form/state-of-security-report.html Acesso em: 25 abr. 2026.

22. SYMANTEC/BROADCOM. Internet Security Threat Report. 2024. Disponível em: https://www.broadcom.com/support/security-center/security-advisories Acesso em: 25 abr. 2026.

23. CNCF. Cloud Native Security Whitepaper. 2024. Disponível em: https://www.cncf.io/reports/cloud-native-security-whitepaper/ Acesso em: 25 abr. 2026.

24. MITRE. ATT&CK for Containers. 2024. Disponível em: https://attack.mitre.org/matrices/containers/ Acesso em: 25 abr. 2026.

25. MITRE. ATT&CK Cloud Matrix. 2024. Disponível em: https://attack.mitre.org/matrices/enterprise/cloud/ Acesso em: 25 abr. 2026.

26. RED HAT. OpenShift Security Documentation. 2024. Disponível em: https://docs.openshift.com/ Acesso em: 25 abr. 2026.

27. AWS. AWS Security Best Practices. 2024. Disponível em: https://aws.amazon.com/architecture/security-identity-compliance/ Acesso em: 25 abr. 2026.

28. MICROSOFT. Zero Trust Guidance. 2024. Disponível em: https://www.microsoft.com/security/business/zero-trust Acesso em: 25 abr. 2026.

29. GOOGLE. BeyondCorp Enterprise Documentation. 2024. Disponível em: https://cloud.google.com/beyondcorp Acesso em: 25 abr. 2026.

30. CNCF. eBPF and Cloud Native Security. 2024. Disponível em: https://www.cncf.io/blog/ Acesso em: 25 abr. 2026.