Règles de stratégie de pare-feu

Lorsque vous créez une règle de stratégie de pare-feu, vous spécifiez un ensemble de composants qui définissent le rôle de cette règle. Ces composants spécifient la direction du trafic, la source, la destination et les caractéristiques de couche 4, telles que le protocole et le port de destination (si le protocole utilise des ports).

Chaque règle de pare-feu s'applique soit aux connexions entrantes (entrée), soit aux connexions sortantes (sortie), mais pas aux deux.

Règles d'entrée

La direction entrante fait référence aux connexions entrantes envoyées depuis des sources spécifiques vers des cibles Google Cloud. Les règles d'entrée s'appliquent aux paquets entrants, où la destination des paquets est la cible.

Une règle d'entrée ayant une action deny protège toutes les instances en bloquant leurs connexions entrantes. L'accès entrant peut être autorisé par une règle de priorité supérieure. Un réseau par défaut créé automatiquement inclut des règles de pare-feu VPC préremplies qui autorisent l'entrée pour certains types de trafic.

Règles de sortie

La direction sortante correspond au trafic sortant envoyé depuis une cible vers une destination. Les règles de sortie s'appliquent aux paquets pour les nouvelles connexions où la source du paquet est la cible.

Une règle de sortie ayant une action allow permet à une instance d'envoyer du trafic vers les destinations spécifiées dans la règle. Le trafic sortant peut être refusé par des règles de pare-feu deny de priorité supérieure. Google Cloud bloque ou limite également certains types de trafic.

Composants des règles de stratégie de pare-feu

Les règles des stratégies de pare-feu hiérarchiques, des stratégies de pare-feu réseau globales et des stratégies de pare-feu réseau régionales utilisent les composants décrits dans cette section. Le terme stratégie de pare-feu fait référence à l'un de ces trois types de stratégies. Pour en savoir plus sur les types de stratégies de pare-feu, consultez la page Stratégies de pare-feu.

Les règles des stratégies de pare-feu fonctionnent généralement de la même manière que les règles de pare-feu VPC, à quelques différences près, qui sont décrites dans les sections suivantes.

Priorité

La priorité d'une règle dans une stratégie de pare-feu est un entier compris entre 0 et 2 147 483 647 (inclus). Des entiers plus petits indiquent des priorités plus élevées. La priorité d'une règle d'une stratégie de pare-feu est semblable à la priorité d'une règle de pare-feu VPC, avec les différences suivantes :

  • Chaque règle d'une stratégie de pare-feu doit avoir une priorité unique.
  • La priorité d'une règle dans une stratégie de pare-feu sert d'identifiant unique à la règle. Les règles des stratégies de pare-feu n'utilisent pas de noms pour l'identification.
  • La priorité d'une règle dans une stratégie de pare-feu définit l'ordre d'évaluation dans la stratégie de pare-feu elle-même. Les règles de pare-feu VPC et les règles des stratégies de pare-feu hiérarchiques, des stratégies de pare-feu réseau mondiales et des stratégies de pare-feu réseau régionales sont évaluées comme décrit dans la section Ordre d'évaluation des stratégies et des règles.

Action en cas de correspondance

Une règle d'une stratégie de pare-feu peut avoir l'une des quatre actions suivantes :

  • allow autorise le trafic et arrête toute évaluation approfondie des règles.
  • deny interdit le trafic et arrête toute évaluation approfondie des règles.
  • apply_security_profile_group intercepte de manière transparente le trafic et l'envoie vers le point de terminaison de pare-feu configuré pour l'inspection de couche 7.

Application

Vous pouvez décider si une règle de stratégie de pare-feu est appliquée ou non en définissant son état sur "Activé" ou "Désactivé". Vous définissez l'état d'application lorsque vous créez une règle ou lorsque vous mettez à jour une règle.

Si vous ne définissez pas d'état d'application lorsque vous créez une règle de pare-feu, la règle de pare-feu est automatiquement activée.

Protocols and ports

Comme pour les règles de pare-feu VPC, vous devez spécifier une ou plusieurs contraintes de protocole et de port au moment de la création d'une règle. Lorsque vous indiquez TCP ou UDP dans une règle, vous pouvez spécifier le protocole, le protocole et un port de destination, ou le protocole et une plage de ports de destination. Vous ne pouvez pas spécifier uniquement un port ou une plage de ports. De plus, vous ne pouvez spécifier que des ports de destination. Les règles basées sur les ports sources ne sont pas acceptées.

Vous pouvez utiliser les noms de protocoles suivants dans les règles de pare-feu : tcp, udp, icmp (pour IPv4 ICMP), esp, ah, sctp et ipip. Pour tous les autres protocoles, utilisez les numéros de protocole IANA.

De nombreux protocoles ont les mêmes nom et numéro dans IPv4 et IPv6, ce qui n'est pas le cas de certains protocoles comme ICMP. Pour spécifier le protocole ICMP IPv4, utilisez icmp ou le numéro de protocole 1. Pour spécifier le protocole ICMP IPv6, utilisez le numéro de protocole 58.

Les règles de pare-feu ne permettent pas de spécifier des types et des codes ICMP, mais uniquement le protocole.

Le protocole IPv6 Hop-by-Hop n'est pas compatible avec les règles de pare-feu.

Si vous ne spécifiez pas de paramètres de protocole et de port, la règle s'applique à tous les protocoles et ports de destination.

Journalisation

La journalisation des règles des stratégies de pare-feu fonctionne de la même manière que la journalisation des règles de pare-feu VPC, à l'exception des éléments suivants :

  • Le champ de référence inclut l'ID de la stratégie de pare-feu ainsi qu'un numéro indiquant le niveau de la ressource auquel la stratégie est associée. Par exemple, 0 signifie que la stratégie est appliquée à une organisation et 1 signifie qu'elle est appliquée à un dossier de premier niveau sous l'organisation.

  • Les journaux des règles des stratégies de pare-feu incluent un champ target_resource qui identifie les réseaux VPC auxquels la règle s'applique.

  • La journalisation ne peut être activée que pour les règles allow, deny et apply_security_profile_group. Elle ne peut pas être activée pour les règles goto_next.

Cible, source, destination

Les paramètres cibles identifient les interfaces réseau des instances auxquelles la règle de pare-feu s'applique.

Vous pouvez spécifier à la fois des paramètres sources et des paramètres de destination qui s'appliquent aux sources ou aux destinations des paquets pour les règles de pare-feu d'entrée et de sortie. Le sens de la règle de pare-feu détermine les valeurs possibles pour les paramètres source et de destination.

Les paramètres de cible, de source et de destination fonctionnent conjointement.

Cibles

Le paramètre de cible identifie les interfaces réseau des instances Compute Engine, y compris les nœuds GKE et les instances de l'environnement flexible App Engine.

Vous pouvez définir des cibles pour les règles d'entrée ou de sortie. Les options de cible valides dépendent du type de stratégie de pare-feu.

Cibles pour les règles de stratégies de pare-feu hiérarchiques

