Zero Trust : ne jamais faire confiance, toujours vérifier

Pendant des décennies, la sécurité reposait sur un périmètre : l’intérieur du réseau était considéré comme sûr, l’extérieur comme hostile. Cette approche est obsolète. Le modèle Zero Trust part d’un principe radical : aucune confiance implicite, que l’on soit à l’intérieur ou à l’extérieur du réseau. Chaque accès doit être vérifié, chaque identité authentifiée, chaque flux autorisé explicitement.

En résumé : Zero Trust = “Ne jamais faire confiance, toujours vérifier”. Chaque requête est traitée comme provenant d’un réseau hostile, quel que soit son origine. L’identité et le contexte déterminent l’accès, pas la position réseau.

L’erreur du château fort

Le modèle traditionnel de sécurité périmétrique repose sur une confiance implicite une fois “à l’intérieur”.

Exemples de raisonnements dangereux :

“Le serveur est sur le réseau interne, pas besoin de chiffrer”
“Les flux entre applications internes n’ont pas besoin d’authentification”
“Le VPN donne accès à tout le réseau, c’est normal”
“Si tu es dans le bureau, tu es de confiance”
“Le pare-feu périmétrique nous protège”

Ce modèle échoue face aux menaces modernes :

Menace	Pourquoi le périmètre échoue
Phishing	L’attaquant est déjà “à l’intérieur” via un poste compromis
Mouvement latéral	Une fois dedans, accès libre à tout le réseau
Insider threat	L’employé malveillant est de facto dans le périmètre
Cloud et SaaS	Il n’y a plus de périmètre défini
Télétravail	Les utilisateurs sont partout

Le modèle Zero Trust

Zero Trust repose sur trois piliers fondamentaux :

1. Vérification explicite

Chaque accès est authentifié et autorisé, sans exception :

Authentification forte (MFA) pour tous les utilisateurs
Authentification mutuelle (mTLS) entre services
Tokens à durée limitée et révocables
Vérification à chaque requête, pas seulement à la connexion initiale

2. Accès au moindre privilège

Chaque identité n’accède qu’à ce dont elle a besoin :

Segmentation fine (microsegmentation)
Politiques basées sur l’identité et le contexte
Accès just-in-time plutôt que permanent
Révocation automatique après inactivité

3. Hypothèse de compromission

On suppose qu’une brèche existe déjà :

Chiffrement de tous les flux (y compris internes)
Logging et monitoring exhaustifs
Détection des anomalies comportementales
Blast radius limité par la segmentation

La métaphore de l’aéroport

Dans un aéroport, chaque passager montre son passeport et sa carte d’embarquement à chaque étape : check-in, contrôle de sécurité, embarquement. Peu importe qu’il soit déjà dans l’aéroport, chaque passage est vérifié.

Un modèle Zero Trust fonctionne de la même manière : avoir traversé un premier contrôle ne dispense pas des suivants.

Les composants d’une architecture Zero Trust

Identity Provider (IdP)

Le fournisseur d’identité est la pierre angulaire :

Source unique de vérité pour les identités
Authentification multi-facteurs (MFA)
Fédération d’identités (SSO)
Gestion du cycle de vie des comptes

Policy Engine

Le moteur de politiques décide qui accède à quoi :

Évaluation des attributs (identité, contexte, risque)
Politiques granulaires par ressource
Décision en temps réel
Logs de toutes les décisions

Micro-segmentation

La segmentation fine limite le rayon d’action :

Approche traditionnelle	Approche Zero Trust
VLANs larges	Segmentation par workload
Règles basées sur les IPs	Règles basées sur l’identité
Confiance implicite intra-VLAN	Vérification à chaque flux
Périmètre unique	Périmètres multiples

Proxy d’accès

Les proxies Zero Trust (ZTNA) remplacent le VPN traditionnel :

Accès aux applications, pas au réseau
Authentification et autorisation par session
Inspection du trafic
Pas d’exposition directe des applications

Scénario 1 : Le mouvement latéral

