Zero Trust Architecture

« Never trust, always verify. » Plus de zone de confiance — chaque connexion est traitée comme si elle venait d'Internet, même quand c'est le cas.

Problème

Le modèle « château-fort » (firewall périmétrique → réseau interne de confiance) s'effondre dans le monde cloud / SaaS / partenaires extérieurs. Un attaquant qui obtient un accès interne (phishing employé, container compromis, supply chain) circule librement. Les fuites massives (Target 2013, OPM 2015, SolarWinds 2020) ont toutes exploité un périmètre poreux.

Forces

• Le périmètre réseau a disparu (cloud, BYOD, partenaires, SaaS).
• L'attaquant interne (ou compromis interne) est de plus en plus fréquent.
• Le chiffrement bout-en-bout devient bon marché (mTLS, JWT, OIDC).
• Le coût d'une politique granulaire (« qui peut faire quoi ») est désormais soutenable grâce aux IDP modernes.
• NIST SP 800-207 (août 2020) formalise les principes pour les organismes fédéraux US ; OMB M-22-09 (2022) en fait une obligation.

Solution

Tout accès passe par un Policy Enforcement Point (PEP) qui interroge un Policy Decision Point (PDP) à chaque requête. La décision est basée sur l'identité (utilisateur + appareil + workload), l'attribut de la ressource demandée, et le contexte (heure, géolocalisation, niveau de risque). La connexion est toujours chiffrée (mTLS, TLS 1.3). L'identité est forte (MFA, certificats device-bound). L'autorisation est minimaliste et révocable instantanément. La micro-segmentation réseau renforce le tout côté infrastructure.

Sept piliers NIST

1. Toutes les sources de données et services sont des ressources.
2. Toutes les communications sont sécurisées, peu importe la localisation réseau.
3. Accès accordé par session, avec moindre privilège.
4. Accès déterminé par politique dynamique (identité, posture appareil, comportement).
5. Posture monitoring et mesure d'intégrité de tous les actifs.
6. Authentification et autorisation dynamiques avant chaque accès.
7. Collecte de logs granulaire pour améliorer la politique en boucle.

Implémentation EDI

Un hub EDI expose des endpoints AS2/AS4/SFTP à des centaines de partenaires. Sous Zero Trust : (a) mTLS sur tous les endpoints, avec certificats spécifiques par partenaire (rotation 90 j) ; (b) politiques d'accès par partenaire — Walmart ne peut envoyer que des INVOIC, Stellantis que des DESADV ; (c) monitoring des patterns inhabituels (volumes 10x, horaires anormaux) avec quarantaine automatique ; (d) ZTNA pour l'accès des admins (BeyondCorp / Cloudflare Access / Tailscale) — plus de VPN-périmètre. Conséquence : un certificat partenaire compromis ne donne accès qu'à ses propres flux.

Anti-patterns

• « Zero Trust » comme étiquette marketing alors qu'on garde un firewall périmétrique unique — théâtre de sécurité.
• Politiques statiques sans contexte (heure, géolocalisation, risk score) — granularité trop grossière.
• PEP centralisé non répliqué — SPOF.
• Logs sans rétention ni analyse — boucle de feedback brisée.
• Adoption all-or-nothing — laisser des poches « legacy non-ZT » exploitables.

Patterns liés

• Defense in Depth — Zero Trust est une instance moderne du principe.
• Least Privilege — pilier 3 de NIST SP 800-207.
• Mutual TLS — brique cryptographique du Zero Trust.
• Service Mesh — l'enabler côté infrastructure.

Sources

• NIST SP 800-207 — Zero Trust Architecture, août 2020. NIST SP 800-207 PDF
• Google BeyondCorp — A New Approach to Enterprise Security. research.google/pubs/pub43231/
• Kindervag J. — No More Chewy Centers: Introducing The Zero Trust Model of Information Security, Forrester 2010.
• OMB M-22-09 — Federal Zero Trust Architecture Strategy, janvier 2022.