Le Zero Trust n'est pas un produit, et aucun fournisseur ne peut vous le vendre. Le NIST SP 800-207 le définit comme un ensemble de principes de conception, pas comme une architecture unique. C'est pourquoi deux organisations qui l'appliquent sérieusement obtiennent des résultats différents.
Le principe, en une phrase
Aucune confiance n'est accordée en fonction de l'emplacement réseau. Chaque demande d'accès est évaluée au moment où elle est faite, en fonction de l'identité, de l'état du terminal et du contexte, et cette évaluation est réévaluée.
Le corollaire dérange plus qu'il n'y paraît : le réseau interne cesse d'être une zone de confiance. Un serveur atteint depuis le siège n'est pas plus digne de confiance qu'un serveur atteint depuis un hôtel.
Les six piliers, et leur ordre réel
Identité. Le socle. Sans annuaire fiable, authentification renforcée et gestion du cycle de vie des comptes, tout le reste repose sur du sable.
Terminaux. L'état du poste devient un critère d'accès : chiffrement, correctifs, présence d'un agent de détection.
Réseau. Segmentation, puis micro-segmentation. Le passage du périmètre unique à des zones réduites limite la propagation.
Applications. Accès applicatif plutôt qu'accès réseau. Un utilisateur atteint une application, pas un sous-réseau contenant cette application.
Données. Classification, chiffrement, contrôle des flux sortants. C'est le pilier le plus souvent repoussé, parce qu'il exige une décision métier sur ce qui compte.
Visibilité et automatisation. Journalisation, analyse, réponse. Sans elle, on ne sait pas si les règles fonctionnent.
L'ordre ci-dessus n'est pas une préférence théorique : chaque pilier consomme le précédent. Une micro-segmentation sans identité fiable segmente des adresses, pas des utilisateurs, et redevient un pare-feu compliqué.
Un déploiement qui aboutit
Commencer par une application, pas par le système d'information. L'erreur structurante consiste à lancer un programme transverse de trois ans : au bout de dix-huit mois, aucun utilisateur n'a vu de différence et le budget est remis en cause.
Le chemin qui aboutit part d'un cas d'usage étroit et visible. L'accès des prestataires est le meilleur candidat : population délimitée, risque reconnu, gain immédiat, et personne ne défend le statu quo du tunnel réseau ouvert à un prestataire de maintenance.
Ensuite l'accès distant des salariés, en remplaçant l'accès réseau complet par un accès applicatif. Puis les administrations, qui bénéficient le plus du contrôle contextuel. Puis les flux entre serveurs, qui sont les plus longs à traiter parce qu'ils sont mal documentés.
Une étape préalable est incontournable et souvent sautée : cartographier les flux existants. On ne segmente pas ce qu'on ne connaît pas, et la découverte réserve des surprises, en général une application métier qui parle à une base qu'aucun schéma ne mentionne.
Les erreurs qui reviennent
Acheter avant de concevoir. Un outil d'accès réseau sans confiance ne fait pas une architecture. Il déplace le point de contrôle, ce qui est utile, mais laisse entières les questions d'identité et de segmentation.
Oublier les flux entre serveurs. Beaucoup de projets traitent l'utilisateur et laissent les serveurs communiquer librement. Or le mouvement latéral, qui est la raison d'être de la démarche, se produit précisément là.
Traiter les comptes de service comme des exceptions permanentes. Ils sont nombreux, mal documentés, et personne ne veut être celui qui casse la production. Les laisser hors du périmètre revient à laisser un chemin ouvert à côté de la porte qu'on vient de blinder.
Confondre authentification renforcée et Zero Trust. Un second facteur à la connexion ne réévalue rien ensuite. Une session ouverte le matin reste ouverte, quel que soit ce qui change dans la journée.
Négliger l'expérience utilisateur. Une authentification demandée trop souvent produit du contournement, et le contournement annule le bénéfice. La fréquence de réévaluation doit dépendre de la sensibilité de la ressource.
Mesurer l'avancement
Quatre mesures, plus utiles qu'un pourcentage global de maturité.
La part des applications accessibles sans traversée réseau. Le nombre de flux serveur à serveur autorisés par défaut, qui doit baisser. La part des accès à privilèges soumis à une élévation temporaire. Et le nombre de chemins ouverts depuis un poste ordinaire vers un système critique, mesuré par analyse de graphe et non par revue de configuration.
Ce dernier chiffre est le plus proche de ce que la démarche cherche à obtenir.
Ce que les textes en disent
NIS2 ne prescrit pas d'architecture, mais ses exigences de contrôle d'accès, de segmentation et d'authentification multifacteur pointent dans cette direction. ISO 27001:2022 les couvre par plusieurs contrôles de l'annexe A, dont la ségrégation des réseaux et la gestion des accès à privilèges.
Autrement dit, une démarche Zero Trust bien menée produit des preuves de conformité sans travail supplémentaire, à condition de rattacher dès le départ chaque mesure à l'exigence qu'elle sert.
Ce que Zaxyr apporte
Zaxyr rattache les mesures Zero Trust aux exigences NIS2 et ISO 27001 qu'elles couvrent, et suit leur état réel plutôt que leur état cible. Les indicateurs d'avancement sont calculés à partir des données collectées, ce qui permet de montrer la progression à un comité de direction sans reconstituer un tableau à chaque échéance.