Stratégies de pare-feu

Les stratégies de pare-feu vous permettent de regrouper plusieurs règles de pare-feu afin de pouvoir les mettre à jour en une seule fois, efficacement contrôlées par les rôles IAM (Identity and Access Management). Ces stratégies contiennent des règles qui peuvent explicitement refuser ou autoriser des connexions, tout comme les règles de pare-feu du cloud privé virtuel (VPC).

Stratégies de pare-feu hiérarchiques

Les stratégies de pare-feu hiérarchiques vous permettent de regrouper des règles dans un objet de stratégie pouvant s'appliquer à de nombreux réseaux VPC dans un ou plusieurs projets. Vous pouvez associer des stratégies de pare-feu hiérarchiques à l'ensemble d'une organisation ou à des dossiers individuels.

Pour en savoir plus sur les spécifications des stratégies de pare-feu hiérarchiques, consultez la page Stratégies de pare-feu hiérarchiques.

Stratégies de pare-feu de réseau au niveau mondial

Les stratégies de pare-feu de réseau au niveau mondial vous permettent de regrouper des règles dans un objet de stratégie applicable à toutes les régions (au niveau mondial). Une fois que vous avez associé une stratégie de pare-feu de réseau au niveau mondial à un réseau VPC, les règles de la stratégie peuvent s'appliquer aux ressources du réseau VPC.

Pour en savoir plus sur les spécifications des stratégies de pare-feu de réseau au niveau mondial, consultez la page Stratégies de pare-feu de réseau au niveau mondial.

Stratégies de pare-feu de réseau régionales

Les stratégies de pare-feu de réseau régionales vous permettent de regrouper des règles dans un objet de stratégie applicable à une région spécifique. Une fois que vous avez associé une stratégie de pare-feu de réseau régionale à un réseau VPC, les règles de la stratégie peuvent s'appliquer aux ressources de cette région du réseau VPC.

Pour en savoir plus sur les spécifications des stratégies de pare-feu régionales, consultez la page Stratégies de pare-feu de réseau régionales.

Ordre d'évaluation des stratégies et des règles

Les règles des stratégies de pare-feu hiérarchiques, des stratégies de pare-feu de réseau au niveau mondial, des stratégies de pare-feu réseau régionales et des règles de pare-feu VPC sont mises en œuvre dans le cadre du traitement des paquets de VM de la pile de virtualisation de réseau Andromeda. Les règles sont évaluées pour chaque carte d'interface réseau de la VM.

L'applicabilité d'une règle ne dépend pas de la spécificité de ses protocoles et de la configuration de ses ports. Par exemple, une règle d'autorisation de priorité plus élevée pour tous les protocoles est prioritaire sur une règle de refus de priorité inférieure spécifique au port 22 de TCP.

En outre, l'applicabilité d'une règle ne dépend pas de la spécificité du paramètre cible. Par exemple, une règle d'autorisation de priorité plus élevée pour toutes les VM (toutes les cibles) est prioritaire même si une règle de refus de priorité inférieure existe avec un paramètre cible plus spécifique. Par exemple, un compte de service ou un tag spécifique.

Déterminer l'ordre d'évaluation des stratégies et des règles

L'ordre d'évaluation des règles de stratégie de pare-feu et des règles de pare-feu VPC est déterminé par l'option networkFirewallPolicyEnforcementOrder du réseau VPC associé à la carte d'interface réseau de la VM.

L'option networkFirewallPolicyEnforcementOrder peut avoir les deux valeurs suivantes :

  • BEFORE_CLASSIC_FIREWALL: si vous définissez l'option sur BEFORE_CLASSIC_FIREWALL, les stratégies de pare-feu réseau mondiales et régionales sont évaluées avant les règles de pare-feu VPC dans l'ordre d'évaluation des règles.

  • AFTER_CLASSIC_FIREWALL : si vous définissez l'option sur AFTER_CLASSIC_FIREWALL, les stratégies de pare-feu réseau globales et régionales sont évaluées après les règles de pare-feu VPC dans l'ordre d'évaluation des règles. AFTER_CLASSIC_FIREWALL est la valeur par défaut de l'option networkFirewallPolicyEnforcementOrder.

Pour modifier l'ordre d'évaluation des règles, consultez la section Modifier l'ordre d'évaluation des stratégies et des règles.

Ordre d'évaluation des stratégies et des règles par défaut

