Introduction correcte de l'inspection TLS sur Sophos Firewall

Avec l’inspection TLS, Sophos Firewall met fin à la connexion cryptée du client et établit une deuxième connexion avec le serveur de destination. Il peut inspecter le texte en clair entre les deux. Le pare-feu re-signe le certificat du serveur présenté au client avec sa propre CA (Certificate Authority). Si le client ne fait pas confiance à cette autorité de certification, il affiche un avertissement de certificat ou met fin à la connexion.

Cela permet d’inspecter le contenu déchiffré, notamment l’analyse antimalware et l’analyse de contenu. Sans décryptage, les fonctionnalités de protection peuvent être limitées, selon le module, à des informations telles que l’adresse IP, le domaine, le SNI, le certificat ou les métadonnées du protocole. Cela ne justifie pas un déploiement initial à grande échelle : l’épinglage des certificats, la confidentialité, la compatibilité des applications et la charge supplémentaire du pare-feu doivent être abordés avant le déploiement.

La version courte sûre est la suivante : déterminer s’il faut utiliser le chemin DPI ou proxy Web, distribuer l’autorité de certification de re-signature à un petit groupe, documenter l’état actuel, créer une règle de décryptage à portée étroite, exécuter un test positif et un test négatif, et n’étendre la portée qu’ensuite.

Décisions à prendre avant le pilote

Licence, CA et responsabilités

Les règles d’inspection SSL/TLS et les groupes d’URL qui y sont utilisés sont appliqués avec la licence Base License. Web Protection n’est pas une condition préalable générale à l’inspection TLS. Il est requis lorsque les catégories Web sont utilisées comme critères de règle ou lorsque les fonctionnalités de protection Web correspondantes sont nécessaires. Les inspections contre les logiciels malveillants, Zero-Day et autres nécessitent chacune l’abonnement correspondant. Quels packs Sophos Firewall sont disponibles ? et Comprendre la licence de base de Sophos Firewall expliquent les différences.

Clarifiez les points suivants avant de créer la première règle :

• Documentez la version SFOS utilisée, la licence disponible et le chemin d’inspection prévu.
• Définissez un groupe pilote géré et une fenêtre horaire claire. L’exemple ci-dessous utilise le client 10.20.30.50 du réseau de test 10.20.30.0/24 ; remplacez ces valeurs par vos propres objets.
• Obtenez l’approbation des parties prenantes responsables de la confidentialité pour la portée, la journalisation, la conservation et la notification des utilisateurs.
• Sauvegardez l’état initial exact de la règle de pare-feu, des règles TLS, du profil de décryptage, de l’autorité de certification et de tous les paramètres globaux.
• Désignez le propriétaire, les critères d’abandon, le processus d’exception et le chemin de restauration.

L’autorité de certification signataire doit se trouver dans le magasin de confiance des systèmes d’exploitation ou des navigateurs concernés. Vous pouvez également utiliser une autorité de certification d’entreprise subordonnée. Une autorité de certification de confiance publique n’est pas disponible à cet effet car le pare-feu re-signe les certificats pour les domaines tiers. Avec une autorité de certification externe, l’autorité de certification racine et l’autorité de certification subordonnée doivent être importées ; si l’autorité de certification signataire contient une section EKU, elle doit autoriser TLS Web Server Authentication. Installer le certificat d’autorité de certification Sophos Firewall pour l’analyse HTTPS décrit la distribution, tandis que Configurer une autorité de certification subordonnée pour l’inspection TLS de Sophos Firewall couvre la méthode d’autorité de certification d’entreprise.

⚠️ Ne commencez pas par tous les utilisateurs. Les appareils sans magasin de confiance gérable, le BYOD et les applications utilisant l’épinglage de certificat doivent initialement rester dans un périmètre distinct. Une exception rétablit la connexion, mais supprime son contenu du déchiffrement.

Gardez le DPI et le proxy Web séparés

SFOS utilise le DPI engine par défaut. Sur ce chemin, le pare-feu traite d’abord la règle de pare-feu, puis les règles d’inspection SSL/TLS. La règle d’inspection elle-même n’autorise pas le trafic : même Services: Any signifie uniquement que le trafic TLS déjà autorisé par la règle de pare-feu sur n’importe quel port TCP est éligible pour cette règle d’inspection.

Pour le chemin DPI, ouvrez Rules and policies > Firewall rules, modifiez la règle LAN-to-WAN appropriée et vérifiez Security features > Web filtering :

