Pendant des décennies, la sécurité réseau reposait sur un modèle simple : un périmètre durci protège un intérieur de confiance. Firewall en entrée, VPN pour les distants, et tout ce qui se trouve à l'intérieur du réseau est considéré comme sûr. Ce modèle est mort. Les attaques par mouvement latéral, la compromission de VPN, le cloud hybride et le télétravail massif l'ont rendu obsolète. En 2026, les architectures Zero Trust ne sont plus un concept théorique du NIST : elles sont devenues le standard de fait pour toute infrastructure sérieuse.
Cet article détaille les principes fondamentaux du Zero Trust, propose une architecture concrète, puis montre comment l'implémenter étape par étape sur des serveurs Linux avec des outils open-source. Pas de slides marketing, uniquement du concret.
Pourquoi le périmètre traditionnel est mort
Le modèle castle-and-moat part du principe que les menaces viennent de l'extérieur. Une fois passé le firewall, le trafic interne circule librement entre les machines. Ce postulat s'effondre face à trois réalités.
Le mouvement latéral est la norme, pas l'exception. La grande majorité des attaques récentes suivent le même schéma : compromission d'un poste ou d'un service exposé, puis pivot vers les ressources internes. Un attaquant qui compromet un conteneur Docker mal isolé accède à tout le réseau plat. Le monitoring réseau avec Suricata détecte ces comportements, mais ne les empêche pas structurellement.
Les VPN créent une fausse confiance. Un VPN authentifie un utilisateur au moment de la connexion, puis lui donne accès à l'intégralité du réseau interne. Si ses credentials sont compromis, ou si son poste est infecté, l'attaquant hérite de tous ses accès. Le VPN ne vérifie ni l'état du poste, ni la légitimité de chaque requête individuelle. Même un tunnel WireGuard correctement configuré ne résout que le problème du transport, pas celui de l'autorisation granulaire.
Le cloud hybride dissout le périmètre. Quand vos services tournent simultanément sur des serveurs on-premise, du cloud public, des conteneurs et des fonctions serverless, où se trouve le périmètre ? Il n'existe plus. Chaque service est potentiellement exposé, et la frontière entre intérieur et extérieur est devenue floue.
Les 5 principes fondamentaux du Zero Trust
Le Zero Trust n'est pas un produit à acheter. C'est un modèle architectural basé sur cinq principes interdépendants, formalisés initialement par Forrester puis adoptés par le NIST (SP 800-207). Chaque principe doit être implémenté pour que l'ensemble soit cohérent.
1. Never Trust, Always Verify
Chaque requête, chaque connexion, chaque accès doit être authentifié et autorisé indépendamment, quelle que soit son origine. Un serveur interne qui communique avec un autre serveur interne passe par les mêmes contrôles qu'un utilisateur distant. L'adresse IP source ne constitue jamais une preuve d'identité suffisante.
2. Least Privilège Access
Chaque entité (utilisateur, service, conteneur) reçoit uniquement les permissions strictement nécessaires à sa fonction, et uniquement pour la durée requise. Un service de monitoring n'a pas besoin d'écrire dans la base de données de production. Un développeur n'a pas besoin d'accéder au serveur de paiement. Les accès sont accordés de manière granulaire et temporaire.
3. Assume Breach
L'architecture est conçue en partant du principe qu'une compromission a déjà eu lieu ou aura lieu. Le réseau est segmenté pour limiter le blast radius. Chaque zone est isolée. Si un service est compromis, l'attaquant ne peut pas pivoter librement vers les autres. C'est le principe de micro-segmentation.
4. Verify Explicitly
L'authentification repose sur des signaux multiples : identité de l'utilisateur, état du device, localisation, heure, comportement habituel. Un accès légitime depuis un poste corporate à Paris à 10h du matin n'a pas le même profil de risque qu'une connexion depuis un pays inconnu à 3h du matin. Le Policy Engine évalue ces signaux en temps réel pour chaque décision d'accès.
5. Continuous Monitoring
La vérification n'est pas ponctuelle. L'état de confiance est réévalué en continu pendant toute la session. Un device qui devient non-conforme en cours de session (antivirus désactivé, comportement anormal) voit ses accès révoqués immédiatement. Le logging exhaustif alimente la détection et la réponse aux incidents.
Architecture Zero Trust concrète
Passons du concept à l'architecture. Un déploiement Zero Trust repose sur quatre composants fondamentaux qui interagissent pour évaluer et autoriser chaque requête.
Identity Provider (IdP)
Le socle de tout Zero Trust est l'identité forte. Chaque utilisateur et chaque service doit disposer d'une identité cryptographiquement vérifiable. Pour les utilisateurs, c'est un IdP avec MFA obligatoire. Pour les services, ce sont des certificats X.509 ou des tokens SPIFFE. Sans identité fiable, aucune décision d'accès n'est possible.
Policy Engine / Policy Decision Point (PDP)
Le cerveau de l'architecture. Le Policy Engine reçoit chaque requête d'accès, collecte le contexte (identité, device, localisation, ressource demandée) et applique les politiques définies pour rendre un verdict : autoriser, refuser, ou demander une authentification renforcée. Les politiques sont écrites en code (policy-as-code), versionnées et auditables.
Policy Enforcement Point (PEP)
Le point d'application des décisions. Typiquement un reverse proxy, un sidecar ou un agent réseau qui intercepte le trafic et applique le verdict du PDP. Le PEP bloque ou autorise le trafic en temps réel. Il est déployé au plus près de chaque ressource protégée.
Micro-segmentation réseau
Le réseau est découpé en segments fins. Chaque service ou groupe de services est isolé dans son propre segment, avec des règles de communication explicites. Le trafic entre segments passe obligatoirement par un PEP. La micro-segmentation se fait au niveau firewall (nftables, eBPF) ou au niveau applicatif (service mesh).
+------------------+
| Policy Engine |
| (PDP - OPA) |
+--------+---------+
|
decision | context + verdict
request |
+-------------------+-------------------+
| | |
+-----+-----+ +-----+-----+ +-----+-----+
| PEP | | PEP | | PEP |
| (Envoy) | | (Envoy) | | (Envoy) |
+-----+-----+ +-----+-----+ +-----+-----+
| | |
+-----+-----+ +-----+-----+ +-----+-----+
| Service A | | Service B | | Service C |
| (frontend)| | (API) | | (DB) |
+-----------+ +-----------+ +-----------+
segment-frontend segment-api segment-dataChaque service communique exclusivement via son PEP local. Aucun trafic direct entre segments n'est autorisé. Le Policy Engine centralise la logique d'autorisation et peut être mis à jour sans toucher aux services.
Implémentation étape par étape sur Linux
Passons à la pratique. Les quatre étapes suivantes transforment une infrastructure Linux classique en architecture Zero Trust fonctionnelle, en utilisant uniquement des outils open-source.
Étape 1 : MFA obligatoire avec pam_google_authenticator
Le premier pilier est l'authentification forte. Même avec des clés SSH, ajouter un second facteur TOTP élimine le risque de compromission de clé privée seule. La configuration se fait via PAM, le framework d'authentification de Linux.
# Installation
sudo apt update && sudo apt install -y libpam-google-authenticator
# Configuration par utilisateur
google-authenticator -t -d -f -r 3 -R 30 -w 3Les options utilisées : -t pour le mode time-based, -d pour interdire la réutilisation de token, -f pour forcer l'écriture du fichier, -r 3 -R 30 pour limiter à 3 tentatives par 30 secondes, -w 3 pour une fenêtre de validité de 3 tokens.
# /etc/pam.d/sshd - Ajouter en haut du fichier
auth required pam_google_authenticator.so nullok
# /etc/ssh/sshd_config - Activer le challenge-response
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
KbdInteractiveAuthentication yes
# Redemarrer SSH
sudo systemctl restart sshdAvec AuthenticationMethods publickey,keyboard-interactive, SSH exige la clé privée ET le code TOTP. L'option nullok dans PAM permet aux utilisateurs qui n'ont pas encore configuré leur TOTP de se connecter (retirez-la une fois tout le monde migré). Pour la configuration SSH de base, référez-vous au guide OpenSSH Server.
Étape 2 : Micro-segmentation avec nftables
nftables remplace iptables comme framework de filtrage du noyau Linux. Sa syntaxe est plus cohérente et ses performances supérieures, notamment pour les jeux de règles complexes. L'objectif est de segmenter le réseau pour que chaque service ne puisse communiquer qu'avec ses dépendances explicites.
#!/usr/sbin/nft -f
# /etc/nftables.conf - Micro-segmentation Zero Trust
flush ruleset
table inet zerotrust {
# Definir les segments reseau
set segment_frontend {
type ipv4_addr
elements = { 10.0.1.10, 10.0.1.11 }
}
set segment_api {
type ipv4_addr
elements = { 10.0.2.10, 10.0.2.11 }
}
set segment_data {
type ipv4_addr
elements = { 10.0.3.10 }
}
set segment_monitoring {
type ipv4_addr
elements = { 10.0.4.10 }
}
chain input {
type filter hook input priority 0; policy drop;
# Loopback et connexions etablies
iif lo accept
ct state established,related accept
# SSH avec MFA uniquement depuis le bastion
tcp dport 2222 ip saddr 10.0.0.5 accept
# Monitoring : Prometheus scrape depuis segment monitoring
tcp dport 9100 ip saddr @segment_monitoring accept
# Logging specifique pour les rejets
log prefix "[ZT-DROP] " counter drop
}
chain forward {
type filter hook forward priority 0; policy drop;
# Frontend -> API uniquement sur port 8443 (mTLS)
ip saddr @segment_frontend ip daddr @segment_api tcp dport 8443 accept
# API -> Data uniquement sur port 5432 (PostgreSQL)
ip saddr @segment_api ip daddr @segment_data tcp dport 5432 accept
# Monitoring -> tous les segments (read-only metrics)
ip saddr @segment_monitoring tcp dport 9100 accept
# Retour des connexions etablies
ct state established,related accept
# Tout le reste est bloque et logge
log prefix "[ZT-FWD-DROP] " counter drop
}
chain output {
type filter hook output priority 0; policy accept;
}
}# Appliquer et activer
sudo nft -f /etc/nftables.conf
sudo systemctl enable nftables
# Verifier les regles actives
sudo nft list rulesetChaque segment est défini explicitement. Le frontend ne peut contacter que l'API, l'API ne peut contacter que la base de données. Aucune communication latérale n'est possible. Les rejets sont loggués avec un préfixe identifiable pour le SIEM. Pour les fondamentaux du filtrage, consultez le tutoriel iptables/nftables.
Étape 3 : mTLS entre services
Le TLS classique authentifie le serveur auprès du client. Le mutual TLS (mTLS) ajoute l'authentification du client auprès du serveur. Chaque service possède son propre certificat, et les deux parties vérifient l'identité de l'autre avant d'échanger des données. C'est le mécanisme fondamental pour l'authentification service-to-service en Zero Trust.
# Creer une CA interne pour le Zero Trust
mkdir -p /etc/zt-pki/{ca,certs,private}
chmod 700 /etc/zt-pki/private
# Generer la cle CA
openssl ecparam -genkey -name prime256v1
-out /etc/zt-pki/ca/ca.key
chmod 600 /etc/zt-pki/ca/ca.key
# Generer le certificat CA (10 ans)
openssl req -new -x509 -days 3650
-key /etc/zt-pki/ca/ca.key
-out /etc/zt-pki/ca/ca.crt
-subj "/O=MaBoite/CN=ZeroTrust-CA"# Generer un certificat pour un service (ex: api-backend)
SERVICE_NAME="api-backend"
# Cle privee du service
openssl ecparam -genkey -name prime256v1
-out /etc/zt-pki/private/${SERVICE_NAME}.key
chmod 600 /etc/zt-pki/private/${SERVICE_NAME}.key
# CSR avec SAN
openssl req -new
-key /etc/zt-pki/private/${SERVICE_NAME}.key
-out /etc/zt-pki/certs/${SERVICE_NAME}.csr
-subj "/O=MaBoite/CN=${SERVICE_NAME}"
-addext "subjectAltName=DNS:${SERVICE_NAME},DNS:${SERVICE_NAME}.internal,IP:10.0.2.10"
# Signer avec la CA
openssl x509 -req -days 365
-in /etc/zt-pki/certs/${SERVICE_NAME}.csr
-CA /etc/zt-pki/ca/ca.crt
-CAkey /etc/zt-pki/ca/ca.key
-CAcreateserial
-out /etc/zt-pki/certs/${SERVICE_NAME}.crt
-copy_extensions copyallExemple d'intégration dans un reverse proxy Nginx pour forcer le mTLS :
# /etc/nginx/conf.d/api-mtls.conf
server {
listen 8443 ssl;
server_name api-backend.internal;
# Certificat du serveur
ssl_certificate /etc/zt-pki/certs/api-backend.crt;
ssl_certificate_key /etc/zt-pki/private/api-backend.key;
# Exiger le certificat client (mTLS)
ssl_client_certificate /etc/zt-pki/ca/ca.crt;
ssl_verify_client on;
ssl_verify_depth 2;
# TLS 1.3 uniquement
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
# Extraire le CN du certificat client pour le logging
set $client_cn $ssl_client_s_dn_cn;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header X-Client-CN $client_cn;
proxy_set_header X-Real-IP $remote_addr;
access_log /var/log/nginx/api-mtls-access.log;
}
}Avec cette configuration, seuls les services possédant un certificat signé par votre ÇA interne peuvent communiquer avec l'API. Un service compromis sans le certificat valide est bloqué au niveau TLS, avant même d'atteindre l'application.
Étape 4 : Logging centralisé et détection
Le Zero Trust sans visibilité est aveugle. Chaque décision d'accès, chaque rejet, chaque anomalie doit être loggué, centralisé et analysable. Le triptyque collecte, centralisation, alerting est indispensable.
# Installation de Vector (collecteur de logs haute performance)
curl -sSL https://sh.vector.dev | bash
# /etc/vector/vector.toml - Configuration Zero Trust
[sources.nftables_drops]
type = "journald"
include_matches = { "_TRANSPORT" = ["kernel"] }
[transforms.filter_zt_drops]
type = "filter"
inputs = ["nftables_drops"]
condition = 'contains(string!(.message), "[ZT-DROP]") || contains(string!(.message), "[ZT-FWD-DROP]")'
[sources.ssh_auth]
type = "file"
include = ["/var/log/auth.log"]
read_from = "end"
[transforms.parse_ssh]
type = "remap"
inputs = ["ssh_auth"]
source = '''
. = parse_syslog!(.message)
.tags = ["zero-trust", "authentication"]
'''
[sources.nginx_mtls]
type = "file"
include = ["/var/log/nginx/api-mtls-access.log"]
read_from = "end"
[sinks.loki]
type = "loki"
inputs = ["filter_zt_drops", "parse_ssh", "nginx_mtls"]
endpoint = "http://10.0.4.10:3100"
encoding.codec = "json"
[sinks.loki.labels]
source = "{{ source_type }}"
host = "{{ host }}"
environment = "production"# Activer et demarrer Vector
sudo systemctl enable --now vector
# Verifier que les logs arrivent
vector topLes logs de rejets nftables, d'authentification SSH et d'accès mTLS convergent vers Loki. Depuis Grafana, créez des alertes sur les patterns critiques : tentatives de communication inter-segments bloquées (mouvement latéral potentiel), échecs mTLS répétés (certificat expiré ou attaque), connexions SSH depuis des IP inhabituelles.
Pour compléter la détection, ajoutez Fail2ban en couche supplémentaire sur les logs d'authentification. Le Zero Trust ne remplace pas la défense en profondeur : il la structure.
Outils open-source pour le Zero Trust
L'écosystème open-source offre désormais des alternatives matures aux solutions commerciales. Voici les cinq outils les plus pertinents pour implémenter une architecture Zero Trust complète.
Teleport : accès Zero Trust unifié
Teleport remplace SSH, les VPN et les jump hosts par un proxy d'accès Zero Trust. Chaque session est authentifiée, autorisée et enregistrée. Les certificats sont éphémères (quelques heures), éliminant le problème des clés SSH statiques. L'enregistrement de session permet l'audit complet de toute activité. Teleport prend en charge SSH, Kubernetes, les bases de données et les applications web via un seul point d'entrée.
HashiCorp Boundary : accès réseau Zero Trust
Boundary fournit un accès réseau sécurisé sans exposer les services directement. Les utilisateurs se connectent à Boundary, qui ouvre un tunnel éphémère vers la ressource demandée après authentification et autorisation. Aucune règle firewall n'est nécessaire pour les accès utilisateurs : Boundary gère tout dynamiquement. L'intégration avec Vault pour les credentials dynamiques complète l'ensemble.
Cilium : networking et sécurité eBPF
Cilium utilise eBPF pour implémenter la micro-segmentation au niveau du noyau Linux, avec des performances proches du natif. Les politiques réseau sont définies en termes d'identités de services (pas d'adresses IP), ce qui les rend indépendantes de l'infrastructure. Cilium remplace kube-proxy et fournit l'observabilité réseau via Hubble, donnant une visibilité complète sur le trafic inter-services.
SPIFFE/SPIRE : identité service-to-service
SPIFFE définit un standard ouvert pour l'identité des services. SPIRE en est l'implémentation de référence. Chaque service reçoit un SVID (SPIFFE Verifiable Identity Document), un certificat X.509 à durée de vie courte, automatiquement renouvelé. SPIRE gère la rotation, la distribution et la révocation des identités sans intervention manuelle. C'est le socle idéal pour le mTLS à grande échelle, éliminant la gestion manuelle des certificats décrite plus haut.
Open Policy Agent (OPA) : policy-as-code
OPA est le moteur de décision qui implémente le Policy Decision Point. Les politiques d'accès sont écrites en Rego (un langage déclaratif), versionnées dans Git et déployées comme du code. OPA reçoit une requête d'accès avec son contexte, évalue les politiques et retourne un verdict. Il s'intègre avec Envoy, Kubernetes, Terraform et la plupart des reverse proxies.
# policy.rego - Exemple de politique Zero Trust OPA
package zerotrust.access
default allow = false
# Autoriser le frontend a acceder a l'API pendant les heures ouvrables
allow {
input.source.service == "frontend"
input.destination.service == "api-backend"
input.destination.port == 8443
is_business_hours
}
# Autoriser l'API a acceder a la DB uniquement en lecture
allow {
input.source.service == "api-backend"
input.destination.service == "postgresql"
input.destination.port == 5432
input.action == "SELECT"
}
# Refuser tout acces depuis un service non enregistre
allow {
input.source.spiffe_id != ""
valid_spiffe_id(input.source.spiffe_id)
}
is_business_hours {
now := time.now_ns()
hour := time.clock(now)[0]
hour >= 6
hour < 22
}
valid_spiffe_id(id) {
startswith(id, "spiffe://maboite.internal/")
}Erreurs courantes et pièges à éviter
L'implémentation Zero Trust échoue plus souvent par mauvaise exécution que par mauvaise conception. Voici les six erreurs les plus fréquentes.
1. Commencer par la micro-segmentation réseau
C'est l'erreur classique. La micro-segmentation sans identité forte est du filtrage IP glorifié. Commencez par l'identité (MFA, certificats de service), puis segmentez. Sans identité fiable, vos politiques de segmentation sont basées sur des adresses IP, qui changent, se spoofent et ne prouvent rien.
2. Déployer en big-bang
Le Zero Trust se déploie progressivement. Commencez en mode audit (log-only) pour cartographier les flux réels avant de bloquer quoi que ce soit. Un déploiement brutal provoque des incidents en production et décrédibilise l'initiative. Commencez par un service critique, validez l'approche, puis étendez.
3. Ignorer le trafic est-ouest existant
Avant de segmenter, cartographiez les communications inter-services existantes. De nombreuses applications ont des dépendances non documentées (health checks, backups, synchronisation). Utilisez les logs nftables ou Cilium Hubble pour capturer le trafic réel pendant au moins deux semaines avant de créer les politiques.
4. Négliger la gestion des certificats
Le mTLS à grande échelle signifie des centaines de certificats à gérer, renouveler et révoquer. Sans automatisation (SPIRE, cert-manager, Vault PKI), les certificats expirent, les services tombent et les équipes désactivent le mTLS par frustration. Automatisez la PKI dès le premier jour.
5. Oublier les flux de monitoring
Prometheus, Grafana, le collecteur de logs : ces services doivent aussi passer par le Zero Trust. Un monitoring exclu des règles de segmentation est un vecteur d'attaque. Créez un segment dédié avec des accès restreints en lecture seule vers les endpoints de métriques.
6. Considérer le Zero Trust comme un projet fini
Le Zero Trust est un processus continu, pas un projet avec une date de fin. Les politiques évoluent avec l'infrastructure. Les nouvelles applications doivent être intégrées. Les audits de flux doivent être réguliers. Prévoyez une revue trimestrielle des politiques et des flux autorisés.
Checklist Zero Trust : par où commencer
Voici une checklist ordonnée pour implémenter le Zero Trust progressivement. Chaque étape doit être validée avant de passer à la suivante.
- Semaine 1-2 : Identité forte. MFA obligatoire sur tous les accès SSH et administratifs. Clés SSH uniquement, TOTP comme second facteur. Désactiver les mots de passe partout.
- Semaine 3-4 : Inventaire des flux. Cartographier toutes les communications inter-services. Logger le trafic réseau pendant deux semaines. Documenter chaque flux légitime avec sa source, destination et port.
- Semaine 5-6 : PKI interne. Déployer une ÇA interne. Générer des certificats pour chaque service. Automatiser la rotation avec SPIRE ou un script cron. Mettre en place le mTLS sur un premier service non-critique.
- Semaine 7-8 : Micro-segmentation en audit. Déployer les règles nftables en mode log-only. Vérifier que tous les flux légitimes sont capturés. Ajuster les règles selon les faux positifs.
- Semaine 9-10 : Enforcement progressif. Activer le blocage segment par segment, en commençant par les segments les plus isolés (bases de données). Monitorer les rejets. Corriger les oublis.
- Semaine 11-12 : Logging et alerting. Centraliser tous les logs de sécurité. Créer des dashboards de visibilité. Configurer les alertes sur les rejets anormaux et les échecs d'authentification.
- Mois 4+ : Policy Engine. Déployer OPA pour centraliser les décisions d'accès. Écrire les politiques en code. Versionner dans Git. Intégrer les revues de politiques dans les sprints.
La checklist de sécurité serveur Linux couvre les prérequis de hardening indispensables avant de commencer le Zero Trust. Assurez-vous que ces fondamentaux sont en place avant d'ajouter les couches d'architecture.
L'architecture Zero Trust est un investissement significatif en temps et en complexité opérationnelle. Mais face à la réalité des attaques modernes, où le mouvement latéral et la compromission de VPN sont devenus la norme, c'est désormais le seul modèle qui offre une protection structurelle. Commencez petit, itérez vite, et surtout : ne considérez jamais que c'est terminé.
Commentaires