Gestion des identités et des accès : cycle de vie, MFA et modèles d'autorisation

Chaque décision de contrôle d'accès prise par un système repose sur deux faits : qui fait la demande, et ce que cette personne ou ce programme a le droit de faire. La gestion des identités et des accès (IAM) est la discipline qui consiste à garder ces deux faits exacts — pas seulement au moment où un compte est créé, mais à travers les promotions, les mutations, les prestataires, les acquisitions, les services décommissionnés et la longue traîne de comptes que personne ne se souvient d'avoir accordés. C'est là que la sécurité échoue le plus souvent en silence, car une permission obsolète ne produit aucun message d'erreur.

Pour un développeur, l'IAM se traduit par des choix concrets : quels facteurs d'authentification prendre en charge, comment stocker les identifiants, de quel modèle d'autorisation le domaine a réellement besoin, comment recevoir les comptes utilisateurs depuis l'annuaire d'un client, et que faire des identités machines, désormais plus nombreuses que les identités humaines. Les protocoles qui transportent l'identité d'un système à l'autre — OAuth 2.0 pour l'accès délégué et OpenID Connect pour la connexion fédérée — sont traités à part ; ce guide porte sur le modèle qui les sous-tend.

Le cycle de vie des identités

Un compte a une vie, que l'on décrit généralement en trois temps : arrivée, mobilité, départ (joiner, mover, leaver).

Arrivée. Une source faisant autorité — le SIRH pour les salariés, un registre des contrats pour les fournisseurs, un parcours d'inscription pour les clients — crée l'identité. Les accès sont accordés à partir d'un socle défini pour le poste, et non en copiant les permissions d'un collègue existant, une habitude qui propage les privilèges comme une rumeur.

Mobilité. Quelqu'un change d'équipe, obtient une promotion ou prend une responsabilité temporaire. Le schéma dangereux est l'accumulation de privilèges : les nouveaux accès sont accordés, les anciens ne sont jamais retirés, et au bout de quelques années un salarié de longue date peut à peu près tout faire. Une mobilité doit déclencher la recertification de l'ensemble des habilitations, pas un simple ajout.

Départ. Un départ doit révoquer les accès partout, rapidement, y compris dans les applications fédérées, les VPN, les boîtes aux lettres partagées, les tokens d'API personnels, les consoles cloud et tout ce que la personne a configuré avec ses propres identifiants. C'est là qu'une identité centralisée se rentabilise : désactiver un seul compte d'annuaire ferme toutes les applications qui s'y fédèrent, alors que des comptes gérés localement survivent indéfiniment.

Deux pratiques complémentaires donnent corps à ce cycle. La revue des accès est un exercice périodique au cours duquel le responsable d'un système confirme que chaque utilisateur a encore besoin de ses accès ; elle fonctionne quand le réviseur voit des habilitations formulées en langage clair et peut révoquer en un clic, et elle dégénère en validation automatique quand elle affiche des noms de groupes bruts. La séparation des tâches encode les combinaisons qu'aucune personne ne doit détenir seule — créer un fournisseur et approuver son paiement, par exemple — et se vérifie au moment de l'attribution plutôt que de se découvrir lors d'un audit.

Les facteurs d'authentification

Les preuves d'authentification se répartissent en trois catégories classiques : ce que l'on sait, ce que l'on possède, ce que l'on est. Leur robustesse réelle varie énormément.

Les passkeys, fondées sur WebAuthn et FIDO2, sont la réponse moderne. L'enregistrement crée une paire de clés sur l'authentificateur ; la clé privée ne le quitte jamais et la clé publique est conservée par la relying party. À la connexion, le navigateur signe un challenge accompagné de l'origine du site demandeur, si bien qu'un identifiant pour bank.example.com ne produit rien d'utilisable par un domaine sosie. C'est ce lien à l'origine qui met en échec les proxys de phishing en temps réel, et c'est pourquoi les passkeys remplacent les codes à usage unique au lieu de simplement les compléter. Les passkeys synchronisées suivent l'utilisateur d'un appareil à l'autre via le trousseau de la plateforme ; les clés liées à l'appareil, sur un token matériel, conviennent aux rôles exigeant un haut niveau d'assurance.

L'authentification adaptative, ou fondée sur le risque, ajuste l'exigence au contexte : un nouvel appareil, une localisation inhabituelle ou un virement important déclenchent une authentification renforcée (step-up), alors qu'une session familière n'en déclenche pas. Combinée aux claims acr et amr émis par un fournisseur d'identité, elle permet à une application d'exiger un facteur plus fort pour une opération précise plutôt qu'à chaque connexion.

