Cloud Security: Risiken, Best Practices und SIEM für die Cloud

Cloud Security definiert die operative Basis moderner Cyberabwehr. Organisationen in ganz Europa migrieren kritische Workloads zu drei Hyperscalern: Amazon Web Services (AWS), Microsoft Azure und Google Cloud. Die Angriffsfläche hat sich von physischen Rechenzentren zu drei neuen Kontrollpunkten verlagert: Identitäten, Application Programming Interfaces (APIs) und als Code definierte Konfigurationen.

Die Bitkom-Studie Wirtschaftsschutz 2025 (Economic Security 2025), präsentiert im September 2025, berichtet, dass 87 % der deutschen Unternehmen im vorangegangenen Jahr Datendiebstahl, Industriespionage oder Sabotage erlebt haben. Der Gesamtschaden erreichte 289,2 Milliarden Euro, ein Anstieg von 8 % gegenüber dem Vorjahr. 202,4 Milliarden Euro dieses Gesamtbetrags (70 %) stammen speziell aus Cyberangriffen. 46 % der betroffenen Unternehmen führen Vorfälle auf Akteure aus Russland zurück, weitere 46 % auf Akteure aus China.

Dieser Artikel definiert Cloud Security, listet die wichtigsten Risiken im Jahr 2026 auf, erklärt die Best Practices zur Reduzierung der Exposition und zeigt, wie eine für die Cloud konzipierte Security Information and Event Management (SIEM)-Plattform Bedrohungen erkennt und eindämmt. Drei regulatorische Frameworks bilden die Analyse: die NIS2-Richtlinie, das BSI Cloud Computing Compliance Criteria Catalogue (C5:2026) und das European Cybersecurity Certification Scheme for Cloud Services (EUCS).

Was ist Cloud Security?

Cloud Security ist die Kombination aus Richtlinien, Kontrollen, Prozessen und Technologien, die Daten, Workloads, Identitäten und Infrastruktur in öffentlichen, privaten, hybriden oder Multi-Cloud-Umgebungen schützen. Cloud Security operiert als kontinuierlicher Lebenszyklus, der fünf Phasen umfasst: Architekturplanung, Konfiguration und Deployment, laufende Überwachung, Incident Response und Provider-Exit.

Drei Eigenschaften trennen Cloud Security von traditioneller On-Premises-Informationssicherheit:

• Der Perimeter hat sich aufgelöst. Workloads laufen auf Infrastruktur, die mit anderen Mietern geteilt wird. Die physische Grenze, die Firewalls früher verteidigten, existiert in der Public Cloud nicht mehr.
• Die Schutzeinheit hat sich von Servern zu Identitäten und Konfigurationen verlagert. Eine zu permissive Identity and Access Management (IAM)-Rolle oder ein falsch konfigurierter Storage-Bucket setzt innerhalb von Minuten Terabytes an Daten frei.
• Sicherheitsverantwortung ist geteilt. Der Cloud-Provider sichert die Cloud (physische Infrastruktur, Hypervisor, Managed-Service-Plane). Der Kunde sichert Workloads in der Cloud (Datenklassifizierung, Identität, Netzwerkkonfiguration, Anwendungslogik und Protokollierung).

Das falsche Lesen der Shared-Responsibility-Grenze zwischen Provider- und Kundenpflichten verursacht einen hohen Anteil an Cloud-Datenpannen.

Wie funktioniert Sicherheit in Cloud-Umgebungen?

Sicherheit in Cloud-Umgebungen basiert auf API-Ereignissen, nicht auf physischen Netzwerklogs. Jede bedeutsame Aktion – eine virtuelle Maschine erstellen, eine Firewall-Regel ändern, eine Berechtigung gewähren oder auf ein Storage-Objekt zugreifen – wird als API-Aufruf ausgeführt. Der Audit-Trail dieser API-Aufrufe bildet die Single Source of Truth für die Cloud-Erkennung.

Drei Plattformen produzieren den Großteil der Cloud-Security-Telemetrie: AWS CloudTrail, Azure Activity Logs kombiniert mit Microsoft Entra ID-Anmeldelogs und Google Cloud Audit Logs. Ein moderner Security-Betrieb speist alle drei in ein zentrales SIEM zur Korrelation ein.

Cloud Security funktioniert als kontinuierlicher Kontrollkreislauf über fünf Schichten:

