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

Paramètre d'action Description
allow

Autorise les paquets pour une nouvelle connexion. Arrête l'évaluation des règles dans la stratégie de pare-feu qui contient la règle correspondante. N'évalue aucune autre règle de pare-feu.

Quel que soit le sens de la règle, si le protocole de paquet et le type de stratégie de pare-feu sont compatibles avec le suivi des connexions, une règle d'autorisation crée une entrée de table de suivi des connexions de pare-feu qui autorise les paquets entrants et sortants.
deny

Interdit les paquets pour une nouvelle connexion. Arrête l'évaluation des règles dans la stratégie de pare-feu contenant la règle correspondante. N'évalue aucune autre règle de pare-feu.

Cloud NGFW recherche toujours une entrée dans le tableau de suivi des connexions de pare-feu avant d'évaluer les règles de pare-feu. Par conséquent, si une règle d'autorisation a créé une entrée dans la table de suivi des connexions, cette entrée est prioritaire.
apply_security_profile_group

Intercepte les paquets pour une nouvelle connexion et les envoie à un point de terminaison de pare-feu ou à un groupe de points de terminaison d'interception. Arrête l'évaluation des règles dans la stratégie de pare-feu qui contient la règle correspondante. N'évalue aucune autre règle de pare-feu.

Quel que soit le sens de la règle, si le protocole de paquet et le type de stratégie de pare-feu sont compatibles avec le suivi des connexions, une règle avec l'action apply_security_profile_group crée une entrée de table de suivi des connexions de pare-feu afin que les paquets entrants et sortants soient interceptés par le point de terminaison du pare-feu ou le groupe de points de terminaison d'interception.

Vous ne pouvez pas créer de règles avec l'action apply_security_profile_group dans les stratégies de pare-feu réseau régionales.
goto_next

Arrête l'évaluation des autres règles de la stratégie de pare-feu et évalue les règles de l'étape suivante de l' ordre d'évaluation des stratégies et des règles de pare-feu.

L'étape suivante de l'ordre d'évaluation des règles et des stratégies de pare-feu peut être l'évaluation des règles d'une autre stratégie de pare-feu ou des règles de pare-feu implicites.

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

Toutes les règles de pare-feu d'entrée et de sortie comportent une cible. La cible identifie les interfaces réseau des instances Compute Engine (y compris les nœuds Google Kubernetes Engine et les instances de l'environnement flexible App Engine) auxquelles la règle de pare-feu s'applique.

Chaque règle de pare-feu possède une cible la plus large, que vous pouvez affiner en spécifiant un paramètre cible ou une combinaison de paramètres cibles. Si vous ne spécifiez aucun paramètre cible ni aucune combinaison de paramètres cibles, la règle de pare-feu s'applique à la cible la plus large.

  • Cible la plus large pour les règles des stratégies de pare-feu hiérarchiques : toutes les interfaces réseau de VM d'un sous-réseau dans n'importe quelle région de n'importe quel réseau VPC situé dans un projet sous le nœud Resource Manager (dossier ou organisation) associé à la stratégie de pare-feu hiérarchique.

  • Cible la plus large pour les règles des stratégies de pare-feu de réseau au niveau mondial : toutes les interfaces réseau de VM d'un sous-réseau dans n'importe quelle région du réseau VPC associé à la stratégie de pare-feu de réseau au niveau mondial.

  • Cible la plus large pour les règles des stratégies de pare-feu réseau régionales : toutes les interfaces réseau de VM d'un sous-réseau de la région et le réseau VPC associé à la stratégie de pare-feu réseau régionale.

Le tableau suivant répertorie les paramètres et combinaisons de cibles valides que vous pouvez utiliser pour affiner la cible d'une règle de pare-feu :

Paramètre de cible Compatibilité avec les stratégies de pare-feu hiérarchiques Compatibilité avec les stratégies de pare-feu réseau mondiales et régionales
Cibler les ressources du réseau VPC

