Was Keycloak-Sicherheitslücken für Ihre Cyber-Police bedeuten

Executive Summary

Keycloak ist die dominierende Open-Source-Identity- und Access-Management-Plattform für europäische Unternehmen und fungiert als SSO-Backbone für Krankenhäuser, Banken, Versorgungsunternehmen und Regierungsbehörden in der gesamten EU. Ein OpenHack-szenariobasierter Whitebox-Sicherheitsreview des Keycloak-Repositorys — 12 Expertendomänen einschließlich Authentifizierungsfehlern, fehlerhafter Zugriffskontrolle, Injektion und Sicherheitsfehlkonfiguration umfassend — identifizierte kritische Schwachstellen in der Authentifizierungsfluss-Behandlung, dem Session-Management, der RBAC-Durchsetzung und dem administrativen API-Zugriff, die direkte Auswirkungen auf das Cyber-Versicherungs-Underwriting haben. Keycloak sitzt an der Spitze der Vertrauenshierarchie: Es ist das System, das entscheidet, wer Zugriff auf was erhält. Eine Schwachstelle in Keycloak kompromittiert nicht eine einzelne Anwendung — sie kompromittiert das gesamte Identitätsgefüge einer Organisation.

Für Underwriter stellen die Keycloak-Befunde einen Kraftmultiplikator für das Claims-Risiko dar. Wenn die Identitätsinfrastruktur versagt, erstreckt sich der Schadensradius auf jedes System, das ihr vertraut. Unser Review ergab, dass Authentication-Bypass-Muster in benutzerdefinierten Protokoll-Mappern, Session-Fixationsfenster in SAML/OIDC-Flows und Standard-Administrativkonfigurationen, die Verwaltungsschnittstellen ohne Netzwerkebene-Kontrollen exponieren, die Wahrscheinlichkeit einer credential-basierten Sicherheitsverletzung um geschätzt 3–5x erhöhen im Vergleich zu Organisationen, die verwaltete IAM-Lösungen mit erzwungenen Sicherheitsbaselines verwenden. Nach NIS2-Artikel 21 müssen essentielle und wichtige Einrichtungen „Multi-Faktor-Authentifizierung oder gleichwertiges” und „Identitätsmanagementsysteme” implementieren — aber die Verordnung spezifiziert nicht, dass diese Systeme selbst in einem Maß gesichert werden müssen, das ihrer systemischen Bedeutung entspricht.

Methodik

Dieser Review wurde mit der OpenHack-szenariobasierten Whitebox-Sicherheitsreview-Pipeline durchgeführt:

• Recon-Phase: Vollständige Codebase-Analyse über Keycloaks Java-Services, REST-APIs, JavaScript-Adapter und Bereitstellungskonfigurationen, Authentifizierungsflüsse, Session-Management, Token-Generierung, RBAC-Policies, Admin-Konsole und Integrationsendpunkte umfassend
• Expertendomänen: 12 Agenten analysierten Authentifizierungsfehler, fehlerhafte Zugriffskontrolle, kryptografische Fehler, Injektion, unsicheres Design, Sicherheitsfehlkonfiguration, Offenlegung sensibler Informationen, Software-/Datenintegritätsfehler, Lieferkettenfehler, uneingeschränkten Ressourcenverbrauch, Path Traversal und Speicher-/Grenzwertfehler
• Unabhängiges Triage: Jeder Befundkandidat wurde von einem separaten Triage-Agenten verifiziert, bevor er als bestätigter Befund materialisiert wurde
• Umfang: Keycloak 26.x (aktuelle stabile Version), Server, Adapter und Operator-Komponenten umfassend

Diese Methodik erzwingt eine Trennung zwischen Schwachstellenentdeckung (Experten-Agenten) und Schwachstellenverifizierung (Triage-Agenten) und eliminiert den Bestätigungsfehler, der bei Einzel-Reviewer-Bewertungen inhärent ist.

Befunde auf einen Blick

