Zero Trust en pratique: comment les systèmes se comportent lorsque quelque chose tourne mal

La plupart des discussions sur la sécurité se concentrent sur la manière d’empêcher les attaquants d’entrer. Bien plus rares sont celles qui s’interrogent sur ce qui se passe après qu’un incident s’est produit. Zero Trust ne consiste pas à empêcher chaque défaillance. Il s’agit de concevoir des systèmes capables de rester stables lorsque l’incertitude apparaît.

Les débats sur la sécurité commencent presque toujours par le périmètre. L’attention se porte sur la prévention des intrusions, le renforcement de l’enveloppe externe d’un système et la réduction de la probabilité d’un premier compromis. Pare-feu, mécanismes d’authentification, connexions chiffrées et contrôles d’accès dominent le discours. Tout cela est nécessaire, mais cela évite discrètement une question plus inconfortable : que se passe-t-il lorsque quelque chose échoue malgré tout?

L’expérience montre que l’échec n’est pas une anomalie. Les identifiants fuitent, les configurations dérivent, les dépendances évoluent et les systèmes changent plus vite que les hypothèses sur lesquelles ils ont été conçus. Dans des environnements réels, la question n’est pas de savoir si quelque chose va mal tourner, mais quand. Le facteur décisif n’est pas l’erreur initiale, mais la manière dont le système réagit une fois cette erreur survenue.

C’est ici que la différence entre les architectures traditionnelles et la pensée Zero Trust devient visible. Non pas comme un slogan, ni comme un produit isolé, mais comme une manière fondamentalement différente pour un système de se comporter face à l’incertitude.

Deux façons de penser la confiance

Les systèmes traditionnels reposent généralement sur une idée simple : le danger se situe à l’extérieur, la sécurité à l’intérieur. Une fois qu’une requête a franchi une frontière – après une connexion VPN, une authentification réussie ou l’entrée dans un réseau interne – elle est largement considérée comme digne de confiance. Le système suppose que ce qui se passe en interne est majoritairement bénin et que des vérifications excessives ne feraient que ralentir les opérations.

Zero Trust part d’un postulat différent. Il considère que la localisation n’a, à elle seule, aucune signification et qu’une requête précédemment acceptée ne justifie pas automatiquement la suivante. La confiance n’est pas un état permanent. C’est une décision prise de manière répétée, en fonction du contexte, de l’intention et du comportement observé.

Cette distinction peut sembler abstraite, mais elle devient très concrète au moment précis où quelque chose se dérègle.

Un point de départ réaliste: un identifiant compromis

Imaginons une situation techniquement banale. Un attaquant obtient l’accès à un seul identifiant. Il peut s’agir d’une clé API intégrée dans une application, d’un jeton de compte de service dans un cluster Kubernetes ou d’un compte utilisateur aux privilèges limités. Cela ne nécessite ni compétences exceptionnelles ni vulnérabilités rares. Les identifiants fuitent via les journaux, les sauvegardes, les erreurs de configuration et les fautes opérationnelles courantes.

À ce stade, l’incident reste limité. Un point d’entrée, une identité, un premier appui. La suite dépend entièrement de la manière dont le système est conçu pour réagir.

Ce qui se passe dans une architecture traditionnelle

Dans une configuration classique, cet identifiant est accepté presque tel quel. S’il est valide, le système autorise les actions qui lui sont associées. Ces autorisations sont souvent plus larges que strictement nécessaire, accordées autrefois pour simplifier l’exploitation et rarement réévaluées. Avec le temps, elles deviennent partie intégrante de la normalité supposée du système.

Une fois à l’intérieur, les déplacements sont souvent simples. Les services internes communiquent entre eux parce qu’ils partagent un réseau ou un cluster. Les bases de données acceptent les connexions car elles font confiance aux requêtes provenant de l’intérieur. Les systèmes de supervision enregistrent l’activité, mais le comportement opérationnel du système reste inchangé, comme si rien d’anormal ne se produisait.

