Une grande organisation compte des milliers d'utilisateurs, des centaines de systèmes et des dizaines de milliers d'autorisations d'accès. Un collaborateur qui travaillait au service crédit il y a cinq ans et qui est aujourd'hui au marketing conserve probablement ses anciens droits. Un prestataire dont le projet est terminé peut encore disposer d'un compte actif. Des comptes de service créés pour une intégration temporaire subsistent pendant des années avec un mot de passe inchangé. Aucun de ces cas n'est une catastrophe en soi, mais ensemble ils créent un niveau de risque qu'aucun auditeur ne laissera passer et qu'aucune équipe de sécurité ne peut gérer manuellement.
Il est essentiel ici de distinguer deux notions. La gestion des identités et des accès (IAM) répond à la question de savoir si cette personne est bien celle qu'elle prétend être et si elle est autorisée à effectuer cette action maintenant : authentification, authentification unique, vérification multifacteur et émission de jetons. La gouvernance et l'administration des identités (IGA) traite une question plus profonde : cette personne devrait-elle seulement disposer de cet accès, qui l'a approuvé et quand doit-il être revu ? Les organisations qui ne disposent que de l'IAM verrouillent bien la porte d'entrée, mais ne savent pas à qui elles ont remis une clé.
L'architecture recommandée conçoit les deux comme des couches complémentaires reposant sur une source d'identité commune. Au centre se trouve un annuaire d'identités alimenté par le système RH et le référentiel des tiers, qui suit chaque identité tout au long de son cycle de vie, de l'arrivée au départ. La couche IAM, fondée sur des standards ouverts tels qu'OpenID Connect et SAML, assure l'authentification et l'émission de jetons pour chaque application, API et agent. La couche IGA gère les rôles, les politiques, les workflows de demande et d'approbation, les revues périodiques des accès et la séparation des tâches, et provisionne le résultat sous forme de droits concrets dans les systèmes cibles.
La première considération pratique est la conception du modèle de rôles. Les rôles doivent découler de la structure réelle de l'organisation et des fiches de poste, et non des accès existants ; sinon, tous les droits excessifs accumulés par le passé se trouvent officialisés sous forme de rôles. Une approche réaliste combine des rôles de base attribués selon le service et le poste avec des droits demandés individuellement. Par exemple, chaque collaborateur d'agence reçoit automatiquement le rôle de base de l'agence, mais l'accès à l'approbation de crédits au-delà d'un seuil défini exige une demande, l'accord d'un responsable et une date d'expiration.
La deuxième considération est l'automatisation du cycle de vie. Le contrôle de sécurité le plus efficace consiste à retirer les accès à temps, et cela n'est fiable que si c'est relié aux événements RH. Lorsque le dossier d'un collaborateur passe au statut de départ, les comptes doivent être désactivés, les jetons révoqués et les droits retirés sur-le-champ. Une mutation entre services doit supprimer l'ancien rôle et attribuer le nouveau, et non simplement ajouter le nouveau par-dessus. Ce lien piloté par les événements fait passer la charge de l'équipe de sécurité de la revue manuelle à la supervision des exceptions.
La troisième considération concerne les identités non humaines. Les services, les tâches planifiées, les équipements IoT et, de plus en plus, les agents d'IA ont tous besoin d'une identité, d'un ensemble de droits et d'un propriétaire désigné. Ces identités doivent suivre le même cycle de vie et la même revue périodique que les utilisateurs humains. Un agent agissant pour le compte d'un utilisateur doit détenir un jeton à portée restreinte et de courte durée, et chacune de ses actions doit être attribuée aux deux identités, l'agent et l'utilisateur, afin que la piste d'audit ne perde jamais ni l'un ni l'autre.
Les écueils sont nombreux dans ce domaine. Premièrement, commencer par un outil plutôt que par le modèle de données et le processus ; aucun produit ne peut définir des rôles que personne n'a définis. Deuxièmement, des revues d'accès de pure forme, où les responsables approuvent tout sans lire ; la solution consiste à afficher le contexte, comme la date de dernière utilisation de chaque droit, et à limiter l'ampleur de chaque revue. Troisièmement, ignorer les systèmes existants dépourvus d'interfaces standard, encore gérés par fichiers et accès direct aux bases de données. Quatrièmement, regrouper l'IAM et l'IGA dans un seul projet gigantesque qui perd sa crédibilité avant d'avoir produit sa première valeur.
Chez Niadad, la plateforme Shanasa («شناسا») assure la couche d'identité et d'accès sur des standards ouverts : authentification centralisée, authentification unique (SSO), vérification multifacteur et émission de jetons pour les utilisateurs, les services et les agents. La plateforme Parsa («پارسا») prend en charge la couche de politiques et de gouvernance : définition des rôles et des politiques d'accès, workflows de demande et d'approbation, revues périodiques et séparation des tâches. Dans le programme bancaire de Niadad, ces deux plateformes s'articulent avec le référentiel des tiers Ashna et la passerelle API, afin que l'identité soit gérée comme une chaîne cohérente, de la source jusqu'au point d'application.
La sécurité de l'entreprise se ramène en définitive à une question simple : pouvez-vous dire, à tout moment, qui a accès à quoi et pourquoi ? L'IAM répond au « qui » ; l'IGA répond au « pourquoi ». Une organisation qui dispose des deux ne se contente pas de réussir ses audits : elle peut ouvrir ses systèmes en toute confiance à de nouveaux utilisateurs, partenaires et agents sans en perdre le contrôle. Le travail n'est jamais terminé, car les organisations ne cessent d'évoluer ; mais avec la bonne architecture, suivre le rythme devient une routine plutôt qu'une urgence périodique.