Arrivées et départs ont un responsable. Les mobi…

Les programmes d’identité sont bâtis autour de deux événements. Quelqu’un arrive et reçoit ce que son poste exige. Quelqu’un part et perd tout. Les deux sont visibles, les deux ont un responsable, les deux sont audités.

Le troisième événement n’a rien de tout cela. Quelqu’un change de poste — du back-office au middle-office, du middle-office à une salle de marché — et l’organisation traite cela comme un avenant. Les nouveaux accès sont accordés parce que le nouveau métier ne peut pas se faire sans eux. Les anciens accès sont une question que personne ne porte.

Répétez trois fois au cours d’une carrière et le résultat n’est plus un rôle. C’est une sédimentation.

Chaque mobilité est approuvée pour elle-même. Personne n’approuve jamais le cumul, parce que personne ne regarde le cumul.

Pourquoi une paire est pire qu’une permission

Chaque habilitation de cette pile a passé une revue au moment où elle a été accordée. C’est ce qui rend le sujet difficile à plaider : il n’y a pas d’approbation abusive à trouver, pas de politique enfreinte, pas de contrôle défaillant. Le risque n’est dans aucune d’elles. Il tient au fait que deux d’entre elles se trouvent désormais derrière le même identifiant.

La séparation des tâches est une propriété de la combinaison — c’est pourquoi revoir les habilitations une par une ne peut pas la détecter.

C’est la forme des pertes de la Société Générale en 2008. Jérôme Kerviel avait travaillé au back-office avant de rejoindre une salle de marché, et ce qui a permis de dissimuler les positions aussi longtemps n’était pas une permission excessive isolée — c’était de connaître de l’intérieur le fonctionnement réel des contrôles qu’il contournait désormais. La mobilité était l’événement déterminant, et c’était précisément celui que personne ne traitait comme tel.

Pourquoi c’est difficile à voir

Les trois informations nécessaires pour détecter cela vivent à trois endroits différents, détenues par trois équipes différentes :

Les habilitations vivent dans chaque application, dans le vocabulaire de cette application. « Capture Trades » dans un système et le droit d’enregistrer une opération dans un autre sont la même capacité sous deux noms.
La mobilité vit dans le SIRH, sous forme de changement de poste avec une date d’effet. Elle parvient aux applications comme une demande de nouveauté, pas comme un avis qu’une ancienne habilitation devrait cesser.
La règle — ces deux capacités ne doivent jamais être détenues par une seule personne — vit généralement dans un document de politique, un tableur, ou la tête de quelqu’un.

Rien ne les relie. Une revue des accès présente au relecteur la liste des habilitations d’une personne et demande si chacune est toujours nécessaire. Chacune, prise isolément, l’est encore. Le relecteur approuve la liste, à juste titre, et la paire toxique qu’elle contient survit à un cycle de plus.

Ce qui change vraiment la donne

Trois choses, et l’ordre compte :

Traiter une mobilité comme un départ et une arrivée, pas comme un avenant. Les accès de l’ancien poste doivent être explicitement rejustifiés ou retirés, dans le même workflow que celui qui accorde ceux du nouveau. La mobilité interne est le seul événement du cycle de vie où « ne rien faire » est l’option par défaut, et c’est celui où ne rien faire s’accumule.
Écrire les règles de conflit là où elles peuvent être évaluées. Pas dans un PDF de politique, mais comme des règles portant sur les habilitations réelles, pour que le système puisse répondre « cette attribution crée-t-elle un conflit » au moment de la demande plutôt qu’au moment de la revue. En environnement de marché, cela suppose des règles qui comprennent les instruments, les contreparties, les portefeuilles et les seuils de montant — « approuver des opérations » n’est pas une permission, c’est une permission bornée par quoi et combien.
Détecter la paire au moment de la demande. Un conflit détecté pendant que quelqu’un demande un accès coûte une conversation. Le même conflit détecté lors d’une revue annuelle coûte un projet de remédiation, et détecté par un incident, considérablement plus.

Ce que cela ne règle pas

Quelqu’un doit tout de même écrire les règles. Un système peut appliquer une matrice de conflits et peut suggérer des paires qui y ressemblent. Il ne peut pas vous dire que votre établissement considère ces deux fonctions comme incompatibles — c’est un jugement sur votre métier, et il doit venir de ceux qui le dirigent.
Une paire détenue par deux personnes peut rester un problème si l’une dépend hiérarchiquement de l’autre. La séparation des tâches concerne l’indépendance, pas seulement les identifiants, et un organigramme peut défaire un modèle d’habilitations impeccable.
Résorber l’existant est un projet. Détecter les conflits accumulés est rapide. Décider quel côté de chaque paire retirer, à des personnes qui utilisent les deux, ne l’est pas.

Rien de cela ne justifie de laisser la sédimentation en place. La question que pose un conseil après un incident n’est jamais « chaque attribution avait-elle été approuvée ». C’est « une seule personne aurait-elle pu faire cela », et c’est une question de combinaisons.