Cloud analysen: Erkennung von Angreifern, die gültige Anmeldedaten verwenden

Die schwerwiegendsten cloud der letzten zwei Jahre begannen nicht mit malware. Sie begannen mit einer Anmeldung. Die Angreifer verfügten über gültige Anmeldedaten oder autorisierte OAuth-Token, führten korrekt formatierte Aufrufe an legitime Anwendungsprogrammierschnittstellen (APIs) durch und hinterließen keine fehlerhaften Daten, die eine Signatur hätte abgleichen können. Genau auf diese Realität geht cloud ein. Dieser Leitfaden definiert den Begriff präzise, erklärt die Funktionsweise der Analyse-Pipeline, erläutert anhand von zwei typischen Sicherheitsvorfällen, warum Signaturen versagen, und zeigt die praktische Umsetzung bei Amazon Web Services (AWS), Azure und Google Cloud auf Cloud einschließlich der Telemetrie-Ökonomie und der Rahmenbedingungen, die in den meisten Erklärungen außer Acht gelassen werden.

Was versteht man unter cloud Sicherheitsanalysen?

Cloud werden Erkennungsanalysen auf cloud Telemetriedaten – Audit-Protokolle der Steuerungsebene, Identitäts- und Token-Ereignisse, API-Aufrufmuster sowie Workload- und Flussdaten – angewendet, um das Verhalten von Angreifern aufzudecken. Sie unterscheidet sich von cloud , von einzelnen SIEM-Produkten (Security Information and Event Management) sowie von den „Posture-at-Rest“-Prüfungen im Rahmen des cloud Posture Management (CSPM).

Jeder benachbarte Begriff beantwortet eine andere Frage. Der weiter gefasste Begriff, den AWS als „Sicherheitsanalytik“ definiert – also das Sammeln und Analysieren von Sicherheitsdaten zur Erkennung von Bedrohungen –, wird cloud , wenn die Telemetrie selbst cloud ist und die analysierten Verhaltensmuster sich auf Identitäten und APIs statt auf Endpunkte beziehen. Dieser Bereich fungiert als Erkennungsschicht der cloud , neben Präventions- und Statusmaßnahmen. Es handelt sich dabei ausdrücklich nicht um Geschäftsanalytik, auch wenn beide Bereiche gemeinsame Datenpipelines nutzen.

Die Erkenntnisse aus dem Jahr 2026 verdeutlichen, warum sich dieses Fachgebiet mittlerweile zu einer eigenständigen Disziplin entwickelt hat. Bei den von Mandiant im zweiten Halbjahr 2025 durchgeführten Einsätzen im Bereich Incident Response und Managed Threat Detection – einer plattformunabhängigen Betrachtung schwerwiegender Angriffe auf cloud Software-as-a-Service-Systeme (SaaS) – waren in 83 % der Fälle Identitätsmissbrauch die Ursache, in 73 % der Fälle hatten es die Angreifer auf Daten abgesehen, und die Ausnutzung von Sicherheitslücken machte lediglich 2 % aus (Threat Horizons, 1. Halbjahr 2026). Beachten Sie diese Einschränkungen – die Zahlen beziehen sich auf untersuchte Angriffe und nicht auf jeden einzelnen Alarm in jedem Mandanten.

Das Gesamtbild der Datenpannen sieht anders aus, und die Einstufung der Betroffenen spielt eine Rolle. Der Data Breach Report (DBIR) 2026“ von Verizon stellte fest, dass bei 31 % der Datenpannen Schwachstellen ausgenutzt wurden – womit diese Ursache zum ersten Mal seit 19 Jahren den Diebstahl von Zugangsdaten überholte –, während die Beteiligung Dritter auf 48 % stieg – ein Anstieg von 60 % im Vergleich zum Vorjahr (Verizon DBIR 2026). „M-Trends 2026“, ebenfalls ein Datensatz, der alle Umgebungen abdeckt, bezifferte die globale mediane Verweildauer im Jahr 2025 auf 14 Tage (gegenüber 11 im Vorjahr) und stellte fest, dass Exploits mit 32 % zum sechsten Mal in Folge der häufigste Angriffsvektor waren (M-Trends 2026). Zusammengenommen sagen sie eines ganz eindeutig aus: Bei allen Sicherheitsverletzungen stehen Exploits an erster Stelle, doch bei größeren cloud SaaS-Angriffen dominiert der Identitätsmissbrauch. Identitätsmissbrauch ist genau das, was oberflächliche Signaturen nicht erkennen können.

