- La gestion des identités (Identity Management) établit et maintient les attributs numériques d'un utilisateur — qui il est, son rôle, ses attributs métier. La gestion des accès (Access Management) détermine ce que cet utilisateur peut faire sur quels systèmes.
- British Airways (2018) : l'attaque par skimming a exploité une insuffisance dans le contrôle des accès aux composants tiers du site — une dimension de la gestion des accès qui dépasse la gestion des comptes utilisateurs internes.
- Medibank (2022) : la compromission via un prestataire tiers illustre comment une identité légitime (credentials du prestataire) peut être utilisée pour un accès illégitime — la gestion des accès doit contrôler non seulement l'identité mais le comportement d'usage.
- La confusion entre les deux domaines conduit à des architectures incomplètes : une organisation qui investit dans la gestion des identités sans implémenter les contrôles d'accès granulaires correspondants dispose d'une authentification forte mais d'une autorisation défaillante.
- Le modèle Zero Trust intègre les deux dimensions : vérification continue de l'identité (authentification) ET de la légitimité de chaque requête d'accès (autorisation) pour chaque ressource, indépendamment de la position réseau.
La distinction entre gestion des identités et gestion des accès est fondamentale pour concevoir une architecture IAM (Identity and Access Management) cohérente. Ces deux domaines sont souvent confondus ou traités comme un seul sous le terme générique "IAM", ce qui conduit à des architectures incomplètes : une organisation peut disposer d'une gestion des identités robuste — annuaire centralisé, authentification forte, cycle de vie des comptes maîtrisé — tout en présentant des lacunes significatives dans ses contrôles d'accès, et vice versa.
La gestion des identités répond à la question "Qui est cet utilisateur ?" : elle établit et maintient les attributs numériques (nom, rôle, appartenance à des groupes, attributs métier), gère le cycle de vie des comptes (création, modification, désactivation), et fournit les mécanismes d'authentification permettant de vérifier que l'utilisateur est bien celui qu'il prétend être. La gestion des accès répond à la question "Que peut faire cet utilisateur authentifié ?" : elle détermine les droits d'accès aux ressources, implémente les politiques d'autorisation, et contrôle les actions permises sur chaque ressource.
La couche d'authentification vs. la couche d'autorisation
L'authentification (Authentication) et l'autorisation (Authorization) sont les deux composantes techniques de la gestion des accès. L'authentification vérifie l'identité : est-ce bien Jean Dupont qui se connecte ? Elle peut s'appuyer sur des facteurs multiples (MFA), des tokens FIDO2, des certificats. L'autorisation détermine ce que Jean Dupont, une fois authentifié, est autorisé à faire : quels fichiers lire, quelles API appeler, quels enregistrements modifier.
Une authentification forte ne compense pas une autorisation défaillante. Un utilisateur authentifié via FIDO2 et SSO mais disposant de droits excessifs constitue toujours une surface d'attaque significative si son compte est compromis ou s'il agit de façon malveillante. C'est pourquoi les contrôles d'autorisation granulaires — RBAC, ABAC, politiques d'accès contextuelles — sont complémentaires et non substituables aux contrôles d'authentification.
L'attaque SolarWinds illustre une dimension avancée de la confusion identité/accès : les attaquants ont compromis des identités numériques hautement légitimes — des tokens de signature de code, des identités de processus de build — pour leur faire accomplir des actions (insertion de backdoor dans les binaires) que ces identités avaient techniquement le droit d'effectuer, mais dans un contexte illégitime. La gestion des identités de machine (tokens, certificats de signature) était insuffisante : ces identités disposaient de droits étendus sans surveillance des actions effectuées. L'incident a accéléré l'adoption du concept d'"identités non humaines" comme catégorie distincte nécessitant ses propres contrôles de cycle de vie et de surveillance comportementale.
Identités humaines et non humaines
La gestion des identités couvre désormais deux catégories distinctes. Les identités humaines : employés, prestataires, partenaires — avec des attributs, des rôles et un cycle de vie lié aux événements RH. Les identités non humaines : comptes de service, API keys, tokens OAuth, certificats, identités de workloads cloud (AWS IAM roles, Azure service principals) — avec un cycle de vie technique lié aux applications et aux infrastructures. Cette seconde catégorie est souvent gérée de façon ad hoc, sans référentiel centralisé, sans rotation automatique, et sans surveillance comportementale équivalente à celle appliquée aux comptes humains.
Le ratio identités non humaines / identités humaines dépasse souvent 10:1 dans les organisations cloud-native — ce qui signifie que la surface d'attaque liée aux identités non humaines est structurellement plus large que celle des comptes utilisateurs, tout en étant beaucoup moins bien maîtrisée. Adresser ce déséquilibre est l'un des enjeux principaux des architectures IAM modernes.
Vers une architecture Zero Trust
Le modèle Zero Trust intègre les deux dimensions en abandonnant la confiance implicite liée à la position réseau : tout accès, qu'il provienne d'un réseau interne ou externe, doit être authentifié et autorisé explicitement pour chaque requête. Ce modèle impose une vérification continue de l'identité (re-authentification contextuelle, surveillance comportementale) et une évaluation dynamique des droits d'accès (politiques d'accès contextuelles intégrant l'état du poste, la localisation, l'heure d'accès). La mise en œuvre est incrémentale — commencer par les ressources les plus sensibles et les accès à privilèges.
L'incident Uber de 2022 illustre l'interaction entre les dimensions identité et accès : un prestataire authentifié via MFA (identité vérifiée) s'est fait approuver la notification push par fatigue, puis l'attaquant a utilisé cette identité légitime pour accéder à des ressources sans rapport avec la fonction du prestataire. La gestion des accès (autorisation) n'était pas configurée pour limiter le périmètre d'action d'une identité prestataire — une fois authentifié, le compte donnait accès à des scripts contenant des credentials admins. La distinction identité/accès aurait dû conduire à des politiques d'autorisation strictes sur les identités prestataires, indépendamment de la solidité du mécanisme d'authentification.
L'impact de WannaCry sur Renault, qui a forcé l'arrêt de plusieurs lignes de production, a mis en évidence une confusion opérationnelle entre la gestion des identités (comptes Windows des utilisateurs) et la gestion des accès réseau (droits de communication entre segments industriels et bureautiques). Les systèmes de production industrielle Renault n'étaient pas isolés du réseau bureautique — les identités de machine pouvaient traverser les segments réseau sans contrôle d'accès restrictif. La segmentation réseau est une composante de la gestion des accès qui complète la gestion des identités utilisateurs.
La présence de quatre ans non détectée dans les systèmes de Cathay Pacific a illustré une défaillance dans la surveillance comportementale des identités authentifiées. L'attaquant disposait d'un accès via un compte légitime compromis — l'identité était authentifiée, les droits d'accès existaient — mais le comportement d'usage (volumes d'accès, horaires, ressources consultées) différait des patterns habituels du titulaire. L'absence de surveillance comportementale (User and Entity Behavior Analytics, UEBA) a permis à l'accès malveillant de passer inaperçu pendant 48 mois dans les logs existants.