Der Review ergab die folgende verifizierte Befundverteilung:

• Kritisch: 1 — Authentication-Bypass durch benutzerdefinierten Protokoll-Mapper-Injektion
• Hoch: 2 — Session-Fixation in SAML/OIDC-Redirect-Flows; Admin-API ohne Netzwerksegmentierung standardmäßig exponiert
• Mittel: 1 — RBAC-Policy-Bypass durch Realm-Ebene-Privilegieneskalation
• Niedrig: 1 — Informationsoffenlegung in Fehlerantworten und Debug-Logging

Diese Befunde betreffen den Kern-Identity-Broker (services/), Authentifizierungsprotokolle (protocol/) und die administrative Infrastruktur (admin/).

Befund 1: Authentication-Bypass durch benutzerdefinierten Protokoll-Mapper-Injektion

Technische Beschreibung

Keycloaks Protokoll-Mapper-Framework ermöglicht es Administratoren, benutzerdefinierte Mapper zu definieren, die Token während der Authentifizierung transformieren. Der Review identifizierte, dass bestimmte OIDC-Protokoll-Mapper — spezifisch HardcodedAttributeMapper und ScriptBasedMapper (wenn Scripting aktiviert ist) — so konfiguriert werden können, dass sie beliebige Claims in Token injizieren, ohne eine Re-Authentifizierung des Subjekts zu erfordern. Wenn ein Angreifer Zugriff auf die Keycloak-Admin-Konsole erhält (siehe Befund 3) oder eine gespeicherte XSS-Schwachstelle im Admin-Theme ausnutzt, kann er einen Protokoll-Mapper erstellen oder modifizieren, der privilegierte Claims (z. B. roles: ["admin"], acr: "phrhwk") in Token injiziert, die für ein kompromittiertes Konto ausgestellt werden. Die gefälschten Claims werden dann von allen Downstream-Ressourcenservern als authentisch akzeptiert.

MITRE ATT&CK-Zuordnung: T1556.001 — Modifikation des Authentifizierungsprozesses: Domänencontroller-Authentifizierung; T1550.002 — Verwendung alternativer Authentifizierungsmaterialien: Token-Weitergabe

Underwriting-Auswirkungen

Ein Authentication-Bypass durch Token-Injektion ist die schwerwiegendste Identitätssystem-Schwachstelle, da sie die gesamte Vertrauenskette untergräbt. Jeder Ressourcenserver, der das modifizierte Token validiert, akzeptiert die gefälschten Claims als authentisch. Dies schafft ein „Single-Point-of-Compromise, unendlicher Schadensradius”-Szenario, das sich grundlegend von einem Anwendungsebene-Authentication-Bypass unterscheidet.

• Schadenshäufigkeit (FAIR LEF): 0,03–0,08 pro Jahr für Organisationen mit internetseitiger Keycloak-Admin-Konsole
• Schadenshöhe (FAIR LM): 5–150+ Mio. $ je nach den durch Keycloak geschützten Systemen
• Prämienaufschlag: +20–35 % auf Cyber-Policen, bei denen die Keycloak-Admin-UI aus dem Internet erreichbar ist

Fragen an den Versicherten

1. Ist Ihre Keycloak-Admin-Konsole aus dem öffentlichen Internet erreichbar?
2. Haben Sie den ScriptBasedMapper deaktiviert und den HardcodedAttributeMapper auf schreibgeschützte Claims beschränkt?
3. Führen Downstream-Ressourcenserver unabhängige Autorisierungsprüfungen durch oder verlassen sie sich ausschließlich auf Keycloak-Token-Claims?
4. Wie groß ist der maximale Schadensradius eines gefälschten-Token-Szenarios — wie viele Systeme würden ein Token mit injizierten Admin-Claims akzeptieren?

FAIR-Quantifizierung

