Qu'est-ce que SSL-/TLS-Inspection ?

SSL-/TLS-Inspection en détail

Techniquement, l'inspection fonctionne comme un point intermédiaire contrôlé : le client établit la connexion TLS vers l'instance d'inspection, qui l'établit à son tour vers le site cible. L'instance d'inspection délivre alors au client un certificat signé par un certificat racine distribué dans l'entreprise, soit le certificat racine Zscaler, soit une CA d'entreprise propre. Si ce certificat racine est absent du magasin de certificats d'un appareil ou d'une application, des avertissements de certificat apparaissent.

Tout le trafic ne se prête pas à un contrôle utile. Les applications avec Certificate Pinning n'acceptent que leur certificat attendu et échouent sous inspection ; elles ont besoin d'exceptions ciblées. Il existe par ailleurs des exceptions volontaires pour des raisons de protection des données, typiquement pour des catégories comme les banques ou la santé. Chaque exception est aussi un angle mort : ce qui n'est pas déchiffré ne peut pas être contrôlé pour détecter du code malveillant ou une fuite de données. L'enjeu est de maintenir un catalogue d'exceptions documenté et aussi restreint que possible.

Pourquoi SSL-/TLS-Inspection compte-t-elle dans l'exploitation Zscaler ?

Pour le support, SSL-/TLS-Inspection compte parmi les causes cachées les plus fréquentes : avertissements de certificat dans le navigateur, applications qui échouent seulement sur le réseau de l'entreprise ou seulement avec le client actif, téléversements bloqués par une règle. Sans visibilité sur l'état d'inspection et de règles, ces cas ressemblent à des erreurs applicatives. Les questions clés sont : la connexion est-elle inspectée, une exception s'applique-t-elle, et l'appareil fait-il confiance au certificat racine ?

Au niveau du pilotage, la couverture d'inspection est un indicateur de sécurité : des exceptions trop nombreuses ou trop larges vident de leur substance le sandbox, l'antivirus et le DLP. Dans le même temps, la protection des données et la représentation du personnel exigent des règles traçables sur les catégories exemptées et leurs motifs. Pour les justificatifs, par exemple dans le cadre de NIS2, il faut documenter à quoi ressemble la règle d'inspection, qui l'a modifiée et quand.

Sources d'erreur courantes

• Certificat racine incomplètement distribué : certains appareils ou outils disposant de leur propre magasin de certificats (navigateurs, environnements de développement) ne font pas confiance à l'inspection et génèrent des erreurs de certificat.
• Certificate Pinning négligé : les applications avec pinning échouent sous inspection ; sans liste d'exceptions tenue à jour, des incidents récurrents et difficiles à rattacher apparaissent.
• Exceptions trop larges : exempter durablement des domaines ou des catégories entières du contrôle crée des angles morts pour les malwares et les fuites de données.
• Catégories liées à la protection des données non réglées : des exceptions absentes ou non documentées pour les services bancaires et de santé deviennent un risque de conformité.

SSL-/TLS-Inspection en pratique : ce qu'apporte CentaurNexus

CentaurNexus aide aux deux extrémités. Au cas par cas, Connectivity Triage Map réunit la chaîne ZDX et l'état de la Policy, puis nomme la cause en clair, par exemple si un blocage ou un problème de certificat se cache derrière l'incident. Au niveau de la configuration, Policy Health Saga évalue l'état de santé de la configuration sous forme de score, avec un plan d'action priorisé et un rapport PDF pour les justificatifs NIS2 et DORA ; les exceptions trop larges et les lacunes de la règle d'inspection ressortent ainsi systématiquement, en analyse en lecture seule, sans intervention automatique sur les règles. Le helpdesk n'a pour cela pas besoin de droits d'administration Zscaler. Comment les utilisateurs identifient eux-mêmes un blocage ou un avertissement de certificat, c'est ce que montre l'article Self-service Zscaler directement dans le navigateur.

Termes associés