Cloud analysen im Vergleich zu cloud , SIEM und CSPM

Dies ist die Klarstellung, die in den meisten Erklärungen fehlt, und sie verändert, was Sie kaufen und aufbauen. Cloud beantwortet geschäftliche Fragen – Nutzung, Umsatz, Produktverhalten – über Business-Intelligence-Pipelines. Ein SIEM ist ein Produkt und eine Architektur, eine Umgebung, in der Erkennungsinhalte ausgeführt werden können. CSPM bewertet die Konfiguration im Ruhezustand – öffentliche Buckets, Rollen mit zu weitreichenden Berechtigungen –, bevor ein Angreifer auftaucht. Cloud erkennen aktives Angreiferverhalten in cloud , sobald es auftritt. Die folgende Tabelle stellt die vier Bereiche gegenüber.

Vier Begriffe, die häufig miteinander verwechselt werden: cloud erkennen Verhaltensmuster, cloud unterstützt geschäftliche Entscheidungen, ein SIEM aggregiert Protokolle und CSPM überprüft den Sicherheitsstatus im Ruhezustand.

So funktioniert die cloud -Sicherheitsanalyse

Cloud wandelt große Mengen an cloud in priorisierte, verhaltensbasierte Erkennungen um. Die Pipeline ist über alle Anbieter hinweg einheitlich, auch wenn sich die Log-Namen unterscheiden, und lässt sich in fünf Schritte unterteilen:

1. Erfassen Sie cloud über Anbieter, Konten und Workloads hinweg.
2. Normalisieren und ergänzen Sie Ereignisse mit Kontextinformationen zu Identitäten, Assets und Bedrohungen.
3. Normales Grundverhalten für jede menschliche und nicht-menschliche Identität.
4. Veranstaltungen miteinander verknüpfen und Verhaltensanalysen quellenübergreifend anwenden.
5. Auf signifikante Abweichungen hinweisen und nach Risiko priorisieren.

‍

‍

Der Ausgangspunkt ist cloud Telemetrie. Audit-Protokolle der Steuerungsebene – AWS CloudTrail, Google Cloud Logs sowie Anmelde- und Audit-Protokolle von Entra ID – zeichnen jede Verwaltungsaktion und jeden API-Aufruf in einer Umgebung auf. Identitäts- und Token-Ereignisse erfassen Authentifizierungen, Berechtigungsvergaben und Einwilligungen. API-Aufrufmuster zeigen, was jede Identität tatsächlich tut, während Workload- und Netzwerkflussdaten verdeutlichen, wie sich Daten bewegen. Die Referenzarchitektur von Google beschreibt in ihrem Leitfaden zur Sicherheitsprotokollanalyse die operative Abfolge, um dies korrekt umzusetzen: Aktivieren Sie die richtigen Protokolle, leiten Sie diese an ein Analyseziel weiter und analysieren Sie sie dort.

Die Normalisierung verdient besondere Beachtung, da sich cloud nicht auf einheitliche Schemata einigen können. Dasselbe konzeptionelle Ereignis – nämlich die Übernahme erweiterter Berechtigungen durch eine Identität – sieht in CloudTrail, den Entra ID-Auditprotokollen und Cloud Google Cloud völlig unterschiedlich aus. Durch die Anreicherung werden dann die fehlenden Informationen zu den Rohereignissen ergänzt, darunter die Kritikalität der Ressourcen, die Zugehörigkeit der Identität und der Kontext der Bedrohungsinformationen.

Was diesen Bereich cloud macht, ist die Art der Ressourcen. Cloud ist kurzlebig, API-gesteuert und identitätsorientiert – Workloads bestehen nur wenige Minuten, jede Aktion ist ein API-Aufruf, und die Identität bildet die effektive Sicherheitsgrenze. Das Erkennungssignal ist daher eine Verhaltensabweichung von einer erlernten Basislinie und nicht eine fehlerhafte Nutzlast. Aus diesem Grund steht die Analyse des Benutzer- und Entitätsverhaltens (UEBA) im Mittelpunkt dieses Ansatzes, und die Erkennung von Netzwerkanomalien wendet dieselbe Basislinienlogik auf den Datenverkehr zwischen den Workloads an.

