Présentation des stratégies de sécurité

Cette page explique comment utiliser les stratégies de sécurité Google Cloud Armor pour protéger vos déploiements Google Cloud.

Les stratégies de sécurité Google Cloud Armor protègent votre application en fournissant un filtrage de couche 7 et en effaçant les requêtes entrantes pour détecter les attaques Web courantes ou d'autres attributs de couche 7 afin de bloquer potentiellement le trafic avant qu'il n'atteigne vos services de backend à équilibrage de charge ou vos buckets backend. Chaque stratégie de sécurité est constituée d'un ensemble de règles qui filtrent le trafic en fonction de conditions telles que l'adresse IP d'une requête entrante, la plage d'adresses IP, le code de la région ou les en-têtes de requêtes.

Les stratégies de sécurité Google Cloud Armor sont disponibles pour les types d'équilibreurs de charge et de points de terminaison suivants:

Équilibreur de charge d'application externe global (HTTP/HTTPS)
Équilibreur de charge d'application classique (HTTP/HTTPS)
Équilibreur de charge d'application externe régional (HTTP/HTTPS)
Équilibreur de charge réseau proxy externe global (TCP/SSL)
Équilibreur de charge réseau proxy classique (TCP/SSL)
Équilibreur de charge réseau passthrough externe (TCP/UDP)
Transfert de protocole
VM dotées d'adresses IP publiques

L'équilibreur de charge peut être en niveau Premium ou Standard.

Les backends du service de backend peuvent être n'importe lequel des éléments suivants :

Groupes d'instances
Groupes de points de terminaison du réseau (NEG) zonaux
Groupes de points de terminaison du réseau (NEG) sans serveur : un ou plusieurs services App Engine, Cloud Run ou Cloud Functions
NEG Internet pour les backends externes
Buckets dans Cloud Storage

Lorsque vous utilisez Google Cloud Armor pour protéger un déploiement hybride ou une architecture multicloud, les backends doivent être des NEG Internet. Google Cloud Armor protège également les NEG sans serveur lorsque le trafic est acheminé via un équilibreur de charge. Pour vous assurer que seul le trafic acheminé via votre équilibreur de charge atteint votre NEG sans serveur, consultez la page Contrôles d'entrée.

Google Cloud Armor offre également une protection DDoS avancée du réseau pour les équilibreurs de charge réseau passthrough externes, le transfert de protocole et les VM avec des adresses IP publiques. Pour en savoir plus sur la protection DDoS avancée du réseau, consultez la page Configurer la protection DDoS avancée du réseau.

Protégez vos déploiements Google Cloud avec les stratégies de sécurité Google Cloud Armor

L'équilibrage de charge externe est mis en œuvre à la périphérie du réseau Google dans des points de présence de Google à travers le monde. Au niveau Premium, le trafic utilisateur dirigé vers un équilibreur de charge externe entre dans le point de présence le plus proche de l'utilisateur. Ensuite, l'équilibrage de la charge sur le réseau mondial de Google permet d'acheminer le trafic jusqu'au backend le plus proche disposant d'une capacité suffisante. Dans le niveau Standard, le trafic utilisateur entre dans le réseau de Google par le biais de réseaux d'appairage, de fournisseurs d'accès Internet ou de transit dans la région où vous avez déployé vos ressources Google Cloud.

Les stratégies de sécurité Google Cloud Armor vous permettent d'autoriser, de refuser, de limiter le débit ou de rediriger les requêtes vers vos services de backend à la périphérie de Google Cloud, aussi près que possible de la source du trafic entrant. Cela empêche le trafic indésirable de consommer des ressources ou d'entrer dans vos réseaux de cloud privé virtuel (VPC, Virtual Private Cloud).

Le schéma suivant illustre l'emplacement des équilibreurs de charge d'application externes globaux, des équilibreurs de charge d'application classiques, du réseau Google et des centres de données Google.

Stratégie Google Cloud Armor à la périphérie du réseau. — Règle Google Cloud Armor à la périphérie du réseau (cliquez pour agrandir).

Conditions requises

Voici les exigences liées à l'utilisation des stratégies de sécurité Google Cloud Armor :