Les règles des stratégies de pare-feu hiérarchiques sont compatibles avec les cibles suivantes :

  • Cible la plus large par défaut : lorsque vous omettez la spécification cible dans une règle de stratégie de pare-feu hiérarchique, la règle de pare-feu s'applique à toutes les instances de tous les réseaux VPC dans tous les projets sous le nœud Resource Manager (dossier ou organisation) associé à la stratégie de pare-feu. Il s'agit de l'ensemble de cibles le plus large.

  • Réseaux spécifiques : si vous spécifiez un ou plusieurs réseaux VPC à l'aide du paramètre target-resources, l'ensemble de cibles le plus large est limité aux VM avec une interface réseau dans au moins un des réseaux VPC spécifiés.

  • Instances identifiées par un compte de service : si vous spécifiez un ou plusieurs comptes de service à l'aide du paramètre target-service-accounts, l'ensemble de cibles le plus large est limité aux VM qui utilisent l'un des comptes de service spécifiés.

  • Réseaux et instances spécifiques identifiés par un compte de service : si vous spécifiez à la fois le paramètre target-resources et le paramètre target-service-accounts, l'ensemble de cibles le plus large est limité aux VM qui répondent aux deux critères suivants :

    • Les VM disposent d'une interface réseau dans l'un des réseaux VPC spécifiés.
    • Les VM utilisent l'un des comptes de service spécifiés.

Cibles pour les règles de stratégie de pare-feu de réseau au niveau mondial

Les règles des stratégies de pare-feu de réseau globales sont compatibles avec les cibles suivantes :

  • Cible par défaut : toutes les instances du réseau VPC : lorsque vous omettez la spécification cible dans une règle de stratégie de pare-feu de réseau globale, la règle de pare-feu s'applique aux instances dont l'interface réseau dans le réseau VPC est associée à la stratégie. Les instances peuvent être situées dans n'importe quelle région. Il s'agit de l'ensemble de cibles le plus large.

  • Instances par tags sécurisés cibles : si vous spécifiez des tags cibles avec le paramètre target-secure-tags, l'ensemble de cibles le plus large est limité à ces VM liées aux tags.

  • Instances par comptes de service cibles : si vous spécifiez des comptes de service avec le paramètre target-service-accounts, l'ensemble de cibles le plus large est limité aux seules VM qui utilisent l'un des comptes de service spécifiés.

Cibles pour les règles de stratégie de pare-feu de réseau régionales

Les règles des stratégies de pare-feu de réseau régionales sont compatibles avec les cibles suivantes :

  • Cible par défaut (toutes les instances de la région et du réseau VPC) : lorsque vous omettez la spécification cible dans une règle de stratégie de pare-feu de réseau régionale, la règle de pare-feu s'applique aux instances dont l'interface réseau dans le réseau VPC est associée à la stratégie. Les instances doivent être situées dans la même région que la règle. Il s'agit de l'ensemble de cibles le plus large.

  • Instances par tags sécurisés cibles : si vous spécifiez des tags cibles avec le paramètre target-secure-tags, l'ensemble de cibles le plus large est limité à ces VM liées aux tags.

  • Instances par comptes de service cibles : si vous spécifiez des comptes de service avec le paramètre target-service-accounts, l'ensemble de cibles le plus large est limité aux seules VM qui utilisent l'un des comptes de service spécifiés.

Cibles et adresses IP pour les règles d'entrée

Les paquets acheminés vers l'interface réseau d'une VM cible sont traités en fonction des conditions suivantes :

  • Si la règle de pare-feu d'entrée inclut une plage d'adresses IP de destination, la destination du paquet doit correspondre à l'une des plages d'adresses IP de destination explicitement définies.

  • Si la règle de pare-feu d'entrée n'inclut pas de plage d'adresses IP de destination, la destination du paquet doit correspondre à l'une des adresses IP suivantes :

    • L'adresse IPv4 interne principale attribuée à la carte d'interface réseau de l'instance.

    • Toutes les plages d'adresses IP d'alias configurées sur la carte d'interface réseau de l'instance.

    • L'adresse IPv4 externe associée à la carte d'interface réseau de l'instance.

    • Si IPv6 est configuré sur le sous-réseau, l'une des adresses IPv6 attribuées à la carte d'interface réseau.

    • Une adresse IP interne ou externe associée à une règle de transfert utilisée pour l'équilibrage de charge passthrough, où l'instance est un backend pour un équilibreur de charge réseau passthrough interne ou un équilibreur de charge réseau passthrough externe.

    • Une adresse IP externe ou interne associée à une règle de transfert utilisée pour le transfert de protocole, où l'instance est référencée par une instance cible.

    • Une adresse IP dans la plage de destination d'une route statique personnalisée utilisant l'instance comme VM de saut suivant (next-hop-instance ou next-hop-address).

    • Une adresse IP dans la plage de destination d'une route statique personnalisée utilisant un équilibreur de charge réseau passthrough interne (next-hop-ilb) comme saut suivant si la VM est un backend pour cet équilibreur de charge.

Cibles et adresses IP pour les règles de sortie

Le traitement des paquets émis à partir de l'interface réseau d'une cible dépend de la configuration de transfert IP sur la VM cible. Le transfert IP est désactivé par défaut.

  • Lorsque le transfert IP est désactivé sur la VM cible, celle-ci peut émettre des paquets avec les sources suivantes :

    • L'adresse IPv4 interne principale de la carte d'interface réseau d'une instance.

    • Toutes les plages d'adresses IP d'alias configurées sur la carte d'interface réseau d'une instance.

    • Si IPv6 est configuré sur le sous-réseau, l'une des adresses IPv6 attribuées à la carte d'interface réseau.

    • L'adresse IP interne ou externe associée à une règle de transfert, pour l'équilibrage de charge passthrough ou le transfert de protocole. Cela est valide si l'instance est un backend pour un équilibreur de charge réseau passthrough interne, un équilibreur de charge réseau passthrough externe, ou est référencée par une instance cible.

    Si la règle de pare-feu de sortie inclut des plages d'adresses IP sources, les VM cibles sont toujours limitées aux adresses IP sources mentionnées précédemment, mais le paramètre source peut être utilisé pour affiner cet ensemble. L'utilisation d'un paramètre source sans activer le transfert IP ne développe pas l'ensemble des adresses sources de paquets possibles.

    Si la règle de pare-feu de sortie n'inclut pas de plage d'adresses IP sources, toutes les adresses IP sources mentionnées précédemment sont autorisées.

  • Lorsque le transfert IP est activé sur la VM cible, celle-ci peut émettre des paquets avec des adresses sources arbitraires. Vous pouvez utiliser le paramètre de source pour définir plus précisément l'ensemble des sources de paquets autorisées.

Sources

Les valeurs des paramètres sources dépendent des éléments suivants :

  • Type de stratégie de pare-feu contenant la règle de pare-feu
  • Sens de la règle de pare-feu

Sources des règles d'entrée

Le tableau suivant liste les paramètres de source pouvant être utilisés individuellement ou combinés dans une seule règle de stratégie de pare-feu d'entrée. Cloud NGFW vous oblige à spécifier au moins un paramètre de source.

Paramètre de source de la règle d'Ingress Prise en charge dans les stratégies de pare-feu hiérarchiques Prise en charge dans les stratégies de pare-feu réseau mondiales et régionales
Plages d'adresses IP sources