In den letzten beiden Phasen zeigt die Analytik ihren operativen Nutzen. Durch Korrelation werden isolierte Ereignisse – eine neue Anmeldung, eine Berechtigungsänderung, ein sprunghafter Anstieg der Datenabfragen – zu einem Angriffsszenario verknüpft, und durch Priorisierung wird dieses Szenario im Vergleich zu allen anderen Ereignissen, die um Aufmerksamkeit konkurrieren, eingestuft. Richtig umgesetzt ist dies das Gegenmittel gegen die Alarmmüdigkeit. Es ist auch der entscheidende Faktor für die beiden Kennzahlen, an denen die meisten Security Operations Center (SOCs) gemessen werden – die durchschnittliche Zeit bis zur Erkennung (MTTD) und die durchschnittliche Zeit bis zur Reaktion (MTTR) –, da Analysten von einer kurzen, nach Priorität geordneten Liste ausgehen statt von einem rohen Ereignisstrom.

Warum die signaturbasierte Erkennung in der cloud versagt

Wenn sich ein Angreifer mit gültigen, gestohlenen Anmeldedaten oder einem autorisierten Token authentifiziert, ist die Verhaltensanalyse oft die einzige verbleibende Erkennungsmöglichkeit. Signaturen gleichen bekannte schädliche Artefakte ab – malware , Exploit-Payloads, bösartige Domains. Eine erfolgreiche Anmeldung über eine zugelassene API erzeugt nichts davon. Es gibt keine fehlgeschlagene Authentifizierung, keine abgelegte Binärdatei und keinen Exploit-Datenverkehr, der überprüft werden könnte. Dies ist der gemeinsame blinde Fleck bei Tools, die ausschließlich auf Signaturen basieren, und bei SIEM-Implementierungen, die ausschließlich auf Regeln beruhen.

‍

Die als UNC5537 erfasste Kampagne aus dem Jahr 2024 gegen Snowflake-Kundenumgebungen ist der typische Fall (Analyse zu UNC5537 von Google Threat Intelligence). Die Angreifer nutzten Anmeldedaten, die durch malware gestohlen worden waren – 79,7 % davon waren bereits zuvor offengelegt worden, und einige waren seit vier Jahren nicht mehr aktualisiert worden –, um Konten anzugreifen, bei denen keine Multi-Faktor-Authentifizierung (MFA) und keine Netzwerk-Whitelists vorhanden waren. Rund 165 Organisationen wurden benachrichtigt. Es wurde keine Sicherheitslücke ausgenutzt, und malware keine malware die Plattform. Jede Aktion der Angreifer war eine authentifizierte, korrekt formatierte Abfrage.

Damit blieben den Sicherheitsverantwortlichen drei Arten von Anzeichen, die alle verhaltensbasiert waren: unmögliche Bewegungen zwischen Anmeldungen, unbekannte Client-Anwendungen und Fingerabdrücke sowie Abfragevolumina, die weit außerhalb der Basiswerte eines Kontos lagen. Eine auf diesen Basiswerten aufbauende Verhaltensanalyse, gepaart mit einer Identitätsanalyse, die bewertet, wie sich jedes Konto normalerweise authentifiziert, ist die Antwort der Erkennungstechnik – neben den grundlegenden Präventionsmaßnahmen, die den Opfern fehlten.

Der „Salesloft Drift“-Vorfall aus dem Jahr 2025, der unter der Kennung UNC6395 erfasst wurde, erweiterte die Erkenntnisse von Passwörtern auf Token (Analyse von UNC6395 durch Google Threat Intelligence). Angreifer erlangten Zugriff auf OAuth-Token aus der Drift-Integration und nutzten diese, um wohlgeformte SOQL-Abfragen (Salesforce Object Query Language) gegen zahlreiche Salesforce-Kundeninstanzen auszuführen – im Hauptbericht ist lediglich von „zahlreichen“ die Rede. Keine einzelne Anfrage war fehlerhaft. Die Anzeichen waren aggregierter Natur und verhaltensbezogen – API-Aufrufvolumen, Abfrageform und Abweichungen des User-Agents von der etablierten Basislinie der Integration. Aus diesem Grund behandeln Programme zur Erkennung und Reaktion auf Identitätsbedrohungen (ITDR) nicht-menschliche Integrationen als Identitäten erster Klasse.