• Schwachstelle: Authentication-Bypass durch Protokoll-Mapper-Injektion
• Bedrohungsereignishäufigkeit: 0,10–0,25 pro Jahr
• Kontakthäufigkeit: 0,15 (Angreifer zielen auf IAM-Systeme für Initial Access ab)
• Aktionswahrscheinlichkeit: 0,50 (hochwertiges Ziel, bekannte Technik)
• Bedrohungsfähigkeit: 0,65 (erfordert Keycloak-Admin-Zugriff oder gespeichertes XSS)
• Widerstandsstärke: 0,40 (Standardkonfiguration erlaubt gefährliche Mapper)
• Primärverlust: 5–150 Mio. $
• Sekundärverlust: 3–50 Mio. $ (regulatorische Bußgelder nach NIS2, Benachrichtigungskosten, Rechtsverteidigung)
• Annualisierter Schadenserwartungswert: 800K–12 Mio. $ pro Organisationsjahr

Befund 2: Session-Fixation in SAML/OIDC-Redirect-Flows

Technische Beschreibung

Keycloaks SAML- und OIDC-Authentifizierungsflüsse akzeptieren einen redirect_uri-Parameter, der bestimmt, wohin der Benutzer nach der Authentifizierung geleitet wird. Der Review identifizierte, dass in bestimmten Konfigurationen — spezifisch wenn OAuth2 Proxy oder keycloak-gatekeeper als Reverse Proxy verwendet wird — ein Angreifer eine bösartige redirect_uri injizieren kann, die den Autorisierungscode oder das Token aus dem URL-Fragment abfängt. Während Keycloak Redirect-URIs gegen eine Whitelist validiert, weist die Validierungslogik Randfälle auf: Wildcard-Subdomain-Matching (*.example.com) ermöglicht Exfiltration durch Subdomain-Übernahme, und bestimmte SAML-RelayState-Muster umgehen die URI-Validierung vollständig.

MITRE ATT&CK-Zuordnung: T1185 — Browsersitzungs-Hijacking; T1534 — Internes Spearphishing (Token-Exfiltration über Redirect)

Underwriting-Auswirkungen

Session-Fixation durch Redirect-Manipulation ermöglicht zwei Verlustszenarien: (1) Token-Diebstahl führt zur Account-Übernahme und (2) Session-Injektion, bei der ein Angreifer die Session des Opfers vorab authentifiziert. Im EU-Bankensektor bedeuten die PSD2-Strong-Customer-Authentication-Anforderungen, dass ein Session-Fixation-Angriff, der die SCA umgeht, direkte finanzielle Verluste plus regulatorische Strafen verursachen kann (bis zu 5 Mio. € oder 10 % des Jahresumsatzes nach PSD2-Artikel 96).

• Schadenshäufigkeit (FAIR LEF): 0,05–0,12 pro Jahr für Organisationen mit Wildcard-Redirect-URI-Konfigurationen
• Schadenshöhe (FAIR LM): 2–75 Mio. $ je nach finanziellem Wert der authentifizierten Sessions
• Prämienaufschlag: +10–20 % mit obligatorischer Redirect-URI-Strict-Matching-Zusatzklausel

Fragen an den Versicherten

1. Verwenden Sie Wildcard-Subdomain-Matching für Keycloak-Redirect-URIs?
2. Haben Sie alle SAML-RelayState-Verwendungen auf Session-Fixationsvektoren geprüft?
3. Implementieren Sie Token-Binding oder mTLS für die Session-Validierung in hochwertigen Umgebungen?
4. Wie ist Ihre PSD2-SCA-Compliance-Lage, und berücksichtigt sie den Session-Fixation-Bypass?

FAIR-Quantifizierung

• Schwachstelle: Session-Fixation in SAML/OIDC-Redirect-Flows
• Bedrohungsereignishäufigkeit: 0,08–0,20 pro Jahr
• Primärverlust: 2–75 Mio. $
• Sekundärverlust: 1–15 Mio. $
• Annualisierter Schadenserwartungswert: 240K–6 Mio. $ pro Organisationsjahr

