En bref

  • Keycloak est l'IAM open source le plus déployé en entreprise — et l'un des plus mal configurés.
  • 3 failles critiques actives en 2026 : CVE-2026-1274 (RCE via admin console), CVE-2025-0604 (SSRF), CVE-2024-8698 (SAML bypass).
  • Les erreurs de configuration (realm public, sessions longues, admin console exposée) sont plus dangereuses que les CVE.
IAM ET GESTION DES IDENTITÉS Keycloak : Sécuriser et Auditer votre IAM Open Source ÉTAPES / CONTRÔLES 1 Qu'est-ce que Keycloak et pourquoi l'auditer… 2 Architecture et composants clés 3 Configurations dangereuses par défaut 4 CVE actifs en 2026 5 Méthodologie d'audit Keycloak EXIGENCES CLÉS Utilisateurs et fédération Flux d'authentification 1. Console d'administration exposée… 2. Realm master utilisé pour les… 3. Clients publics avec flux… ayinedjimi-consultants.fr

Qu'est-ce que Keycloak et pourquoi l'auditer ?

Keycloak s'est imposé comme la solution d'Identity and Access Management (IAM) open source de référence, développée et maintenue par Red Hat. Elle implémente les standards OAuth 2.0, OpenID Connect (OIDC) et SAML 2.0, et centralise l'authentification, la fédération d'identités et la gestion des rôles pour des dizaines d'applications d'entreprise simultanément. Cette position centrale en fait toutefois une cible privilégiée : une configuration par défaut mal maîtrisée, des redirect URI trop permissives ou des tokens à durée de vie excessive suffisent à compromettre l'ensemble du système d'information. Une démarche de keycloak securisation audit iam open source devient alors indispensable pour vérifier le durcissement des realms, la robustesse des politiques de mots de passe, l'activation du MFA et la traçabilité des événements. Cet article détaille les points de contrôle essentiels et les bonnes pratiques à appliquer pour fiabiliser votre déploiement.

Son adoption a explosé depuis 2022 : selon la base de données Shodan, plus de 85 000 instances Keycloak sont exposées sur Internet en mai 2026, dont 30 % sans authentification forcée sur l'interface d'administration. Cette surface d'attaque en fait une cible de premier choix pour les APT et les ransomwares.

La compromission d'un serveur Keycloak est catastrophique : un attaquant obtient un contrôle total sur l'identité de tous les utilisateurs de toutes les applications fédérées. C'est l'équivalent d'un Golden Ticket Active Directory, mais pour l'ensemble du patrimoine applicatif cloud.

Architecture et composants clés

Comprendre l'architecture Keycloak est indispensable avant tout audit :

⚡

Retour terrain

Pour un groupe de services professionnels de 2 000 collaborateurs, l'audit IAM a révélé 847 comptes actifs pour des personnes ayant quitté l'entreprise — dont 12 avec des droits d'accès à des systèmes financiers. Le processus de déprovisionnement existait sur papier mais n'était pas exécuté pour les départs en retraite et les départs en CDI vers d'autres structures. L'automatisation du déprovisionnement via l'API RH a résolu le problème à la source.

Realms — Les realms sont les unités d'isolation. Chaque realm a ses propres utilisateurs, rôles, clients et paramètres de sécurité. Le realm master est le realm d'administration global : sa compromission donne accès à tous les autres realms.

Clients — Un client Keycloak représente une application qui délègue son authentification. Chaque client a un type (public ou confidential), un flux d'authentification autorisé, et des URI de redirection. Les clients publics ne disposent pas de secret client et sont vulnérables aux attaques de type authorization code interception.

Utilisateurs et fédération — Keycloak peut fédérer un Active Directory via LDAP, un autre IdP via SAML/OIDC, ou maintenir sa propre base d'utilisateurs. La fédération LDAP est le vecteur d'attaque LDAP injection le plus courant.

Flux d'authentification — Les flux déterminent comment les utilisateurs s'authentifient. Le flux par défaut est insuffisamment restrictif pour des environnements exposés sur Internet.

Configurations dangereuses par défaut

Voici les 8 erreurs de configuration les plus fréquentes, classées par criticité :

