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

Erreur fréquente

Penser que Zero Trust = “ne pas avoir de VPN”. Zero Trust est un modèle de vérification continue, pas une suppression des contrôles d’accès réseau.

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 :

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

Architecture Zero Trust :

1. L’attaquant compromet le même poste
2. Le poste n’a accès qu’aux applications autorisées (via ZTNA)
3. Chaque application exige une ré-authentification MFA
4. Les flux inter-services sont authentifiés (mTLS)
5. Le comportement anormal déclenche une alerte
6. 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 :

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

Approche ZTNA (Zero Trust Network Access) :

1. Authentification forte (MFA) sur l’IdP
2. Vérification de la posture du poste (antivirus, patches)
3. Accès uniquement à l’application demandée
4. Session limitée dans le temps
5. 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

1. La position réseau ne détermine pas la confiance — un attaquant dans le réseau interne doit être bloqué comme un attaquant externe.

2. Vérifier explicitement chaque accès — authentification et autorisation à chaque requête, pas juste à la connexion.

3. Appliquer le moindre privilège — accès uniquement aux ressources nécessaires, pas à “tout le réseau”.

4. Supposer la compromission — concevoir les défenses comme si l’attaquant était déjà présent.

5. Progression par étapes — cartographie, identité, accès conditionnel, microsegmentation, monitoring.

6. 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