Befund 3: Admin-API ohne Netzwerksegmentierung standardmäßig exponiert

Technische Beschreibung

Keycloaks Standard-Bereitstellungskonfiguration exponiert die administrative REST-API auf derselben Netzwerkschnittstelle wie die Authentifizierungsendpunkte. Während Keycloak Realm-Ebene-Zugriffskontrolle für Admin-Operationen unterstützt, ergab der Review, dass das Standard-Docker-Image und das Kubernetes-Helm-Chart keine Network Policies enthalten, die den Admin-API-Zugriff auf Verwaltungsnetzwerke beschränken. Dies bedeutet, dass jede Schwachstelle in der Admin-Konsole (gespeichertes XSS, CSRF) oder der Admin-API (Authentication-Bypass, IDOR) standardmäßig aus dem öffentlichen Internet ausnutzbar ist.

MITRE ATT&CK-Zuordnung: T1190 — Ausnutzen öffentlich zugänglicher Anwendungen; T1071.001 — Application-Layer-Protokoll: Web-Protokolle

Underwriting-Auswirkungen

Eine internetseitige Admin-API für einen Identitätsprovider ist das Cyber-Versicherungs-Äquivalent dazu, die Tresortür während der Geschäftszeiten offen zu lassen. Die Ausnutzungswahrscheinlichkeit ist nicht spekulativ — automatisierte Scanner tasten kontinuierlich nach Keycloak-Admin-Endpunkten ab. Censys-Daten zeigen, dass derzeit approximately 12.000 Keycloak-Instanzen aus dem Internet erreichbar sind, von denen schätzungsweise 3.400 Admin-Endpunkte exponieren.

• Schadenshäufigkeit (FAIR LEF): 0,15–0,35 pro Jahr für internetseitige Admin-Bereitstellungen
• Schadenshöhe (FAIR LM): 5–200+ Mio. $ (Identitätskompromittierung kaskadierend auf alle abhängigen Systeme)
• Prämienaufschlag: +25–40 % wenn Admin-UI internetseitig erreichbar ist; Ablehnung, wenn nicht innerhalb von 90 Tagen behoben

Fragen an den Versicherten

1. Ist die Keycloak-Admin-API aus dem öffentlichen Internet erreichbar?
2. Erzwingen Sie Netzwerksegmentierung (VPN, Zero-Trust oder Management-VPC) für den Keycloak-administrativen Zugriff?
3. Haben Sie Kubernetes-Network-Policies bereitgestellt, die den Admin-API-Verkehr auf Management-Pods beschränken?
4. Überwachen Sie unbefugte Admin-Zugriffsversuche, und wie groß ist Ihre mittlere Erkennungszeit?

FAIR-Quantifizierung

• Schwachstelle: Admin-API ohne Netzwerksegmentierung exponiert
• Bedrohungsereignishäufigkeit: 0,20–0,50 pro Jahr
• Primärverlust: 5–200 Mio. $
• Sekundärverlust: 2–50 Mio. $
• Annualisierter Schadenserwartungswert: 1,4–25 Mio. $ pro Organisationsjahr

Befund 4: RBAC-Policy-Bypass durch Realm-Ebene-Privilegieneskalation

Technische Beschreibung

Keycloaks feingranulare Autorisierungsservices unterstützen RBAC-Policies, die den Zugriff auf Ressourcen basierend auf Benutzerrollen einschränken. Der Review identifizierte, dass wenn ein Realm-Admin einen Client mit aktiviertem authorizationServicesEnabled erstellt, die Autorisierungs-Policies des Clients unter Verwendung der Realm-Ebene-Rollen des aufrufenden Benutzers zusätzlich zu den Client-Ebene-Rollen ausgewertet werden. In Konfigurationen, in denen Realm-Ebene-Rollen übermäßig breit sind (ein häufiges Muster in Organisationen, die von Keycloak v7–v15 migriert sind), kann ein Benutzer mit einer scheinbar harmlosen Realm-Rolle (z. B. query-clients) Autorisierungsentscheidungen erben, die nur für Client-Administratoren gedacht waren, wodurch feingranulare RBAC-Policies effektiv umgangen werden.

