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 Trusted Cloud by S3NS . 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. Trusted 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.

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 et deny. 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 balise sécurisées à partir d'une clé de balise 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.
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 comme 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 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 de source 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.
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 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 spoke VPC 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 prochain saut, 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 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éseaux 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 .

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 .

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-feuTrusted 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.

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 acceptées.

  • Les objets de nom de domaine complet ne sont pas compatibles avec Cloud DNS DNS64. Si vous activez DNS64 avec un nom de domaine complet, les VM ne recevront pas d'adresses IPv6 traduites par NAT.

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 Trusted 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 de sortie, mais nous vous déconseillons d'utiliser des objets de nom de domaine complet avec des enregistrements DNS A dont le TTL (time-to-live) est inférieur à 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) 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 Trusted 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 d'un IDN.

  • Le pare-feu Trusted 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, Trusted 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