Sécurité opérationnelle IAM

Un système IAM mal opéré devient une cible de choix. Tokens trop longs, logs absents, secrets non rotationés, pas de runbook… Ce guide couvre les mesures de hardening essentielles, l’observabilité à mettre en place, et les procédures de réponse aux incidents. Parce que déployer Keycloak ne suffit pas — il faut l’opérer de manière sécurisée.

Ce que vous allez apprendre

Ce guide vous donne les clés pour opérer un système IAM en production. À la fin, vous saurez :

Identifier les menaces courantes : phishing, token theft, session hijacking
Appliquer les mesures de hardening : PKCE, durées courtes, rotation
Observer votre IAM : logs, métriques, alertes
Répondre aux incidents : playbooks, révocation, communication

Prérequis : avoir lu les guides OAuth 2.x, OIDC et MFA/WebAuthn.

Menaces courantes sur l’IAM

Phishing et credential harvesting

L’attaquant crée un faux site (ou email) pour capturer les credentials.

Variante	Description	Cible
Phishing classique	Faux formulaire de login	Mot de passe
Phishing TOTP	Capture OTP en temps réel	MFA classique
OAuth phishing	Fausse page d’autorisation	Code d’autorisation
Spear phishing	Ciblé sur une personne (admin, finance)	Comptes à privilèges

Mitigation :

MFA phishing-resistant (WebAuthn, passkeys)
Formation des utilisateurs
Filtrage email (SPF, DKIM, DMARC)

Token theft

Vol de tokens (access, refresh, session) pour usurper l’identité.

Vecteur	Comment	Impact
XSS	JavaScript malveillant lit le token en mémoire	Accès API
CSRF	L’utilisateur exécute une action sans le savoir	Changement d’état
Log exposure	Token loggé en clair	Persistence de l’attaque
Man-in-the-Middle	Interception réseau (HTTP, proxy mal configuré)	Tout

Mitigation :

Cookies HttpOnly, Secure, SameSite=Strict
Durées courtes (access token 5-15 min)
Rotation des refresh tokens
Validation de l’audience

Session hijacking et fixation

Ces deux attaques ciblent le mécanisme de session plutôt que les credentials. Elles sont souvent sous-estimées car elles ne nécessitent pas de casser un mot de passe.

Attaque	Description
Session hijacking	L’attaquant vole un session ID existant
Session fixation	L’attaquant force un session ID connu, puis attend que l’utilisateur se connecte

Mitigation :

Régénérer le session ID après login
Lier la session à l’IP / user-agent (avec prudence)
Durée de session limitée

Privilege escalation

L’attaquant obtient plus de droits que prévu.

Type	Exemple
Vertical	User → Admin
Horizontal	User A accède aux données de User B

Mitigation :

Valider les permissions côté serveur (pas seulement UI)
Principle of Least Privilege
Tests de politiques automatisés

Replay attacks

Rejouer un token ou une requête capturée.

Mitigation :

nonce dans les requêtes OIDC
Durées courtes + jti (JWT ID) unique
Token binding (lié à la session TLS)

Hardening : les mesures essentielles

OAuth / OIDC

Mesure	Pourquoi	Impact
PKCE obligatoire	Empêche l’interception du code	Tous les clients
Access token 5-15 min	Limite la fenêtre d’exploitation	Refresh plus fréquent
Refresh token rotation	Chaque usage génère un nouveau refresh	Détecte le vol
Audience validation	Empêche l’utilisation d’un token sur un autre service	Critique
Issuer validation	Vérifie que le token vient du bon IdP	Critique

JWT

// Checklist de validation JWT
function validateToken(token) {
  const decoded = jwt.decode(token, { complete: true });

  // 1. Signature valide
  jwt.verify(token, publicKey, { algorithms: ['RS256'] });

  // 2. Issuer attendu
  if (decoded.payload.iss !== 'https://auth.example.com') throw new Error('Invalid issuer');

  // 3. Audience correcte
  if (!decoded.payload.aud.includes('my-api')) throw new Error('Invalid audience');

  // 4. Non expiré
  if (decoded.payload.exp < Date.now() / 1000) throw new Error('Token expired');

  // 5. Not Before respecté
  if (decoded.payload.nbf > Date.now() / 1000) throw new Error('Token not yet valid');

  return decoded.payload;
}

Sessions

Paramètre	Recommandation
Durée de session	15-30 min inactive, 8h max absolue
Cookie flags	`HttpOnly`, `Secure`, `SameSite=Strict`
Régénération ID	Après chaque élévation de privilège
Invalidation	Logout = suppression côté serveur

Secrets et clés

Rotation régulière

Rotez les signing keys tous les 90 jours (automatisé).
Secret management

Utilisez un vault (HashiCorp Vault, AWS Secrets Manager).
Pas de secrets dans le code

Variables d’environnement ou fichiers montés, jamais en dur.
Audit des accès

Loggez qui accède aux secrets.

Observabilité IAM

Les 3 piliers

Pilier	Données IAM
Logs	Authentifications, autorisations, erreurs
Métriques	Latence, taux de succès/échec, MFA adoption
Traces	Parcours utilisateur, corrélation avec les apps