1. Laissez Use web proxy instead of DPI engine désactivé.
2. Sélectionnez une politique Web uniquement si la protection prévue l’exige ; ce n’est pas une condition préalable à la règle de décryptage.
3. Scan HTTP and decrypted HTTPS permet d’analyser les logiciels malveillants pour HTTP et HTTPS déjà déchiffrés. L’option elle-même n’active pas le décryptage HTTPS.

Dans Web Proxy Mode, le proxy gère le déchiffrement HTTPS. Decrypt HTTPS during web proxy filtering est le paramètre pertinent sur le chemin du proxy. Les règles DPI sous Rules and policies > SSL/TLS inspection rules ne s’appliquent pas aux connexions déchiffrées par le proxy Web. Avec le proxy transparent, les ports 80 et 443 passent par le proxy tandis que SSL/TLS sur les autres ports peuvent toujours être gérés par le chemin DPI ; avec le proxy explicite, le proxy Web effectue le décryptage.

Les autorités de certification sont également distinctes : DPI utilise l’autorité de certification des paramètres SSL/TLS ou du profil de décryptage sélectionné. Le proxy Web utilise l’autorité de certification de Web > General settings. Lors d’un changement de mode, vérifiez non seulement les règles mais également l’autorité de certification réellement présentée. Choisissez correctement le moteur DPI ou le proxy Web explique les différences plus en détail.

Ce chemin d’inspection sortant n’est pas destiné aux serveurs Web publiés sur Internet. Web Server Protection / WAF ou un proxy inverse est généralement l’architecture la plus appropriée. Les règles d’inspection SSL/TLS s’appliquent au trafic sortant, de sorte que seules les zones internes peuvent être sélectionnées comme Source zones. Elles détectent TLS sur n’importe quel port TCP, mais ne sont pas appliquées sur UDP.

Intégrer QUIC au parcours d’inspection

QUIC, ou HTTP/3, utilise UDP. Block QUIC protocol dans une règle de pare-feu rejette les paquets UDP sortants vers les ports 80 et 443 dans la portée de cette règle, obligeant les clients à revenir à un chemin TCP inspectable. SFOS sélectionne l’option par défaut dès qu’une stratégie Web est sélectionnée dans la règle ou que Scan HTTP and decrypted HTTPS est activé. Ce paramètre s’applique par règle, et non globalement, alors vérifiez la règle de pare-feu qui correspond réellement.

Ce filtre Web ne peut pas analyser QUIC. Cela ne signifie pas que tous les autres contrôles du pare-feu sont contournés, mais le chemin TCP TLS et le filtre Web attendus ne s’appliquent pas. Bloquer correctement QUIC et HTTP/3 sur Sophos Firewall affiche le test de règle ; Création d’une stratégie de protection Web du pare-feu Sophos couvre la stratégie Web.

Sélectionnez le périmètre par objectif et risque

Le point de départ habituel est le trafic utilisateur géré de LAN à WAN. Un réseau Wi-Fi d’entreprise distinct peut ensuite être ajouté avec Wi-Fi > WAN. Pour l’accès à distance, VPN > WAN n’est pertinent que lorsque le trafic Internet des utilisateurs traverse réellement le pare-feu via un tunnel complet. Incluez les connexions internes de LAN vers une DMZ uniquement lorsque l’inspection du contenu présente un avantage évident et que les deux parties font confiance à l’autorité de certification signataire.

La compatibilité technique et l’autorisation de décryptage sont des décisions distinctes. Les portails bancaires, de santé et gouvernementaux, les gestionnaires de mots de passe, les fournisseurs d’identité, les mises à jour du système d’exploitation et des fournisseurs, ainsi que les services vocaux, vidéo et de collaboration nécessitent une évaluation fonctionnelle et de confidentialité avant leur inclusion. L’épinglage ou l’échec d’un pilote ne justifie pas une exception générale pour une catégorie entière : identifiez d’abord la source, le domaine et l’application réellement requis.

Configurer un pilote complet

Pour un pilote pouvant être testé directement, nous utilisons ces exemples de valeurs :

• Client pilote : 10.20.30.50 du réseau de test documenté 10.20.30.0/24
• Règle de pare-feu : LAN to WAN - TLS pilot
• Règle d’inspection SSL/TLS : TLS decrypt pilot client
• Zone source : LAN, Zone destination : WAN
• Réseaux et services de destination : Any
• Action : Decrypt
• Profil de décryptage : initialement Block insecure SSL ou un profil pilote qui en dérive
• Journalisation : Log connections activé pour le pilote

