Introduction
Pendant longtemps, la cybersécurité s’est construite autour d’une logique de périmètre. Il fallait protéger le réseau, filtrer les flux, durcir les infrastructures, segmenter les environnements, surveiller les postes et empêcher l’intrusion depuis l’extérieur. Cette approche reste nécessaire. Mais elle ne suffit plus.
La transformation cloud, la généralisation du SaaS, le télétravail, l’externalisation, les accès prestataires, les API, les comptes de service et les environnements hybrides ont profondément modifié la surface d’attaque. Le système d’information n’est plus contenu dans un réseau maîtrisé. Il est distribué entre des applications, des identités, des droits, des jetons d’accès, des consoles d’administration, des annuaires, des tenants cloud et des services tiers.
Dans ce contexte, une évidence s’impose aux RSSI : les attaquants ne cassent plus seulement les systèmes. Ils se connectent avec des accès valides. Cette évolution ne signifie pas que les vulnérabilités techniques disparaissent. Au contraire, les rapports récents montrent que l’exploitation de vulnérabilités reste un vecteur d’intrusion majeur, parfois devant le vol d’identifiants comme point d’entrée initial.
Le Verizon DBIR 2026 indique ainsi que 31 % des violations commencent par l’exploitation de vulnérabilités logicielles. Mais une fois l’accès obtenu, la progression de l’attaquant dépend très souvent d’une question d’identité : quel compte utiliser, quel privilège détourner, quel jeton réutiliser, quel accès tiers exploiter, quel administrateur imiter ? L’Identity Security n’est donc pas une brique supplémentaire dans l’outillage cyber. Elle devient un principe d’architecture, de gouvernance et de conformité.
De la sécurité réseau à la sécurité des identités
Le modèle historique reposait sur une distinction relativement simple : l’intérieur du réseau était réputé plus fiable que l’extérieur. Le pare-feu matérialisait une frontière. Les contrôles étaient concentrés sur les points d’entrée. Les utilisateurs internes, une fois authentifiés, bénéficiaient souvent d’un niveau de confiance élevé.
Ce modèle est désormais insuffisant.
Un collaborateur peut accéder à une application métier depuis un ordinateur personnel, un prestataire peut intervenir sur un tenant cloud, une API peut interagir avec un ERP, un compte de service peut déployer du code en production, un administrateur peut gérer plusieurs environnements critiques depuis une console SaaS. Dans chacun de ces cas, le sujet central n’est pas seulement le réseau. C’est l’identité, son niveau de confiance, ses droits effectifs, son contexte d’usage et sa traçabilité.
Le NIST formalise cette rupture dans son approche Zero Trust : la confiance ne doit pas être accordée implicitement en raison de l’emplacement réseau ou de la propriété de l’actif ; l’authentification et l’autorisation doivent être évaluées avant l’accès à une ressource. Le Zero Trust déplace ainsi le centre de gravité de la sécurité vers les utilisateurs, les actifs et les ressources, et non plus uniquement vers les segments réseau.
Pour un RSSI, cela signifie que l’identité devient un périmètre opérationnel. Elle doit être inventoriée, gouvernée, contrôlée, journalisée, revue et auditée avec le même niveau d’exigence que les actifs techniques.
Les comptes compromis : une menace silencieuse
Une compromission d’identité est souvent plus difficile à détecter qu’une intrusion technique classique. Lorsqu’un attaquant exploite un compte valide, il peut agir dans les limites apparentes d’un comportement autorisé. Il se connecte avec un identifiant existant, utilise parfois une authentification réussie, consulte des ressources accessibles au compte et déclenche moins d’alertes qu’un malware ou une exploitation bruyante.
C’est précisément ce que révélait l’incident FICOBA : le risque ne venait pas seulement de la sensibilité de la base consultée, mais de l’utilisation d’accès légitimes dans un contexte où la journalisation, la détection d’anomalies, la gouvernance des habilitations et le contrôle des usages deviennent déterminants.
À lire en complément : notre article sur l’incident FICOBA et les comptes légitimes comme vecteurs d’exfiltration. Les scénarios sont nombreux :
- Un compte collaborateur compromis peut servir à accéder à une messagerie, récupérer des documents, initier une fraude au président ou contourner certains contrôles internes.
- Un compte administrateur peut permettre de modifier des règles de sécurité, désactiver des journaux, créer de nouveaux comptes, extraire des données ou rebondir vers d’autres environnements.
- Un compte prestataire peut fournir un accès discret, parfois maintenu au-delà de la mission initiale.
- Un compte dormant peut être réactivé sans attirer l’attention, surtout s’il appartient à un ancien collaborateur ou à un ancien projet.
- Un compte de service peut disposer de privilèges excessifs, avec un secret statique rarement renouvelé.
- Une application SaaS mal gouvernée peut conserver des droits OAuth, des accès API ou des délégations qui échappent à la vision centrale de la DSI.
L’Identity Security consiste précisément à réduire ces angles morts.
Comptes à privilèges : le point de bascule du risque
Tous les comptes ne présentent pas le même niveau de risque. Un compte utilisateur standard peut exposer des données métier. Un compte à privilèges peut transformer une compromission locale en incident systémique.
Les comptes à privilèges incluent les administrateurs systèmes, administrateurs cloud, administrateurs annuaires, comptes de déploiement, comptes de maintenance, comptes d’urgence, comptes de service, comptes DevOps, comptes d’administration SaaS et comptes utilisés par certains prestataires. Leur criticité tient à leur capacité d’action : création ou suppression d’identités, élévation de privilèges, accès aux sauvegardes, modification de configurations, gestion des clés, consultation massive de données, administration de la sécurité elle-même.
Le principe du moindre privilège ne peut donc pas rester théorique. Il doit devenir mesurable.
- Un programme mature doit répondre à plusieurs questions simples :
- Qui détient des droits d’administration ?
- Pourquoi ces droits sont-ils nécessaires ?
- Depuis quand existent-ils ?
- Sont-ils permanents ou temporaires ?
- Sont-ils utilisés ?
- Sont-ils journalisés ?
- Sont-ils revus par un responsable métier ou technique ?
- Sont-ils associés à une authentification forte ?
- Sont-ils protégés par une solution PAM ?
La difficulté, pour les organisations, n’est pas seulement de définir une politique. Elle est de prouver que cette politique est appliquée dans la durée.
MFA : nécessaire, mais insuffisant
L’authentification multifacteur est devenue un contrôle incontournable. NIS2 mentionne explicitement l’usage de solutions d’authentification multifacteur ou d’authentification continue parmi les mesures de gestion des risques de cybersécurité prévues à l’article 21.
Mais la MFA ne règle pas tout.
Elle peut être contournée par du phishing avancé, de l’ingénierie sociale, des attaques par fatigue MFA, des proxys adversary-in-the-middle, le vol de cookies de session, la compromission de terminaux, la réinitialisation frauduleuse via support IT ou la compromission d’un fournisseur tiers. C’est pourquoi les recommandations actuelles insistent de plus en plus sur des mécanismes de MFA résistants au phishing, comme les passkeys, FIDO2/WebAuthn ou les approches cryptographiques liées à l’origine du site. La CISA recommande explicitement de privilégier une MFA résistante au phishing, et le NIST SP 800-63-4 intègre la résistance au phishing dans ses lignes directrices relatives à l’authentification.
Activer la MFA est une étape minimale. La vraie maturité consiste à savoir où elle est obligatoire, sous quelle forme, pour quels comptes, avec quelles exceptions, et avec quelle capacité de détection en cas d’usage anormal.
Une organisation peut afficher un taux de couverture MFA élevé tout en conservant des failles majeures : comptes de service non protégés, comptes d’urgence exclus, applications legacy non fédérées, accès administrateurs insuffisamment contrôlés, exemptions non revues, sessions persistantes trop longues, droits OAuth non maîtrisés.
Le sujet n’est donc pas seulement l’authentification. C’est la gouvernance complète du cycle de vie de l’identité.
IAM, IGA, PAM : trois fonctions complémentaires
La confusion entre IAM, IGA et PAM est fréquente. Ces trois domaines sont liés, mais ils ne répondent pas au même besoin. L’IAM, ou Identity and Access Management : organise la gestion opérationnelle des identités et des accès. Il couvre généralement l’annuaire, le SSO, la fédération d’identité, l’authentification, le provisioning, le déprovisioning et l’application des règles d’accès. L’IGA, ou Identity Governance and Administration : ajoute une couche de gouvernance. Il ne s’agit plus seulement de donner un accès, mais de savoir si cet accès est justifié, validé, compatible avec les règles de séparation des tâches, revu périodiquement et traçable. L’IGA répond aux questions d’audit : qui a accès à quoi, qui l’a approuvé, sur quelle base, depuis quand, et quand cet accès sera-t-il revu ? Le PAM, ou Privileged Access Management : se concentre sur les comptes à privilèges. Il permet notamment de coffre-forter les secrets, d’imposer l’accès juste-à-temps, d’enregistrer les sessions, de contrôler les élévations de privilèges, de gérer les comptes d’urgence et de réduire l’usage de comptes administrateurs permanents. Ces trois briques ne se substituent pas les unes aux autres. Elles forment un dispositif cohérent.
- L’IAM permet de gérer l’accès.
- L’IGA permet de gouverner et prouver l’accès.
- Le PAM permet de maîtriser les privilèges critiques.
Une démarche Identity Security mature articule ces trois dimensions autour d’une même logique : chaque accès doit être nécessaire, vérifié, limité, tracé, révisable et révocable.
Les angles morts : prestataires, SaaS et identités non humaines
La sécurité des identités ne concerne plus uniquement les salariés.
Les prestataires disposent souvent d’accès sensibles, parfois pour des missions courtes, parfois pour des maintenances récurrentes. Le risque apparaît lorsque ces accès ne sont pas limités dans le temps, pas rattachés à un responsable interne, pas soumis à une MFA robuste, pas journalisés ou pas supprimés à la fin de la mission.
Les environnements SaaS créent un autre angle mort. Une direction métier peut déployer un outil sans intégration complète avec l’annuaire central. Des comptes locaux peuvent coexister avec le SSO. Des administrateurs applicatifs peuvent conserver des droits élevés en dehors de la supervision sécurité. Des connecteurs OAuth peuvent obtenir des permissions larges sans revue régulière. La surface d’identité devient alors fragmentée.
Enfin, les identités non humaines prennent une importance considérable : comptes de service, secrets CI/CD, clés API, workloads cloud, agents d’automatisation, robots RPA, applications interconnectées, pipelines DevOps. Ces identités disposent parfois de droits très puissants, mais elles sont moins visibles que les comptes humains. Elles ne partent pas en congé, ne changent pas de poste et ne signalent pas elles-mêmes que leurs droits sont excessifs.
Un programme Identity Security qui ignore ces identités non humaines reste incomplet.
NIS2, DORA, ISO 27001 : l’identité comme preuve de conformité
L’Identity Security s’inscrit directement dans les référentiels et textes réglementaires actuels. NIS2 impose aux entités concernées des mesures techniques, opérationnelles et organisationnelles de gestion des risques. L’article 21 mentionne notamment la sécurité des ressources humaines, les politiques de contrôle d’accès, la gestion des actifs, l’authentification multifacteur ou continue, ainsi que les communications sécurisées. L’identité est donc au cœur de la mise en conformité opérationnelle, même lorsque le texte ne parle pas explicitement d’IAM ou de PAM.
DORA, applicable depuis le 17 janvier 2025 aux entités financières concernées, renforce également les exigences de résilience numérique et de gestion du risque ICT. Les textes délégués relatifs au cadre de gestion des risques ICT prévoient des politiques documentées de gestion des identités et de contrôle des droits d’accès, incluant l’identification unique, l’authentification, l’attribution des droits et le contrôle des accès privilégiés.
ISO/IEC 27001:2022 fournit, pour sa part, un cadre structurant pour intégrer l’identité dans un système de management de la sécurité de l’information. Les contrôles de l’annexe A relatifs au contrôle d’accès, à la gestion des identités, aux informations d’authentification et aux droits d’accès constituent une base de gouvernance essentielle pour formaliser les politiques, responsabilités, preuves et revues associées.
ISO/IEC 27005 complète cette logique en replaçant l’identité dans une approche par les risques. Tous les accès ne se valent pas. Un compte RH, un administrateur cloud, un prestataire de maintenance, une clé API de production ou un compte de service DevOps n’ont ni la même vraisemblance d’exploitation, ni le même impact potentiel. La gestion du risque permet donc de prioriser les contrôles là où ils réduisent réellement l’exposition.
Pour approfondir cette trajectoire de conformité, consultez nos formations NIS Directive Lead Implementer, ISO 27001 Lead Implementer, DORA et ISO 27005 Risk Manager.
De la politique d’accès à la preuve d’audit
La plupart des organisations disposent déjà d’une politique de contrôle d’accès. Le problème n’est pas l’existence du document. Le problème est sa preuve d’application. Un auditeur, un régulateur, un client grand compte ou un assureur cyber ne se satisfait plus d’une déclaration générale. Il attend des preuves : inventaire des identités, liste des comptes à privilèges, matrice des rôles, processus d’arrivée-mobilité-départ, revues d’habilitation, tickets d’approbation, journaux d’authentification, règles MFA, exceptions documentées, preuves de révocation, campagnes de recertification, rapports PAM, alertes d’usage anormal, analyse des comptes dormants.
La conformité moderne est une conformité démontrable. Dans ce contexte, l’Identity Security devient une discipline de traçabilité. Elle relie les exigences réglementaires aux opérations quotidiennes : création d’un compte, attribution d’un droit, validation managériale, connexion, élévation de privilège, revue, révocation. C’est cette chaîne de preuve qui permet de passer d’une cybersécurité déclarative à une cybersécurité auditable.
Construire une trajectoire Identity Security
Une démarche réaliste ne consiste pas à déployer simultanément tous les outils du marché. Elle doit commencer par une cartographie des identités et des risques.
La première étape consiste à inventorier les identités humaines et non humaines : salariés, prestataires, administrateurs, comptes de service, comptes applicatifs, comptes SaaS, clés API, comptes cloud, comptes d’urgence.
La deuxième étape consiste à classifier les accès selon leur criticité : accès aux données sensibles, accès aux systèmes critiques, accès d’administration, accès aux sauvegardes, accès aux outils de sécurité, accès financiers, accès RH, accès réglementés.
La troisième étape consiste à définir les règles de gouvernance : propriétaire de l’identité, propriétaire de l’application, approbateur métier, durée de validité, niveau MFA requis, conditions d’accès, règles de journalisation, fréquence de revue.
La quatrième étape consiste à traiter les privilèges : suppression des droits permanents inutiles, mise en place de l’accès juste-à-temps, coffre-fort des secrets, enregistrement des sessions critiques, séparation des comptes utilisateurs et administrateurs.
La cinquième étape consiste à industrialiser la preuve : tableaux de bord, indicateurs RSSI, campagnes de revue, reporting conformité, intégration avec le SMSI, liens avec l’analyse de risques, preuves d’audit.
Cette trajectoire permet d’éviter deux écueils : l’approche purement documentaire, qui ne transforme pas les pratiques ; et l’approche purement outillée, qui automatise parfois le désordre existant.
Conclusion : l’identité est devenue un actif critique
L’identité n’est plus seulement un moyen de connexion. Elle est devenue un actif critique du système d’information.
Elle conditionne l’accès aux données, aux applications, aux environnements cloud, aux outils d’administration, aux processus métiers, aux systèmes financiers, aux sauvegardes et aux capacités de réponse à incident. Lorsqu’elle est mal gouvernée, elle devient un vecteur d’intrusion, de fraude, d’exfiltration et de non-conformité. Lorsqu’elle est maîtrisée, elle devient au contraire un levier majeur de résilience.
Pour les RSSI et DSI, la question n’est donc plus : “Avons-nous une solution IAM ?”
La vraie question est : “Sommes-nous capables de prouver, à tout moment, qui peut accéder à quoi, pourquoi, avec quel niveau de risque, sous quel contrôle, et pendant combien de temps ?”
C’est à cette condition que l’Identity Security devient un pilier de la cybersécurité moderne, au croisement du Zero Trust, de NIS2, de DORA, d’ISO 27001 et de la gestion des risques ISO 27005.
DEVFORMA accompagne les organisations et les professionnels dans la structuration de leur gouvernance cybersécurité, la mise en conformité NIS2 et DORA, la mise en œuvre ISO/IEC 27001, l’analyse de risques ISO/IEC 27005 et la montée en compétence des équipes RSSI, DSI, GRC et audit.
Pour renforcer vos compétences, découvrez nos formations ISO/IEC 27001 Lead Implementer, ISO/IEC 27001 Lead Auditor, ISO/IEC 27005 Risk Manager, NIS 2 Directive Lead Implementer et DORA Lead Manager.