Liste simple composée d'adresses IPv4 au format CIDR ou d'adresses IPv6 au format CIDR. La liste est stockée dans la règle de stratégie de pare-feu elle-même.
Groupes d'adresses sources

Collections réutilisables d'adresses IPv4 au format CIDR ou d'adresses IPv6 au format CIDR. La règle de pare-feu fait référence à la collection. Pour en savoir plus, consultez la section Groupes d'adresses pour les stratégies de pare-feu.
Noms de domaine source

Liste d'un ou de plusieurs noms de domaine sources. Pour en savoir plus, y compris sur la conversion des noms de domaine en adresses IP, consultez la section Objets de nom de domaine complet.
Tags sécurisés sources

Liste d'un ou de plusieurs tags sécurisés sources. Pour en savoir plus, consultez la section Comment les tags sécurisés sources impliquent des sources de paquets.
Géolocalisations des sources

Liste d'un ou de plusieurs emplacements géographiques sources spécifiés sous forme de codes pays ou région à deux lettres. Pour en savoir plus, consultez la section Objets de géolocalisation.
Sourcer les listes Google Threat Intelligence

Liste d'un ou de plusieurs noms de liste Google Threat Intelligence prédéfinis. Pour en savoir plus, consultez la section Google Threat Intelligence pour les règles de stratégie de pare-feu.
Champ d'application réseau source

Contrainte qui définit une limite de sécurité. Pour en savoir plus, consultez la section Champs d'application du réseau.

Dans une seule règle d'entrée, vous pouvez utiliser deux paramètres sources ou plus pour produire une combinaison de sources. Cloud NGFW applique les contraintes suivantes aux combinaisons de sources de chaque règle d'entrée:

  • Les plages d'adresses IP source doivent contenir des CIDR IPv4 ou IPv6, et non une combinaison des deux.
  • Un groupe d'adresses source contenant des CIDR IPv4 ne peut pas être utilisé avec un groupe d'adresses source contenant des CIDR IPv6.
  • Une plage d'adresses IP source contenant des CIDR IPv4 ne peut pas être utilisée avec un groupe d'adresses source contenant des CIDR IPv6.
  • Une plage d'adresses IP source contenant des CIDR IPv6 ne peut pas être utilisée avec un groupe d'adresses source contenant des CIDR IPv4.
  • La portée du réseau Internet ne peut pas être utilisée avec les tags sécurisés sources.
  • La portée hors Internet, la portée des réseaux VPC et la portée inter-VPC ne peuvent pas être utilisées avec les listes Google Threat Intelligence sources ni les géolocalisations sources.

Cloud NGFW applique la logique suivante pour faire correspondre les paquets à une règle d'entrée qui utilise une combinaison de sources:

  • Si la combinaison de sources n'inclut pas de champ d'application de réseau source, les paquets correspondent à la règle d'entrée s'ils correspondent à au moins un paramètre source de la combinaison de sources.

  • Si la combinaison de sources inclut un champ d'application réseau source, les paquets correspondent à la règle d'entrée s'ils correspondent au champ d'application réseau source et à au moins l'un des autres paramètres source de la combinaison de sources.

Comment les tags sécurisés sources impliquent des sources de paquets

Les règles d'entrée dans les stratégies de pare-feu de réseau globales et régionales peuvent spécifier des sources à l'aide de tags sécurisés. Chaque tag sécurisé est associé à un seul réseau VPC, et ne peut être associé qu'à une VM disposant d'une interface réseau dans le réseau VPC auquel le tag sécurisé est associé.

Les paquets envoyés à partir d'une interface réseau d'une VM correspondent à une règle d'entrée qui utilise une source de tag sécurisée lorsque les conditions suivantes sont remplies:

  • Si la règle d'entrée se trouve dans une stratégie de réseau régionale, la VM doit se trouver dans une zone de la région de la stratégie de pare-feu réseau. Si la règle d'entrée se trouve dans une stratégie de pare-feu réseau globale, la VM peut se trouver dans n'importe quelle zone.

  • L'interface réseau de la VM qui envoie les paquets répond à l'un des critères suivants:

    • L'interface réseau de la VM se trouve dans le même réseau VPC que le réseau VPC auquel la stratégie de pare-feu réseau globale ou régionale s'applique.
    • L'interface réseau de la VM se trouve dans un réseau VPC connecté, à l'aide de l'appairage de réseaux VPC, au réseau VPC auquel s'applique la stratégie de pare-feu réseau globale ou régionale.
    • Le réseau VPC utilisé par l'interface réseau de la VM et le réseau VPC auquel la stratégie de pare-feu réseau globale ou régionale s'applique sont tous deux des branches VPC sur le même hub Network Connectivity Center.

  • L'adresse IP source du paquet correspond à l'une des adresses suivantes:

    • Adresse IPv4 interne principale de l'interface réseau.
    • N'importe quelle adresse IPv6 (interne ou externe) attribuée à l'interface réseau.

Aucune autre adresse IP source du paquet n'est résolue lorsque vous utilisez des tags sécurisés sources. Par exemple, les plages d'adresses IP d'alias et les adresses IPv4 externes associées à l'interface réseau sont exclues. Si vous devez créer des règles de pare-feu d'entrée avec des sources qui incluent des plages d'adresses IP d'alias ou des adresses IPv4 externes, utilisez plutôt une plage d'adresses source ou un groupe d'adresses source.

Sources des règles de sortie

Vous pouvez utiliser les sources suivantes pour les règles de sortie dans les stratégies de pare-feu hiérarchiques et les stratégies de pare-feu de réseau :

  • Par défaut, implicite par la cible : Si vous omettez le paramètre source d'une règle de sortie, les sources des paquets sont définies implicitement comme décrit dans la sectionCibles et adresses IP pour les règles de sortie.

  • Plages d'adresses IPv4 sources : liste d'adresses IPv4 au format CIDR.

  • Plages d'adresses IPv6 sources : liste d'adresses IPv6 au format CIDR.

Suivez les instructions ci-dessous pour ajouter des plages d'adresses IP sources aux règles de sortie :

  • Si des adresses IPv4 internes et externes sont attribuées à une interface de VM, seule l'adresse IPv4 interne est utilisée lors de l'évaluation des règles.

  • Si vous disposez d'une plage d'adresses IP sources et de paramètres de destination dans la règle de sortie, les paramètres de destination sont résolus dans la même version IP que la version IP source.

    Par exemple, dans une règle de sortie, vous disposez d'une plage d'adresses IPv4 dans le paramètre source et d'un objet FQDN (nom de domaine complet) dans le paramètre de destination. Si le FQDN est résolu à la fois en adresses IPv4 et IPv6, seule l'adresse IPv4 résolue est utilisée lors de l'application de la règle.

Destinations

Les destinations peuvent être spécifiées à l'aide de plages d'adresses IP, qui sont compatibles avec les règles d'entrée et de sortie dans les stratégies de pare-feu hiérarchiques et de réseaux. Le comportement de destination par défaut dépend du sens de la règle.

Destinations pour les règles d'entrée