10.20.30.0/24, l’adresse IP de l’hôte et les noms d’objet sont des exemples. La source de production doit être suffisamment étroite pour identifier un client sans ambiguïté. Any pour la destination et le service facilite l’observation de TLS en dehors de TCP 443 pendant le pilote ; cela n’étend pas ce que permet la règle de pare-feu précédente. Si l’inspection n’est autorisée que pour un groupe de destination spécifique, ajoutez un groupe d’URL ou un autre critère de destination approprié.

Sélectionnez un profil de décryptage

Sous Profiles > Decryption profiles, trois profils par défaut non modifiables sont disponibles :

• Maximum compatibility maximise la compatibilité et ne restreint pas les chiffrements.
• Block insecure SSL bloque les chiffrements faibles et autorise le trafic qui ne peut pas être déchiffré.
• Strict compliance applique des exigences strictes, y compris des exigences basées sur PCI DSS.

Maximum compatibility peut aider à isoler temporairement un client problématique, mais ses contrôles souples le rendent inadapté comme critère d’acceptation de la production. Pour le pilote, Block insecure SSL ou un profil délibérément dérivé est le point de départ le plus transparent. Tolérez les anciennes versions TLS ou les clés RSA de moins de 2048 bits uniquement pour un serveur hérité clairement identifié et dans le cadre d’une règle à portée étroite.

Un profil personnalisé peut remplacer les paramètres SSL/TLS globaux. Les options d’autorité de certification de re-signature sont Use CAs defined in SSL/TLS settings, Re-sign RSA with et Re-sign EC with. Pour le trafic qui ne peut pas être déchiffré, les options sont Use SSL/TLS settings default, Allow without decryption, Drop et Reject. La référence globale par défaut ne s’applique pas à Unrecognized cipher suites ; ce cas doit être évalué explicitement dans le profil. Selon le paramètre, les erreurs de certificat, la taille RSA minimale, les versions TLS et les chiffrements bloqués utilisent Drop, Reject ou Reject and notify comme Block action.

L’inspection ne rend pas digne de confiance un certificat de serveur auto-signé ou avec une chaîne incomplète. Au lieu de l’exclure à la hâte, vérifiez d’abord le nom d’hôte, le certificat original et la chaîne complète.

Avec TLS 1.3, les erreurs de certificat, la taille RSA minimale, une rétrogradation globale et Reject and notify se comportent comme documenté uniquement avec Action: Decrypt. Avec Don’t decrypt ou Deny, Reject est utilisé à la place pour cette gestion de profil. Une rétrogradation globale vers TLS 1.2 introduit un risque de sécurité et ne constitue pas un correctif de compatibilité général.

Créez la règle et vérifiez son ordre

Sous Rules and policies > SSL/TLS inspection rules > Add, définissez les champs comme suit :

1. Rule name: TLS decrypt pilot client
2. Rule position: Top, la règle pilote précède donc les règles de décryptage générales personnalisées
3. Action: Decrypt
4. Log connections: activé pour la surveillance pilote
5. Decryption profile: le profil pilote sélectionné
6. Source zones: LAN
7. Source networks and devices: objet hôte pour 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: vide ou limité à la portée de destination approuvée

Log connections est facultatif et n’est pas obligatoire pour que la règle fonctionne. Il est néanmoins utile pour un pilote limité dans le temps car la négociation TLS et la fermeture de la connexion peuvent être tracées. La conservation doit respecter la politique de confidentialité et d’exploitation convenue.

Le tableau est évalué de haut en bas et le traitement s’arrête à la première correspondance. Tous les critères configurés doivent correspondre simultanément. La règle par défaut fixe Exclusions by website or category reste en haut et ne peut pas être précédée de la sélection de Rule position: Top. Placez les exceptions Don't decrypt personnalisées immédiatement en dessous, suivies de règles pilotes spécifiques et, enfin, de règles de décryptage plus larges.

Les critères d’utilisateur et de groupe ne sont fiables que si SFOS connaît le contexte utilisateur de la connexion. Si cela n’est pas garanti, commencez par un hôte ou un objet réseau sans ambiguïté et ajoutez des critères d’identité uniquement après un test de correspondance distinct.

Limitez les exceptions

