Convergence de différents types d’indicateurs pour les SASE

Pourquoi des procurations dans SASE ?

L’époque où la sécurité au niveau des paquets était considérée comme suffisante est révolue.
En raison de la sophistication des attaques, il devient impératif de procéder à une inspection approfondie du contenu pour différents types de protection.
L’accès en fonction de l’identité est une exigence clé en raison de la répartition du personnel et des applications.
Cet article de blog examine en détail les exigences liées à l’accès tenant compte de l’identité.
L’inspection approfondie du contenu et l’accès tenant compte de l’identité au niveau de l’API/application-ressource nécessitent l’interruption des connexions client, l’inspection du contenu pour la détection des menaces et le contrôle d’accès, ainsi que l’établissement de connexions par l’intermédiaire de proxys.
C’est pourquoi de nombreuses solutions SASE mettent en œuvre la sécurité par l’intermédiaire de proxys.

Types de mandataires

Vous avez peut-être entendu parler des différents types de proxies – Forward, Reverse et Transparent.
La fonctionnalité principale de tous les types de proxies est la même.
Les fonctionnalités de haut niveau sont énumérées ici.

• S’emparer du trafic
• Mettre fin aux connexions des clients.
• Authentifier les clients.
• Obtenir l’identité de l’utilisateur.
• Établir des connexions vers les serveurs.
• Décryptage et cryptage TLS
• Vérifiez la réputation de l’IP et du domaine.
• Effectuer des contrôles d’accès basés sur l’identité.
• Exécuter les fonctions de la CASB.
• Vérifiez si des données ont été perdues et évitez de les perdre.
• Assurer la fonction de détection/prévention des intrusions.
• Assurer la fonction de pare-feu d’application web.
• Recherchez des logiciels malveillants et des indicateurs d’exploitation dans le trafic et agissez.

Les différences entre ces deux types de produits dépendent des facteurs suivants :

• Obtention du trafic pour l’inspection des menaces et le contrôle d’accès
• Authentification des utilisateurs et identification des utilisateurs

Type de proxy transparent

Dans ce cas, les clients et les serveurs ignorent la présence des serveurs mandataires.
Ces proxys capturent le trafic des routeurs du réseau sur lesquels le trafic passe.
Il incombe aux administrateurs de réseau de veiller à ce que le trafic des utilisateurs de bureau et le trafic des utilisateurs en télétravail soient dirigés vers les entités de routage de l’entreprise.
Pour s’assurer que le trafic des utilisateurs WFH passe par les routeurs de l’entreprise, il est normal d’utiliser des clients VPN pour se connecter aux réseaux de l’entreprise.
Dans le cas du SD-WAN, les tunnels VPN aboutissent à des concentrateurs VPN situés au point de contact le plus proche.
L’authentification et l’identification de l’utilisateur s’effectuent via

• Portail explicite
• Portail à la demande
• Établissement d’un tunnel VPN
• Certificat client TLS

