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 relatives à la configuration de vos règles de pare-feu. | Règles bloquées |
| Basé sur le journal | Les insights sont générés sur la base de la journalisation de l'utilisation de vos règles de pare-feu et des informations sur leur configuration. |
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 suivant.
| État | Description |
|---|---|
ACTIVE |
L'insight est actif. Google continue de mettre à jour le contenu des insights ACTIVE en fonction des dernières informations. |
DISMISSED |
L'insight est ignoré et n'est plus visible par les utilisateurs d'une liste d'insights active. Vous pouvez restaurer l'état Pour en savoir plus, consultez Marquer un insight comme ignoré. |
Règles bloquées
Les règles bloquées partagent des attributs, tels que les adresses IP, avec d'autres règles de priorité égale ou supérieure, appelées règles bloquantes. Firewall Insights analyse vos règles de pare-feu VPC et vos 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 afficher des insights sur une règle de stratégie bloquée par une règle VPC de la même stratégie ou de toute autre stratégie.
- 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. Par exemple, dans le cas des stratégies de pare-feu réseau globales, vous pouvez obtenir des informations sur la règle de stratégie de pare-feu réseau globale 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 globale, vous pouvez afficher des insights sur ces règles qui se bloquent les unes les autres dans la même stratégie de pare-feu globale. 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, elle 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 bloquées présentent des filtres de plages d'adresses IP sources 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 de A à E. Pour différents scénarios de règles bloquées, consultez les sections suivantes du tableau.
| Règle de pare-feu |
Type | Cibles | Filtres | Protocoles ou ports |
Action | Priorité | |
|---|---|---|---|---|---|---|---|
| Règle de pare-feu A | X | Entrée | Appliquer à tous | 10.10.0.0/16 | tcp:80 | Autoriser | 1000 |
| Règle de pare-feu B | Y | Entrée | Appliquer à tous | 10.10.0.0/24 | tcp:80 | Autoriser | 1000 |
| Règle de pare-feu C | - | Entrée | web | 10.10.2.0/24 | tcp:80 tcp:443 | Autoriser | 1000 |
| Règle de pare-feu D | - | Entrée | web | 10.10.2.0/24 | tcp:80 | Refuser | 900 |
| Règle de pare-feu E | - | Entrée | 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 plages d'adresses IP sources. Par exemple, la plage d'adresses IP de A est 10.10.0.0/16, tandis que la plage d'adresses IP 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 erreur de configuration du pare-feu. Par exemple, le paramètre de filtre d'adresse IP A est large, ou le paramètre de filtre 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 des ports HTTP 80 et HTTPS 443. Elle a la priorité 1000 (priorité par défaut). En revanche, les règles de pare-feu D et E refusent respectivement l'entrée du trafic Web HTTP et HTTPS, et ont toutes deux une priorité de 900 (priorité élevée). Ainsi, 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 A dans 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 au dossier 1, tandis que la règle de pare-feu B se trouve dans la stratégie Y associée au dossier 2. "Dossier 1" et "Dossier 2" se trouvent sous le même nœud d'organisation, et "Dossier 2" est un enfant de "Dossier 1". Ces deux règles sont identiques, sauf pour leur plage d'adresses IP source. Cet insight indique que la règle de pare-feu B de la stratégie Y n'est pas nécessaire, car elle est déjà couverte par la règle de pare-feu A dans la stratégie X. Ainsi, 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 globale Y est bloquée par la règle 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 globale Y.
L'ordre d'application de la stratégie de pare-feu de la stratégie 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 n'est pas nécessaire, car elle est déjà couverte par la règle A. Ainsi, 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 "deny" ayant fait l'objet d'appels
Cet insight fournit des détails sur les règles deny qui ont fait l'objet d'appels 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 dus à des protections de sécurité ou s'ils résultent d'une mauvaise configuration du réseau.
Règles trop permissives
Firewall Insights fournit une analyse complète du caractère trop permissif de vos règles de pare-feu. Cette analyse inclut les insights suivants :
- Règles d'autorisation non déclenchées
- Autoriser les règles obsolètes basées sur 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 pour l'ensemble de la période d'observation. Sinon, le nombre de règles dans chaque catégorie d'insight 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 afficher des prédictions de machine learning pour savoir si une règle ou un attribut est susceptible d'être appelé à l'avenir. Cette prédiction est produite par une analyse de machine learning qui prend en compte le modèle de trafic historique de cette règle et des règles similaires de la même organisation.
Pour vous aider à comprendre la prédiction, cet insight identifie des règles similaires dans le même projet que la règle identifiée par l'insight. L'insight répertorie le nombre d'appels de ces règles et récapitule les détails de leur configuration. Ces informations incluent la priorité et les attributs de chaque règle, tels que l'adresse IP et les 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.
Autoriser les règles obsolètes basées sur l'analyse adaptative
Cet insight identifie les règles allow les moins susceptibles d'être actives en fonction des schémas d'utilisation et de l'analyse adaptative. L'insight est généré par une analyse de machine learning qui tient compte du nombre moyen d'appels au cours des six dernières semaines et du nombre d'appels récents de l'analyse adaptative. 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.
Par exemple, supposons 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, vous verrez peut-être cet insight pour cette règle, indiquant un changement dans le modèle d'utilisation. Cependant, les règles de pare-feu sont analysées pour identifier ces appels peu fréquents, mais actifs. Ces règles actives n'apparaissent pas dans cet insight.
Pour chaque règle, si l'analyse du machine learning identifie la règle comme inactive, vous pouvez afficher les insights basés sur l'analyse adaptative plus rapidement et avant la fin de la période d'observation. Par exemple, vous pouvez commencer à obtenir des insights basés sur l'analyse adaptative après la première semaine de votre période d'observation, même si elle dure 12 mois.
Une fois la période d'observation terminée, vous pouvez afficher des insights basés sur les données collectées via la journalisation des règles de pare-feu pour l'ensemble de la période d'observation.
Règles d'autorisation comportant des attributs non utilisés
Cet insight identifie les règles allow dont les attributs, tels que les plages d'adresses IP et de ports, n'ont pas été appelés pendant la période d'observation.
Pour chaque règle identifiée, cet insight indique également la probabilité que la règle soit utilisée à 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 des règles similaires de 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écapitulatif inclut des données indiquant si les attributs de ces règles ont été appelé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 ne l'est pas, car vous pourriez l'utiliser pour le trafic ICMP. Toutefois, si la même règle comporte une plage de ports TCP inutilisées, la règle est signalée comme trop permissive.
Règles d'autorisation avec des plages d'adresses IP ou de ports trop permissives
Cet insight 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 un champ d'application plus large que nécessaire. Un champ d'application 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 l'adresse IP et des plages de ports de vos règles de pare-feu. Il suggère également une autre combinaison de plages d'adresses IP et de ports pour les règles comportant des plages trop larges. Avec 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 que TCP et UDP, elle peut être incluse dans cette analyse.
Toutefois, les attributs correspondant à 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 ne semble n'être que partiellement utilisée, l'insight ne la signale pas comme trop large, car elle pourrait ê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 disposer de règles de pare-feu autorisant l'accès à partir de certains blocs d'adresses IP pour les vérifications d'état de l'équilibreur de charge ou pour d'autres fonctionnalités de Google Cloud. 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 plus d'informations sur ces plages, consultez la documentation sur Compute Engine.
Prédictions de machine learning
Comme décrit dans les sections précédentes, deux insights (les règles allow sans appel et les règles allow avec des attributs inutilisés) utilisent des prédictions de machine learning.
Pour générer des prédictions, Firewall Insights entraîne un modèle de machine learning à l'aide de 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 schémas courants indiquant qu'elle est susceptible d'être appelée, Firewall Insights considère que la règle est susceptible d'être appelée à l'avenir. L'inverse est également vrai.
Pour chaque insight utilisant des prédictions, Firewall Insights affiche des détails sur les règles considérées comme semblables à la règle identifiée par l'insight. Par exemple, dans le panneau Détails des insights, vous pouvez consulter des informations sur les trois règles les plus semblables à celle qui fait l'objet de la prédiction. Plus il y a de chevauchement entre les attributs des deux règles, plus elles sont considérées comme similaires.
Pour les règles allow non utilisé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
Et supposons que la règle B ait 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 attributs de tags cibles, de protocoles et de ports. Ils ne diffèrent que par leurs attributs sources. Pour cette raison, ils sont considérés comme similaires.
Pour les règles allow comportant des attributs inutilisés, la similarité est déterminée de la même manière. Pour cet insight, Firewall Insights considère les règles de la même manière lorsque leur configuration inclut les mêmes attributs.