La règle par défaut Exclusions by website or category utilise Don’t decrypt avec Maximum compatibility et reste en première position. La liste Local TLS exclusion list est vide par défaut ; la liste Managed TLS exclusion list contient des sites incompatibles connus et est maintenue via des mises à jour du micrologiciel.

Modifiez la liste locale à :

Web > URL groups > Local TLS exclusion list

Les groupes d’URL ou les correspondances SNI sont plus efficaces pour les exceptions de domaine que de nombreux hôtes FQDN. Selon Sophos, par exemple, 200 hôtes FQDN entraînent 200 recherches pour chaque nouvelle connexion SSL/TLS. Les exceptions Source et Destination ne peuvent pas non plus être combinées. Créer et utiliser des groupes d’URL en toute sécurité explique la portée du domaine, les caractères génériques et les tests négatifs.

Une règle d’inspection SSL/TLS personnalisée avec Action: Don’t decrypt doit enregistrer le domaine, la source concernée, la raison, le ticket, le propriétaire et la date de révision. Don’t decrypt n’est pas un contournement inconditionnel : les restrictions du profil de décryptage sélectionné s’appliquent toujours. Pour autoriser SSL 2/3, la compression ou les chiffrements inconnus pour un cas hérité explicitement approuvé, utilisez un profil avec Allow without decryption avec Action: Don’t decrypt. Cette combinaison n’appartient pas à une règle générale d’Internet.

Les exclusions SSL/TLS et les exceptions Web résolvent différents problèmes. Une exception TLS contrôle le décryptage sur n’importe quel port TCP en mode DPI. Une exception Web modifie les vérifications de stratégie Web sélectionnées ; en mode proxy, cela affecte le chemin proxy concerné. Avant d’effectuer une modification, déterminez si le décryptage ou uniquement une vérification Web doit être exclu. Créer et tester des exceptions Web en toute sécurité affiche le flux de travail de sélection et d’expression régulière.

Prise en charge d’Android avec une portée étroite

Certaines connexions Android utilisent l’épinglage de certificat. La vérification de la connectivité, le Play Store ou les mises à jour peuvent alors échouer sous le décryptage. Le workflow documenté par Sophos utilise un VLAN ou un réseau sans fil isolé et un groupe d’hôtes FQDN contenant :

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• le domaine Google local, par exemple *.google.ch en Suisse

Au-dessus de la règle générale de décryptage, ajoutez une règle d’inspection SSL/TLS avec Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone: Wi-Fi, le réseau d’appareils mobiles comme Source networks and devices, WAN comme Destination zone et le groupe Google comme Destination networks. Elle se situe en dessous de l’exclusion par défaut fixe mais au-dessus de la règle générale de décryptage. Gardez le réseau mobile isolé des ressources internes sensibles.

Validez la configuration à l’aide d’un appareil pilote Android : exécutez la vérification de la connectivité, le navigateur, le téléchargement et la mise à jour du Play Store. Dans Log viewer, seules les destinations Google attendues doivent correspondre à l’exception ; une autre destination HTTPS du même VLAN doit toujours utiliser la règle de décryptage prévue. Ce test négatif empêche l’acceptation d’une exception qui fonctionne mais qui est trop large. Créez des exceptions Web et des exclusions TLS en toute sécurité couvre d’autres méthodes et limitations SNI.

Vérifier l’efficacité

Une simulation de politique, un client réel et les journaux répondent à différentes questions. Combinez-les pour un test d’acceptation fiable.

Sous Diagnostics > Tools > Pop-out tools > Policy tester, sélectionnez Firewall, SSL/TLS, and web et définissez l’adresse IP source, la destination ou l’URL, le protocole et, si nécessaire, le port. Sans protocole, l’outil teste HTTP à l’aide du port par défaut spécifique au protocole. Le testeur de politiques simule un trafic Web transparent ; il ne modélise pas les routes SD-WAN et les règles avec les adresses MAC sous Source networks and devices n’y correspondent pas. Web policy only teste uniquement la stratégie Web. Le résultat est donc une prédiction et non une preuve du chemin réel des données.

Exécutez quatre tests ciblés sur le client :

1. Avant le changement, enregistrez le domaine de destination, l’émetteur du certificat, le temps de réponse et si l’application métier fonctionne.
2. Ouvrez une destination positive approuvée. Le navigateur doit afficher l’autorité de certification de re-signature sélectionnée pour DPI en tant qu’émetteur, et le Log viewer doit montrer une correspondance avec la règle de décryptage et le profil de décryptage attendus.
3. Ouvrez une destination délibérément exclue. Elle doit correspondre à la règle Don't decrypt attendue ; le navigateur ne doit pas y afficher un certificat re-signé par le pare-feu.
4. Une deuxième destination non exclue de la même étendue client doit encore être déchiffrée. C’est le test négatif de l’exception.

