Le trafic Web chiffré TLS (Transport Layer Security) représente une grande partie de l'ensemble du trafic Web. Les acteurs de la menace peuvent utiliser ces canaux chiffrés pour lancer des attaques malveillantes. Par conséquent, il est essentiel de vérifier le trafic chiffré TLS avant de l'acheminer vers sa destination.
Le proxy Web sécurisé propose un service d'inspection TLS qui vous permet d'intercepter le trafic TLS, d'inspecter la requête chiffrée et d'appliquer des règles de sécurité.
En fonction des règles de sécurité implémentées et de la configuration de l'inspection TLS, la solution Secure Web Proxy établit deux connexions sécurisées, l'une avec le client et l'autre avec le serveur externe. La solution de proxy Web sécurisé inspecte ensuite le trafic entre les deux connexions sécurisées. Une fois la validation terminée, vous pouvez appliquer au trafic chiffré les mêmes filtres et contrôles de sécurité que vous appliquez au trafic non chiffré.
Rôle des autorités de certification dans l'inspection TLS
Pour déterminer si le proxy Web sécurisé doit inspecter une connexion TLS, il vérifie l'indicateur tls_inspection_enabled sur ses règles de stratégie de sécurité individuelles. Si l'indicateur est défini et qu'une connexion TLS est détectée, le proxy Web sécurisé génère un nouveau certificat de serveur. Il envoie ce certificat au service d'autorité de certification (CAS) pour qu'il soit signé par votre pool d'autorités de certification (CA) subordonnées.
Ce certificat est ensuite présenté au client et une connexion TLS est établie. Le certificat généré est mis en cache pendant une courte période pour être utilisé lors des connexions ultérieures au même hôte.
Si vous souhaitez inspecter le trafic TLS, vous devez générer un certificat de serveur pour l'hôte auquel le client tente de se connecter. Une autorité de certification privée gérée par l'organisation doit signer ce certificat de serveur. Seuls les clients configurés pour approuver cette autorité de certification privée font confiance à ces certificats de serveur générés. Il s'agit notamment des navigateurs et des clients HTTP intégrés. Par conséquent, l'inspection TLS ne peut être utilisée que pour intercepter et inspecter les connexions TLS des clients sur lesquels votre organisation exerce un contrôle administratif.
Toutes les connexions TLS ne peuvent pas être interceptées, même sur les machines sur lesquelles l'organisation dispose d'un contrôle administratif. En effet, certains clients (en particulier ceux intégrés à d'autres applications) sont codés en dur pour n'accepter que des certificats de serveur spécifiques ou ceux signés par des autorités de certification spécifiques (pratique appelée épinglage de certificat). Les mises à jour logicielles de Microsoft Windows, de macOS et de Google Chrome en sont quelques exemples. Ces connexions échouent en présence d'une inspection TLS. Cela se produit parce que la clé publique et la chaîne de certification de la certification de serveur que le proxy Web sécurisé présente au client ne correspondent pas aux paramètres stockés localement.
Si une règle est configurée pour inspecter le trafic TLS, mais que le client ne fait pas confiance aux certificats d'inspection présentés par le proxy Web sécurisé, la connexion échoue. Dans ce cas, l'inspection TLS est connue pour interrompre les connexions client-serveur, même si le serveur est approuvé. Pour contourner ce problème, vous pouvez ajouter des règles pour contourner l'inspection TLS pour des critères spécifiques. Vous pouvez également limiter l'inspection TLS à des hôtes de destination spécifiques (à l'aide d'un nom de domaine complet), à des sources (à l'aide de tags sécurisés, d'un compte de service ou d'une adresse IP) et à l'aide de l'attribut SessionMatcher d'une règle.
Fonctionnalités compatibles
L'inspection TLS du proxy Web sécurisé est compatible avec les fonctionnalités suivantes:
- Intégration étroite avec CAS, qui est un dépôt hautement disponible et évolutif pour les autorités de certification privées.
- Possibilité d'utiliser votre propre racine de confiance si nécessaire. Vous pouvez également utiliser une autorité de certification racine existante pour signer pour les autorités de certification subordonnées détenues par les CAS. Si vous préférez, vous pouvez générer un nouveau certificat racine dans CAS.
- Critères de déchiffrement précis à l'aide de
SessionMatcherdans les règles de stratégie du proxy Web sécurisé. Ces critères incluent les hôtes correspondants présents dans les listes d'URL, les expressions régulières, les plages d'adresses IP et les expressions similaires. Si nécessaire, les critères peuvent être combinés à des expressions booléennes. - Chaque stratégie de proxy Web sécurisé peut être configurée avec sa propre règle d'inspection TLS et son propre pool d'autorités de certification. Plusieurs règles de proxy Web sécurisé peuvent également partager une seule règle d'inspection TLS.
Cas d'utilisation courants
Pour activer l'inspection TLS, vous pouvez utiliser l'une des méthodes suivantes:
Utilisez une autorité de certification racine existante pour signer les autorités de certification subordonnées détenues dans CAS. Une autorité de certification subordonnée détenue dans CAS est utilisée pour signer les certificats de serveur générés au moment de l'exécution.
Utilisez une autorité de certification racine existante stockée en externe (et non dans CAS) pour signer les autorités de certification subordonnées. Lorsque les autorités de certification subordonnées sont signées par votre autorité de certification racine, vous pouvez les utiliser pour signer les certificats de serveur générés au moment de l'exécution.
Utilisez un certificat racine généré dans CAS. Après avoir créé le certificat racine, vous créez une autorité de certification subordonnée signée par votre nouvelle autorité de certification racine. Cette autorité de certification subordonnée est utilisée pour signer les certificats de serveur générés au moment de l'exécution.
Pour en savoir plus sur ces méthodes, consultez Créer un pool d'autorités de certification subordonnées.