Gartner hat «Preemptive Cybersecurity» zu einem der strategischen Technologietrends für 2026 erklärt. Gemeint ist eine Abwehr, die nicht mehr nur Alarm schlägt, sondern mithilfe von KI eingreift, bevor der Angreifer zuschlägt. Gartner prognostiziert, dass bis 2030 die Hälfte aller Sicherheitsausgaben in solche Lösungen fliesst. Die Formel dazu: «prediction is protection». Ein zweiter Trend auf derselben Liste sind «AI Security Platforms», die KI-Anwendungen und KI-Agenten gegen Angriffe absichern. Bis 2028 sollen laut Gartner über die Hälfte der Unternehmen solche Plattformen einsetzen.

Das klingt nach Zukunft. Ich wollte wissen, wie weit diese Zukunft heute schon ist, vor allem in Azure und AWS. Und ob sie das Tempo mithalten kann, in dem Angriffe inzwischen ablaufen.

Angriffe in Maschinengeschwindigkeit

Ende September 2026 hat Microsoft einen Angriff beschrieben, der zeigt, wie schnell es heute geht. Die Gruppe, die Microsoft Storm-3168 nennt, übernahm bei einem Unternehmen zwei Service Principals, also Dienstkonten, mit denen Anwendungen auf Azure zugreifen. Die Zugangsdaten des einen hatte ein Mitarbeiter zuvor im Klartext in einem öffentlichen GitHub-Ticket gepostet. Danach startete der Angreifer über 150 zerstörerische Operationen in 35 Minuten. Die eigentliche Zerstörung dauerte etwa sieben Minuten. Gelöscht wurden ein Key Vault, eine Function App, ein App Service Plan und die Sperren, die Backups und Wiederherstellung schützen sollten. Mehr als 100 Storage Accounts standen auf der Liste.

Von einer automatischen Abwehr steht in Microsofts Bericht nichts.

Das ist kein Einzelfall. Anthropic hat 2025 eine Kampagne offengelegt, bei der eine KI 80 bis 90 Prozent des Angriffs selbst ausgeführt hat, mit oft mehreren Anfragen pro Sekunde. Bei diesem Tempo hat kein Mensch Zeit, die Abwehrstrategie freizugeben. Bis der Alarm geprüft und die Freigabe eingeholt ist, ist der Schaden passiert. Gartner hat also recht: Die Abwehr muss selbst handeln. Die Frage ist, wo sie das heute schon tut.

Benutzer und Geräte: Die Abwehr handelt bereits

Bei Angriffen auf Benutzer und Endgeräte ist die automatische Abwehr Stand der Technik. Microsoft Defender verknüpft mit Automatic Attack Disruption Signale von Geräten, Identitäten, E-Mail und Cloud-Anwendungen zu einem Gesamtbild. Ist Defender sich sicher, dass ein Angriff läuft, sperrt er kompromittierte Benutzer, beendet ihre Sitzungen, schottet befallene Geräte ab und entschärft bösartige Apps mit Zugriff auf Microsoft 365. Er fragt dafür niemanden. Microsoft gibt für diese Eindämmung eine Präzision von 99 Prozent oder höher an. Jede Aktion lässt sich rückgängig machen.

Mit Predictive Shielding, derzeit in der Preview, geht Defender noch weiter. Erkennt er, dass auf einem Gerät Zugangsdaten abgegriffen wurden, sperrt er die dort wahrscheinlich offengelegten Administratorkonten vorsorglich, bevor der Angreifer sie benutzt. Das ist nicht nur etwas für Konzerne: Attack Disruption ist auch in Microsoft Defender for Business enthalten, dem Paket für kleinere Unternehmen.

Bei Benutzern hat Microsoft die Frage also beantwortet: Die Maschine handelt, der Mensch prüft danach. Bei deinen Anwendungen sieht es anders aus.

Anwendungen und Dienste: Hier wartet die Abwehr

Attack Disruption kennt zwei Arten von Zielen: Geräte, auf denen der Defender-Agent läuft, und Benutzerkonten. Eine Azure Function, eine Web App oder ein Application Gateway ist nichts davon.

  • Web Apps und Functions: Defender for App Service erkennt Angriffe auf deine Anwendungen und gibt Empfehlungen ab. Eine automatische Gegenmassnahme ist nicht vorgesehen. Die Anwendung läuft weiter, während der Alarm auf jemanden wartet.
  • Application Gateway: Die Web Application Firewall blockiert einzelne bösartige Anfragen nach Regeln. Das ist wichtig, aber es ist ein Türsteher, kein Wachdienst. Ist der Angreifer schon drin, etwa über ein gestohlenes Dienstkonto, kommt er gar nicht über das Gateway.

