Provisioning et déprovisioning des accès - JML, SCIM, IGA

Le provisioning (création/attribution d'accès) et le déprovisioning (retrait d'accès) sont deux faces d'un même processus : la gestion du cycle de vie des identités, ou Joiner-Mover-Leaver (JML). Mal automatisé, ce processus produit les deux plus grandes failles silencieuses de toute organisation : les comptes orphelins d'anciens salariés et les privilèges hérités de fonctions passées. Ce guide explique comment industrialiser le cycle, avec SCIM, les plateformes IGA modernes, les signaux HR, et les métriques qui distinguent un IAM mature d'un IAM permissif.

1. Pourquoi le cycle de vie des accès est critique

1.1 Les deux risques structurels

Un process JML défaillant produit invariablement deux catégories de risques :

• Orphan accounts : comptes créés pour des personnes parties, jamais supprimés. Vecteur classique d'attaque - un attaquant qui obtient un credential d'un ex-salarié accède encore aux systèmes. Verizon DBIR 2024 : les comptes d'anciens employés sont impliqués dans 11 % des compromissions internes.
• Permission creep : accumulation silencieuse de permissions au fil des changements de rôle, sans jamais retirer les anciennes. Un développeur devenu manager garde ses accès techniques, puis prend un accès cloud, puis un accès finance quand il dirige un projet transverse. Trois ans plus tard, son compte cumule un périmètre qu'aucun single rôle ne justifie.

1.2 Le coût de la négligence

Cas documentés récents où un déprovisioning défaillant a causé l'incident :

• Morgan Stanley (2020) : des comptes d'ex-employés sur des applications wealth management restés actifs 6+ mois après départs, exposant des données client. Amende FINRA de 35 millions USD.
• Uber (2022) : un contractor dont les credentials ont fuité, actif dans le SI bien après fin de contrat. Point de départ de l'incident majeur.
• Cas fréquent en PME : un ancien admin IT qui "teste" ses anciens accès 6 mois après son départ pour voir s'ils marchent encore - et ils marchent.

1.3 Ce que cache "nous avons un bon offboarding"

Dans la plupart des organisations non-matures, "offboarding" signifie :

• RH envoie un email à l'IT pour désactiver Active Directory.
• L'IT désactive AD sous 24-72 heures.
• Les comptes SaaS individuels (Salesforce, Jira, Confluence, Notion, GitHub, Slack, ...) sont désactivés au fil de l'eau sur les 2-4 semaines suivantes.
• Les accès cloud (AWS console access, GCP, Azure) parfois jamais désactivés.
• Les tokens Git long-lived, clés SSH, tokens API personnels : rarement révoqués.

Résultat : un leaver peut accéder à des ressources critiques pendant des mois après son départ. Dans 8 cas sur 10, personne ne s'en rendrait compte s'il n'en parlait pas.

2. Le modèle JML - Joiner, Mover, Leaver

Le cycle de vie d'une identité en 3 phases.

2.1 Joiner (arrivée)

Création d'une nouvelle identité et attribution des accès initiaux.

Actions types :

• Création du compte AD / Entra ID / Okta.
• Provisioning des accès "birthright" (accès de base donnés à tous : email, calendar, intranet, chat).
• Provisioning des accès spécifiques à la fonction (dev accès repos, finance accès SAP, ops accès cloud).
• Distribution du matériel (laptop, badge).
• Onboarding formation sécurité obligatoire.

Objectif mature : toute l'infrastructure technique est prête le jour 1, zéro ticket manuel.

2.2 Mover (changement interne)

L'identité existe toujours mais son périmètre change : promotion, mutation, réorganisation, projet transverse.

Actions types :

• Ajout des accès du nouveau rôle.
• Retrait des accès de l'ancien rôle.
• Revérification des rattachements (manager, équipe, coût center).
• Mise à jour des groupes.

Ce que la plupart des organisations ratent : le retrait. On ajoute toujours, on retire rarement.

2.3 Leaver (départ)

Retrait complet des accès et fermeture de l'identité.

Actions types :

• Désactivation immédiate (pas suppression) de l'identité dans l'IdP.
• Désactivation des sessions actives (token revocation, SSO session termination).
• Récupération du matériel.
• Transfert des données détenues (mailbox, fichiers, projets).
• Après période légale : suppression définitive.