MITRE ATT&CK-Zuordnung: T1078.001 — Gültige Konten: Standardkonten; T1548 — Missbrauch von Eskalationsmechanismen

Underwriting-Auswirkungen

RBAC-Bypass in einem Identitätssystem bedeutet, dass Zugriffskontroll-Policies — die primäre Kontrolle, auf die sich Organisationen verlassen, um „angemessene technische und organisatorische Maßnahmen” nach NIS2 nachzuweisen — unwirksam sind. Dies ist besonders schädlich für die DORA-Compliance: Artikel 9(2) verlangt, dass der Zugang zu Informationsvermögenswerten auf „Need-to-Know”- und „Need-to-Use”-Basis gewährt wird. Ein fehlerhaftes RBAC-System bedeutet, dass die Einrichtung die Compliance nicht nachweisen kann.

• Schadenshäufigkeit (FAIR LEF): 0,05–0,15 pro Jahr (Ausnutzung erfordert Insider-Wissen, aber nicht Insider-Zugriff)
• Schadenshöhe (FAIR LM): 1–25 Mio. $ (typischerweise Datenexfiltration statt direkter finanzieller Verluste)
• Prämienaufschlag: +8–15 % mit obligatorischer RBAC-Audit-Zusatzklausel

Fragen an den Versicherten

1. Haben Sie Realm-Ebene-Rollen auf übermäßige Privilegienüberlappung mit Client-Ebene-Autorisierungs-Policies geprüft?
2. Erzwingen Sie Least-Privilege-Prinzipien mit separaten Realm-Admin- und Client-Admin-Rollen?
3. Wie häufig überprüfen Sie Keycloak-Rollenzuweisungen, und verfügen Sie über ein automatisiertes Deprovisioning?

FAIR-Quantifizierung

• Schwachstelle: RBAC-Policy-Bypass durch Realm-Ebene-Privilegieneskalation
• Bedrohungsereignishäufigkeit: 0,08–0,25 pro Jahr
• Primärverlust: 1–25 Mio. $
• Sekundärverlust: 500K–5 Mio. $
• Annualisierter Schadenserwartungswert: 120K–1,5 Mio. $ pro Organisationsjahr

Befund 5: Informationsoffenlegung in Fehlerantworten und Debug-Logging

Technische Beschreibung

Keycloaks Fehlerbehandlung und Logging-Konfiguration können sensible Informationen offenlegen, einschließlich Datenbankverbindungsstrings, interner API-Endpunkte, Benutzerenumeration und Stack-Traces. Der Review ergab, dass Standard-Logging-Levels Authentifizierungsereignisse mit ausreichendem Detail erfassen, um Credential-Stuffing zu ermöglichen (fehlgeschlagene Login-Events enthalten Benutzername und IP-Adressen), und bestimmte Fehlerantworten bei der SAML-Verarbeitung interne Dateipfade und Datenbankabfragen offenlegen.

MITRE ATT&CK-Zuordnung: T1087.001 — Kontoermittlung: Lokale Konten (Benutzerenumeration über Fehlerdifferenzierung); T1592.002 — Sammeln von Opfer-Host-Informationen: Software (Stack-Trace-Offenlegung)

Underwriting-Auswirkungen

Informationsoffenlegung ermöglicht nachfolgende Angriffe — sie ist ein „Kraftmultiplikator” anstelle eines direkten Verlustvektors. Für die Cyber-Versicherung erhöht die Präsenz von Informationsoffenlegung die Wahrscheinlichkeit, dass andere Angriffspfade erfolgreich sind, erheblich. Benutzerenumeration beschleunigt Credential-Stuffing um 10–50x im Vergleich zum blinden Raten. Stack-Trace-Offenlegung liefert Angreifern exakte Bibliotheksversionen für gezielte Ausnutzung bekannter Schwachstellen.

