Présentation de la journalisation des règles de stratégie de pare-feu

La journalisation des règles de stratégie de pare-feu vous permet de réaliser des audits, des vérifications et des analyses sur les effets de ces règles. Par exemple, vous pouvez déterminer si une règle de stratégie de pare-feu conçue pour refuser le trafic fonctionne comme prévu. La journalisation des règles de stratégie de pare-feu est également utile si vous devez déterminer le nombre de connexions affectées par une règle de stratégie de pare-feu donnée.

Vous activez la journalisation des règles de stratégie de pare-feu individuellement pour chaque règle de stratégie de pare-feu dont vous souhaitez journaliser les connexions. Cette option est disponible pour toute règle de stratégie de pare-feu, indépendamment de l'action de la règle (allow ou deny) et de la direction du trafic visé (ingress ou egress).

La journalisation des règles de stratégie de pare-feu consigne le trafic vers et depuis les instances de machine virtuelle (VM) Compute Engine. Cela inclut les Cloud de Confiance by S3NS produits basés sur des VM Compute Engine, tels que les clusters Google Kubernetes Engine (GKE) et les instances de l'environnement flexible Google Kubernetes Engine.

Lorsque vous activez la journalisation pour une règle de stratégie de pare-feu, Cloud de Confiance by S3NS crée une entrée appelée un enregistrement de connexion chaque fois que la règle autorise ou refuse du trafic. Vous pouvez consulter ces enregistrements dans Cloud Logging, et exporter les journaux vers n'importe quelle destination compatible avec l'exportation Cloud Logging.

Chaque enregistrement de connexion contient les adresses IP source et de destination, le protocole et les ports, la date et l'heure, ainsi qu'une référence à la règle de stratégie de pare-feu appliquée au trafic.

Pour en savoir plus sur l'affichage des journaux, consultez Gérer la journalisation des règles de stratégie de pare-feu.

Spécifications

La journalisation des règles de stratégie de pare-feu obéit aux spécifications suivantes :

  • Déploiements compatibles : vous pouvez activer la journalisation des règles de stratégie de pare-feu pour les règles de stratégie de pare-feu dans les stratégies de pare-feu hiérarchiques, de réseau mondial, de réseau régional et de système régional associées à un réseau VPC standard, ainsi que pour les stratégies de pare-feu de réseau régional associées à un réseau VPC RoCE.

  • Règles non compatibles : la journalisation des règles de stratégie de pare-feu n'est pas compatible avec les règles des réseaux hérités, les règles de refus implicite du trafic entrant et d'autorisation implicite du trafic sortant dans un réseau VPC standard, ni avec les règles d'autorisation implicite du trafic entrant et sortant d'un réseau VPC RoCE.

  • Compatibilité avec les protocoles : la journalisation des règles de stratégie de pare-feu n'enregistre que les connexions TCP et UDP.

  • Journalisation basée sur les connexions : la journalisation des règles de stratégie de pare-feu est créée lorsqu'une connexion est établie, et non pour chaque paquet individuel. Une connexion reste active tant que des paquets sont échangés au moins une fois toutes les 10 minutes. Chaque nouveau paquet réinitialise le minuteur d'inactivité. Par conséquent, un flux de trafic continu ne génère qu'une seule entrée de journal pour toute sa durée. Si vous avez besoin d'une visibilité continue sur les flux actifs, de longue durée sans période d'inactivité, utilisez les journaux de flux VPC.

  • Connexions existantes : si vous activez la journalisation pour une règle qui correspond à une connexion déjà active TCP ou UDP, aucune entrée de journal n'est générée. La règle de stratégie de pare-feu ne consigne la connexion que si elle reste inactive pendant au moins 10 minutes et qu'un nouveau paquet est envoyé par la suite.

  • Comportement d'autorisation et de refus :

    • Autoriser + Journaliser : une connexion autorisée n'est consignée qu'une seule fois, et l' entrée n'est pas répétée même si la connexion est durable, car les règles de pare-feu sont avec état. Le trafic de réponse est autorisé automatiquement et n'est pas journalisé.

    • Refuser + Journaliser : chaque paquet supprimé correspondant à un 5-tuple unique est journalisé comme une tentative ayant échoué. L'entrée de journal est répétée toutes les cinq secondes tant que des paquets sont observés pour cette connexion refusée.

  • Perspective de génération de journaux : les entrées de journal ne sont créées que si la journalisation est activée pour la règle de stratégie de pare-feu et si cette règle s'applique au trafic envoyé à la VM ou émis par celle-ci. Les entrées sont créées en fonction des limites de journalisation des connexions.

  • Limites de débit : le nombre de connexions journalisées par unité de temps est déterminé par le type de machine de la VM pour les réseaux VPC standards, ou par l'action de surveillance ou de journalisation de la règle pour les réseaux VPC RoCE VPC. Pour en savoir plus, consultez Limites de journalisation des connexions et Surveillance et journalisation

  • Logique basée sur les sessions pour l'inspection avancée : lorsqu'une stratégie de pare-feu utilise l'action avancée apply_security_profile_group, le comportement de journalisation passe d'une logique basée sur les connexions à une logique basée sur les sessions.

    Cloud NGFW génère une seule entrée de journal de haut niveau pour la session initiale qui correspond à la règle et qui est interceptée avec succès pour l'inspection approfondie des paquets, même si plusieurs connexions sous-jacentes appartiennent à la même session. Ce journal de pare-feu de haut niveau est distinct des journaux détaillés de la couche 7, tels que le filtrage des URL ou les journaux de menaces, qui sont générés pour chaque connexion inspectée.

  • Actions et dispositions uniques : les journaux de stratégie Cloud NGFW sont les seuls journaux qui peuvent enregistrer la disposition INTERCEPTED et l'action APPLY_SECURITY_PROFILE_GROUP. Si cette action est utilisée, le système enregistre un champ supplémentaire (apply_security_profile_fallback_action).

  • Journaux d'audit : vous pouvez afficher les modifications de configuration apportées à la règle de stratégie de pare-feu dans les journaux d'audit Cloud NGFW. Pour en savoir plus, consultez Journalisation d'audit Cloud NGFW.

Limites

  • Lorsque vous utilisez l'action apply_security_profile_group avec la journalisation activée, Cloud NGFW ne capture pas les journaux de toutes les sessions. Cette limitation n'affecte pas l'inspection ni l'interception du trafic.

  • Si vous activez la journalisation pour une règle de stratégie de pare-feu qui correspond à des connexions TCP ou UDP existantes, aucune entrée de journal n'est générée pour ces connexions actives. La journalisation de ces connexions ne commence qu'après une période d'inactivité d'au moins 10 minutes.

  • Lorsque vous spécifiez le protocole IP (IpPortInfo.ip_protocol), la valeur ne peut pas être définie sur ALL pour les règles de stratégie de pare-feu.

  • Les règles de stratégie de pare-feu ne sont pas compatibles avec la journalisation des champs de métadonnées hérités, en particulier source_tag, target_tag, source_service_account et target_service_accounts.

Étape suivante