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 Trusted Cloud by S3NS .

Les règles de sécurité Cloud Armor sont disponibles pour les équilibreurs de charge d'application externes régionaux.

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

• Groupes d'instances
• Tous les types de groupes de points de terminaison du réseau (NEG) compatibles avec votre équilibreur de charge

Lorsque vous utilisez Cloud Armor pour protéger un déploiement hybride ou une architecture multicloud, les backends doivent être des NEG Internet ou des NEG hybrides. Cloud Armor protège également les NEG sans serveur lorsque le trafic est acheminé via un équilibreur de charge. Pour savoir comment acheminer le trafic via votre équilibreur de charge avant qu'il n'atteigne votre NEG sans serveur, consultez Contrôles d'entrée.

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

Les règles de sécurité 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 Trusted 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).

Conditions requises

• Le schéma d'équilibrage de charge du service de backend doit être EXTERNAL_MANAGED.
• Le protocole du service de backend doit être l'un des protocoles suivants : HTTP, HTTPS, HTTP/2, UDP, TCP, SSL ou UNSPECIFIED.

À propos des règles de sécurité Cloud Armor

Les stratégies de sécurité Cloud Armor sont des ensembles de règles qui correspondent aux attributs des réseaux 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é Cloud Armor consiste en une condition de correspondance et une action à entreprendre lorsque cette condition est remplie. Par exemple, une condition peut être que l'adresse IP source du trafic entrant corresponde à 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 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é, 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.

Cloud Armor propose deux catégories de règles de sécurité : les règles de sécurité hiérarchiques et les règles de sécurité au niveau du service. Les stratégies de sécurité hiérarchiques sont associées au niveau de l'organisation, d'un dossier ou d'un projet, tandis que les stratégies de sécurité au niveau du service sont associées à un ou plusieurs services de backend. Pour en savoir plus sur les stratégies de sécurité hiérarchiques, consultez Présentation des stratégies de sécurité hiérarchiques.

Un service de backend peut être associé à deux règles de sécurité au niveau du service en même temps, mais il ne peut pas être associé à deux règles de sécurité de backend ni à deux règles de sécurité de périphérie en même temps. Toutefois, vos services de backend n'ont pas besoin d'être associés aux mêmes règles de sécurité. Pour associer et supprimer des stratégies de sécurité des services et fonctionnalités de backend compatibles, consultez Associer et supprimer des stratégies de sécurité.

Si une stratégie de sécurité 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 le schéma suivant, la stratégie de sécurité Cloud Armor internal-users-policy est associée au service de backend test-network.

• Vous pouvez éventuellement utiliser le protocole QUIC avec les équilibreurs de charge qui utilisent Cloud Armor.

• Vous pouvez utiliser des stratégies de sécurité de backend avec GKE et le contrôleur d'entrée 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 des équilibreurs de charge d'application externes régionaux.

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 d'attaques dans l'ensemble de règles. Google propose ces règles en l'état. Elles permettent à 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 indiquent les types de stratégies de sécurité au niveau du service et ce que vous pouvez en faire. Une coche () indique que le type de stratégie de sécurité est compatible avec la fonctionnalité.

Règles de sécurité de backend

Les stratégies de sécurité de backend ont la valeur CLOUD_ARMOR pour l'option type. Si vous ne définissez pas l'indicateur type, la valeur par défaut est CLOUD_ARMOR.

Règles de sécurité des services internes

Les règles de sécurité des services internes vous permettent de configurer une limitation du débit fairshare avec Cloud Service Mesh. Au lieu d'associer une stratégie de sécurité de service interne à un service ou un bucket de backend, vous l'associez à une stratégie de point de terminaison Cloud Service Mesh. Pour en savoir plus sur les règles de sécurité des services internes, consultez Configurer la limitation du débit avec Cloud Armor dans la documentation Cloud Service Mesh.

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.

Il est possible que les numéros de priorité ne soient pas consécutifs. Ces lacunes vous permettent d'ajouter ou de supprimer des règles ultérieurement 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 avec un corps sont évaluées à l'aide de règles préconfigurées utilisant evaluatePreconfiguredWaf. Cette exception est la suivante :

Pour les requêtes HTTP POST, Cloud Armor reçoit l'en-tête de la requête avant le corps (charge utile). Étant donné que 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, 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 prend pas effet.