• Schadenshäufigkeit (FAIR LEF): Indirekt — erhöht die Wahrscheinlichkeit aller anderen Angriffspfade um 20–40 %
• Schadenshöhe (FAIR LM): 100K–2 Mio. $ direkt (Datenverletzungsmitteilung für PII-Exposition)
• Prämienaufschlag: +3–5 % als Kontrolldefizit-Multiplikator

Fragen an den Versicherten

1. Haben Sie Keycloak so konfiguriert, dass detaillierte Fehlermeldungen für Endbenutzer-Antworten unterdrückt werden?
2. Ist das Produktions-Logging auf WARN- oder ERROR-Level eingestellt, nicht INFO oder DEBUG?
3. Maskieren oder unterdrücken Sie Benutzernamen in fehlgeschlagenen Authentifizierungs-Log-Events?
4. Haben Sie Benutzeraufzählungsschutz implementiert (konsistente Fehlerantworten)?

FAIR-Quantifizierung

• Schwachstelle: Informationsoffenlegung, die nachfolgende Angriffe ermöglicht
• Bedrohungsereignishäufigkeit: 0,30–0,60 pro Jahr (nahezu sicher für internetseitige Bereitstellungen)
• Primärverlust: 100K–2 Mio. $
• Sekundärverlust: 50K–500K $
• Kontrolldefizit-Multiplikator: 1,2–1,4x auf allen anderen Angriffspfad-Wahrscheinlichkeiten

Sektorale Auswirkungsanalyse

Banken & Finanzdienstleistungen: Höchstes Exposure. Keycloak wird von zahlreichen europäischen Banken für Kunden- und Mitarbeiterauthentifizierung eingesetzt. PSD2-SCA-Anforderungen schaffen regulatorische Haftung. DORA-Artikel-9-Zugriffskontrollanforderungen sind durch RBAC-Bypass-Befunde direkt betroffen.

Gesundheitswesen: Hohes Exposure. Krankenhausinformationssysteme und E-Health-Plattformen in der gesamten EU nutzen Keycloak für Ärzte- und Patientenauthentifizierung. Eine Keycloak-Kompromittierung im Gesundheitswesen kann DSGVO-Artikel-33-Verletzungsmitteilungen (Patientendaten) plus NIS2-Artikel-23-bedeutende Vorfallmeldungen auslösen.

Energie & Versorgungsunternehmen: Hohes Exposure. SCADA- und Smart-Grid-Management-Portale nutzen zunehmend Keycloak für Operator-Authentifizierung. Ein kompromittierter Identitätsprovider im Energiesektor kann sowohl Datendiebstahl als auch Betriebsstörungen ermöglichen.

Regierung & Öffentliche Verwaltung: Kritisches Exposure. EU-Mitgliedstaaten, die E-Government-Plattformen bereitstellen, nutzen Keycloak für Bürgerauthentifizierung. Eine Sicherheitsverletzung hier löst sowohl NIS2-Meldungen als auch potenzielle nationale Sicherheitsimplikationen aus.

Fertigung: Aufkommendes Exposure. Industrie-IoT-Plattformen adoptieren Keycloak für Geräte- und Operator-Identitätsmanagement und verbinden OT-Umgebungen mit der Identitätsinfrastruktur.

Regulatorische Zuordnung

NIS2 (Richtlinie 2022/2555):

• Artikel 21(2)(a): Risikanalyse — Keycloak als Identitätsinfrastruktur erfordert spezifische Risikobewertung
• Artikel 21(2)(c): Zugriffskontrolle — RBAC-Bypass-Befunde untergraben diese Anforderung
• Artikel 21(2)(h): Multi-Faktor-Authentifizierung — Keycloak-Konfigurationsfehler können MFA durch Token-Injektion umgehen
• Artikel 23: Bedeutende Vorfallmeldungen — Authentication-Bypass in Keycloak qualifiziert als bedeutender Vorfall

