Cette page présente les bonnes pratiques permettant d'optimiser et d'ajuster les déploiements de Google Cloud Armor.
Google Cloud Armor est déployé avec l'équilibreur de charge d'application externe global, l'équilibreur de charge d'application classique ou l'équilibreur de charge réseau proxy externe. Lorsque vous déployez Google Cloud Armor, vous associez une stratégie de sécurité au service de backend de l'équilibreur de charge que vous souhaitez protéger. Une stratégie de sécurité consiste en un ensemble de règles préconfigurées et de règles personnalisées que vous déterminez.
Création d'une stratégie et de règles de sécurité
Les sections suivantes spécifient les bonnes pratiques et les recommandations concernant les nouvelles règles et stratégies de sécurité.
Fournir des descriptions de règles
Utilisez les descriptions de règles pour fournir plus de contexte sur le motif sous-jacent à la création de chaque règle, et la fonction visée pour chacune d'elles. Le champ description est limité à 64 caractères. Par conséquent, les références aux bases de données de gestion de configuration ou à d'autres dépôts constituent le moyen le plus efficace de spécifier du contexte.
Définir un espacement approprié entre les priorités
Lorsque vous configurez des règles pour la première fois, laissez un intervalle d'au moins 10 entre chaque valeur de priorité de règle. Par exemple, les deux premières règles d'une stratégie de sécurité peuvent avoir les priorités 20 et 30. Cela vous permettra ultérieurement d'insérer d'autres règles entre celles-ci, le cas échéant. En outre, nous vous recommandons de regrouper les règles similaires dans des blocs, en laissant des intervalles plus grands entre les groupes.
Utiliser le mode Aperçu
Les règles de stratégie de sécurité, y compris les signatures Open Web Application Security Project (OWASP), peuvent avoir des effets imprévisibles sur votre application. Utilisez le mode aperçu pour évaluer si l'introduction d'une règle va avoir un impact négatif sur le trafic de production.
Activer Google Cloud Armor Adaptive Protection
Activez le service Adaptive Protection pour renforcer la protection de vos applications. Adaptive Protection surveille le trafic et (si nécessaire) recommande de nouvelles règles pour vos stratégies de sécurité. En outre, nous vous recommandons de mettre en place une règle d'alerte afin de vous assurer que les personnes appropriées seront averties des attaques potentielles. Adaptive Protection est particulièrement adapté à la protection volumétrique. Adaptive Protection peut ne pas se déclencher en cas d'attaques non volumétriques.
Activer l'analyse JSON
Si votre application envoie du contenu JSON dans le corps des requêtes POST, veillez à activer l'analyse JSON. Si vous n'activez pas l'analyse JSON, Google Cloud Armor n'analyse pas le contenu JSON des corps de requêtes POST pour les règles WAF préconfigurées. Les résultats peuvent contenir du bruit et générer de faux positifs. Pour en savoir plus, consultez la section Analyse JSON.
Tester votre logique
Une règle est déclenchée lorsque sa condition de correspondance renvoie la valeur "true". Par exemple, la condition de correspondance origin.region_code == 'AU' renvoie la valeur "true" si le code de région de la requête est AU. Si une règle de priorité supérieure renvoie la valeur "true", l'action correspondant à une règle de priorité inférieure est ignorée. Dans l'exemple suivant, supposons que vous souhaitiez créer une règle de sécurité pour bloquer les utilisateurs de la région AU, à l'exception du trafic compris dans la plage d'adresses IP 10.10.10.0/24. Étudions alors la stratégie de sécurité suivante, qui contient deux règles :
Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2
Dans cet exemple, Rule1 autorise le trafic provenant de la plage d'adresses IP 10.10.10.0/24. Comme Rule1 est la règle de priorité la plus élevée, ce trafic est autorisé avant d'être soumis à la règle Rule2, ce qui signifie que Google Cloud Armor ne l'évalue pas par rapport à Rule2 (ou à toute autre règle ayant une priorité moindre).
Lorsque vous créez des stratégies Google Cloud Armor, testez la logique de vos règles pour vous assurer d'obtenir le comportement souhaité. Pour ce faire, nous vous recommandons de générer un trafic synthétique afin de comprendre quelles sont les règles qui bloquent le trafic et de vérifier que vos résultats sont cohérents avec vos décisions de conception de règles. Si vous n'êtes pas sûr du cheminement d'une requête au sein du système, utilisez le mode aperçu pour voir quelle règle correspond à la requête.
Identifier les adresses IP sources de vos analyseurs
Vos analyseurs de sécurité peuvent être situés à l'intérieur ou à l'extérieur de Google. Si vous souhaitez obtenir une évaluation externe et non filtrée de votre application, vous pouvez autoriser explicitement le trafic en fonction de l'adresse IP (ou d'un autre jeton) avant de l'évaluer par rapport à d'autres règles.
Regrouper et trier les règles au sein de votre stratégie de sécurité
Vos applications peuvent desservir différents sous-ensembles de vos clients. Dans l'exemple suivant, vous souhaitez refuser le trafic provenant de certaines zones géographiques ou plages d'adresses IP. Vous devez donc configurer la première règle de votre stratégie afin de refuser ce trafic. En outre, vous souhaitez autoriser explicitement une part du trafic dans l'application, sans qu'il ne soit traité par la règle de sécurité. Nous recommandons dès lors la structure de priorités de règles suivante pour cet exemple, de la priorité la plus élevée à la plus faible :
- Règles de refus explicites (ASN, région, plages d'adresses IP)
- Règles d'autorisation explicites et approuvées (analyseurs, systèmes approuvés – à utiliser avec une extrême précaution)
- Règles de sécurité (OWASP, règles personnalisées)
- Règles d'autorisation explicites (ASN, présence d'une valeur d'en-tête, plage d'adresses IP)
- Règles de refus par défaut
Utiliser reCAPTCHA pour la gestion des bots
Google Cloud Armor s'intègre au reCAPTCHA pour les bots de Google au niveau de la couche WAF. Dans cette intégration, reCAPTCHA génère des jetons reCAPTCHA, et Google Cloud Armor les exécute au lieu de reCAPTCHA. Cela réduit l'origine ce qui permet de réduire les coûts et de rapprocher les contrôles de sécurité que vos backends. Pour en savoir plus, consultez la présentation de la gestion des robots.
Définir des seuils de limitation du débit
La limitation du débit est une fonctionnalité flexible et utile pour éviter les utilisations abusives et limiter les attaques par saturation de service, telles que le bourrage d'identifiants et les attaques DDoS L7. Lorsque vous déployez la limitation du débit pour la première fois, il est important de choisir un seuil pertinent pour votre application. Nous vous recommandons de commencer par les appliquer en mode aperçu. Vous pouvez ajuster les paramètres de limitation du débit à mesure que vous analysez et interprétez le profil du trafic. En outre, il est important de prendre en compte la priorité que vous attribuez à la règle de limitation du débit. Le trafic peut être autorisé ou refusé explicitement par une règle de priorité supérieure avant d'être évalué selon la règle de limitation du débit.
Optimisation des règles
Les applications Web peuvent autoriser des requêtes qui semblent être des attaques et peuvent autoriser, voire exiger, que les utilisateurs envoient des requêtes correspondant aux signatures dans les règles WAF préconfigurées. Il est essentiel de valider les règles Google Cloud Armor par rapport à votre application et de traiter les résultats susceptibles de ne pas être pertinents pour votre application, avant de promouvoir la règle en désactivant le mode aperçu sur une application de production. Les sections suivantes contiennent des bonnes pratiques et des recommandations pour l'ajustement des règles WAF préconfigurées.
Choisir le niveau de sensibilité des règles WAF préconfigurées
Lorsque vous mettez en œuvre l'une des règles WAF préconfigurées, vous pouvez choisir un niveau de sensibilité approprié en fonction de vos exigences de sécurité et de vos échéances. Nous vous recommandons de commencer par un niveau de sensibilité de 1 pour la plupart des applications devant répondre aux exigences de sécurité de votre organisation. Les règles configurées sur la sensibilité 1 utilisent des signatures haute fidélité et réduisent le bruit potentiellement généré par la règle. Les signatures associées à des sensibilités plus élevées peuvent détecter et empêcher un plus grand nombre de tentatives d'"exploit", occasionnant cependant du bruit potentiel pour certaines applications protégées. Toutefois, les charges de travail soumises à des exigences de sécurité plus strictes peuvent davantage se prêter à un niveau de sensibilité le plus élevé. Ces cas d'utilisation peuvent générer beaucoup de bruit ou de nombreux résultats non pertinents, que vous devez résoudre en ajustant les réglages, avant que la stratégie de sécurité ne soit mise en production.
Activer la journalisation détaillée
Si vous avez besoin d'informations supplémentaires sur les attributs de requête et les charges utiles déclenchant une règle WAF particulière, activez la journalisation détaillée. La journalisation détaillée fournit des informations sur les requêtes qui déclenchent des règles particulières, y compris un extrait de la partie mise en cause de la requête, ce qui est utile pour diagnostiquer les problèmes et ajuster Google Cloud Armor. La journalisation détaillée peut entraîner la journalisation du contenu des requêtes des utilisateurs finaux dans Cloud Logging. Par conséquent, vous risquez d'accumuler des informations permettant d'identifier personnellement les utilisateurs finaux dans les journaux. Nous vous déconseillons donc d'exécuter des charges de travail de production avec la journalisation détaillée activée pendant de longues périodes.
Utiliser des règles stables ou Canary
Il existe deux types de règles WAF préconfigurées dans Google Cloud Armor : les règles stables et les règles Canary. Lorsque de nouvelles règles sont ajoutées au jeu actuel ModSecurity Core Rule Set (CRS), nous les publions dans les builds de règles Canary avant de les publier automatiquement dans les builds de règles stables. Nous vous recommandons de déployer les règles Canary dans un environnement de test afin de pouvoir constater les effets des modifications et ajouts dans votre environnement. Vous pouvez consulter les noms des règles sur la page Ajuster les règles WAF de Google Cloud Armor pour vérifier si le build de règles Canary est synchronisé avec le build de règles stables.
Journalisation et surveillance
Les sections suivantes contiennent des bonnes pratiques et recommandations pour configurer la journalisation et la surveillance.
Utiliser Security Command Center
Google Cloud Armor s'intègre automatiquement à Security Command Center. Google Cloud Armor exporte différents résultats dans Security Command Center :
- Pic de trafic autorisé
- Augmentation du taux de refus
Assurez-vous que votre personnel de sécurité Web examine ces résultats.
Choisir un taux d'échantillonnage pour Cloud Logging
Les journaux par requête Google Cloud Armor utilisent l'équilibreur de charge d'application externe global ou le la journalisation d'un équilibreur de charge d'application classique de l'infrastructure. Par conséquent, la génération de journaux Google Cloud Armor est soumise au taux d'échantillonnage des journaux configuré sur l'équilibreur de charge. Nous vous recommandons de conserver le taux d'échantillonnage sur 1 lors d'une démarche active d'ajustement et de mise en œuvre de Google Cloud Armor. Une fois les réglages et la mise en œuvre de Google Cloud Armor terminés, nous vous recommandons de laisser la journalisation complète des requêtes activée. Cependant, certains clients préféreront peut-être redescendre à un taux d'échantillonnage moindre. Les l'équilibreur de charge d'application externe global et l'équilibreur de charge d'application classique ne activer les journaux par défaut. Il est donc important de les activer manuellement.
Utiliser le tableau de bord Cloud Monitoring
Il est essentiel d'avoir une vision claire de ce qui se passe dans votre configuration Google Cloud Armor. Pour faciliter cette tâche, vous pouvez utiliser le tableau de bord de sécurité. Vous pouvez également exporter les journaux Google Cloud Armor directement de Logging vers votre propre plate-forme. Si vous utilisez Adaptive Protection, il est important de disposer d'une procédure de remontée des informations pour toutes les alertes Adaptive Protection déclenchées.
Gestion générale
Vous trouverez ci-dessous des bonnes pratiques et des recommandations supplémentaires pour configurer Google Cloud Armor.
Configurer le contrôle des accès IAM
Conformément aux bonnes pratiques générales de Google Cloud IAM (Identity and Access Management), assurez-vous que les bonnes personnes ont accès à Google Cloud Armor. Le rôle "Administrateur de sécurité de Compute" est requis pour configurer, modifier, mettre à jour et supprimer des stratégies de sécurité Google Cloud Armor. En outre, le rôle "Administrateur de réseaux Compute" ou l'autorisation compute.backendServices.setSecurityPolicy est requis pour associer une stratégie de sécurité Google Cloud Armor à un service de backend.
Réduire le nombre de règles
Une stratégie Google Cloud Armor peut être réutilisée sur plusieurs services de backend. Nous vous recommandons de disposer d'un ensemble cohérent de stratégies de sécurité réutilisables.
Utiliser Terraform
Pour assurer un rollback aisé sur les configurations, ainsi que leur reproduction entre différents projets, nous vous recommandons d'utiliser Terraform. Google Cloud Armor dispose d'une intégration Terraform complète pour les fonctionnalités DG.
Configurer Google Cloud Armor avec Google Kubernetes Engine
Si vous utilisez GKE, vous devez configurer Google Cloud Armor et les autres fonctionnalités sur le trafic entrant via les paramètres BackendConfig. Nous vous déconseillons de configurer manuellement un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique comme point d'entrée. Pour en savoir plus sur la configuration de Google Cloud Armor avec GKE, consultez la page Configurer les fonctionnalités Ingress.