Liste d'un ou plusieurs réseaux VPC spécifiés à l'aide du paramètre target-resources. Cette liste réduit la cible la plus large de la règle de pare-feu aux interfaces réseau de VM qui se trouvent dans au moins l'un des réseaux VPC spécifiés.
Comptes de service cibles

Liste d'un ou plusieurs comptes de service spécifiés à l'aide du paramètre target-service-accounts. Cette liste limite la cible la plus large de la règle de pare-feu aux interfaces réseau de VM appartenant à des instances de VM associées à au moins l'un des comptes de service spécifiés.
Combinaison de comptes de service cibles et de ressources de réseau VPC cibles

Combinaison utilisant à la fois les paramètres target-service-accounts et target-resources dans la même règle. Cette combinaison limite la cible la plus large de la règle de pare-feu aux interfaces réseau de VM qui répondent aux deux critères suivants :

  • Interfaces qui se trouvent dans au moins l'un des réseaux VPC spécifiés
  • Interfaces appartenant à des instances de VM associées à au moins l'un des comptes de service spécifiés
Cibler les valeurs de tag sécurisées à partir d'une clé de tag avec des données sur l'objectif du réseau

Liste d'une ou de plusieurs valeurs de tag provenant d'une clé de tag dont les données d'objectif spécifient un seul réseau VPC. Cette liste réduit la cible la plus large de la règle de pare-feu aux interfaces réseau de VM qui se trouvent dans le réseau VPC spécifié dans les données d'objectif. Pour en savoir plus, consultez Tags sécurisés pour les pare-feu.
Cibler les valeurs de tags sécurisés à partir d'une clé de tag avec des données sur l'objectif de l'organisation

Liste d'une ou de plusieurs valeurs de balise à partir d'une clé de balise dont les données d'objectif sont organization=auto. Cela réduit la cible la plus large de la règle de pare-feu aux interfaces réseau de VM qui se trouvent dans n'importe quel réseau VPC de l'organisation. Pour en savoir plus, consultez Tags sécurisés pour les pare-feu.

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 sources qui peuvent être utilisés individuellement ou combinés dans une même règle de stratégie de pare-feu d'entrée. Cloud NGFW exige que vous spécifiiez au moins un paramètre de source.

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

Liste simple 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 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 façon dont les noms de domaine sont convertis en adresses IP, consultez Objets de nom de domaine complet.
Récupérer les valeurs de tag sécurisées à partir d'une clé de tag avec des données sur l'objectif du réseau

Liste d'une ou de plusieurs valeurs de tag provenant d'une clé de tag dont les données d'objectif spécifient un seul réseau VPC. Pour en savoir plus, consultez Tags sécurisés pour les pare-feu et Comment les tags sécurisés sources impliquent des sources de paquets.
Obtenir les valeurs de tags sécurisés à partir d'une clé de tag avec des données sur l'objectif de l'organisation

Liste d'une ou de plusieurs valeurs de balise à partir d'une clé de balise dont les données d'objectif sont organization=auto. Pour en savoir plus, consultez Tags sécurisés pour les pare-feu et 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 Objets de géolocalisation.
Listes Google Threat Intelligence sources

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

Contrainte qui définit une limite de sécurité. Pour en savoir plus, consultez Types de réseaux.

Dans une seule règle d'entrée, vous pouvez utiliser au moins deux paramètres sources pour créer 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 sources doivent contenir des CIDR IPv4 ou IPv6, mais pas les deux.
  • Un groupe d'adresses sources contenant des CIDR IPv4 ne peut pas être utilisé avec un groupe d'adresses sources contenant des CIDR IPv6.
  • Une plage d'adresses IP sources contenant des CIDR IPv4 ne peut pas être utilisée avec un groupe d'adresses sources contenant des CIDR IPv6.
  • Une plage d'adresses IP sources contenant des CIDR IPv6 ne peut pas être utilisée avec un groupe d'adresses sources contenant des CIDR IPv4.
  • Le type de réseau Internet ne peut pas être utilisé avec les tags sécurisés sources.
  • Les types "hors Internet", "réseaux VPC" et "inter-VPC" ne peuvent pas être utilisés avec les listes Google Threat Intelligence de la source ni avec les géolocalisations de la source .

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 type 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 type de réseau source, les paquets correspondent à la règle d'entrée s'ils correspondent au type de réseau source et à au moins l'un des autres paramètres sources de la combinaison de sources.

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