Bien stocker les mots de passe

Là où les mots de passe subsistent, les règles sont strictes et non négociables. Ne les stockez jamais sous une forme réversible. N'utilisez jamais un simple hash rapide : SHA-256 appliqué à un mot de passe est conçu pour être rapide, ce qui est précisément la propriété que recherche un attaquant muni d'une table volée. Utilisez un algorithme gourmand en mémoire, salé et paramétrable : Argon2id en premier choix, scrypt en second, bcrypt lorsqu'une contrainte de l'écosystème l'impose, PBKDF2 avec un nombre d'itérations élevé lorsque la conformité exige une fonction approuvée par le NIST.

// Argon2id avec des paramètres réglés pour que la vérification coûte quelques centaines de millisecondes sur votre matériel
Argon2PasswordEncoder encoder = new Argon2PasswordEncoder(
        16,          // longueur du sel en octets
        32,          // longueur du hash en octets
        1,           // parallélisme
        1 << 16,     // coût mémoire de 64 Mio
        3);          // itérations

String stored = encoder.encode(submittedPassword);        // contient l'algorithme, les paramètres et le sel
boolean ok = encoder.matches(submittedPassword, stored);  // comparaison en temps constant, jamais equals()

Le sel est propre à chaque utilisateur et stocké avec le hash ; il empêche qu'une même table précalculée casse tous les comptes d'un coup. Un poivre (pepper) — une valeur secrète conservée hors de la base, dans un gestionnaire de clés — ajoute une protection lorsque seule la base fuit. Encodez l'algorithme et les paramètres dans la chaîne stockée afin de pouvoir augmenter le coût ou changer d'algorithme plus tard, en recalculant chaque hash à la connexion réussie suivante.

La politique compte autant que la cryptographie. Autorisez les longues phrases de passe et le collage depuis un gestionnaire ; confrontez les mots de passe candidats aux listes de valeurs déjà divulguées ; abandonnez les règles de composition qui poussent vers Summer2026! ; limitez le nombre de tentatives et verrouillez avec un délai croissant plutôt qu'avec un seuil fixe qui devient un levier de déni de service ; et renvoyez un message d'échec identique, que le compte existe ou non. Un générateur de mots de passe qui s'exécute entièrement dans le navigateur est une ressource raisonnable à recommander aux utilisateurs qui ont besoin d'une valeur robuste. Notez qu'un générateur de hash généraliste sert aux sommes de contrôle et aux condensats de messages — jamais à hacher un mot de passe, précisément parce que ces algorithmes sont rapides.

Les modèles d'autorisation

Choisir un modèle tôt mérite réflexion, car en greffer un après coup coûte cher.

Les listes de contrôle d'accès (ACL) rattachent directement à chaque objet les sujets autorisés. C'est ainsi que fonctionnent les permissions du système de fichiers, décrites dans Utilisateurs, groupes et permissions sous Linux. Précises, mais ingérables à grande échelle : personne ne peut répondre à « à quoi cet utilisateur a-t-il accès ? » sans tout parcourir.

Le contrôle d'accès à base de rôles (RBAC) regroupe les permissions en rôles et attribue les rôles aux utilisateurs. C'est le cheval de bataille — compréhensible, auditable, pris en charge partout. Son mode de défaillance est l'explosion des rôles : les rôles se multiplient pour encoder les exceptions jusqu'à dépasser le nombre d'utilisateurs, et à ce stade ils ont cessé d'être une abstraction.

Le contrôle d'accès à base d'attributs (ABAC) évalue une politique sur les attributs du sujet, de la ressource, de l'action et de l'environnement. Il exprime un contexte hors de portée des rôles, au prix de politiques sur lesquelles il est plus difficile de raisonner et qui se testent moins facilement.

permit if
    subject.department == resource.owningDepartment
    and subject.clearance >= resource.classification
    and action in {"read", "list"}
    and environment.time within subject.workingHours

Le contrôle d'accès fondé sur les relations (ReBAC) modélise l'autorisation comme un graphe — cet utilisateur est éditeur de ce dossier, qui contient ce document — et répond aux questions en le parcourant. Il convient aux produits collaboratifs et aux ressources hiérarchiques où la permission se propage par inclusion, et c'est le modèle qui sous-tend plusieurs services de politique modernes.

En pratique, les systèmes les combinent : des rôles à gros grain ou des scopes OAuth en périphérie, et un contrôle fin fondé sur les relations ou les attributs dans la couche domaine, là où vit la règle de propriété. Externaliser la politique vers un moteur — un sidecar ou une bibliothèque qui évalue des règles déclaratives — sort l'autorisation de la logique métier et la rend testable, mais n'est rentable que lorsque plusieurs services partagent les mêmes règles. Quel que soit le modèle, le point de décision doit se trouver côté serveur, s'appliquer à chaque requête et refuser par défaut.

