Inspection TLS est utilisé pour détecter et empêcher les menaces avancées sur des canaux TLS chiffrés. La fonctionnalité Inspection TLS déchiffre de manière transparente le trafic chiffré et le rend disponible pour des fonctionnalités de sécurité avancées, telles qu'IDS/IPS, la protection contre les programmes malveillants et le filtrage d'URL. Cela fournit une visibilité du trafic chiffré sans déchargement, tout en conservant le chiffrement de bout en bout.
Sans l'inspection TLS, même si vous activez toutes les fonctionnalités de sécurité avancées pour le pare-feu de passerelle, vous ne pouvez pas appliquer ou avoir une visibilité du trafic chiffré qui peut avoir masqué des programmes malveillants dans les paquets. Le déchiffrement TLS permet aux administrateurs de disposer d'un contrôle d'accès, et d'une détection et d'une prévention des menaces plus efficaces dans le trafic chiffré.
- Prise en charge de l'inspection TLS
- Concepts d'inspection TLS
- Stratégies d'inspection TLS
- Création de profils d'action de déchiffrement TLS
- Gestion des certificats d'inspection TLS
Prise en charge de l'inspection TLS
Cette rubrique décrit la prise en charge de la fonctionnalité Inspection TLS dans NSX-T Data Center.
La prise en charge de l'inspection TLS inclut :
- Prise en charge sur les passerelles de niveau 1 uniquement.
- TLS version 1.0 jusqu'à 1.2 est pris en charge. TLS 1.2 avec PFS (Perfect Forward Secrecy) est pris en charge. Si la version 1.3 est utilisée, le proxy NSX négocie avec une version antérieure et établit une connexion.
- Utilisation de l'indication du nom du serveur (SNI) TLS dans le message Client Hello de TLS pour classer le trafic.
- Visibilité du trafic chiffré sans déchargement tout en conservant le chiffrement de bout en bout.
- Déchiffrement TLS sur les pare-feu de passerelle pour intercepter le trafic et le déchiffrer pour le flux vers les fonctionnalités avancées de sécurité du pare-feu.
- Stratégies d'Inspection TLS pour créer un ensemble de règles qui décrivent les conditions à faire correspondre et effectuer une action prédéfinie.
- Les règles de stratégie d'inspection TLS prennent en charge le contournement, les profils d'action de déchiffrement externe et interne.
Concepts de Inspection TLS
Inspection TLS détecte et empêche les menaces avancées dans votre réseau via des canaux TLS chiffrés. Cette rubrique inclut les concepts associés aux fonctionnalités Inspection TLS.
Protocole TLS
- TLS lance une session TLS sur une session TCP établie entre le client et le serveur (également appelée établissement d'une liaison TLS en trois temps).
- Le client envoie un message Client Hello qui inclut la version et le chiffrement TLS pris en charge, ainsi que l'extension SNI (Server Name Indication, Indication du nom du serveur). Inspection TLS utilise la SNI dans le message Client Hello de TLS pour classer le trafic à l'aide du profil de contexte afin d'utiliser les profils de déchiffrement internes, externes ou de contournement.
- Le serveur répond avec le certificat de serveur pour l'authentification et l'identification, et un message Server Hello avec la version et le chiffrement proposés par le client.
- Une fois que le client valide le certificat et vérifie la version finale et le chiffrement, il génère une clé de session symétrique et l'envoie au serveur.
- Pour initier le tunnel TLS sécurisé qui échange des données d'application sur le canal TLS chiffré, le serveur valide la clé de session et envoie le message terminé.
Par défaut, le protocole TLS ne montre que l'identité du serveur au client à l'aide du certificat X.509 et l'authentification du client sur le serveur incombe à la couche d'application.
Types de déchiffrement TLS
- Déchiffrement TLS interne : pour le trafic allant vers un service interne d'entreprise dans lequel vous possédez le service, le certificat et la clé privée. Il est également appelé proxy inverse TLS ou déchiffrement entrant.
- Déchiffrement TLS externe : pour le trafic allant vers un service externe (Internet) dans lequel l'entreprise ne possède pas le service, son certificat et la clé privée. Il est également appelé proxy de transfert TLS ou déchiffrement sortant.
| Légende | Workflow |
|---|---|
| 1 | La SNI du message Hello Client de TLS correspond au profil de contexte de stratégie Inspection TLS. |
| 2 | NSX intercepte la session TLS à partir du client et initie une nouvelle session sur le serveur prévu. |
| 3 | NSX applique la version et le chiffrement TLS (configurables). |
| 4 | Le serveur répond au client avec un certificat TLS |
| 5 | NSX valide le certificat de serveur à l'aide du bundle d'autorité de certification approuvée et génère dynamiquement un certificat d'autorité de certification de proxy et le présente au client. |
Le diagramme et le tableau suivants expliquent le fonctionnement du déchiffrement interne TLS de NSX avec NSX.
| Légende | Workflow |
|---|---|
| 1 | La SNI du message Client Hello de TLS correspond au profil de contexte de stratégie d'inspection TLS configuré pour le domaine interne. |
| 2 | NSX intercepte la session TLS à partir du client et initie une nouvelle session sur le serveur prévu. |
| 3 | NSX applique la version/le chiffrement TLS (configurables). |
| 4 | Le serveur répond avec le certificat dans le cadre de l'établissement d'une liaison TLS (validation facultative). |
| 5 | NSX présente au client le certificat du serveur, qui a été chargé dans le cadre de la configuration. |
Stratégies d'inspection TLS
Une stratégie d'inspection TLS s'applique à un ou plusieurs pare-feu de passerelle de niveau 1 sélectionnés. La première fois que vous ajoutez une stratégie d'inspection TLS, vous pouvez utiliser l'assistant ou configurer manuellement la stratégie et les règles associées. Cette rubrique décrit les concepts et la création de stratégies d'inspection TLS.
- Règles préalables : définit la stratégie pour plusieurs passerelles.
- Passerelle locale : définit des stratégies spécifiques.
- Par défaut (règles postérieures) : cette catégorie TLS par défaut est différente des règles de la stratégie de passerelle, car elle ne contient aucune règle ni stratégie par défaut prêt à l'emploi. Elle vous permet également de définir des règles postérieures dans la catégorie Par défaut (qui n'est pas disponible dans le tableau de pare-feu de passerelle). Par exemple, l'ajout de stratégies communes à plusieurs passerelles après la configuration de la passerelle locale peut constituer un cas d'utilisation.
Créer une stratégie d'inspection TLS
Pour simplifier la configuration de la première stratégie d'inspection TLS, vous pouvez utiliser l'assistant Inspection TLS ou créer manuellement votre stratégie à l'aide de l'interface utilisateur. Cette rubrique ne décrit pas la configuration de l'assistant, mais uniquement les étapes de configuration manuelle.
L'assistant fournit une démonstration du workflow de configuration de l'inspection TLS pour vos pare-feu de passerelle de niveau 1. L'assistant s'affiche sur la page d'accueil de l'inspection TLS uniquement pour la première stratégie, mais vous pouvez accéder à l'assistant dans les onglets Toutes les règles partagées et Règles spécifiques à la passerelle. Vous pouvez ignorer l'assistant de configuration et terminer la création de stratégie et la configuration manuelle du profil d'action de déchiffrement en cliquant sur Ignorer sur la page d'ouverture.
Conditions préalables
Ces conditions préalables sont valides pour les stratégies d'inspection TLS.
- Activation des paramètres d'inspection TLS par passerelle.
Accédez à et sélectionnez l'onglet Paramètres. Sélectionnez une ou plusieurs passerelles dans la liste des passerelles compatibles TLS et cliquez sur Activer.
- Activation de la base de données d'URL sur le cluster Edge.
Accédez à . Les nœuds Edge doivent disposer d'une connectivité Internet afin que le service NSX Threat Intelligence Cloud (NTICS) puisse effectuer des téléchargements de base de données d'URL.
- Pour afficher les statistiques d'inspection TLS à l'aide du tableau de bord Sécurité, déployez NSX Application Platform sur votre environnement NSX-T Data Center 3.2 ou version ultérieure et assurez-vous qu'il est dans un état correct. Une licence spécifique est requise pour la surveillance de séries chronologiques. Pour plus d'informations, reportez-vous au guide Déploiement et gestion de NSX Application Platform et à la section Surveillance des statistiques de sécurité.
Procédure
Création de profils d'action de déchiffrement TLS
Vous pouvez créer trois types de profils d'action de déchiffrement dans Inspection TLS. Cette rubrique décrit les profils et comment les utiliser.
- Profils de contournement de déchiffrement : ce profil est utilisé pour contourner le déchiffrement du trafic destiné à des catégories spécifiques de sites Web, pour des raisons de conformité et de confidentialité. Par exemple, les sites Web de santé et financiers. Le profil de contournement ne peut pas être modifié.
- Profils de déchiffrement externes : ces profils sont destinés aux connexions TLS destinées à un service non détenu par l'entreprise. Par exemple, http://merriam-webster.com. En général, les sites Web Internet.
- Profils de déchiffrement internes : ces profils sont destinés aux connexions TLS destinées à un service détenu par l'entreprise elle-même. Par exemple, http://www.corp.internal.com.
- Créer un profil de déchiffrement externe
- Créer un profil d'action de déchiffrement interne
- Créer un profil d'action de contournement du déchiffrement
Créer un profil de déchiffrement externe
Cette rubrique fournit les étapes de configuration manuelle d'un profil d'action de déchiffrement externe.
Conditions préalables
- Assurez-vous de disposer du rôle d'utilisateur et des autorisations appropriés pour configurer l'inspection TLS.
- Assurez-vous de disposer d'une autorité de certification de proxy approuvée et d'une autorité de certification de proxy non approuvée, importées ou prêtes à être importées, ou de disposer des informations associées pour générer un certificat.
Procédure
Résultats
Vous pouvez désormais utiliser le profil d'action de déchiffrement pour configurer des règles de déchiffrement externes sur vos passerelles de niveau 1.
Que faire ensuite
Créez des stratégies et des règles de déchiffrement externes d'Inspection TLS.
Créer un profil d'action de déchiffrement interne
Cette rubrique fournit les étapes de configuration manuelle d'un profil d'action de déchiffrement interne.
Conditions préalables
- Assurez-vous de disposer du rôle d'utilisateur et des autorisations appropriés pour configurer l'inspection TLS.
- Assurez-vous de disposer d'un certificat de serveur interne importé ou prêt à être importé ou de disposer des informations associées pour générer le certificat.
Procédure
Résultats
Vous pouvez désormais utiliser le profil d'action de déchiffrement interne pour configurer des stratégies et des règles d'inspection TLS sur vos passerelles de niveau 1.
Que faire ensuite
Créez des stratégies et des règles de déchiffrement internes d'inspection TLS.
Créer un profil d'action de contournement du déchiffrement
Cette rubrique fournit des détails sur le profil d'action de contournement du déchiffrement.
Conditions préalables
Les politiques de confidentialité de vos administrations locales et d'entreprise peuvent interdire le déchiffrement de certains contenus. Par exemple, lorsque le client accède à un site Web financier ou site Web d'un fournisseur de santé, des lois peuvent interdire l'interception et le déchiffrement de ce trafic.
Pour faciliter la configuration, NSX inclut un profil de contexte prédéfini, default-bypass-highfidelity-profile, afin de répondre à ces exigences. NSX utilise des profils de contexte pour faire correspondre des URL de domaine à ignorer ou à contourner à partir du déchiffrement. Le profil par défaut inclut les catégories d'URL : santé et finances.
| Paramètre du profil | Description |
|---|---|
| Certificats non valides : autoriser | Définir sur Autoriser : si le serveur présente un certificat expiré ou non approuvé, ce choix permet à la connexion de continuer. |
| Application du chiffrement : transparent | Défini sur transparent : aucune application de chiffrement ou de version TLS ne se produit si l'URL correspond à la règle de profil de contournement du déchiffrement. |
Gestion des certificats d'inspection TLS
Un certificat de sécurité est requis pour Inspection TLS sur NSX-T Data Center. Pour intercepter, déchiffrer et chiffrer le trafic pour Inspection TLS et d'autres applications de sécurité avancées, vous devez préparer le proxy TLS afin qu'il puisse agir comme un proxy transparent pour les connexions TLS. NSX Manager nécessite ces certificats pour établir une approbation entre les applications.
- Importation d'un certificat existant ou génération d'une CSR auto-signée ou auto-signée par une autorité de certification (demande de signature de certificat).
- Exportation d'un certificat existant.
- Importation ou mise à jour d'un bundle d'autorité de certification approuvée par défaut.
- Importation ou mise à jour d'une liste de révocation des certificats (CRL) publics par défaut.
- Filtrage avancé sur toutes les options de filtre prédéfinies.
- Bannière de certificat expiré sur la page Certificats.
- Notification de certificats valides ou non valides avec un code couleur.
Pour plus d'informations sur les options de déploiement, reportez-vous au Certificats.
Le proxy TLS nécessite un certificat d'autorité de certification, également appelé autorité de certification de proxy. NSX Manager utilise l'autorité de certification de proxy pour générer des certificats qui empruntent l'identité des points de terminaison dans la connexion interceptée. En d'autres termes, il permet d'usurper les certificats pour le trafic intercepté sur les serveurs de sites Web. Vous pouvez choisir l'un des deux types de certificats d'autorité de certification de proxy :
- Les certificats auto-signés sont généralement utilisés pour les tests ou les déploiements limités non approuvés. Ce workflow commence par une demande à NSX Manager de générer une paire de clés de certificat d'autorité de certification avec une demande de signature de certificat (CSR). Il demande ensuite à NSX manager d'auto-signer la CSR.
- Une autorité de certification émettrice d'entreprise signe des certificats d'autorité de certification subordonnée approuvés. Ce workflow commence par une demande à NSX Manager de générer une paire de clés de certificat d'autorité de certification avec une CSR, de télécharger celle-ci, puis de l'envoyer à l'autorité de certification émettrice, ce qui entraîne la réception d'un certificat signé. Il charge ensuite le certificat d'autorité de certification public signé vers NSX Manager. Le chargement peut inclure une chaîne de certificats. Les chaînes de certificats sont des certificats de signature intermédiaires entre le nouveau certificat et le certificat d'autorité de certification racine.
Il existe plusieurs façons de charger un nouveau certificat d'autorité de certification dans NSX manager : utilisez l'assistant TLS dans l'interface utilisateur, ajoutez manuellement le certificat dans l'interface utilisateur ou utilisez NSX API. Pour plus de détails, reportez-vous à la section Importer un certificat d'autorité de certification.
Bundles d'autorité de certification approuvée
Après la configuration, ces certificats d'autorité de certification sont distribués aux nœuds exécutant le proxy TLS. Vous pouvez charger plusieurs bundles de certificat d'autorité de certification avec des noms différents. Chaque bundle d'autorité de certification utilisé par le proxy TLS est configuré dans le profil d'action de déchiffrement. Lors du chargement, le bundle d'autorité de certification est validé en tant que concaténation bien formée de certificats codés en PEM et n'est pas stocké s'il n'est pas valide. Si un bundle n'est pas valide, il renvoie des messages d'erreur d'API.
Un seul bundle est limité à une taille de 1 Mo et à 1 000 certificats.
Liste de révocation de certificats
- CRL X.509 codé au format PEM : taille maximale de 40 Mo, 500 000 entrées
- Mozilla OneCRL : taille maximale de 5 Mo, 10 000 entrées
Gestion des alarmes pour les certificats d'inspection TLS
Si vous ne conservez pas vos certificats d'autorité de certification de proxy et qu'ils sont sur le point d'expirer ou ont expiré ou que vous avez reçu un certificat d'autorité de certification expiré, NSX Manager utilise des alarmes pour vous en informer.
NSX déclenche le même ensemble d'alarmes pour les certificats arrivant à expiration ou expirés dans les bundles d'autorité de certification.
Vous pouvez également recevoir une erreur de serveur de journalisation distant en raison d'un certificat TLS non valide. L'erreur d'événement consignée est Log messages to logging server {hostname_or_ip_address_with_port}({entity_id}) cannot be delivered possibly due to an unresolvable FQDN, an invalid TLS certificate or missing NSX appliance iptables rule.. Pour vérifier que le certificat spécifié est valide, utilisez la commande openssl openssl x509 -in <cert-file-path> -noout -dates. Vous pouvez également afficher et mettre à jour les certificats dans l'interface utilisateur d'inspection TLS.
Pour plus d'informations sur l'expiration du certificat, reportez-vous à la section Notification d'alarme pour l'expiration du certificat. Pour plus d'informations sur les « événements de certificat » spécifiques à TLS à partir de NSX Manager, reportez-vous à la section Catalogue d'événements.
