Qu'est-ce qu'un bypass d'inspection SSL ?

Le bypass d'inspection SSL en détail

Lorsque l'inspection SSL est active, Zscaler délivre au client, pour chaque connexion contrôlée, un certificat signé par l'Intermediate CA du tenant. Les navigateurs lui font confiance dès que le certificat est distribué dans le trust store. Les applications avec Certificate Pinning, elles, comparent avec l'original inscrit en dur et mettent fin à la connexion après le handshake TLS, souvent avec une erreur de certificat, parfois sans aucun message. Zscaler tient une liste officielle des applications concernées, des services Adobe jusqu'aux applications mobiles.

Pour l'exception, la documentation Zscaler cite deux voies : exclure l'application cloud dans son ensemble de l'inspection, ou exclure des domaines isolés via une catégorie d'URL dédiée. Il importe de distinguer cela du bypass Zscaler complet via fichier PAC ou profil d'application : l'exception d'inspection reste dans le chemin de données Zscaler et conserve le filtrage d'URL et les autres contrôles, tandis que le bypass complet le quitte entièrement.

Pourquoi les bypasses d'inspection SSL comptent-ils dans l'exploitation Zscaler ?

Les bypasses déterminent deux choses à la fois : la disponibilité et la visibilité. Si une exception nécessaire manque, une application métier reste bloquée, et le helpdesk cherche souvent la cause du côté du Wi-Fi, du VPN ou de l'état du serveur, alors que l'interruption tient en réalité au pinning. À l'inverse, trop d'exceptions créent un angle mort grandissant : du trafic que plus personne ne contrôle pour du code malveillant ou une fuite de données.

En pratique, les bypasses s'accumulent insidieusement : une exception pour un projet, une pour un test, une sur simple demande. Au bout de deux ans, plus personne ne sait lesquelles sont encore nécessaires. C'est pourquoi chaque bypass doit avoir une entrée avec motif, date et responsable, ainsi qu'un cycle de revue fixe. La couverture de l'inspection reste ainsi un état voulu, et non le produit du hasard de l'historique des tickets.

Sources d'erreur courantes

• Exclure des domaines ou des catégories entières alors que quelques noms d'hôte suffiraient : l'exception devient inutilement large.
• Bypass au lieu d'exception d'inspection : le bypass complet qui contourne Zscaler emporte aussi le filtrage d'URL et les policies, pas seulement le déchiffrement.
• Exceptions sans documentation : sans motif ni date, personne ne peut décider plus tard si l'exception peut disparaître.
• Traiter les cas de pinning comme un problème réseau : l'interruption après le handshake est confondue avec un problème de Wi-Fi ou de serveur, et le ticket tourne en boucle.

Bypass d'inspection SSL en pratique : ce qu'apporte CentaurNexus

Savoir si une URL donnée contourne réellement Zscaler ou si elle est seulement exclue du déchiffrement, CentaurNexus le dit sans avoir à deviner. PAC-Lens lit le fichier PAC réellement actif du tenant et indique, via une URL de test, quelle ligne s'applique et si le trafic passe en direct ou via Zscaler. Comment vérifier en direct une seule adresse via une URL de test, c'est ce que montre notre vidéo d'environ deux minutes et demie sur le testeur PAC. Connectivity Triage Map précise ensuite si un problème signalé tient à l'appareil, au réseau ou à une policy. La question « Pourquoi cette application ne fonctionne-t-elle pas ? » devient ainsi un constat vérifiable plutôt qu'une simple supposition. Comment les utilisateurs peuvent eux-mêmes vérifier au préalable les cas de connexion, l'article suivant le montre Le self-service Zscaler directement dans le navigateur.

Termes associés