“51,1% des vecteurs d’attaques cyber concernent la compromission d’accès dans le Cloud” (ANSSI, 2025).

Une statistique loin d’être anodine : le risque se chiffre en millions d’euros. Une réalité pour les nombreuses organisations victimes de ransomware, et dont la réputation est mise à mal.

Toutes les entreprises sont concernées, dans son étude terrain de 2024, la communauté Secatscale recense que 20% des entreprises interrogées ont été la cible d’une cyberattaque sur l’année précédente. 

• Pourquoi les accès sont-ils une cible privilégiée ?
• Quelles conséquences pour les équipes IT et sécurité ? 
• Comment limiter ce risque en pratique ?
• Quels outils utiliser ?

‍

Pourquoi les accès sont-ils pris pour cible ?

Un problème de sécurité “systémique”

Le nombre et l’usage des applications Cloud ont explosé depuis 2010. Les salariés cumulent autour de 35 comptes en moyenne. Pour certains d’entre eux, l’ordre de grandeur dépasse la centaine. C’est ce qu’on observe chez les clients de Zygon.

Cette explosion des usages (le “SaaS sprawl”) s’accompagne d’une réalité terrain : de plus en plus d’applications échappent au contrôle nécessaire des équipes IT et sécurité. C’est le Shadow IT.

Concentrons-nous sur la sécurité de ces milliers d’accès.

Les pratiques des éditeurs de logiciels ne suivent pas un standard unique quand il s’agit des identités sur leurs applications, et les options qu’il proposent sont très variées:

• association login / mot de passe,
• login via lien envoyé par email (magic link),
• multi-factor authentication (MFA),
• Single Sign-On (SSO) avec OpenID Connect,
• SSO avec SAML,
• Just-in-time Provisioning,
• SCIM Provisioning ou Deprovisioning,
• etc.  

Pour faire face à cette variété et ce volume, les équipes responsables de la sécurité proposent idéalement aux salariés:

• un gestionnaire de mots de passe pour consigner les associations login + password.
• une solution de SSO connectée aux Identity Providers de l’entreprise (comme Entra ID de Microsoft, Google Workspace, ou encore Okta par exemple).
• une règle d’activation du MFA pour les applications critiques ou les comptes privilégiés.

Mais ces bonnes pratiques de sécurisation des accès ne sont pas toujours respectées, ce qui en fait - toujours d’après l’ANSSI - une cible de choix pour des acteurs mal intentionnés. 

Cependant, il serait injuste de dire que la responsabilité n’incombe qu’aux seules politiques de gestion des accès des entreprises.

En effet, bien que généralement matures, les standards d’authentification tels que le SSO OpenID ou le SSO SAML ne sont pas systématiquement proposés par les éditeurs.

En reprenant les ordres de grandeur cités plus haut. Pour 200 à 300 applications utilisées en moyenne dans une entreprise, moins d’une centaine proposent des options d’authentification forte (SSO, MFA).

Pire encore, les standards de provisioning comme le SCIM existent, mais l’implémentation est très lacunaire chez les éditeurs. La grande majorité des applications ne le proposent pas, et ceux qui le proposent offrent une API pour le  provisioning uniquement, rarement le déprovisioning.  

En tant qu’équipe IT d’un seul client de ces applications vous n'avez en général pas le rapport de force suffisant pour demander des évolutions de ces fonctionnalités. 

Mais attention : à cela s’ajoute le fait que les éditeurs font souvent payer ces options de SSO. Cette politique tarifaire devient une raison suffisante pour limiter l’activation de ces fonctionnalités à seulement une trentaine d’applications jugées critiques dans la plupart des organisations de taille moyenne.

Un exemple: pour une entreprise de 200 personnes, pour l’application Slack uniquement,  la plus-value de souscription pour activer le SSO via SAML et le provisionnement automatique des utilisateurs s’élève à 20,000 EUR.

Ce sont ces limitations qui rendent ce problème de sécurité systémique. Il y a donc un espace d’incertitude pour plusieurs dizaines, voire centaines d’applications. 

On pourrait penser que ce risque se limite aux seules applications SaaS, mais dans les systèmes d’information modernes toutes les applications se retrouvent souvent connectées entre elles. 

‍

La latéralisation, un autre vecteur d’attaque

La surface d’attaque augmente avec l’interopérabilité des logiciels : des données transitent d’une application à l’autre. 