Si une politique Web fait partie de la conception, bloquez également une catégorie de test ou une URL de test spécifiquement approuvée à cet effet. Exécutez un test de malware uniquement avec un objet de test fournisseur documenté et inoffensif et un résultat attendu prédéfini ; cet article ne prétend pas être un test de laboratoire. Avant et après le pilote, comparez la charge du processeur et de la mémoire, le temps de réponse et les erreurs utilisateur sur la même fenêtre temporelle.

Interpréter correctement Control Center et Log viewer

Le widget Control Center s’appelle SSL/TLS connections. Ses détails sont mis à jour toutes les cinq minutes. Les sessions couvrent les dernières 24 heures et les erreurs les derniers 7 jours ; Failed se réinitialise à minuit. Les données détaillées n’incluent pas les connexions au proxy Web. Decryption peak apparaît uniquement à proximité ou au-dessus du pic, et Decryption limit uniquement à proximité de la limite spécifique à l’appareil. Il n’existe donc pas de seuil universel pour tous les appareils.

Ouvrez le Log viewer en haut à droite et sélectionnez le module SSL/TLS inspection. Une connexion TLS est enregistrée une fois la négociation terminée et lors de sa fermeture. L’action, la règle, le profil de décryptage, la source, la destination, le domaine et la raison de l’erreur sont importants ; les couleurs ne constituent pas à elles seules un critère d’acceptation fiable. Sous Manage > Exclude, vous pouvez ajouter des domaines ou des sous-domaines à la liste d’exclusion TLS locale et des catégories à l’exclusion par défaut. Exclude n’est pas disponible pour les ID d’erreur 19004 et 19005.

Un événement Don't decrypt prouve uniquement que la connexion n’a pas été déchiffrée. Seuls la règle, la correspondance de liste et le test négatif indiquent si l’exception est justifiée et suffisamment étroite.

Circonscrire les erreurs et annuler les modifications

Lorsqu’un incident se produit, limitez initialement le cas à un client, un domaine, un moment précis, une règle de pare-feu et une règle d’inspection SSL/TLS.

• Si le navigateur affiche un avertissement de certificat, comparez l’émetteur visible avec l’autorité de certification utilisée par le chemin DPI ou proxy réel. Vérifiez ensuite le magasin de confiance du client, la chaîne racine/subordonnée et le nom d’hôte.
• Si des événements SSL/TLS sont manquants, vérifiez d’abord la correspondance de la règle du pare-feu et le mode. Confirmez ensuite que Rules and policies > SSL/TLS inspection rules et Advanced settings > SSL/TLS engine > Enabled sont actifs.
• Si le trafic est autorisé mais pas déchiffré, recherchez de haut en bas l’exclusion par défaut fixe, la liste gérée/locale ou une règle Don't decrypt personnalisée. Répétez ensuite le test négatif.
• Si le filtre Web ne s’applique pas, vérifiez la règle de pare-feu actuelle pour sa politique Web, Scan HTTP and decrypted HTTPS, Block QUIC protocol et le mode DPI/proxy. La présence d’une Web Policy ne prouve pas le décryptage.
• Si une seule application échoue, utilisez la raison de l’erreur, la version TLS, le chiffrement, la chaîne de certificat et l’épinglage pour guider la décision suivante. Limitez toute exception temporaire et attribuez-lui une date de révision.
• Si la charge augmente, réduisez la portée du pilote et comparez la même fenêtre temporelle avant et après le changement. Évaluez les avis de pointe ou de limite pour l’appareil spécifique.

Désactivez le SSL/TLS engine seulement brièvement pour le dépannage. Lorsqu’il est désactivé, aucune règle d’inspection SSL/TLS ne s’applique et le moteur DPI n’applique pas la politique Web du pare-feu au HTTPS ; le déchiffrement HTTPS du proxy Web n’est pas affecté. Le désactiver n’est donc pas un substitut équivalent et à faible risque à la désactivation spécifique de la règle pilote.

Testez l’IPS indépendant du port uniquement avec un état initial connu