• Identity and Access Management (IAM). Legt fest, wer – Mensch oder Maschine – welche Aktion auf welcher Ressource ausführen kann. Effektives IAM nutzt kurzlebige Anmeldedaten, phishing-resistente Multi-Faktor-Authentifizierung (MFA) und das Prinzip der geringsten Berechtigung.
• Konfiguration und Posture. Stellt sicher, dass jede Ressource von Beginn an sicher bereitgestellt wird durch Infrastructure as Code (IaC), und bewertet den deployed Zustand kontinuierlich gegen die CIS Foundations Benchmarks für AWS, Azure und Google Cloud.
• Datenschutz. Umfasst Verschlüsselung während der Übertragung, im Ruhezustand und in Verwendung (Confidential Computing), zusammen mit Klassifizierung, Key Management und Data Loss Prevention.
• Workload- und Netzwerksicherheit. Schützt virtuelle Maschinen, Container und serverlose Funktionen sowie die virtuellen Netzwerke, die sie durch Segmentierung, Runtime-Schutz und Vulnerability Management verbinden.
• Erkennung und Reaktion. Konsolidiert IAM-, Konfigurations-, Daten- und Workload-Telemetrie in einem SIEM, korreliert die Daten mit Threat Intelligence und Verhaltensanalytik und treibt automatisierte Eindämmung durch Security Orchestration, Automation, and Response (SOAR)-Playbooks voran.

Der deutsche Markt verstärkt dieses Fünf-Schichten-Modell durch das BSI-IT-Grundschutz-Kompendium. Modul OPS.2.2 Cloud-Nutzung definiert die Prinzipien für Planung, Betrieb und Beendigung einer Cloud-Provider-Beziehung. Modul DER.1 Erkennen sicherheitsrelevanter Ereignisse schreibt SIEM-Fähigkeiten für Betreiber kritischer Infrastruktur (KRITIS – Kritische Infrastrukturen) vor.

Was sind die Hauptrisiken in der Cloud Security?

Die Hauptrisiken in der Cloud Security clustern sich in vier Kategorien: Konfigurationsfehler, Identitätskompromittierung, Software-Supply-Chain-Fehler und unzureichende Protokollierung. Das Open Worldwide Application Security Project (OWASP) Top 10 für 2025, angekündigt bei OWASP Global AppSec im November 2025 und kurz danach finalisiert, bestätigt dieses Ranking durch Analyse von mehr als 175.000 Common Vulnerabilities and Exposures (CVE)-Datensätzen.

Drei strukturelle Verschiebungen im OWASP Top 10:2025 sind für Cloud-Umgebungen am bedeutsamsten:

• A01 Broken Access Control hält für den vierten aufeinanderfolgenden Zyklus die erste Position. Die Kategorie absorbiert nun Server-Side Request Forgery (SSRF). 3,73 % der getesteten Anwendungen haben mindestens eine von 40 Common Weakness Enumerations (CWEs) in dieser Kategorie.
• A02 Security Misconfiguration ist von Position fünf im Jahr 2021 auf Position zwei im Jahr 2025 gestiegen. Modernes Anwendungsverhalten hängt mehr von der Umgebungskonfiguration als vom Code ab.
• A03 Software Supply Chain Failures ist als neue Kategorie in die Liste eingetreten, erweitert aus dem 2021-Eintrag „Vulnerable and Outdated Components.” Die neue Kategorie umfasst Drittanbieter-Abhängigkeiten, Build-Systeme, Continuous Integration / Continuous Deployment (CI/CD)-Pipelines und Update-Mechanismen.

Vier Risikokategorien definieren die Cloud-Security-Exposition im Jahr 2026: Fehlkonfigurationen, IAM-Kompromittierung, Supply-Chain-Fehler und Protokollierungsschwächen.

Wie führen Fehlkonfigurationen zu Datenverlust in der Cloud?

Fehlkonfigurationen führen durch fünf häufige Muster zu Datenverlust in der Cloud. Eine Fehlkonfiguration ist jede Abweichung zwischen dem beabsichtigten sicheren Zustand einer Cloud-Ressource und ihrem deployed Zustand. Cloud-Fehlkonfigurationen verbreiten sich mit Maschinengeschwindigkeit, weil ein Infrastructure-as-Code-Template, das auf Hunderte von Konten angewendet wird, eine gesamte Flotte innerhalb von Minuten exponiert.

Die fünf folgenreichsten Fehlkonfigurationsmuster sind:

