Zero Trust : ne fais confiance à personne

Pourquoi le modèle périmétrique ne protège plus rien

Pendant des décennies, la sécurité réseau reposait sur un principe simple : l’intérieur est sûr, l’extérieur est hostile. Un firewall en bordure, un VPN pour les accès distants, et tout ce qui se trouvait “dedans” était considéré de confiance. Ce modèle du château fort a fonctionné — tant que le château existait vraiment.

Aujourd’hui, ce périmètre a volé en éclats. Le cloud multi-provider distribue les workloads partout. Le SaaS place les données hors de ton réseau. Le télétravail et le BYOD font que les employés se connectent depuis n’importe où, sur n’importe quel device. Et surtout, les attaques modernes ne cherchent plus à forcer le périmètre — elles cherchent à le contourner.

🔥 Cas réel : L’attaque SolarWinds (2020) est l’illustration parfaite de la faillite du modèle périmétrique. Les attaquants ont compromis le mécanisme de mise à jour d’un logiciel de monitoring utilisé par 18 000 organisations, dont des agences gouvernementales américaines. L’attaque venait de l’intérieur — via un logiciel légitime, signé, installé par les équipes elles-mêmes. Aucun firewall n’aurait pu l’arrêter.

Le problème fondamental du modèle périmétrique tient en un mot : lateral movement. Une fois qu’un attaquant est à l’intérieur du réseau (via phishing, supply chain, insider threat), il se déplace librement entre les services. Selon le rapport Verizon DBIR, 34% des breaches impliquent des acteurs internes. Le périmètre n’est plus une ligne de défense — c’est une illusion de sécurité.

Zero Trust : les trois piliers fondamentaux

Le Zero Trust n’est pas un produit qu’on achète et qu’on installe. C’est une architecture et une philosophie de sécurité. Le terme a été formalisé par John Kindervag chez Forrester en 2010, puis popularisé par Google avec le projet BeyondCorp à partir de 2014.

Trois piliers structurent l’approche :

Never Trust, Always Verify — Aucune entité (utilisateur, service, device) n’est de confiance par défaut, qu’elle soit à l’intérieur ou à l’extérieur du réseau. Chaque requête est authentifiée et autorisée individuellement.

Least Privilege — Chaque entité reçoit le minimum d’accès nécessaire pour accomplir sa tâche, pour la durée minimale nécessaire. C’est le principe du just-in-time, just-enough access.

Assume Breach — Tu conçois ton architecture en partant du principe que l’attaquant est déjà à l’intérieur. Chaque service se protège individuellement, comme si les autres étaient compromis.

Pour implémenter ces piliers, une architecture Zero Trust s’appuie sur cinq composants complémentaires :

## Les 5 composants d'une architecture Zero Trust

Identity     → Authentification forte de chaque requête
               (OAuth2, OIDC, certificats X.509, SPIFFE)

Device       → Vérification de la posture du device
               (MDM, device attestation, certificat machine)

Network      → Micro-segmentation et chiffrement en transit
               (mTLS, WireGuard, Network Policies Kubernetes)

Application  → Autorisation fine-grained par requête
               (OPA/Rego, RBAC, ABAC, policies as code)

Data         → Classification et protection des données
               (DLP, encryption at rest, tokenization)

🧠 À retenir : Le Zero Trust ne remplace pas ton firewall — il le complète. Tu gardes la défense en profondeur (firewalls, WAF, IDS), mais tu ne fais plus confiance au réseau interne comme périmètre de sécurité.

L’architecture Zero Trust en pratique

Le cœur d’une architecture Zero Trust repose sur deux composants clés qui travaillent ensemble : le Policy Decision Point (PDP) et le Policy Enforcement Point (PEP).

Le PDP est le cerveau du système. Pour chaque requête, il évalue l’identité (qui fait la requête ?), le contexte (depuis quel device ? quel réseau ? quelle heure ?), le score de risque (calculé dynamiquement) et les politiques définies dans le Policy Store. Il rend un verdict : allow ou deny.

Le PEP est le muscle. Il intercepte chaque requête, consulte le PDP et applique la décision. Concrètement, le PEP peut prendre la forme d’un reverse proxy (Envoy, Nginx avec auth_request), d’un sidecar dans un service mesh (Istio, Linkerd) ou d’un identity-aware proxy (Google IAP, Cloudflare Access, Pomerium).

Voici comment ça se traduit dans un flux concret avec Pomerium, un identity-aware proxy open-source :

# pomerium-config.yaml — Identity-Aware Proxy
routes:
  - from: https://app.internal.company.com
    to: http://app-service:8080
    policy:
      - allow:
          and:
            - email:
                is: user@company.com
            - claim/groups:
                has: engineering
            - device:
                is:
                  approved: true

  - from: https://admin.internal.company.com
    to: http://admin-service:8080
    policy:
      - allow:
          and:
            - claim/groups:
                has: platform-team
            - device:
                is:
                  approved: true
            - accept: true  # MFA step-up requis