Les règles d'Ingress dans les stratégies de pare-feu peuvent spécifier des sources à l'aide de tags sources sécurisés (valeurs de tag). Les valeurs de tag sécurisé identifient les interfaces réseau, et non les caractéristiques des paquets, comme les adresses IP.

Les paquets envoyés à partir d'une interface réseau d'une instance de VM correspondent à une règle d'entrée qui utilise une valeur de tag sécurisé source selon les règles suivantes :

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

  • L'instance de VM doit être associée à la même valeur de tag sécurisé que celle utilisée comme tag sécurisé source dans une règle de pare-feu d'entrée.

  • La valeur du tag sécurisé associée à l'instance de VM et utilisée par la règle de pare-feu d'entrée doit provenir d'une clé de tag dont l'attribut purpose-data identifie au moins un réseau VPC contenant une interface réseau de l'instance de VM :

    • Si les données d'objectif de la clé de tag spécifient un seul réseau VPC, les règles de pare-feu d'entrée qui utilisent la valeur du tag sécurisé source s'appliquent aux interfaces réseau de l'instance de VM qui se trouvent dans ce réseau VPC.

    • Si les données d'objectif de la clé de tag spécifient l'organisation, les règles de pare-feu d'entrée qui utilisent la valeur de tag sécurisé source s'appliquent aux interfaces réseau de l'instance de VM qui se trouvent dans n'importe quel réseau VPC de l'organisation.

  • L'interface réseau de la VM identifiée doit répondre à l'un des critères suivants :

    • L'interface réseau de la VM se trouve dans le même réseau VPC que celui auquel la stratégie de pare-feu 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 la stratégie de pare-feu s'applique.

Pour en savoir plus sur les tags sécurisés pour les pare-feu, consultez Spécifications.

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 section Cibles 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 qui peuvent être utilisés individuellement ou combinés dans une même règle de stratégie de pare-feu de sortie. Cloud NGFW exige que vous spécifiiez au moins un paramètre de destination.

Paramètre de destination des règles de sortie Compatibilité avec les stratégies de pare-feu hiérarchiques Compatibilité avec les stratégies de pare-feu réseau mondiales et régionales
Plages d'adresses IP de destination

Liste simple 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 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 façon dont les noms de domaine sont convertis en adresses IP, consultez Objets de nom de domaine complet.
Géolocalisations 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 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 Google Threat Intelligence pour les règles de stratégie de pare-feu.
Type de réseau de destination

Contrainte qui définit une limite de sécurité. Pour en savoir plus, consultez Types de réseaux.

Dans une même règle de sortie, vous pouvez utiliser au moins deux paramètres de destination pour créer 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, mais pas 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 le type de réseau de destination non 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 type de réseau de destination, les paquets correspondent à la règle de sortie s'ils correspondent à au moins un paramètre de destination dans la combinaison de destinations.

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

Types de réseaux

Les types de réseau vous aident à atteindre vos objectifs de sécurité en utilisant moins de règles de stratégie de pare-feu de manière plus efficace. Cloud NGFW est compatible avec quatre types de réseaux qui peuvent être utilisés pour créer une combinaison de sources ou de destinations 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.

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

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

Les types de réseau Internet et non Internet s'excluent mutuellement. Les types de réseaux VPC et intra-VPC sont des sous-ensembles du type de réseau non Internet.

Type de réseau Internet