• Öffentlich exponierter Storage. S3-Buckets, Azure Blob-Container oder Google Cloud Storage (GCS)-Buckets, die für das Internet geöffnet sind. Entwickler ändern häufig eine Zugriffseinstellung zum Debuggen eines Problems und setzen sie nie zurück. Automatisierte Scanner, die von Forschern und Kriminellen betrieben werden, entdecken diese Expositionen innerhalb von Stunden.
• Standard- und nicht rotierte Anmeldedaten. Service-Accounts, API-Keys oder administrative Konsolen, die auf Standardwerten gehalten werden, in Quellcode hardcodiert sind oder in Repositories zurückgelassen wurden, nachdem der ursprüngliche Entwickler weitergezogen ist.
• Übermäßig permissive Netzwerkregeln. Security Groups und virtuelle Netzwerkregeln, die Management-Ports für 0.0.0.0/0 öffnen. Drei Protokollfamilien tauchen am häufigsten auf: Secure Shell (SSH, Port 22), Remote Desktop Protocol (RDP, Port 3389) und Datenbankports (3306 für MySQL, 5432 für PostgreSQL, 1433 für Microsoft SQL Server).
• Unverschlüsselte Daten und schwaches Key Management. Verschlüsselung auf Storage-Volumes oder Datenbanken deaktiviert, kundenverwaltete Keys nicht rotiert oder sensible Parameter in einfachen Umgebungsvariablen statt in einem Secrets Manager gespeichert.
• Deaktivierte Protokollierung. AWS CloudTrail, Azure Diagnostic Settings oder Google Cloud Audit Logs in einem Nicht-Produktionskonto deaktiviert, das später in die Produktion übergeht und einen dauerhaften Blindspot für Ermittler erzeugt.

Diese fünf Fehler kombinieren sich zur Standard-Cloud-Breach-Kette. Ein Angreifer scannt nach der exponierten Fehlkonfiguration, nutzt Standard-Anmeldedaten oder einen ungepatchten Dienst, eskaliert Berechtigungen durch eine zu permissive IAM-Rolle und exfiltriert Daten durch einen Pfad ohne Protokollierung. Der BSI C5:2026-Katalog erhöht die Anforderungen an Multi-Tenancy-Isolation, Container-Orchestrierungs-Controls und Supply-Chain-Verifizierung – die Konfigurationsoberflächen, wo moderne Angriffe beginnen.

Was sind die häufigsten Bedrohungen für Identity and Access Management (IAM)?

Die sechs häufigsten Bedrohungen für Identity and Access Management (IAM) in der Cloud sind Credential-Diebstahl, Token-Hijacking, Rechteeskalation, Non-Human-Identity-Missbrauch, SSRF-Metadata-Missbrauch und Dormant-Identity-Reaktivierung. IAM kontrolliert alle Zugriffe in Cloud-Umgebungen. Der Rest des Sicherheits-Stacks wird sekundär, sobald ein Angreifer gültige Anmeldedaten, menschlich oder maschinell, besitzt.

Jede Bedrohung entspricht einer spezifischen MITRE-ATT&CK-Technik:

• Credential-Diebstahl via Phishing und Infostealers. Benutzer geben Anmeldedaten auf gefälschten Login-Seiten ein, oder Malware extrahiert gespeicherte Session-Cookies aus Browsern und umgeht damit die Multi-Faktor-Authentifizierung vollständig. MITRE ATT&CK: T1078 Valid Accounts, T1539 Steal Web Session Cookie.
• Token- und Session-Hijacking. Langlebige OAuth-Tokens, Refresh-Tokens oder Cloud Command Line Interface (CLI)-Session-Dateien, die von einer Entwickler-Workstation kopiert und aus einer angreifergesteuerten Umgebung wiedergegeben werden.
• Rechteeskalation durch IAM-Missbrauch. Ein Angreifer mit begrenztem Zugang nutzt schwach definierte Rollen, Trust Policies oder Pass-Role-Berechtigungen, um eine privilegierte Rolle anzunehmen. Rechteeskalation durch IAM-Missbrauch gehört zu den häufigsten Eskalationspfaden in AWS-Umgebungen.
• Non-Human-Identity-Missbrauch. Service-Accounts, CI/CD-Runner, Kubernetes-Service-Tokens und Managed Identities haben breite Berechtigungen und nutzen selten MFA. Non-Human Identities sind zu einer der Zielkategorien mit dem höchsten Wert bei Cloud-Einbrüchen geworden.
• SSRF und Metadata-Service-Missbrauch. Anfällige Anwendungen rufen interne Metadaten-Endpunkte auf (zum Beispiel 169.254.169.254 auf AWS EC2) und extrahieren Instance-Anmeldedaten, was eine schnelle Rechteeskalation über das Konto ermöglicht.
• Dormant-Identity-Reaktivierung. Ehemalige Mitarbeiter, außer Betrieb genommene Service-Accounts oder Testbenutzer, die im Verzeichnis aktiviert und Monate später wiederverwendet werden.

IAM-Hygiene, die sich gegen diese Bedrohungen verteidigt, kombiniert fünf Praktiken: kurzlebige Anmeldedaten (Federated Single Sign-On, Workload Identity Federation, IAM Roles Anywhere), Phishing-resistente MFA, Just-in-Time Privileged Access, kontinuierliche Überprüfung der Berechtigungsnutzung versus Berechtigungsgewährung und Verhaltensanalytik, die Identitäten markiert, die außerhalb des normalen Musters operieren. Verhaltensanalytik bildet die Grundlage von User and Entity Behavior Analytics (UEBA).

