Le trafic chiffré TLS (Transport Layer Security) représente la grande majorité du trafic Web. Étant donné que les acteurs malveillants utilisent souvent ces canaux chiffrés pour masquer leurs 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 obtenant 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 d'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 caché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 certificat : 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 d'entité finale 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 stratégies de sécurité sont appliquées aux données HTTP en texte brut.
Handshake du serveur : Secure Web Proxy lance ensuite une deuxième connexion TLS au 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 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 tout nouveau certificat racine 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 : faites correspondre 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 ou des blocs CIDR (Classless Inter-Domain Routing) spécifiques, tels que
10.0.0.0/24, pour définir les limites du réseau. - Logique booléenne : combinez plusieurs conditions (par exemple, 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 :
Stratégies dédiées : attribuez une stratégie d'inspection TLS et un pool d'autorités de certification uniques à chaque stratégie 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'intégralité de l'URI (y compris le domaine, le chemin d'accès et les chaînes de requête, comme
www.example.com/downloads/malware.exe) plutôt que seulement le nom de domaine.Contrôle des 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.Compatibilité avec les 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 d'entité finale, au lieu d'envoyer des requêtes par domaine directement à CA Service. Pour en savoir plus, consultez Modes d'émission de 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.
Confiance dans les conteneurs d'agents : lorsque vous acheminez le trafic Web sortant depuis des agents IA conteneurisés, par exemple dans Cloud Run ou Google Kubernetes Engine (GKE), vous devez exporter le certificat CA racine depuis votre pool d'autorités de certification ou votre infrastructure à clé publique (PKI) privée, puis l'injecter dans le magasin de confiance des certificats du conteneur. Par exemple, vous pouvez configurer votre environnement d'exécution de conteneur ou définir la variable d'environnement
AGENT_GATEWAY_ROOT_CERTIFICATESouSSL_CERT_FILE. Pour en savoir plus sur la configuration de l'autorité de certification racine, consultez Configurer l'inspection TLS dans "Déployer Secure Web Proxy en tant qu'Agent Gateway".Ancre de confiance privée : étant donné que Secure Web Proxy présente des certificats signés par votre autorité de certification interne plutôt que par une autorité de certification publique, 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 à partir de matériel non géré déclenchent généralement des avertissements
Insecure connection, car 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 certificat. L'épinglage de certificat 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 certificat : 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 à haute sécurité.
- Résultat de l'épinglage de certificats : lorsque 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 restreindre ou ignorer l'inspection en fonction des paramètres suivants :
- Attributs de destination : noms de domaine complets (FQDN) 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 accepte 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 termes de coût, de performances et de journalisation d'audit.
Pour en savoir plus, consultez Configurer la signature d'une autorité de certification intermédiaire locale.
Signature d'une autorité de certification 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 d'entité finale individuels pour les domaines requis.
Les fonctionnalités du mode d'émission de certificats de signature d'autorité de certification intermédiaire locale sont les suivantes :
Réduction des coûts de CA Service : 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) plutôt que d'être effectuées pour chaque domaine, ce qui réduit les coûts de transaction.
Observabilité réduite : les certificats d'entité finale 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 de feuilles direct sont les suivantes :
Observabilité accrue : chaque demande 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 plus élevés de Certificate Authority Service : étant donné que les requêtes sont envoyées à Certificate Authority Service pour chaque domaine, ce processus peut entraîner des frais de transaction plus élevés dans les environnements comportant plusieurs domaines ou tâches de proxy uniques.
Méthodes de configuration des autorités de certification
Pour activer l'inspection TLS, configurez votre autorité de certification (CA) à 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 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.