Mise en Œuvre du Zero Trust : Commencer par des Étapes Pragmatiques

Le Zero Trust a un problème de marketing. Le terme arrive accompagné de pitchs de plateformes et de programmes de transformation pluriannuels, ce qui donne l’impression que l’adopter signifie remplacer tout votre parc identité, réseau et endpoints en un seul effort héroïque. Presque toutes les organisations qui s’y essaient ainsi s’enlisent : le programme devient trop gros pour être financé, trop perturbant pour être mené, et meurt discrètement dans un comité de pilotage.

Les organisations qui y arrivent vraiment font quelque chose de moins spectaculaire. Elles traitent l’architecture zero trust (ZTA) comme une direction de déplacement, pas comme un achat de produit, et elles avancent vers elle par petites étapes constantes qui apportent chacune une valeur autonome. La première de ces étapes, dans presque tous les environnements, est la même : retirer les protocoles d’accès hérités qui sapent silencieusement chacun de vos contrôles modernes.

Ce que le zero trust demande réellement #

Retirez la marque et l’idée centrale est simple : cessez d’accorder l’accès selon l’origine d’une requête et commencez à l’accorder selon ce qu’est la requête et qui la formule, vérifié à chaque fois.

La sécurité traditionnelle faisait confiance à l’intérieur du réseau. Être à l’intérieur du périmètre signifiait être de confiance, si bien qu’un portable sur le LAN d’entreprise, puis sur le VPN, pouvait atteindre beaucoup de choses avec un minimum de revérification. Le zero trust inverse cette hypothèse :

• Vérifier explicitement. Chaque requête est authentifiée et autorisée à partir de l’identité, de l’état du terminal et du contexte, quel que soit l’emplacement réseau.
• Moindre privilège. Utilisateurs et workloads reçoivent l’accès minimal nécessaire, borné dans le temps quand c’est possible.
• Partir du principe que la compromission a eu lieu (assume breach). Concevoir comme si un attaquant était déjà à l’intérieur, en limitant ce qu’une seule compromission déverrouille.

Ce dernier principe relie directement au fait que les protocoles hérités sont la cible initiale naturelle.

Étape 1 : Expulser les protocoles obsolètes #

Les protocoles d’accès hérités sont l’anti-zero-trust. Ils sont antérieurs à la pensée moderne de l’identité et portent des hypothèses qu’aucun nouvel outil ne peut corriger :

• SMBv1 et les dialectes de partage de fichiers non corrigés, âgés de décennies et toujours activés par négligence, que les attaquants exploitent aussi bien pour entrer que pour se propager latéralement.
• NTLMv1 et autres schémas d’authentification faibles, incapables de supporter une vérification moderne et couramment relayés ou cassés.
• Telnet et FTP non chiffré, transmettant les identifiants en clair sur des réseaux que vous prétendez segmentés.
• Authentification HTTP basic et liaisons LDAP non signées, exposant des mots de passe réutilisables à quiconque est positionné pour observer le trafic.
• Protocoles de relève de messagerie anciens (POP3/IMAP non chiffrés) contournant la MFA que vous imposez partout ailleurs.

Chacun de ces éléments est une invitation permanente qui dit : apportez des identifiants des années 1990 et nous les traiterons comme valides. Tant qu’ils restent activés, ils forment des raccourcis autour des contrôles d’identité, des vérifications d’état des terminaux et des politiques d’accès conditionnel. On ne peut pas construire une architecture zero trust sur des protocoles dont toute la conception suppose la confiance par localisation.

La suppression est aussi le rare projet de sécurité au bénéfice quasi immédiat et au coût faible. La plupart des environnements découvrent, par la journalisation plutôt que par devinette, qu’un petit nombre de systèmes ou de flux dépend encore de chaque protocole hérité : un vieux parc d’imprimantes, l’intégration d’un fournisseur, une application oubliée. Chaque dépendance reçoit un court plan de remédiation ; le reste est coupé. Un trimestre de travail concentré élimine généralement l’essentiel de l’exposition.

Puis étendre les mises à niveau, avec constance #

Une fois le socle hérité dégagé, le reste du voyage est une séquence de mises à niveau imbriquées. Aucune n’exige de big bang, et chacune facilite la suivante :

1. Couverture MFA d’abord, surtout les comptes privilégiés. C’est le contrôle de la séquence au meilleur rapport valeur/prix, et il pose la fondation d’identité sur laquelle tout le reste se construit. Méthodes résistantes au phishing pour les administrateurs quand c’est possible.
2. Remplacer la confiance réseau implicite par des autorisations explicites. Faire évoluer l’accès distant depuis des VPN plats vers un accès par application médiatisé par l’identité. Chaque application migrée réduit le rayon d’impact d’un portable volé.
3. Ajouter l’état du terminal aux décisions. Une fois l’accès passé par l’identité, exiger des terminaux gérés et corrigés pour les applications sensibles. Les terminaux en mauvaise santé obtiennent des chemins de quarantaine, pas des données de production.
4. Micro-segmenter progressivement les workloads. Commencer par les services les plus critiques : systèmes de paiement, infrastructure de domaine, magasins de données sensibles. Mettre leurs appelants en liste blanche explicite. C’est le zero trust appliqué au trafic est-ouest, et cela se compose avec la discipline de segmentation déjà abordée ailleurs sur ce blog.
5. Instrumenter et itérer. Journaliser chaque décision d’accès, examiner les refus pour détecter les faux positifs, et étendre le périmètre à un rythme que vos équipes peuvent absorber.

Pourquoi la constance bat la vitesse #

Le mode d’échec des programmes zero trust n’est pas le choix de la mauvaise technologie ; c’est démarrer avec enthousiasme et s’arrêter à mi-parcours. Une architecture semi-déployée est souvent pire que pas d’architecture : deux modèles d’accès fonctionnant en parallèle signifient deux jeux de règles à maintenir, et les utilisateurs contournent celui qui les agace le plus.

Un déploiement constant gagne parce que :

• Chaque phase se termine utilisable. Les utilisateurs vivent un changement à la fois, canaux de support prêts, au lieu d’un mur de migration.
• Les gains de sécurité arrivent tôt et se composent. Retirer les protocoles hérités paie immédiatement ; la MFA paie immédiatement. Vous ne portez jamais un risque non construit en attendant une ligne d’arrivée lointaine.
• Le budget survit au contact de la réalité. De petites phases financées passent plusieurs fois la revue finance ; un programme gigantesque passe généralement une fois puis se fait couper.
• Votre connaissance de l’architecture grandit avec elle. Au moment d’atteindre la micro-segmentation, votre équipe a vécu les mises à niveau d’identité et l’accès conditionnel, et connaît les vrais schémas de trafic de son propre environnement.

Un calendrier réaliste pour la plupart des organisations de taille moyenne ressemble à ceci : suppression des protocoles hérités en un ou deux trimestres, MFA universelle en parallèle, accès par application sur les deux à trois trimestres suivants, et segmentation progressive des workloads poursuivie comme pratique permanente. Dans deux ans, sans avoir jamais mené de « transformation », vous levez les yeux et découvrez que vous en exploitez une.

Notre Évaluation de la Configuration et de l’Architecture identifie les protocoles hérités et les chemins de confiance implicite cachés aujourd’hui dans votre environnement, et notre Conseil vCISO séquence le déploiement en phases finançables que votre équipe peut soutenir. Ou planifiez une session d’ingénierie et de scoping pour commencer par la première étape.