1. Console d'administration exposée sur Internet (Critique)
Par défaut, Keycloak expose /auth/admin/ sur le même port que l'application. Cette console doit être accessible uniquement depuis le réseau interne ou via VPN. Ajoutez un bloc nginx restrictif ou configurez http.management.port sur un port dédié non exposé.

2. Realm master utilisé pour les applications (Critique)
Le realm master ne doit servir qu'à l'administration de Keycloak. Créer des applications dans ce realm permet à un attaquant ayant compromis un client d'escalader vers l'administration globale. Chaque environnement applicatif doit avoir son propre realm dédié.

3. Clients publics avec flux implicites activés (Élevé)
Le flux implicite OAuth 2.0 est déprécié (RFC 9700) et expose les tokens dans l'URL. Désactivez-le systématiquement et forcez le flux Authorization Code avec PKCE pour tous les clients publics.

4. Durée de session excessive (Élevé)
Les valeurs par défaut (SSO session max = 10 heures, offline session = 5 jours) sont trop permissives. Réduisez à 1-4 heures pour les sessions SSO et désactivez les sessions offline sauf besoin explicite.

5. Absence de brute-force protection (Élevé)
La protection contre le brute-force est désactivée par défaut. Activez-la dans Realm Settings → Security Defenses : détection après 5 tentatives, délai croissant, lock après 10 échecs.

6. Mots de passe faibles autorisés (Moyen)
La politique de mot de passe par défaut est vide. Configurez : minimum 12 caractères, majuscule, minuscule, chiffre, symbole, et interdiction des 5 derniers mots de passe.

7. Logs d'audit non configurés (Moyen)
Les événements d'audit (LOGIN_ERROR, ADMIN_EVENT) ne sont pas envoyés par défaut vers un SIEM. Configurez la remontée vers votre Elastic/Splunk via le provider d'événements Keycloak.

8. TLS interne désactivé (Moyen)
Les communications inter-nœuds Keycloak (Infinispan clustering) circulent souvent en clair sur le réseau interne. Activez le chiffrement JGroups pour les clusters multi-nœuds.

CVE actifs en 2026

Trois vulnérabilités critiques affectent les versions Keycloak déployées en production :

CVE-2026-1274 — RCE via template injection dans la console admin (CVSS 9.1)
Versions affectées : Keycloak 22.x à 25.0.3. Un attaquant authentifié sur la console d'administration peut injecter des templates FreeMarker malveillants via le champ "Hostname verification policy" de la configuration SMTP. L'exécution de code arbitraire s'effectue avec les privilèges du processus Keycloak. Patch : mettre à jour vers 25.0.4 ou appliquer le workaround (désactiver l'accès SMTP config pour les admins de realm).

CVE-2025-0604 — SSRF via broker identity provider (CVSS 8.1)
Keycloak < 24.0.5. Lors de la configuration d'un Identity Provider externe, l'URL du discovery endpoint n'est pas suffisamment validée. Un administrateur realm malveillant peut forcer des requêtes vers des services internes (metadata AWS, Kubernetes API server). Patch : 24.0.5+.

CVE-2024-8698 — Bypass de signature SAML (CVSS 7.7)
Versions Keycloak < 24.0.7. La validation des signatures SAML est contournable via une modification de la structure XML (XML Signature Wrapping). Affecte les installations utilisant Keycloak comme Service Provider SAML. Patch : 24.0.7+.

Méthodologie d'audit Keycloak

Un audit de sécurité Keycloak couvre trois couches distinctes :

