Le trafic chiffré TLS (Transport Layer Security) représente la grande majorité du trafic Web. Comme les acteurs malveillants utilisent souvent ces canaux chiffrés pour dissimuler des activités malveillantes, il est essentiel d'inspecter ce trafic avant qu'il n'atteigne sa destination.
Secure Web Proxy fournit un service d'inspection TLS intégré qui vous permet d'intercepter et de déchiffrer le trafic HTTPS. En vous offrant une visibilité sur la requête chiffrée, Secure Web Proxy peut appliquer des règles de sécurité avancées, telles que le filtrage des URL sur le chemin d'accès complet de la requête et l'inspection des en-têtes HTTP, afin de protéger votre environnement contre les menaces dissimulées dans les tunnels chiffrés.
Fonctionnement
L'inspection TLS fonctionne en établissant deux connexions chiffrées distinctes, Secure Web Proxy agissant comme un intermédiaire sécurisé.
Handshake client : lorsqu'un client tente de se connecter à un site externe, tel que
www.example.com, Secure Web Proxy intercepte la requête.Génération de certificats : Secure Web Proxy génère un certificat temporaire pour
www.example.comen temps réel. Selon le mode d'émission de certificats configuré , le proxy demande des certificats feuilles directement à CA Service pour chaque domaine ou les signe localement à l'aide d'un certificat CA intermédiaire mis en cache à partir du pool d'autorités de certification.Validation de la confiance : le client reçoit ensuite ce certificat temporaire.
Point d'inspection : le trafic est déchiffré dans l'instance Secure Web Proxy. À ce stade, les règles de sécurité sont appliquées aux données HTTP en texte brut.
Handshake serveur : Secure Web Proxy lance ensuite une deuxième connexion TLS vers le serveur de destination réel. Le trafic est rechiffré et envoyé à l'adresse de destination.
Principales fonctionnalités
Le service d'inspection TLS du Secure Web Proxy offre un framework flexible et évolutif pour gérer le trafic chiffré grâce aux fonctionnalités suivantes :
Confiance privée intégrée : l'intégration intégrée à CA Service fournit un dépôt disponibilité élevée et géré par Google pour vos autorités de certification privées.
Racine de confiance flexible : utilisez une autorité de certification racine sur site existante pour signer les autorités de certification subordonnées hébergées dans CA Service. Vous pouvez ensuite générer et gérer un certificat racine entièrement nouveau directement dans CA Service.
Déchiffrement spécifique : utilisez
SessionMatcherpour définir précisément le trafic à déchiffrer. Vous pouvez déclencher l'inspection TLS en fonction des paramètres suivants :- Noms de domaine de sites Web : mettez en correspondance des sites Web spécifiques à l'aide d' expressions régulières et de listes de domaines.
- Critères réseau : ciblez des plages d'adresses IP sources spécifiques ou des blocs CIDR (Classless
Inter-Domain Routing), tels que
10.0.0.0/24, pour définir les limites du réseau. - Logique booléenne : combinez plusieurs conditions, telles qu'une adresse IP source et une URL de destination, pour créer des règles de sécurité très spécifiques.
Architecture de règles évolutive :
Règles dédiées : attribuez une règle d'inspection TLS et un pool d'autorités de certification uniques à chaque règle Secure Web Proxy pour une isolation stricte.
Règles partagées : simplifiez la gestion des règles en partageant une seule configuration d'inspection TLS entre plusieurs règles de proxy.
Visibilité complète de l'URI (Uniform Resource Identifier) : inspectez l'URI complet (y compris le domaine, le chemin d'accès et les chaînes de requête, telles que
www.example.com/downloads/malware.exe) plutôt que le nom de domaine uniquement.Contrôle d'accès précis : utilisez l'inspection TLS pour appliquer des règles à des chemins d'accès spécifiques d'un site Web. Par exemple, vous pouvez autoriser l'accès à
www.example.com/documentation, mais bloquerwww.example.com/uploads.Prise en charge des autorités de certification intermédiaires : réduisez les frais d'utilisation de CA Service en mettant en cache localement une seule autorité de certification intermédiaire pour signer les certificats feuilles, au lieu d'envoyer des requêtes par domaine directement à CA Service. Pour en savoir plus, consultez Modes d'émission des certificats.
Rôle des autorités de certification dans l'inspection TLS
Pour inspecter le trafic chiffré, Secure Web Proxy agit comme un intermédiaire de confiance. Cela implique un processus coordonné entre le proxy, CA Service et l'appareil client.
Exigences de confiance du client
L'inspection TLS est conçue pour les environnements dans lesquels une organisation dispose d'un contrôle administratif sur les appareils clients, tels que les ordinateurs portables, les serveurs ou les machines virtuelles (VM) gérés.
- Ancre de confiance privée : comme le Secure Web Proxy présente des certificats signés par votre autorité de certification interne plutôt que par une Public CA, les clients ne font confiance à la connexion que si votre autorité de certification racine privée est préinstallée.
- Champ d'application administratif : les connexions provenant de matériel non géré déclenchent généralement
des avertissements
Insecure connectioncar ces appareils ne disposent pas de l'ancre de confiance spécifique de votre organisation.
Gérer les échecs d'interception
Même sur les appareils gérés, certaines connexions ne peuvent pas être interceptées en raison de l'épinglage de certificats. L'épinglage de certificats se produit lorsqu'une application est codée en dur pour n'accepter qu'une clé publique spécifique ou une chaîne d'autorités de certification publiques spécifique.
- Exemples d'épinglage de certificats : les services courants qui utilisent l'épinglage incluent les mises à jour du système Windows et macOS, les mises à jour de Google Chrome et certaines applications mobiles hautement sécurisées.
- Résultat de l'épinglage de certificats : lorsque le Secure Web Proxy présente son certificat signé, l'application détecte que le certificat ne correspond pas à ses attentes codées en dur et met fin à la connexion.
Atténuation et contrôle précis
Pour éviter les interruptions de service pour les applications épinglées ou pour préserver la confidentialité des sites Web sensibles, vous pouvez utiliser l'attribut SessionMatcher pour contourner l'inspection. Vous pouvez limiter ou ignorer l'inspection en fonction des paramètres suivants :
- Attributs de destination : noms de domaine complets spécifiques.
- Attributs sources : tags sécurisés, comptes de service, ou adresses IP.
- Logique personnalisée : utilisez des expressions booléennes pour exclure un trafic spécifique tout en inspectant le reste de l'environnement.
Modes d'émission des certificats
Secure Web Proxy est compatible avec deux modes de provisionnement des certificats qu'il utilise pour déchiffrer le trafic lors du processus d'inspection TLS. Le choix dépend de vos exigences en matière de coûts, de performances et de journalisation d'audit.
Pour en savoir plus, consultez Configurer une signature CA intermédiaire locale signing.
Signature CA intermédiaire locale
Si vous définissez certificateIssuanceMode sur LOCAL_INTERMEDIATE_CA_SIGNING, Secure Web Proxy demande un seul certificat CA intermédiaire à votre pool d'autorités de certification. Le proxy met en cache cette autorité de certification intermédiaire et signe localement les certificats feuilles individuels pour les domaines requis.
Les fonctionnalités du mode d'émission de certificats de signature CA intermédiaire locale sont les suivantes :
Coûts CA Service inférieurs : les requêtes adressées à CA Service sont limitées au cycle d'actualisation de l'autorité de certification intermédiaire (généralement une fois par jour) au lieu de se produire pour chaque domaine, ce qui entraîne des coûts de transaction inférieurs.
Observabilité réduite : les certificats feuilles individuels que votre proxy signe localement ne sont pas enregistrés dans les journaux d'audit de CA Service.
Provisionnement direct des feuilles
Si vous définissez certificateIssuanceMode sur DIRECT_LEAF_PROVISIONING, Secure Web Proxy communique directement avec votre pool CA Service pour chaque domaine unique afin de demander un certificat d'entité finale.
Les fonctionnalités du mode d'émission de certificats de provisionnement direct des feuilles sont les suivantes :
Observabilité accrue : chaque requête de certificat générée est enregistrée dans les journaux d'audit de CA Service, ce qui vous permet de suivre et d'auditer toutes les activités de génération de certificats.
Coûts CA Service plus élevés : comme les requêtes sont envoyées à CA Service pour chaque domaine, ce processus peut entraîner des frais de transaction plus élevés dans les environnements comportant plusieurs domaines uniques ou tâches de proxy.
Méthodes de configuration des autorités de certification
Pour activer l'inspection TLS, configurez votre autorité de certification à l'aide de l'une des méthodes suivantes :
Autorité de certification subordonnée dans CA Service : utilisez une autorité de certification racine externe existante pour signer une autorité de certification subordonnée stockée dans Google Cloud.
Autorité de certification racine externe : utilisez une autorité de certification racine externe pour signer les certificats qui sont générés au moment de l'exécution via des autorités de certification subordonnées.
Autorité de certification racine gérée par Google : générez un nouveau certificat racine directement dans CA Service pour signer vos autorités de certification subordonnées.
Pour en savoir plus sur ces méthodes, consultez Créer un pool d'autorités de certification subordonnées.