Zero Trust : principes et mise en œuvre

Pendant des années, la sécurité des systèmes d'information a reposé sur une idée simple : protéger le périmètre du réseau d'entreprise avec un pare-feu et un VPN, puis faire confiance à tout ce qui se trouve à l'intérieur. Mais que devient ce périmètre quand les collaborateurs travaillent depuis chez eux, que les données vivent dans des applications SaaS et que les services communiquent par API entre plusieurs clouds ? Comment limiter les dégâts lorsqu'un attaquant parvient à franchir la première barrière avec un mot de passe volé ? C'est à ces questions que répond le Zero Trust : ne jamais faire confiance, toujours vérifier.

Formalisé par Forrester dès 2010, puis popularisé par l'architecture BeyondCorp de Google, le Zero Trust est aujourd'hui un cadre de référence pour les équipes tech et sécurité, notamment grâce à la publication NIST SP 800-207. Il ne s'agit pas d'un produit à acheter, mais d'une approche qui déplace la confiance du réseau vers l'identité, l'appareil et le contexte de chaque requête.

Dans cet article, nous allons explorer les principes du modèle et l'architecture proposée par le NIST, puis le rôle de l'identité, de la micro-segmentation et du moindre privilège, avant de détailler les outils concrets et une feuille de route de migration progressive.

Du modèle du périmètre au Zero Trust

Le modèle classique est souvent comparé à un château fort entouré de douves : une fois le pont-levis franchi, on circule librement. Ce modèle repose sur une confiance implicite accordée à l'emplacement réseau. Une machine connectée au réseau interne ou au VPN est considérée comme sûre, et peut généralement atteindre un grand nombre de ressources.

Ce modèle présente des faiblesses structurelles :

• Mouvement latéral : un attaquant qui compromet un seul poste peut explorer le réseau interne et rebondir de serveur en serveur
• Périmètre dissous : télétravail, cloud, SaaS et appareils personnels placent les ressources et les utilisateurs hors du réseau d'entreprise
• Identifiants volés : le phishing et la réutilisation de mots de passe permettent d'entrer par la porte principale
• Menaces internes : un compte légitime mais compromis, ou un collaborateur malveillant, bénéficie de la confiance du réseau

Le Zero Trust inverse la logique. Il part du principe que le réseau est hostile par défaut, que la compromission est possible (voire déjà survenue) et que chaque demande d'accès doit être évaluée individuellement. La question n'est plus « d'où vient cette requête ? » mais « qui la fait, depuis quel appareil, vers quelle ressource, et dans quel contexte ? ».

Les principes du NIST SP 800-207

Publié en août 2020, le document NIST SP 800-207 (« Zero Trust Architecture ») est la référence la plus citée. Il définit le Zero Trust comme un ensemble de principes de conception, et non comme une technologie particulière. Il énonce sept principes fondateurs, que nous pouvons résumer ainsi :

• Tout est une ressource : données, applications, services, appareils (y compris personnels) sont protégés au même titre
• Communications sécurisées quel que soit l'emplacement : un flux interne est protégé comme un flux venant d'Internet
• Accès accordé session par session : l'authentification d'aujourd'hui ne vaut pas pour la ressource de demain
• Politique dynamique : la décision s'appuie sur l'identité, l'état de l'appareil, le comportement et d'autres attributs contextuels
• Surveillance de l'intégrité des actifs : aucun appareil n'est intrinsèquement fiable, son état de sécurité est évalué en continu
• Authentification et autorisation dynamiques et strictes avant chaque accès
• Collecte d'informations sur l'état des actifs, du réseau et des communications pour améliorer la posture de sécurité

Une architecture en deux plans

Le NIST décrit une architecture logique qui sépare un plan de contrôle, où se prennent les décisions, d'un plan de données, où le trafic circule. Le Policy Decision Point (PDP) regroupe le Policy Engine, qui décide d'accorder ou non l'accès, et le Policy Administrator, qui établit ou coupe la session. Le Policy Enforcement Point (PEP) se place devant la ressource et applique cette décision en mettant en relation le sujet et la ressource.

Le Policy Engine ne travaille pas seul : il s'appuie sur des sources de signaux comme l'annuaire d'identités, l'inventaire et l'état de conformité des appareils, les journaux d'événements ou encore la threat intelligence. Plus ces signaux sont riches, plus la décision est fine.

À lire : découvrez notre formation DevOps Engineer

Les piliers : identité, moindre privilège et micro-segmentation

Trois piliers concentrent l'essentiel de l'effort technique d'une démarche Zero Trust.

L'identité comme nouveau périmètre

Dans un modèle sans périmètre, l'identité devient le point de contrôle principal. Elle concerne les utilisateurs, mais aussi les appareils, les services et les workloads. Une bonne gestion repose sur un fournisseur d'identité centralisé, le SSO, une authentification multifacteur résistante au phishing (clés FIDO2, passkeys) et un cycle de vie automatisé des comptes. Nous détaillons ces mécanismes dans notre article sur l'IAM.

L'identité des machines est tout aussi importante : un service qui appelle une API doit prouver qui il est, au moyen de certificats ou de jetons à durée de vie courte, plutôt que de secrets statiques partagés. La PKI joue ici un rôle central, tout comme la gestion des secrets avec un outil tel que HashiCorp Vault.

