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 : 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

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 - 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 la section Ordre d'évaluation des règles.

  • Lors de la configuration des règles de proxy TCP, l'attribut host de mise en correspondance des sessions n'est pas compatible, 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 uniquement en fonction 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, de l'opérateur logique AND (&&) et de l'opérateur logique OR (||), ainsi que d'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, 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 :

  1. Suivez toutes les étapes de la configuration initiale.

  2. 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 de Secure Web Proxy.

Console

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

    Accéder aux règles SWP

  2. Cliquez sur le nom de votre règle, par exemple policy1.

  3. Cliquez sur Ajouter une règle.

  4. Pour chaque règle, procédez comme suit :

    1. Dans le champ 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 Secure Web Proxy.
      • Désactivé : pour ne pas appliquer la règle à votre instance Secure Web Proxy.

    6. Dans la section Mise en correspondance des sessions, spécifiez les critères de mise en correspondance de la session, par exemple host() == "www.wikipedia.org".

      Pour en savoir plus sur la syntaxe de SessionMatcher, consultez la documentation de référence sur le langage de mise en correspondance CEL.

    7. Dans la section Mise en correspondance des applications, 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

  1. 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 mise en 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 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.

  2. Créez la règle de sécurité. 

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

Limites

Étape suivante