Was sind die Best Practices für Cloud Security?

Best Practices in Cloud Security folgen einem Betriebsprinzip: nichts über Standardkonfigurationen annehmen und jede Ressource kontinuierlich verifizieren. Der deutsche Markt übersetzt dieses Prinzip durch drei überlappende Frameworks: BSI IT-Grundschutz für Risikomanagement, die CIS Benchmarks für technisches Hardening und BSI C5:2026 für Cloud-Provider-Attestierung.

Sieben Kernpraktiken reduzieren das Cloud-Risiko über AWS, Azure und Google Cloud hinweg:

• Geringste Berechtigung für jede Identität anwenden, menschlich und nicht-menschlich, mit vierteljährlichen Zugriffsüberprüfungen und automatischer Deprovisionierung.
• Konfiguration als Code behandeln. Jedes Infrastructure-as-Code-Template versionskontrollieren, Pre-Deployment-Sicherheitsscans durchführen und Pull Requests ablehnen, die Baseline-Richtlinien verletzen.
• Deployed Posture kontinuierlich gegen die CIS Foundations Benchmarks für AWS, Azure und Google Cloud bewerten, durch ein Cloud Security Posture Management (CSPM)-Tool.
• Daten im Ruhezustand, während der Übertragung und in Verwendung verschlüsseln. Keys in dedizierten Key Management Services (KMS) mit kundenverwalteten Rotationsrichtlinien verwalten.
• Audit- und Sicherheitslogs in einem SIEM zentralisieren mit ausreichender Aufbewahrung zur Erfüllung der NIS2-Berichtsfristen und der DSGVO-Datenminimiierungsprinzipien.
• Reaktion auf hochvolumige, gut verstandene Vorfallmuster durch SOAR-Playbooks automatisieren. Menschliche Analysten für neuartige Bedrohungen vorbehalten.
• Provider-Exit planen. Definieren, wie Daten, Logs und Konfigurationen übertragen, gelöscht und verifiziert werden, wenn der Provider gewechselt wird. BSI-Modul OPS.2.2 erzwingt diese Anforderung.

Wie schützt Cloud Security Posture Management (CSPM) Daten?

Cloud Security Posture Management (CSPM) schützt Daten durch fünf Mechanismen: Asset-Discovery, Konfigurationsbewertung, Compliance-Mapping, Angriffspfad-Analyse und automatisierte Behebung. CSPM-Tools verbinden sich mit Provider-APIs – AWS Config, Azure Resource Graph und Google Cloud Asset Inventory – und bewerten jede Ressource gegen Richtlinien, die aus den CIS Benchmarks, Cloud-Provider-Well-Architected-Guidance und regulatorischen Frameworks einschließlich BSI C5 abgeleitet sind.

Die fünf CSPM-Mechanismen funktionieren wie folgt:

• Asset-Discovery. CSPM produziert ein kontinuierlich aktualisiertes Inventar jedes Storage-Buckets, jeder Datenbank, jeder virtuellen Maschine, jedes Container-Clusters, jeder Funktion und Identität über alle Konten und Regionen hinweg. Asset-Discovery eliminiert Shadow Cloud, wo Teams Ressourcen außerhalb der zentralen Sichtbarkeit bereitstellen.
• Konfigurationsbewertung. CSPM bewertet jedes Asset gegen Baseline-Richtlinien – „S3-Buckets dürfen nicht öffentlich lesbar sein”, „Datenbanken müssen Verschlüsselung im Ruhezustand aktivieren”, „IAM-Benutzer müssen MFA aktivieren” – und produziert eine priorisierte Liste von Verstößen.
• Compliance-Mapping. CSPM übersetzt rohe Befunde in Audit-Sprache. Jeder Verstoß wird seinem entsprechenden Control in ISO/IEC 27001:2022, BSI C5:2026, dem CIS Controls v8 Cloud Companion Guide, DSGVO und NIS2 zugeordnet.
• Angriffspfad-Analyse. Moderne CSPM-Plattformen verbinden Identitäts-, Netzwerk-, Schwachstellen- und Datenbefunde in einem Graph. Der Graph zeigt zum Beispiel, dass eine öffentlich zugängliche virtuelle Maschine mit einer bekannten Schwachstelle eine Rolle mit vollem Zugriff auf einen Kundendaten-Bucket annimmt – die Kette, die ein Angreifer ausnutzt.
• Automatisierte Behebung. Für gut definierte Verstöße (öffentlicher Storage, fehlende Verschlüsselung, deaktivierte Protokollierung) wenden CSPM-Plattformen die Korrektur durch die Provider-API an oder öffnen ein Ticket und einen Pull Request gegen das IaC-Repository. Das zugrunde liegende Template wird korrigiert, nicht nur die deployed Ressource.

