Configurer les règles

Le proxy Web sécurisé vous permet de définir différents types de règles dans vos stratégies afin de 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.

Cette page décrit les différents types de règles, ainsi que les étapes à suivre pour les créer et les ajouter à votre stratégie de sécurité.

Configurer des règles de mise en correspondance des hôtes

Les règles de mise en correspondance des hôtes évaluent le nom d'hôte de destination d'une requête Web par rapport à vos listes d'URL autorisées ou refusées . En vérifiant le domaine de destination, tel que www.example.com, ces règles garantissent que votre trafic n'atteint que les sites Web et services approuvés.

Cette section explique comment configurer des règles de mise en correspondance des hôtes pour les modes de déploiement suivants du proxy Web sécurisé :

Mode proxy explicite
Mode de saut suivant

Mode proxy explicite

Lorsque vous déployez le proxy Web sécurisé 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 proxy Web sécurisée.

La mise en correspondance des hôtes en mode proxy explicite fonctionne de la manière suivante 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` de 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 n'est pas pris en charge.`destination.ip` Vous devez utiliser des contrôles de stratégie 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 l'outil de 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 l' outil de mise en correspondance des sessions et l'outil de mise en correspondance des applications.	1. Définissez une règle générale de l'outil de mise en correspondance des sessions qui renvoie `true` ou qui 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, telle que `request.host() == "example.com"`.

Mode de saut suivant

Lorsque vous déployez le proxy Web sécurisé en tant que saut suivant, 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) basée sur les 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 la manière suivante 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` de l'en-tête de requête HTTP standard.	Dans le champ `sessionMatcher`, utilisez `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`, utilisez `host() == "example.com"`.
HTTPS chiffré (avec inspection TLS)	Pour inspecter la requête complète, vous devez utiliser à la fois l' outil de mise en correspondance des sessions et l'outil de mise en correspondance des applications.	1. Définissez une règle générale de l'outil de mise en correspondance des sessions qui renvoie `true` ou qui 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, telle que `request.host() == "example.com"`.

Configurer des règles de proxy TCP

Vous pouvez configurer des règles de proxy TCP (protocole TCP) pour votre application afin de sécuriser le trafic non Web et d’appliquer des stratégies 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 le 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 suivants de l'outil de mise en correspondance des sessions 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 de proxy Web sécurisée 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` tel que `source.matchServiceAccount('x@my-project.iam.gserviceaccount.com')`.
`inIpRange(IP_ADDRESS, IP_RANGE)`	booléen	`True`, si `IP_ADDRESS` est contenu dans le `IP_RANGE`, tel que `inIpRange(source.ip, '1.2.3.0/24')`. Les masques de sous-réseau pour les adresses IPv6 ne peuvent pas dépasser `/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 - 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 stratégie
POLICY_NAME : nom de votre stratégie
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 la section Ordre d'évaluation des règles.
Lors de la configuration des règles de proxy TCP, l'attribut host de l'outil de mise en correspondance des sessions n'est pas pris en charge, car les informations d'hôte ne sont pas disponibles au niveau de la couche TCP.
Les règles de proxy TCP filtrent le trafic Web en fonction uniquement du port de destination. Pour améliorer la sécurité de votre réseau, nous vous recommandons d'ajouter d'autres conditions à l'aide d' opérateurs logiques : l'opérateur logique AND (&&) et l'opérateur logique OR (||), 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')"
```
Le proxy Web sécurisé ne permet pas de configurer des règles de proxy pour les applications UDP (User Datagram Protocol). Par conséquent, le proxy Web sécurisé bloque le trafic des applications basées sur UDP.

Créer une règle de proxy Web sécurisé

Cette section explique comment créer une règle de proxy Web sécurisé.

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

Suivez toutes les étapes de la configuration initiale.
Créez 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 du proxy Web sécurisé.

Console

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

Accéder aux règles SWP
Cliquez sur le nom de votre stratégie, par exemple policy1.
Cliquez sur Ajouter une règle.
Pour chaque règle, procédez comme suit :
1. Dans 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 pour la règle.
4. Pour Action, sélectionnez l'une des options suivantes :
  - Autoriser : pour autoriser les requêtes de connexion correspondant à la règle.
  - Refuser : pour refuser les requêtes de connexion correspondant à la règle.
5. Dans le champ État, sélectionnez l'une des options suivantes pour l' application de la règle :
  - Activé : pour appliquer la règle à votre instance de proxy Web sécurisée.
  - Désactivé : pour ne pas appliquer la règle à votre instance de proxy Web sécurisée.
6. Dans la section Correspondance de session, spécifiez les critères de mise en 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 d'application, spécifiez les critères de mise en correspondance de la requête.
  
  Pour en savoir plus sur la mise en correspondance du trafic TCP, consultez la section Configurer des règles de proxy TCP.
8. Cliquez sur Ajouter une règle.

Cloud Shell

Créez le fichier rule.yaml comme indiqué ici. 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 stratégie
- 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 rule.yaml fichier comme indiqué ici. Pour en savoir plus, consultez la section 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 mise en correspondance du trafic TCP, consultez la section 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 mettre en correspondance le trafic HTTPS. L'inspection TLS de la règle est limitée au trafic qui correspond à l' sessionMatcher attribut de la règle. Pour en savoir plus, consultez la section É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