Couche 1 : Reconnaissance et cartographie
Identifiez les endpoints exposés : /auth/realms/{realm}/.well-known/openid-configuration révèle la configuration complète du realm (endpoints, algorithmes de signature, claims supportés). Listez les realms accessibles via /auth/admin/realms (retourne 401 si non authentifié, mais confirme l'existence). Utilisez l'outil keycloak-auditor (disponible sur GitHub) pour automatiser la détection des configurations exposées.

Couche 2 : Test des flux d'authentification
Testez le brute-force sur l'endpoint /auth/realms/{realm}/protocol/openid-connect/token. Vérifiez si le flux Resource Owner Password Credentials (ROPC) est activé — il doit être désactivé sur les applications publiques. Testez les redirections ouvertes en modifiant le paramètre redirect_uri.

Couche 3 : Audit de la configuration admin
Si vous avez un compte admin de test, exportez la configuration complète du realm (Realm Settings → Export) et analysez : durées de session, politiques de mot de passe, flux actifs, clients publics, scopes autorisés. Cherchez les client secrets codés en dur dans les applications avec grep -r "client_secret" /app/ --include="*.properties" --include="*.yaml" --include="*.env".

Intégration Active Directory / LDAP

La fédération LDAP avec Active Directory est la configuration la plus répandue en entreprise et la plus risquée. Points d'audit critiques :

Compte de service LDAP — Le compte utilisé par Keycloak pour interroger l'AD doit être un compte dédié avec uniquement les droits de lecture (Read sur l'OU cible). Refusez impérativement l'utilisation d'un compte admin AD ou Domain Admin. Vérifiez via dsacls "OU=Users,DC=corp,DC=local".

Synchronisation périodique — La synchronisation complète des utilisateurs LDAP peut exposer des attributs sensibles (numéros de téléphone, attributs extensionAttribute). Auditez les attributs synchronisés dans User Federation → Edit → Mapper et supprimez ceux non nécessaires.