Vous pouvez utiliser les destinations suivantes pour les règles de pare-feu d'entrée dans les stratégies de pare-feu hiérarchiques et de réseau :

  • Par défaut, implicite par la cible : si vous omettez le paramètre de destination dans une règle d'entrée, les destinations des paquets sont définies implicitement, comme décrit dans la section Cibles et adresses IP pour les règles d'entrée

  • Plages d'adresses IPv4 de destination : liste des adresses IPv4 au format CIDR.

  • Plages d'adresses IPv6 de destination : liste des adresses IPv6 au format CIDR.

Suivez ces instructions pour ajouter des plages d'adresses IP de destination pour les règles d'entrée :

Destinations pour les règles de sortie

Le tableau suivant liste les paramètres de destination pouvant être utilisés individuellement ou combinés dans une seule règle de stratégie de pare-feu de sortie. Cloud NGFW nécessite que vous spécifiiez au moins un paramètre de destination.

Paramètre de destination de la règle de sortie Prise en charge dans les stratégies de pare-feu hiérarchiques Prise en charge dans les stratégies de pare-feu réseau mondiales et régionales
Plages d'adresses IP de destination

Liste simple composée d'adresses IPv4 au format CIDR ou d'adresses IPv6 au format CIDR. La liste est stockée dans la règle de stratégie de pare-feu elle-même.
Groupes d'adresses de destination

Collections réutilisables d'adresses IPv4 au format CIDR ou d'adresses IPv6 au format CIDR. La règle de stratégie de pare-feu fait référence à la collection. Pour en savoir plus, consultez la section Groupes d'adresses pour les stratégies de pare-feu.
Noms de domaine de destination

Liste d'un ou de plusieurs noms de domaine sources. Pour en savoir plus, y compris sur la conversion des noms de domaine en adresses IP, consultez la section Objets de nom de domaine complet.
Zones géographiques de destination

Liste d'un ou de plusieurs emplacements géographiques sources spécifiés sous forme de codes pays ou région à deux lettres. Pour en savoir plus, consultez la section Objets de géolocalisation.
Listes Google Threat Intelligence de destination

Liste d'un ou de plusieurs noms de liste Google Threat Intelligence prédéfinis. Pour en savoir plus, consultez la section Google Threat Intelligence pour les règles de stratégie de pare-feu.
Champ d'application réseau de destination

Contrainte qui définit une limite de sécurité. Pour en savoir plus, consultez la section Champs d'application du réseau.

Dans une seule règle de sortie, vous pouvez utiliser au moins deux paramètres de destination pour générer une combinaison de destinations. Cloud NGFW applique les contraintes suivantes aux combinaisons de destinations de chaque règle de sortie:

  • Les plages d'adresses IP de destination doivent contenir des CIDR IPv4 ou IPv6, et non une combinaison des deux.
  • Un groupe d'adresses de destination contenant des CIDR IPv4 ne peut pas être utilisé avec un groupe d'adresses de destination contenant des CIDR IPv6.
  • Une plage d'adresses IP de destination contenant des CIDR IPv4 ne peut pas être utilisée avec un groupe d'adresses de destination contenant des CIDR IPv6.
  • Une plage d'adresses IP de destination contenant des CIDR IPv6 ne peut pas être utilisée avec un groupe d'adresses de destination contenant des CIDR IPv4.
  • Les listes Google Threat Intelligence de destination ou les géolocalisations de destination ne peuvent pas être utilisées avec une portée de réseau de destination autre qu'Internet.

Cloud NGFW applique la logique suivante pour faire correspondre les paquets à une règle de sortie qui utilise une combinaison de destinations:

  • Si la combinaison de destinations n'inclut pas de champ d'application de réseau de destination, les paquets correspondent à la règle de sortie s'ils correspondent à au moins un paramètre de destination de la combinaison de destinations.

  • Si la combinaison de destinations inclut une portée réseau de destination, les paquets correspondent à la règle de sortie s'ils correspondent à la portée réseau de destination et à au moins l'un des autres paramètres de destination de la combinaison de destinations.

Champs d'application réseau

Les champs d'application réseau vous aident à atteindre vos objectifs de sécurité en utilisant moins de règles de stratégie de pare-feu plus efficacement. Cloud NGFW prend en charge quatre types de portées réseau qui peuvent être utilisés pour créer une combinaison source ou une combinaison de destination dans une règle d'une stratégie de pare-feu hiérarchique, d'une stratégie de pare-feu réseau globale ou d'une stratégie de pare-feu réseau régionale.

Types de champ d'application réseau

Le tableau suivant liste les quatre types de portées réseau et indique si un type de portée peut être utilisé dans une combinaison source d'une règle d'entrée, dans une combinaison de destination d'une règle de sortie, ou dans les deux.

Type de champ d'application réseau Sources des règles d'entrée Destinations pour les règles de sortie
Internet (INTERNET)
Hors connexion (NON_INTERNET)
Réseaux VPC (VPC_NETWORKS)
Intra-VPC (INTRA_VPC)

Les portées Internet et hors Internet s'excluent mutuellement. Les réseaux VPC et les portées intra-VPC sont des sous-ensembles de la portée hors Internet.

Champ d'application Internet

La portée Internet (INTERNET) peut être utilisée dans une combinaison de sources d'une règle d'entrée ou dans une combinaison de destinations d'une règle de sortie:

  • Pour une règle d'entrée, spécifiez la source de portée Internet et au moins un autre paramètre source, à l'exception d'une source de tag sécurisé. Les paquets correspondent à la règle d'entrée s'ils correspondent à au moins l'un des autres paramètres source et au paramètre source de portée Internet.

  • Pour une règle de sortie, spécifiez la destination de portée Internet et au moins un autre paramètre de destination. Les paquets correspondent à la règle de sortie s'ils correspondent à au moins l'un des autres paramètres de destination et au paramètre de destination de portée Internet.

Le reste de cette section décrit les critères utilisés par Cloud NGFW pour déterminer si un paquet appartient à la portée Internet.

Portée Internet pour les paquets d'entrée

Les paquets d'Ingress acheminés vers une interface réseau de VM par un Maglev Google sont considérés comme faisant partie du champ d'application d'Internet. Les paquets sont acheminés par un Maglev vers une interface réseau de VM lorsque la destination du paquet correspond à l'un des éléments suivants:

  • Adresse IPv4 externe régionale d'une interface réseau de VM, règle de transfert d'un équilibreur de charge réseau passthrough externe ou règle de transfert pour le transfert de protocole externe.
  • Une adresse IPv6 externe régionale d'une interface réseau de VM, une règle de transfert d'un équilibreur de charge réseau passthrough externe ou une règle de transfert pour le transfert de protocole externe, et le paquet n'a pas été acheminé à l'aide d'une route de sous-réseau importée par l'appairage réseau VPC ou à partir d'un rayon VPC sur un hub Network Connectivity Center.

Pour en savoir plus sur les paquets acheminés par Maglev vers les VM de backend pour un équilibreur de charge réseau passthrough externe ou un transfert de protocole externe, consultez la section Chemins d'accès pour les équilibreurs de charge réseau passthrough externes et le transfert de protocole externe.

Portée Internet pour les paquets de sortie

