Qu'est-ce que le Zscaler Client Connector (ZCC) ?

Zscaler Client Connector en détail

Après la connexion, le client établit, selon sa configuration, des tunnels vers le cloud Zscaler et y achemine le trafic capté. Deux éléments gérés de façon centralisée pilotent ce comportement : le profil de transfert détermine comment le trafic Internet est acheminé (par exemple en mode tunnel ou via un fichier PAC), tandis que le profil d'application règle les paramètres et exceptions propres à chaque plateforme. Le client peut en outre reconnaître des réseaux de confiance définis et y adapter son comportement.

ZCC se gère via un portail d'administration dédié, où profils, policies et versions du client sont tenus à jour de façon centralisée. Le client fonctionne sur les principales plateformes desktop et mobiles, dont Windows, macOS, Linux, iOS et Android. La possibilité pour les utilisateurs de désactiver eux-mêmes le client peut être restreinte par policy : Zscaler prévoit à cet effet des mots de passe dédiés, par exemple pour la désinstallation, et séparément pour la désactivation de services individuels comme ZDX ou Endpoint DLP. La suppression d'un appareil se contente de le désinscrire, sans désinstaller le client.

Pourquoi ZCC compte-t-il dans l'exploitation Zscaler ?

Une grande partie des tickets Zscaler atterrit d'abord sur le client : « pas d'Internet », « application inaccessible », « tout est lent ». La première question utile est presque toujours : ZCC est-il connecté, quel profil est actif, le tunnel est-il établi ? Des classiques comme un portail captif sur le Wi-Fi d'un hôtel expliquent bien des cas. Qui ne peut pas consulter cet état en est réduit à deviner ou à escalader vers les administrateurs.

À l'échelle du parc aussi, le client est critique pour l'exploitation : des versions obsolètes provoquent des erreurs connues, et en tant que point d'application des politiques de sécurité, il ne doit pas pouvoir être désactivé sans que personne s'en aperçoive. Selon l'architecture, un client désactivé signifie un trafic non contrôlé ou un accès manquant. Pour les preuves de conformité, ce qui compte est donc de pouvoir attester l'état réel des clients, pas seulement les policies sur le papier.

Sources d'erreur courantes

• Versions de client obsolètes dans le parc : d'anciennes versions de ZCC se comportent différemment de ce qui est attendu et produisent des symptômes difficiles à reproduire.
• Profil inadapté à l'environnement : un profil de transfert qui fonctionne sur le réseau de l'entreprise provoque des problèmes de connexion en télétravail ou derrière un portail captif.
• Conflits avec d'autres logiciels : des clients VPN ou des produits de sécurité des terminaux installés en parallèle gênent l'établissement du tunnel.
• Clients désactivés sans contrôle : si les utilisateurs peuvent désactiver ZCC librement, du trafic non contrôlé apparaît sans que personne ne s'en aperçoive.

ZCC en pratique : ce qu'apporte CentaurNexus

CentaurNexus rend ce contexte client exploitable pour le support : User Support Center affiche en une seule vue, comme bilan utilisateur à 360 degrés sur ZIA, ZPA et ZDX, la situation d'un utilisateur, sans que le helpdesk ait besoin de droits d'administration Zscaler. Connectivity Triage Map réunit la chaîne ZDX et l'état des policies, puis nomme la cause en clair : FAI, Wi-Fi, appareil ou Zscaler ; le guide suivant montre comment cela se déroule au quotidien Est-ce Zscaler ou le Wi-Fi ?. Si un appareil compromis doit être exclu, Emergency User Isolation l'isole de ZIA et de ZPA. Toutes les actions d'écriture sont auditables, avec validation à quatre yeux en option.

Termes associés