Chaque requête qui arrive sur app.internal.company.com est interceptée par Pomerium. L’utilisateur doit être authentifié (email vérifié), appartenir au groupe engineering et utiliser un device approuvé. Si l’une de ces conditions n’est pas remplie, la requête est rejetée — même depuis le réseau interne.

💡 Tip DevOps : Commence par les applications les plus sensibles (admin panels, bases de données, CI/CD) et étends progressivement. Migrer 100% du trafic vers Zero Trust d’un coup est irréaliste — priorise par niveau de risque.

BeyondCorp : comment Google a tué le VPN

En 2009, Google a subi l’opération Aurora — une attaque sophistiquée attribuée à des acteurs étatiques qui a compromis des systèmes internes. En réponse, Google a lancé le projet BeyondCorp avec un objectif radical : supprimer toute notion de réseau de confiance.

Les principes BeyondCorp sont devenus la référence de l’industrie. Premier principe : l’accès ne dépend pas du réseau. Pas de VPN, pas de “réseau de confiance”. Un employé au bureau et un employé dans un café ont exactement le même niveau d’accès — zéro, tant qu’ils ne sont pas authentifiés. Deuxième principe : l’accès dépend de l’identité ET du device. L’utilisateur doit être authentifié, son device doit être géré et sa posture de sécurité vérifiée. Troisième principe : chaque accès est authentifié, autorisé et chiffré, même entre services internes. Quatrième principe : l’accès est dynamique et contextuel, réévalué à chaque requête.

La vérification du device (Device Trust) est un pilier souvent sous-estimé. Un utilisateur authentifié sur un device compromis reste un vecteur d’attaque majeur :

# Ce que le Device Trust Engine évalue avant chaque accès :

OS à jour ?              → Patch level vérifié contre les CVE critiques
Disque chiffré ?         → FileVault (macOS), BitLocker (Windows), LUKS (Linux)
EDR/Antivirus actif ?    → CrowdStrike, SentinelOne, Defender
Screen lock activé ?     → Timeout < 5 min
Certificat device ?      → Certificat machine délivré par la PKI interne
Inventaire MDM ?         → Device enregistré dans Jamf, Intune, etc.

# Si le device échoue un check → accès restreint ou bloqué
# Même si l'utilisateur est CEO avec un badge MFA

⚠️ Attention : Le Zero Trust ne signifie pas “bloquer tout par défaut et voir qui se plaint”. Une implémentation mal pensée paralyse la productivité. La clé est l’automatisation des vérifications : l’utilisateur ne doit pas sentir la friction si tout est en ordre.

Bonnes pratiques et pièges à éviter

Commence petit, itère souvent. Ne cherche pas à tout migrer en Zero Trust d’un coup. Commence par un cas d’usage précis (accès SSH aux serveurs, accès aux dashboards internes) et étends progressivement.

Investis dans l’identité d’abord. Sans une source d’identité solide (IdP bien configuré, MFA enforced, service accounts avec des SPIFFE IDs), rien d’autre ne tient. L’identité est la fondation du Zero Trust.

Automatise les policies as code. Les politiques d’accès doivent vivre dans Git, être revues en PR et déployées via CI/CD — exactement comme ton infrastructure. OPA/Rego est le standard de facto pour ça :

# policy.rego — Exemple OPA pour autoriser l'accès
package authz

default allow = false

allow {
    input.method == "GET"
    input.path == ["api", "v1", "public"]
}

allow {
    input.method == "POST"
    input.path == ["api", "v1", "orders"]
    token.payload.groups[_] == "order-writers"
    token.payload.device_trust == true
}

token := {"payload": payload} {
    [_, payload, _] := io.jwt.decode(input.token)
}

Monitore et audite tout. Chaque décision d’accès (allow et deny) doit être loguée. Ces logs sont ta source de vérité pour détecter les anomalies, les tentatives de lateral movement et les violations de politique.

🔥 Cas réel : Quand Cloudflare a été ciblé par la même campagne de phishing que Twilio en 2022 (attaque Oktapus), leurs clés de sécurité physiques (FIDO2) et leur architecture Zero Trust ont bloqué l’attaque. Les attaquants avaient les mots de passe et les codes OTP — mais pas les clés physiques requises par le Device Trust. Bilan Cloudflare : 0 compromission. Bilan Twilio : 163 comptes clients affectés.

Résumé — Ce qu’il faut retenir

🧠 À retenir :

• Le modèle périmétrique (firewall + VPN = sécurité) est mort — le cloud, le télétravail et les supply chain attacks l’ont rendu obsolète
• Le Zero Trust repose sur trois piliers : Never Trust Always Verify, Least Privilege, Assume Breach
• L’architecture s’appuie sur un Policy Decision Point (décide) et un Policy Enforcement Point (applique) — souvent implémentés via un identity-aware proxy ou un service mesh
• BeyondCorp de Google est la référence : pas de VPN, accès basé sur l’identité + device trust + contexte, réévalué à chaque requête
• Le Device Trust est aussi important que l’authentification utilisateur — un user authentifié sur un device compromis reste un risque
• Commence par l’identité (IdP + MFA), puis étends aux policies as code (OPA), puis au mTLS et à la micro-segmentation