Dans le cas d’un « portail explicite », les utilisateurs se connectent de manière proactive au portail.
Le service de portail authentifie l’utilisateur à l’aide des systèmes d’authentification de l’entreprise.
Une fois les informations d’identification de l’utilisateur validées, il note l’adresse IP de l’utilisateur (à partir de l’IP source de la connexion) et informe les serveurs mandataires de l’ID de l’utilisateur et des informations de correspondance entre l’adresse IP et l’ID.
Une fois que le mandataire connaît ces correspondances, il identifie l’utilisateur à partir de l’adresse IP du trafic et applique la politique d’identité.
Si l’utilisateur ouvre une session sans s’authentifier de manière proactive auprès du portail, le proxy peut rediriger l’utilisateur vers le portail.
Comme l’accès au portail se fait à la demande, cette méthode d’authentification est également appelée authentification du portail à la demande.
Il convient de noter que la redirection de l’utilisateur vers le portail n’est possible que si la connexion est basée sur HTTP/HTTPS.
Dans le cas de HTTPS, la redirection n’est possible qu’après le décryptage TLS.
En cas d’accès à des services/sites n’appartenant pas à l’entreprise, il est nécessaire d’imiter le certificat du serveur avec le certificat de l’autorité de certification de l’entreprise.
En outre, si l’utilisateur n’est pas un utilisateur humain utilisant le navigateur, la redirection n’est d’aucune utilité.
Malgré ces mises en garde, il s’agit toujours d’un moyen efficace pour le proxy d’authentifier et d’identifier l’utilisateur.
Comme nous l’avons brièvement évoqué, pour faire partie des réseaux d’entreprise, les utilisateurs de WFH (Work From Home) doivent se connecter aux réseaux d’entreprise par l’intermédiaire d’un tunnel VPN.
L’établissement d’un tunnel VPN permet déjà d’authentifier l’utilisateur.
Les concentrateurs VPN attribuent une adresse IP privée unique à chaque client.
Les clients peuvent être configurés pour utiliser le tunnel VPN et donc cette adresse IP comme source pour la majorité des connexions (y compris le split tunnelling désactivé).
Les concentrateurs VPN ont la capacité d’annoncer aux parties externes l’adresse IP attribuée au client, l’ID de l’utilisateur (ID de l’initiateur).
Les serveurs mandataires utilisent cette correspondance pour identifier les sessions d’un utilisateur à un moment ultérieur, lorsque les clients initient des sessions.
Si la session TLS établie par les programmes clients dispose d’un certificat client TLS, celui-ci peut être utilisé pour authentifier et identifier l’utilisateur.
Cette méthode est très rarement utilisée aujourd’hui dans les SASE, mais c’est l’une des options disponibles.
L’un des principaux avantages du type de proxy transparent est qu’il peut capturer tous les protocoles de trafic, et pas seulement HTTP/HTTPS.
Un autre avantage majeur est qu’il n’y a pas de configuration spéciale sur les machines clientes ou les machines serveurs de l’entreprise.
Ce type de proxy présente peu d’inconvénients.
Étant donné qu’il identifie l’utilisateur sur la base de l’adresse IP observée dans le trafic, toutes les applications de la machine de l’utilisateur bénéficient du même traitement de sécurité.
S’il s’agit d’une machine multi-utilisateurs, tous les utilisateurs de cette machine bénéficient du même traitement/privilège de sécurité.
Si cette adresse IP fait office de NAT pour plusieurs machines, toutes les machines situées derrière cette adresse IP NAT bénéficient du même accès et du même traitement de sécurité.
Imaginez que l’ordinateur portable d’un utilisateur soit infecté par un logiciel malveillant.
Le logiciel malveillant bénéficie du même accès que celui défini pour cet utilisateur, car il fait partie de la même machine que celle à partir de laquelle l’utilisateur se connecte au portail.
Pour cette raison, les types de proxy transparents doivent être utilisés avec précaution, au moins pour les sessions HTTP/HTTPS. Un autre inconvénient est que ce type de proxies nécessite la présence d’un client VPN sur les appareils.
Bien que ce ne soit pas un problème pour les appareils gérés, il peut être difficile de convaincre les employés d’installer le client VPN sur les appareils qui leur appartiennent.

Type de proxy de transfert

Les serveurs mandataires sont destinés aux dispositifs clients qui communiquent avec des services/sites externes.
Les applications clientes sont configurées pour passer par un proxy de transfert afin de communiquer avec des services externes.
Les applications clientes sont configurées avec le FQDN/IP du proxy et le port sur lequel les proxys écoutent.
Dans le cas d’un proxy transparent, les adresses IP source et destination de la session n’ont jamais l’adresse IP du proxy.
Dans le cas d’un proxy direct, les connexions du client se font vers l’adresse IP du proxy et la connexion au serveur se fait à partir de l’adresse IP du proxy.
Les fichiers PAC sont utilisés pour configurer les applications clientes, telles que les navigateurs, avec les paramètres du proxy.
Le fichier PAC permet de sélectionner l’acheminement du trafic vers différents serveurs mandataires en fonction des domaines de service de destination.
Les fichiers PAC sont distribués aux navigateurs clients via des solutions de gestion de système ou via le service WPAD (Web Proxy Auto Discovery).
Les applications clientes avec les paramètres du proxy communiquent toujours avec le proxy.
C’est ainsi que les proxys de transmission capturent le trafic.
Dans le cas de connexions TLS telles que HTTPS, chaque connexion TCP commence par une transaction « HTTP CONNECT ».
Cette transaction n’a lieu qu’entre le client et le proxy.
Après cette transaction HTTP CONNECT, les données entre le client et le serveur sont transmises par le proxy.
La transaction « HTTP CONNECT » comporte un champ d’en-tête « host » dont la valeur est utilisée par le proxy pour déterminer le FQDN et le port de la destination finale.
Dans le cas de HTTP2.0, chaque connexion de flux commence par une transaction « HTTP CONNECT ».
Comme vous avez pu le constater, il n’est pas nécessaire d’envoyer le trafic aux routeurs de l’entreprise pour que le proxy le capture.
En d’autres termes, le trafic est directement acheminé vers le proxy.
De cette manière, le proxy est indépendant du réseau.
Les serveurs mandataires peuvent également authentifier et identifier les utilisateurs via les en-têtes proxy-authenticate et proxy-authorization.
Dans le cas des connexions TLS, ces en-têtes sont envoyés respectivement en réponse et en demande dans les transactions HTTP CONNECT.
Il convient de noter qu’il n’est pas nécessaire de décrypter les connexions TLS pour authentifier et identifier l’utilisateur.
Aucune authentification de portail n’est requise.
Un avantage supplémentaire est que de nombreux navigateurs et applications clients prennent en charge Kerberos dans le cadre de l’authentification par proxy.
Ainsi, tout utilisateur qui se connecte à un appareil peut s’authentifier automatiquement auprès du proxy sans qu’il soit nécessaire d’afficher des fenêtres de connexion supplémentaires (également connu sous le nom de SSO).
L’utilisation d’un proxy de type forward pour les clients qui communiquent avec des services externes présente plusieurs avantages.
Certains d’entre eux sont énumérés ci-dessous.