CSPM ist eine kontinuierliche Pflicht, kein einmaliges Audit. Unter NIS2 tragen Leitungsorgane persönliche Haftung für die laufende Aufsicht über Cybersicherheitsmaßnahmen. Vorfälle müssen das BSI innerhalb enger Berichtsfristen erreichen. Ein täglicher oder stündlicher Posture-Scan, der in das SIEM integriert ist, erfüllt diese Pflicht über einen Bestand mit Tausenden von Ressourcen.

Warum ist die Einhaltung gesetzlicher Vorschriften wichtig?

Die Einhaltung gesetzlicher Vorschriften ist wichtig, weil Nichteinhaltung nun direkte finanzielle, persönliche und operative Konsequenzen für Leitungsorgane produziert, nicht nur für IT-Teams. Drei Frameworks definieren die Cloud-Compliance-Landschaft in Deutschland und der Europäischen Union im Jahr 2026.

NIS2-Richtlinie (NIS2UmsuCG in Deutschland). Die NIS2-Richtlinie ist formal die Richtlinie (EU) 2022/2555 über Netz- und Informationssicherheit. Das deutsche Umsetzungsgesetz, das NIS2UmsuCG, passierte den Bundesrat am 21. November 2025, trat am 5. Dezember 2025 in das Bundesgesetzblatt ein und trat am 6. Dezember 2025 ohne Übergangsfrist in Kraft. Das Gesetz gilt für rund 29.500 Einrichtungen. Der Schwellenwert-Test ist einfach: mehr als 50 Mitarbeiter oder ein Jahresumsatz über 10 Millionen Euro. Zu den erfassten Sektoren gehören kritische Infrastruktur, Anbieter digitaler Infrastruktur, Hersteller von Medizinprodukten und Maschinen, Abfallentsorgungsunternehmen sowie Lebensmittel- und Chemieunternehmen. Strafen erreichen 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen und 7 Millionen Euro oder 1,4 % für wichtige Einrichtungen. Mitglieder von Leitungsorganen tragen persönliche Haftung bei Versäumnis der Aufsicht über Cybersicherheitsmaßnahmen. Die Registrierung beim BSI ist innerhalb von drei Monaten nach Inkrafttreten verpflichtend.

BSI C5:2026. Der Cloud Computing Compliance Criteria Catalogue dient als de facto Attestierungsstandard für jeden Cloud-Provider, der mit der deutschen Bundesverwaltung zusammenarbeitet. BSI veröffentlichte die C5:2026-Endversion am 7. April 2026 und ersetzte damit C5:2020. Die Anzahl der Audit-Kriterien wuchs von 121 in C5:2020 auf 168 Kriterien in 17 Themenbereichen in C5:2026. Die neue Ausgabe führt explizite Controls für fünf neue Bereiche ein: Container-Orchestrierung, Post-Quanten-Kryptografie, Confidential Computing, Supply-Chain-Sicherheit und Multi-Tenant-Trennung. C5:2026 ist auf ISO/IEC 27001:2022, das Cloud Security Alliance Cloud Controls Matrix v4 (CSA CCM v4) und NIS2 abgestimmt. Typ-2-Prüfperioden, die am oder nach dem 1. Juni 2027 beginnen, müssen C5:2026 anwenden.

EUCS und der EU Cybersecurity Act. Das European Cybersecurity Certification Scheme for Cloud Services, entwickelt von der Europäischen Agentur für Cybersicherheit (ENISA) im Rahmen des Cybersecurity Act, bleibt formal freiwillig. NIS2 und der EU Data Act geben den Mitgliedstaaten die Befugnis, öffentliche Einrichtungen und kritische Infrastruktur zu verpflichten, EUCS-zertifizierte Provider zu nutzen.

Die DSGVO gilt für jede Log-Zeile, die personenbezogene Daten enthält. In einem Sicherheitskontext umfassen personenbezogene Daten IP-Adressen, Benutzernamen und die meiste Authentifizierungstelemetrie. Ein DSGVO-konformes Cloud-SIEM erzwingt drei Controls: Aufbewahrungsfristen (typischerweise zwölf Monate für Sicherheitslogs, gerechtfertigt durch dokumentierten Zweck), starke Verschlüsselung und rollenbasierter Zugriff auf Log-Daten.

Wie verbessert SIEM die Cloud Security?