L'équilibreur de charge doit être un équilibreur de charge d'application externe global, un équilibreur de charge d'application classique, un équilibreur de charge d'application externe régional, un équilibreur de charge réseau proxy externe global ou un équilibreur de charge réseau proxy classique.
Le schéma d'équilibrage de charge du service de backend doit être EXTERNAL ou EXTERNAL_MANAGED.
Le protocole du service de backend doit être HTTP, HTTPS, HTTP/2, UDP, TCP, SSL ou UNSPECIFIED.

À propos des stratégies de sécurité Google Cloud Armor

Les stratégies de sécurité Google Cloud Armor sont des ensembles de règles qui correspondent aux attributs de couche 3 à 7, afin de protéger les applications ou services externes. Chaque règle est évaluée en fonction du trafic entrant.

Une règle de stratégie de sécurité Google Cloud Armor consiste en une condition de correspondance et une action à entreprendre lorsque cette condition est remplie. Les conditions peuvent être simples, par exemple si l'adresse IP source du trafic entrant correspond à une adresse IP ou à une plage CIDR spécifique (ce que l'on appelle également "règles de liste d'autorisation et de refus d'adresses IP"). À l'aide de la documentation de référence sur le langage des règles personnalisées Google Cloud Armor, vous pouvez également créer des conditions personnalisées qui correspondent à différents attributs du trafic entrant, tels que le chemin d'URL, la méthode de requête ou les valeurs d'en-tête de requête.

Lorsqu'une requête entrante correspond à une condition d'une règle de stratégie de sécurité, Google Cloud Armor autorise, refuse ou redirige la requête, selon que cette requête est une règle d'autorisation, de refus ou de redirection. Vous pouvez appliquer des paramètres d'action supplémentaires, comme l'insertion d'en-têtes de requêtes. Cette fonctionnalité fait partie de la gestion des robots Google Cloud Armor. Pour en savoir plus sur la gestion des robots, consultez la présentation de la gestion des robots.

Vous pouvez associer une stratégie de sécurité Google Cloud Armor à un ou plusieurs services de backend. Un service de backend ne peut être associé qu'à une seule stratégie de sécurité, mais vos services de backend n'ont pas besoin d'être associés à la même stratégie de sécurité.

Si une stratégie de sécurité Google Cloud Armor est associée à un service de backend, elle ne peut pas être supprimée. Un service de backend peut être supprimé, qu'une stratégie de sécurité lui soit associée ou non.

Si plusieurs règles de transfert pointent vers un service de backend auquel une stratégie de sécurité est associée, elles sont appliquées à tout le trafic entrant dans chacune de leurs adresses IP.

Dans l'illustration suivante, la stratégie de sécurité Google Cloud Armor internal-users-policy est associée au service de backend test-network.

Stratégie de sécurité Google Cloud Armor à la périphérie du réseau. — Stratégie de sécurité Google Cloud Armor à la périphérie du réseau (cliquez pour agrandir).

Les stratégies de sécurité Google Cloud Armor présentent les fonctionnalités suivantes :

Vous pouvez éventuellement utiliser le protocole QUIC avec les équilibreurs de charge qui utilisent Google Cloud Armor.
Vous pouvez utiliser Google Cloud Armor avec des équilibreurs de charge qui appartiennent à l'un des niveaux de service réseau suivants :
- Niveau Premium
- Niveau Standard
Vous pouvez utiliser des stratégies de sécurité de backend avec GKE et le contrôleur d'Ingress par défaut.
Vous pouvez utiliser une stratégie de sécurité par défaut qui limite le trafic sur un seuil spécifié par l'utilisateur lorsque vous configurez l'un des équilibreurs de charge suivants :
- Équilibreur de charge d'application externe global
- Équilibreur de charge d'application classique
- Équilibreur de charge d'application externe régional
- Équilibreur de charge réseau proxy externe global
- Équilibreur de charge réseau proxy classique
- Équilibreur de charge réseau passthrough externe

En outre, vous pouvez configurer des règles WAF préconfigurées de Google Cloud Armor, qui sont des règles de pare-feu d'application Web (WAF) complexes avec des dizaines de signatures qui sont compilées à partir des normes Open Source. Chaque signature correspond à une règle de détection des attaques dans l'ensemble de règles. Google propose ces règles en l'état. Elles permettent à Google Cloud Armor d'évaluer des dizaines de signatures de trafic distinctes en se référant à des règles bien nommées, plutôt que de vous obliger à définir chaque signature manuellement. Pour en savoir plus sur les règles WAF préconfigurées, consultez la présentation des règles WAF préconfigurées.

