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

Les règles de sécurité de Google Cloud Armor protègent votre application en fournissant un filtrage de couche 7 et en nettoyant les requêtes entrantes des 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 de 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 uniquement pour les services de backend derrière un équilibreur de charge HTTP(S) externe. L'équilibreur de charge peut être en niveau Premium ou Standard.

Les backends du service de backend peuvent être des instances de machines virtuelles (VM) dans un groupe d'instances, des groupes de points de terminaison du réseau zonaux (NEG zonaux) ou des groupes de points de terminaison du réseau Internet (NEG Internet). Lorsque vous utilisez Google Cloud Armor pour protéger un déploiement hybride ou une architecture multicloud, les backends doivent être des NEG Internet ou des NEG hybrides pour la connectivité lorsque vous utilisez Traffic Director dans un environnement multirégional ou sur site. 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, consultez la page Contrôles d'entrée.

Sécurité périphérique avec les stratégies de sécurité Google Cloud Armor

L'équilibrage de charge HTTP(S) 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 HTTP(S) 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. Au 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 ou de bloquer l'accès à votre équilibreur de charge HTTP(S) externe à 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 HTTP(S) externes, du réseau Google et des centres de données Google.

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

Conditions requises

Voici les exigences liées aux stratégies de sécurité Google Cloud Armor :

  • L'équilibreur de charge doit être un équilibreur de charge HTTP(S) externe.
  • Le schéma d'équilibrage de charge du service de backend doit être EXTERNAL.
  • Le protocole du service de backend doit être l'un des protocoles suivants : HTTP, HTTPS ou HTTP/2.

À 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 blocage 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 sécurité, Google Cloud Armor autorise ou refuse la requête, selon que cette règle est une règle d'autorisation ou une règle de refus.

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 principales 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 HTTP(S) externes qui se trouvent dans l'un des niveaux de service réseau suivants :

    • Niveau Premium
    • Niveau Standard
  • Vous pouvez utiliser des stratégies de sécurité avec GKE et le contrôleur d'entrée par défaut.

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.

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

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 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 autorisée, mais vous pouvez la modifier pour la refuser.

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 :

  • Écriture d'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.

  • Combinaison de plusieurs 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ègles

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 HTTP(S) externes.

  • Une liste d'autorisation d'adresses IP/de CIDR permet d'autoriser une plage CIDR ou une adresse IP source à accéder aux équilibreurs de charge HTTP(S) externes.

  • Les adresses IPv4 et IPv6 sont acceptées dans les règles de liste d'autorisation et de blocage.

  • Les règles d'adresse IP peuvent bloquer ou autoriser des CIDR ou des adresses IP sources individuels. Les adresses source IPv4 et IPv6 sont toutes acceptées. Cependant, les adresses IPv6 ne doivent pas comporter de masques de sous-réseau au-delà de /64.

  • Les règles de refus peuvent renvoyer une réponse HTTP 403 (Non autorisée), 404 (Accès refusé) ou 502 (Passerelle incorrecte).

Règles préconfigurées pour les attaques XSS, SQLi, LSI, RFI et RCE

Vous pouvez utiliser des règles préconfigurées pour limiter les attaques suivantes :

  • Script intersites (XSS)
  • Attaques par injection SQL (SQLI)
  • Attaques par inclusion de fichiers locaux (LFI)
  • Attaques par inclusion de fichiers distants (RFI)
  • Attaques par exécution de code à distance (RCE)

Ces règles sont basées sur l'ensemble de règles de base OWASP Modsecurity version 3.0.2.

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

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.

Vous pouvez activer le mode Aperçu pour une règle à l'aide de l'outil de ligne de commande gcloud 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 Cloud Console.

Logging

Le nom de la stratégie de sécurité Google Cloud Armor, la priorité de règle correspondante, l'action associée et des informations connexes sont enregistrés pour les requêtes HTTP(S) adressées à votre équilibreur de charge HTTP(S) externe. Pour enregistrer les informations de journalisation Google Cloud Armor, vous devez activer la journalisation des requêtes HTTP(S).

Journalisation des requêtes d'équilibrage de charge HTTP(S)

Chaque requête HTTP(S) est journalisé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 plus d'informations, consultez la section Journalisation pour la liste d'autorisation/de blocage d'adresses IP.

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

Limites

  • Une liste d'autorisation/de blocage d'adresses IP pour l'équilibrage de charge HTTP(S) n'est pas compatible avec les buckets de backend Cloud Storage.

  • Les stratégies de sécurité sont appliquées uniquement pour les défauts de cache (miss) CDN. Le contenu est diffusé à partir du cache, même si une règle d'une stratégie de sécurité aurait refusé la requête.

Gestion des connexions WebSocket

L'équilibrage de charge HTTP(S) externe est compatible 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.

Étape suivante