SIEM verbessert die Cloud Security auf vier konkrete Arten: Telemetrie-Konsolidierung, Ereignisanreicherung, Verhaltensanalytik und automatisierte Reaktion. Ein SIEM sammelt Telemetrie aus fünf Schichten – Identität, Netzwerk, Workload, Anwendung und Software as a Service (SaaS) – normalisiert die Daten in ein gemeinsames Modell, korreliert Ereignisse aus Quellen, wendet Erkennungsregeln und maschinelles Lernen an und präsentiert priorisierte Alarme für Sicherheitsanalysten.

Die vier Verbesserungsbereiche funktionieren wie folgt:

• Telemetrie-Konsolidierung. Ein SIEM führt fragmentierte Telemetrie von mehreren Cloud-Providern und SaaS-Anwendungen auf einer einzigen Untersuchungsoberfläche zusammen. Analysten hören auf, zwischen fünf Konsolen zu wechseln, um einen Vorfall zu verfolgen.
• Ereignisanreicherung. Das SIEM fügt Threat Intelligence, Geolokalisierung, Asset-Kritikalität und Benutzeridentitätskontext zu Rohereignissen hinzu. Ein anonymer API-Aufruf wird zu einem kontextualisierten Ereignis mit Attribution.
• Verhaltensanalytik. User and Entity Behavior Analytics (UEBA) erkennt Anomalien, die signaturbasierte Tools übersehen: Impossible Travel zwischen weit entfernten Städten, Reaktivierung ruhender Konten oder Service-Accounts, die auf unbekannte Ressourcen zugreifen.
• Automatisierte Reaktion. Das SIEM integriert sich mit SOAR-Playbooks, um Eindämmungsschritte zu automatisieren, die kein menschliches Urteil erfordern. Die Reaktionszeit verdichtet sich von Stunden auf Sekunden.

Gemessene Änderungen in der Angreifergeschwindigkeit bestätigen den Wert der automatisierten Reaktion. Unit 42 (Palo Alto Networks) berichtet, dass das schnellste Quartil der Einbrüche im Jahr 2025 die Datenexfiltration innerhalb von 72 Minuten erreichte, gegenüber 285 Minuten im Jahr 2024. CrowdStrikes Global Threat Report 2026 misst die durchschnittliche eCrime-Breakout-Zeit mit 29 Minuten. SIEM-Plattformen, die Alarme ausgeben, ohne Eindämmung auszulösen, können mit modernem Angreifer-Tooling nicht mithalten.

Wie erkennt Cloud SIEM Bedrohungen in Echtzeit?

Cloud SIEM erkennt Bedrohungen in Echtzeit durch drei engineerte Stufen: latenzarme Ingestion, geschichtete Analytik und automatisierte Reaktion. Die drei Stufen operieren als eine kontinuierliche Pipeline, gemessen in Sekunden, nicht in Minuten.

Ingestion-Stufe. Jeder große Cloud-Provider exponiert eine Streaming-Audit-Pipeline, die ein modernes SIEM abonniert:

• AWS CloudTrail liefert Management Events, Data Events und Insights Events über Amazon S3 mit Amazon Simple Queue Service (SQS)-Benachrichtigungen oder direkt über Amazon EventBridge.
• Azure Activity Logs und Microsoft Entra ID-Anmeldelogs streamen über Azure Event Hubs in kompatible SIEM-Plattformen.
• Google Cloud Audit Logs – Admin Activity, Data Access, System Event und Policy Denied – fließen über Google Cloud Pub/Sub in eine kompatible SIEM-Plattform für zentrale Analyse.

AWS CloudTrail Lake nimmt Aktivitätsereignisse aus Nicht-AWS-Quellen auf, einschließlich Microsoft Azure, und ermöglicht so einen einheitlichen Untersuchungsspeicher über Provider hinweg.

Analytik-Stufe. Ein Cloud-SIEM führt drei Analyselayer parallel aus:

• Signatur- und regelbasierte Erkennung. Explizite Regeln verwenden die Abfragesprache der Plattform; das anbieterunabhängige Sigma-Format kompiliert für jede große SIEM-Plattform und bewahrt Erkennungslogik über Plattformwechsel. Regeln kodieren MITRE-ATT&CK-Techniken: fehlgeschlagene Login-Bursts (T1110 Brute Force), verdächtige Rollenannahme (T1078 Valid Accounts) und Discovery-Aktivität gegen IAM-APIs (T1087, T1069).
• UEBA und maschinelles Lernen. Die Engine erstellt über mehrere Wochen eine Verhaltensbasis für jeden Benutzer und jede Workload-Identität. Dann bewertet die Engine Abweichungen: Impossible Travel zwischen weit entfernten Anmeldungen, Reaktivierung ruhender Identitäten, Service-Accounts, die unbekannte APIs aufrufen, oder Manager, die ungewöhnliche Dateimengen herunterladen. UEBA erkennt Credential-Diebstahl, wenn die Anmeldedaten selbst technisch gültig bleiben.
• Threat-Intelligence-Korrelation. Das SIEM überprüft jede beobachtete IP-Adresse, jede beobachtete Domain, jeden Datei-Hash und jedes Zertifikat gegen Threat-Intelligence-Feeds von BSI-Advisories, ENISA-Bulletins und kommerziellen Providern und reichert Alarme mit Attributionskontext an.

