Règles de sécurité

Cette page explique les règles de sécurité de la passerelle et comment les créer.

Secure Web Proxy vous permet de définir différents types de règles de sécurité dans vos stratégies de sécurité de passerelle pour sécuriser le trafic Web sortant. Vous pouvez utiliser ces règles pour contrôler précisément la sécurité de votre trafic à l'aide de détails de requête spécifiques, tels que des en-têtes et des modèles d'URL, afin de vous assurer que seul le trafic HTTP/S approuvé quitte votre réseau.

Les règles de sécurité de la passerelle présentent les caractéristiques suivantes :

  • Chaque règle est une instruction if-then qui vérifie une requête Web par rapport aux paramètres suivants :

    • Identité source : qui effectue la requête, par exemple une machine virtuelle (VM) ou un compte de service spécifique.

    • Destination : la requête est envoyée, par exemple une URL de destination ou un domaine tel que trusted-partner.com.

    • Action : décision d'autoriser ou de refuser le trafic.

  • Les règles de sécurité de la passerelle offrent un contrôle précis. Ces règles vous permettent d'appliquer différentes normes de sécurité dans votre organisation à l'aide de définitions claires et structurées.

Règles de mise en correspondance des hôtes

Le proxy Web sécurisé utilise la mise en correspondance des noms d'hôte pour vérifier le domaine de destination. Le processus de validation varie en fonction du mode de déploiement de votre proxy, comme indiqué dans le tableau suivant.

Mode de déploiement Processus de validation de l'hôte
Mode proxy explicite Pour le trafic non chiffré, le proxy compare le nom d'hôte à l'en-tête de connexion HTTP. Si vous utilisez des attributs de mise en correspondance des applications pour l'inspection TLS, le proxy vérifie d'abord le nom d'hôte au niveau de la connexion, puis au niveau de l' application.
Mode de saut suivant Pour le trafic chiffré, le proxy compare le nom d'hôte de destination au champ d'indication du nom du serveur (SNI) dans la requête sortante. Ce champ est visible même sur les connexions sécurisées.

Configurer des règles de mise en correspondance des hôtes pour le mode proxy explicite

Lorsque vous déployez Secure Web Proxy en tant que proxy explicite, configurez des règles de mise en correspondance des hôtes pour vérifier que les informations d'hôte envoyées par le client sont correctement extraites et comparées à vos règles de sécurité définies. En mode proxy explicite, les clients sont configurés de manière active pour envoyer leur trafic directement à l'instance de Secure Web Proxy.

La mise en correspondance des hôtes en mode proxy explicite fonctionne de différentes manières pour différents types de trafic Web :

Type de trafic Mécanisme de mise en correspondance Configuration de la règle
HTTP non chiffré Le proxy Web sécurisé compare le nom d'hôte de destination au champ host dans l'en-tête standard CONNECT de la requête HTTP. Dans le champ sessionMatcher, utilisez host() == "example.com".
HTTPS chiffré (sans inspection TLS (Transport Layer Security) ) La mise en correspondance des hôtes n'est possible ni au niveau de l'application ni au niveau de la session. En effet, les détails de la requête sont chiffrés et l'attribut destination.ipn'est pas compatible. Vous devez utiliser des contrôles de règles plus larges, comme la mise en correspondance de l'identité source, ou activer l'inspection TLS pour le filtrage basé sur l'hôte. Pour utiliser la mise en correspondance des applications, utilisez la mise en correspondance de l'identité source , comme les comptes de service , ou activez l'inspection TLS.
HTTPS chiffré (avec inspection TLS) Pour inspecter la requête complète, vous devez utiliser à la fois la mise en correspondance des sessions et la mise en correspondance des applications. 1. Définissez une règle générale de mise en correspondance des sessions qui renvoie true ou qui correspond à l'hôte de destination, par exemple host() == "example.com".

2. Dans le champ applicationMatcher, ajoutez une règle d'hôte spécifique, par exemple request.host() == "example.com".

Configurer des règles de mise en correspondance des hôtes pour le mode de saut suivant

Lorsque vous déployez Secure Web Proxy en tant que prochain saut, vous devez configurer des règles de mise en correspondance des hôtes. Le trafic est redirigé vers le proxy via une route de cloud privé virtuel (VPC) en fonction des plages d'adresses IP que vous définissez. Les règles de mise en correspondance des hôtes garantissent que le proxy identifie correctement l'hôte de destination en vérifiant différents champs du trafic, tels que l'en-tête d'indication du nom du serveur (SNI).