Une fois que Cloud Armor a reçu la requête HTTP POST avec un corps, il évalue les règles qui s'appliquent à la fois aux en-têtes 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 contenant du contenu potentiellement malveillant soit bloqué. Cloud Armor inspecte jusqu'aux 64 premiers ko (selon la limite d'inspection configurée de 8 ko, 16 ko, 32 ko, 48 ko ou 64 ko) du corps de la requête. Pour en savoir plus sur cette limitation, consultez la section Limites d'inspection du corps POST et PATCH.

L'expression evaluatePreconfiguredWaf() 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, Cloud Armor ne traite que les requêtes POST et PATCH. L'inspection est limitée à la limite d'inspection configurée, jusqu'aux 64 premiers kilo-octets (8 ko, 16 ko, 32 ko, 48 ko ou 64 ko) du corps de la requête, et est décodée comme les paramètres de requête d'URL. 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, Cloud Armor n'est pas compatible avec les autres décodeurs basés sur le type de contenu HTTP ou l'encodage de contenu, tels que XML, Gzip ou UTF-16.

Exemples

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 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: evaluatePreconfiguredWaf('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: evaluatePreconfiguredWaf('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é 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é 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, 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. Cloud Armor fournit des attributs de langage de règles personnalisées pour écrire des conditions de correspondance personnalisées.

• Combinaison d'un maximum de cinq sous-expressions dans une seule 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

Cloud Armor propose les 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 :

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 :

• Ajouter une adresse IP ou une plage CIDR à une liste de blocage vous permet d'empêcher une adresse IP source ou une plage CIDR d'accéder aux équilibreurs de charge compatibles.

• Ajouter une adresse IP ou une plage CIDR à une liste d'autorisation 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 un code d'état HTTP 403 Unauthorized, 404 Access Denied ou 502 Bad Gateway.

• Les règles d'action de dépassement de capacité peuvent renvoyer un code d'état HTTP 429 Too Many Requests.

Règles de géographie source

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

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 régulièrement mise à jour. Bien que nous ne puissions pas garantir de fréquence de mise à jour spécifique, les mappages utilisés par Cloud Armor sont mis à jour environ une fois par semaine pendant les opérations normales.

Les mappages mis à jour doivent être propagés à l'infrastructure de Google dans le monde entier. Le processus de déploiement se déroule progressivement, généralement sur plusieurs jours, dans plusieurs zones et régions sur lesquelles 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 de l'adresse IP source a changé.

Règles WAF préconfigurées

Cloud Armor fournit une liste complète des règles WAF préconfigurées basées sur l'ensemble de règles de base OWASP (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 la méthode
• 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 Cloud Armor.

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 :

• 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.

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 règles en mode Aperçu vous sont facturées au tarif normal par requête.

Vous pouvez activer le mode Aperçu pour une règle à l'aide de Google Cloud CLI et de l'option --preview de la commande gcloud compute security-policies rules update.

Pour désactiver le mode Aperçu, utilisez l'option --no-preview. Vous pouvez également utiliser la consoleTrusted Cloud .

Si une requête déclenche un aperçu, 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 de backend. Vous pouvez également configurer des codes d'erreur personnalisés pour le trafic que Cloud Armor refuse en configurant des pages de réponse personnalisées pour les mêmes codes d'état de la série 4xx ou 5xx que ceux utilisés par les règles de votre stratégie de sécurité existante.

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

Journalisation

Cloud Armor dispose d'une journalisation étendue et vous permet de définir le niveau de verbosité de votre journalisation. Les journaux Cloud Armor sont générés en fonction de la première règle (priorité la plus élevée) qui correspond à une requête entrante, que la stratégie de sécurité soit en mode Aperçu ou non. Cela signifie qu'aucun journal n'est généré pour les règles ne correspondant pas, ni pour les règles correspondantes de priorité inférieure.

Pour obtenir des informations complètes sur la journalisation, consultez Utiliser la journalisation des requêtes. Pour en savoir plus sur la journalisation détaillée, consultez Journalisation détaillée. Pour afficher les journaux Cloud Armor, consultez Afficher les journaux.

Limites

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

Limite d'inspection du corps POST et PATCH

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

L'inspection est limitée à la limite d'inspection configurée, jusqu'aux 64 premiers ko (8 Ko, 16 Ko, 32 Ko, 48 Ko ou 64 Ko) du corps POST ou PATCH. Pour savoir comment configurer la limite d'inspection du corps de la requête lorsque vous utilisez des règles WAF préconfigurées, consultez Mettre à jour la limite d'inspection pour les règles WAF préconfigurées.

Le reste du corps de la requête peut contenir des charges utiles qui correspondraient à une signature de règle WAF, que votre application pourrait accepter. Pour réduire le risque de corps de requête dont la taille dépasse la limite d'inspection configurée, jusqu'aux 64 premiers ko (8 Ko, 16 Ko, 32 Ko, 48 Ko ou 64 Ko), consultez Réduire les risques liés au corps de requête qui dépasse la limite d'inspection configurée.

Cloud Armor peut analyser et appliquer des règles WAF préconfigurées pour les corps POST et PATCH par défaut encodés en URL et au format JSON (Content-Type = "application/json"), auquel cas les règles sont appliquées indépendamment sur les noms et valeurs décodés dans les données. Pour les autres types de contenu et d'encodage, 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). 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 Cloud Armor n'évalue aucun message après la première requête.

Étapes suivantes

• Configurer les règles de sécurité Cloud Armor
• Résoudre les problèmes liés à Cloud Armor