Arrivées, mobilités et départs : garder la maîtrise des accès

Les changements d’accès posent un problème de coordination autant qu’un problème technique. Une plateforme d’identité ne peut pas supprimer le compte d’un prestataire si personne n’informe le responsable que le contrat a pris fin. De même, une notification RH transmise à temps ne prouve pas que chaque application a cessé d’accepter les identifiants de la personne.

Les arrivées, mobilités et départs nécessitent un processus qui relie un événement métier à un état d’accès approuvé, exécute les changements nécessaires et vérifie le résultat. Du point de vue de la direction technique, la question importante n’est pas de savoir s’il existe une liste de contrôle de départ. Elle est de savoir si le processus couvre les systèmes que les personnes utilisent réellement, gère les échecs et laisse une preuve de ce qui a changé et à quel moment.

Définir le cycle de vie et ses passages de relais

Traitez chaque événement du cycle de vie comme une modification des accès autorisés d’une personne, et non simplement comme un ticket de création ou de désactivation de compte. L’enregistrement de l’événement doit identifier la personne, son statut d’emploi ou de mission, son manager ou son parrain, la date et l’heure d’effet et le rôle concerné. Utilisez un identifiant stable plutôt que de vous fier uniquement aux noms ou aux adresses électroniques.

Les RH initient souvent les événements concernant les salariés. Un responsable des achats, un chef de projet ou un parrain interne peut initier ceux des prestataires. Choisissez une source faisant autorité pour chaque population et définissez comment les corrections, les arrivées annulées, les prolongations de contrat et les départs urgents parviennent à l’informatique.

Séparez quatre responsabilités, même lorsqu’une petite équipe en confie plusieurs à la même personne :

Désignez des suppléants et une voie d’escalade. Un départ planifié ne doit pas dépendre de la disponibilité d’un seul administrateur. Pour les changements sensibles, un réviseur indépendant apporte un contrôle utile ; lorsque les effectifs ne le permettent pas, documentez l’organisation retenue et prévoyez une revue a posteriori.

Définissez des critères d’achèvement pour chaque événement. Une arrivée est prête lorsque les accès approuvés et les mesures requises sur l’appareil sont vérifiés. Une mobilité est terminée lorsque les ajouts comme les retraits ont été contrôlés. Un départ est terminé lorsque les voies d’accès sont révoquées et que les questions non résolues relatives aux équipements, aux données ou aux identifiants ont des responsables explicites.

Il s’agit de recommandations pratiques de conception des mesures, et non de délais légaux universels. Au sein d’un SMSI ISO 27001, les mesures de contrôle d’accès doivent refléter le périmètre et le traitement des risques de l’organisation. Voir l’article L’annexe A de l’ISO 27001 en pratique pour le contexte plus large des mesures.

Établir la couverture avant d’automatiser les changements

Commencez par l’inventaire des applications. Pour chaque système, consignez son responsable, sa source d’identité, sa méthode de provisionnement, sa méthode d’authentification, les actions de révocation prises en charge et la méthode de vérification. Incluez les applications gérées de façon centralisée et celles qui disposent de comptes locaux.

L’authentification unique ne signifie pas nécessairement une gestion complète du cycle de vie. Une application peut authentifier via le fournisseur d’identité tout en conservant des administrateurs locaux, des clés d’API, des sessions actives ou des options de récupération. Un connecteur de provisionnement peut désactiver un utilisateur sans retirer chaque droit. Documentez ce que chaque mécanisme fait réellement.

Incluez ces voies d’accès moins visibles :

• Les comptes à privilèges distincts du compte quotidien de la personne.
• Les accès VPN, les certificats, les clés SSH et les outils d’assistance à distance.
• Les jetons d’accès personnels, les identifiants d’API et les mots de passe d’application.
• Les identifiants partagés que la personne connaissait ou pouvait récupérer.
• Les comptes invités, les espaces de collaboration externes et les environnements gérés par les clients.
• Les identités de service dont le propriétaire ou le dépositaire des identifiants change.

