Gestion des identités et des accès : une feuille de route en cinq étapes
Un annuaire historique, un SSO déployé à moitié, des accès cloud accordés au fil de l’eau : la plupart des entreprises de taille intermédiaire accumulent les outils sans jamais poser de vision d’ensemble. Résultat, personne ne sait répondre à une question pourtant simple : qui a accès à quoi et pourquoi ? La gestion des identités et des accès est d’abord un chantier d’organisation, avant d’être un chantier technique. Voici une démarche en cinq étapes, pensée pour une DSI qui veut reprendre la main sans tout reconstruire.
Étape 1 : cartographier les identités et les droits existants
Impossible de gouverner ce qu’on ne voit pas. Le point de départ consiste à inventorier toutes les identités numériques : salariés, mais aussi prestataires, intérimaires, comptes de service applicatifs et comptes techniques créés « temporairement » il y a des années. Cet inventaire croise l’annuaire, le SIRH et les consoles d’administration des applications SaaS, qui échappent souvent au périmètre de la DSI.
L’exercice réserve rarement de bonnes surprises. Dans une ETI industrielle de 900 salariés, un audit de ce type a mis au jour une soixantaine de comptes encore actifs appartenant à des personnes parties depuis plus de six mois, dont deux avec des droits d’administration sur l’ERP. S’y ajoutait un compte de service créé en 2019, doté d’un mot de passe jamais changé, dont plus personne ne connaissait l’usage. Chaque compte dormant est une porte d’entrée que personne ne surveille.
Étape 2 : définir un modèle d’accès par rôles
Une fois l’existant connu, il faut sortir de la logique des droits accordés individu par individu. Le RBAC (contrôle d’accès basé sur les rôles) consiste à définir, avec les métiers, des profils types : un comptable fournisseurs, un technicien de maintenance ou un commercial sédentaire n’ont pas besoin des mêmes applications ni des mêmes niveaux de droits. Chaque rôle est documenté dans une matrice métier/droits, construite sur le principe du moindre privilège : on accorde le nécessaire, rien de plus.
Le vrai travail est là, dans les arbitrages : qui valide qu’un chef d’équipe accède aux données de paie de son service ? Le manager, la RH, la DSI ? Une règle simple fonctionne bien : le propriétaire de la donnée valide, la DSI exécute, le RSSI arbitre les cas litigieux. Sans ce circuit de décision écrit, le modèle se dégrade en quelques mois.
Les rôles eux-mêmes doivent également être réévalués régulièrement. Un modèle RBAC peut perdre de sa pertinence si les autorisations associées à chaque fonction s’accumulent au fil du temps sans être remises en question. La revue ne doit donc pas porter uniquement sur les utilisateurs, mais aussi sur les droits qui composent chaque rôle.
Étape 3 : automatiser l’arrivée et le départ
Tant que la création des comptes repose sur des tickets manuels, les erreurs et les oublis sont garantis. L’étape suivante consiste à brancher le provisioning sur le SIRH : une embauche déclenche automatiquement la création des comptes correspondant au rôle défini à l’étape 2, avec un workflow d’approbation pour toute demande hors profil. Symétriquement, un départ enregistré dans le SIRH déclenche automatiquement le déprovisionnement à la date et à l’heure prévues pour la fin des accès.
Le gain se mesure vite. Une arrivée qui mobilisait le support sur une dizaine de tickets, soit deux à trois heures de traitement étalées sur une semaine, se règle en quelques minutes. Le nouvel arrivant est opérationnel le premier jour au lieu du cinquième et le helpdesk récupère plusieurs dizaines d’heures par mois sur un site de taille moyenne. Surtout, l’automatisation réduit fortement le risque qu’un compte reste actif après le départ de son titulaire.
Étape 4 : traiter à part les comptes à privilèges
Les comptes d’administrateurs, les accès aux serveurs de production ou aux consoles cloud ne relèvent pas du régime commun : ce sont des cibles particulièrement sensibles, car leur compromission peut donner accès à des ressources critiques.
Une démarche PAM (gestion des accès à privilèges) permet de contrôler spécifiquement ces accès : gestion sécurisée des secrets, élévation temporaire des privilèges, contrôle des sessions et traçabilité des actions.
Deux mécanismes sont particulièrement importants. L’élévation temporaire de privilèges d’abord : un administrateur obtient ses droits pour une intervention donnée et une durée limitée, puis les perd. L’enregistrement des sessions sensibles ensuite, qui permet de retracer une intervention sur un serveur critique en cas d’incident ou d’audit. Pour un prestataire d’infogérance, cette traçabilité constitue aussi une protection contractuelle appréciable des deux côtés.
Étape 5 : moderniser l’authentification
Reste le maillon le plus exposé : la preuve d’identité elle-même. Un modèle de rôles rigoureux ne protège rien si un attaquant parvient à usurper l’identité d’un utilisateur autorisé.
Les codes SMS et certaines notifications de validation apportent une protection supplémentaire, mais restent plus exposés aux techniques de phishing et de contournement que les mécanismes d’authentification résistants au phishing. Les standards FIDO2 et WebAuthn, utilisés notamment par les clés de sécurité physiques et les passkeys, reposent sur des mécanismes cryptographiques liés au service légitime. Ils empêchent ainsi le simple vol et rejeu d’identifiants via un faux domaine et offrent une résistance nettement supérieure à ce type de phishing.
Le passwordless simplifie au passage la vie des utilisateurs, ce qui conditionne aussi l’adoption. Des solutions dédiées à la gestion des identités et des accès, comme Hideez, permettent d’intégrer l’authentification sans mot de passe et les clés de sécurité dans une gestion centralisée des accès, sans multiplier inutilement les briques à administrer.
Mesurer et faire vivre le dispositif
Une démarche IAM n’est jamais terminée : les organisations bougent, les utilisateurs changent de fonction et les rôles évoluent. Des revues d’accès régulières, validées par les managers, permettent de corriger cette dérive. La pertinence des rôles et des autorisations qui leur sont associées doit également être réévaluée dans le temps.
Trois indicateurs peuvent notamment servir de base au pilotage :
- le taux de comptes sans propriétaire identifié ou sans justification active
- le délai moyen de déprovisionnement après un départ
- le taux de couverture de la MFA résistante au phishing
À plus long terme, ce socle peut préparer une architecture Zero Trust, où la confiance n’est pas accordée uniquement en fonction du réseau d’origine et où les demandes d’accès sont évaluées selon l’identité, le terminal, la ressource et le contexte. On n’y arrive pas par les outils seuls : on y arrive par ces cinq étapes, prises dans l’ordre.