Par défaut, et lorsque le champ networkFirewallPolicyEnforcementOrder du réseau VPC associé à la carte d'interface réseau de la VM est défini sur AFTER_CLASSIC_FIREWALL, Google Cloud évalue les règles applicables à la carte d'interface réseau de la VM dans l'ordre suivant :

  1. Si une stratégie de pare-feu hiérarchique est associée à l'organisation contenant le projet de la VM, Google Cloud évalue toutes les règles applicables dans la stratégie de pare-feu hiérarchique. Étant donné que les règles des stratégies de pare-feu hiérarchiques doivent être uniques, la règle de priorité la plus élevée qui correspond au sens du trafic et les caractéristiques de couche 4 déterminent la manière dont le trafic est traité :
    • La règle peut autoriser le trafic. Le processus d'évaluation s'arrête.
    • La règle peut refuser le trafic. Le processus d'évaluation s'arrête.
    • La règle peut envoyer le trafic pour l'inspection de couche 7 (apply_security_profile_group) vers le point de terminaison de pare-feu. La décision d'autoriser ou de supprimer le paquet dépend alors du point de terminaison de pare-feu et du profil de sécurité configuré. Dans les deux cas, le processus d'évaluation de la règle s'arrête.
    • La règle peut autoriser le traitement des règles définies comme indiqué dans les étapes suivantes si l'une des conditions suivantes est remplie :
      • Une règle ayant une action goto_next correspond au trafic.
      • Aucune règle ne correspond au trafic. Dans ce cas, une règle goto_next implicite s'applique.
  2. Si une stratégie de pare-feu hiérarchique est associée à l'ancêtre de dossier le plus distant (le plus élevé) du projet de la VM, Google Cloud évalue toutes les règles applicables dans la stratégie de pare-feu hiérarchique de ce dossier. Étant donné que les règles des stratégies de pare-feu hiérarchiques doivent être uniques, la règle de priorité la plus élevée qui correspond au sens du trafic et les caractéristiques de couche 4 déterminent la manière dont le trafic est traité : allow, deny, apply_security_profile_group ou goto_next, comme décrit à la première étape.
  3. Google Cloud répète les actions de l'étape précédente pour une stratégie de pare-feu hiérarchique associée au dossier suivant le plus proche du projet de la VM dans la hiérarchie des ressources. Google Cloud évalue d'abord les règles des stratégies de pare-feu hiérarchiques associées à l'ancêtre de dossier le plus distant (le plus proche de l'organisation), puis évalue les règles des stratégies de pare-feu hiérarchiques associées au dossier suivant (enfant) le plus proche du projet de la VM.

  4. Si des règles de pare-feu VPC existent dans le réseau VPC utilisé par la carte d'interface réseau de la VM, Google Cloud évalue toutes les règles de pare-feu VPC applicables.

    Contrairement aux règles des stratégies de pare-feu :

    • Les règles de pare-feu VPC n'ont pas d'action explicite goto_next ou apply_security_profile_group. Une règle de pare-feu VPC ne peut être configurée que pour autoriser ou refuser le trafic.

    • Deux règles de pare-feu VPC ou plus dans un réseau VPC peuvent partager le même numéro de priorité. Dans ce cas, les règles de refus prévalent sur les règles d'autorisation. Pour plus d'informations sur la priorité des règles de pare-feu VPC, consultez la section Priorité dans la documentation sur les règles de pare-feu VPC.

    Si aucune règle de pare-feu VPC ne s'applique au trafic, Google Cloud passe à l'étape suivante, avec la règle goto_next implicite.

  5. Si une stratégie de pare-feu de réseau au niveau mondial est associée au réseau VPC de la carte d'interface réseau de la VM, Google Cloud évalue toutes les règles applicables dans la stratégie de pare-feu. Étant donné que les règles des stratégies de pare-feu doivent être uniques, la règle de priorité la plus élevée qui correspond au sens du trafic et les caractéristiques de couche 4 déterminent la manière dont le trafic est traité : allow, deny, apply_security_profile_group ou goto_next, comme décrit à la première étape.

  6. Si une stratégie de pare-feu de réseau régionale est associée au réseau VPC de la carte d'interface réseau et à la région de la VM, Google Cloud évalue toutes les règles applicables dans la stratégie de pare-feu. Étant donné que les règles des stratégies de pare-feu doivent être uniques, la règle de priorité la plus élevée qui correspond au sens du trafic et les caractéristiques de couche 4 déterminent la manière dont le trafic est traité : allow, deny ou goto_next, comme décrit à la première étape.

  7. Enfin, Google Cloud applique les règles de pare-feu implicites de sortie autorisée et de refus de trafic VPC d'entrée.

Le schéma suivant illustre le flux de résolution pour les règles de pare-feu.

Flux de résolution des règles de pare-feu.
Figure 1. Flux de résolution des règles de pare-feu (cliquez pour agrandir).

Modifier l'ordre d'évaluation des stratégies et des règles

Google Cloud vous permet de modifier le processus d'évaluation des règles par défaut en permutant l'ordre des règles de pare-feu VPC et des stratégies de pare-feu réseau (globales et régionales). Lorsque vous effectuez cet échange, la stratégie de pare-feu réseau au niveau mondial (étape 5) et la stratégie de pare-feu réseau régionale (étape 6) sont évaluées avant les règles de pare-feu VPC (étape 4) dans l'ordre d'évaluation des règles.

Pour modifier l'ordre d'évaluation des règles, exécutez la commande suivante pour définir l'attribut networkFirewallPolicyEnforcementOrder du réseau VPC sur BEFORE_CLASSIC_FIREWALL:

gcloud compute networks update VPC-NETWORK-NAME \
    --network-firewall-policy-enforcement-order BEFORE_CLASSIC_FIREWALL

Pour en savoir plus, consultez la section sur la méthode networks.patch.

Règles de pare-feu efficaces

Les règles des stratégies de pare-feu hiérarchiques, les règles de pare-feu VPC, et les règles des stratégies de pare-feu réseau globales et régionales contrôlent les connexions. Il peut être utile d'afficher toutes les règles de pare-feu qui affectent un réseau individuel ou une interface de VM.

Règles de pare-feu efficaces pour le réseau

Vous pouvez afficher toutes les règles de pare-feu appliquées à un réseau VPC. La liste inclut tous les types de règles suivants :

  • Règles héritées des stratégies de pare-feu hiérarchiques
  • Règles de pare-feu VPC
  • Règles appliquées à partir des stratégies de pare-feu réseau globales et régionales

Règles de pare-feu efficaces pour l'instance

Vous pouvez afficher toutes les règles de pare-feu appliquées à l'interface réseau d'une VM. La liste inclut tous les types de règles suivants :

  • Règles héritées des stratégies de pare-feu hiérarchiques
  • Règles appliquées à partir du pare-feu VPC de l'interface
  • Règles appliquées à partir des stratégies de pare-feu réseau globales et régionales

Les règles sont triées en commençant par le niveau de l'organisation pour finir par le niveau du réseau VPC. Seules les règles qui s'appliquent à l'interface de la VM s'affichent. Les règles des autres stratégies ne sont pas affichées.

Pour afficher les règles de stratégies de pare-feu efficaces dans une région, consultez la section Obtenir des stratégies de pare-feu efficaces pour un réseau.

Règles prédéfinies

Lorsque vous créez une stratégie de pare-feu hiérarchique, une stratégie de pare-feu de réseau globale ou une stratégie de pare-feu de réseau régionale, Cloud NGFW ajoute des règles prédéfinies à la stratégie. Les règles prédéfinies que Cloud NGFW ajoute à la stratégie dépendent de la manière dont vous créez la stratégie.

Si vous créez une stratégie de pare-feu à l'aide de la console Google Cloud, Cloud NGFW ajoute les règles suivantes à la nouvelle stratégie :

  1. Règles "goto-next" pour les plages IPv4 privées
  2. Règles de refus prédéfinies pour Threat Intelligence
  3. Règles de refus prédéfinies pour la géolocalisation
  4. Règles "goto-next" de priorité la plus faible possible

Si vous créez une stratégie de pare-feu à l'aide de Google Cloud CLI ou de l'API, Cloud NGFW n'ajoute que les règles "goto-next" de priorité la plus faible possible à la stratégie.

Toutes les règles prédéfinies dans une nouvelle stratégie de pare-feu utilisent intentionnellement des priorités faibles (nombres de priorité importants) pour que vous puissiez les remplacer en créant des règles avec des priorités plus élevées. Vous pouvez également personnaliser les règles prédéfinies, à l'exception des règles "goto-next" de priorité la plus faible possible.

Règles "goto-next" pour les plages IPv4 privées

  • Une règle de sortie avec les plages IPv4 de destination 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, une priorité 1000 et une action goto_next.

  • Une règle d'entrée avec les plages IPv4 sources 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, une priorité 1001 et une action goto_next.

Règles de refus prédéfinies pour Threat Intelligence

  • Une règle d'entrée avec la liste Threat Intelligence source iplist-tor-exit-nodes, une priorité 1002 et une action deny.

  • Une règle d'entrée avec la liste Threat Intelligence source iplist-known-malicious-ips, une priorité 1003 et une action deny.

  • Une règle de sortie avec la liste Threat Intelligence de destination iplist-known-malicious-ips, une priorité 1004 et une action deny.

Pour en savoir plus sur Threat Intelligence, consultez la page Threat Intelligence pour les règles de stratégie de pare-feu.

Règles de refus prédéfinies pour la géolocalisation

  • Une règle d'entrée avec des géolocalisations correspondantes sources CU, IR, KP, SY, XC et XD, une priorité 1005 et une action deny.

Pour en savoir plus sur les géolocalisations, consultez la section Objets de géolocalisation.

Règles "goto-next" de priorité la plus faible possible

Vous ne pouvez ni modifier, ni supprimer les règles suivantes :

  • Une règle de sortie avec la plage IPv6 de destination ::/0, une priorité de 2147483644 et une action goto_next.

  • Une règle d'entrée avec la plage IPv6 source ::/0, une priorité 2147483645 et une action goto_next.

  • Une règle de sortie avec la plage IPv4 de destination 0.0.0.0/0, une priorité 2147483646 et une action goto_next.

  • Une règle d'entrée avec la plage IPv4 source 0.0.0.0/0, une priorité 2147483647 et une action goto_next.

Étapes suivantes