Ne désactivez pas automatiquement toutes les identités de service associées à un salarié qui part : l’une d’elles peut faire tourner une charge de production. Transférez plutôt la propriété, revoyez les droits et renouvelez les identifiants exposés lorsque c’est approprié. L’objectif est de retirer l’accès de la personne sans provoquer une interruption évitable.

Rapprochez périodiquement l’inventaire des exports d’identités, des enregistrements d’appareils, des registres d’achats et des déclarations des équipes. Aucune source unique ne révélera nécessairement chaque application. Les découvertes non gérées doivent entrer dans le processus de cycle de vie plutôt que de rester des exceptions informelles.

Arrivées : provisionner un état de départ maîtrisé

Construire des profils de rôle avec des exceptions encadrées

Définissez des ensembles d’accès selon les responsabilités, et pas seulement selon les intitulés de poste. Un analyste du support peut avoir besoin d’accéder aux tickets clients mais pas aux exports de facturation. Un ingénieur logiciel peut avoir besoin des dépôts de code et des environnements de développement sans recevoir par défaut l’administration de la production.

Chaque profil de rôle doit avoir un responsable, une version, des groupes ou droits inclus et une date de revue. Consignez la version appliquée à chaque arrivée. Sinon, une mise à jour ultérieure du rôle rend difficile la reconstitution des décisions d’accès passées.

Demandez séparément les accès supplémentaires. La demande doit indiquer la finalité métier, le responsable du système ou des données qui valide, le niveau de droits et, le cas échéant, l’échéance. Évitez de copier l’ensemble des droits d’un salarié existant : vous risquez de reproduire les exceptions accumulées et les privilèges issus de rôles antérieurs.

Préparez les comptes avant la date d’arrivée lorsque c’est utile, mais maîtrisez leur activation. Une embauche annulée doit déclencher le nettoyage des comptes préparés, des appareils expédiés et des invitations. Les prestataires doivent avoir un parrain interne et une date de fin ou de revue ; les prolongations doivent exiger une décision explicite plutôt que de se transformer silencieusement en accès permanent.

Établir le socle de l’appareil et de l’authentification

Consignez l’identifiant de l’appareil, la personne à laquelle il est attribué, la date de remise et l’inscription au système de gestion. Vérifiez le socle pertinent avant d’accorder des accès sensibles : système d’exploitation pris en charge, état des correctifs, chiffrement du disque, verrouillage de l’écran, protection des terminaux et configuration d’authentification approuvée.

Il s’agit de choix de mise en œuvre fondés sur les risques, et non d’une affirmation selon laquelle toutes les organisations doivent utiliser des paramètres identiques. Pour les appareils personnels, définissez explicitement les accès autorisés et le traitement des données plutôt que de les considérer comme équivalents à des ordinateurs portables gérés.

Utilisez, lorsqu’elles existent, des observations datées issues des systèmes de gestion des appareils. Un inventaire manuel peut rester utile s’il est rapproché et étayé par des preuves ; un inventaire en temps réel mérite aussi un examen attentif lorsqu’un appareil a cessé de remonter des informations. Conservez les heures d’observation afin qu’un ancien état satisfaisant ne soit pas pris pour une assurance actuelle.

Vérifiez l’enrôlement à l’authentification et la remise initiale des identifiants. Lorsque votre politique exige l’authentification multifacteur, confirmez qu’elle est active avant le début de l’accès, plutôt que de consigner seulement l’envoi d’une invitation d’enrôlement. Ne mettez ni identifiants ni codes de récupération dans les tickets du cycle de vie.

Mobilités : retirer l’ancien rôle, pas seulement ajouter le nouveau

Les mutations sont souvent les événements les plus délicats du cycle de vie, car la personne reste en poste et son compte existant continue de fonctionner. Les nouveaux accès retiennent l’attention parce que des droits manquants bloquent le travail. Les anciens accès peuvent persister sans aucun symptôme visible.

