Fin septembre 2026, l’ANSSI a publié son rapport d’incident sur les cyberattaques qui ont touché la DGFiP. À l’origine de ces incidents : plusieurs dizaines d’identifiants d’agents dérobés par des infostealers sur des ordinateurs que la DGFiP n’administrait pas. Ils ont ensuite été réutilisés sur des portails accessibles sans aucune authentification forte. Parmi ses recommandations, l’ANSSI préconise d’interdire l’usage des équipements personnels pour accéder aux ressources professionnelles. Mais, comment faire lorsque c’est nécessaire ?
L’authentification multifacteur est conçue pour renforcer la sécurité des comptes : elle vous dit qui se connecte, mais elle ne vous dit rien de l’ordinateur depuis lequel l’utilisateur se connecte. C’est un détail, et pourtant il change tout, en particulier lorsque l’appareil en question est le PC familial d’un collaborateur, le portable d’un consultant géré par son ESN ou la machine d’un partenaire qui intervient quelques semaines dans le cadre d’un projet. Ces trois cas ont un point commun : le service informatique n’a aucune visibilité sur l’état de la machine. Ce qui amène à se poser des questions : le système est-il à jour ? Le disque est-il chiffré ? Une solution de sécurité est-elle active sur l’appareil ?
Dans le doute, certains DSI et RSSI prendront une décision : interdire ces appareils. Sur le papier, c’est la solution la plus sage pour éviter d’exposer le système d’information de son entreprise. Toutefois, il y a la réalité du terrain. Ainsi, un consultant en mission n’aura pas forcément de poste fourni par votre entreprise et certains collaborateurs consultent leur messagerie depuis leur PC personnel, avec ou sans autorisation.
Sécuriser le BYOD et l’accès des prestataires revient donc à répondre à une question simple à formuler, mais plus délicate à traiter : comment faire confiance à un appareil que l’on ne gère pas, sans pour autant l’enrôler dans un MDM ? Dans cet article, je vous propose de revenir sur ce que le modèle Zero Trust attend réellement d’un appareil, puis de passer en revue les options disponibles (blocage, MDM, protection des applications, isolation, protections natives d’Entra ID) avec leurs limites respectives. Par la suite, nous verrons comment une approche de type device trust, avec Specops Device Trust, permet de vérifier la posture de l’appareil et de conditionner l’accès en conséquence, au moment de la connexion puis pendant toute la session.
Cet article inclut une communication commerciale pour Specops Software.
Pour faire confiance à un appareil que l’IT ne gère pas, la bonne approche consiste à évaluer son état à chaque accès. Surtout, on part du principe qu’il a tout à prouver, et qu’il est considéré comme non fiable : c’est à lui de prouver le contraire. Il y a 6 points importants que l’on peut mettre en évidence :
Ne rien présumer : un appareil personnel ou tiers est considéré comme non fiable tant qu’il n’a pas démontré le contraire.
Identifier l’appareil : il est reconnu et rattaché à un utilisateur précis (avec un nombre d’appareils limité par personne).
Vérifier sa posture à la connexion : système et applications à jour, chiffrement du disque, antivirus et pare-feu actifs, etc.
Réévaluer cette posture pendant la session : un poste conforme à l’ouverture de session peut ne plus l’être deux heures plus tard.
Adapter l’accès : accorder, restreindre ou refuser selon le niveau de confiance, en proposant à l’utilisateur de corriger lui-même le problème.
Tracer chaque décision : chaque accès accordé ou refusé doit pouvoir être expliqué après coup.
La difficulté réside dans l’approche pour déterminer l’état de l’appareil : on doit vérifier l’appareil, sans pour autant le gérer. Et c’est bien deux choses différentes.
Appareils non gérés : de quoi parle-t-on ?
Un appareil non géré est un terminal qui accède aux ressources de l’entreprise sans être administré par son service informatique : pas d’inscription dans l’outil de gestion des appareils (MDM), pas de stratégies de configuration, pas d’agent de sécurité imposé. Autrement dit, c’est un appareil utilisé pour accéder à des ressources mais dont on ignore tout. Derrière cette définition se cachent des situations différentes.
BYOD, prestataires, appareils tiers : trois cas, trois contraintes
SituationÀ qui appartient l’appareil ?Qui l’administre ?Contrainte principaleCollaborateur avec son appareil personnel (BYOD)Au salariéPersonne, ou le salarié lui-mêmeVie privée et acceptabilité d’un outil de gestionPrestataire ou consultantÀ son employeur (ESN, cabinet de conseil)Le service informatique de son employeurAppareil déjà géré par un tiers, aucune autorité de votre partAppareil tiers ponctuel (partenaire, freelance, intervenant)Au tiersInconnuRelation courte, aucune visibilité
Le BYOD (Bring Your Own Device, que la CNIL traduit par AVEC pour « Apportez Votre Équipement personnel de Communication ») désigne l’usage d’équipements personnels dans un contexte professionnel. Il relève d’un choix de l’employeur, qui peut l’autoriser sous conditions ou l’interdire. Dans les faits, il est souvent toléré bien avant d’être encadré : un collaborateur consulte Outlook depuis son ordinateur personnel le soir, un autre installe Teams sur son smartphone pour ne pas rater une réunion.
Le cas du prestataire est un cas intéressant. Le consultant arrive en mission avec un ordinateur portable fourni et administré par son employeur. Vous ne pouvez pas l’inscrire dans votre MDM, puisqu’il est déjà géré par une autre organisation. Et vous n’avez, a priori, aucune garantie sur la façon dont ce poste est maintenu. Il accède pourtant à certaines de vos ressources.
Pourquoi la MFA ne suffit pas
La MFA vérifie l’identité de l’utilisateur au moment de l’authentification. Une fois la session ouverte, le service s’appuie sur un jeton ou un cookie de session. Si l’appareil héberge un infostealer, ce cookie peut être exfiltré puis rejoué depuis la machine de l’attaquant, sans mot de passe ni second facteur : la MFA ayant déjà été satisfaite, elle n’est pas redemandée. J’ai détaillé ce scénario plus en détail dans ma présentation de Specops Device Trust face au vol de session, ainsi que dans le tutoriel consacré à la sécurisation de Chrome, Edge et Firefox contre les infostealers.
Un appareil personnel est un terrain favorable à ce type d’attaque : ordinateur partagé avec la famille, logiciels installés sans contrôle, extensions de navigateur à la provenance douteuse, mises à jour reportées. Par ailleurs, un appareil compromis n’a même pas besoin de laisser fuiter un cookie pour poser problème : l’utilisateur légitime travaille, avec une session parfaitement valide, depuis une machine qui peut enregistrer ses frappes au clavier ou copier les documents qu’il ouvre.
Autrement dit, la MFA protège l’identité, mais pas le terminal. Il faut un second signal, propre à l’appareil, pour déterminer si la connexion est autorisée ou non.
Ce que le Zero Trust attend d’un appareil
Le Zero Trust est souvent résumé par la formule « ne jamais faire confiance, toujours vérifier ». Appliqué aux appareils, qu’est-ce que cela signifie ?
La publication de référence du NIST, la SP 800-207 Zero Trust Architecture, évoque justement ce cas de figure. Elle affirme qu’aucune confiance implicite ne doit être accordée sur la seule base de l’emplacement réseau ou de la propriété de l’appareil (entreprise ou personnel), et que l’authentification comme l’autorisation portent à la fois sur l’utilisateur et sur l’appareil. Le document cite d’ailleurs le BYOD parmi les évolutions à l’origine du modèle.
Trois de ses principes concernent directement notre sujet du jour :
La décision d’accès est dynamique : elle tient compte de l’état observable de l’identité, de l’application et de l’appareil qui fait la demande (versions des logiciels installés, emplacement, comportement observé, etc.).
L’entreprise mesure la posture de tous ses actifs, y compris ceux qui lui sont seulement associés : aucun appareil n’est fiable par nature. Les appareils non gérés peuvent être traités différemment, jusqu’au refus de toute connexion, et un appareil personnel peut être autorisé à accéder à certaines ressources mais pas à d’autres.
L’authentification et l’autorisation sont réévaluées en continu : la confiance n’est pas acquise pour toute la durée de la session.
De son côté, l’ANSSI mentionne dans son guide à propos du modèle Zero Trust (juin 2025) que l’objectif principal de ce modèle est de réduire la confiance implicite accordée à un sujet qui souhaite accéder au système d’information. L’agence française insiste aussi sur une adoption progressive, par cas d’usage, et sur le fait que le Zero Trust complète la défense en profondeur plutôt qu’il ne la remplace. L’accès depuis des appareils non gérés est justement un cas d’usage bien délimité pour démarrer.
Traduit en questions opérationnelles, cela donne trois tests à appliquer à chaque accès :
Cet appareil est-il connu et rattaché à cet utilisateur ?
Est-il sain au moment de la connexion ?
Le reste-t-il pendant toute la session ?
Les options classiques et leurs limites
Face aux appareils non gérés, les organisations disposent de plusieurs leviers. Aucun n’est inutile, mais aucun ne répond seul aux trois questions précédentes.
Bloquer les appareils non gérés
C’est l’option la plus radicale, et d’une certaine façon la plus simple : seuls les appareils de l’entreprise, conformes, accèdent aux ressources. Sur le plan de la sécurité, c’est cohérent. Sur le plan opérationnel, c’est plus compliqué : il faut équiper chaque prestataire et chaque intervenant ponctuel, et accepter que les collaborateurs ne puissent plus consulter leur messagerie depuis un appareil personnel. Le risque, c’est de voir apparaître des contournements (transfert de documents vers une messagerie personnelle, partage de fichiers via des services non autorisés), autrement dit du shadow IT.
C’est pourtant la position de l’ANSSI dans son rapport d’incident sur la DGFiP : interdire les équipements personnels pour accéder aux ressources professionnelles. Il s’agit d’une recommandation formulée à la suite d’un incident et adressée à la DGFiP, pas d’une obligation qui s’impose à toutes les organisations. Pour des agents qui accèdent à des données fiscales, c’est une décision légitime.
Mais le même rapport met aussi en évidence la limite de cette approche, tel qu’évoqué précédemment : le serveur du cadastre était utilisé par des notaires et des géomètres-experts, des professionnels extérieurs dont la DGFiP ne gère pas les équipements. On ne peut pas fournir un PC à chaque notaire de France. C’est précisément pour ces accès, que l’on ne peut ni interdire ni gérer, que la vérification de l’appareil prend tout son sens.
Enrôler les appareils dans un MDM
Inscrire les appareils personnels dans Microsoft Intune ou dans une autre solution de gestion des appareils permet d’imposer une configuration et de mesurer la conformité. C’est la bonne approche pour les appareils du parc de l’entreprise, mais elle trouve vite ses limites hors de ce périmètre :
L’acceptabilité : beaucoup d’utilisateurs refusent de confier l’administration de leur appareil personnel à leur employeur.
Le cadre légal : la CNIL rappelle que l’employeur ne peut pas accéder aux éléments de la vie privée stockés sur l’équipement personnel, et qu’il ne peut pas s’arroger le droit d’effacer à distance l’ensemble des données du terminal (seulement la partie dédiée à l’accès aux ressources de l’entreprise).
Les prestataires : leur poste est déjà géré par leur employeur, ce qui exclut en pratique une inscription dans votre propre MDM.
La surface d’exposition : un MDM donne un pouvoir étendu sur les appareils inscrits. L’attaque subie par Stryker en mars 2026 l’a illustré : après la compromission d’un compte administrateur Microsoft 365, les attaquants ont utilisé la fonction d’effacement d’Intune pour réinitialiser près de 80 000 appareils, y compris des équipements personnels que certains employés avaient inscrits.
Protéger les applications plutôt que l’appareil
La gestion des applications mobiles (MAM) applique des stratégies de protection aux applications et à leurs données, sans prendre la main sur l’appareil : restriction du copier-coller, des téléchargements ou de l’impression, par exemple. C’est l’approche classique pour les smartphones personnels sous iOS et Android. Microsoft l’a étendue à Windows avec le profil professionnel de Microsoft Edge : une stratégie d’accès conditionnel exige une stratégie de protection des applications, ce qui oriente l’utilisateur vers un profil Edge protégé.
C’est une brique pertinente pour protéger les données, mais elle ne règle pas la question de l’appareil lui-même. Sur Windows, elle se limite au navigateur Edge, les applications de bureau restant hors périmètre. Elle reste aussi propre à l’écosystème Microsoft (Entra ID et Intune), et ne concerne ni macOS ni Linux côté poste de travail. Enfin, un poste personnel infecté reste infecté, même lorsque les données de l’application sont protégées.
Isoler l’accès : VDI et navigateur sécurisé
Une autre approche consiste à ne jamais laisser les données atteindre l’appareil : bureau virtuel (Azure Virtual Desktop, Windows 365, Citrix, etc.) ou navigateur d’entreprise avec isolation. Le NIST décrit ce modèle de « portail » dans la SP 800-207 : il évite d’installer un logiciel sur chaque appareil et s’adapte bien au BYOD, mais l’organisation ne dispose alors que de peu d’informations sur l’appareil qui se connecte, et ne peut pas le surveiller en continu.
En pratique, l’appareil source reste une boîte noire. Un enregistreur de frappes ou un outil de capture d’écran sur le poste personnel voit tout ce que l’utilisateur affiche dans son bureau virtuel. À cela s’ajoutent le coût de l’infrastructure et une expérience utilisateur parfois dégradée.
Les protections natives d’Entra ID contre le vol de jeton
Microsoft propose ses propres parades contre le rejeu de jetons. La principale est la protection des jetons (Token Protection), un contrôle de session de l’accès conditionnel qui n’accepte que des jetons liés cryptographiquement à l’appareil. Sur Windows, elle fonctionne avec les appareils joints, hybrides ou simplement inscrits dans Entra ID, ce qui peut inclure un PC personnel (voir notre tutoriel pour inscrire des machines dans Microsoft Entra ID).
Ses limites sont toutefois importantes dans notre contexte :
Applications natives uniquement : les applications utilisées dans un navigateur ne sont pas prises en charge, alors que c’est justement le mode d’accès le plus courant depuis un appareil personnel.
Ressources limitées : Exchange Online, SharePoint Online et Microsoft Teams (ainsi qu’Azure Virtual Desktop et Windows 365 sous Windows).
Apple : sous macOS et iOS, seuls les appareils gérés par un MDM sont pris en charge.
Pas d’évaluation de la posture de sécurité : le jeton est lié à l’appareil, mais l’état de santé de cet appareil n’est pas évalué.
L’évaluation continue de l’accès permet quant à elle de révoquer rapidement une session lorsqu’un événement lié à l’identité survient (compte désactivé, mot de passe modifié, risque élevé détecté). Elle ne réagit pas à un changement d’état du poste, comme un antivirus désactivé.
Synthèse des approches
ApprocheCe qui est vérifiéSans enrôlement MDM ?Limite principale pour le BYOD et les prestatairesBlocage des appareils non gérésRien, l’appareil est refuséOuiProductivité et contournements (shadow IT)MDM (Intune, Jamf, Workspace ONE…)Conformité de l’appareil entierNonIntrusif, mal accepté, inapplicable à un poste déjà géré par un tiersMAM (protection des applications)Données dans l’applicationOuiSur Windows, limité à Edge, l’appareil lui-même n’est pas évalué en profondeurVDI ou navigateur isoléPeu ou pas l’appareil sourceOuiCoût, expérience utilisateur, appareil source inconnuToken Protection (Entra ID)Liaison du jeton à l’appareilOui sous Windows, non sous macOS et iOSApplications natives uniquement, aucune vérification de postureDevice trustIdentité de l’appareil et posture, en continuOui, mais avec un agentInstallation d’un agent à faire accepter
Le device trust : vérifier l’appareil sans le gérer
Commençons par évoquer le principe en lui-même : qu’est-ce que le device trust ? Le device trust (confiance des appareils) désigne l’ensemble des mécanismes qui intègrent l’appareil dans la décision d’accès : l’appareil doit être identifié, rattaché à un utilisateur et jugé sain au regard d’une politique de sécurité. Contrairement à un MDM, il ne configure pas l’appareil : il observe l’état de cet appareil et décide de l’accès en fonction de ce qu’il constate.
En pratique, une solution de device trust s’intercale directement au sein du parcours d’authentification. Lorsque l’utilisateur se connecte, elle vérifie que l’appareil est connu, qu’il est autorisé pour cet utilisateur et qu’il respecte les exigences de sécurité définies. La vérification se poursuit ensuite pendant la session. Si l’appareil cesse d’être conforme, l’accès est restreint, et l’utilisateur est invité à corriger le problème.
Cette approche répond aux trois questions opérationnelles du Zero Trust évoquées précédemment.
Ce que Specops Device Trust apporte pour les appareils non gérés
Specops Device Trust est une solution SaaS de Specops (Outpost24). Elle repose sur la technologie d’Infinipoint, un éditeur racheté par Outpost24 fin 2025. Je vous ai déjà présenté la console en détail dans un article dédié à Specops Device Trust, que je vous invite à lire pour en savoir plus.
Voici les caractéristiques principales de cette solution :
Intégration au fournisseur d’identité : avec Microsoft Entra ID, Specops Device Trust est déclaré comme méthode d’authentification externe (External MFA), une fonctionnalité disponible en version finale depuis le 24 mars 2026. D’autres fournisseurs d’identité sont pris en charge, comme Okta, Google, Citrix, PingOne ou Keycloak, ainsi qu’OpenID Connect de façon générale.
Classification des appareils : chaque appareil est classé selon son type (ordinateur ou mobile) et sa catégorie (appareil d’entreprise ou personnel). Les règles et les limites s’appliquent indépendamment pour chaque catégorie, ce qui permet d’être plus strict sur un appareil personnel que sur un poste de l’entreprise, ou l’inverse.
Propriété et épinglage : le premier utilisateur qui s’authentifie sur un appareil en devient le propriétaire. Vous pouvez limiter le nombre d’appareils par personne, exiger une approbation manuelle de chaque nouvel appareil et épingler un utilisateur à ses appareils. Un identifiant ou un cookie de session volé devient alors inutilisable depuis une autre machine, à cause de l’absence d’association entre l’utilisateur et l’appareil (celui de l’attaquant étant inconnu / non approuvé).
Posture vérifiée sans MDM : Windows, macOS, Linux, iOS et Android sont pris en charge, avec plusieurs centaines de contrôles disponibles : mises à jour du système et des applications tierces, chiffrement, antivirus, pare-feu, ou encore présence d’une vulnérabilité précise (CVE). Certaines règles sont réservées aux appareils d’entreprise, d’autres s’appliquent aux appareils personnels.
Vérification continue : la posture est évaluée à la connexion, puis régulièrement tout au long de la session (le plus rapide étant toutes les 10 minutes).
Remédiation par l’utilisateur : en cas d’écart, l’utilisateur peut corriger lui-même la configuration, avec une période de grâce paramétrable (correction immédiate, date limite fixe ou fenêtre glissante de quelques jours).
Traçabilité : les journaux d’accès indiquent, pour chaque tentative, l’utilisateur, l’application, l’appareil, sa classification (entreprise ou personnel), son statut de conformité et la règle appliquée.
Un point à garder en tête : la solution ne demande pas d’enrôlement dans un MDM, mais l’installation du client Specops Device Trust sur l’appareil reste nécessaire pour bénéficier de l’ensemble des fonctionnalités, notamment de la vérification de la posture de sécurité. Cet agent sert à vérifier l’ordinateur, pas à le gérer (il est important de bien comprendre la différence).
Deux scénarios concrets avec Specops Device Trust
Un consultant en mission avec le portable de son ESN
Julien est consultant pour une ESN. Il démarre une mission de quatre mois chez vous et doit accéder à Microsoft 365 ainsi qu’à une application métier fédérée avec Entra ID. Son ordinateur portable est fourni et géré par son employeur.
Voici comment se déroule son accès avec Specops Device Trust :
Création du compte : son compte est créé dans Entra ID et ajouté à un groupe dédié aux prestataires, ciblé par les stratégies de Specops Device Trust.
Première connexion : après le premier facteur, l’authentification bascule vers Specops Device Trust. L’appareil est inconnu, Julien est invité à installer le client.
Enregistrement de l’appareil : le portable est rattaché à son compte, classé comme appareil personnel (non géré par votre entreprise), et l’épinglage limite ses accès à cette seule machine.
Contrôle de posture : le profil de posture défini pour les prestataires vérifie que le système est à jour, que le disque est chiffré, que l’antivirus et le pare-feu sont actifs. Une mise à jour manque ? Julien voit le problème, l’applique et bénéficie le cas échéant de la période de grâce prévue.
Pendant la session : si l’antivirus est désactivé en cours de journée, l’écart est détecté lors de la vérification suivante et l’accès est restreint jusqu’à ce qu’une correction soit apportée.
Fin de mission : vous désactivez le compte et retirez l’appareil de la console. Aucun profil MDM n’est à retirer et aucune donnée n’est à effacer sur un appareil qui ne vous appartient pas.
Un point d’organisation à anticiper : l’installation d’un client sur le portable du consultant doit être acceptée par son employeur.
Exemple d’invite Specops Device Trust lorsqu’un appareil n’est pas conforme à la stratégie
Une collaboratrice qui consulte sa messagerie depuis son PC personnel
Claire travaille au service comptable. Le soir, il lui arrive de consulter sa messagerie depuis l’ordinateur familial, une machine que le service informatique ne gère pas. Votre politique BYOD l’autorise, mais sous conditions.
Dans Specops Device Trust, la stratégie appliquée aux appareils personnels limite chaque collaborateur à un ordinateur personnel et à un mobile personnel. Le profil de posture de sécurité associé exige un système à jour, un antivirus actif et un navigateur à jour. Lors de sa première connexion depuis ce PC, Claire installe le client, l’appareil est rattaché à son compte et classé comme appareil personnel (BYOD).
Imaginons maintenant que ce PC soit infecté par un infostealer et que son cookie de session Microsoft 365 soit exfiltré par le logiciel malveillant. L’attaquant a des informations sensibles en sa possession. Toutefois, s’il tente de le rejouer depuis sa propre machine, cela ne fonctionnera pas : l’appareil n’est pas celui de Claire, donc l’accès est refusé et la tentative d’accès infructueuse est visible dans les journaux d’accès. Si l’infection a en plus désactivé l’antivirus, le PC de Claire lui-même perdra l’accès car il n’est plus conforme à la stratégie. C’est souvent l’un des premiers signaux d’une compromission, la désactivation des protections étant une action courante avant le déploiement d’un malware.
Les points de vigilance
L’approche device trust répond à un vrai besoin, mais comme pour toutes les solutions, il y a des avantages et des inconvénients. Jusqu’ici, j’ai surtout évoqué les avantages de cette approche et la réponse que cela pouvait apporter vis-à-vis des connexions depuis des appareils non gérés. Mais, il y a tout de même des points d’attention qui parfois peuvent se transformer en point de blocage.
La vérification complète de la posture de sécurité suppose l’installation d’un client sur l’appareil. Ce n’est pas obligatoire en fonction de la manière dont est configurée la solution, mais pour répondre à la problématique évoquée dans cet article, ça l’est. Pour un salarié, c’est nettement moins intrusif qu’un MDM, mais cela reste un logiciel tiers installé sur un ordinateur personnel. Pour un prestataire, c’est un sujet contractuel. Dans les deux cas, cela s’anticipe.
La transparence vis-à-vis des utilisateurs
Dans l’édition 2024 de son guide de la sécurité des données personnelles, la CNIL recommande d’évaluer les risques liés à l’usage d’équipements personnels et de ne les autoriser qu’en fonction de ces risques, de limiter les données et les applications accessibles sur ces appareils non maîtrisés selon leur criticité, et de formaliser les responsabilités et les précautions dans la charte informatique. Une solution de device trust permet d’appliquer techniquement ces exigences.
Reste à informer les salariés des contrôles effectués, à intégrer le dispositif à la charte informatique. Il me semble également judicieux de spécifier la liste précise des informations remontées par le client, afin de pouvoir répondre clairement à la question suivante : « qu’est-ce que l’entreprise voit de mon PC ? ».
Seules les applications dont l’authentification passe par le fournisseur d’identité intégré (ou par un service connecté à la solution) bénéficient du contrôle. Une application qui authentifie ses utilisateurs en dehors de ce circuit échappe à la vérification.
Le device trust ne déploie pas d’applications, ne pousse pas de configuration et ne protège pas les données une fois téléchargées. Il effectue une analyse de l’état de la machine en allant lire sa configuration. Sur le parc d’une entreprise, il complète Intune ou un autre MDM (la solution peut d’ailleurs s’intégrer à Intune, Jamf, Workspace ONE ou CrowdStrike).
La dépendance au point de décision
Dans une architecture Zero Trust, le service qui prend la décision d’accès devient un point de passage obligé, et le NIST cite d’ailleurs son indisponibilité parmi les risques du modèle. Prévoyez des comptes d’accès d’urgence exclus des stratégies d’accès conditionnel, comme le recommande Microsoft. Démarrez aussi par une phase d’observation, en mode non bloquant, pour ajuster les règles avant de les rendre obligatoires.
Conclusion
Le rapport de l’ANSSI sur la DGFiP rappelle l’ordre des priorités : d’abord une authentification forte partout, ensuite l’interdiction des équipements personnels lorsque c’est possible. Le device trust intervient là où cette interdiction n’est pas tenable, pour les prestataires, les partenaires ou les usages BYOD que l’organisation a choisi d’autoriser. Surtout, elle prouve qu’il existe aujourd’hui des solutions techniques adéquates pour allier souplesse et sécurité.
Faire confiance à un appareil que l’on ne gère pas n’est pas une contradiction, à condition de remplacer la confiance accordée par défaut par une confiance mesurée. La vérification effectuée à chaque accès et pendant la session répond bien à ce besoin, tout en étant conforme à l’approche Zero Trust.
Comme nous l’avons vu, Specops Device Trust ajoute l’appareil à la décision d’accès, effectue une association entre l’utilisateur et l’appareil, et surtout, il vérifie en continu la posture de sécurité. Ceci est valable pour les collaborateurs en BYOD comme pour les prestataires, sans enrôlement dans un MDM. Mais attention, la principale contrainte reste l’installation du client sur l’appareil, qu’il faut faire accepter et encadrer.
Envie d’en savoir plus ? Demandez une démo Specops Device Trust.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.