Du point de vue de l’attaquant, c’est un environnement qui récompense la patience. Il y a du temps pour explorer, tester les connexions possibles et observer les interactions entre composants. La progression ne nécessite pas de franchir de nouvelles défenses, seulement d’emprunter les chemins que le système offre déjà. Tout semble normal, parce que, techniquement, tout l’est.

La caractéristique déterminante est la continuité de la confiance. Une fois accordée, elle tend à persister.

Zero Trust commence après la première erreur

Zero Trust ne promet pas d’empêcher la fuite initiale d’un identifiant. Il ne prétend pas éliminer les erreurs humaines ni les dérives de configuration. Sa valeur n’apparaît qu’après la première défaillance.

Dans un système orienté Zero Trust, un identifiant compromis n’ouvre pas automatiquement un accès étendu. Chaque requête effectuée avec cette identité est évaluée dans son contexte. Le système ne se demande pas seulement qui effectue la requête, mais aussi ce qui est demandé, vers quelle destination, et si ce comportement correspond à ce qui est attendu.

En l’absence d’autorisation explicite pour cette combinaison, la requête échoue. Non pas parce qu’une attaque a été détectée, mais parce qu’aucune justification n’existe. La progression devient conditionnelle plutôt qu’automatique.

Ce glissement subtil a des conséquences profondes. Le chemin de l’attaquant se rétrécit rapidement. Au lieu d’une exploration sans limites, il se heurte à des frontières définies par la finalité, le temps et le périmètre.

Quand l’observation modifie le comportement

Une différence clé entre les deux modèles réside dans la manière dont les systèmes réagissent aux anomalies. Dans les environnements traditionnels, une activité inhabituelle est souvent simplement enregistrée pour être analysée plus tard. Des journaux sont produits, des alertes peuvent être déclenchées, mais le comportement opérationnel du système reste inchangé.

Zero Trust considère l’observation comme une entrée, et non comme une simple preuve. Lorsque les systèmes de surveillance – souvent des collecteurs centralisés de journaux et d’événements tels que les plateformes SIEM – détectent des comportements qui s’écartent des schémas établis, cette information alimente directement les mécanismes de contrôle.

IF service=backend AND
   request_rate > baseline*5 AND
   destination not in allowed_service_map
THEN
   action = "tighten_policy_for_source"

Cela ne requiert pas une certitude parfaite. Le système n’a pas besoin de qualifier l’activité de malveillante. Il lui suffit de reconnaître une zone d’incertitude. Lorsque l’incertitude augmente, la confiance diminue.

Concrètement, cela se manifeste souvent au niveau du réseau. Le trafic provenant d’une source au comportement inattendu peut être limité à un ensemble restreint de destinations. Des connexions techniquement possibles ne sont plus autorisées, sauf si elles sont explicitement nécessaires. Le système s’adapte et durcit sa posture sans intervention humaine.

Contrairement aux environnements traditionnels, où les anomalies coexistent avec des accès inchangés, Zero Trust permet à l’observation de remodeler le comportement du système en temps réel.

Là où les conteneurs rendent la différence visible

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      automountServiceAccountToken: false
      containers:
        - name: app
          image: example/app:1.0.0
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false

Les environnements Kubernetes illustrent particulièrement bien cette distinction, car la confiance y est directement inscrite dans la configuration. Kubernetes n’est pas en soi une plateforme Zero Trust, mais il fournit les mécanismes permettant d’appliquer – ou d’ignorer – les principes du Zero Trust.

Considérons ce qui se produit lorsqu’un attaquant obtient l’accès à un conteneur en cours d’exécution.

Dans de nombreuses configurations par défaut, le système de fichiers d’un conteneur est accessible en écriture. Les processus s’exécutent avec des privilèges élevés à l’intérieur du conteneur. Les communications réseau entre pods sont ouvertes. Les comptes de service accordent automatiquement un accès à l’API Kubernetes. Du point de vue de la sécurité, cela reflète la même hypothèse que dans les systèmes traditionnels : une fois à l’intérieur, l’environnement est largement digne de confiance.