Traitez la mobilité comme une comparaison entre trois états : les accès actuels, le nouveau profil approuvé et les exceptions maintenues approuvées. Déterminez quels droits doivent être ajoutés, conservés, réduits ou retirés. Vérifiez les attributions directes ainsi que les groupes, les appartenances imbriquées, les rôles d’administration et les droits locaux des applications.

L’ancien manager doit aider à identifier les responsabilités qui ont pris fin. Le manager d’accueil confirme les nouvelles fonctions, tandis que les responsables des systèmes ou des données valident les accès sensibles. On évite ainsi qu’un nouveau manager autorise implicitement le maintien d’accès aux informations d’un autre service.

Une période de transition peut être légitime. Une personne qui quitte la finance peut avoir besoin d’un accès limité pour achever une passation. Consignez le droit précis, la justification, le responsable qui valide et l’échéance. Lorsque c’est possible, remplacez un large accès en écriture par un accès plus restreint ou en lecture seule. Inscrivez l’échéance dans une tâche exécutable ou un paramètre système, et pas seulement dans un commentaire.

Les changements peuvent aussi concerner les appareils, les boîtes aux lettres partagées, la responsabilité des données et les fonctions à privilèges. Passer à un rôle d’administration ne doit pas transformer automatiquement le compte quotidien en identité à privilèges.

Après l’exécution, comparez l’ensemble réel des accès au résultat visé. Lors d’un changement de service, attribuer le nouveau rôle peut être simple. Le contrôle important consiste à vérifier s’il subsiste d’anciens accès à la finance, aux données clients ou à l’administration. Un échantillon de mobilités qui ne vérifie que le nouveau provisionnement passe à côté de ce risque.

Départs : coordonner la révocation, les équipements et la continuité de l’activité

Fixer le calendrier selon le risque et les circonstances

Consignez une heure de révocation effective, fuseau horaire compris. « Dernier jour » est trop ambigu pour des équipes réparties et pour l’automatisation planifiée. Distinguez un départ planifié d’un licenciement urgent, d’une compromission suspectée ou d’une absence imprévue nécessitant une suspension temporaire.

Convenez du calendrier avec les RH et la direction concernée. Limitez les détails sensibles d’une rupture aux personnes qui en ont besoin, tout en veillant à ce que les exécutants disposent de suffisamment d’informations pour agir. Les départs à haut risque peuvent exiger une action immédiate coordonnée ; les départs ordinaires peuvent permettre une passation planifiée avant la fin des accès.

Ne laissez pas le transfert des données ou l’expédition des appareils retarder la révocation. Ces activités peuvent avoir leurs propres dates d’achèvement et leurs propres responsables. Si un déclencheur arrive en retard, consignez l’heure de coupure prévue, l’exécution réelle et l’intervalle d’exposition plutôt que de modifier les documents pour que l’événement paraisse traité à temps.

Fermer toutes les voies d’accès pertinentes

Désactivez l’identité principale et exécutez les actions propres à chaque application figurant dans l’inventaire. Traitez, selon le cas, les sessions actives, les jetons d’actualisation, les comptes locaux, les comptes à privilèges, l’accès à distance, les certificats et les identifiants personnels. La désactivation d’un compte central ne prouve pas que chaque session existante ou chaque identifiant émis indépendamment est devenu inutilisable.

Renouvelez, selon le risque, les secrets partagés auxquels la personne pouvait accéder, et vérifiez que ce renouvellement ne perturbera pas les systèmes qui en dépendent. Supprimez les méthodes de récupération ou les délégations qui pourraient rétablir l’accès. Lorsque des environnements de clients ou de fournisseurs sont concernés, demandez la révocation à leur responsable et conservez sa confirmation.

