Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Règles de sécurité

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

Secure Web Proxy vous permet de définir différents types de règles de sécurité dans vos règles 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 en utilisant des détails de requête spécifiques (comme les en-têtes et les 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é de la source : qui envoie la requête, par exemple une machine virtuelle (VM) spécifique ou un compte de service.
- Destination : où 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

Secure Web Proxy utilise la correspondance du nom d'hôte pour valider le domaine de destination. Le processus de validation varie en fonction de la façon dont votre proxy est déployé, comme indiqué dans le tableau suivant.

Mode de déploiement	Procédure de validation de l'hôte
Mode proxy explicite	Pour le trafic non chiffré, le proxy vérifie le nom d'hôte par rapport à l'en-tête de connexion HTTP. Si vous utilisez des [attributs ApplicationMatcher](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) 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 du saut suivant	Pour le trafic chiffré, le proxy vérifie le nom d'hôte de destination par rapport au champ "Server Name Indication" (Indication du nom du serveur) dans la requête sortante. Ce champ est visible même sur les connexions sécurisées.

Configurer des règles de correspondance d'hôte pour le mode proxy explicite

Lorsque vous déployez Secure Web Proxy en tant que proxy explicite, configurez des règles de correspondance d'hôte 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 activement configurés pour envoyer leur trafic directement à l'instance Secure Web Proxy.

Dans le mode proxy explicite, la correspondance de l'hôte fonctionne pour différents types de trafic Web de la manière suivante :

Type de trafic	Mécanisme de mise en correspondance	Configuration de la règle
HTTP non chiffré	Secure Web Proxy vérifie le nom d'hôte de destination par rapport au champ `host` dans l'en-tête `CONNECT` standard de la requête HTTP.	Dans le champ `sessionMatcher`, spécifiez `host() == "example.com"`.
HTTPS chiffré (sans inspection TLS (Transport Layer Security))	La mise en correspondance des hôtes n'est pas possible 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.ip` n'est pas pris en charge. Vous devez utiliser des contrôles des règles plus larges, comme la mise en correspondance de l'identité de la source, ou activer l'inspection TLS pour le filtrage basé sur l'hôte.	Pour utiliser l'outil Application Matcher, 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 le Session Matcher et l'Application Matcher.	1. Définissez une règle générale de correspondance de session qui renvoie `true` ou correspond à l'hôte de destination, tel que `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 correspondance d'hôte pour le mode "Saut suivant"

Lorsque vous déployez Secure Web Proxy comme prochain saut, vous devez configurer des règles de correspondance d'hôte. Le trafic est redirigé vers le proxy via une route de cloud privé virtuel (VPC) basée sur les plages d'adresses IP que vous définissez. Les règles de correspondance d'hôte 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 SNI (Server Name Indication).

Dans le mode "Prochain saut", la correspondance de l'hôte fonctionne pour différents types de trafic Web de la manière suivante :

Type de trafic	Mécanisme de mise en correspondance	Configuration de la règle
HTTP non chiffré	Le Secure Web Proxy vérifie le nom d'hôte de destination par rapport au champ `host` dans l'en-tête de requête HTTP standard.	Dans le champ `sessionMatcher`, spécifiez `host() == "example.com"`.
HTTPS chiffré (sans inspection TLS)	Le proxy Web sécurisé compare le nom d'hôte à l'en-tête SNI de la requête sortante, qui est visible même si le reste du trafic est chiffré.	Dans le champ `sessionMatcher`, spécifiez `host() == "example.com"`.
HTTPS chiffré (avec inspection TLS)	Pour inspecter la requête complète, vous devez utiliser à la fois le Session Matcher et l'Application Matcher.	1. Définissez une règle générale de correspondance de session qui renvoie `true` ou correspond à l'hôte de destination, tel que `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 le protocole TCP.

Si votre charge de travail (telle que vos applications et services) utilise Secure Web Proxy comme prochain saut, il est avantageux d'appliquer des règles de proxy TCP. 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 empêcher le trafic sortant d'atteindre 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 le 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 Secure Web Proxy comme prochain saut 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 Session Matcher 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`	string	Adresse IP du client qui a envoyé la requête.
`source.port`	string	Port client ayant envoyé la requête.
`destination.port`	string	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 être supérieurs à "/64".

Exemple de règle de proxy TCP

Cet exemple montre comment définir un gatewaySecurityPolicyRule Secure Web Proxy à 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 de Secure Web Proxy.

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 - such as, for SSH"
basicProfile: ALLOW
sessionMatcher: "destination.port == 22"

Remplacez les éléments suivants :

PROJECT_ID : ID de votre projet
REGION : région de votre règle
POLICY_NAME : nom de votre règle
RULE_NAME : nom de la règle de proxy TCP. Dans cet exemple, nous pouvons considérer sa valeur comme allow-ssh-tcp-proxy.

Remarques importantes

Toutes les règles de proxy TCP que vous configurez doivent avoir une priorité plus élevée (nombre inférieur) que les règles HTTP/S pour s'assurer qu'elles sont évaluées et appliquées en premier. Pour en savoir plus, consultez Ordre d'évaluation des règles.
Lors de la configuration des règles de proxy TCP, l'attribut host "Session Matcher" n'est pas compatible, car les informations sur l'hôte ne sont pas disponibles au niveau TCP.
Les règles de proxy TCP filtrent le trafic Web en fonction du port de destination uniquement. Pour renforcer la sécurité de votre réseau, nous vous recommandons d'ajouter d'autres conditions à l'aide des opérateurs logiques ET (&&) et OU (||), ainsi que des attributs compatibles tels que source.ip. Voici un exemple de définition d'une règle de proxy TCP plus spécifique :
```
  // Allow port 22 from only a specific source IP range
  sessionMatcher: "destination.port == 22 && inIpRange(source.ip, '10.0.0.0/24')"
```
Secure Web Proxy ne permet pas de configurer des règles de proxy pour les applications protocole de datagramme utilisateur (UDP). Par conséquent, Secure Web Proxy bloque le trafic des applications basées sur UDP.

Créer une règle de sécurité

Avant de créer une règle de sécurité de passerelle, assurez-vous d'effectuer les actions suivantes :

Suivez toutes les étapes de la configuration initiale.
Créer une règle

Après avoir créé une règle et l'avoir associée à une stratégie, vous pouvez l'utiliser lors du déploiement de Secure Web Proxy.

Console

Dans la console Google Cloud , accédez à la page Règles SWP.

Accéder aux règles SWP
Cliquez sur le nom de votre règle, par exemple policy1.
Cliquez sur Ajouter une règle.
Pour chaque règle, procédez comme suit :
1. Pour Priorité, saisissez un ordre d'évaluation numérique pour la règle. Les règles sont évaluées de la priorité la plus élevée à la plus faible, où 0 correspond à la priorité la plus élevée.
2. Dans le champ Nom, saisissez un nom pour la règle.
3. Dans le champ Description, saisissez une description de la règle.
4. Pour Action, sélectionnez l'une des options suivantes :
  - Autoriser : autorise les demandes de connexion correspondant à la règle.
  - Refuser : pour refuser les demandes de connexion correspondant à la règle.
5. Pour le champ État, sélectionnez l'une des options suivantes pour l'application des règles :
  - Activé : pour appliquer la règle à votre instance Secure Web Proxy.
  - Désactivé : pour ne pas appliquer la règle à votre instance Secure Web Proxy.
6. Dans la section Correspondance de session, spécifiez les critères de correspondance de la session, tels que host() == "www.wikipedia.org".
  
  Pour en savoir plus sur la syntaxe de SessionMatcher, consultez la documentation de référence sur le langage de correspondance CEL.
7. Dans la section Correspondance de l'application, spécifiez les critères de correspondance de la requête.
  
  Pour en savoir plus sur la correspondance du trafic TCP, consultez Configurer des règles de proxy TCP.
8. Cliquez sur Ajouter une règle.

Cloud Shell

Utilisez l'éditeur de texte de votre choix pour créer un fichier rule.yaml. Pour en savoir plus sur la syntaxe de sessionMatcher, consultez la documentation de référence sur le langage de correspondance CEL.
```
name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
description: Allow wikipedia.org
enabled: true
priority: 1
basicProfile: ALLOW
sessionMatcher: host() == 'www.wikipedia.org'
```
Remplacez les éléments suivants :
- PROJECT_ID : ID de votre projet
- REGION : région de votre règle
- RULE_NAME : nom de la règle. Dans cet exemple, nous pouvons considérer sa valeur comme allow-wikipedia-org.
Facultatif : Si vous souhaitez créer une règle avec l'inspection TLS activée, créez le fichier rule.yaml comme indiqué ici. Pour en savoir plus, consultez Présentation de l'inspection TLS et Activer l'inspection TLS.
```
  name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
  description: Allow wikipedia.org
  enabled: true
  priority: 1
  basicProfile: ALLOW
  sessionMatcher: host() == 'www.wikipedia.org'
  applicationMatcher: request.path.contains('index.html')
  tlsInspectionEnabled: true
```
Pour en savoir plus sur la correspondance du trafic TCP, consultez Configurer des règles de proxy TCP.

Important : Pour activer l'inspection TLS pour chaque règle que vous créez, définissez l'attribut tlsInspectionEnabled sur true pour chaque règle qui utilise applicationMatcher afin de faire correspondre le trafic HTTPS. L'inspection TLS de la règle est limitée au trafic qui correspond à l'attribut sessionMatcher de la règle. Pour en savoir plus, consultez Évaluation des règles d'inspection TLS.

Créez la règle de stratégie de sécurité.

gcloud network-security gateway-security-policies rules import allow-wikipedia-org \
    --source=rule.yaml \
    --location=REGION \
    --gateway-security-policy=policy1

Limites

Si vous créez une stratégie d'autorisation dans votre instance Secure Web Proxy, le proxy ignore toutes les stratégies de sécurité de passerelle et les règles de sécurité de passerelle associées existantes.
Secure Web Proxy ne permet pas de configurer des règles pour les applications User Datagram Protocol (UDP). Secure Web Proxy bloque le trafic des applications basées sur UDP.