Can we trust the Zero Trust Architecture ?
Le concept de « Zero Trust » ne vous parle pas ? Voici un petit refresh !
Le modèle Zero Trust repose sur des principes assez simples de définition : aucun utilisateur n’est totalement digne de confiance et on ne devrait pas permettre à quelconque utilisateur d’accéder à des ressources avant d’avoir vérifié leur justesse et ses autorisations. Ce modèle établit un “accès minimum basé sur des autorisations”, qui à son tour peut restreindre l’accès d’un utilisateur ou d’un groupe d’utilisateurs à une ressource.
Le Zero Trust n’est pas une technologie (et c’est important de le concevoir ainsi). La base du Zero Trust est de limiter la confiance pour déployer son infrastructure et ses flux de travail. Ce modèle suppose que l’on ne doit pas faire confiance aux actifs ou aux comptes utilisateurs en se basant uniquement sur un emplacement physique (normalement dans les locaux de l’entreprise ou en datacenter) ou sur le réseau local de l’entreprise.
Vous l’avez compris, l’objectif est de répondre aux enjeux de production en suivant l’évolution de la société (BYOD, cloud, accès distant, etc.) en ajoutant des contrôles réguliers, dynamiques et granulaires afin de garantir un niveau minimum de sécurité.
Un peu d’histoire
Le modèle Zero Trust a été inventé par Google vers 2009, dans le cadre du projet « BeyondCorp » qui a été la réponse de l’opération Aurora à une importante cyberattaque qui a visé une trentaine d’entreprises américaines et qui a finalement pris la tournure d’un incident diplomatique entre la République populaire de Chine et les États-Unis.
Un peu plus tard, Microsoft mettait en avant le concept Assume Breach (« we assume systems will fail or people will make errors »), un principe de sécurité défini sur un modèle de vulnérabilité assumée… intrigant non ? Mais pourquoi pas, le concept est « innovant ».
Dans l’ensemble des cas, le constat est le même : malgré la confiance que nous accordons aux solutions de protection périmétrique, les attaquants trouveront tout de même une vulnérabilité à exploiter sur les périmètres. Le concept Assume Breach est de définir des scénarios offensifs, les qualifier et de corriger les vulnérabilités. Un vrai wargame comme on les aime avec les fameuses deux équipes :
Blue team versus Red team, le purple match est lancé ! Je ne m’attarde pas trop sur le sujet, il est déjà traité ici.
Comme notre communauté le dit si souvent : « il y a deux types d’entreprises, celles qui sont piratées, et celles qui ne le savent pas encore ». En résumé, on présume que la sécurité périmétrique est en échec et qu’il ne faut faire confiance ni à l’humain ni à la machine.
Et c’est en 2010 que le cabinet d’analyste « Forrester Research » a introduit pour la première fois le terme « Zero Trust » afin de qualifier ce concept et par la suite sont arrivés les acronymes ZTA pour Zero Trust Architecture et ZTNA pour Zero Trust Network Access.
Et concrètement, ça donne quoi ?
Le Zero Trust est une réponse aux tendances et évolution de nos systèmes d’informations qui incluent les utilisateurs distants, ceux qui apportent leurs propres appareils (ordinateur ou smartphone), les actifs basés sur le cloud, etc. Le Zero Trust se concentre sur la protection des ressources (serveurs, applications, transport, etc.), sans se baser uniquement sur l’architecture, du fait que la localisation physique ou logique n’est plus considérée comme un élément clé de la posture de sécurité des ressources.
Le fonctionnement de l’architecture Zero Trust est assez simple finalement, cela commence par mettre en place des moyens d’authentification à l’état de l’art, vérifier la conformité de l’identité de l’utilisateur (heure de connexion, géolocalisation, etc.), vérifier si l’appareil est bien conforme à notre politique, vérifier si cet appareil est bien protégé… et tout cela sans oublier les projets d’intégration ou d’amélioration de la détection, le durcissement des actifs ou pour finir (voir commencer ?) par une analyse de risques, avec la méthode EBIOS RM, évidemment !
Finalement, cela n’est vraiment pas si simple que cela ! Il faut y aller méthodiquement tout en gardant à l’esprit que le changement se conduit. Autant vous dire que ce n’est pas donné à l’ensemble des systèmes d’information et notre retour d’expérience le confirme.
Un cas concret serait de comparer le Zero Trust au modèle de sécurité présent dans les aéroports. Lorsque nous devons nous rendre dans un autre pays via un vol international :
Notre retour d’expériences ? Voici quelques avis
Premièrement, l’avis de l’expert cybersécurité ne peut être que positif. Le principe de Zero Trust permet l’intégration de la vérification de la confiance et l’amélioration de la protection périmétrique. Cependant, nous gardons à l’esprit qu’une analyse de risque reste nécessaire avant toute intégration du modèle Zero Trust.
Et même si le modèle offre de nombreux avantages, comme toute architecture, elle possède quelque désavantage dont le déploiement qui serait susceptible d’être complexe. Une bonne préparation est, pour le coup, primordiale et cela pour plusieurs raisons :
- La première est évidente, il ne faut pas ajouter de nouveaux risques au système d’information. Cela semble indéniable, mais sans conduite du changement, c’est difficilement évitable ;
- Une des raisons qui arrive rapidement sur le tapis est le maintien de la production. Nous avons tous une production à faire tourner et le Zero Trust, par sa complexité possible, apporte des couches supplémentaires de sécurité amplifiant les points de complexité liée au fameux troubleshooting.
J’ai eu l’occasion, dès 2014, d’initier le principe chez plusieurs de nos clients et malgré sa phase de croissance, le Zero Trust fait sensation dans l’industrie de la sécurité tout en gardant une méfiance forte des parties métiers. Ce qui est certain, c’est qu’avec de plus en plus de cyberattaques (et ce n’est pas moi qui le dis), il est nécessaire de revoir nos architectures et intégrer le Zero Trust à notre réflexion. Si nous parlons aujourd’hui du modèle Zero Trust, cela signifie que nous (RSSI, chef de projet, architecte, administrateur, etc.) devons revoir nos positions en intégrant une « nouvelle » vision de la sécurité de nos systèmes d’information et des vulnérabilités qui y sont présentes sans perdre de vue que ces principes sont garants d’une certaine production.