Dieser Trend hat sich bis ins Jahr 2026 entlang zweier unterschiedlicher Pfade fortgesetzt. Berichte vom Juli 2026 dokumentierten eine einjährige Welle von OAuth-Missbrauch im Zusammenhang mit dem Erpressungs-Ökosystem der ShinyHunters (The Hacker News). Eine separatephishing veranlasste die Opfer dazu, von Angreifern kontrollierte Passkeys in Entra ID zu registrieren, wodurch eine phishing Kontrollinstanz in einen dauerhaften Zugangspunkt verwandelt wurde (Help Net Security). Unterschiedliche Vorgehensweisen, dasselbe Erkennungsproblem – gültige Identitätsartefakte (Token, Session-Cookies, Passkeys), die legitime APIs ansteuern.

Auch in der cloud kommt es nach wie vor zu Exploits cloud mit einer wichtigen Einschränkung hinsichtlich des Anwendungsbereichs. In den Telemetriedaten Cloud selbst – die sich von den Daten aus dem Mandiant-Projekt unterscheiden – stieg die Remote-Code-Execution (RCE) als Angriffsvektor von 2,9 % im ersten Halbjahr 2025 auf 13,6 % im zweiten Halbjahr (Threat Horizons, 1. Halbjahr 2026).

Wenn es tatsächlich zu einer Ausnutzung kommt, erfolgt die Entwicklung von Exploits schneller als die Verbreitung der Signatur. React2Shell (CVE-2025-55182) ist eine RCE-Schwachstelle vor der Authentifizierung in React Server Components, die im Common Vulnerability Scoring System (CVSS) mit der Höchstpunktzahl 10,0 bewertet wurde (React-Sicherheitshinweis). Die Schwachstelle wurde bereits innerhalb von etwa 48 Stunden nach ihrer Offenlegung aktiv ausgenutzt – die Cybersecurity and Infrastructure Security Agency (CISA) nahm sie am 5. Dezember 2025, zwei Tage nach der Veröffentlichung des Sicherheitshinweises, unter Berufung auf Hinweise auf aktive Ausnutzung in den Katalog der bekannten ausgenutzten Schwachstellen auf (CISA-Warnung). Auch Verhaltensanalysen schließen einen Teil dieser Lücke – eine Workload, die plötzlich einen Krypto-Miner startet, weicht von ihrem Normalzustand ab, noch bevor eine Signatur bereitgestellt wird.

Anwendungsfälle und Techniken der Cloud -Sicherheitsanalyse

Derselbe analytische Kern unterstützt eine Reihe von Anwendungsfällen, die jeweils eine verhaltensbezogene Frage aufwerfen, die sich mit keiner Signatur beantworten lässt. SOC-Analysten nutzen diese Erkennungen zur Triage, Threat Hunter zur Überprüfung von Hypothesen und Compliance-Teams als Nachweis für die Überwachungsabdeckung. Der Vorteil liegt in einer frühzeitigeren Erkennung, weniger Fehlalarmen und kürzeren Untersuchungen. Alle diese Fälle bauen auf der Baselining-Phase der Pipeline auf.

• Erstellung von Verhaltens-Baselines für Benutzeridentitäten. UEBA-ähnliche Modelle erfassen die üblichen geografischen Standorte, Zeiten und Clients, an denen sich die einzelnen Benutzer anmelden, und kennzeichnen anschließend unrealistische Reisen, Zugriffe außerhalb der üblichen Zeiten sowie erstmals auftretende Anwendungen.
• Erkennung von Anomalien bei API-Aktivitäten. Durch den Abgleich von Aufrufvolumen, Aufrufzusammensetzung, geografischer Verteilung und Kundenprofil mit den Referenzwerten der jeweiligen Identität lassen sich Token-Diebstahl und Missbrauch durch Automatisierung frühzeitig erkennen.
• Erkennung von Insider-Bedrohungen und Datenexfiltration. Spitzen im Abfragevolumen und ungewöhnliche Datenzugriffe decken Insider-Bedrohungen und schrittweise Datendiebstähle auf, während die Analyse des Netzwerkverkehrs bestätigt, wie die Daten tatsächlich übertragen wurden.
• Anreicherung von Bedrohungsinformationen. Durch die Korrelation von cloud mit kuratierten Bedrohungsinformationen lässt sich eine ungewöhnliche Anmeldung einer bekannten Infrastruktur zuordnen – und entsprechend priorisieren.

