Cette page décrit les catégories et les états de Firewall Insights.
Les insights analysent la configuration et l'utilisation de vos règles de pare-feu à l'aide du type d'insight google.compute.firewall.Insight.
Catégories d'insights
Dans Firewall Insights, les insights appartiennent aux deux catégories générales décrites dans le tableau suivant.
| Catégorie | Description | Insights |
|---|---|---|
| Basé sur la configuration | Les insights sont générés en fonction des données sur la façon dont vous avez configuré vos règles de pare-feu. | Règles bloquées |
| Basé sur le journal | Les insights sont générés en fonction de la journalisation de l'utilisation de vos règles de pare-feu et des informations sur la façon dont vous les avez configurées. |
Règles trop permissives
Règles |
Chaque sous-type d'insight est associé à un niveau de gravité. Par exemple, pour les insights sur les règles bloquées, le niveau de gravité est medium. Pour en savoir plus, consultez la section
Gravité dans la
documentation de l'outil de recommandation.
États des insights
Chaque insight peut avoir l'un des états suivants, que vous pouvez modifier comme décrit dans le tableau ci-dessous.
| État | Description |
|---|---|
ACTIVE |
L'insight est actif. Google continue de mettre à jour le contenu des
ACTIVE insights en fonction des dernières informations. |
DISMISSED |
L'insight est ignoré et n'est plus affiché pour aucun utilisateur dans aucune
liste d'insights actifs. Vous pouvez rétablir l'état Pour en savoir plus, consultez la section Marquer un insight comme ignoré. |
Règles bloquées
Les règles bloquées partagent des attributs, tels que des adresses IP, avec d'autres règles de priorité supérieure ou égale, appelées règles bloquantes. Firewall Insights analyse vos règles de pare-feu VPC et stratégies de pare-feu pour détecter ces règles bloquées.
- Pour les stratégies de pare-feu attribuées à un réseau VPC, vous pouvez consulter des insights sur une règle de stratégie bloquée par une règle VPC dans la même stratégie ou dans une autre.
- Les stratégies de pare-feu hiérarchiques, les stratégies de pare-feu réseau mondiales et les règles de pare-feu VPC sont évaluées en fonction de l'ordre d'évaluation des stratégies et des règles. Par exemple, dans le cas des stratégies de pare-feu réseau mondiales, vous pouvez obtenir des insights sur la règle de stratégie de pare-feu réseau mondiale bloquée par une règle de pare-feu VPC en fonction de l'ordre d'évaluation des règles.
- Si vous disposez de règles de pare-feu avec des tags sécurisés dans une stratégie de pare-feu réseau mondiale, vous pouvez afficher des insights sur les règles qui se bloquent mutuellement dans la même stratégie de pare-feu mondiale. Pour en savoir plus, consultez la section Tags pour les pare-feu.
Firewall Insights n'identifie pas toutes les règles bloquantes possibles. Plus précisément, il n'identifie pas que plusieurs tags d'autres règles de pare-feu ont bloqué les tags d'une règle de pare-feu.
Exemples de règles bloquées
Dans cet exemple, certaines règles bloquées et bloquantes ont des filtres de plage IP source qui se chevauchent, tandis que d'autres ont des priorités de règles différentes.
Le tableau suivant présente les règles de pare-feu A à E. Pour différents scénarios de règles bloquées, consultez les sections qui suivent le tableau.
| Stratégie de pare-feu |
Type | Cibles | Filtres | Protocoles ou ports |
Action | Priorité | |
|---|---|---|---|---|---|---|---|
| Règle de pare-feu A | X | Ingress | Appliquer à tous | 10.10.0.0/16 | tcp:80 | Autoriser | 1000 |
| Règle de pare-feu B | O | Ingress | Appliquer à tous | 10.10.0.0/24 | tcp:80 | Autoriser | 1000 |
| Règle de pare-feu C | - | Ingress | web | 10.10.2.0/24 | tcp:80 tcp:443 |
Autoriser | 1000 |
| Règle de pare-feu D | - | Ingress | web | 10.10.2.0/24 | tcp:80 | Refuser | 900 |
| Règle de pare-feu E | - | Ingress | web | 10.10.2.0/24 | tcp:443 | Refuser | 900 |
Exemple 1 : la règle de pare-feu B est bloquée par la règle de pare-feu A
Dans cet exemple, il existe deux règles de pare-feu : A et B. Ces règles sont presque identiques, à l'exception de leurs filtres de plage d'adresses IP source. Par exemple, la plage d'adresses IP de A est 10.10.0.0/16, tandis que celle de B est 10.10.0.0/24. Par conséquent, la règle de pare-feu B est bloquée par la règle de pare-feu A.
L'insight shadowed firewall rules indique généralement une configuration incorrecte du pare-feu. Par exemple, le paramètre de filtre d'adresse IP de A est étendu, ou le paramètre de filtre de B est trop restrictif et inutile.
Exemple 2 : la règle de pare-feu C est bloquée par les règles de pare-feu D et E
Dans cet exemple, il existe trois règles de pare-feu : C, D et E. La règle de pare-feu C autorise l'entrée du trafic Web du port HTTP 80 et du port HTTPS 443, et a une priorité de 1000 (priorité par défaut). En revanche, les règles de pare-feu D et E refusent l'entrée du trafic Web HTTP et HTTPS, respectivement, et les deux ont une priorité de 900 (haute priorité). Par conséquent, la règle de pare-feu C est bloquée par les règles de pare-feu D et E combinées.
Exemple 3 : la règle de pare-feu B de la stratégie de pare-feu Y est bloquée par la règle de pare-feu A de la stratégie X
Dans cet exemple, il existe deux règles de pare-feu : A et B. La règle de pare-feu A se trouve dans la stratégie X associée à Folder1, tandis que la règle de pare-feu B se trouve dans la stratégie Y associée à Folder2. Folder1 et Folder2 se trouvent sous le même nœud d'organisation, et Folder2 est un enfant de Folder1. Ces deux règles sont identiques, à l'exception de leur plage d'adresses IP source. Cet insight indique que la règle de pare-feu B de la stratégie Y est inutile, car elle est déjà couverte par la règle de pare-feu A de la stratégie X. Par conséquent, la règle de pare-feu B de la stratégie Y est bloquée par la règle de pare-feu A de la stratégie X.
Exemple 4 : la règle de pare-feu B de la stratégie de pare-feu réseau mondiale Y est bloquée par la règle de pare-feu A
Dans cet exemple, il existe deux règles de pare-feu : A et B. Les règles de pare-feu A et B se trouvent dans Network1, mais la règle de pare-feu B se trouve dans la stratégie de pare-feu réseau mondiale Y.
L'ordre d'application de la stratégie de pare-feu Y est AFTER_CLASSIC_FIREWALLS.
Ces deux règles sont presque identiques, à l'exception de leur plage d'adresses IP source.
Cet insight indique que la règle B de la stratégie Y est inutile, car elle est déjà couverte par la règle A. Par conséquent, la règle de pare-feu B de la stratégie Y est bloquée par la règle de pare-feu A.
Règles de refus ayant été déclenchées
Cet aperçu fournit des détails sur les règles deny utilisées au cours de la
période d'observation.
Ces informations vous fournissent des signaux de suppression de paquets de pare-feu. Vous pouvez ensuite vérifier si les paquets supprimés sont attendus en raison de protections de sécurité ou s'ils sont le résultat d'une mauvaise configuration réseau.
Règles trop permissives
Firewall Insights fournit une analyse complète de la validité des règles de pare-feu. Cette analyse inclut les insights suivants :
- Règles d'autorisation non déclenchées
- Règles d'autorisation obsolètes en fonction de l'analyse adaptative
- Règles d'autorisation comportant des attributs non utilisés
- Règles d'autorisation avec des plages d'adresses IP ou de ports trop permissives
Les données fournies par ces insights proviennent de la journalisation des règles de pare-feu. Par conséquent, ces données ne sont exactes que si vous avez activé la journalisation des règles de pare-feu pendant toute la période d'observation. Sinon, le nombre de règles dans chaque catégorie d'insights peut être supérieur à celui indiqué.
Les insights sur les règles trop permissives évaluent le trafic TCP et UDP. Les autres types de trafic ne sont pas analysés. Pour en savoir plus, consultez la description de chaque insight.
Chaque sous-type d'insight est associé à un niveau de gravité. Par exemple, le niveau de gravité est high pour les insights sur les règles trop permissives. Pour en savoir plus, consultez la section
Gravité dans la
documentation de l'outil de recommandation.
Règles d'autorisation non déclenchées
Cet aperçu identifie les règles allow qui n'ont pas été utilisées pendant la période d'observation.
Pour chaque règle, vous pouvez consulter les prédictions de machine learning indiquant si une règle ou un attribut est susceptible d'être atteint à l'avenir. Cette prédiction est produite par une analyse de machine learning qui tient compte du modèle de trafic historique de cette règle et de règles similaires dans la même organisation.
Pour vous aider à comprendre la prédiction, cet aperçu identifie des règles similaires dans le même projet que la règle identifiée par l'insight. Il répertorie le nombre d'appels de ces règles et résume les détails de leur configuration. Ces détails incluent la priorité et les attributs de chaque règle, tels que son adresse IP et ses plages de ports.
Allow rules with no hits évalue les règles de pare-feu appliquées au trafic TCP et UDP. Si une règle de pare-feu autorise tout autre type de trafic, elle n'est pas incluse dans cette analyse.
Règles d'autorisation obsolètes en fonction de l'analyse adaptative
Cet aperçu identifie les règles allow qui sont moins susceptibles d'être actives en fonction des modèles d'utilisation et de l'analyse adaptative. L'insight est produit par une analyse de machine learning qui tient compte du nombre moyen d'appels au cours des six dernières semaines et de l'analyse adaptative des nombres d'appels récents. Toutefois, si la règle n'a jamais été active depuis le début du suivi du nombre d'appels, elle peut également être incluse dans l'insight jusqu'à ce qu'elle redevienne active.
Supposons, par exemple, qu'une règle de pare-feu ait été fréquemment appelée au cours des dernières semaines de la période d'observation et qu'elle ait cessé de l'être pendant plusieurs jours. Dans ce cas, cet insight peut s'afficher pour cette règle, indiquant une modification du modèle d'utilisation. Toutefois, les règles de pare-feu sont analysées pour identifier celles qui sont rarement appelées, mais qui sont actives. Ces règles actives n'apparaissent pas dans cet insight.
Pour chaque règle, si l'analyse de machine learning l'identifie comme inactive, vous pouvez afficher plus rapidement les insights basés sur l'analyse adaptative et avant la fin de votre période d'observation. Par exemple, vous pouvez commencer à recevoir des insights basés sur l'analyse adaptative après la première semaine de votre période d'observation, même si celle-ci dure 12 mois.
Une fois votre période d'observation terminée, vous pouvez afficher les insights basés sur les données collectées à partir de la journalisation des règles de pare-feu pendant toute la période d'observation.
Règles d'autorisation comportant des attributs non utilisés
Cet aperçu identifie les règles allow qui comportent des attributs tels que des adresses IP et des plages de ports qui n'ont pas été utilisés pendant la période d'observation.
Pour chaque règle identifiée, cet aperçu indique également la probabilité que la règle soit susceptible d'être atteinte à l'avenir. Cette prédiction est basée sur des prédictions de machine learning qui tiennent compte des modèles de trafic historiques de cette règle et de règles similaires dans la même organisation.
Pour vous aider à comprendre la prédiction, l'insight résume les autres règles de pare-feu du même projet qui présentent des attributs similaires. Ce résumé inclut des données indiquant si les attributs de ces règles ont été utilisés.
Allow rules with unused attributes n'évalue que les attributs définis pour le trafic TCP et UDP. Si une règle autorise d'autres types de trafic, outre TCP et UDP, elle peut être incluse dans cette analyse. Toutefois, les attributs qui concernent d'autres types de trafic ne sont pas analysés.
Supposons, par exemple, qu'une règle autorise le trafic TCP et ICMP. Si la plage d'adresses IP autorisée semble inutilisée, elle n'est pas considérée comme telle, car vous pouvez l'utiliser pour le trafic ICMP. Toutefois, si la même règle comporte une plage de ports TCP inutilisée, la règle est signalée comme étant trop permissive.
Règles d'autorisation avec des plages d'adresses IP ou de ports trop permissives
Cet aperçu identifie les règles allow qui peuvent avoir des adresses IP ou des plages de ports trop étendues.
Les règles de pare-feu sont souvent créées avec une portée plus large que nécessaire. Une portée trop large peut entraîner des risques de sécurité.
Cet insight permet d'atténuer ce problème en analysant l'utilisation réelle de vos adresses IP et de vos plages de ports de vos règles de pare-feu. Il suggère également une autre combinaison d'adresses IP et de plages de ports pour les règles dont les plages sont trop étendues. Grâce à ces connaissances, vous pouvez supprimer les plages de ports inutiles en fonction des modèles de trafic pendant la période d'observation.
Allow rules with overly permissive IP address or port ranges n'évalue que les attributs définis pour le trafic TCP et UDP. Si une règle autorise d'autres types de trafic, outre TCP et UDP, elle peut être incluse dans cette analyse.
Toutefois, les attributs qui concernent d'autres types de trafic ne sont pas analysés.
Supposons, par exemple, qu'une règle autorise le trafic TCP et ICMP. Si la plage d'adresses IP autorisée semble n'être que partiellement utilisée, l'insight ne signale pas la plage d'adresses IP comme étant trop étendue, car elle peut être utilisée pour le trafic ICMP. Toutefois, si la même règle comporte une plage de ports TCP partiellement inutilisée, la règle est signalée comme étant trop permissive.
Sachez que votre projet peut comporter des règles de pare-feu qui autorisent l'accès à partir de certains blocs d'adresses IP pour les vérifications de l'état de l'équilibreur de charge ou pour d'autres Google Cloud fonctionnalités. Ces adresses IP risquent de ne pas être appelées, mais elles ne doivent pas être supprimées de vos règles de pare-feu. Pour en savoir plus sur ces plages, consultez la documentation Compute Engine.
Prédictions de machine learning
Comme décrit dans les sections précédentes, deux insights (les règles allow non déclenchées et les règles allow avec des attributs non utilisés) utilisent les prédictions de machine learning.
Pour générer des prédictions, Firewall Insights entraîne un modèle de machine learning à l'aide des règles de pare-feu de la même organisation. De cette manière, Firewall Insights apprend les modèles courants. Par exemple, Firewall Insights apprend sur les combinaisons d'attributs qui ont tendance à être atteints. Ces attributs peuvent inclure des plages d'adresses IP, des plages de ports et des protocoles IP.
Si la règle de pare-feu contient des modèles courants qui montrent qu'elle est susceptible d'être atteinte, Firewall Insights est plus sûr que la règle pourrait être appelée à l'avenir. L'inverse est également vrai.
Pour chaque aperçu utilisant des prédictions, Firewall Insights affiche des détails sur les règles considérées comme similaires à la règle identifiée par l'insight. Par exemple, dans le panneau Détails de l'insight, vous pouvez afficher des détails sur les trois règles les plus similaires à la règle qui fait l'objet de la prédiction. Plus les attributs des deux règles se chevauchent, plus elles sont considérées comme similaires.
Pour les règles allow non déclenchées, considérons l'exemple suivant :
Supposons que la règle A comporte les attributs suivants :
Source IP ranges: 10.0.1.0/24
Target tags: http-server
Protocol and ports: TCP:80
Supposons que la règle B comporte les attributs suivants :
Source IP ranges: 10.0.2.0/24
Target tags: http-server
Protocol and ports: TCP:80
Ces deux règles partagent les mêmes tags cibles, attributs de protocole et attributs de port. Elles ne diffèrent que par leurs attributs source. Pour cette raison, elles sont considérées comme similaires.
Pour les règles allow avec des attributs non utilisés, la similarité est déterminée de la même manière. Pour cet insight, Firewall Insights tient compte des règles similaires lorsque leur configuration inclut les mêmes attributs.