Depuis quelques années, un couple de mots ressort de plus en plus dans le monde de la sécurité.
Cette combinaison de termes, c’est "Zero Trust".
C’est un couple qui revient beaucoup, mais le concept est encore méconnu, mal compris et parfois déformé par un excès de marketing.
Alors, c’est quoi Zero Trust ? Qu’est-ce que ça change à nos SI ? Au-delà du concept, comment peut-on le décliner ?
Dans cet article, on va donc creuser un peu ce concept qui consiste à minimiser au maximum la confiance en notre infrastructure. On parlera aussi de Zero Trust Architecture, le terme générique regroupant les architectures liées à ce modèle. Et cela pourrait changer la façon dont vous concevez la sécurité.
Afin de comprendre les origines de Zero Trust (parfois abrégé ZT), il est nécessaire de revenir sur les éléments qu’il remet en cause dans les approches courantes de la sécurité.
On ne reviendra pas sur la totalité de ce qu’est le monde de la sécurité informatique aujourd’hui, aussi, nous nous concentrerons sur les éléments remis en question par Zero Trust. Remarquez que ces choix sont bien entendus orientés pour les besoins de l’explication de ce qu’est Zero Trust. Tout n’est pas à jeter dans les pratiques actuelles.
Quelques prémisses (quelque peu caricaturées, entendons-nous bien) de l’approche traditionnelle de la sécurité sont :
Certaines de ces prémisses se sont avérées fausses ces dernières années. Les autres sont bousculées.
Quelques mouvements principaux ont retenu notre attention :
Le travail dans les métiers du tertiaire connaît un mouvement diffus mais réel vers plus de travail à distance. La pandémie de COVID-19 ayant massivement accéléré ce phénomène. À tel point que de plus en plus d’entreprises, particulièrement dans l’IT (Facebook, Spotify, Twitter...) annoncent désormais faire du télétravail une stratégie de long terme. Leurs employés n’auront donc pas accès (du moins directement) au réseau qui est censé assurer la sécurité du système.
De plus, on vous en parlait l’année dernière, les VPN sont une brique assez difficile à maîtriser dans un SI. Ils ont du mal à tenir des charges aussi massives que celles que l’on souhaite leur faire encaisser ces derniers temps. Il faut donc investir très sérieusement dans l’ingénierie ou payer très cher un éditeur qui le fera pour vous… juste pour permettre à vos utilisateurs d’accéder à votre SI.
La croissance incroyable et la généralisation de l’utilisation du cloud public semblent aussi être un mouvement majeur de l’informatique. Or, avoir une application dans le cloud public, c’est accepter de sortir une partie de son métier de son réseau d’entreprise. Celui-là même qui était un élément de base de notre stratégie de sécurité. On peut bien sûr simuler une appartenance au SI grâce, une fois de plus, à des VPN. Cependant ces solutions sont toujours des solutions de contournement et lorsqu’une partie significative (20%, 30%, 50% ?) de mes nouvelles applications sont dans des clouds publics, est-il vraiment sain de maintenir un régime d’exception ?
Troisième élément, les DSI externalisent une bonne partie de leur main-d'œuvre à des sociétés de services et/ou de conseil. Il est aujourd’hui excessivement rare pour la DSI d’une grande entreprise de dépasser 50% d’internes. Il est donc compliqué de faire travailler tout le monde avec du matériel sous contrôle. Il est aussi très difficile de définir un profil générique pour les externes qui auront forcément accès à notre réseau (ce qui, on le rappelle, est l’un des éléments de notre stratégie de défense).
Ces situations offrent donc un véritable challenge aux postulats proposés. Le lecteur le plus sagace aura peut-être déjà remarqué qu’il semblerait confortable de s’affranchir de certaines limites. Et si l’on arrêtait de contrôler nos SI par leurs réseaux ?
Zero Trust propose donc une approche différente de la sécurité. On relègue la sécurité par le périmètre réseau au second plan, car le problème est peut-être ailleurs. Cette approche, on l’a dit, a connu une vague de popularité ces derniers temps. Cependant, arrêter de se baser sur la sécurité périmétrique et utiliser des modèles différents est un argument récurrent (à défaut d’être sur le devant de la scène) depuis… au moins 2004.
Ce que propose le modèle est résumé dans le terme lui-même : "Zero Trust". L’idée est de renoncer à cette confiance faite par défaut à un acteur tiers, quelle que soit sa provenance. Désormais tout le monde doit prouver qui il est (s’authentifier) et ce qu’il a le droit de faire (ce qu’il est autorisé à faire) avant de pouvoir accéder ou agir sur une ressource.
Ce qui est proposé ici ce n’est pas de détruire le modèle de sécurité traditionnel. On souhaite bel et bien transformer ce modèle en trouvant des stratégies plus efficaces ; tant en termes de sécurité que d’usabilité.
Il est sur mon réseau ? Et alors ? Qu’il prouve qui il est et qu’il a le droit de discuter avec moi !
Extrait du discours (fictif) d’un système propriétaire d’une ressource en Zero Trust
Les impacts de ce simple concept sur les douleurs identifiées précédemment sont importants. Puisque le périmètre (c'est-à-dire le filtrage des utilisateurs par le réseau) ne me protège pas, je peux le remplacer par des stratégies pilotées, cohérentes et renforcées d’authentification. Cela implique que :
D’un côté, on a donc les problématiques présentées en partie I, toutes résolues (ou partiellement résolues) directement ou indirectement par Zero Trust.
De l’autre, on a aussi quelques avantages supplémentaires (ou renforcement des bonnes pratiques existantes) par rapport à une protection par le réseau :
Cette architecture, justement, c’est le sujet de notre prochaine partie.
L**’architecture Zero Trust** ou Zero Trust Architecture (ZTA) pour les plus anglophiles, c’est un modèle d’architecture générique proposé afin de répondre aux enjeux de Zero Trust.
Ce modèle, on le retrouve notamment dans la définition du NIST de Zero Trust. C’est une preuve que les éléments de base proposés ici sont reconnus par les praticiens comme étant une solution classique à la problématique.
Cela ne signifie pas qu’il s’agit de la seule solution possible pour faire du Zero Trust. Ni même que ZTA couvre entièrement les concepts de Zero Trust. Cela signifie simplement que cette implémentation spécifique fonctionne bien pour certaines organisations qui l’utilisent, y compris à l’échelle.
L’architecture Zero Trust classique (NIST) pourrait basiquement être décrite par ce schéma, qu’on détaillera par la suite :
Nous allons illustrer cette architecture avec l’exemple d’un système de gestion de la relation client : un CRM. Celui-ci est développé en interne par l’entreprise La Grosse Boîte. On a donc notre application (le-crm), où une chargée de clientèle (Nadia) veut modifier l’adresse d’un de ses clients (Denis). Ce cas aurait cependant pu être décliné dans à peu près tous les cas d'usage d’une application à usage interne et développée sur mesure.
En tant que système de sécurité et schéma d’authentification et d’autorisation, Zero Trust a l’objectif suivant : assurer que l’utilisateur (Subject) puisse accéder à la ressource (Enterprise Resource ou Resource) - soit la donnée à traiter et à protéger.
On représente ici notre Subject comme un humain. Cependant, il peut très bien s’agir d’un utilisateur qui n’est pas humain. Votre application peut être utilisée par d’autres services, dans des contextes "machine-to-machine" sans que cela pose le moindre problème pour Zero Trust. Car en réalité un tel contexte est un contexte où vous accordez votre confiance au développeur et à l’opérateur du produit.
Dans notre exemple, le Subject sera donc Nadia, utilisatrice de le-crm. La Resource sera l’adresse de Denis.
Le Resource Management System est la brique permettant de traiter et de gérer l’Enterprise Resource. Le plus souvent, c’est une application. Cette brique n’est pas dans la norme, car elle n’est pas fondamentalement nécessaire. On pourrait accéder directement à la ressource sans intermédiaire. Cependant, conceptualiser le Resource Management System aide à une meilleure compréhension du modèle, car il s’agit souvent d’un élément sous-entendu. On a donc choisi de le représenter ici. Il s’agit dans notre exemple de l’application web qui permet d’accéder et de modifier la donnée du profil : c’est-à-dire l’application le-crm.
L’utilisateur, pour pouvoir accéder à la Resource va aussi utiliser un System. Cela correspond à son moyen d’accès au système de gestion de la ressource. Dans le cas de notre CRM, on l’a dit, l’utilisateur y accède via une application web. Le System correspond donc à l’ensemble des moyens permettant l’accès à l’application, et notamment :
Parlons désormais des éléments centraux de l’Architecture Zero Trust. On ne les définira que peu par rapport au métier de l’application car ils sont des éléments d’architecture technique plus que des éléments profondément métier. Il y en a trois et ils sont situés au centre sur notre schéma :
Le Policy Engine : c’est un élément qui est géré à l’échelle de notre organisation. Ici à l’échelle du SI de La Grosse Boîte. L’idée de ce composant est de créer des stratégies liées à l’authentification et l’autorisation pour toute l’organisation.
Ces règles peuvent être très génériques et s'appliquent de manière globale (ce ne sont pas des règles pour un flux unitaire).
On mettra ici par exemple des règles liées à une authentification telle qu’on la conçoit aujourd’hui. Par exemple, une politique de mot de passe (sans règles liées à la composition de préférence).
Là où Zero Trust va plus loin, c’est qu’il remet en avant un élément un peu à la marge (pour le grand public du moins) dans le monde de l’authentification ces dernières années : l'authentification basée sur le score ou sur le risque (on verra souvent risk-based authentication). L’idée est de fournir des éléments contextuels sur le risque lié à la requête à la place ou en plus des éléments non contextuels.
Par exemple :
C’est ce composant qui fait de l’architecture Zero Trust une approche à échelle d’un SI. Si ce composant est absent, vous n’implémentez pas vraiment une architecture Zero Trust car votre implémentation perd son aspect systémique. Vous ne mutualisez et ne consolidez pas vraiment les stratégies d’authentification.
Le Policy Enforcement Point (PEP) se situe cette fois-ci au niveau de l’architecture technique d’un produit (ici, c’est donc la responsabilité de le-crm). On peut le voir comme une pure brique technique dont le rôle principal est de servir de porte d’entrée (avec un videur, le Policy Administrator, dont on parle juste après !) à notre application.
La porte peut donc être ouverte ou fermée pour un utilisateur, dans un certain contexte et à cause de son niveau d’authentification ou d’autorisation.
En plus de son rôle principal de porte (ouverte / fermée), le PEP centralise les accès à notre application. Il peut donc être utile et sain de lui adjoindre des opérations de traçage et de monitoring des accès.
Le Policy Administrator (PA) est une fois de plus un élément de l’architecture de notre application.
Ce composant correspond à la vraie brique d’authentification de l’architecture. Il s’occupe de :
L’idée ici est de se servir du PA avec un protocole d’authentification ou d’autorisation classique (par exemple OpenID Connect). On se sert de cette brique comme on se servirait d’un Authorization Server en Oauth2 (c’est d’ailleurs souvent à proprement parler un Authorization Server Oauth2 en 2021 !).
L’idée principale est donc de le contacter, qu’il vérifie et atteste ce qu’on a le droit de faire sur le périmètre de notre application puis qu’on le laisse tranquille jusqu’à la prochaine fois.
Dans le cas de le-crm, c’est lui qui fournit la page de login et délivre les tokens aux utilisateurs.
Même si conceptuellement, le PA et le PEP ont des rôles distincts, ils seront, dans certaines implémentations, regroupés dans une seule brique commune par souci de simplicité. Il est en effet souvent plus simple de rassembler la porte et le videur qui est censé contrôler celle-ci.
On ne les détaillera que peu mais les éléments qui sont en dehors du cadre sont des éléments qui donnent de l’information pour une prise de décision du Policy Administrator.
Concrètement, il s’agit d’éléments servant à contextualiser la demande d’authentification / d’autorisation par différents moyens, pouvant inclure :
À ce moment de l’article, vous pourriez être tenté de vous dire quelque chose comme "Oui, bon c’est bien gentil tous ces concepts mais jusqu’ici je n’ai rien de concret à mettre en place sur mon SI".
On vous propose donc de voir un premier exemple d’implémentation, celui de Google, qui réfléchit à cette architecture depuis une dizaine d’années et l’utilise depuis quelque temps. Ça s’appelle Beyond Corp et ils commencent aujourd’hui à le commercialiser packagé via Google Cloud Platform (avec des offres comme Beyond Corp Enterprise).
Beyond Corp, c’est basiquement le modèle autour duquel l’architecture Zero Trust a émergée. Les définitions de la ZTA viennent en grande partie de l’implémentation Beyond Corp, en supprimant le spécifique au besoin de Google et en généralisant.
C’est la raison pour laquelle on retrouve toutes les briques standard et quelques possibilités avancées dont on a parlé précédemment (quelques éléments de contextualisation de la requête notamment).
C’est aujourd’hui, assez logiquement, l’offre la plus mature du marché.
Une correspondance partielle des éléments Zero Trust et de l’offre commerciale Beyond Corp pourrait être la suivante :
Maintenant qu’on a vu dans quel contexte il peut être intéressant de transitionner vers une architecture Zero Trust pour son SI, on peut aussi se poser la question inverse. Mon organisation est-elle prête pour une architecture Zero Trust ?
En effet, comme pour tout changement d’ampleur sur l’architecture du SI, il est pour le moins douteux de penser qu’il est possible de changer en profondeur son archi sans changer son organisation (la Loi de Conway, vous connaissez peut-être).
Le passage de tout un SI vers une architecture Zero Trust est un projet de transformation majeur et ne se fera pas sans votre RSSI et/ou votre équipe sécurité. Il faudra qu’ils soient convaincus de l’intérêt pour les utilisateurs du SI. Il faudra aussi qu’ils comprennent les avantages en termes de sécurisation des ressources. Il faudra qu’ils soient convaincus que changer une bonne partie du fondement de leur modèle de sécurité actuel sera rentable à moyen terme.
Bref, il faudra convaincre et changer l’organisation et les manières de penser.
Pour ce qui est de la migration en elle-même, c’est un sujet à part entière et cet article étant déjà long, on ne va donc pas s’étendre dessus ici.
On vous propose cependant quelques axes qui nous semblent de bonnes stratégies de priorisation pour une migration :
Ce qu’on a vu au cours de cet article, c’est que Zero Trust est un modèle de sécurité basé sur la limitation maximale de la confiance dans les systèmes d'information. Notamment de la confiance dans le réseau d’entreprise.
Cet objectif de base a des impacts énormes sur la façon dont on conçoit la protection de notre périmètre métier. Il ne s’agit plus de protéger une ville avec des murs très hauts et très épais. Il s’agit désormais de protéger un grand nombre d’habitations éparses, en plaçant une porte identique à l’entrée de chacune d’entre elles.
Si Zero Trust est un concept, l’architecture Zero Trust (Zero Trust Architecture ou ZTA) est une adaptation de ce concept sous forme d’une architecture générique, implémentable à l’échelle d’un SI.
Zero Trust répond à des problématiques qui semblent être des mouvements de fond du domaine de l’IT et qui sont des douleurs pour les stratégies de sécurité traditionnelles. Cloud, télétravail, externalisation, effacement du périmètre … sont autant de points de crispation et de contournement des politiques de sécurité des entreprises.
Zero Trust nous semble aujourd'hui être un modèle très prometteur pour la structuration d’un SI. C’est un modèle qui permet de diminuer les contraintes pour les utilisateurs tout en améliorant notre niveau de sécurité et en éliminant les crispations susnommées. C’est exactement ce que l’on cherche lors de la mise en place d’un système de sécurité.
Pour ces raisons, mettre en place Zero Trust nous semble un investissement d’avenir qui pourrait être extrêmement intéressant pour beaucoup de SI.
En effet, aujourd’hui est sans doute le meilleur moment pour entamer un chantier de passage vers des politiques Zero Trust, si votre contexte le permet. La réflexion sur ces sujets est mature, les technologies qui répondent au besoin émergent.
C’est un chantier d’ampleur, mais c’est surtout un changement qui sera bénéfique à moyen et long terme, et qui permettra d’accompagner de manière plus sereine des mouvements déjà en œuvre dans nos organisations.
Pour aller plus loin :