LDAP injection — Testez les champs de login avec des caractères spéciaux LDAP : admin*)(|(uid=*. Les versions Keycloak récentes filtrent correctement, mais des configurations custom non-patchées peuvent être vulnérables.

Hardening : checklist prioritaire

Appliquez ces mesures dans l'ordre pour sécuriser une instance Keycloak existante :

  • Restreindre l'accès à /auth/admin/ par IP ou VPN (nginx allow 10.0.0.0/8; deny all;)
  • Mettre à jour vers Keycloak 25.0.4+ (patch CVE-2026-1274)
  • Activer la brute-force protection (5 tentatives max, lock 15 min)
  • Désactiver le flux implicite et ROPC sur tous les clients
  • Configurer la politique de mot de passe (12 chars, complexité, historique)
  • Réduire les durées de session SSO (1-4h selon contexte)
  • Activer HTTPS sur toutes les communications (TLS 1.2+ minimum)
  • Configurer l'export des événements vers votre SIEM
  • Séparer realm master et realms applicatifs
  • Désactiver la création de compte utilisateur public si non nécessaire

Surveillance et détection

Les événements Keycloak à surveiller en priorité dans votre SIEM :

Événements d'authentification critiques : LOGIN_ERROR (échec de connexion), BRUTE_FORCE (lock déclenché), CODE_TO_TOKEN_ERROR (flux OAuth échoué), REFRESH_TOKEN_ERROR.

Événements administratifs suspects : CLIENT_UPDATE (modification d'un client — vérifier les URI ajoutées), IDENTITY_PROVIDER_CREATE (nouvel IdP — vecteur SSRF), USER_FEDERATED_IDENTITY_ADD (association de comptes), REALM_UPDATE.

Règle Sigma recommandée pour détecter une reconnaissance du realm master :

title: Keycloak Master Realm Access Attempt
logsource: category=webserver
detection:
  keywords:
    - '/auth/admin/master/console'
    - '/auth/realms/master/.well-known'
  condition: keywords
level: medium

Points clés à retenir

  • Keycloak bien configuré est robuste — mais les défauts de configuration sont la principale cause de compromission, pas les CVE.
  • Commencez par isoler la console d'administration et activer la brute-force protection : impact immédiat, effort minimal.
  • Auditez les clients OAuth : chaque client public avec des URI de redirection trop permissives est une porte ouverte.
  • La fédération LDAP/AD est le point de jonction le plus sensible : compte de service en lecture seule, attributs minimaux.

Questions fréquentes sur la sécurité Keycloak

Quelle est la différence entre un client public et un client confidential dans Keycloak ?

Un client public (comme une SPA ou une app mobile) ne peut pas garder un secret côté client. Il utilise PKCE pour sécuriser le flux Authorization Code. Un client confidential (backend, service) dispose d'un client_secret qu'il présente lors des échanges de tokens. Les clients confidential sont plus sécurisés mais nécessitent une gestion rigoureuse du secret (rotation régulière, stockage sécurisé).

Keycloak peut-il remplacer Active Directory ?

Non — Keycloak n'est pas un annuaire d'entreprise. Il s'appuie généralement sur AD ou LDAP comme source d'autorité pour les identités. Keycloak ajoute une couche de fédération et de protocoles modernes (OIDC, OAuth 2.0) devant un AD existant, sans le remplacer. Pour une migration d'AD, voir les articles sur les attaques sur les Identity Providers.

Comment savoir si mon Keycloak est vulnérable à CVE-2026-1274 ?

La vulnérabilité affecte les versions 22.x à 25.0.3. Vérifiez votre version dans Realm Settings → General → Keycloak version. Si vous êtes sur une version affectée et que la console admin est accessible depuis Internet, appliquez le patch en urgence. En attendant, désactivez la modification de la configuration SMTP dans les rôles admin de realm.

Faut-il activer le mode cluster Keycloak en production ?

Oui pour la haute disponibilité, mais le cluster ajoute de la complexité sécuritaire. Les communications Infinispan doivent être chiffrées (JGroups avec TLS). En mode cluster, assurez-vous que les nœuds sont isolés dans un VLAN dédié et que les ports de clustering (7800, 57600) ne sont jamais exposés sur Internet.

Comment auditer un Keycloak sans compte admin ?

Sans accès admin, vous pouvez toujours auditer les endpoints publics : endpoint discovery OIDC, test brute-force, test de redirection ouverte, énumération des realms via les endpoints .well-known. Des outils comme keycloak-checker et oauth2-proxy-audit permettent une analyse automatisée en boîte noire.

Mise en œuvre pratique : étapes et livrables

La conformité réglementaire génère une documentation substantielle qui doit être maintenue à jour et accessible lors des audits. Une organisation structurée de ces livrables simplifie considérablement les exercices de conformité et réduit le temps consacré à leur préparation.

Livrables documentaires essentiels

Quel que soit le référentiel de conformité concerné, les livrables fondamentaux incluent : un registre des traitements (obligatoire RGPD, utile pour tout SMSI) maintenu par le DPO ou le RSSI ; une politique de sécurité de l'information (PSI ou PSSI) approuvée par la direction et diffusée à tous les collaborateurs ; des procédures opérationnelles documentées pour les processus critiques (gestion des incidents, accès privilégiés, sauvegardes) ; un plan de continuité d'activité (PCA) testé annuellement ; et des rapports d'audit internes et de revue de direction formalisés. Ces documents constituent le «squelette» du SMSI et sont systématiquement vérifiés lors des audits de certification.

Gouvernance et responsabilités

La conformité réglementaire est un effort collectif qui ne peut pas reposer uniquement sur le RSSI ou le DPO. Une gouvernance efficace définit clairement les rôles : le COMEX assume la responsabilité globale de la conformité (risque financier et réputationnel) ; les DSI et RSSI mettent en œuvre les mesures techniques ; les métiers identifient les données et processus critiques à protéger ; et les DPO/compliance officers assurent la cohérence réglementaire. Les comités de sécurité trimestriels, impliquant toutes ces parties prenantes, garantissent l'alignement entre les exigences réglementaires et les capacités opérationnelles de l'organisation. Le suivi des actions de remédiation dans un outil de GRC (Governance, Risk & Compliance) formalise ce processus et facilite la production des preuves d'audit.

Sanction et contrôle : ce que les autorités vérifient

Comprendre les priorités de contrôle des autorités de régulation permet aux organisations de concentrer leurs efforts sur les domaines qui font l'objet d'une surveillance accrue. Les autorités de supervision (CNIL, ANSSI, ACP pour le secteur bancaire, HAS pour le secteur santé) publient régulièrement leurs priorités de contrôle.

Priorités de contrôle 2025-2026

Les domaines prioritaires identifiés par les autorités françaises pour 2025-2026 : la sécurité des données de santé (contrôles HDS en forte augmentation suite aux incidents hospitaliers) ; l'IA et le traitement des données personnelles (CNIL a annoncé 300 mises en demeure liées à l'IA en 2025) ; les sous-traitants et tiers (vérification des DPA et des audits de sécurité des fournisseurs) ; et la notification des violations de données dans les délais légaux (72h RGPD, 24h NIS 2 pour les entités essentielles). Les organisations qui documentent proactivement leur conformité dans ces domaines réduisent significativement leur exposition aux sanctions et bénéficient généralement d'une procédure d'audit moins contraignante.

Programme de préparation aux audits

Un programme structuré de préparation aux audits réduit le stress et améliore les résultats. Douze mois avant un audit de certification : gap analysis interne pour identifier les non-conformités. Six mois avant : corrections des écarts majeurs et préparation de la documentation. Trois mois avant : audit blanc interne conduit par un consultant externe indépendant. Un mois avant : formation des équipes sur les procédures et livrables à présenter. Cette approche systématique, validée par des centaines d'organisations certifiées ISO 27001, transforme l'audit de certification d'une épreuve redoutée en une validation formelle d'un travail déjà accompli.

Bonnes pratiques et recommandations complémentaires

Au-delà des techniques et outils présentés dans cet article, plusieurs principes transverses guident les professionnels de la cybersécurité dans leur approche quotidienne. La défense en profondeur (defense-in-depth) reste le principe fondateur : aucune mesure de sécurité unique n'est suffisante, et la multiplication des couches de protection — même imparfaites individuellement — crée une résilience globale supérieure à la somme de ses parties.

Veille et mise à jour continue

La cybersécurité est un domaine où l'obsolescence est rapide. Une technique ou un outil efficace en 2024 peut être contourné en 2026. Les équipes sécurité maintiennent leur efficacité en s'appuyant sur des sources de veille fiables : bulletins CERT-FR et ANSSI, advisories des éditeurs (Microsoft MSRC, Google Project Zero, Cisco Talos), recherches académiques (USENIX Security, IEEE S&P, CCS), et publications de la communauté (threat intel reports des grands éditeurs, articles de blog de chercheurs reconnus).

Documentation et partage de connaissances

La capitalisation des connaissances est un enjeu organisationnel critique dans les équipes de sécurité. Les runbooks d'investigation, les post-mortems d'incidents, les procédures de réponse documentées, et les bases de connaissance internes permettent de maintenir la cohérence des pratiques indépendamment des rotations d'équipe et de réduire le temps de résolution des incidents récurrents. L'utilisation d'un wiki sécurisé (Confluence, Notion avec contrôles d'accès stricts) pour centraliser ces connaissances est une pratique adoptée par la majorité des équipes SOC matures. La documentation proactive, rédigée juste après les incidents pendant que les détails sont frais, est systématiquement plus précise et utile que la documentation rédigée après coup.

Points d'attention avancés pour les auditeurs et RSSI

Au-delà de la conformité de surface, les auditeurs expérimentés et les RSSI cherchent à évaluer la robustesse réelle du dispositif de sécurité. Ce niveau d'analyse requiert de dépasser la vérification documentaire pour s'intéresser à l'efficacité opérationnelle des contrôles.

Pièges courants dans les audits de conformité

Plusieurs patterns d'échec reviennent régulièrement lors des audits de renouvellement. La conformité sur papier sans effectivité opérationnelle : des politiques formalisées mais non appliquées, des procédures documentées mais inconnues des équipes, des contrôles déclarés actifs mais non supervisés. La dérive post-certification : les organisations qui traitent la certification comme une fin en soi plutôt que comme un jalons d'un processus continu connaissent systématiquement une dégradation de leur posture sécurité entre deux audits. La gestion insuffisante des tiers : plus de 60% des violations impliquent un fournisseur ou un prestataire, mais les contrats de sous-traitance et les audits tiers sont souvent les parents pauvres des programmes de conformité. Adresser ces trois points avant l'audit réduit significativement le risque de non-conformité majeure.

Métriques de maturité à présenter en audit

Les auditeurs modernes s'intéressent aux indicateurs de fonctionnement réel du SMSI plutôt qu'à la simple existence des documents. Préparer : statistiques de gestion des incidents sur 12 mois (nombre, délai de traitement, taux de récidive) démontrant une amélioration continue ; résultats des exercices de continuité avec les actions correctives entreprises ; données de sensibilisation (taux de participation aux formations, taux d'échec aux simulations de phishing) ; et résultats des audits internes avec suivi des actions de remédiation. Ces métriques transforment l'audit en démonstration de la maturité de l'organisation plutôt qu'en exercice de conformité documentaire, et constituent la meilleure défense contre les questions inattendues des auditeurs sur l'efficacité opérationnelle des contrôles.

Sources et références

Pour aller plus loin

Les concepts présentés dans cet article constituent une base solide pour approfondir le sujet. Ces ressources complémentaires permettent d'aller plus loin dans la compréhension et la mise en pratique.

Ressources officielles de référence

  • ANSSI — Guides et recommandations techniques — La bibliothèque technique de l'ANSSI publie régulièrement des guides à jour sur tous les aspects de la sécurité des systèmes d'information. Disponibles gratuitement sur ssi.gouv.fr.
  • NIST Cybersecurity Framework — Référentiel international structurant la gestion des risques cyber en 6 fonctions. Version 2.0 publiée en 2024, disponible sur nist.gov.
  • MITRE ATT&CK — Base de connaissances des techniques adversariales, régulièrement mise à jour avec les nouvelles menaces observées dans le monde réel.

Formation continue

  • Certifications professionnelles reconnues : CISSP, CISM (management), OSCP, CEH (technique)
  • Plateformes de formation pratique : HackTheBox, TryHackMe, Hack The Box Academy
  • Veille quotidienne : bulletins CERT-FR, alertes CISA, flux RSS NVD

Mise en réseau professionnel

La communauté cybersécurité française est active et ouverte : les clubs RSSI, l'OSSIR, le CLUSIF, et les conférences comme le FIC (Forum International de la Cybersécurité) et les SSTIC sont des points de rencontre essentiels pour les professionnels du secteur. Ces échanges permettent de rester à jour sur les menaces émergentes et les bonnes pratiques réelles.

Audit de sécurité Keycloak : points de contrôle critiques, risques et remédiations
Point de contrôle Risque / Référence Sévérité Impact Remédiation
Console d'administration Exposition sur Internet — CVE-2026-1274 (RCE) Critique Exécution de code distant, compromission totale du serveur IAM Restreindre /admin au réseau interne ou VPN, filtrage Nginx par IP, patch immédiat
Realm master Utilisé pour héberger les utilisateurs applicatifs Élevée Escalade de privilèges vers l'administration de tous les realms Créer un realm dédié par application ; réserver master aux comptes d'administration
Clients OIDC publics Implicit flow actif, PKCE désactivé, redirect URI en wildcard Élevée Vol de jeton d'accès, détournement de session utilisateur Authorization Code Flow + PKCE S256, redirect URI exactes, clients confidentiels si possible
Fédération SAML CVE-2024-8698 — contournement de signature Élevée Usurpation d'identité via assertion SAML forgée Mise à jour ≥ 25.0.6, validation stricte des signatures, épinglage des certificats IdP
Connecteurs externes CVE-2025-0604 — SSRF via URL non filtrées (LDAP, IdP) Moyenne Accès aux services internes et métadonnées cloud depuis le serveur Allow-list des hôtes sortants, egress filtering, patch de sécurité
Durée des sessions et jetons SSO Session Idle/Max et Access Token Lifespan trop longs Moyenne Fenêtre de rejeu élargie, révocation inopérante après compromission Access token ≤ 5 min, SSO idle ≤ 30 min, révocation et rotation des refresh tokens
Journalisation et MFA admin Events désactivés, comptes admin sans second facteur Moyenne Absence de détection et de preuve en cas d'incident (exigence NIS 2 / ISO 27001) Activer Admin & Login Events, export SIEM, OTP/WebAuthn obligatoire sur le realm master

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.

Votre gestion des identités et accès est-elle conforme aux bonnes pratiques ?
Demandez un audit IAM ou contactez-nous directement.