Maîtrisez la Confidentialité de Vos Données : Le Guide Ultime pour les Règles de Non-Déchiffrement sur Netskope

Découvrez comment exempter spécifiquement certains flux de données de l'inspection SSL/TLS sans compromettre votre posture de sécurité globale.

Les Points Essentiels à Retenir

Précision Chirurgicale : Les règles de non-déchiffrement permettent d'exclure sélectivement du trafic de l'inspection SSL/TLS, essentiel pour la confidentialité des données sensibles (financières, médicales) ou la compatibilité avec certaines applications (ex: celles utilisant l'épinglage de certificat).
Contrôle Granulaire : Configurez ces règles en vous basant sur des critères multiples tels que les utilisateurs, les groupes, les domaines, les catégories d'URL, les adresses IP sources ou les applications spécifiques pour un ciblage précis.
Compromis Éclairé : Bien que Netskope continue de journaliser les métadonnées du trafic non déchiffré, l'inspection approfondie (DLP, protection contre les menaces) est limitée. Utilisez ces règles judicieusement après une analyse des risques.

Qu'est-ce qu'une Règle de Non-Déchiffrement Netskope ?

Dans l'écosystème de sécurité Netskope, une règle de non-déchiffrement (souvent appelée "Do Not Decrypt" ou DND) est une configuration spécifique au sein des politiques de déchiffrement SSL/TLS. Par défaut, pour assurer une sécurité maximale, Netskope est conçu pour déchiffrer le trafic SSL/TLS afin d'inspecter son contenu à la recherche de menaces, de fuites de données (DLP), et pour appliquer des politiques d'accès granulaires. Cependant, il existe des scénarios légitimes où ce déchiffrement n'est pas souhaitable ou possible.

Une règle de non-déchiffrement permet donc aux administrateurs de définir des exceptions à ce comportement par défaut. Lorsqu'un flux de trafic correspond aux critères d'une règle de non-déchiffrement, Netskope laisse ce trafic chiffré. Bien que le contenu ne soit pas inspecté en profondeur, Netskope agit toujours comme un proxy pour ce trafic, ce qui signifie qu'il peut toujours journaliser les métadonnées (comme la source, la destination, le volume de données) et potentiellement appliquer certaines politiques de contrôle d'accès basées sur ces informations limitées.

Ces règles sont cruciales pour équilibrer les besoins de sécurité avec les exigences de confidentialité, de conformité et de fonctionnalité technique de certaines applications ou services.

Quand Faut-il Envisager une Règle de Non-Déchiffrement ?

La décision d'implémenter une règle de non-déchiffrement doit être mûrement réfléchie. Voici les cas d'usage les plus courants et les facteurs à considérer :

Cas d'Usage Courants

Protection des Données Sensibles et Conformité

Pour certains types de trafic, comme les communications bancaires, les données médicales personnelles ou d'autres informations hautement confidentielles, les réglementations (telles que le RGPD, HIPAA) ou les politiques internes peuvent interdire le déchiffrement par des tiers, même à des fins de sécurité. Une règle de non-déchiffrement garantit que ces données restent chiffrées de bout en bout lors de leur transit via Netskope.

Applications avec Épinglage de Certificat (Certificate Pinning)

Certaines applications, notamment mobiles ou des logiciels spécifiques, utilisent une technique de sécurité appelée "épinglage de certificat". Cela signifie que l'application s'attend à communiquer avec un serveur présentant un certificat SSL/TLS bien précis. Si Netskope (ou tout autre proxy de déchiffrement) tente d'intercepter et de déchiffrer ce trafic en présentant son propre certificat, l'application détectera cette "anomalie" et bloquera la connexion. Pour ces applications, une règle de non-déchiffrement est indispensable pour assurer leur bon fonctionnement.

Problèmes de Performance ou de Compatibilité

Dans de rares cas, le processus de déchiffrement/rechiffrement peut introduire une latence perceptible pour certaines applications très sensibles au temps de réponse, ou causer des problèmes de compatibilité avec des protocoles non standards ou des implémentations SSL/TLS atypiques. Bien que Netskope soit optimisé pour minimiser ces impacts, une règle de non-déchiffrement peut être une solution temporaire ou ciblée pendant que les problèmes sous-jacents sont investigués.

Trafic Invité ou Spécifique

Le trafic généré par des utilisateurs invités ou des segments réseau spécifiques pour lesquels une inspection approfondie n'est pas jugée nécessaire ou prioritaire peut également être candidat à une règle de non-déchiffrement pour simplifier la gestion et réduire la charge de traitement.

Visualisation des Facteurs de Décision

Le graphique radar ci-dessous illustre comment différents cas d'usage peuvent peser sur les facteurs décisionnels pour implémenter une règle de non-déchiffrement. Les scores plus élevés indiquent une plus grande importance du facteur pour ce cas d'usage. 'Exposition aux Risques Accrus' signifie qu'un score élevé indique une plus grande exposition potentielle si le trafic n'est pas déchiffré.

Guide Détaillé : Créer Votre Règle de Non-Déchiffrement sur Netskope

La création d'une règle de non-déchiffrement dans Netskope se fait via l'interface d'administration. Voici les étapes à suivre :

Interface de création de politique de déchiffrement SSL Netskope

Interface de la section "SSL Decryption" où les politiques sont gérées.

1. Accès à la Console Netskope et Navigation

Connectez-vous à votre console d'administration Netskope avec des identifiants disposant des droits nécessaires. Une fois connecté, naviguez vers la section des politiques de déchiffrement SSL. Typiquement, cela se trouve sous : Policies > SSL Decryption.

2. Ajout d'une Nouvelle Politique de Déchiffrement SSL

Sur la page "SSL Decryption", vous verrez une liste des politiques existantes. Cliquez sur le bouton Add Policy (Ajouter une politique) pour initier la création d'une nouvelle règle.

3. Configuration des Critères de Concordance (Match Criteria)

C'est ici que vous spécifiez quel trafic sera concerné par cette règle de non-déchiffrement. Vous devez définir au moins un critère. Netskope offre une grande flexibilité :

User (Utilisateur) / User Group (Groupe d'utilisateurs) : Ciblez des utilisateurs spécifiques ou des groupes d'utilisateurs (souvent synchronisés depuis votre annuaire Active Directory).
Source IP Addresses (Adresses IP Source) : Appliquez la règle en fonction de l'adresse IP d'origine du trafic.
Domain (Domaine) / URL : Spécifiez des noms de domaine exacts (ex: banqueexemple.com), des domaines avec jokers (ex: *.servicesfinanciers.com) ou des URL spécifiques.
Category (Catégorie) : Utilisez les catégories d'URL prédéfinies par Netskope (ex: "Financial Services", "Health and Medicine") pour cibler des ensembles de sites.
Application : Sélectionnez des applications cloud spécifiques identifiées par Netskope.

Lorsque vous combinez plusieurs types de critères (ex: Utilisateur ET Domaine), l'opérateur logique AND est appliqué. Si vous spécifiez plusieurs valeurs pour un même type de critère (ex: Catégorie "Finance" OU Catégorie "Santé"), l'opérateur logique OR est appliqué.

Le tableau suivant résume les principaux types de critères et leurs usages :

Type de Critère	Description	Exemples d'Utilisation
Utilisateur / Groupe	Cible la politique en fonction de l'identité de l'utilisateur ou de son appartenance à un groupe.	Exclure le trafic du département financier vers des sites bancaires spécifiques.
Domaine / URL	Cible la politique en fonction du nom de domaine ou de l'URL de destination.	Ne pas déchiffrer les connexions vers `*.microsoftonline.com` pour éviter les problèmes avec les applications Office 365 utilisant l'épinglage.
Catégorie Web	Cible la politique en fonction de la catégorie du site web visité.	Ne pas déchiffrer tout le trafic classé dans la catégorie "Services Médicaux".
Adresse IP Source	Cible la politique en fonction de l'adresse IP d'origine du client.	Exclure du déchiffrement le trafic provenant d'un segment réseau invité.
Application	Cible la politique en fonction de l'application cloud identifiée par Netskope.	Ne pas déchiffrer le trafic vers une application SaaS spécifique connue pour ses problèmes de compatibilité avec le déchiffrement SSL.

4. Définition de l'Action : "Do Not Decrypt"

Dans la section "Action" de la configuration de la politique, sélectionnez l'option Do Not Decrypt (Ne pas déchiffrer). C'est cette action qui indique à Netskope de laisser le trafic correspondant chiffré.

5. Sauvegarde, Activation et Application de la Politique

Une fois tous les paramètres configurés :

Donnez un nom descriptif à votre politique.
Sauvegardez la politique (bouton Save).
Par défaut, les nouvelles politiques peuvent être désactivées. Assurez-vous qu'elle est activée (il y a généralement un interrupteur ou une case à cocher dans la liste des politiques).
Enfin, et c'est une étape cruciale, vous devez appliquer les changements de configuration pour que la nouvelle politique prenne effet. Recherchez un bouton tel que Apply Changes en haut à droite de la page des politiques. Si ce bouton n'est pas grisé ou si une icône d'avertissement jaune apparaît à côté de vos règles, cela signifie que vos modifications n'ont pas encore été validées et que votre politique ne sera pas appliquée.

6. Vérification de la Règle

Après avoir appliqué la politique, il est impératif de vérifier qu'elle fonctionne comme prévu. Vous pouvez :

Tester l'accès aux sites/applications concernés depuis un poste client approprié.
Consulter les journaux d'événements (Skope IT) dans Netskope. Le trafic qui correspond à une règle de non-déchiffrement peut y être identifié. Certaines sources suggèrent d'utiliser des requêtes de recherche avancée, comme "bypass_traffic eq yes and ssl_decrypt_policy eq yes" pour identifier les flux contournant le déchiffrement SSL (la syntaxe exacte peut varier).
Utiliser des outils de développement de navigateur pour inspecter le certificat du site : s'il s'agit du certificat original du site et non du certificat de Netskope, le trafic n'est pas déchiffré.

Vue d'Ensemble du Processus et de ses Implications

La carte mentale ci-dessous synthétise les aspects clés de la création et de la gestion des règles de non-déchiffrement sur Netskope, des motivations initiales aux bonnes pratiques à adopter.

mindmap root["Création d'une Règle de Non-Déchiffrement sur Netskope"] Pourquoi?["Pourquoi créer une règle DND?"] Confidentialite["Confidentialité des données
(financières, médicales)"] Conformite["Conformité réglementaire
(RGPD, HIPAA)"] Technique["Raisons techniques
(ex: épinglage de certificat)"] Performance["Problèmes de performance
ou de compatibilité applicative"] Comment?["Comment créer la règle?"] Acces["1. Accès Console Netskope"] Navigation["2. Policies > SSL Decryption"] Ajout["3. Cliquer 'Add Policy'"] Criteres["4. Définir Critères de Concordance
(Utilisateur, Domaine, Catégorie, IP, etc.)"] Action["5. Sélectionner Action 'Do Not Decrypt'"] Sauvegarde["6. Sauvegarder, Activer et Appliquer
les changements"] Criterescles["Critères de Concordance Clés"] Utilisateur["Utilisateur / Groupe d'utilisateurs"] Domaine["Domaine / URL (avec jokers si besoin)"] Categorie["Catégorie Web prédéfinie"] IP["Adresse IP Source / Destination"] Application["Application Cloud spécifique"] Impacts["Impacts et Limitations"] Visibilite["Réduction de la visibilité
sur le contenu du trafic chiffré"] SecuriteLimitee["Limitations pour les fonctions DLP,
détection de menaces avancée,
et politiques d'accès granulaires"] Proxy["Netskope agit toujours comme proxy
(journalisation des métadonnées)
mais n'inspecte pas le contenu"] BonnesPratiques["Bonnes Pratiques"] Specificite["Être le plus spécifique possible
dans les critères pour limiter la surface d'exemption"] Limitation["Utiliser avec parcimonie,
uniquement lorsque c'est nécessaire"] Verification["Vérifier et tester minutieusement
l'effet de la règle"] Documentation["Documenter la raison d'être
de chaque règle de non-déchiffrement"] Revue["Réviser périodiquement les règles
pour s'assurer de leur pertinence continue"]

Comprendre le Contournement HTTPS et ses Implications dans Netskope

Bien que distincte du "non-déchiffrement", la notion de "contournement HTTPS" (HTTPS Bypass) est parfois évoquée dans des contextes similaires. Il est important de comprendre que ne pas déchiffrer le trafic signifie que Netskope ne peut pas inspecter son contenu pour des menaces ou des fuites de données. La vidéo ci-dessous, bien que traitant du contournement de certaines protections, peut offrir un aperçu des scénarios où le trafic n'est pas entièrement analysé par la plateforme, ce qui est une conséquence directe des règles de non-déchiffrement.

Cette vidéo (en anglais) aborde le contournement de certaines fonctionnalités de sécurité, illustrant les conséquences potentielles lorsque le trafic n'est pas pleinement inspecté.

En configurant une règle "Do Not Decrypt", vous acceptez consciemment cette limitation de visibilité pour le trafic concerné, en privilégiant la confidentialité, la conformité ou la fonctionnalité applicative.

Implications et Bonnes Pratiques

Impact sur la Sécurité et la Visibilité

La principale implication d'une règle de non-déchiffrement est la réduction de la visibilité sur le trafic concerné. Sans déchiffrement, Netskope ne peut pas :

Inspecter le contenu pour détecter des malwares, ransomwares ou autres menaces.
Appliquer des politiques de prévention de perte de données (DLP) pour identifier et bloquer la fuite d'informations sensibles.
Mettre en œuvre des contrôles d'accès granulaires basés sur le contenu ou les actions spécifiques au sein d'une application (ex: interdire le téléchargement de fichiers depuis une application cloud spécifique).

Netskope pourra toujours voir les métadonnées de la connexion (adresses IP, domaines, ports), mais le "quoi" et le "comment" des données échangées resteront opaques. C'est un compromis à évaluer soigneusement.

Bonnes Pratiques Recommandées

Pour minimiser les risques et maximiser l'efficacité de votre configuration Netskope :

Principe du moindre privilège : N'appliquez des règles de non-déchiffrement que lorsque c'est absolument nécessaire. Soyez aussi spécifique que possible dans vos critères de correspondance pour limiter la portée de l'exception. Évitez les règles trop larges (ex: ne pas déchiffrer tout le trafic d'une catégorie entière si seulement quelques sites posent problème).
Documentation : Documentez la raison d'être de chaque règle de non-déchiffrement. Cela facilitera les audits futurs et la maintenance.
Révision Périodique : Les besoins et les applications évoluent. Révisez régulièrement vos règles de non-déchiffrement pour vous assurer qu'elles sont toujours justifiées et correctement configurées. Une application qui nécessitait une exception pourrait avoir été mise à jour et ne plus en avoir besoin.
Ne pas utiliser comme solution par défaut : Si une application rencontre des problèmes, investiguez d'abord la cause racine avant de créer une règle de non-déchiffrement. Contactez le support Netskope ou votre partenaire d'implémentation pour du dépannage.
Surveillance Compensatoire : Si vous devez exempter un volume important de trafic, envisagez des mesures de surveillance ou de sécurité compensatoires pour les systèmes concernés, si possible.

Foire Aux Questions (FAQ)

Pourquoi ma règle de non-déchiffrement ne semble-t-elle pas fonctionner ? ▾

Plusieurs raisons peuvent l'expliquer :

Ordre des politiques : L'ordre dans lequel Netskope évalue les politiques peut avoir un impact. Assurez-vous que votre règle de non-déchiffrement est évaluée avant d'autres politiques qui pourraient prendre le dessus.
Critères incorrects : Vérifiez que les critères de correspondance (domaine, utilisateur, catégorie, etc.) sont exacts et ciblent bien le trafic souhaité. Une simple faute de frappe peut suffire.
Changements non appliqués : Assurez-vous d'avoir cliqué sur "Apply Changes" après avoir créé ou modifié la politique. Sans cela, les modifications ne sont pas actives.
Conflits de politiques : Une autre politique plus générale ou plus spécifique pourrait interférer.
Problèmes de steering : Le trafic n'est peut-être pas correctement dirigé vers Netskope pour que la politique s'applique.

Quelles sont les principales conséquences de ne pas déchiffrer le trafic ? ▾

La conséquence majeure est une perte de visibilité sur le contenu de ce trafic. Cela signifie que Netskope ne pourra pas effectuer d'inspection approfondie pour :

La détection de menaces (malwares, phishing).
L'application des politiques de prévention des pertes de données (DLP).
L'application de contrôles d'accès granulaires basés sur des actions spécifiques au sein des applications.

Essentiellement, vous échangez une partie de la capacité d'inspection et de protection contre la garantie de confidentialité ou la compatibilité technique pour ce trafic spécifique.

Puis-je appliquer des règles de non-déchiffrement à des utilisateurs ou groupes spécifiques ? ▾

Oui, absolument. Netskope permet de définir des critères de correspondance basés sur l'utilisateur ("User") ou le groupe d'utilisateurs ("User Group"). C'est une bonne pratique pour limiter la portée de la règle de non-déchiffrement uniquement aux personnes ou départements qui en ont réellement besoin (par exemple, le département financier pour l'accès à certains portails bancaires spécifiques).

Comment Netskope gère-t-il le trafic qui correspond à une règle "Do Not Decrypt" ? ▾

Lorsque le trafic correspond à une règle "Do Not Decrypt", Netskope :

Laisse la session SSL/TLS chiffrée. Il n'y a pas d'interception Man-in-the-Middle pour ce flux.
Agit toujours comme un proxy pour la connexion, ce qui signifie qu'il relaie le trafic entre le client et le serveur de destination.
Peut journaliser les métadonnées de la connexion (IP source/destination, domaine, port, volume de données, etc.) dans les journaux Skope IT.
Ne peut pas appliquer de politiques de sécurité qui nécessitent une inspection du contenu (DLP, anti-malware, etc.) sur ce trafic spécifique.
Peut générer des alertes d'événement Skope IT spécifiques si le trafic est abandonné en raison d'une correspondance de politique de protection en temps réel lors de la recherche de politique de déchiffrement SSL, mais sans notification à l'utilisateur.

Est-il recommandé de ne pas déchiffrer tout le trafic par défaut ? ▾

Non, ce n'est généralement pas recommandé. Le déchiffrement SSL/TLS est une capacité clé des solutions de sécurité modernes comme Netskope, car une grande partie du trafic web et applicatif est chiffrée. Sans déchiffrement, la plateforme perd une grande partie de son efficacité pour détecter les menaces, prévenir les fuites de données et appliquer des contrôles fins. La recommandation est d'activer le déchiffrement SSL autant que possible, et d'utiliser les règles de "Do Not Decrypt" de manière ciblée et justifiée pour des exceptions spécifiques (confidentialité, compatibilité technique, conformité).