Zwei davon verdienen besondere Beachtung, da sie als Anker für die Untersuchungen dienen. Die Erkennung von Datenexfiltration in der cloud im Wesentlichen ein Problem der Abfragen und des Datenabflusses – bei der Snowflake-Kampagne waren die beständigen Signale das Abfragevolumen und Muster, die weit außerhalb der für das Konto üblichen Basiswerte lagen. Und die Anreicherung wandelt eine Anomalie in eine Entscheidung um – dieselbe Anmeldung wird anders bewertet, wenn ihre Quellinfrastruktur bereits mit Credential-Stuffing-Kampagnen in Verbindung steht.

Analyse maschineller und nicht-menschlicher Identitäten

In cloud meisten cloud gibt es mittlerweile weitaus mehr Dienstkonten, API-Schlüssel und OAuth-Token als Menschen. Eine von Tenable verfasste und von der Cloud Alliance (CSA) veröffentlichte Analyse aus dem Jahr 2026 beziffert das Verhältnis von maschinellen zu menschlichen Identitäten auf etwa 100 zu 1. Tenables Cloud AI Security Risk Report 2026“ ergab zudem, dass 65 % der Unternehmen vergessene cloud beherbergen – Identitäten, für die niemand verantwortlich ist, die niemand aktualisiert oder überwacht.

Diese „Geister“ sind keine hypothetischen Fälle. Die schon seit Jahren bestehenden, nicht aktualisierten Anmeldedaten hinter der UNC5537-Kampagne fielen genau in diese Kategorie. Nicht-menschliche Identitäten verhalten sich zudem ganz anders als Menschen – keine Arbeitszeiten, keine Reisen und äußerst regelmäßige Anrufmuster –, sodass sie eigene Referenzwerte benötigen, die von der menschlichen UEBA getrennt sind. Ein Dienstkonto, das sich plötzlich interaktiv authentifiziert, seinen Geltungsbereich erweitert oder einen neuen Datensatz abfragt, ist eines der deutlichsten Erkennungssignale, cloud liefern.

Cloud -Sicherheitsanalysen im Vergleich zu SIEM und verwandten Kategorien

Ein SIEM ist die Plattform, auf der Analysen ausgeführt werden können – cloud sind die dort ausgeführten Funktionen zur Erkennung von Verhaltensmustern. Beide ergänzen sich, sie stehen nicht in Konkurrenz zueinander. Verwirrung in diesem Bereich kommt teuer zu stehen – Teams kaufen entweder ein zweites Produkt, das sie gar nicht benötigen, oder gehen davon aus, dass ihre Protokollaggregation cloud bereits erkennt. Die folgende Tabelle verdeutlicht die Abgrenzungen, einschließlich der angrenzenden Plattformkategorien, mit denen Käufer konfrontiert sind.

Cloud sind eine Funktion, während SIEM, CDR und CNAPP die Produkte und Plattformen sind, auf denen diese Funktion ausgeführt wird oder in denen sie integriert ist.

SIEM-Plattformen bilden nach wie vor das Rückgrat für Aggregation, Korrelation und Compliance vieler Teams, und genau das ist der springende Punkt: Die Produktfrage ist von der Frage nach den Fähigkeiten zu trennen. Cloud (CDR) beantworten die Frage nach den Funktionen direkt, indem sie cloud Verhaltensanalysen mit Reaktionsmaßnahmen für Teams bündeln, die sich die Pflege der Erkennungsinhalte abnehmen lassen möchten. Der praktische Zusammenhang ergibt sich oft aus den Kosten – Teams nutzen cloud , um zu entscheiden, welche Telemetriedaten in das SIEM-System eingespeist werden und welche in kostengünstigere Speicher umgeleitet werden; ein Kompromiss, den der nächste Abschnitt quantifiziert.

