IAM et Zero Trust : le SaaS à la rescousse ?

Zero Trust partout, justice nulle part : dans les allées des salons français en 2019, il était difficile de passer à côté des nombreux vendeurs qui vantaient les mérites de cette approche. Fait-on face à un buzzword de plus cachant simplement une gestion des identités et accès à laquelle on aurait donné un coup de peinture pour mieux la vendre ? Probablement. Mais comme souvent, il y a (quand même) un fond de réflexion derrière la débauche de réclame mettant le Zero Trust à toutes les sauces.

Si l’on remonte à l’origine du terme, on retrouve les premières mentions chez Forrester aux alentours de 2010. Le concept a été théorisé par John Kindervag, à l’époque analyste chez Forrester, et décrit une approche de la sécurité et de la gestion des accès adaptées à l’émergence des nouveaux usages, Cloud et mobilité en tête.

En 2013, Google donne le ton

Selon Kindervag, une approche Zero Trust s’oriente autour de trois concepts clefs :

• Toutes les ressources doivent être accessibles depuis n’importe quel endroit, et ce de façon sécurisée.
• Les contrôles d’accès et d’identité doivent permettre une gestion plus fine.
• Les administrateurs doivent conserver et analyser l’ensemble du trafic sur le réseau.

L’idée maîtresse du Zero Trust est de mettre en place une architecture du réseau qui prend acte de l’obsolescence du modèle de sécurité périmétrique : dans un système d’information moderne, impossible de se contenter de considérer un “intra” sécurisé par des pare-feu et un réseau externe par nature non sécurisé et qu’il conviendrait donc de filtrer. « Jusqu’alors, on était sur un modèle de sécurité périmétrique. A l’intérieur du périmètre, les utilisateurs sont réputés comme étant de confiance, contrairement à l’extérieur. Ce qui a changé aujourd’hui, c’est que le périmètre a volé en éclats », résume Nicolas Petroussenko, VP Sales chez Okta.

Pour les grandes entreprises, le tournant a débuté il y a quelques années déjà. L’un des principaux exemples est celui de Google, qui a largement documenté la mise en place de cette approche en interne dans une série d’articles regroupés sous l’appellation Beyond Corp. Dans ces différents articles, le géant de la Silicon Valley détaille la façon dont Google a su faire évoluer son système d’information pour prendre en compte cette nouvelle donne et implémenter en interne les grands principes détaillés quelques années plus tôt par Kindervag. Chez Google, cela se traduit notamment par la mise en place d’un système d’authentification qui attribue un score à l’utilisateur en prenant en compte l’identité de l’utilisateur, l’appareil qu’il utilise, son lieu de connexion ainsi que d’autres facteurs jugés pertinents. Selon le niveau de fiabilité, l’utilisateur disposera ou non d’un accès à certaines ressources ou à certains segments du réseau.

Une approche qui n’est pas sans rappeler le projet Abacus, à destination cette fois du grand public, mais qui visait en 2016 à mettre en place un “Trust Score” similaire sur Android. Depuis sa première annonce, le projet a fait assez peu parler de lui. Mais on imagine assez facilement que Google a été tenté de porter vers le grand public les principes déployés en interne autour de 2013 avec le projet Beyond Corp.

Le SaaS en embuscade

Mais tout le monde n’a pas les reins aussi solides que Google, et ce type de projet n’est pas à la portée de toutes les entreprises. Comme le faisait remarquer Paul Simmonds, CEO et CISO de la Global Identity Foundation, dans une conférence intitulée The Fallacy of Zero Trust, tout le monde n’a pas les moyens de reconstruire son réseau de zéro comme a pu le faire Google : « ce qu’ils font paraît très bien, mais cela coûte souvent beaucoup trop cher à mettre en place ».

C’est sur ce créneau que les offres SaaS tentent de se positionner. « L’idée, c’est d’avoir un tiers qui va valider l’identité de l’utilisateur avant de le connecter à l’application ou aux ressources qu’il demande, un peu comme une opératrice téléphonique qui mettait en relation les utilisateurs à l’époque », explique ainsi Yogi Chandiramani, VP Sales chez Zscaler. Zscaler a récemment déployé sa solution auprès d’Engie, qui a recours à son service pour connecter ses employés en call center au système informatique de l’entreprise.

Du côté d’Okta, la stratégie est plus ou moins similaire : «  le principe, c’est de déplacer la gestion des identités dans le Cloud. Nous récupérons toutes les informations d’authentification et d’identité et nous les centralisons pour autoriser les accès », explique Nicolas Petroussenko. Avec cette approche, le fournisseur peut se charger d’étoffer les facteurs de vérification de l’identité en ajustant le niveau demandé selon le comportement des utilisateurs, afin de demander par exemple des facteurs d’authentification supplémentaires sur une connexion jugée potentiellement suspecte.

Plusieurs questions restent néanmoins en suspens : on peut ainsi se demander si la mise en place de ces brokers ne vient pas créer un « single point of failure », c’est-à-dire une cible de choix pour les attaquants. « Le fait est que les attaquants profitent aujourd’hui de la gestion décentralisée des accès, en profitant de la faiblesse des mots de passe des utilisateurs pour se déplacer latéralement dans le réseau », explique Nicolas Petroussenko. Si celui-ci concède qu’Okta est « une espèce de Graal pour les hackers », il assure que le niveau de sécurité élevé leur permet de faire face aux attaques. « Au final, l’idée c’est que cette centralisation apporte un peu plus de sécurité et de flexibilité », poursuit le directeur. Jusqu’au jour où les brokers commenceront à tomber ?