Le badge prouve qui tu es, pas où tu peux aller

Au centre commercial « Les Arcades », un employé qui passe le sas du personnel le matin a franchi la première barrière : il a prouvé son identité. Le vigile sait que c'est bien Camille, responsable de la bijouterie. Mais cette reconnaissance ne dit rien de ce qu'elle a le droit de faire une fois à l'intérieur.

C'est là que commence une seconde histoire, plus large et plus discrète. Camille porte un badge. Ce badge ouvre la réserve de la bijouterie et le local technique de son étage, mais reste muet devant le bureau du directeur et devant la salle des coffres. Quelqu'un, quelque part, a décidé une fois pour toutes des portes que ce badge ouvre, et il faudra que cette décision reste juste le jour où Camille change de poste ou quitte l'entreprise.

Prouver son identité n'est que la porte d'entrée. La vraie question de sécurité est ensuite permanente : qui a accès à quoi, avec quels droits, et pour combien de temps ?

Le billet précédent traitait de l'authentification : comment un système vérifie qui tu es, avec les facteurs, le MFA et le SSO. Ce billet prend le relais. Une fois l'identité établie à la porte, il faut la gérer dans la durée et encadrer les accès les plus sensibles.

On va dérouler ça en quatre temps. D'abord l'IAM, qui gère le cycle de vie d'une identité de son arrivée à son départ. Ensuite la façon d'autoriser à l'échelle, quand on a des milliers de badges à attribuer sans tout faire à la main. Puis les comptes à privilèges, ces passe-partout qui ouvrent toutes les portes et que les attaquants visent en premier. Enfin le PAM, la discipline qui met ces passe-partout sous clé. Le cas Colonial Pipeline servira de fil rouge réel à la fin.

IAM : le cycle de vie d'une identité

Aux Arcades, le service du personnel ne se contente pas de distribuer des badges. Il suit chaque badge dans le temps. Le jour où un saisonnier est embauché, on lui crée un badge avec les bons accès. Le jour où il passe de la réserve à la caisse, on adapte ses droits. Le jour où son contrat se termine, on désactive son badge et on récupère son matériel.