Les attaquants l’ont bien compris et atteignent les informations critiques par latéralisation. Une pratique qui consiste à cibler des vulnérabilités d’un environnement cloud pour en atteindre un autre, mieux protégé.

Les transferts d’information sont la plupart du temps automatiques et gérés par une identité dédiée. S’il ne s’agit pas du compte d’une personne en particulier, on parle alors de Non-Human-Identities (NHIs). Les intégrations via API font partie de cette catégorie “non-humaine”.

Cette appellation (NHIs) englobe aussi les comptes génériques partagés. Comme les adresses admin@, billing@, support@... qui sont mutualisées et permettent à plusieurs personnes de s’identifier à différentes applications.

Les permissions de ces comptes sont généralement étendues. Et avec plusieurs personnes derrière un même compte, les responsabilités et la traçabilité deviennent floues.

En plus des salariés, la liste s’allonge encore avec les accès externes.

‍

Adresses génériques, identités externes et partage d’accès : autant de vulnérabilités

L’organisation moderne ne se limite plus à des collaborateurs en CDI travaillant sur site. Aujourd’hui, elle s’appuie sur un écosystème plus large : salariés à temps partiel, freelances, consultants, prestataires externes, parfois dans le même pays, parfois à l’international. Tous ont besoin d’accéder aux systèmes d’information de l’entreprise pour contribuer efficacement.

Mais cette flexibilité s’accompagne de nouveaux défis. Les identités ne se résument plus aux seules adresses e-mail des employés. On crée des comptes pour des prestataires externes, qu’ils utilisent via des identifiants dédiés (@externe.entreprise.com) ou en tant qu’invités sur des applications spécifiques (@expertcomptable.fr).

Pensez aux dossiers Google Drive partagés, aux plateformes collaboratives (design, gestion de projet…) où des freelances et des consultants travaillent aux côtés des équipes internes. Ces accès multiples, s’ils ne sont pas gérés avec rigueur, deviennent autant de vulnérabilités potentielles pour l’entreprise.

‍

Un niveau de complexité supplémentaire avec la gestion des rôles

Au-delà du nombre croissant d’identités à gérer, la diversité des modèles de droits, de rôles et de permissions complexifie encore davantage la gouvernance des identités.

Chaque application définit ses propres niveaux d’accès, et ces modèles varient considérablement d’une plateforme à l’autre.

De plus, les ressources à protéger via ces droits forment une grande variété. Elles englobent des bases de données, des informations clients, des notes de réunion, des designs, des roadmaps, des dépôts de code, voire des machines et serveurs.

Chaque environnement introduit ses propres règles d’accès, rendant la tâche des équipes IT et sécurité encore plus ardue.

Contrairement aux applications legacy, où les rôles et permissions étaient souvent personnalisés en fonction de l’organigramme de l’entreprise, les éditeurs de solutions SaaS imposent aujourd’hui des modèles standardisés.

Ces modèles sont rarement assez granulaires pour refléter les besoins réels des organisations. Les équipes IT et sécurité doivent alors jongler avec des permissions souvent trop larges ou mal adaptées, tout en cherchant à comprendre et à cartographier la gestion des accès pour chaque application cloud utilisée.

Ce changement de paradigme marque une véritable rupture générationnelle dans la gestion des identités et des accès.

‍

Quelles conséquences pour les équipes IT et sécurité ?

Les vulnérabilités sont multiples. Les identités sont protéiformes. Alors comment les équipes IT et sécurité s'adaptent-elles pour limiter le risque de compromission ? 

Du Castle-and-Moat au Zero-Trust

Plusieurs courants de pensée coexistent, évoluent et des standards émergent. Les applications Cloud et les accès à distance ont rendu obsolète l’approche historique d’un réseau interne sécurisé (concept Castle-and-Moat ou modèle “périmétrique”).

De nouvelles postures plus modernes ont été adoptées dans la gestion des identités :

• Lister les applications à risque et les bloquer (dans un VPN, et/ou via un firewall)
• Suivre et analyser l’usage pour prévenir le risque (via un CASB)
• Renforcer la sécurité à chaque identification (via le SSO, le MFA)
• Limiter les rôles de chaque identités au plus petit périmètre possible (least privilege)

Ces bonnes pratiques ne sont pas mutuellement exclusives (ni exhaustives).

Elles relèvent d’une approche Zero-Trust. Un concept séduisant mais dont la mise en œuvre fait face aux systèmes hérités d’une part, et à une interprétation libre de ces principes d’autre part.

