La sécurité des identités est le nouveau périmètre : surmonter les limites d'Active Directory

Un quart de siècle après son apparition, Windows Active Directory (AD) définit encore les réseaux sur site. Mais il faut bien l'admettre : AD est un système d'identité vieillissant. Il a été conçu pour une époque plus simple, où la sécurité signifiait une seule chose : un réseau interne sûr et un monde extérieur dangereux.

Ce monde n'existe plus.

Aujourd'hui, les utilisateurs et les données sont partout. Le périmètre se trouve là où ils se trouvent. Et sécuriser un réseau signifie désormais gérer avec soin les identités de toutes les personnes qui y accèdent — une tâche que le vol d'identifiants et le phishing rendent chaque jour plus difficile.

Les limites d'AD compliquent sérieusement cette mission. Les points de friction sont suffisamment nombreux pour que beaucoup d'organisations choisissent simplement de migrer vers une plateforme cloud comme Entra ID.

Mais cela apporte son lot de problèmes : migrations complexes, coûts élevés, et dépendance croissante envers un fournisseur d'identité (IdP) cloud tiers.

Le passage au cloud est rarement total. Les grandes organisations tendent à adopter des plateformes IAM cloud comme Entra ID, mais beaucoup de PME restent sur AD sur site, et pour de bonnes raisons.

AD sur site facilite la prise en charge d'applications anciennes qui fonctionnent bien mais ne peuvent pas facilement migrer vers le cloud. Dans certains secteurs, conserver les données sensibles sur site est une exigence réglementaire ou sécuritaire. Et comparé aux coûts de licence des solutions IAM cloud, AD est tout simplement moins cher.

Les failles d'AD se répartissent en deux catégories : les faiblesses inhérentes à son architecture vieillissante, et les fonctionnalités absentes qui rendent sa gestion sécurisée difficile aujourd'hui.

Le problème architectural le plus important est sa dépendance aux mots de passe. Si un utilisateur présente un mot de passe valide, AD considère cet utilisateur comme légitime. Selon les standards zero trust actuels, c'est une hypothèse dangereuse — les mots de passe se font voler, et des attaquants peuvent usurper l'identité d'utilisateurs réels de manière difficile à détecter.

À partir de là, les attaquants peuvent tenter d'élever leurs privilèges et finir par compromettre AD lui-même. Si cela se produit, ils obtiennent le contrôle total du réseau.

À cela s'ajoute l'absence de plusieurs fonctionnalités critiques : une MFA, le SSO, le contrôle d'accès contextuel, la surveillance des utilisateurs, la limitation des sessions simultanées et une journalisation de conformité adéquate.

La solution n'est pas de remplacer AD — c'est de l'enrichir.

On peut le faire avec un IdP cloud, mais cela implique une migration longue et une perte de contrôle. Les IdP cloud signifient également confier sa base de données d'authentification à un tiers, ce qui crée une dépendance à la connectivité internet et à la disponibilité du service — souvent à un coût élevé par utilisateur.

UserLock adopte une approche différente. Il conserve AD en place et lui ajoute les fonctionnalités de sécurité modernes qui lui font défaut — sur site, sans migration, sans dépendance cloud permanente.

Là où des solutions comme Entra ID et Okta sont conçues pour remplacer AD, UserLock est conçu pour fonctionner à ses côtés. Les organisations conservent AD comme système d'identité principal tout en bénéficiant d'une MFA, du SSO pour les applications SaaS (dont Microsoft 365, AWS et Salesforce), et d'une surveillance des utilisateurs en temps réel.

Une MFA est indispensable aujourd'hui. Si AD était conçu maintenant, il l'intégrerait nativement. Ce n'est pas le cas — les organisations doivent trouver et mettre en place leur propre solution.

UserLock : Agit comme une couche d'authentification entre AD et l'utilisateur. Les administrateurs définissent les politiques de MFA sur le serveur UserLock. Lorsque les utilisateurs se connectent à un système Windows, ils sont invités à utiliser la méthode de MFA choisie : QR code, notification push, TOTP ou clé de sécurité.

Connecter AD aux applications cloud nécessite des outils comme ADFS et Entra Connect Sync — une infrastructure supplémentaire qui génère coûts et complexité.

UserLock : UserLock SSO agit comme un IdP sur site, permettant aux organisations de s'authentifier auprès des applications SaaS sans migrer les utilisateurs vers un IdP cloud. AD sur site suffit.

AD n'a aucun moyen de suivre les sessions utilisateurs sur plusieurs appareils ou connexions. Les sessions simultanées — se connecter à plusieurs applications ou serveurs depuis un même compte en même temps — représentent un risque sérieux. Elles favorisent le partage d'identifiants, rendent les comportements anormaux plus difficiles à détecter et offrent aux attaquants plus de latitude pour se déplacer.

UserLock : Analyse les sessions en temps réel, identifie les sessions parentes et applique des politiques de sécurité prédéfinies. Lorsqu'un utilisateur tente d'ouvrir une connexion simultanée, les administrateurs peuvent la bloquer, forcer une déconnexion ou verrouiller automatiquement les sessions existantes.

AD traite l'accès de manière binaire : autorisé ou refusé. Dans un monde où les utilisateurs se connectent depuis plusieurs endroits, c'est très limitant. Les administrateurs se retrouvent à choisir entre accepter des connexions risquées ou bloquer des connexions légitimes.

UserLock : Les administrateurs peuvent définir des politiques d'accès granulaires selon l'utilisateur, le groupe, l'OU, l'appareil, l'adresse IP, l'heure de connexion et le type de session (VPN, IIS, Wi-Fi, événements UAC).

Les comptes administrateurs sont des cibles de choix pour les attaquants — et ces privilèges ont tendance à se multiplier et à se disperser avec le temps. Ils ne sont pas toujours bien sécurisés, et les attaquants le savent.

UserLock : L'accès administrateur est strictement contrôlé. L'accès peut être conditionnel ou temporaire, et l'élévation de privilèges déclenche une authentification supplémentaire. Les comptes administrateurs cessent d'être un "mode dieu" tout-ou-rien.

La visibilité sur le comportement des utilisateurs est au cœur de la sécurité réseau, mais AD ne la fournit pas. Si quelque chose d'inhabituel se produit, les administrateurs peuvent ne pas le savoir avant qu'il soit trop tard. La journalisation native d'AD est également insuffisante pour répondre à la plupart des exigences de conformité.

UserLock : Le tableau de bord UserLock offre aux administrateurs une vue en temps réel des sessions utilisateurs, avec des indicateurs de risque intégrés. Tentatives d'accès sur des comptes désactivés ou verrouillés, changements d'identifiants en cours de session, refus d'accès répétés — tout remonte automatiquement. Sans fouiller dans les journaux.