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 de configuration de 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 configuration de vos règles de pare-feu. |
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, qu'il est possible de modifier comme décrit dans le tableau.
| É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 ne s'affiche plus sur aucune liste d'insights actifs des utilisateurs. 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 les 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 vos stratégies de pare-feu pour détecter ces règles masqué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 masqué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 masqué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 au niveau mondial, vous pouvez afficher des insights sur les règles qui se masquent mutuellement dans la même stratégie de pare-feu global. 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 ne détecte pas que plusieurs tags d'autres règles de pare-feu ont masqué 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 de 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 | Entrée | Appliquer à tous | 10.10.0.0/16 | tcp:80 | Autoriser | 1000 |
| Règle de pare-feu B | O | 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 plage d'adresses IP source. 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.
Les insights shadowed firewall rules indiquent généralement une configuration du pare-feu incorrecte. Par exemple, le paramètre de filtre d'adresse IP de A est trop large, 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 au dossier 1, tandis que la règle de pare-feu B se trouve dans la stratégie Y associée au dossier 2. Les dossiers 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 globale 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 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 règle 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 "deny" ayant fait l'objet d'appels
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
- Autoriser les règles 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'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 de 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 des 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.
Autoriser les règles obsolètes en fonction de l'analyse adaptative
Cet insight identifie les règles allow qui sont moins susceptibles d'être actives en fonction des tendances d'utilisation et de l'analyse adaptative. Cet insight est généré par une analyse de machine learning tenant 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 de requêtes, 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 n'ait plus été appelée pendant plusieurs jours. Dans ce cas, vous verrez peut-être cet insight pour cette règle, ce qui indique un changement dans le modèle d'utilisation. Toutefois, les règles de pare-feu sont analysées pour identifier celles qui sont déclenchées rarement, mais qui sont actives. Ces règles actives n'apparaissent pas dans cet insight.
Pour chaque règle, si l'analyse de machine learning identifie la règle comme inactive, vous pouvez consulter les insights basés sur l'analyse adaptative plus rapidement et avant la fin de votre 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 celle-ci est de 12 mois.
À la fin de la période d'observation, vous pouvez afficher les insights basés sur les données recueillies lors 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 insight identifie les règles allow dont les attributs tels que l'adresse IP et les plages de ports 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é atteints.
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 être 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 insight identifie les règles allow qui peuvent avoir des plages d'adresses IP ou 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 combinaison alternative de plages d'adresses IP et de plages de ports pour les règles comportant des plages 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 cette plage comme étant trop large, 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 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 non utilisé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 appelée, Firewall Insights est plus sûr que la règle pourrait ê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 similaires à la règle identifiée par l'insight. Par exemple, dans le panneau Détails de l'insight, vous pouvez consulter les détails des trois règles les plus similaires à la règle faisant l'objet de la prédiction. Plus il existe de chevauchements entre les attributs des deux règles, plus elles sont similaires.
Pour les règles allow non utilisées, considérons l'exemple suivant :
Supposons que la règle A possède 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 possède 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 comportant 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.