D’ailleurs, un des principes fondateurs du Zero-Trust est l’amélioration de la gouvernance des identités.

‍

La gouvernance des identités comme clef de voûte de la sécurité des applications

Les logiques de sécurité qui s’appliquaient aux solutions on-premise ont dû évoluer avec l’adoption des solutions Cloud.

Gains de productivité, liberté de choisir ces outils, bien-être au travail, capacité d'innovation, tout cela déjà présent avec le SaaS se voit renforcé avec l'IA. Il ne s'agit plus aujourd'hui pour l'équipe Sécurité moderne de chercher à bloquer le cloud, mais plutôt de travailler avec.

Pour autant, l’équation semble insoluble : il s’agit de limiter le risque sans diminuer la surface d’attaque ni la latéralisation.

Améliorer la gouvernance de toutes les identités est une nécessité. Pourtant, il n’existe pas de solution unique, déployable en quelques clics, qui réponde à cette exigence.

En pratique, élargir le périmètre de gestion des identités entraîne inévitablement une augmentation des tickets et une charge accrue pour les équipes IT et sécurité. Le modèle Zero-Trust, bien que pertinent en théorie, se heurte à cette réalité opérationnelle.

Alors, par où commencer ?

‍

Comment limiter le risque de compromission des identités ?

La mise en œuvre d’une gouvernance moderne des identités 

Faire l’autruche n’est plus une option. Même face à un problème systémique, il faut agir. Mais pas n’importe comment : progressivement, de manière organisée et en s’appuyant sur les bons outils.

L’enjeu n’est pas de multiplier les efforts manuellement, mais de trouver une solution qui amplifie la capacité d’action des équipes, évitant ainsi un travail de fourmi chronophage et inefficace.

La plupart des organisations ont déjà appliqué les principes du Zero-Trust sur leurs applications critiques, notamment pour répondre aux exigences des standards de sécurité comme ISO 27001, SOC2 ou DORA.

L’étape suivante d’une gouvernance moderne consiste à élargir ce périmètre, sans compromettre la fluidité des opérations ni submerger les équipes IT et sécurité sous une charge de travail ingérable.

‍

Étendre l’authentification renforcée partout où c’est possible

Toutes les applications ne supportent pas le SSO ou le MFA, mais lorsqu’elles le permettent, il est essentiel de s’assurer que tous les utilisateurs les ont bien activés. Comment procéder ?

• Recenser les applications utilisées en interne qui proposent le SSO ou le MFA, voir s’il est activé (et le cas échéant, estimer le ratio risque / investissement pour le proposer)
• Identifier en continu les identités n’ayant pas activé le MFA sur une application compatible et envoyer un rappel automatique à l’utilisateur.
• Détecter en continu les identités n’ayant pas activé le SSO (type OpenID) sur une application compatible et envoyer un rappel automatique à l’utilisateur.
• Définir des alertes basées sur l’utilisation d’une application ou la criticité de ses données pour déclencher l’activation du SSO ou du Zero Trust.
• Gérer les exceptions en recensant les applications ne proposant ni SSO ni MFA dans un inventaire dédié et en fournissant des gestionnaires de mots de passe sécurisés aux collaborateurs concernés.
• Surveiller les bases de données de fuites de mots de passe et exiger automatiquement une rotation du mot de passe pour les utilisateurs impactés.

‍

Vérifier l’offboarding et la fermeture des comptes

Il ne suffit pas de désactiver un email ou un compte d’Identity Provider pour supprimer un utilisateur de toutes les applications auxquelles il avait accès. L’utilisateur peut encore se connecter avec ses identifiants existants ou via des sessions non expirées, notamment sur un appareil non contrôlé par l’organisation.

‍

• Lister l’ensemble des comptes créés, officiellement ou non, par l’utilisateur pendant sa collaboration avec l’organisation.
• Lancer le déprovisioning automatique sur toutes les applications compatibles.
• Demander la fermeture manuelle des comptes du collaborateur à tous les responsables d’applications.
• Demander la fermeture manuelle des comptes individuels directement au collaborateur lors de la restitution de son matériel.
• Consigner les comptes ne rentrant pas dans ces catégories comme des exceptions.
• Systématiser les revues d’accès sur les applications afin d’assurer le bon fonctionnement de ces processus.

‍

Appliquer les pratiques de Least-Privilege

La sécurité des identités ne se limite pas au provisioning et au déprovisioning en début et en fin de contrat. Il s’agit d’appliquer les principes du Least-Privilege pour minimiser les accès inutiles et réduire les risques.