• L’authentification et l’identification de l’utilisateur sont déterministes.
  Dans le cas d’un proxy transparent, si l’utilisateur oublie de s’authentifier de manière proactive sur le portail, la redirection du portail à la demande ou du portail captif pour l’authentification de l’utilisateur n’est possible qu’après le décryptage TLS.
  Certaines entreprises n’autorisent pas le décryptage TLS pour les sites qui collectent des informations confidentielles.
  Si les sites adoptent l’épinglage de certificats, les proxys transparents ne sont pas censés imiter le certificat et le décryptage TLS n’est donc pas possible.
  Dans ce cas, il n’est pas possible de déterminer l’utilisateur afin d’assurer l’application de la politique en fonction de l’identité.
  Dans le cas d’un proxy direct, la phase d’authentification du proxy ayant lieu avant tout échange TLS, l’authentification et l’identification de l’utilisateur sont déterministes.
• Comme nous l’avons vu précédemment, le proxy direct est indépendant du réseau et peut fonctionner avec n’importe quel réseau tant que les applications clientes sont configurées avec des paramètres de proxy.
  Il n’est pas nécessaire qu’un client VPN soit présent sur les appareils, même si les utilisateurs travaillent à domicile.
• Étant donné que de nombreuses applications client prennent en charge Kerberos, l’utilisateur bénéficie d’une expérience SSO.
• Le cryptage de l’appel client (ECH) dans TLS 1.3+ gagne du terrain dans l’industrie.
  Lorsque ECH est adopté, SNI n’est pas visible et, par conséquent, le type de proxy transparent ne sera pas en mesure d’effectuer un filtrage d’URL et un contrôle d’accès, même de base.
  Dans le cas d’un proxy direct, en raison de la transaction HTTP CONNECT, le proxy connaît le FQDN de destination même si ECH est adopté.
  En d’autres termes, le type de proxy direct est sûr pour l’ECH.
• Il n’y a pas de liste blanche d’adresses IP.
  Chaque application client doit s’authentifier séparément auprès du proxy, ce qui est très sûr.

Il y a aussi quelques inconvénients.
Il ne fonctionne que pour le trafic HTTP/HTTPS.
Bien que la majorité des applications client prennent en charge les paramètres du proxy, certaines ne le font pas.

Type de proxy inverse

Les proxys inversés sont utilisés pour les applications serveur frontales.
Les proxys inversés sont utilisés pour protéger les services contre les menaces, pour fournir un RBAC, pour terminer les sessions TLS et également pour équilibrer la charge des sessions de trafic entre plusieurs instances de services.
Les proxy inversés capturent le trafic via des méthodes DNS.
Le FQDN de chaque service d’entreprise exposé aux employés ou aux utilisateurs publics est configuré dans les serveurs DNS de l’entreprise pour pointer vers les adresses IP des instances de proxy inverse.
Ainsi, chaque fois qu’un utilisateur tente de se connecter aux services de l’entreprise, le trafic correspondant atterrit dans les proxys inversés.
Les proxys inversés mettent également fin aux sessions HTTPS/HTTP.
Dans le cadre de ce processus, ils authentifient également les utilisateurs et identifient ensuite les utilisateurs des sessions via les méthodes OIDC, SAMLv2 et SPENGO/Kerberos.
Dans le cas d’une communication d’application à application, les utilisateurs sont également identifiés à partir des certificats TLS.

SASE Proxy

Pour en savoir plus sur les SASE, veuillez lire l’article de blog sur le décryptage des SASE.
Comme vous avez pu le constater, les solutions SASE sont censées fournir une sécurité complète – sécurisation des clients, sécurisation des données SaaS et sécurisation des applications d’entreprise.
Comme décrit dans l’article de blog Identity-aware-SASE, les contrôles d’accès basés sur l’identité sont la caractéristique clé de SASE.
Bien que de nombreuses entreprises puissent se contenter d’un accès HTTP/HTTPS, certaines d’entre elles peuvent également avoir besoin de contrôles d’accès pour d’autres protocoles.
En raison de ces besoins, nous pensons que le proxy SASE doit être transparent pour le trafic non-HTTP et pour les applications clientes qui ne supportent pas les paramètres du proxy.
Le proxy SASE doit agir en tant que forward proxy pour les applications clientes qui accèdent à l’Internet et aux services SaaS afin de fournir un contrôle d’accès déterministe basé sur l’identité et également pour assurer la pérennité de l’adoption de l’ECH.
Le proxy SASE agira également en tant que proxy inverse pour protéger les applications d’entreprise.
Cette convergence de plusieurs types de proxy est nécessaire à la réussite de la solution SASE.

• Blog CTO Insights

  La série de blogs Aryaka CTO Insights fournit un leadership éclairé sur les thèmes du réseau, de la sécurité et de la SASE.
  Pour les spécifications des produits Aryaka, consultez les fiches techniques d’Aryaka.