Éditorial

Enquête sur l'écart entre la promesse du Zero Trust et les déploiements qui ajoutent une authentification sans supprimer la confiance implicite du réseau interne.

~11 min de lecture7 sections

Zero Trust marketing ou sécurité réellement vérifiée

Le Zero Trust est vendu comme la fin du périmètre réseau : chaque accès serait vérifié, contextualisé et révoqué dès que son contexte change. Dans la plupart des déploiements, il signifie surtout une authentification multifacteur à l’entrée, puis les mêmes zones plates, les mêmes comptes de service surpuissants et les mêmes flux internes que précédemment. Le concept reste exploitable, mais seulement après avoir retiré des slides tout ce qu’elles ont ajouté.

→ Lire l’explication complète de la marmotte

La promesse Zero Trust et le périmètre qui survit

Zero Trust ne désigne pas un produit. C’est un modèle de décision : ne pas déduire l’autorisation d’accès d’une position réseau, d’un réseau privé virtuel ou d’une authentification ancienne. Chaque demande doit être évaluée contre une identité, un appareil, une ressource, une action, un contexte et une politique. Le National Institute of Standards and Technology (NIST) formule cela dans sa publication SP 800-207 autour de la vérification explicite, du moindre privilège et de l’hypothèse de compromission.

La traduction commerciale a supprimé les parties qui coûtent. Un accès réseau privé virtuel renforcé par une authentification multifacteur devient « Zero Trust Network Access », puis « Zero Trust » tout court. Un proxy qui vérifie une session à l’ouverture devient un contrôle continu. Un annuaire centralisé devient une stratégie d’identité. Rien de cela n’est inutile. Rien de cela ne suffit.

Le test est brutal : après l’authentification initiale, un poste compromis peut-il scanner les services internes, joindre une base de données, appeler des interfaces d’administration, utiliser des identifiants en cache ou rebondir vers un autre segment ? Si la réponse est oui, la confiance implicite est toujours là. Elle a seulement reçu une couche de peinture identitaire.

La sécurité périmétrique ne disparaît pas parce qu’un pare-feu est remplacé par un courtier d’accès. Elle disparaît lorsque le réseau n’est plus une preuve d’autorisation. Or, les adresses sources, les plages privées, les groupes de réseau privé virtuel et les sous-réseaux de serveurs continuent souvent de porter cette preuve. Les règles disent encore : « autoriser depuis le réseau interne ». C’est l’antithèse du modèle annoncé.

La page filtrage, segmentation, NAC et Zero Trust couvre les mécanismes de segmentation et de contrôle d’accès au réseau. Le présent dossier tranche sur le récit vendu autour de ces mécanismes : sans segmentation appliquée aux flux Est-Ouest, sans identité de charge de travail et sans politique par ressource, l’étiquette Zero Trust relève du rebranding. La version plaquette tient dans un portail d’accès distant renommé ; la version qui résiste à une compromission commence par cartographier les identités et les flux, exercice notoirement moins photogénique.

Le coût réel de la vérification continue

Vérifier continuellement ne veut pas dire redemander un mot de passe à chaque requête. Cela veut dire réévaluer une décision lorsque les attributs qui la fondent changent : état de conformité du poste, niveau d’authentification, localisation admise, sensibilité de la ressource, comportement de session, révocation d’un compte ou d’un certificat.

Cette réévaluation exige une chaîne entière. Il faut une source d’identité disponible, des signaux fiables sur le terminal, un moteur de politiques, un point d’application proche de la ressource, une journalisation corrélable et des règles de repli. Il faut aussi décider de ce qui arrive quand l’un de ces composants ne répond plus. Refuser tout accès préserve la politique mais immobilise des services. Autoriser avec la dernière décision connue maintient le service mais accepte une fenêtre de risque. Cette fenêtre doit être explicitement bornée, mesurée et assumée.

Le compromis central est là : gagner une réduction du mouvement latéral et de la persistance, payer en complexité opérationnelle, en latence, en dépendances critiques et en coût de gouvernance. Prétendre obtenir le gain sans payer le prix est la partie marketing. Le coût ne disparaît pas, il se déplace dans les connecteurs, les exceptions, les comptes techniques et les tickets d’incident.

Une décision d’accès à faible durée de vie limite les effets d’une révocation tardive, mais augmente la disponibilité requise du fournisseur d’identité. Une session de huit heures réduit les appels de contrôle, mais rend une compromission exploitable pendant huit heures si aucun mécanisme de réévaluation ne casse la session. Un jeton signé reste valide jusqu’à son expiration sauf introspection, liste de révocation ou contrôle côté ressource. La révocation d’un compte ne retire pas magiquement les jetons déjà émis. Les jetons ne lisent pas les communiqués de crise.