Die nebenstehenden Akronyme beschreiben den Anwendungsbereich, nicht den Wettbewerb. Eine cloud Anwendungsschutzplattform (CNAPP) bündelt den Schutz des Sicherheitsstatus und der Workloads über den gesamten Anwendungslebenszyklus hinweg. CSPM bewertet die Konfiguration im Ruhezustand, eine cloud (CWPP) schützt die Rechenschicht, und cloud (CIEM) regelt, wer was tun darf. Keine dieser Lösungen ersetzt die Verhaltenserkennung – sie reduzieren und kartieren die Angriffsfläche, die anschließend durch Analysen überwacht wird. Die identitätsbasierten Einbruchsnachweise aus dem Jahr 2026, wonach 83 % der schwerwiegenden cloud SaaS-Fälle in Mandiant-Einsätzen auf Identitäten zurückzuführen waren (Threat Horizons H1 2026), erklären, warum sich jede dieser Kategorien zunehmend auf das Identitätsverhalten konzentriert.

Der Markt hat bereits eine Entscheidung in der Frage „Funktionalität oder Produkt“ getroffen. Eigenständige cloud wurden wiederholt aus dem Programm genommen oder in umfassendere Plattformen zur Erkennung und Sicherheitslageintegration integriert. Betrachten Sie den Begriff als eine Funktion, die Sie benötigen – sei es in einem SIEM, einem Security Data Lake oder einer CDR-Plattform –, und nicht als ein einzelnes Element im Architekturdiagramm.

Die wirtschaftlichen Aspekte der cloud

Die Analyse Cloud ist nur so gut wie die Telemetriedaten, deren Speicherung man sich leisten kann. Die Kosten für die Datenerfassung sind das zentrale Argument der Praktiker gegen jede Architektur, die große Mengen an Telemetriedaten benötigt, und sie sind der eigentliche Grund für die Existenz von Sicherheits-Data-Lakes – die Trennung von kostengünstigem Speicher und selektiver Erkennung.

Das Datenvolumen wächst schneller als die Budgets, und nicht alle Protokolle sind ihren Aufwand wert. Audit-Protokolle zum Datenzugriff sind hier ein klassisches Problem – in den Implementierungsrichtlinien von Google wird der Verwaltung des Volumens der Audit-Protokolle zum Datenzugriff besondere Aufmerksamkeit gewidmet, bevor Daten weitergeleitet werden (Richtlinien zur Analyse von Sicherheitsprotokollen). Entscheidend ist die Auswahl der Telemetriedaten. Protokolle der Steuerungsebene und der Identitätsverwaltung bieten den höchsten Erkennungswert pro Gigabyte, während ausführliche Protokolle der Datenebene nur dann erfasst werden sollten, wenn die betroffenen Ressourcen dies rechtfertigen. Diese Auswahl ist entscheidend dafür, dass die Überwachungcloud auch bei wachsenden Infrastrukturen nachhaltig bleibt.

Die Aufbewahrungsstufenregelung löst den Zielkonflikt zwischen Datenerfassung und Erkennung. Telemetriedaten zur Echtzeit-Erkennung werden als „hot“ gespeichert, Daten zur Untersuchung als „warm“ und Daten zur proaktiven Suche als „cold“ – sie sind weiterhin durchsuchbar, werden aber wie Archivspeicher abgerechnet.

Durch die mehrstufige Aufbewahrung bleiben hochwertige Telemetriedaten für die Suche abrufbar, ohne dass für alles die Kosten für Hot-Storage anfallen.

Die Aufbewahrungsfrist ist nicht nur ein Häkchen auf einer Compliance-Checkliste – sie bestimmt, welche Daten im Rahmen einer Untersuchung einsehbar sind. Während der UNC5537-Kampagne bot die Standardaufbewahrungsfrist von Snowflake den Ermittlern ein Zeitfenster von 365 Tagen, in dem sie die Kontoaktivitäten durchforsten konnten (die UNC5537-Untersuchung). Unternehmen mit kürzeren Zeitfenstern verfügen schlichtweg über weniger historische Daten, die sie rekonstruieren können.

Die Benchmarks verdeutlichen, worum es geht. Data Breach „Cost of a Data Breach des Ponemon Institute bezifferte den weltweiten Durchschnitt für das Jahr 2025 auf 4,44 Millionen US-Dollar, wobei 241 Tage benötigt wurden, um eine Sicherheitsverletzung zu identifizieren und einzudämmen – Zahlen für alle Umgebungen, wobei die Ausgabe für 2026 in Kürze erscheint (Help Net Security). Die Zeitpläne Cloud unterstreichen dieselbe Dringlichkeit. In der Auswertung der cloud des DBIR 2026 durch Push Security hatten nur 23 % der Drittanbieterorganisationen Lücken cloud vollständig behoben, und im Median benötigte ein Unternehmen acht Monate, um 50 % der festgestellten Probleme bei Passwörtern und Fehlkonfigurationen von Berechtigungen zu beheben (Push Security).

