Règles de stratégie de pare-feu

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

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

Règles d'entrée

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

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

Règles de sortie

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

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

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

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

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

Priorité

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

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

Action en cas de correspondance

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

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

Application

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

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

Protocols and ports

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

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

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

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

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

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

Journalisation

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

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

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

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

Cible, source, destination

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

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

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

Cibles

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cibles et adresses IP pour les règles de sortie

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

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

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

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

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

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

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

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

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

Sources

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

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

Sources des règles d'entrée dans les stratégies de pare-feu hiérarchiques

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

  • Plage source par défaut : lorsque vous omettez une spécification source dans une règle d'entrée, Google Cloud utilise la plage d'adresses IPv4 source par défaut 0.0.0.0/0 (toute adresse IPv4). La valeur par défaut n'inclut pas les sources IPv6.

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

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

  • Géolocalisations : liste d'un ou de plusieurs emplacements géographiques sources spécifiés sous forme de codes pays ou région à deux lettres pour filtrer le trafic entrant. Pour en savoir plus, consultez la section Objets de géolocalisation.

  • Groupes d'adresses sources : liste d'un ou de plusieurs groupes d'adresses sources constitués de CIDR IPv4 ou IPv6. Pour en savoir plus sur les groupes d'adresses, consultez la section Groupes d'adresses pour les stratégies de pare-feu.

  • Noms de domaine sources : liste d'un ou de plusieurs noms de domaine sources. Pour en savoir plus sur les noms de domaine, consultez la section Nom de domaine pour les stratégies de pare-feu.

  • Combinaison source valide : vous pouvez spécifier différentes combinaisons des sources précédentes dans les règles d'entrée. L'ensemble de sources effectif correspond à l'union de ces combinaisons.

    Lorsque vous spécifiez une combinaison de sources dans une règle d'entrée, la règle est appliquée à un paquet correspondant à au moins un des critères de paramètre source.

    Suivez ces consignes lorsque vous définissez des combinaisons sources pour une règle :

    • N'utilisez pas à la fois des plages d'adresses IPv4 sources et des plages d'adresses IPv6 sources dans la même règle.
    • N'utilisez pas de groupe d'adresses source contenant des CIDR IPv4 avec un autre groupe d'adresses source contenant des CIDR IPv6 dans la même règle.
    • N'utilisez pas de plages d'adresses IPv4 sources et un groupe d'adresses source contenant des CIDR IPv6 dans la même règle.
    • N'utilisez pas de plages d'adresses IPv6 sources et un groupe d'adresses source contenant des CIDR IPv4 dans la même règle.

Sources des règles d'entrée dans les règles de pare-feu de réseau

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

  • Plage source par défaut : lorsque vous omettez une spécification source dans une règle d'entrée, Google Cloud utilise la plage d'adresses IPv4 source par défaut 0.0.0.0/0 (toute adresse IPv4). La valeur par défaut n'inclut pas les sources IPv6.

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

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

  • Géolocalisations : liste d'un ou de plusieurs emplacements géographiques sources spécifiés sous forme de codes pays ou région à deux lettres pour filtrer le trafic entrant. Pour en savoir plus, consultez la section Objets de géolocalisation.

  • Groupes d'adresses sources : liste d'un ou de plusieurs groupes d'adresses sources constitués de CIDR IPv4 ou IPv6. Pour en savoir plus sur les groupes d'adresses, consultez la section Groupes d'adresses pour les stratégies de pare-feu.

  • Noms de domaine sources : liste d'un ou de plusieurs noms de domaine sources. Pour en savoir plus sur les noms de domaine, consultez la section Nom de domaine pour les stratégies de pare-feu.

  • Tags sécurisés sources : un ou plusieurs tags sécurisés qui identifient les interfaces réseau des instances de VM du même réseau VPC auquel la stratégie de pare-feu réseau s'applique, ou dans un réseau VPC connecté au réseau de la stratégie de pare-feu à l'aide de l'appairage de réseaux VPC. En outre, si la stratégie est une stratégie de pare-feu réseau régionale, les instances de VM doivent se trouver dans la même région que la stratégie.

  • Combinaison source valide : vous pouvez spécifier différentes combinaisons des sources précédentes dans les règles d'entrée. L'ensemble de sources effectif correspond à l'union de ces combinaisons.

    Lorsque vous spécifiez une combinaison de sources dans une règle d'entrée, la règle est appliquée à un paquet correspondant à au moins un des critères de paramètre source.

    Suivez ces consignes lorsque vous définissez des combinaisons sources pour une règle :

    • N'utilisez pas à la fois des plages d'adresses IPv4 sources et des plages d'adresses IPv6 sources dans la même règle.
    • N'utilisez pas de groupe d'adresses source contenant des CIDR IPv4 avec un autre groupe d'adresses source contenant des CIDR IPv6 dans la même règle.
    • N'utilisez pas de plages d'adresses IPv4 sources et un groupe d'adresses source contenant des CIDR IPv6 dans la même règle.
    • N'utilisez pas de plages d'adresses IPv6 sources et un groupe d'adresses source contenant des CIDR IPv4 dans la même règle.

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

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

