AI verändert den Takt bei Angriffsversuchen im Cyberspace – Verteidiger müssen Schritt halten. Doch wie wird sinnvoll reagiert, wenn Angreifer eine KI immer schneller und flexibler nutzen und so herkömmliche Abwehrsysteme an ihre Grenze bringen? In diesem Beitrag beantworten wir zentrale Fragestellungen rund um Continuous Verification und wollen zeigen, wie sich mit Keycloak ein Zero‑Trust‑Ansatz pragmatisch realisieren lässt.
Sind Ansätze die nur auf der Erkennung von Bedrohungen basieren für IAM noch ausreichend?
Viele Sicherheitsarchitekturen setzen implizit auf Vorhersagbarkeit: Man erkennt bekannte Muster, klassifiziert Anomalien und trifft Entscheidungen im Nachhinein. Im Identity‑Kontext entsteht daraus ein strukturelles Risiko: Die Bedrohungsanalyse erfolgt erst, nachdem ein Zugriff bereits stattgefunden hat: Events aus IAM und der Anwendung werden zentral im Backend aggregiert und analysiert, um Angriffsmuster und unbefugte Zugriffe zu erkennen. Erfolgt eine Validierung des Zugriffs primär beim Login, sind IAM-Systeme mit lange Sitzungsdauern und globalen Berechtigungen ein attraktives Angriffsziel. Gelingt die initiale Umgehung – etwa durch Phishing oder Session‑Diebstahl – können sich Angreifer oft unbemerkt bewegen und werden nicht entdeckt, oder erst wenn sie schon wieder weg sind.
Keycloak adressiert diesen blinden Fleck nicht mit „mehr Erkennung“, sondern mit mehr, bzw. ständiger Validierung und kontinuierlicher Autorisierung: Policies werden bei jeder Anfrage ausgewertet, Zugriffe bleiben so kontextabhängig und sind sofort blockierbar. So wird das Risiko vom Zeitpunkt der Anmeldung und der Session entkoppelt.
Wie lässt sich Zero Trust als „Kontrollsystem“ mit Keycloak umsetzen?
Zero Trust versteht sich nicht als Orakel, das Bedrohungen erkennen möchte, sondern grenzt ein, was ausgeführt werden kann: Nur was explizit erlaubt ist, darf stattfinden – und dass bei jeder Aktion, bei jedem Zugriff. Keycloak bringt hierfür die wichtigsten Bausteine mit:
- Authorization Services für fein granulare Richtlinien (RBAC, ABAC/CBAC, zeitbasierte und JavaScript‑Policies), die per Policy Enforcement Point (PEP) Anwendungen integrieren und für jeden Request ausgewertet und durchgesetzt werden.
- Token‑Härtung durch kurze Gültigkeiten, präzise Scopes/Audiences und Token Exchange zum Downscoping in nachgelagerte Dienste.
- Schnelle Widerrufbarkeit via Back‑Channel‑Logout und Session‑Invalidation, damit Entscheidungen nicht an Token‑Lebensdauer gebunden sind.
Im Ergebnis entsteht ein Identitäts‑Kontrollsystem, das nicht „rät“, bzw. beobachtet und erkennt, sondern begrenzt – ganz im Sinn von Zero Trust.
Wie reduziert Continuous Verification in Keycloak den „Blast Radius“ unbekannter Bedrohungen?
Statt auf Signaturen oder die Erkennung von Angriffen in Logdaten zu vertrauen, setzt Continuous Verification auf die laufende Bestätigung von Identität, Kontext und Berechtigung. Mit Keycloak gelingt das auf drei Ebenen:
Identität: Nutzung moderner Anmeldeverfahren. Passkeys/WebAuthn bieten phishingsichere Primärauthentisierung, die sich um Step‑up (z. B. PushOTP) erweitern lässt. Über kontextsensitive Flows können zusätzliche Faktoren dort eingefordert werden, wo das Risiko höher ist – etwa bei sensiblen Aktionen, neuen Geräten oder ungewohnten Umgebungen.
Anwendung/API: Zugriffentscheidungen aus der Verantwortung der Anwendung/Service herausnehmen. Der PEP prüft Richtlinien bei jeder Anfrage; Änderungen an Policies greifen ohne Re‑Deployments der Anwendungen. Für besonders feingranulare Freigaben unterstützt Keycloak UMA 2.0, wodurch Berechtigungen sogar Anfrage-bezogen erteilt werden können.
Sitzungen und Widerruf: Kürzere Token‑TTLs konsequent konfigurieren und Back‑Channel‑Logout nutzen, um aktive Sitzungen zentral zu beenden. So wird die Verwertbarkeit gestohlener Tokens reduziert und der Zeitraum eventuell vorhandener Fehlkonfigurationen die zu weitreichenden Berechtigungen führen könnten deutlich verkürzt werden.
Wie geht es weiter, wenn KI‑gestützte Angriffe zur Normalität werden?
Je weniger man sich auf Erkennung verlassen muss, desto widerstandsfähiger wird das System. Neben der erwähnten Per‑Request‑Autorisierung und kurzen Token-TTLs besteht ein weiterer Ansatz: Ereignisgetriebene Maßnahmen. Über das OpenID Shared Signals Framework (SSF) und das Continuous Access Evaluation Profile (CAEP) lassen sich sicherheitsrelevante Ereignisse in Anwendungen und im IAM – zum Beispiel ein sprunghafter Risikoanstieg oder ein kompromittiertes Konto – in Echtzeit in Sicherungs-Maßnahmen übersetzen: Session beenden, erneute Authentisierung verlangen oder Step‑up erzwingen.
Wichtig ist die Einordnung: SSF/CAEP sind noch nicht Teil des Keycloak‑Kerns. Es existiert eine Community‑Erweiterung (PoC), die in Pilotumgebungen sehr vielversprechende Ergebnisse bringt. Für den produktiven Einsatz ist es noch zu früh, aber wichtig ist zu verstehen, dass hier ein mächtiger, standardisierter Mechanismus entsteht, der in Zukunft eine wichtige Rolle in der Abwehr zunehmend komplexer Angriffsmuster spielen wird.
Wo liegen die typischen Stolpersteine?
Viele Organisationen scheitern weniger an der Technik als an der Disziplin der Umsetzung. Lange Sitzungen aus Komfortgründen vergrößern den Blast Radius. Nur‑Login‑Prüfungen ohne Policies und globale Berechtigungs-Scopes lassen die wichtigen Security-Richtlinien im Tagesgeschäft verpuffen und führen oft zu implizitem Vertrauen. Und mit fehlendem oder unzureichendem Monitoring bleibt oft unklar, ob Revokes, Step‑ups und Denies dort ankommen, wo sie sollen. Kontinuierliche Verifikation braucht auch hohe Standards im Betrieb: klar definierte Prozesse, Automatisierung, Monitoring und regelmäßige Policy‑Reviews.
Fazit
Wer sich beim Identity‑Schutz allein auf Beobachtung und Erkennung verlässt, spielt gegen die Zeit – und gegen Gegner, die KI zunehmend professionell nutzen. Continuous Verification verschiebt den Schwerpunkt: weg vom einmaligen „Erlauben“, hin zum laufenden Bestätigen und begrenzen. Keycloak bietet dafür heute schon entscheidenden Stellschrauben: Per‑Request‑Autorisierung, kurze & eng berechtigte Tokens, adaptive Authentifizierung und – in Zukunft – ereignisgetriebene Sitzungssteuerung. So entsteht eine Zero‑Trust‑Architektur, die robust bleibt, selbst wenn herkömmliche Erkennungsmechanismen versagt.
Wenn Du diesen Weg gehen möchtest,unterstützen wir Dich gerne– vom Architektur‑Review über Design und Rollout bis zur User Migration und der Einführung von Passkey oder einem SSF/CAEP‑Pilot für Deine kritischsten Workloads.