Types de stratégies de sécurité

Les tableaux suivants présentent les types de règles de sécurité et leur utilisation. Une coche () indique que le type de stratégie de sécurité est compatible avec la fonctionnalité.

Règles de sécurité à l'échelle mondiale

	Règle de sécurité de backend		Règle de sécurité périphérique
Type d'interface	Équilibreur de charge d'application externe global Équilibreur de charge d'application classique	Équilibreur de charge réseau proxy externe global Équilibreur de charge réseau proxy classique	Équilibreur de charge d'application externe global Équilibreur de charge d'application classique
Point de rattachement (ressource protégée)	Service backend	Service backend	Service de backend Bucket de backend
Actions de la stratégie	Autoriser Refuser Redirection (`GOOGLE_RECAPTCHA` et `EXTERNAL_302`) Limiter Exclusion basée sur le débit	Autoriser Deny Limitation Exclusion basée sur le débit	Autoriser Refuser
Adresse IP source
Géographie source
ASN source
Limitation du débit
Empreintes JA3
Gestion des robots
Filtrage de couche 7
WAF
Adaptive Protection
Renseignement sur les menaces
Security Command Center
Cloud Monitoring
Demander la journalisation

Règles de sécurité à l'échelle régionale

	Stratégie de sécurité backend régionale	Règle de sécurité en périphérie du réseau
Type d'interface	Équilibreur de charge d'application externe régional	Équilibreur de charge réseau passthrough externe Transfert de protocole VM dotées d'adresses IP publiques
Point de rattachement (ressource protégée)	Service de backend (régional)	Pool cible Instance cible Service de backend (régional) Instance
Actions de la règle	Autoriser Deny Limitation Exclusion basée sur le débit	Autoriser Refuser
Adresse IP source
Géographie source
ASN source
Limitation du débit
Empreintes JA3
Gestion des robots
Filtrage de couche 7
WAF
Adaptive Protection
Renseignement sur les menaces
Filtrage des décalages d'octets
Security Command Center
Cloud Monitoring
Demander la journalisation

Règles de sécurité de backend

Les règles de sécurité de backend sont utilisées avec les services de backend exposés par les types d'équilibreurs de charge suivants:

Équilibreur de charge d'application externe global
Équilibreur de charge d'application classique
Équilibreur de charge d'application externe régional
Équilibreur de charge réseau proxy externe global
Équilibreur de charge réseau proxy classique

Ils permettent de filtrer les requêtes et de protéger les services de backend qui référencent des groupes d'instances ou des groupes de points de terminaison du réseau (NEG), y compris les NEG Internet, zonaux, hybrides et sans serveur. Tous les équilibreurs de charge ne sont pas compatibles avec tous les types de NEG. Pour en savoir plus sur les NEG compatibles avec votre équilibreur de charge, consultez la page Présentation des groupes de points de terminaison du réseau.

Lorsque vous utilisez des équilibreurs de charge réseau proxy externes globaux ou des équilibreurs de charge réseau proxy classiques, Google Cloud Armor n'applique l'action deny de la règle de stratégie de sécurité que sur les nouvelles demandes de connexion. L'action deny met fin à la connexion TCP. En outre, si vous fournissez un code d'état avec votre action deny, ce code d'état est ignoré.

Les règles de sécurité de backend comportent l'option facultative type CLOUD_ARMOR. Si vous ne définissez pas l'option type, la valeur par défaut est CLOUD_ARMOR.

Stratégies de sécurité Edge

Les règles de sécurité périphérique permettent aux utilisateurs de configurer des règles de filtrage et de contrôle d'accès pour le contenu stocké en cache. Cela inclut les points de terminaison tels que les services de backend compatibles avec Cloud CDN et les buckets Cloud Storage. Les règles de sécurité périphérique prennent en charge le filtrage basé sur un sous-ensemble de paramètres par rapport aux règles de sécurité de backend. Vous ne pouvez pas définir une règle de sécurité périphérique en tant que règle de backend. Les règles de sécurité Edge sont compatibles avec les points de terminaison suivants:

Équilibreur de charge d'application externe global
Équilibreur de charge d'application classique