Distinction critique : désactivation ≠ suppression. On désactive immédiatement, on supprime après période de conservation légale (RGPD, obligations fiscales, contentieux possibles).

2.4 Trois variantes importantes du Leaver

• Départ standard : préavis respecté, transition planifiée. Simple.
• Départ d'urgence / licenciement : déprovisioning instantané avant notification de la personne pour éviter vengeance / exfiltration. Processus dédié avec RH + IT coordonnés.
• Départ externe/contractor : cycle plus court, processus distinct (contrat au lieu de SIRH).

3. HR comme source de vérité

3.1 Principe

Le SIRH (Système d'Information des Ressources Humaines) doit être la source unique de vérité pour l'état d'une identité : existence, statut (actif/inactif), rôle, équipe, manager, site.

Si chaque outil applicatif a sa propre liste d'utilisateurs maintenue manuellement, rien ne marche. HR pilote, IAM exécute.

3.2 Les 3 événements HR clés

Les événements qui déclenchent JML :

1. Création d'un employé en SIRH (avec date de début) → déclenche Joiner.
2. Modification (équipe, manager, titre) → déclenche Mover.
3. Désactivation / termination → déclenche Leaver.

Ces événements doivent se propager automatiquement via intégration HR → IdP → applications SaaS → cloud.

3.3 Intégrations HR typiques

Les principaux SIRH exposent des APIs ou des connecteurs pour alimenter les IdP :

• Workday (leader enterprise) : APIs riches, connecteurs natifs Okta/Entra/SailPoint.
• SAP SuccessFactors : similaire, très répandu.
• BambooHR, HiBob, Personio : plus orientés PME/mid-market, connecteurs Okta/Entra.
• ADP, Silae, Sage : SIRH français/européens.

Pattern moderne : HR publie des événements → middleware IGA les consomme → IGA orchestre la propagation.

3.4 Contractors et identités non-salariés

Le SIRH classique ne gère souvent pas les contractors, freelances, stagiaires, volontaires. Deux approches :

• Module contractor dans le SIRH (Workday Contingent Workers, SuccessFactors External Workforce).
• Système parallèle : CSV / application dédiée, synchronisé vers IdP avec processus équivalent.

Critique : ces identités doivent avoir les mêmes contrôles que les employés. Elles sont même souvent plus risquées (accès temporaire, faible formation sécurité, moins d'attache à l'organisation).

4. SCIM - le standard du provisioning automatisé

4.1 Définition

SCIM (System for Cross-domain Identity Management) est un standard IETF (RFC 7643-7644) qui définit une API REST pour la gestion des identités à travers des systèmes hétérogènes.

SCIM 2.0 (2015) est la version courante. Elle permet :

• Création, modification, suppression d'utilisateurs depuis un IdP vers une application.
• Gestion des groupes et appartenances.
• Synchronisation bidirectionnelle si nécessaire.
• Schéma extensible (attributs custom).

4.2 Objets SCIM principaux

• Users : représentation de l'utilisateur (username, name, email, active, groups, custom attributes).
• Groups : collections d'utilisateurs, souvent mappées à des rôles applicatifs.
• Resources types : extensions possibles (Roles, Entitlements).

4.3 Exemple de payload SCIM - création d'un utilisateur

POST /scim/v2/Users
 
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "jean.dupont@example.com",
  "name": {
    "givenName": "Jean",
    "familyName": "Dupont"
  },
  "emails": [
    {
      "primary": true,
      "value": "jean.dupont@example.com",
      "type": "work"
    }
  ],
  "active": true,
  "groups": [
    {
      "value": "engineering",
      "display": "Engineering Team"
    }
  ]
}

4.4 Applications qui supportent SCIM

La majorité des grands SaaS en 2026 :

• Collaboratif : Slack, Microsoft Teams, Google Workspace, Zoom, Notion.
• Dev : GitHub Enterprise Cloud, GitLab Premium, Jira Cloud, Linear.
• Sales : Salesforce, HubSpot.
• Support : Zendesk, Intercom, Freshdesk.
• Data : Snowflake, Databricks, Looker, Tableau.
• Cloud : AWS IAM Identity Center, GCP Cloud Identity, Azure.

