Les comptes invités restent actifs après leurs…

Toutes les entreprises connaissent cette histoire. Un partenaire envoie un consultant. Quelqu’un lui ouvre un compte. La mission se termine — ou pire, le consultant quitte le partenaire en cours de route — et le compte reste exactement où il était, habilité à tout ce à quoi il était habilité le premier jour.

Le problème n’est pas que ce compte existe. C’est que personne chez vous n’est en mesure de savoir quand il devrait cesser d’exister. La seule personne qui pourrait vous le dire travaille ailleurs, et vous prévenir ne fait pas partie de son travail.

Les attestations vérifiables ne réduisent pas ce problème. Elles le déplacent vers la seule organisation capable d’y répondre. Voici le mécanisme complet, à travers le scénario sur lequel nous revenons sans cesse : Alpha Trading Co a besoin de Brandon Chen, d’ACME Advisory, dans une data room, et Alpha n’a jamais rencontré Brandon.

Deux entreprises s’entendent avant que quiconque demande quoi que ce soit

L’entente lie les deux organisations et se noue bien avant qu’une personne ait besoin d’un accès.

Rien dans cette image ne concerne Brandon. Deux équipes sécurité établissent, une fois pour toutes, que chacune acceptera les attestations émises par l’autre — et c’est tout. On est plus proche d’une relation de banque correspondante que d’une demande de compte : la partie coûteuse et minutieuse se fait une seule fois, entre institutions, et chaque personne ensuite ne coûte presque rien.

Kira ne contacte jamais Brandon

Kira Patel, SVP Finance chez Alpha, n’écrit jamais à Brandon et ne demande à personne chez ACME de confirmer qu’il y travaille.

Kira n’ouvre pas de ticket, ne demande à personne de créer quoi que ce soit et ne réclame aucun courriel de confirmation à ACME. Elle choisit les accès qu’elle veut lui accorder et saisit son adresse professionnelle. La plateforme reconnaît un domaine auquel Alpha fait déjà confiance, et c’est là toute la moitié interne du processus.

Brandon le prouve depuis son téléphone

Brandon prouve qui il est avec ce que son employeur lui a déjà remis, et ses attributs voyagent avec la preuve.

Observez ce qui n’a pas eu lieu. Personne n’a saisi le titre de Brandon dans un formulaire chez Alpha. Personne n’a envoyé un tableur de noms de consultants. Alpha ne lui a pas inventé un mot de passe pour le réinitialiser trois semaines plus tard. Les attributs qui déterminent ce qu’il peut voir — son titre, son ancienneté, son service — arrivent sous forme d’assertions de l’organisation qui l’emploie, la seule qui ait qualité pour les faire.

Cela dépasse le confort. Une adresse courriel déclarée n’est pas une preuve d’identité, et un attribut saisi à la main est obsolète dès son enregistrement. Les auditeurs posent des questions sur les deux, et la plupart des processus de comptes invités y répondent mal.

Ce que les IAM traditionnels ne savent pas faire

Les deux mêmes organisations, à un état d’écart. Alpha l’apprend par la revérification, pas par un message que quelqu’un a pensé à envoyer.

C’est là tout l’argument, et il vaut la peine d’être précis sur ce qui le fait fonctionner. On ne prévient pas Alpha du départ de Brandon. Alpha demande à ACME, à intervalles réguliers, si l’attestation qu’elle a acceptée est toujours valable — et un jour la réponse est non. L’événement qui compte se produit chez ACME, dans le processus de départ d’ACME, pour les raisons propres à ACME. Alpha en hérite.

Comparons honnêtement les deux modes de défaillance :

La méthode habituelle. Brandon conserve son accès chez Alpha pendant des mois. Kira ignore qu’il est parti. La revue trimestrielle des accès est la première occasion de s’en apercevoir, et c’est la revue d’une liste sur laquelle personne ne dispose d’information fraîche. Chaque départ de consultant devient un petit risque caché qui vieillit tranquillement.
Avec une attestation émise par l’employeur. Le statut est revérifié auprès de l’émetteur au lieu d’être mémorisé. Quand il change, l’identité invitée et toutes les habilitations qui en découlent suivent, et la séquence est consignée pour quiconque la demandera plus tard.

Ce que cela ne règle pas

Trois limites honnêtes, parce qu’un mécanisme décrit uniquement par ses bons jours ne sert pas à grand-chose :

Le partenaire doit émettre des attestations. Cela fonctionne entre organisations qui ont toutes deux fait le travail de mise en place. Un fournisseur sans fournisseur d’identité digne de ce nom reste un problème manuel, et la relation de confiance doit exister avant la première demande, pas pendant.
Toujours employé ne veut pas dire toujours sur votre dossier. L’attestation vous dit que Brandon travaille chez ACME. Elle ne vous dit pas qu’il devrait encore être dans votre data room une fois la mission terminée. Le périmètre et les dates de fin restent à votre charge.
La révocation va à la vitesse de votre revérification. « En continu » signifie à intervalles, pas par télépathie. L’exposition entre la révocation et votre prochaine vérification est un chiffre que vous devriez connaître et choisir délibérément.

Rien de tout cela n’annule le changement. L’écart qui se referme ici est celui que personne n’était en mesure de refermer : la distance entre un fait qui vit dans le SIRH de votre partenaire et une habilitation qui vit dans le vôtre.