Consignez chaque résultat individuel. Un dépassement de délai d’un connecteur n’est pas une fermeture réussie au seul motif que la tâche globale s’est terminée. Acheminez les échecs vers un intervenant nommé, utilisez une solution de repli approuvée et vérifiez l’état final. Les accès urgents non résolus doivent entrer dans le processus d’escalade de sécurité.

Récupérer les appareils sans supposer que les commandes à distance ont abouti

Suivez chaque équipement attribué jusqu’à sa restitution, son inspection et sa réinitialisation ou sa mise au rebut approuvée. Pour les collaborateurs à distance, consignez les modalités d’expédition et les questions de garde non résolues. Retirez les accès physiques et récupérez les jetons ou les clés le cas échéant.

Si la restitution tarde, utilisez les fonctions de verrouillage ou d’effacement disponibles conformément à la politique et au risque. Distinguez l’émission d’une commande de sa prise en compte et de son exécution par l’appareil. Un ordinateur portable hors ligne peut ne pas recevoir la commande. Évaluez l’exposition résiduelle à partir de l’état du chiffrement, des identifiants locaux, des données en cache et des restrictions réseau disponibles plutôt que de considérer « effacement en file d’attente » comme une preuve d’effacement.

Préserver les données nécessaires et récupérer les licences

Désignez un successeur pour les documents métier, les dépôts, les processus partagés et la responsabilité des services. Utilisez des mécanismes de transfert administratif autorisés plutôt que de demander à quelqu’un de se faire passer pour l’ancien salarié. Délimitez l’accès à la messagerie ou aux fichiers, consignez la finalité et limitez le nombre de personnes qui le reçoivent.

Séparez la révocation des accès, la récupération des licences, la conservation et la suppression. Le retrait d’une licence peut affecter la disponibilité des données différemment selon les applications. Vérifiez les exigences de conservation et toute mesure de conservation à des fins contentieuses avant un nettoyage irréversible.

Pour les données à caractère personnel, l’article 5 du RGPD établit le principe de limitation de la conservation ; il ne crée pas de délai universel de suppression des comptes des salariés. Définissez des durées de conservation justifiées et des responsabilités de nettoyage. L’article 32 exige des mesures de sécurité adaptées au risque ; documentez donc le raisonnement qui sous-tend les mesures de départ plutôt que de considérer une liste de contrôle comme une conformité juridique en soi.

Conserver la preuve du changement réel

L’enregistrement utile relie la décision autorisée au résultat observé. Conservez l’événement, la validation, les systèmes concernés, les heures d’exécution, les résultats de vérification et le traitement des exceptions. Incluez l’heure d’effet prévue afin que les réviseurs puissent évaluer le respect des délais.

Un dossier de preuves pratique contient :

• Un identifiant stable de la personne et de l’événement, avec la source qui l’a initié.
• Le profil approuvé et les éventuels droits conservés ou supplémentaires.
• Les actions, résultats, horodatages et références de journaux pertinents par système.
• Une vérification montrant l’état d’accès obtenu.
• Les résultats relatifs aux équipements, au transfert des données et aux licences le cas échéant.
• Les actions en échec et les exceptions, avec un responsable, une échéance et la preuve de leur clôture.

Une politique démontre une intention. Un ticket démontre une coordination. Un résultat applicatif ou un export des accès aide à démontrer la mise en œuvre. Aucun ne doit se substituer aux autres. Les captures d’écran peuvent être utiles lorsque des exports plus probants ne sont pas disponibles, mais elles doivent comporter suffisamment de contexte pour identifier le système, la personne concernée et l’heure d’observation.

Protégez ces enregistrements : ils contiennent des informations relatives à l’emploi et des détails sensibles pour la sécurité. Appliquez des restrictions d’accès et un calendrier de conservation, et évitez de collecter comme preuves des mots de passe, des récits de rupture inutiles ou des boîtes aux lettres entières. Les enregistrements historiques doivent rester compréhensibles même après la suppression des comptes opérationnels.

