21/10/2021
Cybersecurity Insights
Software-Defined Perimeter et les approches ZTNA
Précédemment, nous avons vu le modèle Zero Trust, ses principes, les composants d’une architecture Zero Trust et le Single-Packet Authorization (SPA) utilisé par le SDP. Nous allons donc commencer par voir le SDP pour mieux appréhender les approches choisies par les éditeurs ZTNA.
Software-Defined Perimeter
L’architecture proposée par la Cloud Security Alliance en 2014 conserve les principes de l’architecture Zero Trust définie par le NIST avec la séparation du Control Plane et du Data Plane. Cette architecture utilise quatre composants logiques :
- SDP Controller : appareil ou processus sécurisant l’accès au service isolé en s’assurant que les utilisateurs sont authentifiés et autorisés à accéder au service avec un terminal validé. Il force aussi l’application de politiques supplémentaires pour que les communications établies soient sécurisées.
- Initiating Host (IH) : il représente le client où l’agent SDP est installé.
Accepting Host (AH) : accepte les connexions sécurisées depuis les IHs, il représente un ensemble de services protégés par le SDP. - SDP Gateway : elle donne l’accès aux utilisateurs et terminaux autorisés aux processus et services protégés. Elle permet le monitoring, le logging et le reporting sur ces connexions.
Architecture Software-Defined Perimeter
Le fonctionnement de l’architecture SDP suit les étapes suivantes :
- Le ou les SDP Controller(s) sont activés pour commencer à construire une architecture SDP. Le SDP Controller possède l’ensemble des informations concernant les accès autorisés aux différents éléments de l’architecture SDP.
- Les Accepting SDP Hosts (AH) s’ajoutent auprès du SDP Controller. Souvent, les Accepting SDP Hosts (AH) sont derrière une SDP Gateway qui s’occupe d’établir la connexion et de communiquer avec le SDP Controller.
- Les Initiating SDP Hosts (IH) s’ajoutent auprès du SDP Controller avec l’envoi du Single-Packet Authorization. Le SDP Controller a les clés utilisées par le Initiating SDP Hots pour authentifier le paquet.
- Après connexion des différents composants auprès du SDP Controller, le SDP Controller contrôle la liste des Accepting SDP Hosts avec lesquels l’Initiating SDP Host a un accès autorisé.
- Le SDP Controller prévient les Accepting SDP Hosts concernés que l’Initiating SDP Host en question est autorisé à communiquer avec eux.
- Le SDP Controller envoie ensuite une liste des adresses IP des Accepting SDP Hosts autorisés à l’Initiating SDP Host.
- L’Initiating SDP Host communique avec les Accepting SDP Hosts après établissement d’une communication bidirectionnelle chiffrée (utilisation du mutual TLS).
L’architecture SDP réutilise des principes déjà connus pour proposer une architecture Zero Trust.
Différences entre l’architecture BeyondCorp et l’architecture Software-Defined Perimeter
Une solution ZTNA
Une solution ZTNA suit les principes du modèle Zero Trust en ayant les fonctionnalités suivantes :
- Authentification multi-facteurs de l’utilisateur
- Vérification de conformité du terminal utilisé : PC, tablette, smartphone
- Interconnexions avec les fournisseurs d’identité et les solutions EDR
- Application de politiques d’accès selon le contexte
- Protection des services utilisant TCP et UDP
- Interconnexions avec les solutions SIEM pour l’envoi des logs
Deux approches sont adoptées par les éditeurs pour leurs solutions ZTNA. Ces approches identifiées par le Gartner, s’inspirent des modèles d’architecture Zero Trust de 2014 .
L’approche Service-Initiated ZTNA
Cette approche s’inspire du modèle BeyondCorp de Google. L’utilisateur s’authentifie depuis son navigateur web au portail hébergé sur le ZTNA Broker/Proxy. Après authentification et vérification, les ZTNA Connectors autorisés sont accessibles pour l’utilisateur.
L’avantage de ce modèle est de ne pas avoir besoin d’agent pour qu’un service soit accessible à un utilisateur. Le fait de ne pas avoir d’agent apporte aussi moins d’informations sur la conformité du terminal. Certaines ressources sont protégées par ce modèle comme les ressources Web, les accès en SSH et en RDP mais la prise en charge d’autres services est rare.
Service-Initiated ZTNA, Market Guide for Zero Trust Network Access, Gartner (2020)
Le type Endpoint-Initiated ZTNA
Ce modèle s’inspire du Software-Defined Perimeter où le ZTNA Controller correspond au SDP Controller. Dans un premier temps, l’utilisateur va s’authentifier auprès du ZTNA Controller qui va vérifier son identité et celle du terminal utilisé. Le ZTNA Controller renvoie ensuite la liste des applications auxquelles l’utilisateur est autorisé à accéder. Il prévient ensuite la ZTNA Gateway que cette paire utilisateur-terminal est autorisée à accéder à la ressource.
Les avantages du modèle sont similaires à ceux du Software-Defined Perimeter et présentent aussi les mêmes inconvénients. La nécessité d’avoir un agent bloque les terminaux non gérés par l’entreprise. Ce modèle propose néanmoins un niveau de vérification précis en s’appuyant sur des données récupérées par l’agent. Toutes les applications utilisant TCP ou UDP peuvent être protégées et sont accessibles.
Endpoint-Initiated ZTNA, Market Guide for Zero Trust Network Access, Gartner (2020)
Que ce soit une ZTNA Gateway ou un ZTNA Connector, le composant est déployé au plus près des ressources et n’accepte pas les flux entrants. Les ressources ne sont jamais exposées directement sur Internet.
Dans ce second article, nous avons vu que le Software-Defined Perimeter est une solution ZTNA mais qu’une solution ZTNA n’était pas forcément une solution SDP. Le ZTNA a deux approches correspondant aux deux modèles d’architecture Zero Trust. Nous avons aussi défini les caractéristiques d’une solution ZTNA. Dans le prochain et dernier article sur le ZTNA, nous allons voir dans quelles mesures le ZTNA peut remplacer les solutions VPN SSL historiques.
Jérémy LANOË
Consultant Infrastructure Security
