Communication sécurisée et zero trust

Pourquoi le périmètre réseau a cessé de fonctionner

Pendant des décennies, la plupart des organisations ont protégé leurs systèmes comme un château entouré de douves. Un pare-feu séparait l’intérieur de confiance de l’internet non fiable, le personnel se connectait à l’intérieur par un réseau privé virtuel (VPN), et tout ce qui se trouvait déjà à l’intérieur était considéré comme amical. Les services du centre de données s’appelaient les uns les autres en HTTP simple, sans authentification, car le réseau lui-même tenait lieu d’identifiant. Le chapitre 6 rangeait le réseau est sécurisé parmi les illusions de l’informatique distribuée ; le modèle périmétrique est cette illusion transformée en architecture.

Trois évolutions l’ont mis en échec. D’abord, l’intérieur est devenu trop vaste pour être défendu : les ordinateurs portables voyagent, le personnel travaille depuis chez lui, des partenaires se connectent, et un seul e-mail d’hameçonnage (phishing) ou un seul mot de passe VPN volé place un attaquant à l’intérieur des douves. Une fois là, l’attaquant se déplace de machine en machine, ce qu’on appelle le mouvement latéral. Lors de la violation de 2013 chez le distributeur américain Target, les attaquants ont d’abord utilisé des identifiants réseau volés à un sous-traitant en chauffage et ventilation, puis ont atteint de là les terminaux de paiement, emportant les données d’environ 40 millions de cartes. Ensuite, l’intérieur s’est dissous : les charges de travail tournent désormais sur plusieurs comptes cloud, des produits SaaS et des API tierces, si bien qu’il n’existe plus de mur unique sur lequel poser un pare-feu. Enfin, l’intérieur est devenu dynamique : des conteneurs apparaissent et disparaissent à chaque minute et les adresses IP sont réutilisées, si bien que des règles écrites sous la forme autoriser 10.0.4.0/24 à joindre 10.0.7.12 ne décrivent rien de stable.

L’idée qu’il faut abandonner le périmètre est plus ancienne que son nom. Le Jericho Forum, un groupe de responsables de la sécurité d’entreprises, plaidait pour la dépérimétrisation dès 2004 ; John Kindervag, alors analyste chez Forrester Research, a forgé l’expression zero trust vers 2010 ; et les articles de Google sur BeyondCorp, à partir de 2014, ont montré que l’approche fonctionnait à grande échelle. Le slogan est ne jamais faire confiance, toujours vérifier : aucune requête n’est considérée comme fiable en raison de sa provenance.

Le zero trust selon la définition du NIST

Le texte de référence est la publication spéciale 800-207 du NIST, Zero Trust Architecture, parue en août 2020 (Rose, Borchert, Mitchell et Connelly). Elle décrit le zero trust (confiance zéro) comme un ensemble de principes qui déplacent les défenses de périmètres statiques, fondés sur le réseau, vers les utilisateurs, les actifs et les ressources, et une architecture zero trust comme le plan d’une organisation pour les appliquer. Son affirmation centrale est qu’aucune confiance implicite n’est accordée à un actif ou à un compte utilisateur sur la seule base de son emplacement physique ou réseau, ni de son propriétaire. L’authentification et l’autorisation sont des fonctions distinctes, exécutées avant l’établissement d’une session vers une ressource.

La publication énonce sept principes. Ils méritent d’être connus dans leur formulation propre, car de nombreux produits se disent zero trust alors qu’ils n’en respectent qu’un ou deux.

Points de décision et d’application de politique

SP 800-207 décrit ce mécanisme à l’aide d’un petit ensemble de composants logiques. Un point d’application de politique (PEP) se place devant une ressource et ne laisse passer le trafic que sur instruction : en pratique, un proxy tenant compte de l’identité (identity-aware proxy), une API gateway, un sidecar de service mesh ou un proxy de base de données. Le point de décision de politique (PDP) prend la décision. Le NIST le divise en un moteur de politique, qui évalue la requête au regard de la politique et des données d’entrée et décide, et un administrateur de politique, qui exécute la décision en ouvrant ou en fermant le chemin, par exemple en émettant un jeton de session à courte durée de vie ou en configurant le PEP. Les données d’entrée comprennent le fournisseur d’identité, la posture de l’appareil et de la charge de travail (niveau de correctifs, configuration, intégrité), le renseignement sur les menaces, les politiques d’accès elles-mêmes et les journaux d’activité.

Séparer la décision de l’application est le même geste que séparer la politique du mécanisme dans les systèmes d’exploitation, et il est payant pour la même raison : les politiques peuvent être écrites une seule fois, revues, testées et modifiées de manière centralisée, tandis que l’application est répartie partout où circule le trafic. Les moteurs de politique de la section 8.3, comme Open Policy Agent, sont souvent le moteur qui se trouve derrière un PDP. La question de conception pour un architecte est de savoir où placer les points d’application pour qu’aucun chemin ne les contourne, et comment garder la décision rapide et disponible, car un PDP sur le chemin critique de chaque requête devient une dépendance avec son propre budget de disponibilité et de latence. Les réponses courantes consistent à mettre les décisions en cache pendant quelques secondes, à pousser des politiques compilées vers le PEP pour qu’il puisse décider localement, et à décider à l’avance de ce qui se passe si le PDP est injoignable (normalement refuser, avec une courte liste d’autorisations pour les contrôles de santé).

BeyondCorp : le zero trust pour les personnes

Google a commencé à abandonner son réseau d’entreprise privilégié après l’intrusion de 2009 connue sous le nom d’Opération Aurora, et en a décrit le résultat dans BeyondCorp: A New Approach to Enterprise Security (Rory Ward et Betsy Beyer, ;login:, décembre 2014), suivi de plusieurs autres articles. La conception comporte trois parties principales. Chaque appareil est enregistré dans un inventaire des appareils et identifié par un certificat. Un proxy d’accès, joignable depuis internet, se place devant chaque application interne ; les employés atteignent les applications à travers lui depuis n’importe quel réseau, y compris le réseau du bureau, qui ne bénéficie d’aucun privilège particulier. Un composant d’inférence de confiance combine l’identité de l’utilisateur et l’état de l’appareil pour attribuer un niveau de confiance, et chaque application déclare le niveau minimal qu’elle exige.

La conséquence qui a surpris a été la suppression du VPN : un employé dans un café et un employé à son bureau passent par les mêmes contrôles. L’idée est aujourd’hui vendue sous forme de produits appelés identity-aware proxy (proxy tenant compte de l’identité) et accès réseau zero trust (ZTNA). Le Zero Trust Maturity Model de l’agence américaine de cybersécurité et de sécurité des infrastructures (CISA) (version 2.0, avril 2023) est un outil d’autoévaluation utile : il note cinq piliers (identité, appareils, réseaux, applications et charges de travail, et données) de « traditionnel » à « optimal », avec la visibilité, l’automatisation et la gouvernance en transversal.

TLS mutuel, certificats et identité de charge de travail

Le zero trust entre services exige deux choses à chaque appel : le chiffrement, et une identité forte pour les deux extrémités. Transport Layer Security assure les deux. TLS 1.3 (RFC 8446, août 2018) achève sa poignée de main en un seul aller-retour : le client envoie les algorithmes qu’il prend en charge et une part de clé, le serveur répond avec sa part de clé et son certificat, et tous deux dérivent des clés de session par Diffie-Hellman éphémère, de sorte que chaque session bénéficie de la confidentialité persistante (forward secrecy : une clé de serveur volée ne permet pas de déchiffrer un trafic passé enregistré). TLS 1.3 a supprimé les options faibles des versions antérieures, dont l’échange de clés RSA, les chiffrements en mode CBC, RC4, les signatures SHA-1, la compression et la renégociation ; TLS 1.0 et 1.1 ont été formellement dépréciés par la RFC 8996 en 2021. Un mode facultatif sans aller-retour (0-RTT) permet à un client qui revient d’envoyer des données immédiatement, mais ces données précoces peuvent être rejouées par un attaquant : il faut donc les limiter aux requêtes idempotentes. Les principaux navigateurs et fournisseurs cloud ont aussi commencé à utiliser un échange de clés hybride post-quantique qui combine X25519 et ML-KEM (normalisé par le NIST sous le nom FIPS 203 en 2024), ce qui protège le trafic enregistré aujourd’hui contre un futur ordinateur quantique.

Un certificat lie une clé publique à un nom et est signé par une autorité de certification (CA) ; le client vérifie la chaîne de signatures jusqu’à une racine en laquelle il a déjà confiance. Ce système de CA, de certificats, de magasins de confiance et de révocation est une infrastructure à clés publiques (PKI). Les certificats publics sont aussi inscrits dans des journaux Certificate Transparency, si bien qu’un certificat émis à tort pour votre domaine peut être repéré. Le HTTPS ordinaire n’authentifie que le serveur. Avec le TLS mutuel (mTLS), le client présente lui aussi un certificat, et le serveur apprend ainsi quelle charge de travail l’appelle. Les certificats internes proviennent d’une CA privée gérée par l’organisation, en général au sein de sa plateforme de secrets ou de service mesh, car les CA publiques n’émettent pas de certificats pour des noms internes.

Quel nom mettre dans le certificat ? Les noms d’hôte et les adresses IP sont de piètres identités pour des conteneurs. SPIFFE (Secure Production Identity Framework for Everyone, projet diplômé de la Cloud Native Computing Foundation) normalise l’identité de charge de travail : chaque charge de travail reçoit une URI comme spiffe://fooddelivery.example/ns/prod/sa/orders et un SPIFFE Verifiable Identity Document à courte durée de vie, soit un certificat X.509 pour le mTLS, soit un JWT. Son implémentation de référence, SPIRE, atteste une charge de travail (vérifie de quel compte de service Kubernetes ou de quelle instance cloud il s’agit réellement) avant d’émettre le document, et en assure la rotation automatiquement, en général toutes les heures environ. Les règles d’autorisation peuvent alors dire orders peut appeler payments au lieu de désigner des adresses.

Les service meshes

Implémenter le mTLS, la rotation des certificats, les nouvelles tentatives et l’autorisation par appel dans chaque service, dans chaque langage, coûte cher et donne des résultats incohérents. Un service mesh (maillage de services) déplace ce travail dans l’infrastructure. Dans la conception classique, chaque instance de service reçoit un proxy sidecar (Envoy dans Istio, un micro-proxy en Rust dans Linkerd) qui intercepte son trafic ; un plan de contrôle émet les identités, distribue les politiques et collecte la télémétrie. Des conceptions plus récentes sans sidecar, comme le mode ambient d’Istio, confient le mTLS à un proxy partagé par nœud et n’ajoutent un proxy distinct que là où une politique au niveau HTTP est nécessaire. NIST SP 800-207A (septembre 2023) décrit ce patron comme la manière d’appliquer le zero trust aux applications cloud native : une segmentation fondée sur l’identité, avec des politiques appliquées par le service mesh à chaque appel.

Un service mesh est une décision de plateforme importante. Il ajoute de la latence à chaque saut (généralement faible, mais mesurable au p99), de la mémoire par pod, un plan de contrôle qui doit lui-même être hautement disponible et sécurisé, et une courbe d’apprentissage pour chaque équipe. Il ne protège en outre que le trafic qui le traverse : un traitement qui se connecte directement à la base de données le contourne. Les petits systèmes de quelques services s’en sortent souvent mieux avec un mTLS fourni par une bibliothèque ou par les équilibreurs de charge de la plateforme. Les questions décisives sont le nombre de services et de langages que vous avez, et l’existence ou non d’une équipe plateforme pour l’exploiter (voir la section 10.7).

Automatiser les certificats

Les certificats expirent, et les certificats expirés sont l’une des causes les plus courantes de pannes évitables. Le 6 décembre 2018, un certificat expiré dans un logiciel Ericsson utilisé par l’opérateur mobile britannique O2 a privé environ 32 millions de clients de données mobiles pendant la majeure partie d’une journée. Le remède est l’automatisation. Le protocole ACME (Automatic Certificate Management Environment, RFC 8555, 2019), développé pour l’autorité de certification Let’s Encrypt, permet à un logiciel de prouver qu’il contrôle un domaine (en servant un jeton en HTTP, en ajoutant un enregistrement DNS ou en répondant à un défi TLS), d’obtenir un certificat et de le renouveler sans intervention humaine. Let’s Encrypt, une CA gratuite et à but non lucratif qui a commencé à émettre des certificats en 2015, a fait des certificats à courte durée de vie renouvelés automatiquement la norme ; des outils comme cert-manager font de même dans Kubernetes, et tous les grands équilibreurs de charge cloud peuvent gérer les certificats pour vous.

L’automatisation n’est plus facultative. En vertu du vote SC-081 du CA/Browser Forum, la durée de vie maximale des certificats TLS reconnus publiquement est passée à 200 jours pour les certificats émis à partir du 15 mars 2026, et passera à 100 jours à partir du 15 mars 2027 et à 47 jours à partir du 15 mars 2029. Des durées de vie courtes limitent les dégâts d’une clé volée et réduisent la dépendance à la révocation, qui a toujours mal fonctionné. Sur le plan de l’architecture, cela signifie que chaque certificat, public ou interne, a besoin d’un propriétaire, d’un renouvellement automatisé, d’une surveillance des dates d’expiration avec des alertes bien avant l’échéance, et d’une procédure manuelle de secours répétée.

Segmentation et microsegmentation

Le zero trust ne signifie pas que le réseau ne compte plus ; il signifie que le réseau n’est plus le seul contrôle. La segmentation du réseau divise l’infrastructure en zones reliées par des chemins contrôlés : sous-réseaux publics pour les équilibreurs de charge, sous-réseaux privés pour les services, sous-réseaux isolés pour les bases de données, et comptes cloud séparés pour la production, le staging et les outils de sécurité. La microsegmentation réduit les zones à des charges de travail individuelles, de sorte que chaque service ne peut recevoir du trafic que des appelants dont il a besoin et n’en envoyer qu’à ses dépendances déclarées.

Dans Kubernetes, tous les pods peuvent joindre tous les autres pods, sauf si des ressources NetworkPolicy les en empêchent ; la première étape est donc une politique de refus par défaut pour chaque namespace, suivie d’autorisations explicites. Le contrôle du trafic sortant (egress) compte autant que celui du trafic entrant (ingress) : un service compromis qui ne peut pas ouvrir de connexions vers internet ne peut pas facilement exfiltrer des données volées ni télécharger d’autres outils. Les groupes de sécurité cloud, les network policies Kubernetes et les politiques d’autorisation du service mesh agissent à des couches différentes (adresses et ports, pods et labels, identités de charge de travail et méthodes HTTP) et s’utilisent au mieux ensemble : les couches extérieures donnent une protection grossière qui survit à une erreur de configuration du service mesh, la couche intérieure exprime l’intention avec précision. C’est la défense en profondeur (section 8.1) appliquée au réseau.

Sécuriser l’API gateway

L’API gateway (passerelle d’API) est le principal point d’application entre internet et les services ; elle assume donc plusieurs fonctions. Authentification : terminer le TLS, puis valider chaque jeton d’accès (signature avec un algorithme imposé, émetteur, audience, expiration et date de début de validité), rejeter les requêtes qui n’en ont pas, et transmettre aux services une identité vérifiée, jamais les affirmations brutes du client. Limitation de débit : limiter les requêtes par client, par utilisateur et par route, généralement avec un token bucket (seau à jetons), en répondant HTTP 429 avec un en-tête Retry-After ; des limites distinctes, plus strictes, protègent la connexion, la réinitialisation du mot de passe et l’utilisation des bons de réduction contre le bourrage d’identifiants (credential stuffing) et l’énumération. Validation des entrées : imposer des tailles de requête et des nombres d’en-têtes maximaux, n’accepter que les types de contenu déclarés, et valider les corps de requête par rapport au schéma OpenAPI pour que les requêtes malformées n’atteignent jamais un service. Un pare-feu applicatif web (WAF) peut ajouter des signatures d’attaque génériques, mais c’est un complément, pas un substitut à un code correct.

Sachez ce qu’une passerelle ne peut pas faire. Elle voit la route et le jeton, mais pas si la commande 81723 appartient au client qui la demande. La faille d’autorisation au niveau des objets (broken object level authorisation), où un utilisateur modifie un identifiant dans l’URL et lit les données de quelqu’un d’autre, figure en première place de l’OWASP API Security Top 10 dans ses éditions 2019 et 2023, et seul le service qui possède les données peut l’empêcher. Les services doivent donc autoriser eux-mêmes chaque requête, à l’aide de l’identité vérifiée que transmet la passerelle. Quand un service en appelle un autre pour le compte d’un utilisateur, il doit transmettre un jeton qui nomme à la fois l’utilisateur et le service appelant, obtenu par exemple par l’échange de jetons OAuth 2.0 (RFC 8693), plutôt que son propre identifiant tout-puissant ; sinon, un bogue dans un service en fait un député confus (confused deputy) capable d’agir pour n’importe qui.