Implementierung von cloud icherheitsanalysen in AWS, Azure und GCP

Die Bezeichnungen der Telemetriedaten variieren je nach Anbieter – die Fragen zum Nutzerverhalten hingegen nicht. Die Referenzarchitektur von Google definiert die Fragenbereiche, die jede IT-Umgebung abdecken sollte: Anmelde- und Zugriffsanomalien, Berechtigungsänderungen, Bereitstellungsaktivitäten, Datenzugriff und Netzwerkmuster (Leitfaden zur Analyse von Sicherheitsprotokollen). In der folgenden Tabelle werden diese Fragen den wichtigsten Datenquellen der einzelnen Anbieter zugeordnet.

Die gleichen Kategorien von Verhaltensfragen gelten für jeden Anbieter, sobald die Telemetriedaten zur Steuerungsebene und zur Identitätserkennung übertragen werden.

Die meisten Unternehmen beantworten diese Fragen an mehreren Stellen gleichzeitig. Ein cloud vereinheitlicht die Protokollschemata der Anbieter in einer einzigen Analyseebene, sodass überall dieselbe Basislogik gilt. Anbieterspezifische Detailtiefe zahlt sich jedoch weiterhin aus – die AWS-Bedrohungserkennung beispielsweise überlagert die Managementebene mit CloudTrail-Datenereignissen und Flow-Protokollen, um das aufzufangen, was in den Protokollen auf Kontoebene übersehen wird.

Container erweitern diecloud . Kubernetes-Audit-Protokolle und Laufzeitereignisse sehen überall gleich aus, unabhängig davon, wo der Cluster ausgeführt wird. Dadurch wird die Kubernetes-Sicherheitstelemetrie zu einem natürlichen verbindenden Element – und erweitert dieselben Basisstandards auf cloud , in denen sich Arbeitslasten über Rechenzentren und Clouds erstrecken.

Überwachen Sie den Identitätsanbieter (IdP) selbst und nicht nur die dahinter liegenden Workloads. CVE-2026-40379, eine Spoofing-Sicherheitslücke aus dem Jahr 2026 in Entra ID, wurde von der CVE Numbering Authority (CNA) mit 9,3 und vom National Institute of Standards and Technology (NIST) (NVD-Eintrag) mit 7,5 bewertet. Wenn der IdP das Ziel ist, werden seine eigenen Anmelde- und Audit-Telemetriedaten zur Erkennungsfläche.

Zuordnung zu MITRE ATT&CK und Compliance-Rahmenwerken

MITRE ATT&CK , veröffentlicht am 28. April 2026, hat die Modellierung von Ausweichstrategien neu strukturiert. Die frühere Taktik „Defense Evasion“ wurde abgeschafft und in „Stealth“ (0005) und Verteidigungsmangel (0112) — wobei Letzteres Angreifer umfasst, die Sicherheitsmechanismen, Pipelines und Tools umgehen, sodass die Verteidiger nicht erkennen können, was vor sich geht, und den Vorgängen nicht vertrauen können. Die ATT&CK cloud umfasst 12 Taktiken auf vier Plattformen – Office-Suite, Identitätsanbieter, SaaS und IaaS (Infrastructure as a Service) – und bietet Erkennungsingenieuren ein gemeinsames Vokabular für die in diesem Leitfaden beschriebenen Verhaltensweisen.

Ein Überblick über cloud aus ATT&CK v19 bis hin zu den verhaltensbasierten Erkennungsmechanismen, die cloud bieten können.

Daraus ergibt sich ganz natürlich die Compliance-Zuordnung. Im Rahmen des 2024 veröffentlichten NIST Cybersecurity Framework (CSF) 2.0 ist diese Vorgehensweise der Funktion „Detect“ – einer der sechs Funktionen des Frameworks – unter den Kategorien DE.CM und DE.AE (NIST) zugeordnet. Die CSA Cloud Matrix v4 mit 197 Kontrollmaßnahmen in 17 Domänen enthält die entsprechenden Anforderungen in ihrer Domäne „Logging & Monitoring“ (LOG) (CSA CCM).