Reaktionsstufe. Ein SOAR-Playbook führt die Eindämmung automatisch aus, sobald ein Alarm einen definierten Risikoschwellenwert überschreitet. Das Playbook führt fünf Aktionen durch: eine Microsoft-Entra-ID-Session widerrufen, einen kompromittierten AWS-Access-Key deaktivieren, eine Azure-VM durch Microsoft Defender for Cloud isolieren, einen Indicator of Compromise an der Cloud-Firewall blockieren und ein Ticket mit angefügtem angereichertem Kontext öffnen.

Was sind die Unterschiede zwischen Cloud-SIEM und On-Premises-SIEM?

On-Premises-SIEM und Cloud-SIEM teilen einen Zweck – erfassen, korrelieren und alarmieren – aber operieren in unterschiedlichen Umgebungen. Traditionelles SIEM wurde für endliche Logs von Firewalls, Servern und Netzwerkgeräten innerhalb eines kontrollierten Perimeters konzipiert. Cloud-native SIEM wurde für Millionen kurzlebiger API-Ereignisse pro Sekunde konzipiert, die von Workloads generiert werden, die nur Minuten existieren.

Gartner trennt Cloud-gehostetes SIEM (Legacy-Produkte, die auf virtuellen Maschinen in einem Cloud-Account installiert sind) von Cloud-nativem SIEM (Plattformen, die für serverlose Ingestion, verteilte Data Lakes und elastisches Computing architekturiert sind). Cloud-gehostetes SIEM behält die Skalierungs- und Preisbeschränkungen seiner On-Premises-Herkunft. Cloud-native SIEM beseitigt diese Beschränkungen, führt aber seine eigene Ingestion-Ökonomie ein.

Sicherheitsverantwortliche (CISOs) in der DACH-Region (Deutschland, Österreich, Schweiz) berichten, dass SIEM-Verlängerungen in den Jahren 2025-2026 ein kritischer Druckpunkt sind. Kommerzielle Plattformen berechnen nach Events per Second (EPS) oder Ingestion-Volumen (GB/Tag). Kubernetes und Microservices generieren Größenordnungen mehr Log-Daten als On-Premises-Monolithen. Organisationen erleben häufig, dass SIEM-Rechnungen sich innerhalb eines Vertragszyklus verdoppeln, während die nominale Kapazität konstant bleibt. Der Druck, innerhalb von EPS-Obergrenzen zu bleiben, veranlasst Teams, ganze Log-Quellen stillschweigend zu verwerfen und damit Audit-Blindspots zu erzeugen.

Deutsche Mittelstands- und Enterprise-Sicherheitsteams setzen zunehmend auf hybride Architekturen. Erkennungsregeln verwenden das anbieterunabhängige Sigma-Format und leben in Git, was die Kompilierung in die Abfragesprache jedes aktuellen oder zukünftigen SIEM ermöglicht. Open-Source-SIEM- und Analytik-Engines verarbeiten einen Teil der Ingestion und Analytik. Kommerzielle oder Open-Source-SOAR-Plattformen orchestrieren die Reaktion. Diese Entkopplung bewahrt die Option, den Anbieter zu wechseln, ohne zweitausend Erkennungsregeln neu zu schreiben – die größten versteckten Kosten von Legacy-SIEM.

Was sind die Deployment-Modelle für Cloud-SIEM?

Vier Deployment-Modelle decken Cloud-SIEM-Implementierungen ab: SaaS-Cloud-natives SIEM, Cloud-gehostetes SIEM im Kundenmandanten, Hybrid-SIEM und Managed Detection and Response (MDR) mit einem souveränen SIEM. Die Wahl hängt von drei Faktoren ab: regulatorischen Einschränkungen, bestehender Infrastruktur und Größe des Sicherheitsteams.

