L’identité ne suffit pas Pourquoi la sécurité des dispositifs doit prendre part à la charge

L'identité ne suffit pas Pourquoi la sécurité des dispositifs doit prendre part à la charge

L’authentification a longtemps constitué le pilier fondamental de la cybersécurité. Le principe était simple : vérifier l’identité de l’employé et sécuriser l’accès. Mais les cyberattaques professionnelles emploient maintenant des kits de phishing sophistiqués et exploitent l’intelligence artificielle. Ce pilier commence à se fissurer. L’authentification est forcée de supporter une charge structurelle qu’elle n’a pas été conçue pour assumer.

L’authentification n’est pas obsolète, mais dans les environnements marqués par la prolifération des services en ligne, les appareils personnels et le travail hybride, un identifiant valide ne garantit plus une connexion sûre. Le véritable danger ne réside pas dans un échec d’authentification, mais dans la vérification des signaux appropriés. Sans contrôles en temps réel de l’appareil, une session de connexion légitime pourrait aussi bien être compromise.

Le point faible après l’authentification

L’authentification multifactorielle devait résoudre ce problème. Cependant, les kits de phishing permettent maintenant aux attaquants d’intercepter la communication entre un utilisateur et le portail de connexion légitime. Ils peuvent ainsi récupérer en temps réel le jeton de session qui est généré après une authentification multifactorielle réussie. La victime effectue toutes les vérifications de sécurité exactement comme prévu. L’attaquant obtient alors le cookie qui prouve cette authentification.

La publication spéciale NIST 800-207, cadre fondamental pour l’architecture Zero Trust, avait anticipé cette faille. Ce document recommande de ne pas se fier à une fiabilité implicite après que un sujet a atteint un niveau d’authentification basique. Il spécifie que les décisions d’accès doivent prendre en compte la conformité de l’appareil utilisé pour la requête.

Dans la pratique, beaucoup d’organisations considèrent encore l’authentification comme une vérification ponctuelle. L’identité est confirmée, l’authentification multifactorielle est validée, une session commence, et la confiance persiste jusqu’à l’expiration du jeton. Mais un jeton de session dans le navigateur d’un attaquant est identique au même jeton dans le navigateur de l’utilisateur. Les logs d’authentification traditionnels ne peuvent les différencier.

Les limites du Zero Trust

La plupart des implémentations Zero Trust sont centrées sur l’identité. Elles visent à renforcer l’authentification, imposer l’authentification multifactorielle, réduire la dépendance aux mots de passe et introduire des politiques de connexion basées sur le risque. La vérification de l’appareil, quant à elle, est souvent appliquée de manière disparate. Elle s’arrête généralement au moment de la connexion, ou elle concerne seulement les workflows basés sur navigateur dans des cadres conditionnels modernes. Les protocoles anciens, les outils d’accès distant et les intégrations API bénéficient souvent d’une confiance implicite après que l’identité a été établie.

Ce modèle est fragmenté. Les appareils personnels et ceux de tiers peuvent être faiblement contrôlés ou totalement non gérés. La confiance attachée à une session persiste même si la conformité de l’appareil se dégrade pendant la session. Les signaux d’identité et les signaux de l’endpoint sont analysés dans des outils séparés avec une intégration limitée. L’identité est examinée avec rigueur au moment de la connexion, puis l’accès est rarement réévalué.

L’appareil constitue la seconde partie de la réponse

Un mot de passe compromis utilisé depuis un ordinateur contrôlé par un attaquant ne devrait pas être traité comme le même mot de passe utilisé depuis un endpoint professionnel inscrit, chiffré et conforme. C’est précisément ce qui se produit quand l’accès dépend seulement de l’identité.

La conformité de l’appareil répond à des questions que l’identité ne peut traiter. L’appareil est-il chiffré ? La protection de l’endpoint est-elle active et fonctionnelle ? Le système d’exploitation est-il mis à jour ? La configuration respecte-elle la politique ? Ce matériel est-il approuvé ?

Ces informations doivent surtout rester actuelles après la connexion initiale et pendant toute la session. Une mise à jour peut être retardée, la protection de l’endpoint peut être désactivée, un logiciel non autorisé peut être installé. Les conditions au moment de la connexion ne sont pas celles trois heures après. Une vérification continue de l’appareil réduit la valeur des identifiants compromis et des jetons interceptés, car l’accès devient lié non seulement à une identité, mais aussi à un endpoint fiable et conforme.

Quatre principes pour un modèle plus robuste

Une approche plus défendable combine l’authentification avec une vérification continue de l’appareil. Concrètement, cela implique :

  1. Vérifier continuellement l’utilisateur et l’appareil : L’accès devrait rester conditionnel à la conformité de l’appareil, pas seulement à la vérification d’identité. Si la protection de l’endpoint est désactivée ou si le chiffrement est interrompu pendant la session, le niveau de confiance devrait être ajusté en temps réel. Cela limite en une seule action l’efficacité des identifiants compromis, la réutilisation de jetons, la fatigue liée à l’authentification multifactorielle et les endpoints contrôlés par des attaquants.
  2. Associer l’accès à du matériel approuvé : Les contrôles basés sur l’appareil permettent aux organisations d’inscrire du matériel de confiance et de différencier les endpoints professionnels, personnels et de tiers. Des identifiants valides utilisés depuis un appareil non reconnu ne devraient pas simplement donner accès parce que l’authentification multifactorielle a réussie.
  3. Appliquer une mise en œuvre proportionnée : Des contrôles rigides génèrent des contournements. Une stratégie mature de conformité peut imposer des restrictions conditionnelles, réduire les privilèges ou établir des périodes de grâce limitées, au lieu de bloquer systématiquement. Cet équilibre est important pour les équipes hybrides et distantes.
  4. Permettre une correction en autonomie : Si la confiance est liée à la conformité de l’appareil, les utilisateurs doivent pouvoir restaurer cette confiance. Des corrections guidées pour le chiffrement, les mises à jour du système ou la protection de l’endpoint permettent aux employés de résoudre les problèmes de conformité sans créer un ticket informatique ou perdre un accès nécessaire.

Les solutions comme Specops Device Trust rendent ce modèle opérationnel, car elles étendent les décisions de confiance au-delà de l’identité et maintiennent les contrôles quand les conditions changent. Elles authentifient les utilisateurs et vérifient leurs appareils en continu sur Windows, macOS, Linux et les plateformes mobiles, pas seulement au moment de la connexion.

Specops Device Trust

L’authentification reste importante. Elle ne peut simplement plus assumer seule toute la responsabilité d’une décision d’accès.