CrowdStrike bringt CDR zu Google Cloud auf dem Next 2026

Stellen Sie sich einen Eisenbahn-Stellwerksraum der 1950er Jahre vor. Drei Strecken laufen in den Bahnhof ein, aber nur zwei verfügen über Live-Telemetrie auf dem Tableau. Die Züge der dritten Strecke existieren, fahren pünktlich und befördern Fahrgäste – doch was auf ihr passiert ist, erfährt der Fahrdienstleiter erst am nächsten Morgen aus einem Stapel Papierprotokolle. Das war in etwa die Situation von CrowdStrikes Cloud-Abdeckung bis diese Woche. Die dritte Strecke wurde jetzt angeschlossen.

Auf dem Google Cloud Next 2026 kündigte CrowdStrike an, dass sein Cloud Detection and Response (CDR)-Dienst nun Google Cloud Platform neben dem bereits unterstützten AWS und Azure abdeckt. Das Versprechen: Echtzeitschutz zur Laufzeit für Google-Workloads – als Gegenmaßnahme zu Angreifern, die KI nutzen, um sich schneller durch Cloud-Umgebungen zu bewegen, als Verteidiger reagieren können.

Was passiert ist

Am 23. April, wie SC Media berichtete, brachte CrowdStrike Holdings seinen CDR-Dienst auf die Google Cloud Platform und schloss damit eine auffällige Lücke in der Falcon Cloud Security-Plattform. CDR lief bereits seit einiger Zeit auf AWS und Azure. Google Cloud, obwohl es das dritte Standbein des Hyperscaler-Stuhls bildet und bevorzugte Heimat vieler ML- und Data-Engineering-Teams ist, stand außerhalb des Echtzeitüberwachungs-Zirkels.

Die Ankündigung fiel auf dem Google Cloud Next 2026, was kaum zufälliger hätte gewählt werden können. Zwei wesentliche Punkte sind entscheidend. Erstens ist GCP nun neben AWS und Azure in das Echtzeit-Monitoring von CDR integriert. Zweitens erweiterte CrowdStrike die Falcon-Plattform auf regionale Google-Cloud-Infrastruktur – das stille Detail, das Compliance-Verantwortliche in Europa und am Golf mehr interessieren wird als das Marketing.

CrowdStrikes Aussage ist eindeutig: Angreifer nutzen KI, um Eindringversuche und Lateral Movement in Cloud-Umgebungen zu beschleunigen, und die traditionelle Batch-Log-Verarbeitung kann damit nicht mithalten. CDRs Antwort ist Event-Streaming, KI und maschinelles Lernen zur Korrelation von Angreiferaktivitäten mit Cloud-Asset- und Identitätskontext sowie automatisierte Reaktionsmaßnahmen auf Basis dieser Korrelation.

Für alle, die schon einmal einen lauten GuardDuty-Feed um 2 Uhr morgens aufleuchten sahen und versucht haben herauszufinden, welche IAM-Rolle was in welchem Projekt getan hat, ist die Idee einer einheitlichen Oberfläche für alle drei Clouds keine Kleinigkeit. Das ist der Stellwerksraum, in dem endlich alle drei Strecken auf dem Tableau erscheinen.

Technische Struktur

Der Kern liegt im Telemetrie-Modell. Traditionelle Cloud-Sicherheitstools – einschließlich der meisten CSPM- und CNAPP-Angebote – stützen sich stark auf die Batch-Log-Verarbeitung: CloudTrail einlesen, Cloud Audit Logs einlesen, sie nach einem Zeitplan verarbeiten und Befunde ausgeben. Das funktioniert für Posture- und Compliance-Reporting. Es scheitert in dem Moment, in dem ein Angreifer schneller agiert als die Ingest-Verzögerung.

CDRs Ansatz ist Event-Streaming. Aktivitäten in der Cloud-Control-Plane und zur Laufzeit werden sofort analysiert – nicht erst am Ende eines Batch-Fensters. Kombiniert man das mit einem Sensor-Modell, das über Falcon bereits auf Workloads läuft, entsteht ein Szenario, in dem Telemetrie auf Prozessebene und Control-Plane-Events nahezu in Echtzeit korreliert werden können.

