ZTNA et introduction au modèle Zero Trust

Ce premier article sur le Zero Trust Network Access (ZTNA) a pour but de donner les principes fondamentaux sur lesquels reposent le ZTNA. Nous allons voir une définition du modèle Zero Trust après avoir contextualisé les enjeux actuels sur les accès distants.

Selon le Gartner, en 2023, plus de 60% des entreprises adopteraient une solution ZTNA pour remplacer leur solution VPN. Le ZTNA apporte une nouvelle réponse pour offrir des accès distants aux collaborateurs accentuée pendant la crise de la COVID-19. Les accès distants sont devenus nécessaires pour assurer la continuité d’une entreprise. Le nombre de cyberattaques a d’ailleurs fortement augmenté pendant cette période. La sécurité des accès distants est donc de plus en plus préoccupante.

Une définition du modèle Zero Trust

Les notions de flux autorisés et de périmètres accordent une confiance implicite que le modèle Zero Trust refuse. Dans les années 2000, le Jericho Forum ainsi que le projet Black Core initié par le Département de la Défense des États-Unis proposent des pistes de réflexion sur un nouveau modèle de sécurité. L’accès dépendrait désormais de l’identité de l’utilisateur. En 2010, John Kindervag, analyste chez Forrester, reprend ces idées pour définir le modèle Zero Trust. Ce modèle n’accorde aucune confiance mais des accès en imposant plusieurs vérifications. Ces vérifications forment un contexte.

Le contexte est composé de l’identité de l’utilisateur, du rôle de l’utilisateur et de la vérification de conformité du terminal utilisé, aussi appelée Device Posture. L’authentification multi-facteurs est imposée à l’utilisateur qui doit saisir ses identifiants et effectuer une seconde action :

• Saisie du code envoyé par SMS, mail ou généré via une application (OTP)
• Validation de la demande d’accès via une application (PUSH)
• Utilisation du jeton RSA ou de clé d’authentification

Le rôle de l’utilisateur est analysé pour appliquer un principe de moindres privilèges et un principe de besoin d’en connaître au strict nécessaire limitant la visibilité et l’accès à certaines ressources. Pour s’assurer que l’accès n’expose pas l’infrastructure à des menaces externes, une vérification granulaire du terminal est effectuée.

Vérification granulaire de la conformité du terminal

Aucune distinction n’est faite entre des utilisateurs qui se connectent depuis des réseaux gérés et non gérés par l’entreprise. Les vérifications sont appliquées de la même manière pour ne pas accorder de confiance implicite. Le modèle donne aussi la possibilité à l’ensemble des terminaux et à l’ensemble des réseaux d’accéder aux ressources de l’entreprise.

La vérification est continue et ne s’arrête pas au moment où l’accès à une ressource a été accordé. La conformité du terminal utilisé peut changer, ce qui conduit à une réévaluation de l’accès accordé. Le trafic est aussi surveillé pour détecter une action malveillante.

En 2014, Google intègre le concept du modèle Zero Trust dans un projet de refonte de l’infrastructure. Ce projet s’intitule BeyondCorp en référence au nom de l’architecture à implémenter au sein de Google. BeyondCorp désigne aussi la solution Zero Trust que Google propose à ses clients. Cette décision a été prise à la suite d’une cyberattaque : l’Opération Aurora.

Article sur l’Opération Aurora : https://cyware.com/news/everything-you-need-to-know-about-operation-aurora-5c5f5b99

L’objectif est de protéger l’accès aux services web et SSH depuis des terminaux gérés par Google. La même année, la Cloud Security Alliance présente le Software-Defined Perimeter pour proposer un second modèle d’architecture Zero Trust.

L’architecture Zero Trust

Le modèle Zero Trust est un concept et ne représente pas une solution qu’une entreprise peut appliquer en tant que tel. Néanmoins, le NIST a déterminé les composants logiques permettant d’obtenir un début d’architecture Zero Trust dans son état de l’art. Une architecture Zero Trust est divisée en deux parties : le Control Plane et le Data Plane.

Composants logiques d’une architecture Zero Trust selon le NIST

Le Control Plane

