Zero Trust : principes et pilote de contrôle des accès

Le Zero Trust est un modèle de sécurité centré sur les accès aux ressources. Il évite de considérer un utilisateur ou un équipement comme fiable uniquement parce qu’il se trouve dans le réseau interne. Son utilité se vérifie sur des accès précis : une application, un compte de service ou une intervention d’administration.

Comprendre la décision d’accès

Le NIST SP 800-207 décrit une autorisation fondée sur l’identité, la ressource et le contexte, avec des droits limités et une réévaluation selon la politique retenue. Un accès autorisé à une ressource n’autorise pas automatiquement les autres. La localisation peut être un signal ; elle ne suffit pas à elle seule à établir la confiance. Source : NIST SP 800-207, § 2.1.

Dans le modèle logique du NIST, le Policy Engine décide, le Policy Administrator organise l’établissement ou la fermeture du chemin d’accès, et le Policy Enforcement Point applique le contrôle. Ces fonctions peuvent être regroupées dans un même service. Source : NIST SP 800-207, § 3.

Exemple hypothétique : une prestataire de maintenance doit intervenir sur une application de facturation. L’objectif proposé est de lui permettre cette intervention pendant la fenêtre approuvée, sans lui ouvrir les dossiers RH ni les outils d’administration sans rapport avec sa mission. La vérification doit porter sur les droits réellement obtenus et leur retrait.

Garder la défense en profondeur

Dans son Essentiel de juin 2025, l’ANSSI présente le Zero Trust comme un complément de la défense en profondeur, et non comme un remplacement de la défense périmétrique. Elle insiste sur la qualité des attributs utilisés pour décider et sur les effets d’une panne ou d’une compromission des fonctions centrales de contrôle. Source : ANSSI, modèle Zero Trust, v1.0.

Il faut donc vérifier le comportement du service si l’annuaire, le moteur de décision ou une source d’état du terminal devient indisponible. Une règle restrictive mal maîtrisée peut interrompre une activité légitime ; une exception trop large peut laisser un accès ouvert.

Le remplacement d’un VPN ne constitue pas à lui seul une architecture Zero Trust. La question opérationnelle est celle des ressources accessibles et des contrôles appliqués. Le NIST décrit plusieurs modèles de déploiement et des canaux de communication sécurisés : opposer simplement « tunnel VPN » et « aucun tunnel ZTNA » est trompeur. Source : NIST SP 800-207, § 3.1 et 3.2.

Commencer par un pilote dont on peut mesurer le résultat

La grille suivante est une proposition de pilote. Choisissez un périmètre assez limité pour pouvoir expliquer chaque décision, mais assez représentatif pour révéler les dépendances.

Pour chaque essai, conservez les conditions, le résultat, les écarts et le responsable de correction. Ne concluez pas au succès sur la seule absence de plainte utilisateur : certains refus injustifiés ou accès excessifs peuvent rester invisibles.

L’analyse de risques permet de choisir le premier périmètre. La durée du programme dépend ensuite de ses applications, de leurs interfaces et des ressources disponibles ; un calendrier de 18 à 36 mois ne constitue pas une norme.

Identités, authentification et règles compréhensibles

La politique doit expliquer qui peut accéder à quoi, sous quelles conditions et pendant combien de temps. Elle doit aussi couvrir les identités techniques et les procédures de récupération. Le guide de l’authentification multifacteur aide à examiner les mécanismes et leurs exceptions.

Formalisez les décisions dans la politique de sécurité. Proposition pratique : pour chaque règle, indiquez son objectif, les attributs dont elle dépend, la manière de vérifier leur exactitude et la procédure de retour arrière. Une règle fondée sur une information obsolète doit pouvoir être identifiée et corrigée.

La supervision doit être dimensionnée sur les événements réellement utiles et les capacités de l’équipe. Notre comparatif SIEM propose une méthode pour comparer collecte, recherche, conservation et exploitation, puis vérifier ces choix dans un pilote réversible.

RGPD et NIS2 : évaluer les mesures, pas l’étiquette

L’Art. 32 du RGPD demande des mesures adaptées aux risques, avec une évaluation régulière de leur efficacité. Le nom commercial ou architectural ne démontre pas que les accès à un traitement donné sont appropriés. Source : RGPD, Art. 32(1) et (2).

Les données utilisées pour décider ou surveiller les accès doivent elles-mêmes respecter les principes du RGPD, notamment finalité, minimisation et durée de conservation. La recherche d’un contexte de sécurité plus précis ne justifie pas une collecte illimitée sur les personnes. Source : RGPD, Art. 5(1)(b), (c) et (e).

NIS2 vise notamment les politiques de contrôle d’accès et, selon les besoins, les mécanismes d’authentification prévus à l’Art. 21(2)(i) et (j). Le règlement 2024/2690 mentionne les architectures Zero Trust parmi les exemples de principes de conception sécurisée, dans son annexe § 6.2.2(b), pour les entités relevant de son champ. Cela ne transforme pas l’achat d’un produit baptisé Zero Trust en obligation générale. Sources : NIS2, Art. 21, règlement 2024/2690.

Écrire une règle avant de choisir son outil

Commencez par une phrase que le responsable métier et l’administrateur comprennent de la même façon. Par exemple : « Cette équipe peut consulter les dossiers de son activité depuis les équipements admis, pendant la durée de sa mission. » Il reste ensuite à définir ce que signifient équipe, dossier, équipement admis et fin de mission dans le système concerné.

Pour préparer cette traduction, proposez une fiche comportant la ressource, l’opération autorisée, la personne responsable de l’habilitation et les informations nécessaires à la décision. Précisez également qui corrige une donnée erronée. Un salarié affecté au mauvais service dans l’annuaire peut subir un refus injustifié ou recevoir des droits excessifs ; modifier la règle générale n’est pas nécessairement la bonne réponse.

Cette fiche doit distinguer trois moments : approbation du besoin, mise en place de la règle et observation de son effet. L’accord du responsable métier ne prouve pas que l’application applique correctement la restriction. Inversement, un refus technique ne dit pas si le besoin professionnel a été correctement qualifié.

Définir ce qui rend une information utilisable

Pour chaque information retenue, posez une question de contrôle : qui la produit, à quelle date, pour quel périmètre et comment une erreur sera-t-elle signalée ? Une indication de conformité du poste doit pouvoir être rapprochée du poste réellement utilisé. Le statut d’une personne ne doit pas être confondu avec celui d’un compte partagé ou d’un traitement automatique.

Le dossier du pilote peut prévoir une colonne « information absente ou contradictoire ». Décrivez alors la décision attendue et la personne capable d’examiner la situation. Le silence d’une source ne permet pas de conclure spontanément que tout est conforme. Il ne fournit pas davantage, à lui seul, une procédure de continuité acceptable pour le métier.

Limitez cette collecte aux informations nécessaires à l’objectif poursuivi. La justification doit porter sur leur utilité pour le contrôle d’accès, leurs destinataires et leur conservation. Des données recueillies pour sécuriser un accès ne deviennent pas automatiquement disponibles pour évaluer la productivité des personnes. Ce nouvel usage demanderait sa propre analyse.

Préparer un scénario qui révèle les exceptions

Dans un exemple entièrement fictif, Aubépine souhaite limiter l’accès d’une équipe de support à une application de commandes. Le pilote envisagé comporte un accès habituel, une mission temporaire de remplacement et une perte de l’information sur l’état du poste. À ce stade, aucun essai n’a été exécuté et aucune décision technique n’est présentée comme acquise.

Pour le remplacement, l’équipe doit préciser les opérations nécessaires, l’approbation attendue et la fin de la mission. Elle doit aussi prévoir comment constater le retrait des droits, y compris si la personne reste salariée dans un autre rôle. Ce scénario peut mettre en évidence une différence entre la fin de l’autorisation dans le dossier métier et sa prise en compte effective par les composants techniques.

Pour l’information manquante sur le poste, la discussion doit couvrir l’activité que l’on peut poursuivre, les moyens disponibles pour résoudre l’incertitude et la personne habilitée à décider. Une exception de secours proposée doit avoir un périmètre, un motif et une fin. Elle ne doit pas devenir le nouveau chemin habituel dont personne ne vérifie les droits.

Décider de l’extension à partir des résultats disponibles

Le compte rendu du pilote peut présenter, pour chaque situation préparée, le comportement attendu, le comportement effectivement observé et les limites de l’observation. Distinguez les refus justifiés, les refus qui bloquent une activité autorisée et les accès plus larges que prévu. Une moyenne globale peut masquer une exception importante sur une ressource sensible.

Avant d’étendre le dispositif, attribuez les corrections et précisez celles qui conditionnent la suite. Préparez également la procédure de retour à une configuration maîtrisée si une modification perturbe le service. Étendre un pilote signifie élargir son périmètre et ses dépendances : les conclusions obtenues sur une application ne dispensent pas d’examiner les autres.

Ce qu’il faut retenir

• Le Zero Trust organise des décisions d’accès explicites et contextualisées.
• Le périmètre réseau ne suffit pas à établir la confiance.
• Le pilote doit vérifier les accès autorisés, les refus et les situations de panne.
• La conformité dépend des mesures réelles et de leurs preuves.

FAQ

Faut-il supprimer tous les VPN ?

Le choix dépend des usages, de l’architecture et des contrôles appliqués. Le remplacement d’une technologie ne démontre pas, à lui seul, que les accès sont limités aux ressources nécessaires.

Une PME peut-elle commencer sur une application ?

Oui, un périmètre limité peut servir à vérifier les règles et les dépendances. L’objectif doit rester concret et mesurable avant toute extension.

Zero Trust signifie-t-il demander un code MFA à chaque action ?

Non. Les règles d’authentification et de réévaluation dépendent du contexte et de la politique retenue. La répétition des sollicitations n’est pas, à elle seule, une mesure de l’efficacité du contrôle.

Recevez nos analyses conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne, docteur en droit, travaille depuis plus de 20 ans sur la protection des données et le droit des technologies.