Inspection TLS locale ou dans le cloud : les compromis liés au déploiement
- L'inspection TLS déchiffre, examine et rechiffre le trafic ; le texte en clair existe donc brièvement, quel que soit l'endroit où cela se produit.
- L'inspection locale permet de contrôler les données en clair et les clés au niveau local ; évaluez séparément les services fournis dans le cloud et leurs traitements.
- Les recommandations de la NSA préconisent d'inspecter chaque session une seule fois, au sein du réseau d'entreprise, sans recourir à une chaîne de proxys.
- Tenez à jour une liste d'exceptions validée pour les applications épinglées, les catégories sensibles en matière de confidentialité et le trafic qui ne passe pas l'inspection.
- Le protocole « Client Hello » chiffré, publié sous la référence RFC 9849, limite la visibilité passive et nécessite une gestion spécifique.
L'inspection TLS (encore souvent appelée « inspection SSL ») consiste à intercepter une session TLS, à la déchiffrer à l'aide d'un certificat auquel l'entreprise fait confiance, à en inspecter le contenu, puis à la rechiffrer avant de la transmettre à sa destination. Sans cette technique, les passerelles Web sécurisées, les moteurs DLP et les bacs à sable ne voient que les métadonnées de destination. Grâce à elle, ils peuvent détecter les logiciels malveillants, bloquer l'exfiltration de données et appliquer des politiques d'utilisation acceptable au sein même des sessions chiffrées.
La question n'est pas de savoir s'il faut procéder à une inspection, mais où. Ce guide compare l'inspection TLS locale et dans le cloud en fonction des voies de décryptage, des responsabilités liées aux certificats, des exceptions, de la journalisation et des opérations.
Cet article fait partie du guide consacré à la sécurité du cloud hybride.
Fonctionnement de l'inspection TLS
L'inspection TLS fonctionne de la manière suivante : un proxy de confiance met fin à la session chiffrée du client, inspecte le contenu, puis établit une nouvelle session chiffrée vers la destination.
Le proxy fait office de serveur vis-à-vis du client et de client vis-à-vis de la destination :
- Le client établit une session TLS avec un site web ou une application.
- Le proxy intercepte la connexion et présente un certificat pour la destination, signé par une autorité de certification (CA) d'inspection d'entreprise à laquelle les appareils clients font confiance.
- Le proxy établit sa propre session TLS avec la destination réelle et vérifie la validité du certificat de ce serveur.
- Le trafic est déchiffré entre les deux sessions, inspecté, puis rechiffré.
Cela signifie que le proxy détient une clé très puissante et traite le texte en clair pour chaque session inspectée. L’avis de la NSA intitulé « Managing Risk from Transport Layer Security Inspection » (Gérer les risques liés à l’inspection de la sécurité de la couche de transport ) recommande de limiter au maximum ce type de situation : effectuer l’inspection une seule fois, au sein du réseau d’entreprise, et éviter les inspections redondantes par plusieurs proxys de transfert. L’alerte précédente de la CISA concernant l’interception HTTPS avertissait que des produits d’inspection mal mis en œuvre peuvent affaiblir la sécurité TLS, par exemple en ne validant pas correctement les certificats en amont.
Comparaison rapide entre l'inspection TLS locale et l'inspection TLS dans le cloud
L'inspection locale conserve les données en clair et les clés au sein de votre infrastructure, tandis que l'inspection dans le cloud les transfère vers les points de présence du fournisseur.
| Facteur | Inspection TLS locale (sur site) | Inspection TLS dans le cloud |
|---|---|---|
| Lorsqu'il y a du texte en clair | Les équipements de votre centre de données ou de vos succursales | Points de présence des fournisseurs |
| Qui détient la clé privée de l'autorité de certification chargée de l'inspection ? | Vous, éventuellement dans votre propre HSM | Fournisseur, ou vous-même via les options de clé prises en charge par le fournisseur |
| Idéal pour | Données réglementées, trafic interne, utilisateurs sur site, OT | Utilisateurs distants, trafic direct vers les services SaaS |
| Latence pour les utilisateurs sur site | Cela dépend de la capacité locale et du chemin de trafic | Cela dépend de la distance entre les points de présence et du routage |
| Planification des capacités | Cordialement ; le déchiffrement nécessite une grande puissance de calcul | Fournisseur |
| Dépendance vis-à-vis de la connectivité externe | Aucune pour l'application de la politique Web locale ; obligatoire pour les services fournis dans le cloud, tels que la protection des données | Obligatoire |
| Emplacement des journaux et des éléments de preuve | Les journaux locaux sont configurables ; les données relatives aux services cloud sont soumises à la politique de stockage de ces derniers | Régions de fournisseurs, sous réserve de configuration |
| Effort opérationnel | Dimensionnement du matériel, application des correctifs, cycle de vie des certificats | Distribution des certificats, exceptions, configuration des fournisseurs |
La plupart des organisations hybrides ont recours à ces deux méthodes : l'inspection locale pour certains trafics sur site et réglementés, et l'inspection dans le cloud pour les utilisateurs distants. Mettez en place la terminaison TLS sur chaque chemin et évitez tout déchiffrement redondant, y compris lorsqu'une passerelle locale transfère le trafic vers des services gérés dans le cloud.
Parcours de déchiffrement
Toute architecture hybride doit recenser chaque point de terminaison TLS et de rechiffrement, et éviter toute inspection redondante.
Parmi les chemins d'accès courants, on peut citer :
- Connexion d'un utilisateur de bureau à Internet : passerelle locale ou connexion via un tunnel vers un point de présence dans le cloud
- Utilisateur distant connecté à Internet : point de présence dans le cloud ou acheminement vers une passerelle locale
- De l'utilisateur à l'application privée : déterminez si et où le chemin ZTNA sélectionné prend en charge l'inspection TLS
- Session de navigation : contrôles au niveau du navigateur permettant de visualiser le contenu sans décryptage réseau
- Point d'extrémité : inspection par agent sur le terminal
L'un des risques liés aux environnements hybrides réside dans le déchiffrement inopiné et redondant. Une succursale peut acheminer son trafic via un proxy local, puis via un service cloud qui met à nouveau fin à la connexion TLS. Documentez chaque étape d'inspection requise, protégez chaque limite de texte en clair et supprimez les étapes redondantes qui augmentent l'exposition aux risques ou compliquent le dépannage.
Responsabilités liées au certificat
La fiabilité de la vérification TLS dépend entièrement de celle des certificats sur lesquels elle repose ; veillez donc à définir clairement les responsabilités pour chaque étape du cycle de vie des certificats :
- Création et protection des certificats d'authentification. Indiquez où se trouve la clé privée, qui y a accès et si un module HSM est nécessaire. Vérifiez les intégrations HSM prises en charge pour chaque passerelle locale ou service cloud ainsi que la version du produit correspondante ; ne partez pas du principe que la prise en charge est assurée.
- Distribution. Comment l'autorité de certification (CA) est-elle installée dans les magasins de confiance du système d'exploitation et du navigateur sur les appareils gérés, et que se passe-t-il sur les appareils non gérés ?
- Rotation. Le calendrier et la procédure de remplacement de l'agent de contrôle sans interruption de service.
- Validation en amont. Vérifiez que le proxy rejette les certificats de destination non valides, périmés ou révoqués, plutôt que de les masquer aux utilisateurs.
- Prise en charge des protocoles. Le protocole TLS 1.3 (RFC 8446) doit être traité de manière native, sans rétrogradation.
Exceptions en matière de circulation
Aucune organisation ne devrait tout déchiffrer ; veillez donc à tenir à jour une liste des exceptions, documentée et régulièrement révisée :
| Type d'exception | Raison | Manipulation habituelle |
|---|---|---|
| Applications dont le certificat est épinglé | L'inspection interrompt la connexion | Contournement en fonction de la destination ; application des contrôles liés à la réputation et à la catégorie |
| Catégories « Santé », « Finances » et « Vie privée » | Confidentialité des données des salariés, obligations légales et exigences du comité d'entreprise | Contourner le déchiffrement ; continuer à appliquer la politique relative aux catégories |
| Authentification TLS réciproque et par certificat client | Le serveur proxy ne peut pas présenter le certificat client | Contournez cette fonctionnalité ou utilisez une fonction de transfert prise en charge |
| Services de mise à jour et certains protocoles OT | Stabilité et assistance technique du fournisseur | Contournement par destination avec accès restreint |
| QUIC et HTTP/3 (RFC 9000) | De nombreux serveurs proxy ne peuvent pas analyser le protocole QUIC | Bloquez QUIC afin que les navigateurs recourent à TLS sur TCP, ou vérifiez la prise en charge native |
Passez en revue les exceptions chaque trimestre. Les contournements obsolètes constituent souvent un angle mort.
Le « Client Hello » chiffré et ses implications
Le protocole « Client Hello » chiffré masque le nom d'hôte de destination aux observateurs passifs ; il convient donc de repenser la visibilité basée sur le SNI ainsi que certaines décisions relatives au contournement.
Le protocole « Client Hello » chiffré a été publié sous la référence RFC 9849 en 2026. L'ECH chiffre la partie de la négociation TLS qui révélait auparavant le nom d'hôte de destination (la « Server Name Indication », ou SNI) ainsi que d'autres champs. Les outils passifs qui classifient le trafic en analysant la SNI perdent cette visibilité pour les sites utilisant l'ECH.
Les proxys explicites qui mettent fin à la connexion TLS se trouvent dans une situation différente, car ils établissent leurs propres sessions avec les destinations. Malgré tout, l'ECH a des implications opérationnelles :
- Les navigateurs peuvent envoyer des extensions de type ECH même lorsque le protocole ECH n'est pas utilisé ; les outils d'analyse doivent donc les traiter correctement.
- Le RFC indique que, dans les environnements d'entreprise gérés, une approche consiste à désactiver l'ECH via une stratégie de groupe et à compter sur le fait que les clients respectent ce paramètre.
- Les décisions relatives à la catégorie et à la réputation qui reposaient sur le SNI pour le trafic contourné doivent être remplacées par une solution alternative, telle que des contrôles au niveau de la couche DNS ou une configuration explicite du proxy.
Vérifiez la feuille de route ECH de votre prestataire de services d'inspection et testez son comportement avec les versions actuelles des navigateurs.
Exploitation forestière
Les journaux d'inspection peuvent contenir des URL, des identités et des preuves DLP ; leur contenu, leur emplacement et leur accès doivent donc faire l'objet de décisions explicites :
- Quels champs sont enregistrés pour le trafic déchiffré par opposition au trafic contourné ?
- Où sont conservés les journaux, et s'ils peuvent sortir du territoire
- Durées de conservation et personnes autorisées à accéder à l'intégralité des éléments de preuve
- Quels événements sont transmis au SIEM ?
L'inspection locale facilite la conservation des journaux et des preuves sur le territoire national. L'inspection dans le cloud nécessite de vérifier les zones de stockage des journaux du fournisseur ainsi que les contrôles d'accès. Voir la section « Souveraineté des données » dans « Sécurité du cloud hybride ».
Compromis opérationnels
L'inspection locale privilégie l'effort opérationnel au détriment du contrôle, l'inspection dans le cloud privilégie la simplicité au détriment du contrôle, et l'inspection hybride nécessite un moteur de règles unique pour fonctionner.
L'inspection locale nécessite de dimensionner les équipements en fonction des pics de trafic, de maintenir à jour les moteurs d'inspection et de prévoir l'évolution des capacités matérielles ou virtuelles. En contrepartie, elle offre un contrôle total sur le texte en clair, les clés et les journaux relatifs au trafic inspecté localement ; de plus, l'application locale des politiques relatives au Web et aux applications privées se poursuit en cas d'interruption du réseau étendu (WAN) ou du cloud, tandis que les services mis en œuvre dans le cloud du fournisseur sont suspendus jusqu'au rétablissement de la connectivité.
L'inspection dans le cloud transfère la planification des capacités et les mises à jour des moteurs au fournisseur. Elle nécessite toutefois toujours la distribution des certificats, la gestion des exceptions et l'ajustement des politiques, et elle introduit une dépendance vis-à-vis de la disponibilité et de la connectivité du fournisseur.
L'inspection hybride combine les deux, mais ne fonctionne correctement qu'avec un seul moteur de règles. Si les passerelles locales et celles du cloud disposent de listes d'exceptions et de règles DLP distinctes, les utilisateurs seront traités différemment selon leur emplacement.
L'approche de Skyhigh en matière d'inspection sur site et dans le cloud
Skyhigh procède à l'inspection TLS en local lorsque la conformité l'exige, et dans le cloud pour les utilisateurs distants, le tout dans le cadre d'une seule et même politique.
Skyhigh Hybrid SSE Mesh effectue le déchiffrement et l’inspection SSL/TLS localement sur les propres appareils de l’organisation lorsque la conformité l’exige, et dans les points de présence du cloud Skyhigh pour les utilisateurs distants, le tout géré par un seul moteur de politiques. Les politiques « Secure Web Gateway » et «Zero Trust Access» sont appliquées en natif au niveau de la passerelle, tandis que la politique de protection des données est appliquée dans le cloud Skyhigh sur le trafic que la passerelle transfère. Le trafic Web déchiffré sur la passerelle sur site y est inspecté puis rechiffré afin de garantir l’application locale des politiques Web. Lorsqu’une politique fait appel à un service appliqué dans le cloud, tel que la protection des données, la passerelle transfère le trafic concerné vers le cloud Skyhigh, où la même politique est appliquée. Les contrôles de navigateur sécurisés sans agent ajoutent une inspection compatible WebSocket du trafic lié à l’IA et à la messagerie au sein de la session de navigation.
Sources
- NSA. Gestion des risques liés à l'inspection du protocole SSL (novembre 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- CISA. « L'interception HTTPS compromet la sécurité TLS » (Alerte TA17-075A, mars 2017). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF. RFC 8446 : Protocole TLS (Transport Layer Security) version 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF. RFC 9849 : « Client Hello » chiffré par TLS. https://www.rfc-editor.org/rfc/rfc9849.html
- IETF. RFC 9000 : QUIC : un protocole de transport multiplexé et sécurisé basé sur UDP. https://www.rfc-editor.org/rfc/rfc9000.html
- Skyhigh Security. « L'adoption de l'hybride est désormais plus simple grâce à la plateforme Skyhigh SSE » (3 octobre 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
- Skyhigh Security. « Moderniser votre infrastructure Symantec Edge Secure Web Gateway , grâce à Skyhigh Hybrid SSE Mesh » (15 juillet 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html