Die KI- und ML-Schicht führt die Angreifer-zu-Kontext-Korrelation durch. Das ist der unscheinbare Teil, der tatsächlich entscheidend ist. Ein verdächtiger API-Aufruf für sich allein ist Rauschen. Derselbe Aufruf, verknüpft mit einem spezifischen Service-Account, einer bestimmten Compute-Ressource, einer konkreten Identitätskette und einer bekannten TTP aus MITRE ATT&CK, ist eine Detektion. Das Problem in der Cloud-Sicherheit ist nicht das Signalvolumen, sondern die Verknüpfung dieser Signale ohne den Analysten zu überwältigen. Das ist der Zweck der Korrelationsschicht.

Der Teil mit der regionalen Google-Cloud-Infrastruktur wird in den meisten Pressemitteilungen übergangen. Falcon, das auf regionaler GCP-Infrastruktur läuft, bedeutet, dass die Datenebene des Sicherheitstools selbst innerhalb einer bestimmten Jurisdiktion verbleibt. Für Kunden unter DSGVO, Schrems-II-Folgeregeln, VAE-Datenlokalisierungsvorschriften oder australischen Behörden-Workloads ist das der Unterschied zwischen „Wir können das kaufen" und „Legal hat es im zweiten Quartal abgelehnt". Wer jemals versucht hat, ein US-amerikanisches SaaS-Sicherheitstool durch einen deutschen Betriebsrat genehmigen zu lassen, weiß genau, wie viel Reibung das beseitigt.

Automatisierte Reaktionsmaßnahmen sind das letzte Glied. Detektionen, die um 3 Uhr morgens nur einen Menschen alarmieren, sind keine Verteidigung, sondern Benachrichtigungen. Die Verknüpfung von Korrelationsergebnissen mit Aktionen – Isolierung eines Workloads, Entzug eines Tokens, Beenden eines Prozesses – ist der Punkt, an dem sich Event-Streaming auszahlt. Ob diese Aktionen konservativ oder aggressiv konfiguriert werden, wird die Konfigurationsdebatte in jedem einführenden Team sein.

Wer unter Druck gerät

Der offensichtliche Verlierer ist jeder reine Cloud-native Sicherheitsanbieter, dessen wichtigstes Differenzierungsmerkmal lautete: „Wir decken alle drei Clouds ab, die Agent-Anbieter nicht." Dieser Vorteil ist nun deutlich kleiner geworden. Wiz, Orca, Sysdig, Lacework-Nachfolgeprodukte: Sie haben nach wie vor echte technische Argumente, aber „CrowdStrike unterstützt GCP nicht richtig" ist keines mehr davon.

Der weniger offensichtliche Verlierer ist das interne SOC, das GuardDuty, Defender for Cloud und Security Command Center mit einem Haufen Python und guten Wünschen zusammengefrickelt hat. Diese Architektur funktioniert. Sie ist aber auch personalintensiv und fragil, wenn Mitarbeiter gehen. Eine konsolidierte CDR-Lösung verändert den internen Business Case für die Aufrechterhaltung dieser selbst gebauten Pipeline – insbesondere in mittelständischen Unternehmen, wo das Sicherheitsteam aus sechs Personen besteht und zwei davon diese Woche Bereitschaft haben.

Branchen mit starkem GCP-Einsatz spüren das am deutlichsten. iGaming-Betreiber, die GCP für BigQuery und Echtzeit-Analytics rund um das Spielerverhalten gewählt haben, haben nun eine ernsthafte Laufzeitoption auf derselben Cloud. Fintechs, die Betrugsmodelle auf Vertex AI und Kartenfluss-Services auf GKE betreiben, haben genau diese Art von Abdeckung gefordert. Ad-Tech-Plattformen, die Petabytes durch GCP-Pipelines schieben, haben historisch zu wenig in die Laufzeit-Cloud-Detektion investiert, weil das Tooling dort schwächer war. Diese Ausrede ist nun abgelaufen.

