Introduction à Zero Trust 

Au commencement, l’Internet était plat. Chaque équipement possédait une adresse IP publique. Il suffisait d’un xhost + ou d'un .rhosts mal configuré pour se connecter à distance sur un serveur (légitimement… ou pas). Cet âge d’or réminiscent n’est pas si lointain ; si vous avez connu le modem « SpeedTouch USB » (aussi appelé « la Raie Manta ») au début des années 2000, votre ordinateur domestique a lui aussi été exposé à Internet. À cette époque, son espérance de vie était d’environ 7 minutes – en partie à cause des vers Code Red, Blaster et Sasser, mais surtout parce que la connexion à distance était possible pour les comptes sans mot de passe (cas fréquent chez les particuliers). Ce n’est plus le cas aujourd’hui fort heureusement, même si les mots de passe faibles sur les comptes disposant d'un accès RDP restent une source majeure de compromission…

Puis sont arrivées les douves et les fortifications : pare-feu et serveur mandataire (dont l’invention a été – comme celle d’Internet – attribuée a posteriori à un français), zones démilitarisées (DMZ), translation d’adresse (NAT)… La sécurité d’un réseau se mesure à son nombre de VLAN. Le cloisonnement devient la réponse universelle à tous les problèmes de sécurité.

Enfin, le troisième âge : HTTP. Fini RMI, CORBA, et autres protocoles exotiques à base de XML et de ports dynamiques. HTTP devient le protocole de transport universel, au point d’être utilisé aujourd’hui pour transporter des informations de couche inférieure, par exemple « DNS-over-HTTPS » (DoH). Combiné à TLS 1.3 qui interdit par conception toute interception de flux, il faut se rendre à l’évidence : le réseau est devenu opaque aux équipements de sécurité. Aujourd’hui, Internet se compose d’équipements (ordinateurs, ordiphones ou cyber gadgets) connectés entre eux via HTTP, et la sécurité ne peut se concevoir qu’au niveau des équipements terminaux (client comme serveur).

1. Une brève histoire du Zero Trust

Le concept de « Zero Trust » a été inventé par Google vers 2009, dans le cadre du projet « BeyondCorp » qui a fait suite à la vague d’attaques « Aurora ».

Dans un souci d’impartialité historique, il ne faut toutefois pas manquer de citer les travaux de feu le Jericho Forum qui vantait les vertus de la « dépérimétrisation » dès 2004. Le sujet a même été présenté lors de la conférence française SSTIC 2008 par Cédric Blancher [1] (un auteur historique et prolifique du magazine MISC).

Un peu plus tard, Microsoft mettait en avant le concept « Assume Breach ». La communauté sécurité s’amusait du fait « qu’il n’y a que deux catégories d’entreprises : celles qui sont piratées, et celles qui ne le savent pas encore ». En un mot, que la sécurité est un échec et qu’il ne faut faire confiance ni aux utilisateurs, ni aux machines.

Ne connaissant pas de traduction officielle du terme « Zero Trust », et dans la plus pure tradition du cinéma français**, je vous propose donc de franciser ce concept sous le nom de « Trust Nothing ».

2. Principes fondamentaux

Comme son nom l’indique, dans le modèle « Zero Trust », la notion de réseau de confiance (souvent assimilé au réseau « Corporate ») n’existe plus. Il n’est pas possible de prendre une décision de sécurité sur la base du point d’attachement du terminal. Celui-ci peut être un ordiphone privé de connexion Wi-Fi qui revient par un réseau cellulaire public, ou un ordinateur portable en situation de travail à domicile (situation qui est passée de visionnaire en 2009 à vivement recommandée de nos jours).

Historiquement, les entreprises ont déployé des réseaux privés virtuels (VPN) pour répondre à ce besoin. Mais cette solution montre rapidement ses limites :

• L’authentification de l’utilisateur est décorrélée de son authentification sur les applications cibles. Le partage (ou le vol) de secrets entre plusieurs utilisateurs est possible ; c’est ainsi qu’on trouve sur Internet des webcams filmant le mot de passe à usage unique dispensé par une clé RSA Secure Access.
• Les concentrateurs VPN sont des points de panne uniques (SPOF), aussi bien en termes de débit que de sécurité. Aucune marque de concentrateur VPN ayant fait l’objet de plusieurs alertes de sécurité critiques ne sera citée afin de protéger les innocents.
• Le VPN ajoute une couche de complexité : client logiciel spécifique à mettre à jour régulièrement, latence accrue (parfois insupportable en vidéoconférence), consommation énergétique accrue sur les équipements mobiles, connexion impossible lorsque les ports ou protocoles requis sont filtrés par un point d’accès Wi-Fi un peu trop strict (ex. hôtel), déconnexions intempestives…
• Les utilisateurs oublient de « monter » le VPN et se retrouvent avec du trafic en clair sur leur réseau local d’attachement (parfois non sécurisé).

À l’inverse, les stagiaires, prestataires et autres personnels temporaires sur site se retrouvent connectés au réseau interne de l’entreprise (sans VPN) et disposent d’un accès souvent trop large aux ressources internes, alors qu’une bonne politique de sécurité se fonde sur le principe du moindre privilège.

Finalement, la démocratisation du Cloud donne le coup de grâce aux architectures réseau traditionnelles. Désormais les ressources de l’entreprise sont exposées sur Internet derrière des adresses IP publiques dynamiques, du moins lorsque ces ressources sont servies par des grappes de conteneurs.

Il est donc clair que le VPN est un échec, et que le moyen d’accès au réseau ne peut pas être utilisé comme critère de sécurité. Une sécurité moderne et efficace doit respecter a minima les principes suivants :

• Tout le trafic est chiffré par défaut. La sécurité ne doit pas reposer sur une action explicite de l’utilisateur.
• Le chiffrement est efficace et transparent pour l’utilisateur. Transporter du HTTPS à l’intérieur d’un tunnel IPSEC ou HTTPS ne fait que doubler la consommation énergétique et la latence, ce qui est peu efficace. À l’inverse, le mode 0-RTT de TLS 1.3, ou les modes de chiffrement AES en « streaming » rendent le chiffrement quasiment invisible.
• Le terminal et l’utilisateur bénéficient tous les deux d’une authentification forte. Leur identité est par exemple attestée par des clés privées stockées dans des composants matériels.
• Le contrôle d’accès est implémenté au plus près de la ressource accédée, plutôt que dans un équipement intermédiaire lointain (comme un pare-feu). C’est le concept de micro-segmentation ; il n’y a plus de réseau « à plat » dans lequel disposer d’une adresse IP permettrait magiquement d’accéder à toutes les autres ressources du même sous-réseau.

3. Implémentation

3.1 Identité

« Zero Trust » n’est pas un produit, c’est un processus (comme toute mesure de sécurité efficace). Désolé, mais vous ne pourrez donc pas déployer une magicoboîte (traduction non officielle de « appliance ») qui vous fera passer dans le monde merveilleux du « Zero Trust ».

La première brique de base du « Zero Trust » est de fournir une identité forte à tous les équipements et utilisateurs de votre système d’information. Nous avons tous appris à la dure que la carte n’est pas le territoire : les attaquants qui ont passé un coup de nmap sur votre réseau ont une meilleure visibilité sur votre infrastructure que votre administrateur réseau et son fichier Visio généré à partir d’une feuille Excel basée sur les inventaires de l’année dernière. Il est donc temps de passer à une approche par autorisation explicite (anciennement appelée « whitelisting », bien que ce terme ne soit plus très populaire) : tout le monde est autorisé à se connecter au système d’information, pourvu qu’il dispose d’un certificat client. Dès lors il est facile d’énumérer la liste des certificats actifs/expirés/révoqués, ainsi que la date à laquelle ils ont été « vus » sur le réseau pour la dernière fois.

C’est ce que propose en substance le protocole 802.1x, sauf que celui-ci est négocié au point d’attachement réseau. Dès que l’équipement est en situation de mobilité hors de son réseau mère, la propagation de l’identité devient plus problématique. En utilisant un certificat au niveau de la couche HTTP et non plus Ethernet, l’équipement possède désormais une identité universelle à l'échelle de la planète. Mais si vous avez réussi à déployer 802.1x, alors déployer une autre forme d'identité machine ne devrait pas être trop difficile.

Les identités sont des biclés, dont il convient de protéger la partie privée. De nos jours, le stockage sécurisé de ces informations ne pose plus trop de problèmes : TPM 2.0 sur tous les PC Windows récents, puce de sécurité « T2 » dans la Touch Bar du MacBook et dans les iDevices, TEE dans les téléphones Android, et clé de sécurité U2F pour les identités utilisateurs (il en existe aussi bien en USB-A qu’en USB-C ou Bluetooth Low Energy). Oubliez les projets complexes et coûteux nécessitant une carte à puce externe.

3.2 Serveur mandataire

Dans le modèle « Zero Trust », le serveur mandataire est la clé de voûte de la sécurité. En effet, c’est lui qui authentifie l’utilisateur et accorde l’accès aux ressources selon le niveau de risque instantané. Le serveur peut par exemple demander à l’utilisateur de ressaisir son mot de passe, ressaisir son mot de passe + utiliser sa clé U2F (par exemple pour l’accès à un site sensible tel que les données RH), ou simplement refuser l’accès.

La politique de sécurité est gérée par ressource, contrairement à l’ancien modèle « VPN » où le contrôle d’accès fonctionne en « tout ou rien ». La réauthentification de l’utilisateur est basée sur la « fraîcheur » de sa session. En clair : l’utilisateur s’identifie une fois par jour plutôt qu’une fois par application. Ai-je réussi à susciter votre intérêt pour le modèle « Zero Trust » ?

Bien entendu, cela suppose que (1) toutes les applications soient accessibles en mode Web et n’utilisent pas de client « lourd » ainsi que (2) toutes les applications acceptent de déléguer l’authentification et la gestion des utilisateurs à une base externe. Ce qui n’est pas forcément le cas avec les applications « historiques » (traduction de « legacy ») qu’on trouve dans les entreprises ayant un système d’information fossile…

Notons que le moteur de calcul des risques utilisé par Google n’est pas disponible publiquement. Il constitue une bonne partie du savoir-faire destiné à limiter les risques de compromission de compte malgré la faiblesse des mots de passe et des pratiques utilisateurs, dans un contexte B2C où il est difficile d’imposer des règles de complexité et de rotation des mots de passe.

Chez Google, le serveur mandataire se nomme « Uberproxy ». Vous le trouverez sur Internet ; n’hésitez pas à y chercher des bugs et à les remonter via le programme de Bug Bounty – votre fortune est assurée ;)

4. En pratique

4.1 Documents de référence

Le concept de « Zero Trust » est si populaire de nos jours que le NIST lui a dédié la publication spéciale SP 800-207. Bien qu’à l’état de brouillon à la date de rédaction de cet article, et très orientée sur les problématiques du gouvernement américain, sa lecture reste intéressante, car ce document va probablement influencer les offres commerciales.

4.2 Logiciels de référence

Je ne vais pas m’étendre sur les logiciels (gratuits, libres, et/ou commerciaux), car c’est un domaine foisonnant que je connais peu. Notons encore une fois que le « Zero Trust » est plus un chemin qu’une destination et qu’il ne se résume généralement pas au déploiement d’un logiciel.

4.3 Direct Access

Bien que n’adhérant pas strictement au modèle, il faut citer le protocole Direct Access proposé par Microsoft depuis Windows 2008 R2. Le principe est d'accéder aux ressources par leur adresse IPv6. La connectivité est assurée de manière transparente aussi bien à l’intérieur du réseau « mère » qu’à l’extérieur, par l’encapsulation IPv6 dans UDPv4 au besoin ; il n’y a donc plus de VPN à « monter ». L’authentification et le chiffrement sont fournis « gratuitement » par la couche transport, via IPSEC.

À terme, les couches d’encapsulation devaient disparaître (dans un futur alternatif où l’Internet serait 100% IPv6). Le concept est très proche de celui de « BeyondCorp », malheureusement IPv6 n’a pas connu le succès de HTTP et les protocoles de transition sont parfois bloqués sur des réseaux qu’on pourrait qualifier de « non neutres » tels que les points d’accès Wi-Fi publics.

4.4 Cloud IAP

Cloud IAP (« Identity-Aware Proxy ») est l’implémentation interne de la philosophie « Zero Trust » par Google, offerte en tant que produit Cloud. Mon propos n'est pas d'en faire la promotion, mais vous pourrez aisément tester la solution en utilisant les $300 de crédits Cloud gratuits.

Ce socle de base est complété par de nombreux produits tiers fédérés au sein de la « BeyondCorp Alliance ». Le rôle de ces produits est d'aider au calcul de risque par la remontée d'informations environnementales sur la posture de sécurité du client.

5. Conclusion

5.1 Beyond Beyond Corp : Beyond Prod

« BeyondProd » est le modèle « BeyondCorp » appliqué aux microservices. En substance, chaque microservice possède une identité forte et ne fait pas confiance de manière implicite aux autres microservices, y compris au sein de la même application. Chaque appel de fonction est authentifié et se voit appliquer une politique de sécurité dynamique.

Ces concepts sont implémentés nativement dans le triptyque Kubernetes / Istio / Envoy, où toutes les communications sont protégées par authentification TLS mutuelle, et une politique de sécurité explicite (sous la forme d'un fichier de configuration YAML) connecte les microservices entre eux.

5.2 TLS Token Binding

Toute amélioration des propriétés de sécurité du protocole HTTP bénéficie directement à la sécurité du modèle « Zero Trust ».

C'est le cas par exemple du « TLS Token Binding » (anciennement « TLS Channel ID »), un mécanisme conçu initialement pour remplacer les cookies comme moyen de persistance des sessions utilisateurs. Le vol de cookies est un serpent de mer pour la sécurité des applications web, et une bénédiction pour les pentesteurs et les bounty hunters de tout poil. Grâce au « TLS Token Binding », la persistance de la session utilisateur est assurée par le canal TLS lui-même, ce qui bénéfice à la sécurité du protocole U2F (voir à ce sujet la présentation réalisée lors de SSTIC 2016 [2]).

Cela rend certes les couches « transport » et « application » du modèle OSI interdépendantes, ce qui ne manquera pas de faire enrager les puristes (et rendre quelques questionnaires d'embauche caducs), mais cette délinéation arbitraire avait de toute façon déjà été fortement mise à mal par HTTP/2 et ALPN (« Application-Layer Protocol Negotiation »).

Le mot de la fin

Les esprits chagrins ne manqueront pas de faire remarquer que le « Zero Trust » n'est que la combinaison d'un SSO et d'un serveur mandataire inverse (« reverse proxy »). Loin de moi l'idée de les détromper, mais la sécurité logicielle ne se résume-t-elle pas à l'écriture de programmes sans bogues ? La lutte contre le filoutage (« phishing ») ne consiste-t-elle pas tout simplement à supprimer les mots de passe ?

Bien que de nombreux problèmes de sécurité admettent une solution théorique, la beauté du concept de « Zero Trust » est qu'il en existe au moins une implémentation opérationnelle à large échelle. Cela devrait vous motiver pour vos prochains projets d’infrastructure : il est possible de faire mieux, ne lâchez rien sur les fondamentaux (du moins si vous êtes responsable de la sécurité d’un tel projet). Construire une cathédrale logicielle dont la sécurité repose sur la perfection de chacun de ses composants unitaires (y compris ses utilisateurs) est impossible.

Au lieu de vous laisser partir avec 42 conseils sur les bras, je me limiterai à vous en donner un seul – facilement applicable en toutes circonstances : trust no one :)

Références

[1] « Dépérimétrisation : futur de la sécurité réseau ou pis-aller passager ? », SSTIC 2008, https://www.sstic.org/2008/presentation/Deperimetrisation_futur_de_la_securite_reseau_ou_pis_aller_passager/

[2] « A first glance at the U2F protocol », SSTIC 2016, https://www.sstic.org/2016/presentation/a_first_glance_at_the_u2f_protocol/

[3] BeyondCorp, les sites de référence, https://www.beyondcorp.com/, https://cloud.google.com/beyondcorp

[4] BeyondProd, https://cloud.google.com/security/beyondprod

[5] « BeyondCorp: A New Approach to Enterprise Security » (2014), https://www.usenix.org/system/files/login/articles/login_dec14_02_ward.pdf

[6] « BeyondCorp: The Access Proxy » (2016), https://research.google/pubs/pub45728/

[7] « BeyondCorp: Design to Deployment at Google » (2016), https://storage.googleapis.com/pub-tools-public-publication-data/pdf/44860.pdf

[8] « How Google adopted BeyondCorp » :

• https://security.googleblog.com/2019/06/how-google-adopted-beyondcorp.html,
• https://security.googleblog.com/2019/08/how-google-adopted-beyondcorp-part-2.html,
• https://security.googleblog.com/2019/09/how-google-adopted-beyondcorp-part-3.html,
• https://security.googleblog.com/2019/10/how-google-adopted-beyondcorp-part-4.html