Exemple concret : une mobilité suivie d’un départ

Prenons l’exemple illustratif d’une entreprise disposant d’un fournisseur d’identité central, d’ordinateurs portables gérés et d’une application financière avec des droits locaux. Supposons qu’une salariée passe des opérations financières au succès client le 1er juin, qu’elle ait besoin d’une passation de cinq jours ouvrés et qu’elle quitte ensuite l’entreprise le 30 septembre. Ces dates et dispositions sont des hypothèses d’exemple, et non des délais prescrits.

Pour la mobilité, l’informatique relève les droits actuels. L’accès au succès client est approuvé, l’accès en écriture à la finance est retiré à l’heure d’effet et un accès restreint en lecture à la finance est maintenu jusqu’à la fin de la passation. Le responsable de la finance approuve cette exception. Comme l’application financière gère des droits locaux, son administrateur exécute et vérifie le changement séparément de la mise à jour des groupes dans le fournisseur d’identité.

À l’échéance, la vérification constate qu’un droit d’export local subsiste. L’enregistrement de mobilité reste ouvert, l’administrateur retire ce droit et le réviseur consigne l’état final. L’enseignement est précis : le changement de rôle a réussi au niveau central, mais le modèle de droits de l’application exigeait une action supplémentaire.

Pour le départ ultérieur, le processus fixe une heure de coupure précise, transfère les fichiers métier à un successeur approuvé, désactive les identités, révoque les sessions et jetons concernés et vérifie directement le compte financier. L’ordinateur portable n’est pas encore arrivé par coursier. Sa restitution reste une exception relative aux équipements, avec des actions de confinement et des observations de l’appareil consignées séparément de la révocation des comptes.

Les preuves obtenues montrent à la fois les changements réussis et l’échec initial du retrait. Masquer cet échec ferait perdre l’information nécessaire pour améliorer le processus.

Tester la couverture et rendre la prochaine amélioration concrète

Échantillonnez des événements réels du cycle de vie au regard de l’inventaire des applications. Incluez des prestataires, des utilisateurs à privilèges, des collaborateurs à distance, des mobilités avec un chevauchement temporaire et des applications hors du fournisseur d’identité. Les revues des accès doivent aussi examiner si les droits actuels correspondent toujours aux responsabilités de chaque personne ; elles complètent les changements déclenchés par des événements au lieu de les remplacer.

Testez les chemins d’échec autant que l’exécution normale : un événement RH manqué, un connecteur en échec, un administrateur indisponible, une restitution d’appareil retardée ou une arrivée annulée. Vérifiez que les alertes parviennent à un intervenant et que les nouvelles tentatives ou les actions manuelles produisent des résultats vérifiables.

Parmi les indicateurs utiles figurent le délai de révocation par rapport à l’heure de coupure convenue, les actions en échec en attente de résolution, les accès temporaires échus et les événements clôturés sans vérification. Définissez ce que chaque indicateur compte. Une bonne moyenne peut masquer une exception à privilèges de longue durée. Utilisez les constats pour mettre à jour les profils de rôle, le comportement des connecteurs, les responsabilités et les règles d’escalade.

Secani peut soutenir l’enregistrement vérifiable des mesures en reliant les exigences aux systèmes, aux responsables, aux preuves et aux décisions. Gardez les modifications de comptes dans les systèmes opérationnels de gestion des identités et des appareils ; utilisez l’espace de travail de conformité pour conserver le périmètre, les résultats téléversés, les exceptions et les décisions de revue. Des réviseurs humains doivent valider toute conclusion sur les preuves assistée par l’IA avant de s’y fier.

Commencez par une équipe représentative ainsi qu’une arrivée, une mobilité et un départ récents. Retracez chaque événement, de la notification à l’état réel des systèmes. Corrigez le premier passage de relais ou la première voie d’accès non couverts, attribuez-en la responsabilité et testez de nouveau avant d’étendre le processus.