Applications qui ne supportent pas SCIM nativement :

• Nombreuses applications legacy.
• Petites SaaS de niche.
• Outils internes custom.

Pour ces cas : connecteurs custom via IGA ou scripts de synchronisation.

4.5 Ce que SCIM ne résout pas

• Provisioning infrastructure (création d'un repo GitHub, d'un channel Slack dédié). SCIM gère les users et groupes, pas les ressources métiers.
• Permissions fines applicatives (un user qui a accès à un projet spécifique dans Jira). SCIM fournit un cadre, l'application configure le détail.
• Workflows d'approbation. SCIM exécute, ne décide pas.

Pour ces besoins avancés : plateformes IGA (voir §6).

5. Automatiser l'onboarding - workflow mature

5.1 Vision cible

Jour J-7 : RH crée le collaborateur dans Workday avec date de début.

Dès la validation HR : SCIM / middleware IGA déclenche en cascade :

1. Création du compte IdP (Entra ID / Okta).
2. Génération du mot de passe initial chiffré transmis par canal sécurisé.
3. Attribution des groupes birthright (basés sur département + fonction).
4. Propagation SCIM vers applications fédérées (Slack, GitHub, Jira, Confluence).
5. Provisioning Google Workspace / Microsoft 365 (mailbox, drive).
6. Création du compte VPN, configuration MFA initiale.
7. Commande hardware (laptop, écran) via intégration ITSM.
8. Inscription aux formations sécurité obligatoires.
9. Notification manager avec checklist accueil.

Jour J : le collaborateur reçoit son laptop, se connecte, ses accès fonctionnent. Premier login : FIDO2 enrollment.

5.2 Rôles birthright vs role-based

• Birthright access : accès donnés à tout employé (email, chat, intranet, VPN). Automatique sans approbation.
• Role-based access : accès spécifiques à une fonction ou équipe (développeur = GitHub + IDE licences ; finance = SAP ; sales = Salesforce). Attribués via règles basées sur le titre/département dans HR.
• Request-based access : accès exceptionnels demandés par l'utilisateur (accès projet spécifique, outil spécialisé). Approbation manager + owner de la ressource.

5.3 Birthright bien calibré

Erreur fréquente : donner un birthright trop large "pour éviter les tickets". Résultat : chaque nouvel arrivant a accès à 80 % des ressources, violant le least privilege.

Birthright bien calibré :

• Email et calendar : oui.
• Chat (Slack / Teams) : oui.
• Intranet, HR self-service : oui.
• VPN : oui mais sans accès serveurs spécifiques.
• GitHub, Jira : non par défaut, attribué selon rôle.
• AWS/GCP/Azure : non par défaut, attribué selon rôle.
• Bases de données : non par défaut.

6. Industrialiser avec une plateforme IGA

Pour des organisations de plus de 500-1000 identités, le provisioning manuel ou scripté atteint ses limites. Les plateformes IGA (Identity Governance and Administration) prennent le relais.

6.1 Fonctionnalités typiques d'une plateforme IGA

• Provisioning automatisé vers des centaines d'applications connectées.
• Workflow d'approbation multi-niveaux (manager, owner ressource, sécurité).
• Access request portal : self-service pour demander de nouveaux accès.
• Access reviews périodiques (trimestrielles, annuelles).
• Role mining : analyse des accès existants pour proposer des rôles cohérents.
• Policies de séparation des tâches (SoD) : empêcher un même utilisateur d'avoir des accès incompatibles (ex. créer fournisseur + valider paiement).
• Audit et reporting : pour conformité SOX, SOC 2, ISO 27001.

6.2 Leaders du marché 2026

Pour PME : Entra Identity Governance ou Okta IG suffisent généralement. Pour grandes entreprises avec SI hétérogène : SailPoint ou Saviynt dominent.

6.3 Quand investir dans IGA

Signaux indiquant le besoin d'une plateforme IGA :

• Plus de 500 employés + contractors.
• Plus de 50 applications à provisionner.
• Obligations de conformité (SOX, ISO 27001, SOC 2, DORA, NIS 2).
• Offboarding manuel qui prend plus de 2 heures par leaver.
• Access reviews impossibles à mener manuellement.