Par défaut, SFOS vérifie le trafic déchiffré par rapport aux signatures IPS sur chaque port TCP. Pour un faux positif reproductible, documentez l’ID de signature, la source, la destination, le port TCP, la règle de pare-feu, la règle d’inspection et la version SFOS. Préférez une exception de signature étroite avec Action: Allow packet dans la stratégie IPS actuellement utilisée ; Configurer et tester Sophos Firewall IPS décrit cette méthode.

Un symptôme possible d’un problème lié à l’inspection indépendante du port est la détection répétée de la même signature IPS sur le même site Web. La répétition seule ne prouve pas un faux positif. On vérifie la correspondance exacte de la Signature ID et de la destination dans les journaux, on contrôle le processus de travail légitime concerné et on évalue le risque avant d’approuver une exception de signature à portée étroite et réversible.

L’inspection plus approfondie des menaces potentielles peut augmenter la charge et réduire légèrement le débit du trafic HTTPS déchiffré par rapport aux anciennes versions de Sophos Firewall. Il s’agit d’un effet possible lié à la version, et non d’une baisse garantie ni d’une preuve de régression du build actuellement utilisé. Pour contextualiser les résultats, on compare le débit, la charge CPU et mémoire ainsi que le temps de réponse avec une charge de trafic comparable dans la même fenêtre temporelle ; une seule comparaison ne remplace pas une analyse des causes.

Une comparaison globale dans la console de l’appareil n’est autorisée que si la valeur actuelle exacte, on ou off, est déjà connue à partir de l’enregistrement des modifications ou d’une configuration sauvegardée de manière fiable. La documentation officielle du SFOS 22 ne donne aucune vérification préalable en lecture seule pour ce commutateur. Si l’état initial est inconnu, n’effectuez pas le test.

Ce n’est qu’avec un état initial documenté de on que vous pouvez définir les éléments suivants pour une comparaison préparée :

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

La deuxième commande ici restaure uniquement l’état initial connu de on. Si l’état initial était off, ne l’activez pas aveuglément ; conservez off ou restaurez-le exactement après toute modification autorisée. Ce paramètre global affecte l’ensemble du pare-feu et peut réduire légèrement le débit ou, avec off, restreindre la portée de l’inspection. Documentez le résultat et la fenêtre de temps sans considérer cela seul comme la preuve d’une cause générale.

Effectuer le rollback dans un ordre défini

Un rollback restaure l’état initial documenté plutôt que d’introduire une nouvelle architecture :

1. Désactivez la règle pilote TLS decrypt pilot client. Ne modifiez pas le profil, la politique Web et les exceptions en même temps.
2. À l’aide du client pilote, confirmez que cette règle ne correspond plus et que le chemin précédemment documenté est à nouveau utilisé. Ne présumez pas que les sessions existantes sont immédiatement réévaluées ; établissez une nouvelle connexion pour le test.
3. Si une seule destination est affectée et que les opérations l’exigent, créez une exception Don't decrypt limitée dans le temps et exécutez son test négatif.
4. Après approbation, supprimez les exceptions temporaires, les objets de test et les paramètres CA distribués uniquement pour le pilote de manière contrôlée. Ne supprimez pas les autorités de certification partagées sans vérifier.
5. Enregistrez l’ID de règle, le client, la destination, l’autorité de certification visible, l’événement de journal, l’heure et les paramètres restaurés dans l’enregistrement des modifications.

La stratégie Web peut rester configurée, mais sans décryptage, elle ne peut pas analyser la charge utile HTTPS chiffrée. Revenir au proxy Web uniquement s’il s’agit de l’état initial vérifié. Ne désactivez pas l’intégralité du moteur SSL/TLS en tant que restauration standard, car cela arrête toutes les règles DPI TLS et l’application de la politique Web DPI à HTTPS.

Arrêtez le déploiement dès qu’une application critique pour l’entreprise tombe en panne, que des avertissements de certificat apparaissent en dehors du groupe pilote, que la portée correspond plus largement que prévu ou que la charge et les erreurs dépassent les limites prédéfinies. Développez le groupe Source progressivement seulement après que le test positif, le test négatif d’exception, les applications métier, les journaux, les commentaires des utilisateurs et le profil de charge répondent tous aux critères convenus tout au long de la période convenue.

Pendant le fonctionnement, examinez les exclusions, les erreurs TLS, les nouvelles applications, la charge et les commentaires des utilisateurs selon un calendrier défini. Conservez les exceptions temporaires uniquement pendant que le propriétaire, le motif et la date de révision restent valides ; sinon, retirez-les après un nouveau test positif et négatif.

FAQ