Ce suivi, de la création à la suppression, c'est exactement ce que fait l'IAM (Identity and Access Management) en informatique. Une identité n'est pas un objet figé : elle naît, elle évolue, elle doit mourir proprement. On résume ce parcours en trois moments, souvent appelés joiner, mover, leaver.

  • Joiner (l'arrivée) : on crée le compte et on lui attribue les accès correspondant au rôle. C'est le provisioning. Au mieux, il est automatisé depuis le logiciel RH, pour qu'un nouvel employé ait ses accès dès le premier jour, ni plus, ni moins.
  • Mover (le changement) : la personne change de poste, d'équipe, de site. Ses droits doivent suivre. Le piège classique est qu'on lui ajoute les nouveaux accès sans jamais retirer les anciens.
  • Leaver (le départ) : la personne quitte l'organisation. Tous ses accès doivent être révoqués sans délai. C'est le deprovisioning, et c'est l'étape qu'on néglige le plus souvent.
L'étape la plus dangereuse n'est pas de donner un accès, c'est d'oublier de le retirer. Un compte qui survit à son propriétaire est une porte ouverte que plus personne ne surveille.

Le badge oublié dans un tiroir est le cauchemar du service de sécurité. Aux Arcades, c'est le badge d'un employé parti depuis six mois, jamais désactivé, qui ouvre toujours la réserve. En informatique, on appelle ça un compte dormant : un compte encore actif, mais que plus personne n'utilise ni ne surveille. Personne ne remarque s'il sert à se connecter à trois heures du matin.

Le tableau ci-dessous met côté à côté les trois moments du cycle, leur version « Les Arcades » et le risque concret quand l'étape est ratée.

Étape Au service du personnel En informatique Risque si l'étape échoue
Joiner (arrivée) Création du badge, droits du poste Provisioning du compte et des accès Accès trop larges accordés « pour aller vite »
Mover (changement) Adaptation des droits du badge Mise à jour des rôles et des groupes Accumulation des anciens droits (privilege creep)
Leaver (départ) Désactivation du badge, restitution Deprovisioning, révocation des accès Compte dormant, porte ouverte non surveillée

Le cadre de référence sur la notion d'identité numérique est la suite NIST SP 800-63, qui pose le vocabulaire et les exigences autour des identités. Un bon IAM, c'est d'abord un cycle de vie sans trou : ce qui entre sort, et ce qui change est suivi.

Autoriser à l'échelle : RBAC, ABAC et dérive des droits

Tant qu'il y a dix employés, on peut décider des accès de chaque badge à la main. Aux Arcades, avec plusieurs centaines de personnes et des dizaines de boutiques, c'est ingérable. On ne raisonne plus par individu, on raisonne par rôle.

Le service du personnel définit des profils : « vendeur bijouterie », « agent de maintenance », « responsable d'étage ». Chaque profil donne droit à un jeu de portes précis. Quand Camille devient responsable, on ne liste pas ses cinquante accès un par un : on lui attribue le rôle « responsable de boutique », et le rôle porte les droits. C'est le RBAC (Role-Based Access Control), le contrôle d'accès basé sur les rôles.

Le RBAC est simple et lisible, mais il a une limite. Il ne sait pas tenir compte du contexte. « Responsable de boutique » donne accès à la réserve, peu importe l'heure, le jour ou l'endroit d'où la demande arrive. Pour aller plus loin, on passe à l'ABAC (Attribute-Based Access Control), basé sur des attributs : on autorise l'accès en fonction de propriétés combinées, par exemple « responsable ET sur site ET en horaire d'ouverture ». La règle devient « accès à la réserve uniquement pendant les heures de la boutique, depuis le réseau interne ».

Critère RBAC (par rôle) ABAC (par attributs)
Principe Un rôle porte un jeu de droits fixe Une règle évalue des attributs (qui, quoi, quand, où)
Lisibilité Élevée, facile à auditer Plus fine mais plus complexe à raisonner
Souplesse contextuelle Faible (pas d'heure, pas de lieu) Forte (heure, localisation, sensibilité)
Bon terrain Organisations stables, rôles clairs Contextes dynamiques, accès conditionnels
Risque propre Multiplication des rôles ad hoc Règles trop nombreuses, difficiles à tracer
RBAC et ABAC ne s'opposent pas : on commence souvent par des rôles clairs, puis on affine avec des attributs là où le contexte compte vraiment. Le bon réflexe est de coller au plus près du moindre privilège.

Deux notions complètent ce tableau. La première est la séparation des tâches (Segregation of Duties, SoD) : on évite qu'une même personne cumule des droits incompatibles. Aux Arcades, celui qui commande la marchandise ne devrait pas être aussi celui qui valide seul les paiements aux fournisseurs, sinon il peut se payer une fausse facture sans contrôle. En informatique, c'est la même logique : qui crée un compte ne devrait pas être qui en approuve seul les accès sensibles.

La seconde est la dérive des droits (privilege creep). C'est le résultat silencieux d'un mover mal géré : à force de changer de poste sans jamais perdre ses anciens accès, un employé finit par ouvrir bien plus de portes que son rôle actuel ne le justifie. C'est la transgression directe du moindre privilège, un principe que documentent la famille de contrôles d'accès (AC) du NIST SP 800-53 et le contrôle d'accès de la norme ISO/IEC 27001. La parade est ennuyeuse mais indispensable : revoir périodiquement qui a accès à quoi, et retirer ce qui ne se justifie plus.

Les comptes à privilèges : le passe maître

Parmi tous les badges des Arcades, il en existe un d'une autre nature. Le gardien-chef possède un passe maître, une seule clé qui ouvre toutes les portes du centre : boutiques, réserves, locaux techniques, salle des coffres, bureau du directeur. Pas de profil, pas de restriction d'horaire. Tout, partout.

Ce passe est l'objet le plus précieux et le plus dangereux du bâtiment. Précieux parce qu'il rend possibles la maintenance, les rondes de nuit et les interventions d'urgence. Dangereux parce que celui qui le vole n'a plus aucune barrière devant lui. En informatique, ce passe maître porte un nom familier : le compte à privilèges, dont les figures les plus connues sont l'administrateur (admin) et le super-utilisateur (root).

Ces comptes ne se limitent pas aux administrateurs humains. Trois familles cohabitent, et chacune a sa version aux Arcades.

  • Comptes d'administration humains : le gardien-chef et son passe. Ils peuvent tout modifier, tout supprimer, tout configurer.
  • Comptes de service : les automatismes qui tournent sans personne derrière, comme le système qui ouvre et ferme les rideaux de fer chaque jour à heure fixe. En informatique, ce sont les comptes techniques qu'utilisent les applications pour parler entre elles. Souvent puissants, rarement surveillés, parfois avec un mot de passe qui ne change jamais.
  • Comptes partagés : un passe accroché dans le local de sécurité, que plusieurs gardiens utilisent à tour de rôle. Pratique, mais quand quelque chose tourne mal, impossible de savoir qui s'en est servi. Pas de responsabilité individuelle, pas de traçabilité.
Un compte à privilèges est la cible numéro un d'un attaquant. Compromettre un compte ordinaire ouvre une porte ; compromettre un compte admin ouvre le bâtiment entier. C'est pourquoi ces comptes méritent un traitement à part.

La logique du moindre privilège vaut ici plus que partout ailleurs. Tout le monde n'a pas besoin du passe maître, et celui qui en a besoin n'en a pas besoin en permanence. Le gardien n'a pas à se promener avec le passe dans la poche toute la journée : il en a besoin pour une intervention précise, à un moment précis. C'est exactement l'idée que va industrialiser le PAM.

PAM : mettre le passe maître sous clé

Aux Arcades, la direction a fini par tirer la conséquence du danger. Le passe maître ne traîne plus dans une poche ni accroché à un clou. Il vit dans un coffre à clés au PC sécurité. Pour l'obtenir, un gardien doit le demander, signer un registre, indiquer pourquoi il en a besoin, puis le rendre après son intervention. Et le passe ne lui est confié que pour une durée limitée.

Cette gestion stricte du passe maître, c'est le PAM (Privileged Access Management), la gestion des accès à privilèges. Le PAM ne supprime pas les comptes puissants, on en a besoin. Il les encadre pour qu'ils ne soient ni détenus en permanence, ni utilisés sans trace. Trois mécanismes principaux le composent.

Le premier est le coffre-fort de secrets (vaulting) et la rotation. Au lieu que chaque administrateur connaisse le mot de passe root, ce mot de passe est rangé dans un coffre numérique. On ne le retire que sur demande justifiée, et il est changé régulièrement (rotation), comme on reforgerait la clé du passe après chaque usage sensible. Un secret qui change souvent et que personne ne mémorise est bien plus difficile à voler durablement.

Le deuxième est l'accès juste-à-temps (Just-In-Time, JIT). Plutôt que d'avoir des droits admin en permanence, on n'obtient le privilège qu'au moment précis où on en a besoin, pour une fenêtre courte, après quoi il est retiré automatiquement. L'objectif visé porte un nom : le zéro privilège permanent (zero standing privilege). En dehors de l'intervention, plus personne ne détient le passe. Il n'y a donc presque jamais de passe à voler.

Le troisième est l'enregistrement de session. Aux Arcades, la vidéosurveillance et le PC sécurité enregistrent les déplacements ; le PC sécurité du SI fait pareil pour les sessions à privilèges. Toute action menée avec le passe maître est journalisée, et parfois la session entière est enregistrée. Si quelque chose tourne mal, on sait précisément qui a fait quoi, quand, et sur quel système. La responsabilité individuelle est rétablie, même pour ce qui ressemblait à un compte partagé.

Le schéma ci-dessous montre comment une session d'administration est intermédiée par le PAM, de la demande jusqu'à la restitution du privilège.

sequenceDiagram participant A as "Administrateur" participant P as "PAM (coffre + courtier)" participant S as "Serveur cible" A->>P: "Demande d'accès justifiée (durée limitée)" P->>P: "Vérifie le droit, ouvre une fenêtre JIT" P->>S: "Ouvre la session avec un secret du coffre" P->>P: "Enregistre la session (journalisation)" A->>S: "Travaille via le PAM, sans connaître le secret" P->>S: "Fin de fenêtre : ferme la session" P->>P: "Rotation du secret, accès retiré"
Le PAM transforme un privilège permanent et silencieux en un privilège temporaire, justifié et enregistré. On ne fait plus confiance à un passe maître qui dort dans une poche : on le prête contre signature, pour un temps court, et on le reprend.

Cette logique prolonge directement le Zero Trust et le moindre privilège : aucun accès n'est acquis pour toujours, chaque demande est vérifiée, et le privilège élevé est l'exception encadrée, pas la règle confortable.

Scénario B : Colonial Pipeline et le compte VPN oublié

Le 7 mai 2021, Colonial Pipeline, opérateur d'un des plus grands oléoducs des États-Unis, a dû interrompre ses opérations à la suite d'une attaque par rançongiciel. Ce qui rend ce cas instructif n'est pas le rançongiciel lui-même, mais la porte d'entrée qu'ont empruntée les attaquants. Cette porte relie les trois fils de ce billet.

D'après le témoignage de Joseph Blount, PDG de Colonial Pipeline, devant le Sénat américain et l'analyse de l'incident publiée par Mandiant, l'accès initial s'est fait via un compte d'accès distant VPN qui n'était plus censé être utilisé, mais n'avait jamais été désactivé. Le mot de passe de ce compte figurait dans une fuite d'identifiants. Et ce compte d'accès distant n'était pas protégé par MFA.

Recoupons avec les notions du billet.

  • Échec du cycle de vie (leaver/deprovisioning) : le compte n'était plus actif au sens des usages, mais il était toujours activé techniquement. C'est le compte dormant typique, celui qu'on a oublié de retirer.
  • Accès à privilèges non encadré : un accès distant à un réseau sensible n'a transité par aucune logique de PAM ni de juste-à-temps. Le privilège dormait là, permanent, prêt à l'emploi pour qui détenait le mot de passe.
  • Absence de MFA sur un accès privilégié : un mot de passe compromis a suffi. L'avis conjoint CISA/FBI sur le rançongiciel DarkSide recommande d'ailleurs le MFA en tête de ses parades : un second facteur résistant aurait coupé court à un identifiant volé. La mécanique des facteurs et du MFA est détaillée dans le billet précédent.
Aucune de ces failles n'est exotique. Un compte non désactivé, un accès distant non encadré, pas de second facteur : trois omissions ordinaires d'hygiène des accès qui, réunies sur le même compte, ont ouvert la voie à l'arrêt d'une infrastructure critique.

La leçon rejoint tout ce qui précède. La sécurité des identités ne tient pas à un seul produit, mais à une discipline continue : sortir ce qui doit sortir, encadrer ce qui est puissant, et ne jamais laisser un accès sensible reposer sur un simple mot de passe oublié dans un coin.

Points clés

  • L'IAM gère le cycle de vie d'une identité (joiner, mover, leaver). L'étape la plus négligée, le deprovisioning, produit des comptes dormants qui sont des portes ouvertes non surveillées.
  • On autorise à l'échelle par rôles (RBAC) ou par attributs (ABAC), en visant le moindre privilège, avec séparation des tâches et lutte contre la dérive des droits (privilege creep).
  • Les comptes à privilèges (admin, root, comptes de service, comptes partagés) sont la cible numéro un. Compromettre un admin n'ouvre pas une porte, il ouvre le bâtiment entier.
  • Le PAM met ces comptes sous clé : coffre-fort de secrets et rotation, accès juste-à-temps (zéro privilège permanent), enregistrement de session pour rétablir la traçabilité.
  • Colonial Pipeline (mai 2021) réunit les trois échecs : compte VPN dormant non désactivé, accès distant privilégié non encadré, absence de MFA. Une hygiène des accès basique aurait fermé cette porte.

Dans la série

Palier 2 : Verrouiller les accès. Domaine : Identité & accès.

Pour aller plus loin