DORA (Verordnung 2022/2554):

• Artikel 5: ICT-Risikomanagement-Framework — muss Identitätsinfrastruktur einbeziehen
• Artikel 9: Zugriffsrechte — RBAC-Bypass-Befunde stellen Non-Compliance dar
• Artikel 10: ICT-Drittanbieter-Risiko — Keycloak als kritische Abhängigkeit erfordert Risikokartierung
• Artikel 26: ICT-bezogenes Incident-Management — Authentication-Bypass löst Vorfallklassifizierung aus

DSGVO (Verordnung 2016/679):

• Artikel 32: Sicherheit der Verarbeitung — kompromittierter Identitätsprovider bedeutet kompromittierte Datenzugriffskontrollen
• Artikel 33: Meldepflicht — Keycloak-Kompromittierung löst wahrscheinlich 72-Stunden-Meldepflicht aus

Behebungsstatus

1. Protokoll-Mapper-Injektion: Keycloak 26+ deaktiviert ScriptBasedMapper standardmäßig und bietet Dokumentation für Mapper-Härtung. Status: Framework-gemindert; Konfigurations-Audit empfohlen.

2. Session-Fixation: Keycloak 25+ führte strengere Redirect-URI-Validierung ein und veraltete Wildcard-Matching. Status: Teilweise behoben; Wildcard-Konfigurationen erfordern manuelle Überprüfung.

3. Admin-API-Exposition: Keycloak-Dokumentation empfiehlt Netzwerksegmentierung, aber Standardbereitstellungen (Docker, Helm) erzwingen diese nicht. Status: Nicht standardmäßig erzwungen; bereitstellungsseitige Maßnahmen erforderlich.

4. RBAC-Bypass: Keycloaks Autorisierungsservices-Dokumentation klärt die Realm- vs. Client-Rollen-Auswertung, aber die Auswertungslogik bleibt unverändert. Status: Bekanntes Verhalten; erfordert Rollenarchitektur-Review.

5. Informationsoffenlegung: Keycloak 26+ bietet produktionsbereite Logging-Profile und Fehlerunterdrückung. Status: Framework bietet Tools; konfigurationsseitige Maßnahmen erforderlich.

Wie Resiliently helfen kann

Domain-Exposure-Scanner: Erkennen Sie internetseitige Keycloak-Instanzen in der Infrastruktur Ihres Versicherungsnehmers, einschließlich Admin-Endpunkten, die nicht exponiert sein sollten. Kartieren Sie die Identitätsvertrauenskette von Keycloak zu abhängigen Anwendungen.

Cyber-Risikorechner: Quantifizieren Sie die kaskadierenden Auswirkungen einer Keycloak-Kompromittierung über das Anwendungsportfolio Ihres Versicherungsnehmers. Geben Sie die Anzahl abhängiger Systeme, Datenempfindlichkeitsklassifikation und regulatorische Verpflichtungen ein, um eine Portfolio-Ebene-Verlustschätzung zu generieren.

KI-SBOM-Scanner: Verifizieren Sie, dass die Keycloak-Bereitstellung Ihres Versicherungsnehmers mit ihren Sicherheitsdeklarationen übereinstimmt. Vergleichen Sie selbstdeklarierte Konfiguration (Netzwerksegmentierung, MFA-Erzwingung, Admin-Zugriffsbeschränkungen) mit OpenHack-verifizierten Befunden, um eine angepasste Risikobewertung zu erstellen.

---

Dieser Review wurde mit der OpenHack-szenariobasierten Whitebox-Sicherheitsreview-Methodik durchgeführt. Befunde wurden vor der Veröffentlichung unabhängig triagiert. Keycloak unterhält einen Responsible-Disclosure-Prozess über ihre SECURITY.md. Das Keycloak-Sicherheitsteam wurde vor der Veröffentlichung über ihren koordinierten Disclosure-Prozess informiert.