Gestion des identités : départ d’un collaborateur

Par : Arnout van der Vorst 5 août 2010

Produit et technologie

En gestion des identités, nous distinguons souvent trois scénarios : l’intégration, la mobilité interne et la sortie. La priorité se porte presque toujours sur l’intégration, car l’enjeu est de rendre un nouveau collaborateur rapidement opérationnel. La mobilité interne est souvent moins prioritaire et dépend de la maturité de l’organisation en matière de sécurité et de gestion des rôles.

La sortie est toutefois tout aussi importante, notamment pour la sécurité, les coûts de licences et l’encombrement des environnements informatiques. La nécessité de désactiver les comptes et de retirer les droits peut être forte lorsque des collaborateurs quittent l’entreprise dans des conditions moins favorables. Nous observons cependant une différence de priorité entre la désactivation immédiate des comptes et le nettoyage ultérieur des ressources.

Un point important à garder à l’esprit est la date à laquelle une personne quitte l’entreprise. Elle est presque toujours enregistrée dans un système RH ou un logiciel de paie, puisque l’organisation n’autorisera pas la poursuite du versement du salaire. Ces informations parviennent toutefois rarement à l’IT et il est fréquent que le service informatique lance de sa propre initiative des actions de nettoyage sur la base de ses propres constats (dernière connexion au réseau).

Voici quelques exemples de scénarios que j’ai conçus pour des clients :

Avant qu’une personne ne quitte l’entreprise :

Avertissement envoyé par e-mail 2 semaines à l’avance au collaborateur et à son manager, précisant l’action et la date à laquelle les comptes et les droits seront bloqués.
Avertissement supplémentaire durant les 2 derniers jours.

Le jour du départ :

Blocage de la connexion dans Active Directory (désactivation). Il est également possible de laisser le compte actif tout en n’autorisant la connexion que sur un poste non existant. La boîte aux lettres Exchange reste ainsi accessible, par exemple.
Déplacer le compte vers une OU dédiée.
Retirer l’appartenance aux groupes à l’exception des groupes de distribution, afin d’éviter les NDR vers ces groupes.
Optionnel : attendre un certain nombre de jours avant le blocage si le collaborateur bénéficie d’un délai supplémentaire.
Transfert des droits sur la messagerie et les données vers, par exemple, un manager. Cela peut se faire par délégation ou réattribution des droits, ou par copie complète de ces ressources vers l’espace du manager.
Création d’un ticket clôturé dans TOPdesk avec la description du blocage.
Provisionnement en aval : blocage de l’utilisateur dans l’application X.

Après une période de blocage définie :

Suppression du compte.
Déplacement des données (répertoire personnel, profil, répertoire personnel du serveur Terminal et/ou profils) vers un dossier d’archive.
Extraction de la boîte aux lettres Exchange en PST et stockage sur un serveur d’archive.
Optionnel : suppression complète de tous les e-mails et des données.

Les scénarios ci-dessus peuvent être exécutés de manière automatisée et par étapes, toutefois certaines parties du scénario peuvent également être lancées via un formulaire électronique. Il est par exemple courant d’automatiser l’avertissement et le blocage, mais de placer la suppression définitive "derrière un bouton".