Revenir au blog
ZTNA 2.0: Zero Trust, Zero exception - Image
L'approche “Zero Trust” des entreprises qui consiste à vraiment minimiser, voire supprimer toute confiance implicite dans l’accès distant de tout utilisateur se confronte à l’approche dite « ZTNA » (Zero Trust Networks Access) des éditeurs traditionnels de sécurisation des accès distants, qui ne sont pas initialement outillés pour gérer tous les cas d’usage, n’importe quel utilisateur, n’importe quel cloud, et n’importe quel contenu.

Avec ZTNA 2.0, Palo Alto Networks pose les fondations d’une nouvelle ère de l’accès sécurisé. 

 

Un jour, le VPN fut… 


Oui, Tout a commencé avec le VPN, souvenez-vous, c’
était il y a si longtemps… 

Les accès réseaux distants se faisaient avec un tunnel chiffré VPN. Ce tunnel masquait certes la communication entre les 2 points de connexion, mais manquait cruellement de granularité. Les VPN n’étaient pas forcément conçus pour contrôler quels utilisateurs pouvaient accéder à quelles applications, ce qu’ils pouvaient faire avec ces applications et quel contenu était susceptible d’être échangé. 

L’autre problème évident des VPN est qu’ils étaient conçus pour un monde où un utilisateur se connectait depuis un site de confiance vers des ressources internes. Autrement dit, les VPN n’ont pas la flexibilité et l’évolutivité pour un monde hybride, avec des accès simultanés vers l’Internet, les data centers, ou le cloud public. 

Ce manque d’évolutivité, de visibilité et de contrôle est devenu incompatible avec les standards minimums des entreprises, et l’absence de contrôle de l’identité, de l’application et du contenu des accès aboutissait au paradoxe d’augmenter la surface d’attaque sous prétexte de sécuriser une connexion distante. 

 

Alors ZTNA 1.0 est apparu… 

 

Pour remédier à ce manque de visibilité et de contrôle, les éditeurs de sécurité ont fait avec les accès distants ce qu’ils avaient fait avec le firewall de première génération, à savoir ajouter un proxy. C’est l’avènement des éditeurs de proxy dans le cloud. Confrontés à la problématique du contrôle d’accès au réseau et à l’approche ZTNA, ces éditeurs ont estimé que la meilleure façon de faire du Zero Trust était de solliciter un tiers de vérification : un « broker ». En d’autres termes, l’utilisateur s’authentifie d’abord à travers ce broker et c’est le broker qui valide l’authentification sur la base de l’identité et du type de requête. Une fois validée, la connexion se fait directement vers sa cible : vérification terminée.  

Mais le problème est justement que ça s’arrête là. Une fois la connexion validée, une confiance implicite totale est dangereusement accordée, car Il n’y aucune autre inspection. Pourquoi ? parce qu’étant donné la façon dont ces produits sont architecturés, l’inspection se fait dans le broker, et que dans ce cas, le trafic ne passe pas à travers le broker… 

En d’autres termes, une fois connecté, un attaquant aurait les mains libres. en effet, un attaquant qui serait déjà présent dans le endpoint ne pourrait pas être détecté par une vérification d’intégrité et de posture de ce endpoint. Si des données étaient exfiltrées, la fuite ne pourrait pas être détecté par des fonctions de DLP ; une tentative d’exploitation de vulnérabilité ne pourrait pas être vue etc... 

Le gain en granularité d’authentification obtenu grâce au ZTNA 1.0 au profit du VPN est trop cher payé, et entre en contradiction avec les principes élémentaires du Zero Trust. 

 

 

ZTNA 2.0 : le meilleur des deux mondes !

 

Comme souvent la solution se situe en prenant le meilleur des deux mondes :
L’accès réseau VPN de l’ancien monde qui a le contenu du trafic à sa disposition avec les avantages d’authentification de ZTNA :
c’est ZTNA 2.0 de Palo Alto Networks 

 ZTNA 2.0 va combler les lacunes de ZTNA 1.0. On va bien sûr continuer à avoir une inspection très granulaire de l’identité de l’utilisateur, de sa destination, de ce qu’il essaie de faire etc… Mais ces contrôles vont être combinés à une inspection en profondeur et continue du trafic.  

Prenons le scénario classique de l’utilisateur qui parvient à se connecter de manière légitime à une application. Deux cas de figure, soit le endpoint peut passer subitement sous contrôle d’un attaquant une fois qu’il est connecté, ou un malware qui était déjà présent dans le endpoint depuis longtemps sans agir, se réveille car il attendait simplement l’authentification .
Avec ZTNA 2.0, cette tentative de prise de contrôle sera mise en lumière, parce que les connexions vont être inspectées pour chercher d'éventuels exploits de vulnérabilités, afin de mettre en avant les anomalies de comportement, détecter les malwares etc... 

Le niveau d’inspection va également détecter des transferts de données anormales qui seraient par exemple effectuées par un malware qui s’exécuterait au niveau de l’application. 

Toutes ces détections sont possibles tout simplement parce que, contrairement à ZTNA 1.0 qui autorisait puis ignorait, ZTNA 2.0 de Palo Alto Networks ne s’arrête jamais d’inspecter le tunnel, avec des fonctions de prévention et de détection largement éprouvées, ainsi que des outils avancés de DLP (Data Loss Prevention) 

Il y a bien sûr de nombreux exemples qui illustrent comment l’inspection de sécurité en continue et en profondeur déjoue de nombreuses attaques, anciennes comme modernes, puisqu'on ne se contente plus simplement de faire confiance à une connexion approuvée,

En quelques mots...

 

ZTNA 1.0 était un bon début, car cela permettait quand même de contrôler l’utilisateur, l’application à laquelle il accédait et ce qu’il pouvait faire avec cette application. Dans le monde moderne hybride, la confiance et la légitimité qu’accordait ZTNA 1.0 sont devenues des vulnérabilités que l’on peut exploiter. Les niveaux de contrôle de l’utilisateur et d’inspection du trafic apportés par ZTNA 2.0 de Palo Alto Networks corrigent ces failles et s’adaptent au changement de paradigme provoqué par les nouveaux environnements, les nouveaux utilisateurs et les nouvelles applications.

 

Écrit par K.M.