Les paquets de sortie envoyés par les interfaces réseau de la VM et acheminés à l'aide de routes statiques qui utilisent le prochain saut de la passerelle Internet par défaut sont considérés comme faisant partie du champ d'application Internet. Toutefois, si l'adresse IP de destination de ces paquets de sortie est destinée aux API et services Google, ces paquets sont considérés comme hors du champ d'application d'Internet. Pour en savoir plus sur la connectivité aux API et services Google, consultez la section Champ d'application hors Internet.

Lorsque les paquets sont acheminés à l'aide d'une route statique qui utilise le prochain saut de la passerelle Internet par défaut, tous les paquets envoyés par les interfaces réseau de la VM aux destinations suivantes sont considérés dans le champ d'application Internet:

  • Destination d'une adresse IP externe en dehors du réseau de Google.
  • Adresse IPv4 externe régionale de destination d'une interface réseau de VM, règle de transfert d'un équilibreur de charge externe régional ou règle de transfert pour le transfert de protocole externe.
  • Adresse IPv6 externe régionale de destination d'une interface réseau de VM, règle de transfert d'un équilibreur de charge externe régional ou règle de transfert pour le transfert de protocole externe.
  • Destination d'une adresse IPv4 et IPv6 externe globale d'une règle de transfert d'un équilibreur de charge externe global.

Les paquets envoyés par les interfaces réseau de la VM aux passerelles Cloud VPN et Cloud NAT sont considérés dans le champ d'application d'Internet:

  • Les paquets de sortie envoyés depuis une interface réseau d'une VM exécutant un logiciel VPN vers l'adresse IPv4 externe régionale d'une passerelle Cloud VPN sont considérés comme relevant du champ d'application Internet.
  • Les paquets de sortie envoyés d'une passerelle Cloud VPN à une autre ne sont pris en compte dans aucun champ d'application réseau, car les règles de pare-feu ne s'appliquent qu'aux VM.
  • Pour le NAT public, les paquets de réponse envoyés depuis une interface réseau de VM à l'adresse IPv4 externe régionale d'une passerelle Cloud NAT sont considérés dans le champ d'application d'Internet.

Si des réseaux VPC sont connectés à l'aide de l'appairage de réseaux VPC ou si des réseaux VPC participent en tant que spokes VPC sur le même hub Network Connectivity Center, les routes de sous-réseau IPv6 peuvent fournir une connectivité aux destinations d'adresses IPv6 externes régionales des interfaces réseau de VM, aux règles de transfert d'équilibreur de charge externe régional et aux règles de transfert de protocole externe. Lorsque la connectivité à ces destinations d'adresses IPv6 externes régionales est fournie à l'aide d'une route de sous-réseau, les destinations se trouvent dans le champ d'application hors Internet.

Champ d'application hors Internet

Le champ d'application hors Internet (NON-INTERNET) peut être utilisé dans une combinaison de sources d'une règle d'entrée ou dans une combinaison de destinations d'une règle de sortie:

  • Pour une règle d'entrée, spécifiez la source de portée hors Internet et au moins un autre paramètre de source, sauf pour une source de liste Threat Intelligence ou une source de géolocalisation. Les paquets correspondent à la règle d'entrée s'ils correspondent à au moins l'un des autres paramètres source et au paramètre source de portée non Internet.

  • Pour une règle de sortie, spécifiez la destination hors champ d'application Internet et au moins un autre paramètre de destination. Les paquets correspondent à la règle de sortie s'ils correspondent à au moins l'un des autres paramètres de destination et au paramètre de destination de portée non Internet.

Le reste de cette section décrit les critères utilisés par Cloud NGFW pour déterminer si un paquet appartient à la portée hors Internet.

Portée non Internet pour les paquets d'entrée

Les paquets d'Ingress acheminés vers une interface réseau de VM à l'aide de sauts suivants dans un réseau VPC ou à partir d'API et de services Google sont considérés comme hors champ Internet.

Les paquets sont acheminés à l'aide de sauts suivants dans un réseau VPC ou à partir des API et services Google dans les scénarios suivants:

  • La destination du paquet correspond à l'un des éléments suivants:

    • Adresse IPv4 ou IPv6 régionale interne d'une interface réseau de VM, règle de transfert d'un équilibreur de charge réseau passthrough interne ou règle de transfert pour le transfert de protocole interne.
    • Une adresse IPv6 externe régionale d'une interface réseau de VM, une règle de transfert d'un équilibreur de charge réseau passthrough externe ou une règle de transfert pour le transfert de protocole externe, et le paquet a été acheminé à l'aide d'une route de sous-réseau local, d'une route de sous-réseau d'appairage ou d'une route de sous-réseau du Network Connectivity Center.
    • Toute adresse dans la plage de destination d'une route statique où la VM de réception est une VM de saut suivant ou une VM de backend d'un équilibreur de charge réseau passthrough interne de saut suivant.

  • La source du paquet correspond à l'un des éléments suivants:

Portée non Internet pour les paquets de sortie

Les paquets de sortie envoyés par les interfaces réseau de la VM et acheminés dans un réseau VPC ou envoyés aux API et services Google sont considérés comme faisant partie du champ d'application hors Internet.

Les paquets sont acheminés à l'aide de sauts suivants dans un réseau VPC ou vers les API et services Google dans les scénarios suivants:

Champ d'application des réseaux VPC

Le champ d'application Réseaux VPC (VPC_NETWORKS) ne peut être utilisé que dans le cadre d'une combinaison de sources d'une règle d'entrée. Vous ne pouvez pas utiliser la portée des réseaux VPC dans une combinaison de destinations d'une règle de sortie.

Pour utiliser la portée des réseaux VPC dans le cadre d'une combinaison de sources d'une règle d'entrée, procédez comme suit:

  1. Vous devez spécifier une liste de réseaux VPC sources:

    • La liste des réseaux sources doit contenir au moins un réseau VPC. Vous pouvez ajouter jusqu'à 250 réseaux VPC à la liste des réseaux sources.
    • Un réseau VPC doit exister avant de pouvoir l'ajouter à la liste des réseaux sources.
    • Vous pouvez ajouter le réseau à l'aide de son identifiant d'URL partiel ou complet.
    • Les réseaux VPC que vous ajoutez à la liste des réseaux sources n'ont pas besoin d'être connectés les uns aux autres. Chaque réseau VPC peut se trouver dans n'importe quel projet.
    • Si un réseau VPC est supprimé après avoir été ajouté à la liste des réseaux sources, la référence au réseau supprimé reste dans la liste. Le NGFW Cloud ignore les réseaux VPC supprimés lors de l'application d'une règle d'entrée. Si tous les réseaux VPC de la liste des réseaux sources sont supprimés, les règles d'entrée qui s'appuient sur la liste sont inefficaces, car elles ne correspondent à aucun paquet.

  2. Vous devez spécifier au moins un autre paramètre de source, à l'exception d'une source de liste d'informations sur les menaces ou d'une source de géolocalisation.