La mise en correspondance des hôtes en mode de saut suivant fonctionne de différentes manières pour différents types de trafic Web :

Type de trafic Mécanisme de mise en correspondance Configuration de la règle
HTTP non chiffré Le Secure Web Proxy compare le nom d'hôte de destination au champ host dans l'en-tête de requête HTTP standard. Dans le champ sessionMatcher, utilisez host() == "example.com".
HTTPS chiffré (sans inspection TLS) Secure Web Proxy compare le nom d'hôte à l' en-tête SNI dans la requête sortante, qui est visible même si le reste du trafic est chiffré. Dans le champ sessionMatcher, utilisez host() == "example.com".
HTTPS chiffré (avec inspection TLS) Pour inspecter la requête complète, vous devez utiliser à la fois la mise en correspondance des sessions et la mise en correspondance des applications. 1. Définissez une règle générale de mise en correspondance des sessions qui renvoie true ou qui correspond à l'hôte de destination, par exemple host() == "example.com".

2. Dans le champ applicationMatcher, ajoutez une règle d'hôte spécifique, par exemple request.host() == "example.com".

Règles de proxy TCP

Les règles de proxy TCP (protocole TCP) vous permettent de contrôler le trafic qui n'est pas du trafic Web standard, tel que HTTP (port 80) ou HTTPS (port 443). En configurant des règles de proxy TCP, vous pouvez autoriser ou bloquer le trafic sur n'importe quel autre port TCP. Ces règles vous aident à bloquer le trafic malveillant et à gérer les applications non Web qui utilisent TCP.

Si votre charge de travail (telle que vos applications et services) utilise un proxy Web sécurisé comme saut suivant, l'application de règles de proxy TCP est avantageuse. La redirection basée sur les routes dirige le trafic non HTTP(S) et non Web vers votre instance Secure Web Proxy. Vous pouvez ainsi bloquer le trafic sortant vers des sites externes malveillants et gérer les services externes auxquels vos charges de travail réseau peuvent se connecter.

Configurer des règles de proxy TCP

Vous pouvez configurer des règles de proxy TCP pour votre application afin de sécuriser le trafic non Web et d'appliquer des règles de sécurité pour les applications qui n'utilisent pas de protocole HTTP/S standard, par exemple pour les ports 80 et 443.

En appliquant ces règles, vous pouvez empêcher l'utilisation non autorisée d'autres ports TCP pour le transfert de données ou les activités malveillantes. Cela est particulièrement utile lorsque vos charges de travail utilisent un proxy Web sécurisé comme saut suivant pour les protocoles non Web.

Pour implémenter des règles de proxy TCP et créer une règle d'autorisation ou de blocage du trafic pour votre application, vous devez spécifier le port de destination. Vous pouvez également inclure l'un des attributs de mise en correspondance des sessions suivants pour affiner les critères de la règle d'autorisation ou de blocage.

Le tableau suivant fournit plus d'informations sur les différents attributs que vous pouvez utiliser dans une règle de proxy TCP :

Attribut Type d'attribut Description
source.ip chaîne Adresse IP du client qui a envoyé la requête.
source.port chaîne Port client qui a envoyé la requête.
destination.port chaîne Port en amont vers lequel votre instance Secure Web Proxy envoie le trafic.
source.matchTag(SECURE_TAG) booléen

True, si la source est associée à SECURE_TAG.

L'argument est l'ID permanent du tag sécurisé, tel que source.matchTag('tagValues/123456').

source.matchServiceAccount(SERVICE_ACCOUNT) booléen True, si la source est associée à SERVICE_ACCOUNT par exemple source.matchServiceAccount('x@my-project.iam.gserviceaccount.com').
inIpRange(IP_ADDRESS,
IP_RANGE)
booléen True, si IP_ADDRESS est contenu dans IP_RANGE, par exemple inIpRange(source.ip, '1.2.3.0/24'). Les masques de sous-réseau pour les adresses IPv6 ne peuvent pas excéder `/64`.

Exemple de règle de proxy TCP

Cet exemple montre comment définir un proxy Web sécurisé gatewaySecurityPolicyRule à l'aide d'une expression CEL pour autoriser tout le trafic TCP vers le port 22. Vous pouvez utiliser cette configuration lorsque vous appliquez les fonctionnalités de proxy TCP du proxy Web sécurisé.

L'exemple de code suivant montre comment définir une règle de proxy TCP :

name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
enabled: true
priority: 100 # Lower numbers have higher priority
description: "Allow TCP proxy traffic to port 22