Les règles de sécurité périphérique peuvent être configurées pour filtrer les requêtes avant qu'elles ne soient diffusées à partir du cache de Google. Les stratégies de sécurité périphérique sont déployées et appliquées près du périmètre le plus externe du réseau de Google, en amont de l'emplacement du cache Cloud CDN. Les règles de sécurité périphérique peuvent coexister avec les règles de sécurité de backend pour fournir deux couches de protection. Elles peuvent être appliquées simultanément à un service de backend, quelles que soient les ressources vers lesquelles pointe ce service (par exemple, des groupes d'instances ou des groupes de points de terminaison réseau). Seules les règles de sécurité périphériques peuvent être appliquées aux buckets de backend.

Lorsque les règles de sécurité périphérique et les règles de sécurité de backend sont associées au même service de backend, les règles de sécurité de backend ne sont appliquées que pour les requêtes de défaut de cache qui ont été autorisées par les règles de sécurité périphériques.

Les stratégies de sécurité Edge sont évaluées et appliquées avant Identity-Aware Proxy (IAP). Une requête bloquée par une règle de sécurité périphérique est refusée avant qu'IAP n'évalue l'identité du demandeur. Le blocage d'une requête avec une stratégie de sécurité périphérique empêche IAP de diffuser une page de connexion ou de tenter d'authentifier l'utilisateur.

Les règles de sécurité périphériques utilisent la valeur de l'option type CLOUD_ARMOR_EDGE.

Règles de sécurité en périphérie du réseau

Les stratégies de sécurité en périphérie du réseau vous permettent de configurer des règles pour bloquer le trafic à la périphérie du réseau de Google. L'application de règles de sécurité en périphérie du réseau n'utilise pas les ressources de VM ou d'hôte, ce qui permet d'éviter que le trafic à volume élevé n'épuise les ressources de la charge de travail cible ou ne provoque un déni de service. Vous pouvez configurer des stratégies de sécurité en périphérie du réseau pour les ressources suivantes:

Équilibreurs de charge réseau externes à stratégie directe
Transfert de protocole
VM dotées d'adresses IP publiques

Les règles de sécurité en périphérie du réseau acceptent le filtrage en fonction de certains des mêmes paramètres que les règles de sécurité de backend. Elles constituent le seul type de stratégie de sécurité compatible avec le filtrage du décalage des octets. Consultez le tableau Types de règles de sécurité pour obtenir la liste complète des paramètres disponibles.

Les règles de sécurité en périphérie du réseau utilisent l'option type CLOUD_ARMOR_NETWORK. Pour configurer des règles de sécurité en périphérie du réseau, vous devez d'abord configurer la protection DDoS avancée du réseau dans la région où vous souhaitez créer ces règles. Pour en savoir plus sur la protection DDoS avancée du réseau, consultez Configurer la protection DDoS avancée du réseau.

Ordre d'évaluation des règles

L'ordre d'évaluation des règles est déterminé par la priorité de la règle, du nombre le plus faible au nombre le plus élevé. La règle ayant la valeur numérique la plus basse est attribuée à la priorité logique la plus élevée et est évaluée avant les règles ayant des priorités logiques inférieures. La valeur numérique minimale de priorité est 0. La priorité d'une règle diminue lorsque le numéro qui lui est attribué augmente (1, 2, 3, N+1). Vous ne pouvez pas configurer deux règles (ou plus) ayant la même priorité. La priorité de chaque règle doit être définie sur une valeur numérique comprise entre 0 et 2147483646 (inclus). La valeur de priorité 2147483647, également appelée INT-MAX, est réservée à la règle par défaut.

Vous pouvez définir des suites de numéros de priorité discontinues. Cela permet d'ajouter ou de supprimer certaines règles par la suite sans affecter les autres règles. Par exemple, 1, 2, 3, 4, 5, 9, 12, 16 est une série valide de valeurs numériques de priorité auxquelles vous pourrez ajouter des règles numérotées de 6 à 8, 10 à 11 et 13 à 15. Il n'est pas nécessaire de modifier les règles existantes, à l'exception de l'ordre d'exécution.

En règle générale, la règle de priorité la plus élevée qui correspond à la requête est appliquée. Cependant, il existe une exception lorsque les requêtes HTTP POST sont évaluées à l'aide de règles préconfigurées utilisant evaluatePreconfiguredExpr(). Cette exception est la suivante.

Pour les requêtes HTTP POST, Google Cloud Armor reçoit l'en-tête de la requête avant le corps (charge utile). Étant donné que Google Cloud Armor reçoit d'abord les informations d'en-tête, il évalue les règles qui correspondent à l'en-tête, mais il ne met en correspondance aucune règle préconfigurée sur le corps. S'il existe plusieurs règles basées sur l'en-tête, Google Cloud Armor les évalue en fonction de leur priorité, comme prévu. Notez que les actions redirect et l'insertion d'actions d'en-tête personnalisées ne fonctionnent que pendant la phase de traitement des en-têtes. L'action redirect, en cas de correspondance établie pendant la phase suivante de traitement du corps, est traduite en une action deny. L'action d'en-tête de requête personnalisée, en cas de correspondance établie pendant la phase de traitement du corps, ne prendra pas effet.

Une fois que Google Cloud Armor a reçu le corps HTTP POST, il évalue les règles qui s'appliquent à la fois à l'en-tête et au corps de la requête. Par conséquent, il est possible que les règles de priorité inférieure qui autorisent l'en-tête d'une requête soient mises en correspondance avant que celles ayant une priorité plus élevée bloquent le corps de la requête. Dans de tels cas, il est possible que la partie d'en-tête HTTP de la requête soit envoyée au service de backend cible, mais que le corps POST contenant du contenu potentiellement malveillant soit bloqué. Google Cloud Armor inspecte les 8 premiers kilo-octets du corps POST. Pour en savoir plus sur cette limitation, consultez la section Limites d'inspection du corps POST.

L'expression evaluatePreconfiguredExpr() pour les règles préconfigurées est la seule expression évaluée par rapport au corps de la requête. Toutes les autres expressions sont évaluées uniquement par rapport à l'en-tête de la requête. Parmi les types de requêtes HTTP avec un corps de requête, Google Cloud Armor ne traite que les requêtes POST. L'inspection est limitée aux huit premiers kilo-octets du corps POST et est décodée comme les paramètres de requête d'URL. Google Cloud Armor peut analyser et appliquer des règles WAF préconfigurées pour les corps POST au format JSON (Content-Type = "application/json"). Toutefois, Google Cloud Armor n'est pas compatible avec les autres décodeurs HTTP basés sur le type ou l'encodage de contenu, tels que XML, Gzip ou UTF-16.

Examples

Dans l'exemple suivant, les règles 1, 2 et 3 sont évaluées dans cet ordre pour les champs d'en-tête IP et HTTP. Toutefois, si une adresse IP IP 9.9.9.1 lance une attaque XSS dans le corps d'une requête HTTP POST, seul le corps est bloqué (par la règle 2). L'en-tête HTTP est transmis au backend (par la règle 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

Dans l'exemple suivant, la stratégie autorise l'adresse IP IP 9.9.9.1 sans analyser les attaques XSS :

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Règle par défaut

Chaque stratégie de sécurité Google Cloud Armor contient une règle par défaut qui est mise en correspondance si aucune des règles de priorité supérieure n'est mise en correspondance ou s'il n'y a pas d'autres règles dans la stratégie. Une priorité de 2147483647 (INT-MAX) est automatiquement attribuée à la règle par défaut, laquelle est toujours présente dans la stratégie de sécurité.

Vous ne pouvez pas supprimer la règle par défaut, mais vous pouvez la modifier. L'action par défaut pour la règle par défaut est deny, mais vous pouvez remplacer l'action par allow.

Empreinte numérique

Chaque stratégie de sécurité Google Cloud Armor possède un champ fingerprint. Ce champ contient un hachage des contenus stockés dans la règle. Lorsque vous créez une règle, ne renseignez pas la valeur de ce champ. Si vous indiquez une valeur, elle est ignorée. Toutefois, lorsque vous mettez à jour une stratégie de sécurité, vous devez spécifier l'empreinte actuelle, que vous obtenez lorsque vous exportez ou décrivez la stratégie (à l'aide de EXPORT ou de DESCRIBE, respectivement).

L'empreinte vous empêche de remplacer la mise à jour d'un autre utilisateur. Si l'empreinte que vous fournissez est obsolète, cela signifie que la stratégie de sécurité a été mise à jour depuis la dernière récupération de l'empreinte. Pour vérifier les différences et récupérer la dernière empreinte numérique, exécutez la commande DESCRIBE.

Langage des règles et moteur d'application

Le langage des règles et le moteur d'application offrent les possibilités suivantes :

Possibilité d'écrire des expressions de règles personnalisées qui peuvent correspondre à divers attributs des couches 3 à 7 des requêtes entrantes. Google Cloud Armor fournit un langage flexible pour écrire des conditions de correspondance personnalisées.
Possibilité de combiner jusqu'à cinq sous-expressions dans une même règle.
Blocage ou autorisation de requêtes en fonction du code de région de la requête entrante. Les codes de région sont basés sur les codes ISO 3166-1 alpha-2. Les codes de région correspondent parfois à des pays spécifiques, mais certains englobent un pays et ses zones associées. Par exemple, le code US comprend tous les États des États-Unis, un district et six zones périphériques.

Types de règle

Google Cloud Armor dispose des types de règles suivants.

Règles de liste d'autorisation et de blocage d'adresses IP

Vous pouvez créer des règles de liste d'autorisation et de blocage d'adresses IP dans une stratégie de sécurité. Voici quelques exemples :

Une liste de blocage d'adresses IP/de CIDR permet d'empêcher une plage CIDR ou une adresse IP source d'accéder aux équilibreurs de charge compatibles.
Une liste d'autorisation d'adresses IP/de CIDR vous permet d'autoriser une adresse IP source ou une plage CIDR à accéder aux équilibreurs de charge compatibles.
Les adresses IPv4 et IPv6 sont acceptées dans les règles de liste d'autorisation et de blocage.
Les règles de refus peuvent renvoyer une réponse HTTP 403 (Non autorisée), 404 (Accès refusé) ou 502 (Passerelle incorrecte).
Les règles d'action de dépassement de capacité peuvent renvoyer un code HTTP 429 (trop de requêtes).

Règles géographiques sources

Vous pouvez autoriser ou refuser les requêtes provenant de zones géographiques sélectionnées définies par le code pays Unicode.

Google Cloud Armor utilise notre propre base de données de géolocalisation IP pour identifier l'emplacement géographique des requêtes. La base de données est mise à jour régulièrement. Bien que nous ne puissions pas garantir de fréquence de mise à jour spécifique, les mappages utilisés par Google Cloud Armor sont mis à jour environ une fois par semaine pendant les opérations normales.

Les mises à jour doivent être propagées sur l'infrastructure de Google à l'échelle mondiale. Le processus de déploiement se déroule progressivement, généralement sur plusieurs jours, dans plusieurs zones et régions sur lesquelles Google Cloud Armor est déployé. En raison de ce processus de déploiement progressif, il est possible que les requêtes provenant de la même adresse IP source soient traitées de manière incohérente lors d'un déploiement lorsque le mappage de géolocalisation est modifié pour l'adresse IP source.

Règles WAF préconfigurées

Google Cloud Armor fournit une liste complète des règles WAF préconfigurées basées sur l'ensemble de règles de base ModSecurity Core (CRS) pour vous aider à détecter les éléments suivants :

Attaques par injection SQL
Attaques par script intersites
Attaques par inclusion de fichiers locaux
Attaques par inclusion de fichiers distants
Attaques par exécution de code à distance
Attaques par application de méthodes
Attaques par détection du scanner
Attaques de protocole
Attaques par injection PHP
Attaques par réparation de session
Attaques Java
Attaques NodeJS

Pour en savoir plus, consultez la présentation des règles WAF préconfigurées de Google Cloud Armor.

Règles de gestion des robots

Vous pouvez utiliser des règles de gestion des robots pour effectuer les opérations suivantes :

Rediriger les requêtes d'évaluation de reCAPTCHA Enterprise avec des questions manuelles facultatives
Évaluer les jetons reCAPTCHA Enterprise associés à une requête et appliquer l'action configurée en fonction des attributs de jeton
Rediriger les requêtes vers l'URL alternative configurée avec une réponse 302
Insérer des en-têtes personnalisés dans les requêtes avant de les transmettre par proxy à vos backends

Pour en savoir plus sur la gestion des robots, consultez la présentation de la gestion des robots.

Règles préconfigurées pour les listes d'adresses IP nommées

Les règles préconfigurées pour les listes d'adresses IP nommées permettent d'effectuer les opérations suivantes :

Intégrer les listes d'adresses IP nommées des fournisseurs tiers à Google Cloud Armor
Simplifier la maintenance des plages d'adresses IP autorisées ou bloquées
Synchroniser quotidiennement les listes des fournisseurs tiers
Augmenter la capacité de configuration des adresses IP et des plages dans les stratégies de sécurité, car les listes d'adresses IP nommées ne sont pas soumises à des limites concernant le nombre d'adresses IP par règle

Règles de limitation du débit

Vous pouvez utiliser des règles de limitation du débit pour effectuer les opérations suivantes :

Limiter le nombre de requêtes par client en fonction d'un seuil que vous configurez.
Bannir temporairement les clients qui dépassent un seuil de requêtes que vous avez défini pour une période donnée.

Lorsque vous utilisez la limitation du débit avec des équilibreurs de charge réseau proxy externes globaux ou des équilibreurs de charge réseau proxy classiques, les restrictions suivantes s'appliquent:

Google Cloud Armor applique uniquement des actions de limitation du débit telles que la limitation ou le bannissement aux nouvelles requêtes de connexion des clients.
Seuls les types de clés ALL et IP sont acceptés.
Si vous essayez d'utiliser le type de clé HTTP-HEADER ou HTTP-COOKIE avec des équilibreurs de charge TCP/SSL, le type de clé est interprété en tant que ALL, et XFF-IP est interprété en tant que IP.

Pour en savoir plus sur la limitation du débit et son fonctionnement, consultez la page Présentation de la limitation du débit.

Mode aperçu

Vous pouvez prévisualiser les effets d'une règle sans l'appliquer. En mode aperçu, les actions sont consignées dans Cloud Monitoring. Vous pouvez choisir d'afficher un aperçu des règles individuelles d'une stratégie de sécurité ou de chaque règle dans la stratégie. Les frais standards par requête vous sont facturés pour les règles en mode aperçu.

Vous pouvez activer le mode d'aperçu pour une règle en utilisant Google Cloud CLI et de l'option --preview de gcloud compute security-policies rules update.

Pour désactiver le mode Aperçu, utilisez l'option --no-preview, qui n'est pas documentée actuellement. Vous pouvez également utiliser Google Cloud Console.

Si une requête déclenche un aperçu, Google Cloud Armor continue d'évaluer d'autres règles jusqu'à ce qu'il trouve une correspondance. La règle correspondante et la règle de prévisualisation sont disponibles dans les journaux.

Réponses d'erreur personnalisées

Lorsque vous utilisez un équilibreur de charge d'application externe global, vous pouvez configurer des réponses d'erreur personnalisées pour les codes d'état HTTP correspondant aux erreurs générées par les équilibreurs de charge ou les instances backend. En outre, vous pouvez configurer des codes d'erreur personnalisés pour le trafic refusé par Google Cloud Armor en configurant des pages de réponse personnalisées pour les mêmes codes d'erreur des séries 4xx ou 5xx que ceux utilisés par vos règles de stratégie de sécurité existantes.

Pour en savoir plus sur les réponses d'erreur personnalisées, consultez la présentation des réponses d'erreur personnalisées. Pour connaître les étapes de configuration, consultez la section Configurer des réponses d'erreur personnalisées.

Journalisation

Google Cloud Armor offre une journalisation complète et vous permet de définir le niveau de verbosité de votre journalisation. Pour en savoir plus sur la journalisation, consultez la section Utiliser la journalisation des requêtes.

Pour afficher les journaux Google Cloud Armor, consultez la section Afficher les journaux.

Journalisation des requêtes de l'équilibreur de charge d'application externe

Chaque requête HTTP(S) évaluée par rapport à une stratégie de sécurité Google Cloud Armor est enregistrée via Cloud Logging. Les journaux fournissent des détails tels que le nom de la stratégie de sécurité appliquée, la règle de correspondance et si la règle a été appliquée. La journalisation des requêtes pour les nouvelles ressources de service de backend est désactivée par défaut. Pour vous assurer que les requêtes Google Cloud Armor sont consignées, vous devez activer la journalisation HTTP(S) pour chaque service de backend protégé par une stratégie de sécurité.

Pour en savoir plus, consultez la page Journalisation et surveillance de l'équilibreur de charge d'application externe.

Journalisation des requêtes de l'équilibreur de charge réseau proxy externe

Vous pouvez configurer la journalisation pour les équilibreurs de charge réseau proxy externes à l'aide des commandes Google Cloud CLI, comme indiqué dans la section Journalisation et surveillance de l'équilibrage de charge proxy TCP/SSL. Vous ne pouvez pas activer la journalisation pour les équilibreurs de charge réseau proxy externes à l'aide de la console Google Cloud.

Quand utiliser la journalisation détaillée ?

Vous ne saurez peut-être pas pourquoi une règle WAF préconfigurée a été déclenchée par une requête particulière. Les journaux d'événements par défaut de Google Cloud Armor contiennent la règle déclenchée, ainsi que la sous-signature. Toutefois, vous devrez peut-être identifier les détails de la requête entrante ayant déclenché la règle à des fins de dépannage, de validation ou d'ajustement des règles.

Vous pouvez ajuster le niveau de détail enregistré dans vos journaux. Nous vous recommandons d'activer la journalisation détaillée uniquement lorsque vous créez, modifiez ou dépannez une stratégie. Si vous activez la journalisation détaillée, elle s'applique aux règles en mode aperçu ainsi qu'aux règles actives (non prévisualisées) lors des opérations standards.

Pour en savoir plus sur la journalisation détaillée, consultez la section Journalisation détaillée.

Analyse du contenu du corps de la requête POST

Par défaut, Google Cloud Armor évalue le contenu complet d'un corps POST en tant que chaîne uniforme (sous réserve des limites liées à la taille du corps) par rapport aux signatures de vos règles WAF préconfigurées. Pour les requêtes contenant un autre encodage tel que JSON, les composants structurels du message (non spécifiés par l'utilisateur) peuvent déclencher des correspondances avec les signatures WAF préconfigurées. Pour éviter le bruit et réduire le risque de faux positifs, nous vous recommandons de configurer Google Cloud Armor pour activer l'analyse alternative pour tout type de contenu compatible si vos charges de travail protégées:

Diffuser des API REST
Utiliser GraphQL
Recevoir toutes les requêtes dont le contenu est encodé au format JSON

Pour en savoir plus sur les règles WAF préconfigurées, consultez la section Appliquer l'analyse JSON aux valeurs d'en-tête Content-Type personnalisées.

Pour en savoir plus, consultez la page Journalisation et surveillance de l'équilibreur de charge d'application externe global.

Limites

Les sections suivantes détaillent les limites des stratégies de sécurité.

Limite d'inspection du corps POST

L'expression evaluatePreconfiguredExpr() pour les règles préconfigurées est la seule expression que Google Cloud Armor évalue par rapport au corps de la requête. Parmi les types de requêtes HTTP ayant un corps de requête, Google Cloud Armor ne traite que les requêtes POST.

L'inspection est limitée aux 8 premiers Ko du corps POST, qui sont décodés comme les paramètres de requête d'URL. Le reste du corps POST peut contenir du code malveillant, ce que votre application peut accepter. Pour réduire le risque lié aux corps POST dont la taille dépasse 8 Ko, consultez le guide de dépannage.

Google Cloud Armor peut analyser et appliquer des règles WAF préconfigurées pour les corps POST par défaut encodés en URL et au format JSON (Content-Type = "application/json"). Dans ce cas, les règles sont appliquées indépendamment aux noms et aux valeurs décodés dans les données. Pour les autres types de contenu et types d'encodage, Google Cloud Armor ne décode pas les données, mais applique les règles préconfigurées sur les données brutes.

Gestion des connexions WebSocket

Les équilibreurs de charge d'application externes globaux sont compatibles avec le protocole WebSocket. Les canaux WebSocket sont initiés à partir de requêtes HTTP(S). Google Cloud Armor peut empêcher l'établissement d'un canal WebSocket, par exemple si une liste de blocage d'adresses IP bloque l'adresse IP d'origine. Cependant, les transactions ultérieures dans le canal ne sont pas conformes au protocole HTTP, et Google Cloud Armor n'évalue aucun message après la première requête.