Le Control Plane représente l’ensemble des composants chargés de collecter les informations nécessaires à la retranscription du contexte et chargés de la prise de décision. Il est composé du Policy Decision Point, lui-même composé du Policy Engine et du Policy Administrator. Le Policy Engine applique les politiques d’accès en s’appuyant sur les données collectées : le contexte. Le Policy Administrator génère les identifiants nécessaires à la communication entre le terminal et la ressource.

Dans le Control Plane, d’autres éléments sont aussi présents pour compléter la constitution d’un contexte comme les logs d’activité, les inventaires d’identité pour les utilisateurs et les terminaux ou encore la PKI pour vérifier l’authenticité d’un certificat. La centralisation des logs et la remontée d’alertes assurent la surveillance continue de l’ensemble du trafic avec le SIEM. Pour protéger le dispositif mis en place, la Threat Intelligence peut aussi être utilisée.

Le Data Plane

Le reste des composants se trouve dans le Data Plane. Le Data Plane représente l’ensemble des composants avec lesquels l’utilisateur peut interagir. L’utilisateur peut interagir avec le Policy Enforcement Point mais pas avec le Policy Decision Point qui est dans le Control Plane.

Lorsqu’un utilisateur veut accéder à une ressource, il est obligé de passer par le Policy Enforcement Point. Le Policy Enforcement Point envoie une demande au Policy Decision Point qui va renvoyer la décision prise. Ce composant ne collecte que l’information transmise par le Policy Decision Point et applique la décision renvoyée.

Pour revenir à BeyondCorp et au Software-Defined Perimeter (SDP), les architectures sont différentes mais utilisent ces composants logiques. BeyondCorp utilise un portail pour imposer les décisions renvoyées par le Data Plane et imposer l’authentification à l’utilisateur. Pour l’authentification, BeyondCorp utilise aussi un serveur RADIUS et le SSO. Le SDP utilise un autre système pour authentifier l’utilisateur avec l’envoi de Single-Packets Authorization.

Le Single-Packet Authorization

Le Single-Packet Authorization (SPA) s’appuie sur le principe du port-knocking. Le port-knocking consiste à ouvrir un port lorsqu’une séquence d’envoi de paquets sur certains ports est réalisée. Un port est un numéro unique codé sur 16 bits pour indiquer que l’information envoyée ou reçue est destinée à une application en particulier. Le port répond à un besoin de distinguer une information d’une autre pour une même machine ayant la même adresse IP. De cette manière, une connexion en SSH est possible sur le port 22 à un serveur Web pour l’administrer, et l’accès au service web est possible sur le port 80 depuis un navigateur web.

Avec le port-knocking, le service est inaccessible et aucune preuve de son fonctionnement n’est visible tant que la séquence n’a pas été exécutée. Par exemple pour ouvrir le port 22 correspondant au SSH, l’utilisateur doit d’abord envoyer un paquet TCP ou UDP sur le port 800, 400 puis 6523. Un utilisateur qui ne connaît pas la séquence ne peut pas ouvrir le port. De cette manière, le pare-feu a des règles dynamiques avec une politique default-drop. Le pare-feu n’accepte aucune connexion entrante à part celles qui sont déjà établies par défaut et ajoute une règle lorsque la séquence est respectée.

Fonctionnement du Port-Knocking

Le projet open-source fwknop implémente le SPA en suivant le principe du port-knocking pour donner un accès à un ou plusieurs services. La seule différence entre le SPA et le port-knocking est la génération du paquet authentifié et chiffré remplaçant l’usage de l’envoi de paquets sur une séquence de ports spécifiques. De cette manière, le SPA porte les informations permettant d’authentifier l’utilisateur et le terminal contrairement au port-knocking.

Dans ce premier article, nous avons donné une définition du modèle Zero Trust et le contexte historique derrière ses principes. Nous avons ensuite vu les composants d’une architecture Zero Trust et un projet open-source permettant d’implémenter le SPA utilisé par l’architecture Software-Defined Perimeter (SDP).

Dans le prochain article, nous verrons l’importance du SDP et de BeyondCorp dans les solutions ZTNA et nous allons définir les caractéristiques d’une solution ZTNA, cliquez-ici pour consulter le second article.