Le type de réseau internet (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 type 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 sources et correspondent au paramètre source de type Internet.

  • Pour une règle de sortie, spécifiez la destination de type "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 correspondent au paramètre de destination de type Internet.

Le reste de cette section décrit les critères utilisés par Cloud NGFW pour déterminer si un paquet appartient au type de réseau Internet.

Type de réseau Internet pour les paquets entrants

Les paquets d'Ingress acheminés vers une interface réseau de VM par un Maglev Google sont considérés comme appartenant au type de réseau Internet. Un Maglev achemine les paquets 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.
  • Adresse IPv6 externe régionale d'une interface réseau de VM, d'une règle de transfert d'un équilibreur de charge réseau passthrough externe ou d'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 de réseaux VPC ou à partir d'un VPC spoke sur un hub Network Connectivity Center.

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

Type de réseau 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 appartenant au type de réseau Internet. Toutefois, si l'adresse IP de destination de ces paquets sortants concerne les API et services Google, ces paquets sont considérés comme appartenant au type de réseau "non Internet". Pour en savoir plus sur la connectivité aux API et services Google, consultez Type de réseau sans accès à Internet.

Lorsque les paquets sont acheminés à l'aide d'une route statique qui utilise la passerelle Internet par défaut comme saut suivant, tous les paquets envoyés par les interfaces réseau de la VM vers les destinations suivantes sont considérés comme appartenant au type "Internet" :

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

Les paquets envoyés par les interfaces réseau de VM aux passerelles Cloud VPN et Cloud NAT sont considérés comme appartenant au type Internet :

  • Les paquets sortants 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 appartenant au type Internet.
  • Les paquets de sortie envoyés d'une passerelle Cloud VPN à une autre ne sont considérés comme appartenant à aucun type de 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 vers l'adresse IPv4 externe régionale d'une passerelle Cloud NAT sont considérés comme appartenant au type "Internet".

Si des réseaux VPC sont connectés à l'aide de l'appairage de réseaux VPC ou s'ils 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 sont plutôt de type réseau non Internet.

Type de réseau non Internet

Le type de réseau non 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 type non Internet et au moins un autre paramètre de source, à l'exception d'une source de liste Threat Intelligence ou d'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 sources et correspondent au paramètre source de type non Internet.

  • Pour une règle de sortie, spécifiez une destination de type non 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 type non Internet.

Le reste de cette section décrit les critères utilisés par Cloud NGFW pour déterminer si un paquet appartient au type de réseau non Internet.

Type de réseau non Internet pour les paquets entrants

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 des API et services Google sont considérés comme appartenant au type de réseau non 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 :

Type de réseau non Internet pour les paquets de sortie

Les paquets sortants 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 appartenant au type de réseau non 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 :

Type de réseau VPC

Le type de réseau VPC (VPC_NETWORKS) ne peut être utilisé que dans une combinaison de sources d'une règle d'entrée. Vous ne pouvez pas utiliser le type de réseaux VPC dans une combinaison de destinations d'une règle de sortie.

Pour utiliser le type de réseaux VPC dans 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 que vous puissiez l'ajouter à la liste des réseaux sources.
    • Vous pouvez ajouter le réseau en utilisant 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. Cloud NGFW ignore les réseaux VPC supprimés lorsqu'il applique 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 le type de réseaux 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 l'un des réseaux VPC sources.

  • Le réseau VPC source et le réseau VPC auquel s'applique la stratégie de pare-feu contenant la règle d'entrée 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

Type de réseau intra-VPC

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

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

Un paquet correspond à une règle d'entrée qui utilise le type 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 s'applique la stratégie de pare-feu contenant la règle d'entrée.

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

  • Règle de pare-feu 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.

  • Règle de pare-feu de refus sélectif : 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

Les objets de nom de domaine complet (FQDN) contiennent les noms de domaine que vous spécifiez au format de nom de domaine. Vous pouvez utiliser des objets de nom de domaine complet comme sources pour les règles d'entrée ou comme destinations pour les règles de sortie dans une stratégie de pare-feu hiérarchique, une stratégie de pare-feu réseau globale ou une stratégie de pare-feu réseau régionale.

Vous pouvez combiner les FQDN avec d'autres paramètres. Pour en savoir plus sur les combinaisons de paramètres sources dans les règles d'entrée, consultez Sources pour les règles d'entrée. Pour en savoir plus sur les combinaisons de paramètres de destination dans les règles de sortie, consultez Destinations pour les règles de sortie.

Les objets FQDN sont compatibles avec les règles de réponse Cloud DNS, les zones privées gérées à portée de réseau VPC, les noms DNS internes Compute Engine et les zones DNS publiques. Cette prise en charge s'applique tant que le réseau VPC ne dispose pas d'une règle de serveur sortant spécifiant un serveur de noms alternatif. Pour en savoir plus, consultez Ordre de résolution des réseaux VPC.

Mapper des objets de nom de domaine complet à des adresses IP

Cloud NGFW résout régulièrement les objets de nom de domaine complet en adresses IP. Cloud NGFW suit l'ordre de résolution des noms VPC de Cloud DNS dans le réseau VPC contenant les cibles de la règle de pare-feu.

Cloud NGFW utilise le comportement suivant pour la résolution des adresses IP :

  • Prise en charge de la résolution d'enregistrements CNAME : Cloud NGFW utilise la résolution d'enregistrements CNAME Cloud DNS si la réponse à une requête d'objet FQDN est un enregistrement CNAME.

  • Adresses IP du programme Cloud NGFW utilise les adresses IP résolues lorsqu'il programme les règles de pare-feu qui utilisent des objets de nom de domaine complet. Chaque objet FQDN peut être mappé à un maximum de 32 adresses IPv4 et 32 adresses IPv6.

    Si la réponse DNS à une requête d'objet de nom de domaine complet résout plus de 32 adresses IPv4 ou plus de 32 adresses IPv6, Cloud NGFW limite les adresses IP programmées dans les règles de pare-feu aux 32 premières adresses IPv4 et aux 32 premières adresses IPv6.

  • Ignorer les objets de nom de domaine complet : Si Cloud NGFW ne parvient pas à résoudre un objet de nom de domaine complet en adresse IP, il l'ignore. Dans les situations suivantes, Cloud NGFW ignore un objet de nom de domaine complet :

    • Lorsque NXDOMAIN réponses ont été reçues. Les réponses NXDOMAIN sont des réponses explicites d'un serveur de noms indiquant qu'aucun enregistrement DNS pour la requête d'objet de nom de domaine complet n'existe.

    • Lorsqu'aucune adresse IP n'existe dans une réponse. Dans ce cas, une requête d'objet de nom de domaine complet ne génère pas de réponse avec une adresse IP que Cloud NGFW peut utiliser pour programmer une règle de pare-feu.

    • Lorsque le serveur Cloud DNS est inaccessible. Cloud NGFW ignore les objets de nom de domaine complet si un serveur DNS qui fournit la réponse est inaccessible.

    Lorsqu'un objet de nom de domaine complet est ignoré, Cloud NGFW programme les parties restantes d'une règle de pare-feu, si possible.

Éléments à prendre en compte pour les objets FQDN

Tenez compte des éléments suivants pour les objets de nom de domaine complet :

  1. Étant donné que les objets FQDN sont mappés et programmés en tant qu'adresses IP, Cloud NGFW se comporte comme suit lorsque deux objets FQDN ou plus sont mappés sur la même adresse IP. Supposons que vous disposiez des deux règles de pare-feu suivantes qui s'appliquent à la même cible :

    • Règle 1 : priorité 100, trafic entrant autorisé depuis le nom de domaine complet source example1.com
    • Règle 2 : priorité 200, trafic entrant autorisé depuis le nom de domaine complet source example2.com

    Si example1.com et example2.com sont résolues en la même adresse IP, les paquets entrants de example1.com et example2.com correspondent à la première règle de pare-feu, car celle-ci a une priorité plus élevée.

  2. Voici quelques points à prendre en compte lorsque vous utilisez des objets de nom de domaine complet :

    • Une requête DNS peut présenter des réponses uniques en fonction de l'emplacement du client à l'origine de la requête.

    • Les réponses DNS peuvent être très variables lorsqu'un système d'équilibrage de charge basé sur DNS est impliqué.

    • Une réponse DNS peut contenir plus de 32 adresses IPv4.

    • Une réponse DNS peut contenir plus de 32 adresses IPv6.

    Dans les situations précédentes, étant donné que Cloud NGFW effectue des requêtes DNS dans chaque région contenant l'interface réseau de la VM à laquelle la règle de pare-feu s'applique, les adresses IP programmées dans les règles de pare-feu ne contiennent pas toutes les adresses IP possibles associées au nom de domaine complet.

    La plupart des noms de domaine Google, tels que googleapis.com, sont soumis à une ou plusieurs de ces situations. Utilisez plutôt des adresses IP ou des groupes d'adresses.

  3. N'utilisez pas d'objets de nom de domaine complet avec Cloud DNS DNS64. Cloud NGFW ne programme pas les adresses IPv6 Well-Known Prefix (WKP) utilisées par DNS64.

    DNS64 et NAT64 sont conçus pour être utilisés ensemble afin de permettre la connectivité aux serveurs IPv4 uniquement à partir de clients de VM IPv6 uniquement. Pour fournir cette connectivité, un fournisseur DNS64 synthétise une réponse AAAA à une requête DNS pour laquelle aucun enregistrement AAAA n'existe. La réponse AAAA synthétisée encode l'adresse IPv4 du serveur dans les quatre derniers octets d'une adresse IPv6 WKP (64:ff9b::/96). Lorsque le client IPv6 uniquement envoie des paquets à l'adresse IPv6 WKP, un fournisseur NAT64 extrait l'adresse IPv4 du serveur de l'adresse IPv6 WKP et ouvre une connexion IPv4 au serveur IPv4 uniquement.

    Lorsque DNS64 est impliqué, nous vous recommandons d'utiliser des adresses IP ou des groupes d'adresses dans les règles de pare-feu. Assurez-vous d'inclure l'adresse IPv4 du serveur et sa représentation IPv6 WKP.

  4. Évitez 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.

Mettre en forme les noms de domaine

Les objets de nom de domaine complet doivent respecter le format standard de nom de domaine complet.Ce format est défini dans les normes RFC 1035, RFC 1123 et RFC 4343. Cloud NGFW rejette les objets FQDN qui incluent un nom de domaine ne respectant pas toutes les règles de mise en forme suivantes :

  • Chaque objet FQDN doit être un nom de domaine comportant au moins deux libellés :

    • Chaque libellé doit correspondre à une expression régulière ne comprenant que les caractères suivants : [a-z]([-a-z0-9][a-z0-9])?..
    • Chaque libellé doit comporter entre 1 et 63 caractères.
    • Les libellés doivent être concaténés avec un point (.).

    Par conséquent, les objets de nom de domaine complet ne sont pas compatibles avec les caractères génériques (*) ni les noms de domaine de premier niveau (ou racine), tels que *.example.com. et .org, car ils ne comportent qu'un seul libellé.

  • Les objets de nom de domaine complet sont compatibles avec les noms de domaine internationalisés (IDN). Vous pouvez fournir un IDN au format Unicode ou Punycode. Réfléchissez aux éléments suivants :

    • Si vous spécifiez un IDN au format Unicode, Cloud NGFW le convertit au format Punycode avant de le traiter.

    • Vous pouvez utiliser le convertisseur IDN pour créer la représentation Punycode d'un IDN.

    • Le nombre maximal de caractères (1 à 63 par libellé) s'applique aux IDN après conversion au format Punycode.

  • La longueur encodée d'un nom de domaine complet (FQDN) ne peut pas dépasser 255 octets.

Cloud NGFW n'accepte pas les noms de domaine équivalents dans la même règle de pare-feu. Par exemple, si les deux noms de domaine (ou représentations Punycode des IDN) diffèrent au maximum par un point final (.), Cloud NGFW les considère comme équivalents.

Étapes suivantes