Sans IGA mais avec ces signaux : l'organisation porte un risque caché et produit de la dette opérationnelle.

7. Le déprovisioning - la phase critique

7.1 Timing optimal

Le déprovisioning doit être instantané à la date de départ effective. Pour atteindre ce niveau :

• Date de départ connue dans HR au plus tard 24h avant (idéalement plusieurs jours/semaines).
• Processus automatisé déclenché à heure précise.
• Désactivation simultanée de toutes les sessions et tokens actifs.

Pour les départs d'urgence : déclenchement manuel par HR/sécurité, sans attendre.

7.2 Checklist déprovisioning complet

• Désactivation compte IdP (Entra ID / Okta / Google).
• Révocation de toutes les sessions actives (SSO tokens, refresh tokens).
• Désactivation SCIM propagée à toutes les applications fédérées.
• Révocation des Personal Access Tokens Git (GitHub, GitLab, Bitbucket).
• Rotation ou suppression des clés SSH personnelles déployées.
• Suppression des clés GPG personnelles utilisées pour signer commits.
• Révocation des tokens API personnels (cloud, SaaS, internal tools).
• Désactivation VPN.
• Blocage du badge physique.
• Transfert email / forwarding configuré.
• Transfert ownership Google Drive / SharePoint.
• Révocation membership repositories et projets.
• Suppression des comptes locaux dans les applications non-SSO.
• Rotation des credentials partagés dont la personne connaissait la valeur (secrets Vault non-rotés, API keys partagées).
• Suppression des permissions sur comptes de service qu'elle administrait.

Points souvent oubliés : les credentials partagés (si la personne connaissait une API key ou un password de service, il faut le roter) et les certificats (certs TLS signés par elle, certs client déployés sur ses devices).

7.3 Déprovisioning cloud - cas particuliers

Dans AWS/GCP/Azure, plusieurs catégories d'identités à traiter :

• Console users via IdP : désactivés automatiquement via SCIM/SAML.
• Access Keys personnels (AWS) : à inventorier et supprimer (pas géré par SSO).
• Service accounts dont la personne était owner : transférer la propriété.
• Resources taggées par la personne (instances, buckets) : revue ownership.
• IAM roles assumables par la personne : vérifier qu'aucun ne reste.

Outil utile : AWS Access Analyzer pour identifier les permissions résiduelles.

7.4 Chasse aux orphan accounts - exercice régulier

Quatre fois par an minimum :

1. Export de toutes les identités actives depuis chaque application critique.
2. Comparaison avec la liste des employés actifs SIRH.
3. Identification des écarts.
4. Investigation : est-ce un service account légitime ? Un ex-employé oublié ? Un contractor qui aurait dû être désactivé ?
5. Nettoyage.

Dans une org sans IGA mature, ce hunt typique découvre 2-10 % d'orphan accounts à chaque passe.

8. Les identités non-humaines - machines, services, bots

8.1 Un enjeu croissant

Dans un environnement cloud moderne, le ratio est typiquement 10 à 50 identités machine pour 1 identité humaine. Comptes de service, clés API, tokens CI/CD, bots, agents autonomes.

Ces identités ont leur propre cycle de vie :

• Création : au déploiement d'un workload.
• Rotation : périodique des credentials.
• Désactivation : quand le workload est décommissionné.

8.2 Qui est owner d'une identité machine ?

Chaque identité machine doit avoir un human owner documenté. Sinon, au départ de cet human owner (leaver), personne ne sait si l'identité machine doit être conservée ou supprimée.

8.3 Rotation et déprovisioning automatisés

• Secrets éphémères via Vault, AWS Secrets Manager, GCP Secret Manager : credentials générés à la demande, durée de vie courte, rotation automatique.
• Workload identity (IRSA AWS, Workload Identity Federation GCP, Managed Identity Azure) : pas de credential long-lived à gérer.
• SPIFFE/SPIRE : identité cryptographique portable, rotation intégrée.
• Ownership tags obligatoires sur toutes les identités machine, utilisés pour le ménage automatique.

8.4 Ménage des identités orphelines cloud

Régulièrement, scripts ou outils CIEM qui identifient :