Le moindre privilège

Le moindre privilège consiste à n'accorder que les droits strictement nécessaires, pour la durée nécessaire. Dans une démarche Zero Trust, il se décline sous plusieurs formes :

• Accès Just-in-Time : les droits d'administration sont élevés à la demande, puis retirés automatiquement
• Accès Just-Enough : les rôles sont découpés finement plutôt que des droits larges « au cas où »
• Revues d'accès régulières : les permissions inutilisées sont détectées et supprimées pour éviter l'accumulation de droits
• Autorisation contextuelle : le niveau d'accès dépend aussi de l'état de l'appareil, de la localisation et du niveau de risque

La micro-segmentation

La micro-segmentation découpe le réseau en zones très petites, parfois jusqu'à la charge de travail individuelle, avec des règles explicites sur les flux autorisés. Si un serveur est compromis, l'attaquant ne peut pas atteindre les autres systèmes. Sur Kubernetes, les NetworkPolicies en sont une première illustration, et un service mesh comme Istio permet d'aller plus loin avec des politiques d'autorisation au niveau applicatif.

# Politique Istio : seul le service "frontend" peut appeler "paiement"
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: paiement-depuis-frontend
  namespace: boutique
spec:
  selector:
    matchLabels:
      app: paiement
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/boutique/sa/frontend"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/paiements/*"]

Cette politique n'autorise que les requêtes POST provenant de l'identité du compte de service frontend. Toute autre demande vers le service paiement est refusée, quel que soit son emplacement réseau. L'identité du client est authentifiée par le mTLS, que nous abordons juste après.

Des outils concrets pour la mise en œuvre

Le Zero Trust s'assemble à partir de briques existantes. Le tableau suivant relie chaque besoin aux familles d'outils les plus courantes.

mTLS : authentifier les deux côtés

Avec le TLS classique, seul le serveur prouve son identité au client. Avec le mTLS (mutual TLS), le client présente lui aussi un certificat, ce qui permet d'authentifier chaque service avant d'échanger. Les certificats sont émis par une autorité interne et renouvelés fréquemment. Un maillage de services automatise cette émission et cette rotation, sans modifier le code applicatif.

ZTNA : remplacer le VPN

Le ZTNA (Zero Trust Network Access) donne accès à une application précise, et non à un réseau entier. Contrairement à un VPN qui place l'utilisateur sur le réseau interne, le ZTNA passe par un courtier d'accès qui vérifie l'identité, l'état de l'appareil et la politique, puis ouvre une connexion limitée à l'application demandée. Les applications ne sont plus exposées publiquement, ce qui réduit fortement la surface d'attaque.

À découvrir : notre formation DevOps Engineer

Feuille de route de migration progressive

Aucune organisation ne bascule en Zero Trust du jour au lendemain. Une migration réaliste procède par étapes, en commençant par ce qui réduit le plus le risque pour le moindre effort.

1. Cartographier : inventorier les identités, appareils, applications, données et flux critiques. On ne protège pas ce qu'on ne connaît pas.
2. Renforcer l'identité : centraliser l'authentification, généraliser le SSO et activer une MFA résistante au phishing, en priorisant les comptes à privilèges.
3. Fiabiliser les appareils : inventorier le parc, imposer un niveau de conformité minimal (chiffrement, correctifs, EDR) avant d'autoriser l'accès.
4. Choisir un périmètre pilote : une application sensible ou une équipe volontaire, pour valider les politiques et mesurer l'impact sur l'expérience utilisateur.
5. Remplacer progressivement le VPN par du ZTNA, application par application, et segmenter les flux est-ouest avec le mTLS et des politiques explicites.
6. Surveiller et itérer : centraliser les logs, détecter les anomalies et ajuster les politiques en continu.

Quelques pièges reviennent régulièrement. Vouloir tout migrer d'un coup mène à l'échec, tout comme traiter le Zero Trust comme un projet purement technique alors qu'il touche aux usages et à la culture. Il faut aussi prévoir un mode d'observation (politiques en audit avant blocage) pour éviter de casser des flux légitimes. Enfin, les cadres de gouvernance comme ISO 27001 fournissent un bon cadre pour inscrire la démarche dans la durée, et l'approche se prolonge jusqu'aux nouveaux usages comme la sécurité des LLM et des agents IA, qui sont eux aussi des sujets à authentifier et à limiter.

Conclusion

Le Zero Trust marque un changement de perspective : la confiance n'est plus accordée par l'emplacement réseau, elle se mérite à chaque requête. Les principes du NIST SP 800-207 donnent un cadre clair, avec une séparation entre les points de décision et d'application, nourris par des signaux sur l'identité, l'appareil et le contexte.

Pour les équipes tech et sécurité, la mise en œuvre passe par des briques maîtrisées : une identité forte pour les humains comme pour les machines, le moindre privilège appliqué en continu, une micro-segmentation qui limite les mouvements latéraux, et des accès applicatifs de type ZTNA. Une migration progressive, pilotée par les risques, vaut mieux qu'un grand soir.

Maîtriser ces mécanismes devient une compétence différenciante pour les profils DevOps et sécurité, au moment où les architectures distribuées rendent le périmètre classique définitivement obsolète.