Les identités de charge de travail aggravent le problème. Les applications parlent en permanence, souvent avec des secrets statiques ou des certificats longs. Si une application est autorisée par son sous-réseau et un mot de passe de base de données partagé, aucun portail d’authentification multifacteur ne corrige la situation. Il faut des identités distinctes, des droits limités par destination et des secrets renouvelables. La gestion des identités est donc une dépendance d’architecture, pas une phase de finition.

Les contrôles qui cassent réellement la confiance implicite

Un programme défendable commence par les ressources à fort impact : administration, données personnelles, secrets de déploiement, interfaces de production, sauvegardes et systèmes d’identité. Chercher à microsegmenter chaque imprimante avant ces actifs produit surtout des diagrammes héroïques et des exceptions permanentes.

Chaque ressource critique doit disposer d’un point d’application capable de décider à partir de l’identité appelante. Pour un service Hypertext Transfer Protocol Secure (HTTPS), ce point peut être un proxy applicatif, une passerelle d’interface de programmation applicative ou le service lui-même. Pour un flux de base de données, une politique réseau seule ne prouve pas l’identité de l’utilisateur final : elle contrôle au mieux l’identité du client applicatif. Cette différence interdit de promettre une traçabilité utilisateur là où l’architecture ne transporte qu’un compte de service.

La microsegmentation consiste à limiter les communications entre charges de travail selon les flux explicitement nécessaires. Elle réduit le rayon d’explosion d’un hôte compromis, à condition que les règles reposent sur une identité stable ou sur une attestation fiable. Une règle fondée sur une adresse Internet Protocol est fragile : l’adresse désigne une localisation technique, pas une autorité. Dans un environnement orchestré, elle peut changer avant même que le tableau de bord ait fini de charger.

Le Network Access Control (NAC), ou contrôle d’accès au réseau, est utile pour admettre un terminal dans un réseau selon son identité et son état. Il ne protège pas automatiquement les accès applicatifs postérieurs. De même, le Zero Trust Network Access (ZTNA), ou accès réseau Zero Trust, peut masquer une application d’administration sans cloisonner les communications entre serveurs. Les deux mécanismes se complètent, mais ni l’un ni l’autre ne remplace une autorisation fine sur la ressource.

La recommandation est nette : employer le terme Zero Trust uniquement quand une décision d’accès est appliquée par ressource, liée à une identité vérifiable, limitée dans le temps et révisable sur événement de sécurité. Dans les autres cas, parler d’authentification renforcée, de segmentation ou d’accès applicatif. Ces mots sont moins vendeurs, mais ils n’exigent pas d’expliquer ensuite pourquoi le réseau interne reste un buffet à volonté.

Exemple : vérifier qu’une politique bloque le mouvement latéral

Une politique réseau ne démontre pas un modèle Zero Trust complet, mais elle permet de détecter immédiatement le mensonge le plus fréquent : un espace interne où tout peut joindre tout. L’exemple suivant applique un refus par défaut entre espaces de noms Kubernetes, puis autorise uniquement l’interface applicative attendue. Kubernetes est un orchestrateur de conteneurs, et un espace de noms y sépare logiquement des ressources.

# Refuse tout trafic entrant et sortant pour les pods du namespace payments.
# Précondition : un moteur réseau Kubernetes qui applique NetworkPolicy.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# allow-api-to-db.yaml
# Autorise seulement l'API identifiée par son label à joindre PostgreSQL sur 5432.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api
      ports:
        - protocol: TCP
          port: 5432

# Appliquer les politiques, puis tester depuis un pod non autorisé.
kubectl apply -f deny-all.yaml
kubectl apply -f allow-api-to-db.yaml

# Cette connexion doit échouer depuis un pod dépourvu du label app=api.
kubectl -n payments run test --rm -it --image=postgres:16 \
  -- psql -h postgres -U appuser -d payments

Ce test doit être exécuté en intégration et après toute modification de labels, de règles ou de moteur réseau. Un manifeste accepté par l’interface de programmation applicative ne prouve rien : certains moteurs de réseau ignorent les politiques de sortie ou les appliquent différemment. La dépendance au moteur doit être vérifiée avant le déploiement, sinon la politique devient une incantation YAML particulièrement bien indentée.

Cette segmentation ne remplace pas l’authentification PostgreSQL, la rotation du mot de passe appuser, le chiffrement du trafic ni les droits au niveau des tables. Elle limite seulement qui peut tenter la connexion. C’est précisément ce qu’il faut annoncer.

Surface d’attaque, exploitation et reprise

Un système de décision centralisé devient une cible de premier rang. Compromettre le fournisseur d’identité permet d’émettre des sessions, de modifier des groupes ou d’enrôler un second facteur frauduleux. Compromettre le moteur de politiques permet d’élargir silencieusement les autorisations. Compromettre l’agent de posture peut faire passer un terminal non conforme pour sain. Le modèle réduit certains chemins d’attaque, il concentre aussi la valeur de quelques composants. La concentration n’est pas un défaut si elle est traitée comme telle.