Logs critiques à collecter

Événement	Priorité	Détails à capturer
Login success/failure	Haute	User, IP, user-agent, timestamp, MFA utilisé
Token issuance	Haute	Client, scopes, audience
Token refresh	Moyenne	Refresh token ID, rotation
Logout	Moyenne	User, session ID
Password change	Haute	User, IP, méthode (self/admin)
MFA enrollment/unenroll	Haute	User, type d’authenticator
Admin actions	Critique	Qui, quoi, sur qui

Métriques clés

Métrique	Alerte si
Login failure rate	> 5% sur 5 min
MFA failure rate	> 10% (possible MFA fatigue attack)
Token refresh rate	Spike inhabituel
Latency P99 auth	> 2s
Active sessions	Spike ou chute brutale

Corrélation et contexte

User: alice@example.com
IP: 203.0.113.42 (nouveau pays: RU)
Action: Password change
Time: 03:47 UTC (inhabituel)
MFA: OTP (pas WebAuthn habituel)
→ ALERTE : Possible account takeover

Réponse aux incidents IAM

Types d’incidents

Incident	Gravité	Exemples
Credential compromise	Critique	Mot de passe admin fuité
Session hijack	Haute	Token volé, accès non autorisé
MFA bypass	Critique	Faille dans le flow MFA
Privilege escalation	Critique	User devient admin
DoS sur l’IdP	Haute	IdP indisponible = personne ne peut se connecter

Playbook : credential compromise

Containment immédiat
- Révoquer toutes les sessions de l’utilisateur
- Invalider tous les refresh tokens
- Désactiver le compte si nécessaire
Investigation
- Quand le credential a-t-il été compromis ?
- Quelles actions ont été effectuées ?
- D’autres comptes sont-ils affectés ?
Remediation
- Forcer un changement de mot de passe
- Réenrôler le MFA
- Vérifier les modifications (email, permissions)
Communication
- Informer l’utilisateur
- Notifier le management si données sensibles
- Déclaration réglementaire si nécessaire (RGPD, etc.)
Post-mortem
- Comment l’attaque s’est-elle produite ?
- Quelles mesures pour éviter la récidive ?

Playbook : token theft

Identifier le scope
- Quel token ? Access, refresh, session ?
- Quel utilisateur / service account ?
- Depuis quand ?
Révoquer
- Invalider le token (si token opaque + store)
- Révoquer le refresh token
- Terminier la session
Analyser l’impact
- Quelles API ont été appelées ?
- Quelles données ont été accédées ?
Renforcer
- Réduire la durée des tokens
- Activer la rotation des refresh tokens
- Ajouter token binding si possible

Révocation de tokens

Stratégies

Type de token	Stratégie de révocation
Access token (JWT)	Durée courte (5-15 min), pas de révocation individuelle
Access token (opaque)	Lookup en base, révocation immédiate
Refresh token	Store côté serveur, révocation par rotation ou explicite
Session	Store côté serveur, invalidation immédiate

Révocation globale

Pour une compromission majeure :

# Keycloak : révoquer toutes les sessions d'un realm
POST /admin/realms/{realm}/logout-all

# Keycloak : révoquer les sessions d'un utilisateur
POST /admin/realms/{realm}/users/{userId}/logout

Token introspection

Côté resource server, vérifiez si le token est toujours valide :

POST /oauth2/introspect
Content-Type: application/x-www-form-urlencoded

token=eyJhbGci...&token_type_hint=access_token

Réponse :

{
  "active": false,
  "reason": "Token revoked"
}

Rotation des secrets

Signing keys (JWT)

Générer une nouvelle clé

Ajouter à la JWKS sans supprimer l’ancienne.
Publier la nouvelle clé

La JWKS expose maintenant 2 clés (ancienne + nouvelle).
Basculer la signature

L’IdP signe les nouveaux tokens avec la nouvelle clé.
Attendre l’expiration

Les anciens tokens expirent naturellement.
Supprimer l’ancienne clé

Retirer de la JWKS après expiration du plus long token.

Client secrets

Étape	Action
1	Générer un nouveau secret
2	Configurer l’application avec le nouveau (dual-secret)
3	Tester que le nouveau fonctionne
4	Révoquer l’ancien secret
5	Supprimer l’ancien des configurations

Checklist de sécurité opérationnelle

Avant la mise en production

PKCE activé sur tous les clients
Access tokens ≤ 15 min
Refresh token rotation activée
Cookies HttpOnly, Secure, SameSite=Strict
MFA obligatoire pour les admins
Validation iss, aud, exp, nbf sur tous les tokens
Secrets dans un vault, pas dans le code

En production continue

Logs envoyés au SIEM
Alertes configurées (failure rate, anomalies)
Rotation des signing keys planifiée (90 jours)
Playbooks de réponse aux incidents documentés
Tests de pénétration réguliers (focus auth)
Revue des permissions et accès admin (trimestriel)

À retenir

Références

Prochaines étapes

Déployer Keycloak Mettez en pratique sur un IdP réel.