NIS2 (Richtlinie (EU) 2022/2555) schreibt gemäß Artikel 23 eine Frühwarnung innerhalb von 24 Stunden nach Bekanntwerden eines schwerwiegenden Vorfalls, eine Vorfallmeldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats vor. DORA (Verordnung (EU) 2022/2554) gilt seit dem 17. Januar 2025 für Finanzinstitute in der EU – derart enge Meldefristen legen einen deutlichen Schwerpunkt auf die Geschwindigkeit der Erkennung.

Moderne Ansätze für die Analyse cloud

Die Branche konzentriert sich zunehmend auf drei Entwicklungstrends. Bei der Erkennung steht die Identität im Vordergrund, denn darauf deuten die verifizierten Erkenntnisse hin – laut den Mandiant-Daten aus dem zweiten Halbjahr 2025 (Threat Horizons, erstes Halbjahr 2026) war die Identität bei 83 % der schwerwiegenden cloud SaaS-Angriffe ausschlaggebend. Einzelne Analysetools werden zunehmend zu Plattformen konsolidiert, von SIEM-gehosteten Content-Paketen bis hin zu cloud und Reaktionsplattformen. Und KI-gestützte Triage und Hunting werden zum Standard, da schlanke Teams nicht in der Lage sind, plattformübergreifendes Verhalten manuell in cloud zusammenzufügen.

Für Käufer gibt es drei Kriterien, die robuste Plattformen von einfachen Dashboards unterscheiden. Achten Sie auf eine einheitliche Übersicht über cloud, Identitäts- und SaaS-Umgebungen. Bestehen Sie auf Verhaltenserkennungen, die auch nach dem Diebstahl von Anmeldedaten weiterhin funktionieren – der Test zur Erkennung und Reaktion auf Identitätsbedrohungen. Und legen Sie mehr Wert auf die Qualität der Signale als auf die Anzahl der Warnmeldungen, gemessen daran, was ein kleines Team tatsächlich untersuchen kann.

Wie Vectra AI das Thema cloud analysen Vectra AI

Vectra AI cloud aus einer „Assume-Compromise“-Perspektive Vectra AI . Da Angreifer zunehmend mit gültigen Identitäten auftreten, legt die Methodik den Schwerpunkt auf die Eindeutigkeit von Angriffssignalen in den Bereichen Netzwerk, Identitäten, cloud und SaaS – dabei werden Verhaltensmuster aufgedeckt, die auf einen aktiven Angreifer hindeuten, anstatt auf Signaturen zu setzen, die bei Missbrauch gültiger Anmeldedaten niemals ausgelöst werden. In der Praxis bedeutet dies, für jede Identität – ob Mensch oder Maschine – einen Referenzwert zu ermitteln, Abweichungen über verschiedene Bereiche hinweg zu einem einheitlichen Angriffsszenario zusammenzufügen und die wenigen Signale, die auf einen tatsächlichen Fortschreiten des Angriffs hindeuten, gegenüber der reinen Menge an Warnmeldungen hervorzuheben.

Schlussfolgerung

Cloud hat ihren eigenen Namen verdient, weil die cloud , wonach die Erkennung suchen muss. Angreifer, die mit gültigen Anmeldedaten und Tokens eindringen, umgehen Signaturen gänzlich – die charakteristischen Sicherheitsverletzungen der Jahre 2024 und 2025 gingen weder mit malware noch mit Exploits oder fehlgeschlagenen Anmeldeversuchen einher, sondern lediglich mit Abweichungen vom Normalzustand. Die Lösung ist ein ganzheitlicher Ansatz, kein einzelnes Produkt. Erfassen Sie die relevanten Telemetriedaten aus den Bereichen Control-Plane, Identitäten, APIs und Workloads. Erstellen Sie für jede Identität – ob Mensch oder Maschine – eine Basislinie. Stufen Sie die Aufbewahrungsfristen ein, damit die Suche nach Sicherheitsvorfällen kostengünstig bleibt. Ordnen Sie Erkennungsergebnisse der ATT&CK cloud und den von Auditoren anerkannten Frameworks zu. Teams, die cloud als Fähigkeit betrachten – unabhängig davon, wo sie ausgeführt wird –, werden auch weiterhin die Angreifer aufspüren, die von ihren Signaturen nie erkannt werden.

‍