Un attaquant envoie un email de phishing à un employé. La pièce jointe installe un malware sur son poste.

Architecture périmétrique traditionnelle :

L’attaquant compromet le poste d’un employé
Il scanne le réseau interne (ports ouverts partout)
Il trouve un serveur de fichiers accessible sans authentification
Il exfiltre des données sensibles
Il pivote vers d’autres serveurs via les credentials cachés
Compromission totale en quelques heures

Architecture Zero Trust :

L’attaquant compromet le même poste
Le poste n’a accès qu’aux applications autorisées (via ZTNA)
Chaque application exige une ré-authentification MFA
Les flux inter-services sont authentifiés (mTLS)
Le comportement anormal déclenche une alerte
L’équipe sécurité isole le poste compromis

Le mouvement latéral est bloqué car chaque accès exige une vérification que l’attaquant ne peut pas fournir.

Scénario 2 : L’accès depuis l’extérieur

Un développeur en télétravail doit accéder à une application interne.

Approche VPN traditionnelle :

Connexion VPN → accès au réseau interne complet
Tout le trafic passe par le VPN (latence, bande passante)
Si le poste est compromis, l’attaquant a aussi accès
Pas de visibilité fine sur ce que fait l’utilisateur

Approche ZTNA (Zero Trust Network Access) :

Authentification forte (MFA) sur l’IdP
Vérification de la posture du poste (antivirus, patches)
Accès uniquement à l’application demandée
Session limitée dans le temps
Logs détaillés de toutes les actions

L’utilisateur n’accède qu’à ce dont il a besoin, pas à “tout le réseau”.

Comment implémenter Zero Trust

L’implémentation de Zero Trust est progressive. On ne passe pas d’un modèle périmétrique à Zero Trust en un jour.

Phase 1 : Cartographie

Inventorier tous les actifs, applications, flux de données
Identifier les données sensibles et leurs chemins d’accès
Documenter les flux existants entre applications

Phase 2 : Identité

Centraliser la gestion des identités (IdP unique)
Déployer l’authentification multi-facteurs
Fédérer les identités (SSO pour toutes les applications)

Phase 3 : Accès conditionnel

Définir des politiques basées sur le contexte
Implémenter l’accès conditionnel (identité + posture + localisation)
Limiter la durée des sessions et tokens

Phase 4 : Microsegmentation

Segmenter les workloads par criticité
Authentifier les flux entre services (mTLS)
Bloquer les flux non explicitement autorisés

Phase 5 : Monitoring continu

Logger toutes les décisions d’accès
Détecter les comportements anormaux
Automatiser les réponses aux incidents

Pièges courants

Le projet “Big Bang”

Vouloir tout transformer en Zero Trust d’un coup. C’est un changement progressif, application par application, flux par flux.

Zero Trust = ZTNA uniquement

Confondre Zero Trust avec les solutions commerciales de “Zero Trust Access”. Le modèle est architectural, pas un produit qu’on achète.

Oublier l’expérience utilisateur

Une authentification MFA demandée 50 fois par jour pousse les utilisateurs à chercher des contournements. L’équilibre sécurité/UX est crucial.

Ignorer les flux machine-to-machine

Se concentrer sur les utilisateurs humains et oublier que les services communiquent entre eux. Ces flux doivent aussi être authentifiés.

À retenir

La position réseau ne détermine pas la confiance — un attaquant dans le réseau interne doit être bloqué comme un attaquant externe.
Vérifier explicitement chaque accès — authentification et autorisation à chaque requête, pas juste à la connexion.
Appliquer le moindre privilège — accès uniquement aux ressources nécessaires, pas à “tout le réseau”.
Supposer la compromission — concevoir les défenses comme si l’attaquant était déjà présent.
Progression par étapes — cartographie, identité, accès conditionnel, microsegmentation, monitoring.
L’identité est le nouveau périmètre — les décisions reposent sur qui (identité) et quoi (contexte), pas où (réseau).

Liens utiles

Défense en profondeur — Plusieurs couches de protection
Moindre privilège — Fondement du Zero Trust