• Software as a Service (SaaS) Cloud-native SIEM. Der Provider betreibt die gesamte Plattform. Der Kunde verbindet Log-Quellen, schreibt Erkennungsregeln und empfängt Alarme. Der operative Aufwand ist am geringsten, und die Time-to-Value ist am schnellsten. Die Datenresidenz hängt von den regionalen Angeboten des Providers ab – eine kritische Überlegung unter der DSGVO und der EUCS.
• Cloud-gehostetes SIEM im Kundenmandanten. Ein traditionelles SIEM-Produkt läuft auf virtuellen Maschinen innerhalb des eigenen AWS-, Azure- oder Google-Cloud-Kontos der Organisation. Der Kunde behält die volle Datenkontrolle und fixiert Storage auf bestimmte Regionen. Der Kunde akzeptiert die operative Last von Patching, Skalierung und Hochverfügbarkeit. Dieses Modell passt, wenn Compliance erfordert, dass Daten innerhalb einer bestimmten nationalen Jurisdiktion bleiben.
• Hybrid-SIEM. Telemetrieerfassung läuft in drei Umgebungen – On-Premises-Collector, Cloud-native Ingestion-Pipelines und SaaS-Konnektoren – und konsolidiert entweder in einer zentralisierten SaaS-Plattform oder in einem selbst gehosteten Analytik-Tier. Diese Konfiguration dominiert mittelgroße deutsche Organisationen, die erhebliche On-Premises-Estates neben Cloud-Workloads betreiben. Hybrid-SIEM passt zu Einrichtungen, die sowohl den NIS2 als auch den sektorspezifischen KRITIS-Anforderungen unterliegen.
• Managed Detection and Response (MDR) mit einem souveränen SIEM. Ein externer MDR-Provider betreibt das SIEM, das Security Operations Center (SOC) und die Reaktions-Playbooks im Auftrag des Kunden. Die Plattform befindet sich innerhalb eines europäischen Rechenzentrums, um Datensouveränitätsanforderungen zu erfüllen. MDR-Adoption ist in der DACH-Region unter zwei Drücken schnell gewachsen: dem Cybersicherheitsfachkräftemangel und den NIS2-Bestimmungen zur persönlichen Haftung. Eine dokumentierte MDR-Partnerschaft gibt Leitungsorganen eine verteidigbare Audit-Spur der Sorgfalt.

Zusammenfassung: Cloud Security, Risiken, Best Practices und SIEM für die Cloud

Cloud Security im Jahr 2026 definiert das Betriebsmodell für jede digital aktivierte Organisation in Deutschland und der Europäischen Union. Drei Kräfte treiben die Verschiebung: Identität, Konfiguration und API-Telemetrie bilden nun die primäre Risikofläche; NIS2, BSI C5:2026 und EUCS treten als verbindliche Compliance-Frameworks in Kraft; und 87 % der deutschen Unternehmen berichten über Vorfälle, während das schnellste Quartil der Einbrüche die Datenexfiltration in 72 Minuten erreicht.

Das Risikobild in der Cloud Security clustert sich in vier Kategorien. Broken Access Control, Security Misconfiguration und Software Supply Chain Failures belegen die ersten drei Positionen im OWASP Top 10 für 2025. Protokollierungs- und Erkennungsblindspots vervollständigen die vier. Fehlkonfigurationen (öffentlicher Storage, Standard-Anmeldedaten, übermäßig permissive Netzwerkregeln) verwandeln kleine operative Fehler in Headline-Datenpannen. IAM-Kompromittierung durch Phishing, Token-Diebstahl, SSRF und Non-Human-Identity-Missbrauch verwandelt ein gestohlenes Credential in eine vollständige Kontoübernahme.

Cloud-Security-Best-Practices kombinieren sieben Elemente: Least-Privilege-Identität, Konfiguration-als-Code mit kontinuierlicher CSPM-Bewertung gegen die CIS Benchmarks, Verschlüsselung in jeder Schicht einschließlich in Verwendung, zentralisierte Protokollierung mit NIS2- und DSGVO-konformer Aufbewahrung, automatisierte Reaktion durch SOAR, Provider-Exit-Planung und kontinuierliche Beweissammlung.

SIEM operationalisiert Cloud Security mit der Geschwindigkeit, die Cloud-Angriffe verlangen. Ein cloud-natives SIEM nimmt AWS CloudTrail, Azure Activity Logs, Microsoft Entra ID-Anmeldelogs und Google Cloud Audit Logs in großem Maßstab auf. Das SIEM korreliert Ereignisse durch regelbasierte Erkennung, UEBA und Threat Intelligence. Das SIEM treibt automatisierte Eindämmung durch SOAR voran. Die Wahl zwischen vier Deployment-Modellen – SaaS, Cloud-gehostet, hybrid und MDR – spiegelt eine Souveränitäts- und Betriebsentscheidung wider, nicht nur eine technische.

Das Betriebsprinzip von Cloud Security, Risiken, Best Practices und SIEM für die Cloud lässt sich auf eines reduzieren: kontinuierliche, identitätszentrierte, evidenzbasierte Verteidigung, unterstützt von einem für die Cloud konzipierten SIEM, das auf NIS2, BSI C5:2026 und EUCS abgestimmt ist.