• IAM users AWS non utilisés depuis plus de 90 jours.
• Service accounts GCP sans key used récemment.
• Managed Identities Azure non attachées à une ressource.

Ces identités sont candidates à la désactivation/suppression après validation de leur owner.

9. Métriques qui comptent

10. Les erreurs classiques

10.1 HR et IT désynchronisés

Le SIRH enregistre un départ mais l'IT n'est pas notifié, ou avec un décalage. Mitigation : intégration HR → IdP directe, sans intermédiaire humain.

10.2 Mover traité comme un Joiner

Nouveau rôle = nouveaux accès ajoutés, anciens accès jamais retirés. Après 5 movers, l'identité est sur-privilégiée. Mitigation : le processus Mover force une revue et un retrait, pas seulement un ajout.

10.3 Oubli des contractors

SIRH ne les traite pas ou les traite différemment, le déprovisioning échappe au cycle standard. Mitigation : système contractor dédié avec processus équivalent.

10.4 Applications non-SSO ignorées

SSO couvre 80 % des apps, les 20 % restants sont dans un angle mort. Leur déprovisioning reste manuel, souvent oublié. Mitigation : inventaire obligatoire + checklist dédiée pour les applications non-fédérées.

10.5 Credentials partagés jamais rotés

Un ancien admin connaissait le mot de passe du compte partagé ops@example.com. Ce mot de passe n'est jamais changé après son départ. Mitigation : rotation obligatoire à chaque départ de personne ayant eu accès aux secrets partagés.

10.6 Machines sans owner

Services et clés API créés par quelqu'un qui est parti. Personne ne sait à quoi ça sert, personne n'ose supprimer. La dette gonfle. Mitigation : tag owner obligatoire à la création, blocage de création sans owner.

10.7 Pas de test des procédures de déprovisioning d'urgence

Licenciement conflictuel nécessite déprovisioning instantané. Sans procédure testée, le timing dérive, la personne a le temps de copier des données. Mitigation : runbooks testés en drill annuel.

11. Plan d'implémentation sur 12 mois

Mois 1-3 - fondations

• Choix et mise en place de l'IdP central si absent.
• Intégration HR → IdP (automatique ou manuelle dans un premier temps).
• Définition des rôles birthright et par fonction.
• Inventaire complet des applications + leur capacité SCIM.

Mois 4-6 - automatisation SCIM

• Activation SCIM sur les 20 applications les plus utilisées.
• Tests de Joiner et Leaver end-to-end sur pilote.
• Documentation des processus manuels pour les 20 % restants.
• Runbook de déprovisioning d'urgence.

Mois 7-9 - governance

• Mise en place access request portal (via IdP, IGA léger, ou ITSM).
• Premières access reviews semestrielles.
• Intégration contractors dans le cycle formel.
• Audit orphan accounts, nettoyage initial.

Mois 10-12 - maturité

• Déploiement IGA si volumétrie le justifie.
• Access reviews trimestrielles.
• Métriques dashboard CISO.
• Red team exercise orienté IAM (attaques via credentials d'ex-employés simulés).
• Certification SOC 2 ou ISO 27001 sur le volet identité.

12. Verdict et posture Zeroday

Le provisioning et le déprovisioning sont la mécanique invisible de toute sécurité identité. Quand ça marche, personne ne le voit : les gens arrivent productifs, les departs sont étanches. Quand ça ne marche pas, tout le reste de l'arsenal sécurité (MFA, SSO, CIEM, ITDR) est affaibli.

Pour un ingénieur IAM : maîtriser SCIM, HR integrations, IGA platforms est un parcours direct vers des postes senior bien rémunérés. Les profils capables de piloter un programme JML complet sont recherchés et rares.

Pour une organisation : investir dans ce domaine produit des gains durables qui dépassent le périmètre sécurité. Productivité employés (onboarding rapide), compliance (audit trail), réduction coût helpdesk, résilience opérationnelle. C'est l'un des investissements IAM qui se défend le mieux auprès du CFO, pas uniquement du CISO.

Pour approfondir : SSO : définition pour l'authentification qui sert de base à SCIM, least privilege en pratique pour le volet permissions, pourquoi l'identité est centrale en cybersécurité pour le contexte stratégique, qu'est-ce qu'un ingénieur IAM pour le parcours métier.