Lead-analytics

Software-Defined Perimeter et les approches ZTNA | Sécurité
Lost Password?

A password will be emailed to you. You will be able to change your password and other profile details once you have logged in.

Software-Defined Perimeter et les approches ZTNA

sécurité
almond

Avis d'expert par Jérémy Lanoë - Consultant Infrastructure Security, Almond

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 :

  1. 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.
  2. 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.
  3. 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.
  4. 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é.
  5. Le SDP Controller prévient les Accepting SDP Hosts concernés que l’Initiating SDP Host en question est autorisé à communiquer avec eux.
  6. Le SDP Controller envoie ensuite une liste des adresses IP des Accepting SDP Hosts autorisés à l’Initiating SDP Host.
  7. 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

SOFTWARE-DEFINED PERIMETERBEYONDCORP
AuthentificationEnvoi du SPAConnexion depuis l’Access Proxy + RADIUS ou SSO
AutorisationRègles du SDP ControllerDécision de l’Access Control Engine
Présence d’un agentOuiNon
Protocoles supportésTCP/UDPWEB et SSH
Exposition des ressourcesPorts fermés(default-drop)Derrière l’Identity Aware Proxy

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.


Partager cet article




Sur le même sujet...

Aucun Commentaire