Qu'est-ce que Surrogate IP ?
Surrogate IP est un service Zscaler qui associe un utilisateur authentifié à son adresse IP privée, afin que ses policies utilisateur s'appliquent aussi au trafic que le service ne peut pas authentifier directement. D'après la documentation Zscaler, cela concerne surtout les applications sans support des cookies, les connexions HTTPS non déchiffrées et les transactions avec des User Agents inconnus. Sans Surrogate IP, seules les policies de site généralistes s'appliqueraient à ce trafic. L'association vaut pour un utilisateur par adresse, elle est reportée dans les logs, et elle prend fin avec le délai d'inactivité, la déconnexion, ou la connexion d'un autre utilisateur depuis la même adresse.
Surrogate IP en détail
Le mécanisme est volontairement simple : lorsqu'un utilisateur se connecte avec succès depuis un site connu, le service retient l'association « cette IP privée appartient en ce moment à cet utilisateur ». À partir de là, les transactions sans identification utilisateur lui sont également attribuées, aussi bien dans les policies que dans les journaux. Effet secondaire pratique : qui s'est authentifié dans un navigateur n'a pas besoin de se reconnecter dans un second navigateur ou dans des applications de bureau.
Les conditions requises sont un chemin de transfert qui conserve l'adresse privée visible (tunnel GRE ou IPsec sans NAT, proxy chaining avec transmission XFF, ou un port proxy dédié), ainsi qu'une authentification imposée sur le site. Les limites apparaissent là où plusieurs utilisateurs partagent une même adresse : pour le VDI multi-session, Zscaler déconseille explicitement cet usage, car l'association peut alors viser le mauvais utilisateur.
Pourquoi Surrogate IP compte-t-il dans l'exploitation Zscaler ?
Au quotidien, Surrogate IP explique toute une famille de tickets énigmatiques. Un utilisateur reçoit apparemment au hasard les mauvaises policies : en réalité, c'est la policy de site qui s'applique, car l'association a expiré. Deux collègues partagent un poste, et le second hérite des blocages du premier : en réalité, l'association tient encore. Une application de bureau se comporte différemment du navigateur : en réalité, sans Surrogate IP, il manque l'identification utilisateur pour le trafic hors navigateur.
Pour les analyses aussi, le mécanisme compte double : l'association rend les logs nominatifs et donc parlants, mais elle y transmet aussi les erreurs d'attribution. Qui fonde des rapports ou des preuves sur des données de logs devrait savoir sur quels sites Surrogate IP est actif, avec quel délai d'inactivité, et où des appareils partagés limitent la fiabilité de l'information.
Sources d'erreur courantes
- Surrogate IP combiné avec du VDI multi-session : plusieurs utilisateurs partagent une adresse, policies et logs visent les mauvaises personnes.
- Délai d'inactivité mal calibré : trop court, il provoque des retours constants aux policies de site ; trop long, il maintient artificiellement des associations sur des appareils partagés.
- NAT dans le chemin de transfert : si l'adresse privée disparaît en chemin, le service ne peut plus associer, et la fonction tourne à vide.
- Documentation manquante sur les sites où Surrogate IP est actif : le helpdesk interprète alors les anomalies de policy comme un dysfonctionnement Zscaler plutôt que comme une question d'association.
Surrogate IP en pratique : ce qu'apporte CentaurNexus
CentaurNexus détermine si un comportement de policy étrange cache une association expirée ou étrangère, sans recherche dans plusieurs vues. La recherche utilisateur à 360° affiche, par nom, e-mail ou adresse IP, le statut d'un utilisateur sur ZIA, ZPA et ZDX sur une seule page, sans droits d'administration Zscaler. Connectivity Triage Map indique en clair si un problème vient de l'appareil, du réseau, d'une policy ou de l'association. Le First Level répond ainsi à la question « Pourquoi ai-je la mauvaise règle ? » avec un constat plutôt qu'une intuition. L'article suivant décrit cette approche à 360 degrés : Le support Zscaler sans droits d'administration.
Termes associés
Questions fréquentes sur Surrogate IP
Tout le trafic ne peut pas être authentifié directement : les applications sans support des cookies, les connexions HTTPS non déchiffrées et les User Agents inconnus ne portent pas d'identification utilisateur. Surrogate IP comble cette lacune en attribuant ces transactions, via l'adresse IP privée, au dernier utilisateur authentifié à cette adresse. Ce sont ainsi les policies utilisateur qui s'appliquent, et non les policies de site généralistes.
L'association vaut pour exactement un utilisateur par adresse IP et reste valable jusqu'à ce que le délai d'inactivité configuré expire, que l'utilisateur se déconnecte, ou qu'un autre utilisateur s'authentifie depuis la même adresse. L'administrateur configure ce délai au niveau du site ; c'est le levier principal entre confort et association propre.
Zscaler déconseille l'usage avec le VDI multi-session, car de nombreux utilisateurs y partagent une même machine virtuelle et donc la même adresse IP privée. L'association peut alors attribuer le trafic au mauvais utilisateur, aussi bien dans les policies que dans les logs. Pour ce type d'environnement, d'autres méthodes d'authentification sont préférables.
D'après la documentation Zscaler, il faut un chemin de transfert qui conserve l'IP privée visible : un tunnel GRE ou IPsec sans NAT, un proxy chaining avec transmission XFF activée, ou un port proxy dédié. L'authentification doit en outre être imposée sur le site. C'est seulement alors que le service peut relier utilisateur et adresse de façon fiable.
Le service attribue aussi les transactions associées à l'utilisateur dans les logs. Cela rend les analyses plus parlantes, mais signifie aussi qu'une association erronée, par exemple sur des postes partagés, se retrouve également dans le journal. Qui utilise les logs à des fins de preuve ou d'analyse devrait connaître et documenter les limites de l'association basée sur l'IP.
- Portail d'aide Zscaler : Understanding Surrogate IP - help.zscaler.com
- Portail d'aide Zscaler : Understanding User Provisioning and Authentication - help.zscaler.com
Remarque : CentaurNexus est un produit indépendant de SourcingBlox GmbH et non une offre de Zscaler, Inc. Les noms de produits et de marques appartiennent à leurs détenteurs respectifs.