Une approche Zero Trust traite cette situation différemment.

Lorsque le système de fichiers racine d’un conteneur est monté en lecture seule, le système ne suppose plus que le processus doit pouvoir modifier son propre environnement. Même si un attaquant parvient à exécuter du code dans le conteneur, il ne peut ni installer d’outils supplémentaires, ni modifier les binaires de l’application, ni établir une persistance. Tout ce qu’il fait n’existe qu’en mémoire et disparaît au redémarrage du pod.

L’exécution des conteneurs avec des utilisateurs non privilégiés renforce encore cette frontière. Le processus est traité comme une application, et non comme un système d’exploitation. De nombreuses techniques d’exploitation courantes échouent simplement parce que les privilèges requis sont absents.

Les politiques réseau ajoutent une couche supplémentaire. Au lieu de supposer que chaque pod peut communiquer avec tous les autres, les échanges ne sont autorisés explicitement que là où ils sont nécessaires. Un pod compromis ne devient pas un point d’appui vers l’ensemble du cluster. Il devient un point terminal isolé, à portée limitée.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress-from-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

La restriction des chemins réseau suffit souvent à empêcher les déplacements latéraux entre services, mais elle ne traite pas une autre voie d’escalade fréquente : l’accès au plan de contrôle lui-même. Dans les environnements Kubernetes, cela signifie généralement l’API Kubernetes. Si un pod compromis peut s’authentifier auprès du serveur API, l’isolation réseau seule ne suffit plus. L’attaquant peut commencer à inventorier les ressources, lire les configurations ou tenter de créer de nouveaux workloads.

C’est pourquoi la pensée Zero Trust s’étend au-delà du trafic entre services pour inclure l’identité des workloads et l’accès au plan de contrôle.

apiVersion: v1

kind: Pod
metadata:
  name: job-no-k8s-api
spec:
  automountServiceAccountToken: false
  containers:
    - name: job
      image: example/job:1.0.0
      securityContext:
        runAsNonRoot: true
        readOnlyRootFilesystem: true

Même l’accès à l’API Kubernetes est traité avec prudence. Les pods qui n’ont pas besoin d’interagir avec le plan de contrôle ne reçoivent pas les identifiants nécessaires. Cela élimine entièrement l’un des chemins d’escalade les plus courants.

Aucune de ces mesures ne rend les attaques impossibles. Elles les rendent contraintes.

Transformer la forme du risque

L’effet le plus important du Zero Trust n’est pas la prévention, mais la transformation. Dans une architecture traditionnelle, une seule erreur peut ouvrir une voie d’abus large et persistante. Dans un système orienté Zero Trust, la même erreur conduit à une opportunité étroite, temporaire et fragile.

Du point de vue de l’attaquant, l’environnement devient hostile aux progressions lentes et méthodiques. Les accès expirent. Les routes sont bloquées. Les actions qui s’écartent du comportement attendu réduisent, plutôt qu’elles n’élargissent, les options disponibles. Ce qui aurait pu être une exploration discrète devient une course contre le temps et la visibilité.

Il ne s’agit pas d’une garantie de sécurité. C’est un changement de dynamique.

Une conclusion honnête

Zero Trust n’élimine pas les compromissions. Il ne supprime pas la nécessité d’une ingénierie rigoureuse ni d’opérations disciplinées. Il ne promet ni détection parfaite ni contrôle absolu. Ce qu’il offre, c’est une réponse par défaut différente face à l’échec.

Les systèmes traditionnels tendent à préserver la confiance tant qu’on ne leur indique pas explicitement de faire autrement. Les systèmes Zero Trust fonctionnent à l’inverse. Lorsque la certitude s’érode, la confiance se contracte.

En pratique, cette différence détermine souvent si un incident reste une perturbation contenue ou s’amplifie en une défaillance systémique. Non pas parce que Zero Trust serait magique, mais parce qu’il aligne le comportement du système sur la réalité selon laquelle les systèmes complexes échouent – et que la résilience commence par la manière dont ils réagissent lorsqu’ils le font.