Annuaires, provisioning et fédération

Les annuaires LDAP restent la source de référence des utilisateurs dans la plupart des grandes organisations. Un annuaire est un arbre hiérarchique d'entrées identifiées par des noms distinctifs (DN), avec des utilisateurs et des groupes comme objets et des attributs tels que uid, mail et memberOf. Historiquement, les applications se connectaient directement à LDAP pour authentifier ; aujourd'hui, mieux vaut laisser le fournisseur d'identité dialoguer avec l'annuaire et offrir à votre application une connexion fédérée, afin que les identifiants ne transitent jamais par votre code.

SCIM (RFC 7644) règle l'autre moitié du problème : faire entrer les comptes dans une application et, surtout, les en faire sortir. C'est un protocole REST reposant sur un schéma utilisateur JSON standard, qu'un fournisseur d'identité utilise pour créer, mettre à jour, désactiver et supprimer des comptes au rythme des changements de l'annuaire.

PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: app.example.com
Content-Type: application/scim+json
Authorization: Bearer <provisioning token>

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace", "path": "active", "value": false }
  ]
}

Prendre en charge SCIM fait du déprovisionnement, non plus un ticket manuel, mais la conséquence automatique d'un changement dans l'annuaire : c'est la chose la plus utile qu'une application métier puisse faire pour la posture de sécurité de ses clients. Passer active à false doit immédiatement mettre fin aux sessions et révoquer les tokens, et pas seulement masquer le compte dans une liste.

Identités à privilèges, machines et cloud

Les comptes administrateurs méritent un traitement à part. La gestion des accès à privilèges (PAM) implique : aucun droit d'administration permanent, une élévation demandée pour une tâche et accordée pour une durée limitée, des comptes distincts pour le travail d'administration, l'enregistrement des sessions lorsque le risque le justifie, et une authentification adossée à du matériel pour chaque connexion privilégiée. Des identifiants de secours (break-glass) existent, scellés, surveillés et testés — et leur utilisation déclenche automatiquement une alerte.

Les identités machines sont désormais plus nombreuses que les identités humaines. Services, jobs, pipelines et conteneurs doivent tous s'authentifier, et la mauvaise réponse est une clé d'API partagée dans un fichier de configuration. Privilégiez une identité délivrée par la plateforme à la charge de travail en cours d'exécution : un rôle d'instance dans un compte cloud, un token de service account projeté dans Kubernetes, un certificat de courte durée émis par une autorité interne pour le TLS mutuel. Dans le vocabulaire des services de base d'AWS, c'est la différence entre une access key commitée dans un dépôt et un rôle assumé par une instance en cours d'exécution, sans aucun identifiant statique nulle part. Quand un secret statique est inévitable, limitez-le à une seule action, faites-le tourner automatiquement et alertez sur toute utilisation depuis une source inattendue.

Enfin, l'audit. Chaque authentification, chaque décision d'autorisation portant sur une ressource sensible, chaque attribution de permission et chaque élévation de privilèges doit produire une entrée de journal indiquant l'acteur, l'action, la cible, le résultat et l'heure, écrite dans un endroit que l'acteur ne peut pas modifier. C'est cette trace qui fait passer un incident de la spéculation à une chronologie.

Points clés à retenir

• L'identité est un cycle de vie, pas un formulaire d'inscription ; ceux qui changent de poste accumulent des privilèges, et ceux qui partent doivent perdre leurs accès partout, rapidement.
• Les passkeys fondées sur WebAuthn sont liées à l'origine et résistent au phishing, ce qui explique qu'elles surclassent désormais les codes à usage unique et les validations par notification push.
• Stockez les mots de passe avec Argon2id ou une fonction équivalente gourmande en mémoire, salée et paramétrée, et préférez la longueur et le filtrage aux règles de composition et à la rotation forcée.
• Choisissez le modèle d'autorisation dont le domaine a besoin — des rôles pour les permissions à gros grain, des attributs ou des relations quand le contexte et la propriété décident — et appliquez-le côté serveur, à chaque fois.
• Fédérez l'authentification vers l'annuaire et prenez en charge SCIM afin que la création et, surtout, la désactivation des comptes soient automatiques.
• Appliquez aux identités à privilèges et aux identités machines la même rigueur qu'aux identités humaines : aucun droit permanent, aucun secret statique là où la plateforme peut en délivrer de courte durée, et une piste d'audit que personne ne peut réécrire.