04.02 · Sécuriser
Gestion des identités et des accès
L’IAM n’est plus un sujet d’infrastructure — c’est le squelette de toute sécurité moderne. Et son maillon le plus faible n’est pas l’authentification, c’est l’offboarding.
Le mythe du SSO suffisant
Le déploiement d’un SSO d’entreprise (Okta, Entra ID, Google Workspace) est devenu l’étape la mieux maîtrisée de l’IAM. C’est aussi celle qu’on confond le plus volontiers avec le périmètre complet de la discipline. Or le SSO ne couvre, dans la plupart des organisations, que 40 à 60 % du parc applicatif. Le reste — applications anciennes, outils achetés en marge, intégrations tierces — vit en dehors.
Le cycle de vie identité — six étapes, deux maillons faibles
Une démarche IAM moderne couvre six étapes du cycle de vie d’une identité dans l’organisation. Deux d’entre elles concentrent la majorité des incidents : la variation (changement de poste) et l’offboarding.
Onboarding
Création des accès au moment de l’arrivée. Maîtrisé dans la majorité des organisations.
Authentification
SSO + MFA. Étape la mieux outillée, souvent confondue avec l’IAM complet.
Autorisation
Rôles et permissions. Tend à dériver vers le sur-droit faute de revue régulière.
Variation
Changement de poste, mutation, projet. L'étape la plus négligée — les anciens droits s'accumulent sur les nouveaux.
Revue d’accès
Audit périodique des permissions. Doit être trimestriel a minima sur les applications sensibles.
Offboarding
Révocation complète à la sortie. Le maillon le plus faible — surtout hors SSO.
Pourquoi l’offboarding échoue
L’offboarding échoue rarement pour des raisons techniques. Il échoue pour deux raisons structurelles : la liste des accès à révoquer n’est jamais à jour, et le délai entre l’annonce du départ et son effectivité crée une fenêtre de risque pendant laquelle la révocation est procéduralement difficile à exiger.
La réponse opérationnelle tient en trois éléments. D’abord, lier l’IAM au référentiel RH : tout départ déclenche automatiquement le workflow de révocation, sans dépendre d’un ticket. Ensuite, étendre la couverture SSO le plus possible — toute application hors SSO est une candidate à un compte oublié. Enfin, planifier une revue trimestrielle des comptes "orphelins" : comptes actifs sans propriétaire RH identifié.
Le principe du moindre privilège, version moderne
Le principe du moindre privilège — n’accorder que les permissions strictement nécessaires — est aussi ancien que la sécurité informatique. Sa version moderne ajoute deux exigences propres au SaaS : les permissions doivent être temporaires par défaut (toute permission élevée expire après usage ou période) et contextuelles (accordées selon le contexte d’accès : appareil, réseau, heure, géographie).
Cette évolution s’appelle souvent zero-trust. Au-delà du terme, l’idée pratique est simple : on ne fait plus confiance au réseau interne, on ne fait plus confiance à la session ouverte, on n’accorde plus de permission "à vie". Chaque accès se rejustifie en temps réel.
Ce qu’il faut retenir
- Le SSO ne couvre que la moitié du parc. La moitié non-SSO concentre les comptes oubliés et les fuites par accès résiduel.
- Six étapes du cycle de vie, deux maillons faibles : variation et offboarding. C’est là que l’investissement paie le plus.
- Le test ultime : un salarié parti il y a six mois peut-il encore se connecter à quelque chose ? Si oui, l’IAM n’est pas mature, quels que soient les outils déployés.