Die nächsten 90 Tage für Security-Leads in diesen Branchen sehen in etwa so aus: ein Beschaffungsgespräch darüber, ob eine Konsolidierung auf Falcon Cloud Security sinnvoll ist, eine schwierige interne Debatte über den Agent-Fußabdruck auf GKE-Nodes und eine stille Neubewertung des CNAPP-Vertrags, der zur Erneuerung ansteht. Erwarten Sie aggressives Pricing von etablierten Anbietern, die ihre Position verteidigen wollen. Erwarten Sie ungewöhnlich gut gelaunte CrowdStrike-Account-Teams im zweiten Quartal.

Leitfaden für Sicherheitsteams

Wenn GCP in Ihrer Umgebung vorhanden ist und CrowdStrike bereits auf Ihren Endpoints läuft, ist die Aufgabe dieser Woche klar und begrenzt. Führen Sie einen Proof of Value der CDR-GCP-Abdeckung gegen Ihre drei größten Erkennungslücken durch. Kein Bake-off, sondern ein gezielter Test: Kann es eine Missbrauchskette eines Service-Account-Tokens von Anfang bis Ende erkennen? Kann es eine kompromittierte Workload-Identität mit Control-Plane-Aktivität korrelieren? Kann es eine automatische Eindämmung ohne menschliches Eingreifen auslösen?

Kartieren Sie Ihre aktuelle GCP-Erkennungsabdeckung anhand von ATT&CK for Cloud-Techniken – vor der Vendor-Demo, nicht danach. Sie möchten wissen, welche Cloud-TTPs Sie derzeit nicht oder zu spät erkennen. Andernfalls werden Ihnen die Features präsentiert, die der Anbieter zeigen möchte, nicht die, die Sie benötigen.

Für Teams unter Datenlokalisierungsdruck: Klären Sie genau, welche GCP-Regionen die regionale Falcon-Infrastruktur abdeckt, und lassen Sie sich das schriftlich bestätigen. „Regional" ist ein Spektrum. Frankfurt ist nicht Dammam, ist nicht Sydney. Ihr Datenschutzbeauftragter wird fragen, und die Antwort muss konkret sein.

Widerstehen Sie schließlich dem Drang, am ersten Tag aggressive automatische Reaktionen zu aktivieren. Event-Streaming plus KI-Korrelation plus automatisierte Aktion ist eine leistungsstarke Kombination – und eine hervorragende Möglichkeit, die eigene Produktion lahmzulegen, wenn das Tuning nicht stimmt. Betreiben Sie es zunächst im Beobachtungsmodus, bauen Sie Vertrauen in die Erkennungen auf und stufen Sie dann spezifische Playbooks auf automatische Eindämmung hoch. Die Eisenbahn-Analogie gilt: Sie geben dem neuen Stellwerkssystem keine volle Kontrolle über die Weichen, bis Sie beobachtet haben, wie es einige hundert Züge korrekt geleitet hat.

Die wichtigsten Erkenntnisse

• CrowdStrike CDR deckt nun Google Cloud neben AWS und Azure ab und schließt eine echte Lücke in der Falcon Cloud Security-Plattform.
• Der architektonische Ansatz setzt auf Event-Streaming und KI-Korrelation gegen Angreifer, die sich schneller bewegen als Batch-Log-Pipelines mithalten können.
• Falcon auf regionaler GCP-Infrastruktur ist der stille Gewinn für Kunden mit Datenlokalisierungsanforderungen in Europa, am Golf und im asiatisch-pazifischen Raum.
• Reine Cloud-native Sicherheitsanbieter verlieren ihr Argument „CrowdStrike unterstützt GCP nicht" über Nacht.
• Unternehmen sollten einen Pilottest gegen spezifische Erkennungslücken durchführen, die regionale Abdeckung schriftlich bestätigen lassen und die automatische Reaktion zunächst im Beobachtungsmodus belassen.