Un paquet correspond à une règle d'entrée qui utilise la portée des réseaux VPC dans sa combinaison de sources si toutes les conditions suivantes sont remplies:

  • Le paquet correspond à au moins un des autres paramètres de source.

  • Le paquet est envoyé par une ressource située dans l'un des réseaux VPC sources.

  • Le réseau VPC source et le réseau VPC auquel la stratégie de pare-feu contenant la règle d'entrée s'applique sont le même réseau VPC, ou sont connectés à l'aide de l'appairage de réseaux VPC ou en tant que spokes VPC sur un hub Network Connectivity Center.

Les ressources suivantes se trouvent dans un réseau VPC:

  • Interfaces réseau de VM
  • Tunnels Cloud VPN
  • Rattachements de VLAN Cloud Interconnect
  • Appareils de routeur
  • Proxies Envoy dans un sous-réseau proxy réservé
  • Points de terminaison Private Service Connect
  • Connecteurs d'accès au VPC sans serveur

Champ d'application intra-VPC

La portée réseau intra-VPC (INTRA_VPC) ne peut être utilisée que dans le cadre d'une combinaison de sources d'une règle d'entrée. Vous ne pouvez pas utiliser la portée intra-VPC dans une combinaison de destination d'une règle de sortie.

Pour utiliser la portée intra-VPC dans le cadre d'une combinaison de sources d'une règle d'entrée, vous devez spécifier au moins un autre paramètre de source, sauf pour une source de liste Threat Intelligence ou une source de géolocalisation.

Un paquet correspond à une règle d'entrée qui utilise la portée intra-VPC dans sa combinaison source si toutes les conditions suivantes sont remplies:

  • Le paquet correspond à au moins un des autres paramètres de source.

  • Le paquet est envoyé par une ressource située dans le réseau VPC auquel la stratégie de pare-feu contenant la règle d'entrée s'applique.

Les ressources suivantes se trouvent dans un réseau VPC:

  • Interfaces réseau de VM
  • Tunnels Cloud VPN
  • Rattachements de VLAN Cloud Interconnect
  • Appareils de routeur
  • Proxies Envoy dans un sous-réseau proxy réservé
  • Points de terminaison Private Service Connect
  • Connecteurs d'accès au VPC sans serveur

Objets de géolocalisation

Utilisez des objets de géolocalisation dans les règles de stratégie de pare-feu pour filtrer le trafic IPv4 et IPv6 externe en fonction d'emplacements géographiques ou de régions spécifiques.

Vous pouvez appliquer des règles avec des objets de géolocalisation au trafic entrant et sortant. Selon la direction du trafic, les adresses IP associées aux codes pays sont mises en correspondance avec la source ou la destination du trafic.

  • Vous pouvez configurer des objets de géolocalisation pour des stratégies de pare-feu hiérarchiques, des stratégies de pare-feu réseau globales et des stratégies de pare-feu réseau régionales.

  • Pour ajouter des géolocalisations aux règles de stratégie de pare-feu, utilisez les codes pays ou région à deux lettres, tels que définis dans les codes pays ISO 3166 alpha-2.

    Par exemple, si vous souhaitez n'autoriser le trafic entrant que des États-Unis vers le réseau, créez une règle de pare-feu d'entrée avec le code pays source défini sur US et l'action définie sur allow. De même, si vous souhaitez n'autoriser le trafic sortant que vers les États-Unis, configurez une règle de stratégie de pare-feu de sortie avec le code pays de destination défini sur US et l'action définie sur allow.

  • Cloud NGFW vous permet de configurer des règles de pare-feu pour les territoires suivants, qui sont soumis à des sanctions complètes aux États-Unis:

    Territoires Code attribué
    Crimée XC
    Républiques populaires autoproclamées de Donetsk et de Lougansk XD

  • Si une règle de pare-feu comporte plusieurs codes pays en double, une seule entrée est conservée pour ce code pays. L'entrée en double est supprimée. Par exemple, dans la liste de codes pays ca,us,us, seul ca,us est conservé.

  • Google gère une base de données avec des adresses IP et des mappages de codes pays. Les pare-feu Google Cloud utilisent cette base de données pour mapper les adresses IP du trafic source et de destination au code pays, puis appliquent la règle de stratégie de pare-feu correspondante aux objets de géolocalisation.

  • Parfois, les attributions d'adresses IP et les codes pays changent en raison des conditions suivantes :

    Étant donné qu'il faut un certain temps pour que ces modifications soient reflétées dans la base de données de Google, vous pouvez constater des interruptions et des changements de comportement pour certains trafics bloqués ou autorisés.

Utiliser des objets de géolocalisation avec d'autres filtres de règles de stratégie de pare-feu

Vous pouvez utiliser des objets de géolocalisation avec d'autres filtres sources ou de destination. Selon le sens de la règle, la règle de stratégie de pare-feu est appliquée au trafic entrant ou sortant qui correspond à l'union de tous les filtres spécifiés.

Pour en savoir plus sur le fonctionnement des objets de géolocalisation avec d'autres filtres sources dans les règles d'entrée, consultez les sections Sources des règles d'entrée dans les stratégies de pare-feu hiérarchiques et Sources des règles d'entrée dans les stratégies de pare-feu réseau.

Pour en savoir plus sur le fonctionnement des objets de géolocalisation avec d'autres filtres de destination dans les règles de sortie, consultez la section Destinations pour les règles de sortie.

Google Threat Intelligence pour les règles de stratégie de pare-feu