‍

• Faire une distinction claire entre les applications absolument nécessaires et celles qui sont approuvées mais optionnelles.
• Créer un processus simple et clair de demande d’accès aux applications pour les collaborateurs.
• Représenter au plus proche de la réalité les rôles et permissions des applications afin d’éviter les erreurs d’assignation de droits.
• Assujettir les demandes d’accès à un principe d’approbation par un supérieur, un manager ou un responsable d’application, sans ralentir inutilement le processus.
• Recertifier régulièrement les rôles et permissions des utilisateurs par le manager et/ou le responsable d’application.
• Monitorer l’utilisation des comptes applicatifs pour identifier et supprimer les accès inutiles.

‍

Discovery en temps réel, remédiation à l’échelle. 

La détection automatique du Shadow IT ne doit pas être une simple liste d’alertes, mais un processus structuré qui oriente vers des actions concrètes. Il faut la configurer comme un intake form automatisé, permettant d’identifier les risques, de réagir rapidement et d’intégrer les applications pertinentes dans le SI.

• Mettre en place des alertes sur les applications à haut risque en fonction du type de données stockées, des connexions API vers d’autres services, des vulnérabilités connues, des arnaques ou des tentatives de phishing.
• Réagir immédiatement aux alertes critiques en contactant les utilisateurs concernés et en bloquant les applications dangereuses si nécessaire.
• Éduquer les utilisateurs sur les bonnes pratiques de sécurité lorsqu’une application non risquée est détectée, plutôt que de l’interdire systématiquement.
• Organiser une revue formelle avec les équipes concernées lorsqu’une application dépasse un certain seuil d’adoption afin d’évaluer son intégration officielle au SI.
• Réaliser des revues d’accès régulières, au minimum annuelles, pour mesurer l’usage effectif des applications et supprimer les accès inutiles.

‍

Quels outils utiliser pour sécuriser (toutes) les identités ?

Un socle commun déjà adopté

Chaque organisation a son contexte : taille, secteur d’activité, cadre normatif, héritage de solutions déjà utilisées et de leurs interdépendances. 

La plupart des options de sécurisation des accès citées dans cet article sont généralement déjà mises en place par les équipes IT et sécurité : 

• Les gestionnaires de mots de passe pour consigner et sécuriser les associations login + password, et leur partage éventuel entre identités génériques (Bitwarden, 1password)
• Les solutions de SSO connectées aux Identity Providers de l’entreprise (Entra ID de Microsoft, Google Workspace, ou encore Okta par exemple)

La mise en œuvre de la gouvernance s’organise la plupart du temps dans une solution de ticketing / helpdesk comme ServiceNow, Zendesk ou JIRA.

Ces même solutions peuvent être connectées aux messagerie interne (Slack, Teams) pour faciliter les demandes aux utilisateurs. 

Concernant les mouvements des employés (onboarding / offboarding) ce sera la solution de gestion RH (SIRH) qui déclenche l’ordre d’ouvrir ou de fermer les comptes concernés.

L’ensemble de ces outils sont interconnectés, et les workflows orchestrés depuis d’autres SaaS (Zapier, n8n, Make) ou directement entre deux solutions.

‍

L’apport des plateformes dédiées à la gouvernance moderne des identités

En résumé, l’approche historique de la gestion des identités et des accès se limite à un périmètre restreint d’applications. Soit par arbitrage (les quelques logiciels jugés critiques), ou par compatibilité (vu plus haut, avec l’exemple des applications compatibles SCIM pour le SSO).

Par ailleurs, elle est centrée sur les accès des employés. Et ne prend pas en compte la réalité des comptes partagés, des connecteurs, des fameuses Non-Human-Identities (NHIs)... 

Les solutions modernes viennent compléter ces postures existantes en proposant :

1. D’élargir le périmètre des applications contrôlées pour étendre la sécurité
2. D’automatiser la remédiation, la délégation des tâches, pour limiter le nombre de tickets
3. De systématiser les revues d’accès pour simplifier la conformité

Zygon a été créé pour apporter aux équipes IT et sécurité une solution concrète à ces nouveaux enjeux de sécurité. L’évolution des usages a étendu la surface d’attaque.

Plutôt que de chercher à restreindre ce qui s’apparente à un mouvement de fond, nous proposons une approche flexible, en complément des outils existants, pour améliorer rapidement la sécurité d’un périmètre plus large d’applications.