Am deutlichsten wird die Lücke bei den Dienstkonten, mit denen deine Anwendungen auf Datenbanken, Speicher und Schlüssel zugreifen:

  • Registrierte Apps mit Zugriff auf Microsoft 365 werden von Attack Disruption erfasst. Liest eine kompromittierte App Postfächer aus, greift Defender automatisch ein.
  • Service Principals mit Azure-Rechten, also die Konten aus dem Fall Storm-3168, lassen sich über Conditional Access für Workload Identities automatisch blockieren. Das passiert, sobald Microsoft ein erhöhtes Risiko erkennt oder sich das Konto von ausserhalb bekannter Netze anmeldet. Dafür brauchst du die Zusatzlizenz Workload Identities Premium. Die Regel gilt nur für Dienstkonten aus deinem eigenen Tenant, und sie greift erst, wenn das Konto ein neues Token anfordert. Ein bereits ausgestelltes Token bleibt bis zum Ablauf gültig.
  • Managed Identities, die Konten hinter Functions und Web Apps, sind laut Microsoft ausdrücklich nicht abgedeckt, weder von Conditional Access noch von der Risikoerkennung. Sitzt ein Angreifer im Code einer Function, nutzt er deren Managed Identity, und nichts sperrt sie automatisch.

Das ist die Ironie: Microsoft empfiehlt Managed Identities zu Recht, weil es dort kein Passwort gibt, das in einem GitHub-Ticket landen kann. Storm-3168 wäre so wohl nicht passiert. Aber genau diese sicherste Art von Dienstkonto hat keinen automatischen Notschalter.

AWS wartet bewusst auf dich

AWS geht noch einen Schritt weiter Richtung Mensch. Der GuardDuty Investigation Agent, seit Juni 2026 in der Preview, analysiert einen Verdacht in Minuten und gibt Empfehlungen ab, ausführen tut er sie nicht. Beim Dienst AWS Security Incident Response kann AWS Server, Benutzer und Speicher zwar eindämmen, laut Dokumentation aber erst, nachdem du die Risiken geprüft und zugestimmt hast. Microsoft lässt die Maschine bei Benutzern handeln. AWS lässt sie ermitteln und dich entscheiden. Gegen einen Angreifer, der in sieben Minuten eine Umgebung löscht, kommt diese Entscheidung zu spät.

Was die Hersteller planen

Beide arbeiten daran. Microsoft hat im August 2026 Project Perception vorgestellt, ein System aus spezialisierten KI-Agenten, die Angriffspfade aufdecken, Alarme sortieren, Angriffe rekonstruieren und neue Erkennungsregeln schreiben. Es ist bisher nur für eingeladene Kunden verfügbar. Der Agent für die Behebung priorisiert heute, was zuerst repariert werden soll. Und laut Microsoft halten die Agenten vor folgenreichen Aktionen an und warten auf deine Freigabe. AWS hat im August 2026 seine Lösung Automated Security Response erweitert, mit der Funde automatisch behoben werden können. Diese Lösung rollst du allerdings selbst aus und konfigurierst sie selbst.

Die Richtung stimmt, aber was angekündigt ist, ermittelt und empfiehlt. Eine automatische Eindämmung für Web Apps, Functions und Managed Identities habe ich bei keinem der beiden gefunden, auch nicht angekündigt. Gemessen an Gartners Anspruch heisst das: Bei Benutzern und Geräten ist «prediction is protection» schon Realität. Bei deinen Anwendungen und Dienstkonten ist es noch ein Trend. Ich bin sicher, dass sich das ändert. Bis dahin musst du die Lücke selbst schliessen.

Was du jetzt tun kannst

  • Den Benutzerteil vollständig einschalten: Defender auf allen Geräten, Servern und Domain Controllern, die Automatik in den Gerätegruppen auf «voll». Jede Lücke dort ist ein blinder Fleck.
  • Dienstkonten automatisch blockieren lassen: Conditional Access für Workload Identities einrichten, mit einer Regel für erhöhtes Risiko und einer für unbekannte Netze.
  • Secrets abschaffen, wo es geht: Managed Identities statt Passwörtern. Was trotzdem ein Secret braucht, gehört in den Key Vault, nie in Code, Konfigurationsdateien oder Tickets. Ein veröffentlichtes Secret ist kompromittiert, auch wenn du es wieder löschst.
  • Rechte radikal begrenzen: Eine Function, die Dateien liest, braucht kein Recht, Storage Accounts zu löschen. Was das Dienstkonto nicht darf, kann auch ein Angreifer damit nicht tun.
  • Die Reaktion für deine Anwendungen selbst bauen: Defender for Cloud kann bei einem Alarm automatisch eine Logic App starten. Die kann einer Managed Identity die Rechte entziehen, eine Web App für alle ausser dem Admin-Netz sperren oder Schlüssel rotieren. Und lege fest, dass sie das ohne Freigabe tut. Sonst hast du dir die AWS-Philosophie nachgebaut.
  • Backups vor den eigenen Konten schützen: Storm-3168 hat zuerst die Sperren der Backups entfernt. Wer die Wiederherstellung löschen darf, sollte nicht dasselbe Konto sein, das die Anwendung betreibt.

Wenn du wissen willst, wo deine Azure-Umgebung heute selbst abwehrt und wo sie auf einen Menschen wartet, buch unten einen Termin, und wir schauen es uns gemeinsam an.