Les contre-mesures minimales sont les suivantes :

séparer les rôles d’administration d’identité, de politique et de plateforme ;
journaliser les changements de politiques, d’attributs et d’appartenance aux groupes dans un stockage non modifiable par l’opérateur courant ;
exiger une authentification résistante au hameçonnage pour les privilèges élevés, avec clés matérielles lorsque le risque le justifie ;
limiter les jetons d’administration à quelques minutes et imposer une réauthentification pour les actions destructrices ;
inventorier les comptes de service, leurs propriétaires, leurs destinations et leurs échéances ;
tester la coupure du fournisseur d’identité, du résolveur de noms, du moteur de politiques et de la collecte de signaux terminal.

Les sauvegardes doivent inclure les politiques versionnées, les configurations des connecteurs, les autorités de certification et les clés de signature des jetons lorsqu’elles sont gérées localement. Une clé de signature perdue invalide les sessions et peut bloquer la reprise. Une clé restaurée sans contrôle de version peut réactiver des jetons qui auraient dû mourir. Les clés doivent être protégées dans un HSM (Hardware Security Module), ou module matériel de sécurité, quand leur compromission donne le pouvoir de forger des identités à grande échelle. La page cryptographie et gestion des clés détaille les contraintes de conservation et de rotation qui ne se négocient pas avec un fournisseur de slogans.

Zero Trust ne garantit pas qu’une application est sans vulnérabilité, qu’un administrateur légitime ne commettra pas d’erreur, qu’une donnée autorisée ne sera pas exfiltrée, ni qu’un terminal sain le restera après son dernier contrôle. Le reste doit venir du durcissement, de la détection, de la sauvegarde, de la réponse à incident et de la gouvernance des droits. Une politique parfaite qui protège une application vulnérable protège surtout un joli point d’entrée.

🐝 Ce qui arrive si on s’en passe

Sans décision d’accès par ressource, la porte de la ruche reste ouverte une fois le badge présenté, et le coût se paie surtout après coup. Les journaux n’enregistrent plus qu’un compte de service partagé : impossible de rattacher une requête à une personne, donc impossible de délimiter le périmètre d’un incident autrement qu’en suspectant l’ensemble des utilisateurs du compte. La révocation devient déclarative : désactiver un compte ne coupe ni les sessions ouvertes ni les jetons déjà émis, et rien ne permet de prouver l’heure réelle de fin d’accès. Le confinement se fait alors à la hache, en coupant un segment entier, avec interruption des services sains qui y résident. Enfin, la reprise repose sur des règles non versionnées, ce qui interdit de démontrer quelles autorisations existaient au moment des faits.

🦫 Explication de la marmotte 🍫

Le principe consiste à ne plus considérer qu’une personne ou un ordinateur a tous les droits parce qu’il est déjà connecté au réseau interne. Pour chaque accès à une application ou à une donnée, le système doit vérifier qui demande, quel appareil est utilisé, quelle ressource est demandée et si les règles autorisent cette action.

Le contrôle commence par l’identité : une personne ou un programme doit prouver son identité. Le système vérifie ensuite les droits associés. Il peut aussi vérifier si l’ordinateur respecte des règles, par exemple s’il est à jour et protégé. Une décision autorise ou refuse alors un accès précis, pour une durée limitée.

Ce fonctionnement échoue si l’organisation vérifie seulement l’entrée sur le réseau. Après cette entrée, un ordinateur infecté peut encore chercher d’autres serveurs et utiliser des accès internes trop larges. Pour réduire ce risque, il faut limiter les communications entre applications, donner des droits distincts à chaque programme et empêcher les accès non nécessaires.

Ces contrôles dépendent de services centraux qui gèrent les identités et les règles. Si ces services sont indisponibles, il faut savoir si l’accès est bloqué ou temporairement maintenu. S’ils sont compromis, un attaquant peut obtenir de faux droits. Il faut donc surveiller les changements, renouveler les secrets, sauvegarder les règles et tester les pannes. Le nom ne protège rien : seule l’application réelle de ces règles, ressource par ressource, réduit le danger.

Pages voisines

La citent

Zero Trust marketing ou sécurité réellement vérifiée

Elle cite

Zero Trust marketing ou sécurité réellement vérifiée

Zero Trust marketing ou sécurité réellement vérifiée

La promesse Zero Trust et le périmètre qui survit

Le coût réel de la vérification continue

Les contrôles qui cassent réellement la confiance implicite

Exemple : vérifier qu’une politique bloque le mouvement latéral

Surface d’attaque, exploitation et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines