Introduction à Zero Trust 

Magazine
Marque
MISC
Numéro
110
Mois de parution
juillet 2020
Spécialité(s)


Résumé

La sécurité informatique adore les modes. Le « Zero Trust » fait partie de ces concepts qui sont devenus populaires du jour au lendemain. Et comme le sexe chez les adolescents, « tout le monde en parle, personne ne sait réellement comment le faire, tout le monde pense que tous les autres le font, alors tout le monde prétend le faire* ».


Body

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 :)

Notes

* Dan Ariely (2013), à propos du Big Data.

** C.f. « Very Bad Trip », « Sex Friends », « Good Morning England », « Just Married », etc.

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 » :



Article rédigé par

Par le(s) même(s) auteur(s)

Introduction à Metasploit

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
76
Mois de parution
janvier 2015
Spécialité(s)
Résumé

Le test d'intrusion (pentest) est une activité qui a connu son heure de gloire entre les années 2000 et 2010. Elle consiste à simuler l'activité d'un pirate sur un réseau interne ou externe, afin de tester en conditions opérationnelles l'efficacité de ses mesures de protection et de détection (le terme « opérationnel » reste à définir, car les conditions de réalisation du test sont parfois risibles). Metasploit est un outil permettant d'effectuer de telles simulations...

Introduction au reverse engineering

Magazine
Marque
MISC
HS n°
Numéro
7
Mois de parution
mai 2013
Spécialité(s)
Résumé

L’ingénierie inverse ou « reverse engineering », souvent abrégé « reverse » dans le jargon informatique, consiste à analyser un système jusqu’à être capable de le dupliquer, voire de l’améliorer. Il existe une activité industrielle importante autour de la fabrication de pièces détachées pour des systèmes dont le fabricant n’assure plus le support, ou a purement et simplement disparu.

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous