Qu’est-ce qu’un proxy inverse ?

Quelle est la différence entre un proxy inverse et un proxy direct ?

Il est facile de confondre ces deux types de serveurs proxy, aussi allons-nous les détailler.

Situé devant un serveur Web, un proxy inverse garantit qu’aucun client ne communique directement avec le serveur. Un proxy direct (un autre mode CASB) se trouve devant les terminaux des clients pour intercepter les demandes entrantes et garantir qu’aucun serveur ne communique directement avec un client. Ces différents types de serveurs peuvent sembler similaires d’un point de vue fonctionnel, mais les proxys directs dépendent généralement d’un agent logiciel installé sur les terminaux pour transférer le trafic, contrairement aux proxys inverses.

Qu’est-ce qu’un serveur proxy inverse ?

« Serveur proxy inverse » est essentiellement un terme plus formel pour désigner un proxy inverse. (Il en va de même pour « serveur proxy direct » pour un proxy direct). Le terme « serveur » a tendance à être abandonné aujourd’hui car il évoque le matériel, comme une boîte physique, alors que la technologie revêt souvent la forme d’une application ou d’un service cloud.

Comment fonctionne un proxy inverse ?

Situé dans le flux du trafic, un proxy inverse s’intègre au service d’authentification d’une entreprise (par exemple, l’authentification unique). Une fois que le service informatique a configuré les services et les applications pour qu’ils effectuent des transactions avec le proxy inverse, ce dernier peut fonctionner en ligne sans agent. L’utilisateur bénéficie ainsi d’une expérience directe, le trafic entrant vers les applications cloud gérées et le reste étant automatiquement redirigé vers le proxy inverse.

Examinons ce processus plus en détail.

Un proxy inverse peut protéger les données sensibles (par exemple, les données PCI, PII) en agissant comme un intermédiaire ou un substitut du serveur qui héberge ces données. Les demandes du client sont d’abord acheminées vers le proxy inverse, puis via un port spécifique dans tout pare-feu applicable, puis vers le serveur de contenu et enfin, dans le sens inverse. Le client et le serveur ne communiquent jamais directement, mais le client interprète les réponses comme s’ils avaient communiqué. Voici les étapes de base :

1. Le client envoie une demande que le proxy inverse intercepte.
2. Le proxy inverse transmet la demande entrante au pare-feu. Le proxy inverse peut être configuré pour répondre directement aux demandes de fichiers dans son cache sans communiquer avec le serveur (pour plus de détails à ce sujet, consultez les cas d’utilisation).
3. Le pare-feu bloque la demande ou la transmet au serveur.
4. Le serveur envoie la réponse au proxy à travers le pare-feu.
5. Le proxy inverse envoie la réponse au client.

Le proxy inverse peut également analyser les réponses du serveur pour y rechercher des informations qui pourraient permettre à un hacker de rediriger vers des ressources internes protégées ou de tirer parti d’autres vulnérabilités.

Logiciels Open Source et proxys inverses

Les proxys inverses sont souvent construits sur des logiciels Open Source (OSS) car ils permettent aux développeurs d’accéder, de modifier et de distribuer le code source. De nombreux proxys inverses Open Source proposent des fonctionnalités flexibles et personnalisables qui permettent aux utilisateurs d’adapter le proxy en fonction de leurs besoins.

À titre d’exemple, Nginx, Apache et HAProxy sont tous des proxys inverses qui, grâce à leur fonctionnalité OSS, fournissent l’équilibrage de charge, la mise en cache, le déchargement SSL et le routage des requêtes http. Les logiciels Open Source peuvent également être la solution idéale à des fins de sécurité, car ils permettent plusieurs examens du code afin d’identifier les vulnérabilités et proposer des correctifs.

Cas d’utilisation du proxy inverse

Le proxy inverse, en tant que mode de déploiement du CASB, est au cœur du modèle SSE (Security Service Edge, aux côtés de la passerelle Web sécurisée (SWG) , de l’accès réseau Zero Trust (ZTNA) et d’autres services de sécurité fournis dans le cloud.

Au-delà du SSE, les cas d’utilisation spécifiques les plus courants pour les proxys inverses sont très divers :

Sécurisation des appareils non gérés

Nombre de vos employés peuvent utiliser plusieurs appareils pour le travail, y compris leurs appareils personnels. Par ailleurs, de nombreux fournisseurs, partenaires et clients peuvent avoir besoin d’accéder à vos applications internes sur leurs propres appareils non gérés, ce qui représente un risque pour votre sécurité.

Vous pouvez installer des agents tels que des VPN pour gérer les appareils appartenant à votre entreprise, mais les terminaux non gérés sont différents. Les tiers ne vous laisseront pas installer des agents sur leurs terminaux, et de nombreux employés ne veulent pas non plus d’agents sur leurs appareils personnels. En revanche, un proxy inverse offre une protection sans agent contre les fuites de données et les malwares provenant de tout appareil non géré qui accède à vos applications et ressources cloud.

Protection des données

Un proxy inverse peut appliquer des politiques de protection contre la perte de données pour empêcher les téléchargements accidentels ou intentionnels d’informations sensibles vers ou depuis des applications cloud autorisées. Étant donné qu’il opère en mode inline et inspecte le trafic chiffré (en particulier un proxy inverse basé sur le cloud), il peut garantir que les données téléchargées sont conformes à vos politiques.

Prévention des menaces

Un fichier infecté dans un service cloud peut se propager aux applications et appareils connectés, en particulier aux appareils non gérés. En empêchant, sans agent, le chargement ou le téléchargement de fichiers infectés vers ou depuis des ressources cloud, un proxy inverse offre une protection contre les menaces avancées telles que les malwares et ransomwares.

Par nature, les proxys inverses dissimulent également les serveurs et leurs adresses IP aux clients, ce qui protège les ressources web contre les menaces telles que les attaques par déni de service distribué (DDoS).

Équilibrage de charge

Les proxys inverses peuvent être utilisés pour traiter les demandes des clients qui pourraient autrement submerger un unique serveur en cas de forte demande, ce qui permet une grande disponibilité et de meilleurs temps de chargement tout en soulageant le serveur backend. Ils le font principalement de deux manières différentes :

1. Un proxy inverse peut mettre en cache le contenu d’un serveur d’origine dans un stockage temporaire, puis envoyer le contenu aux clients qui le demandent sans autre transaction avec le serveur (c’est ce qu’on appelle l’accélération Web). Un système de noms de domaine (DNS) peut être utilisé pour acheminer les demandes de manière uniforme entre plusieurs proxys inverses.
2. Si un grand site Web ou un autre service Web utilise plusieurs serveurs d’origine, un proxy inverse peut répartir les demandes entre ceux-ci afin d’assurer une charge uniforme sur les serveurs.

Les avantages de l’utilisation d’un proxy inverse

En gardant ces cas d’utilisation à l’esprit, les avantages de l’utilisation d’un proxy inverse se répartissent en trois domaines principaux :

• Sécurité des données et prévention des menaces : les proxys inverses fournissent une fonctionnalité de pare feu d’application Web (WAF) en surveillant et en filtrant le trafic (y compris le trafic chiffré) entre les terminaux gérés/non gérés et le serveur Web, le protégeant ainsi de l’injection SQL, des scripts intersites et d’autres cyberattaques.
• Évolutivité et gestion des ressources : il s’agit d’un avantage en deux parties. Les proxy inverses permettent d’étendre les opérations en éliminant la nécessité d’installer des agents sur chaque terminal utilisateur avant de pouvoir fournir un accès sécurisé aux ressources gérées. Ils prennent également en charge l’évolutivité de l’infrastructure grâce à des fonctionnalités telles que l’équilibrage de la charge du serveur, la gestion du trafic API, etc.
• Performance et productivité : les proxys inverses basés sur le cloud peuvent analyser et appliquer des politiques de sécurité au trafic, y compris au trafic des utilisateurs distants, sans backhauling via votre data center. Ils disposent également d’une capacité d’évolution réellement illimitée pour inspecter le trafic TLS/SSL (la majorité du trafic actuel), alors que les pare-feu et les proxys basés sur des appliances ne peuvent que rarement inspecter le chiffrement TLS/SSL sans baisse importante des performances.

Les défis liés aux proxys inverses

Les proxys inverses offrent des avantages notables pour la sécurisation des appareils non gérés et des applications d’entreprise, mais ils présentent également des inconvénients notables, tels que :

• Aucune sécurité pour les ressources non gérées : si un utilisateur a besoin d’un accès sécurisé à une application ou à une ressource qui n’est pas intégrée à votre SSO, le proxy inverse ne pourra pas s’en charger. Les proxys inverses ne surveillent que le trafic destiné aux ressources approuvées, pas l’ensemble du trafic. Pour sécuriser les ressources non approuvées de la même manière, vous devrez recourir à un proxy direct.
• Risque de pannes fréquentes : les proxys inverses sont généralement codés en dur pour fonctionner avec des versions spécifiques d’applications, donc lorsqu’une application est mise à jour et que le nouveau code est envoyé au proxy, une rupture est possible. Cela peut engendrer une indisponibilité de l’application mise à jour jusqu’à ce que le proxy puisse être recodé, ce qui provoque le mécontentement des utilisateurs et une perte de productivité.

Une meilleure solution : l’isolation du navigateur basée sur le cloud

De plus en plus d’entreprises se tournent désormais vers l’isolation du navigateur basée sur le cloud pour éviter les limitations et les risques de rupture des proxys inverses tout en permettant une utilisation sécurisée des appareils non gérés sans agent de terminal.

Lorsqu’un utilisateur accède à une application cloud gérée, Zscaler Cloud Browser Isolation virtualise la session et restitue le contenu dans un environnement isolé dans le cloud, en envoyant la session à l’utilisateur sous forme de flux de pixels. L’expérience utilisateur est identique à l’expérience native de cette application cloud, à cela près que CBI empêche les appareils non gérés de télécharger, copier, coller ou imprimer les données sensibles présentes dans l’application.

CBI constitue donc le moyen idéal de favoriser la flexibilité et la productivité de votre base d’utilisateurs étendue tout en empêchant les fuites accidentelles, l’exfiltration malveillante et la prolifération de logiciels malveillants via des appareils non gérés.

Isolation du navigateur de Zscaler basée sur le cloud

Zscaler Browser Isolation™ offre une défense inégalée contre les fuites de données et les menaces basées sur le Web, optimisée par l’isolation Web Zero Trust la plus avancée du secteur.

Expérience utilisateur inégalée

Bénéficiez de connexions ultra-rapides aux applications et aux sites Web grâce à notre technologie unique de streaming de pixels et à notre architecture proxy directe vers le cloud. Les utilisateurs reçoivent un flux haute performance de pixels dans leur navigateur, garantissant ainsi la sécurité sans nuire à la productivité.

Protection cohérente pour les utilisateurs, où qu’ils se trouvent

Protégez n’importe quel utilisateur, sur n’importe quel appareil, où qu’il se trouve, grâce à une politique d’isolation Zero Trust qui s’étend du siège social aux sites mobiles ou distants, en passant par des fonctions et des départements fortement ciblés.

Moins de tracas de gestion

Déployez et gérez la solution en quelques secondes, à l’aide de Zscaler Client Connector ou d’une option sans agent pour acheminer le trafic via Zscaler Zero Trust Exchange™ avec l’intégration native de Cloud Browser Isolation.

Compatibilité universelle

Bénéficiez d’une couverture pour tous les principaux navigateurs Web en fonction des préférences des utilisateurs. La persistance des cookies pour les sessions isolées permet de conserver intacts les paramètres clés, les préférences et les informations de connexion des utilisateurs.