Les règles de stratégie de pare-feu vous permettent de sécuriser votre réseau en autorisant ou en bloquant le trafic en fonction des données Google Threat Intelligence. Les données Google Threat Intelligence incluent des listes d'adresses IP basées sur les catégories suivantes:

  • Nœuds de sortie Tor : Tor est un logiciel Open Source qui permet des communications anonymes. Pour exclure les utilisateurs qui masquent leur identité, bloquez les adresses IP des nœuds de sortie Tor (c'est-à-dire les points de terminaison au niveau desquels le trafic quitte le réseau Tor).
  • Adresses IP malveillantes connues : adresses IP connues pour être à l'origine des attaques d'applications Web. Pour améliorer la stratégie de sécurité de votre application, bloquez ces adresses IP.
  • Moteurs de recherche : adresses IP que vous pouvez autoriser afin d'activer l'indexation des sites.
  • Plages d'adresses IP du cloud public : cette catégorie peut être bloquée pour éviter que des outils automatisés malveillants ne parcourent des applications Web, ou autorisée si votre service utilise d'autres clouds publics. Cette catégorie est également divisée en plusieurs sous-catégories, décrites ci-dessous :
    • Correspond aux plages d'adresses IP utilisées par Amazon Web Services
    • Correspond aux plages d'adresses IP utilisées par Microsoft Azure
    • Correspond aux plages d'adresses IP utilisées par Google Cloud
    • Correspond aux plages d'adresses IP utilisées par les services Google

Les listes de données Google Threat Intelligence peuvent inclure des adresses IPv4, des adresses IPv6, ou les deux. Pour configurer Google Threat Intelligence dans vos règles de stratégie de pare-feu, utilisez les noms de listes Google Threat Intelligence prédéfinis en fonction de la catégorie que vous souhaitez autoriser ou bloquer. Ces listes sont constamment mises à jour, protégeant ainsi les services contre les nouvelles menaces sans étape de configuration supplémentaire. Les noms de liste valides sont les suivants.

Nom de la liste Description
iplist-tor-exit-nodes Correspond aux adresses IP des nœuds de sortie TOR
iplist-known-malicious-ips Correspond aux adresses IP connues pour attaquer des applications Web
iplist-search-engines-crawlers Correspond aux adresses IP des robots d'exploration des moteurs de recherche
iplist-vpn-providers Correspond aux adresses IP appartenant à des fournisseurs de VPN dont la réputation est faible
iplist-anon-proxies Correspond aux adresses IP appartenant à des proxys anonymes ouverts
iplist-crypto-miners Correspond aux adresses IP appartenant à des sites de minage de cryptomonnaie
iplist-public-clouds
  • iplist-public-clouds-aws
  • iplist-public-clouds-azure
  • iplist-public-clouds-gcp
  • iplist-public-clouds-google-services
 Correspond aux adresses IP appartenant à des clouds publics
  • Correspond aux plages d'adresses IP utilisées par Amazon Web Services
  • Correspond aux plages d'adresses IP utilisées par Microsoft Azure
  • Correspond aux plages d'adresses IP utilisées par Google Cloud
  • Correspond aux plages d'adresses IP utilisées par les services Google

Utiliser Google Threat Intelligence avec d'autres filtres de règles de stratégie de pare-feu

Pour définir une règle de stratégie de pare-feu avec Google Threat Intelligence, procédez comme suit:

  • Pour les règles de sortie, spécifiez la destination à l'aide d'une ou de plusieurs listes Google Threat Intelligence de destination.

  • Pour les règles d'entrée, spécifiez la source à l'aide d'une ou de plusieurs listes Google Threat Intelligence sources.

  • Vous pouvez configurer des listes Google Threat Intelligence pour les stratégies de pare-feu hiérarchiques, les stratégies de pare-feu réseau globales et les stratégies de pare-feu réseau régionales.

  • Vous pouvez utiliser ces listes avec d'autres composants de filtre des règles sources ou de destination.

    Pour en savoir plus sur le fonctionnement des listes Google Threat Intelligence avec d'autres filtres sources dans les règles d'entrée, consultez les sections Sources des règles d'entrée dans les stratégies de pare-feu hiérarchiques et Sources des règles d'entrée dans les stratégies de pare-feu réseau.

    Pour en savoir plus sur le fonctionnement des listes Google Threat Intelligence avec d'autres filtres de destination dans les règles de sortie, consultez la section Destinations pour les règles de sortie.

  • La journalisation du pare-feu est effectuée au niveau de la règle. Pour faciliter le débogage et l'analyse des effets de vos règles de pare-feu, n'incluez pas plusieurs listes Google Threat Intelligence dans une seule règle de pare-feu.

  • Vous pouvez ajouter plusieurs listes Google Threat Intelligence à une règle de stratégie de pare-feu. Chaque nom de liste inclus dans la règle compte pour un attribut, quel que soit le nombre d'adresses IP ou de plages d'adresses IP incluses dans cette liste. Par exemple, si vous avez inclus les noms de liste iplist-tor-exit-nodes, iplist-known-malicious-ips et iplist-search-engines-crawlers dans votre règle de stratégie de pare-feu, le nombre d'attributs de règle par stratégie de pare-feu est augmenté de trois. Pour en savoir plus sur le nombre d'attributs de règle, consultez la page Quotas et limites.

Créer des exceptions aux listes Google Threat Intelligence

Si vous disposez de règles qui s'appliquent à des listes Google Threat Intelligence, vous pouvez utiliser les techniques suivantes pour créer des règles d'exception applicables à certaines adresses IP dans une liste Google Threat Intelligence:

  • Liste d'autorisation sélective: supposons que vous ayez une règle de pare-feu d'entrée ou de sortie qui refuse les paquets depuis ou vers une liste Google Threat Intelligence. Pour autoriser les paquets depuis ou vers une adresse IP spécifique dans cette liste Google Threat Intelligence, créez une règle de pare-feu d'autorisation d'entrée ou de sortie séparée avec une priorité plus élevée et spécifiant l'adresse IP de l'exception en tant que source ou destination.

  • Liste de refus sélective: supposons que vous ayez une règle de pare-feu d'entrée ou de sortie qui autorise les paquets depuis ou vers une liste Google Threat Intelligence. Pour refuser des paquets depuis ou vers une adresse IP spécifique dans cette liste Google Threat Intelligence, créez une règle de pare-feu de refus d'entrée ou de sortie avec une priorité plus élevée et spécifiant l'adresse IP de l'exception en tant que source ou destination.

Groupes d'adresses pour les stratégies de pare-feu

Les groupes d'adresses constituent une collection logique de plages d'adresses IPv4 ou de plages d'adresses IPv6 au format CIDR. Vous pouvez utiliser des groupes d'adresses pour définir des sources ou des destinations cohérentes référencées par de nombreuses règles de pare-feu. Les groupes d'adresses peuvent être mis à jour sans modifier les règles de pare-feu qui les utilisent. Pour en savoir plus sur les groupes d'adresses, consultez la section Groupes d'adresses pour les stratégies de pare-feu.

Vous pouvez définir des groupes d'adresses sources et de destination pour les règles de pare-feu d'entrée et de sortie, respectivement.

Pour en savoir plus sur le fonctionnement des groupes d'adresses sources avec d'autres filtres sources dans les règles d'entrée, consultez les sections Sources des règles d'entrée dans les stratégies de pare-feu hiérarchiques et Sources des règles d'entrée dans les stratégies de pare-feu réseau.

Pour en savoir plus sur le fonctionnement des groupes d'adresses de destination avec d'autres filtres de destination dans les règles de sortie, consultez la section Destinations pour les règles de sortie.

Objets de nom de domaine complet

Utilisez des objets de nom de domaine complet dans les règles de stratégie de pare-feu pour filtrer le trafic entrant ou sortant de domaines spécifiques.

Vous pouvez appliquer des règles de stratégie de pare-feu qui utilisent des objets de nom de domaine complet à la fois au trafic entrant et au trafic sortant. Selon la direction du trafic, les adresses IP associées aux noms de domaine sont mises en correspondance avec la source ou la destination du trafic.

  • Vous pouvez configurer des objets de nom de domaine complet pour les stratégies de pare-feu hiérarchiques, les stratégies de pare-feu réseau globales et les stratégies de pare-feu réseau régionales.

  • Vous devez spécifier les objets de nom de domaine complet dans la syntaxe de nom de domaine complet standard.

    Pour en savoir plus sur les formats de nom de domaine, consultez la section Format de nom de domaine.

  • À intervalles réguliers, Cloud NGFW met à jour les règles de stratégie de pare-feu qui contiennent des objets FQDN en incluant les derniers résultats de résolution de noms de domaine.

  • Les noms de domaine spécifiés dans les règles de stratégie de pare-feu sont résolus en adresses IP en fonction de l'ordre de résolution des noms VPC de Cloud DNS. Cloud DNS informe le pare-feu Cloud NGFW en cas de changement des résultats de résolution de nom de domaine, également appelés enregistrements DNS (système de noms de domaine).

  • Si deux noms de domaine résolvent la même adresse IP, la règle de stratégie de pare-feu s'applique à cette adresse IP, et pas seulement à un domaine. En d'autres termes, les objets de nom de domaine complet sont des entités de couche 3.

  • Si l'objet de nom de domaine complet de la règle de stratégie de pare-feu de sortie inclut un domaine contenant des CNAME dans l'enregistrement DNS, vous devez configurer votre règle de stratégie de pare-feu de sortie avec tous les noms de domaine que vos VM peuvent interroger, y compris tous les alias potentiels, pour garantir un comportement fiable des règles de pare-feu. Si vos VM interrogent des CNAME qui ne sont pas configurés dans la règle de stratégie de pare-feu de sortie, celle-ci peut ne pas fonctionner lors de la modification des enregistrements DNS.

  • Vous pouvez également utiliser des noms DNS internes Compute Engine dans vos règles de stratégie de pare-feu réseau. Assurez-vous toutefois que votre réseau n'est pas configuré pour utiliser un autre serveur de noms dans la règle de serveur sortant.

  • Si vous souhaitez ajouter des noms de domaine personnalisés dans vos règles de stratégie de pare-feu réseau, vous pouvez utiliser les zones gérées Cloud DNS pour la résolution de nom de domaine. Assurez-vous toutefois que votre réseau n'est pas configuré pour utiliser un autre serveur de noms dans la règle de serveur sortant. Pour en savoir plus sur la gestion des zones, consultez la page Créer, modifier et supprimer des zones.

Limites

Les limites suivantes s'appliquent aux règles de pare-feu d'entrée et de sortie qui utilisent des objets de nom de domaine complet :

  • Les objets de nom de domaine complet ne sont pas compatibles avec les caractères génériques (*) et les noms de domaine de premier niveau (racine). Par exemple, *.example.com. et .org ne sont pas compatibles.

Vous pouvez utiliser des objets de nom de domaine complet dans les règles de stratégie de pare-feu d'entrée. Vous devez prendre en compte les limites suivantes lorsque vous définissez des objets de nom de domaine complet pour les règles d'entrée :

  • Un nom de domaine peut résoudre jusqu'à 32 adresses IPv4 et 32 adresses IPv6. Les requêtes DNS qui résolvent plus de 32 adresses IPv4 et 32 adresses IPv6 sont tronquées pour n'inclure que 32 adresses IPv4 ou IPv6 de ces adresses IP résolues. Par conséquent, n'incluez pas de noms de domaine qui résolvent plus de 32 adresses IPv4 et IPv6 dans les règles de stratégie de pare-feu d'entrée.

  • Certaines requêtes de nom de domaine présentent des réponses uniques en fonction de l'emplacement du client à l'origine de la requête. L'emplacement à partir duquel la résolution DNS de la règle de stratégie de pare-feu est effectuée correspond à la région Google Cloud qui contient la VM à laquelle la règle de stratégie de pare-feu s'applique.

  • N'utilisez pas de règles d'entrée qui utilisent des objets de nom de domaine complet si les résultats de résolution de nom de domaine sont très variables ou si la résolution de nom de domaine utilise une forme d'équilibrage de charge basée sur DNS. Par exemple, de nombreux noms de domaine Google utilisent un schéma d'équilibrage de charge basé sur DNS.

Vous pouvez utiliser des objets de nom de domaine complet dans les règles de stratégie de pare-feu sortant, mais nous vous déconseillons d'utiliser des objets de nom de domaine complet avec des enregistrements A DNS dont la valeur TTL (time-to-live) est inférieure à 90 secondes.

Utiliser des objets de nom de domaine complet avec d'autres filtres de règles de stratégie de pare-feu

Dans une règle de stratégie de pare-feu, vous pouvez définir des objets de nom de domaine complet avec d'autres filtres sources ou de destination.

Pour en savoir plus sur le fonctionnement des objets de nom de domaine complet avec d'autres filtres sources dans les règles d'entrée, consultez les sections Sources des règles d'entrée dans les stratégies de pare-feu hiérarchiques et Sources des règles d'entrée dans les stratégies de pare-feu réseau.

Pour en savoir plus sur le fonctionnement des objets de nom de domaine complet avec d'autres filtres de destination dans les règles de sortie, consultez la section Destinations pour les règles de sortie.

Format de nom de domaine

Les pare-feu VPC sont compatibles avec le format de nom de domaine tel que défini dans les normes RFC 1035, RFC 1123 et RFC 4343.

Pour ajouter des noms de domaine aux règles de stratégie de pare-feu, suivez les consignes de mise en forme suivantes :

  • Le nom de domaine doit contenir au moins deux libellés décrits comme suit :

    • Chaque libellé correspond à des expressions régulières ne comprenant que les caractères suivants : [a-z]([-a-z0-9][a-z0-9])?..
    • Chaque libellé comporte entre 1 et 63 caractères.
    • Les libellés sont concaténés avec un point (.).

  • La longueur maximale encodée du nom de domaine ne doit pas dépasser 255 octets.

  • Vous pouvez également ajouter un nom de domaine internationalisé (IDN, Internationalized Domain Name) aux règles de stratégie de pare-feu.

  • Les noms de domaine doivent être au format Unicode ou Punycode.

  • Si vous spécifiez un IDN au format Unicode, le pare-feu Google Cloud le convertit au format Punycode avant de le traiter. Vous pouvez également utiliser l'outil de conversion IDN pour obtenir une représentation Punycode de l'IDN.

  • Le pare-feu Google Cloud n'accepte pas les noms de domaine équivalents dans la même règle de stratégie de pare-feu. Après avoir converti le nom de domaine en Punycode, si les deux noms de domaine diffèrent au maximum par un point final, ils sont considérés comme équivalents.

Scénarios d'exceptions pour le nom de domaine complet

Lorsque vous utilisez des objets de nom de domaine complet dans les règles de stratégie de pare-feu, vous pouvez rencontrer les exceptions suivantes lors de la résolution de nom DNS :

  • Nom de domaine incorrect : si vous spécifiez un ou plusieurs noms de domaine qui utilisent un format non valide lors de la création d'une règle de stratégie de pare-feu, vous obtenez une erreur. La règle de stratégie de pare-feu ne peut être créée que si tous les noms de domaine sont correctement formatés.

  • Le nom de domaine n'existe pas (NXDOMAIN) : si le nom de domaine n'existe pas, Google Cloud ignore l'objet de nom de domaine complet de la règle de stratégie de pare-feu.

  • Aucune résolution d'adresse IP : si le nom de domaine ne correspond à aucune adresse IP, l'objet de nom de domaine complet est ignoré.

  • Le serveur Cloud DNS n'est pas accessible : si un serveur DNS n'est pas accessible, les règles de stratégie de pare-feu qui utilisent des objets de nom de domaine complet ne s'appliquent que si les résultats de résolution DNS précédemment mis en cache sont disponibles. Les objets de nom de domaine complet de la règle sont ignorés s'il n'y a pas de résultats de résolution DNS mis en cache ou si les résultats DNS mis en cache ont expiré.

Étapes suivantes