Les règles des stratégies de pare-feu avec des tags sécurisés sont appliquées comme suit :

  • Dans une stratégie de réseau global, les règles d'entrée s'appliquent aux paquets émis depuis l'interface réseau d'une VM liée au tag, où la VM répond à l'un des critères suivants :

    • L'interface réseau de la VM utilise le même réseau VPC que la stratégie de pare-feu.
    • L'interface réseau de la VM utilise un réseau VPC connecté au réseau VPC de la stratégie de pare-feu via l'appairage de réseaux VPC.

  • Les règles d'entrée d'une stratégie de réseau régionale s'appliquent aux paquets émis depuis l'interface réseau d'une VM liée au tag, où la VM située dans la même région que la stratégie de pare-feu répond à l'un des critères suivants :

    • L'interface réseau de la VM utilise le même réseau VPC que la stratégie de pare-feu.
    • L'interface réseau de la VM utilise un réseau VPC connecté au réseau VPC de la stratégie de pare-feu via l'appairage de réseaux VPC.

Outre la spécification d'une interface réseau, les adresses IP sources suivantes sont résolues :

  • L'adresse IPv4 interne principale de cette interface réseau
  • Toutes les adresses IPv6 attribuées à cette interface réseau

Si une règle de pare-feu d'entrée contient également des plages d'adresses IP de destination, l'interface réseau liée à un tag sécurisé est résolue avec la même version IP que la plage d'adresses IP de destination.

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

Sources des règles de sortie

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

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

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

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

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

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

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

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

Destinations

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

Destinations pour les règles d'entrée

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

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

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

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

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

Destinations pour les règles de sortie

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

  • Plage de destination par défaut : lorsque vous omettez une spécification de destination dans une règle de sortie, Google Cloud utilise la plage d'adresses IPv4 de destination par défaut 0.0.0.0/0 (toute adresse IPv4). La valeur par défaut n'inclut pas les destinations IPv6.

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

  • Géolocalisations : liste d'un ou de plusieurs emplacements géographiques de destination spécifiés sous forme de codes pays ou région à deux lettres pour filtrer le trafic entrant. Pour en savoir plus, consultez la section Objets de géolocalisation.

  • Groupes d'adresses de destination : liste d'un ou de plusieurs groupes d'adresses de destination composés de CIDR IPv4 ou IPv6. Pour en savoir plus sur les groupes d'adresses, consultez la section Groupes d'adresses pour les stratégies de pare-feu.

  • Noms de domaine de destination : liste d'un ou de plusieurs noms de domaine de destination. Pour en savoir plus sur les noms de domaine, consultez la section Nom de domaine pour les stratégies de pare-feu.

  • Combinaison de destinations valide : vous pouvez spécifier différentes combinaisons des destination précédentes dans les règles d'entrée. L'ensemble de destination effectif correspond à l'union de ces combinaisons.

    Lorsque vous spécifiez une combinaison de destinations dans une règle de sortie, la règle est appliquée à un paquet correspondant à au moins un des critères de paramètre de destination.

    Suivez ces consignes lorsque vous définissez des combinaisons de destinations pour une règle :

    • N'utilisez pas à la fois des plages d'adresses IPv4 de destination et des plages d'adresses IPv6 de destination dans la même règle.
    • N'utilisez pas de groupe d'adresses de destination contenant des CIDR IPv4 avec un autre groupe d'adresses de destination contenant des CIDR IPv6 dans la même règle.
    • N'utilisez pas de plages d'adresses IPv4 de destination et un groupe d'adresses de destination qui contient des CIDR IPv6 dans la même règle.
    • N'utilisez pas de plages d'adresses IPv6 de destination et un groupe d'adresses de destination qui contient des CIDR IPv4 dans la même règle.

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 Next Generation Firewall vous permet de configurer des règles de pare-feu pour les territoires suivants, qui sont soumis à des sanctions complètes aux États-Unis :

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

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

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

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

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

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

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

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

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

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 Threat Intelligence. Les données Threat Intelligence incluent des listes d'adresses IP basées sur les catégories suivantes :

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

Les listes de données Threat Intelligence peuvent inclure des adresses IPv4, des adresses IPv6, ou les deux. Pour configurer Threat Intelligence dans vos règles de stratégie de pare-feu, utilisez les noms de listes 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 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 Threat Intelligence, procédez comme suit :

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

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

  • Vous pouvez configurer des listes 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 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 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 Threat Intelligence dans une seule règle de pare-feu.

  • Vous pouvez ajouter plusieurs listes 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 Threat Intelligence

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

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

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

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

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

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

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

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

Objets de nom de domaine complet

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

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

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

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

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

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

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

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

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

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

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

Limites

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

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

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

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

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

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

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

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

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

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

Format de nom de domaine

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Étapes suivantes