Google Cloud Armor et Google Cloud CDN sont deux services proposés par Google dans le cadre de son offre Cloud qui permettent d'améliorer la sécurité et les performances d'un site ou d'une application web. Dans cet article, nous verrons comment configurer ces deux solutions afin d'optimiser la sécurité et les performances de votre application web. Nous listerons également les fonctionnalités avancées et quelques conseils pour l’optimisation de ces deux outils.

Fondamentaux de Google Cloud CDN

Google Cloud CDN (Content Delivery Network) est un service de diffusion de contenu qui accélère la livraison de votre contenu aux utilisateurs finaux. Il utilise plus de 134 points de présence répartis dans le monde entier pour mettre à disposition vos fichiers statiques (images, vidéos, fichiers CSS, etc.) auprès de vos utilisateurs en utilisant le serveur le plus proche géographiquement. Cela permet de réduire les temps de chargement de votre site web et d'améliorer l'expérience utilisateur. Google Cloud CDN est accessible à tous les utilisateurs de Google HTTP (S) Load Balancer et offre de nombreuses fonctionnalités, telles que HTTP/2 et HTTP/3 basé sur le protocole QUIC de l'IETF (Internet Engineering Task Force), Anycast, TLS version 1.3, logging et monitoring. En outre, il permet de purger le cache instantanément.

Fondamentaux de Google Cloud Armor

Google Cloud Armor est un service de sécurité réseau qui protège contre les attaques de type DDoS (Distributed Denial of Service) et les attaques d'application ciblées. Il utilise des règles de sécurité qui analysent en temps réel le trafic entrant et bloquent les requêtes malveillantes avant qu'elles n'atteignent le service. Google utilise Cloud Armor pour protéger sa propre infrastructure mondiale (Google Search, Gmail et YouTube) contre les attaques de type DDoS. En effet, lors de la plus grosse cyberattaque de l'histoire sur son cloud, Cloud Armor a été capable de détecter cette attaque très tôt grâce à sa fonctionnalité de protection adaptative, qui a agi comme un pare-feu et a permis le déclenchement de mécanismes de protection. Cette attaque a impliqué 46 millions de requêtes par seconde, mais grâce à Cloud Armor, Google a été en mesure de la contrer efficacement.

Quelle architecture ?

Ci-dessous une vision de l’architecture mise en place lors de l’utilisation de Google Cloud Armor et de Google Cloud CDN

Schéma d'architecture avec le traffic des utilisateurs de différentes régions, qui va passer par Cloud CDN, puis les Load Balancers Google, protégés par Cloud Armor, avant d'arriver sur les machines Compute ou le storage au plus proche de la région de l'utilisateur

Les requêtes des utilisateurs sont acheminées à travers le réseau internet vers le Google Front End (GFE) le plus proche du client.

Le GFE est capable de consulter directement le cache du CDN et de répondre directement à l'utilisateur, sans avoir besoin de contacter votre infrastructure. Cela permet une optimisation de l'utilisation de vos ressources cloud.

En revanche, lorsque le contenu demandé par l'utilisateur n'est pas disponible dans le cache, le GFE transfère la requête au load balancer global. Ce dernier transfère ensuite la requête au backend service le plus proche géographiquement de l'utilisateur. Ces backend services peuvent être constitués d'un ou plusieurs des éléments suivants sur Google Cloud : groupes de machines virtuelles, clusters GKE, App Engine, Cloud Run, Cloud Function, bucket GCS, et enfin d'autres cibles en utilisant les Network Endpoint Groups de Google.

Cloud Armor est placé au niveau du load balancer, et va permettre d'analyser le trafic entrant avant d'être renvoyé à vos backends.

Mise en place avec Terraform

L’ensemble du code terraform est disponible sur le dépôt git: https://github.com/TanguyBaudrin/terraform-googlecloud-lb-cloud-armor-cdn

Le dépôt git contient tout le code pour démarrer depuis un projet vide, dans la suite de l’article nous nous concentrerons sur les éléments nécessaires à Cloud Armor et Cloud CDN.

Déploiement du load balancer

Code terraform utilisant le module de load balancer Google

module "gce-lb-http" {
  source               = "GoogleCloudPlatform/lb-http/google"
  version              = "6.3.0"
  name                 = "https"
  
  [...]
  
  backends = {
    this = {
    [...]
    enable_cdn                      = true
    security_policy                 = google_compute_security_policy.this.self_link
    [...]
  }
}

Dans cet exemple, nous utilisons le module terraform officiel de Google qui facilite grandement la mise en place d’un load balancer.

Pour la partie Cloud Armor et Cloud CDN, ce qui nous intéresse ce sont les deux paramètres enable_cdn et security_policy. Le premier permet simplement d’activer Cloud CDN, le second va nous permettre d’activer Cloud Armor en appliquant une règle de security policy.

A noter, les règles Cloud Armor sont liées aux différents backend services, vous permettant d’avoir des règles différentes en fonction de vos différents types de backend. Ou au contraire réutiliser les mêmes règles pour l’ensemble de vos backend services.

Mise en place de Cloud Armor

Pour rappel, Cloud Armor est la solution de Google pour se protéger contre les attaques par déni de service (DDoS) et les attaques d'application ciblées.

Filtrer les requêtes utilisateur par ip “statique”

La configuration de vos règles Cloud Armor utilise la ressource google_compute_security_policy, une seule ressource va vous permettre de configurer l’ensemble des règles à appliquer. Voici un exemple de mise en place d’une règle de blocage sur certaines plages d’ip sur Cloud Armor.

resource "google_compute_security_policy" "this" {
  name = "my-policy"

  rule {
    action   = "deny(403)"
    priority = "1000"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["9.9.9.0/24"]
      }
    }
    description = "Deny access to IPs in 9.9.9.0/24"
  }

  rule {
    action   = "allow"
    priority = "2147483647"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["*"]
      }
    }
    description = "default rule"
  }
}

Dans cet exemple, nous créons deux règles : la première interdit les adresses IP sources dans la plage "9.9.9.0/24" avec une priorité de 1000, et la seconde autorise toutes les adresses IP avec une priorité de 2147483647.

Une valeur de priorité plus petite indique une règle qui sera appliquée en priorité. Dans notre cas, la règle interdisant les adresses IP en "9.9.9.0/24" étant plus "petite", elle sera prioritaire sur l'autorisation de toutes les adresses IP.

Attention, il y a une limitation sur cette fonctionnalité : vous ne pouvez pas déclarer plus de 10 adresses IP pour une seule règle. Si vous souhaitez bloquer un grand nombre d'adresses IP, vous devrez donc les déclarer dans des règles différentes par paquet de 10.

Filtrer des listes d’IP connues comme malveillantes ou inappropriées

Cloud Armor propose une fonctionnalité de "Threat intelligence" qui est incluse dans l'offre Managed Protection Plus et qui vous permet, au lieu de bloquer des listes d'adresses IP manuellement, d'utiliser des listes d'adresses IP maintenues par Google.

Ces adresses IP sont globales et vous n'aurez pas la possibilité d'y ajouter vos propres listes, mais elles comprennent des adresses IP connues dans différentes catégories :

Liste des noeuds de sortie du réseau Tor
Liste des adresses IP reconnues comme étant malveillantes
Liste des robots scanneurs des moteurs de recherche
Liste des adresses IP de proxies de Cloudflare, Fastly, Imperva
Liste des adresses IP des principaux cloud providers, AWS, Azure, Google

Dans notre cas nous allons ajouter à notre code terraform, la liste des ip connues comme étant malveillantes, pour ce faire il suffit d’ajouter une règle à notre security policy

rule {
  action      = "deny(403)"
  priority    = "1001"
  description = "Matches IP addresses known to attack web applications"
  match {
    expr {
      expression = "evaluateThreatIntelligence('iplist-known-malicious-ips')"
    }
  }
  preview = false
}

Dans cet exemple, nous créons une règle avec une priorité 1001 qui bloque les IP qui sont réputées malicieux selon Google.

Filtrer les requêtes identifiées comme malveillantes

Cloud armor propose également un ensemble de règles qui pourront vous protéger des requêtes malveillantes classiques de type injection sql, cve, etc…

La liste est importante, et l’ensemble de ses règles est disponible ici directement dans la documentation de Google : https://cloud.google.com/armor/docs/waf-rules

On pourra noter un exemple qui a fait couler beaucoup d’encre et de sueurs dans les équipes IT, avec la faille log4shell. Sur Cloud Armor, il est rapide et facile de bloquer ces requêtes au niveau du load balancer en activant la règle cve-canary.

Le choix de ces règles va dépendre du type d’application hébergées sur vos services de backend, en effet si votre application est une application Java, les règles ne seront pas les mêmes que s’il s’agit d’une application NodeJS ou PHP.

Dans notre cas,nous souhaitons ajouter une règle de protection de type “Remote code execution”, pour ce faire nous utiliserons la règle rce-v33-stable

rule {
  action      = "deny(403)"
  priority    = "1003"
  description = "Remote code execution requests"
  match {
    expr {
      expression = "evaluatePreconfiguredExpr('rce-v33-stable')"
    }
  }
}

Ces règles peuvent être encore affinées pour extraire certaines données de l’analyse faite par Cloud Armor, si vous constatez de faux positifs vous pourrez ainsi corriger le tir et vous assurer que les requêtes légitimes ne sont pas bloquées.

De même vous pouvez affiner les différentes signatures, pour exclure, ou ajouter des signatures de requêtes qui ne seraient pas disponible de base dans votre règle.

Limiter le nombre de requêtes possibles pour un client

Cloud armor propose également une fonctionnalité de limitation de nombre de requêtes qui permet de réduire plus facilement le trafic vers les ressources backend en fonction du volume de demandes. Permettant ainsi de protéger vos ressources backend d’attaques de type DDoS.

rule {
  action      = "deny(403)"
  priority    = "1002"
  description = "rate-based-ban path '/' (10 rpm throttle 20 rpm ban )"
  match {
    expr {
      expression = "request.path.matches('/')"
    }
  }
  preview = true
  rate_limit_options {
    enforce_on_key = "IP"
    exceed_action  = "deny(429)"
    rate_limit_threshold {
      count        = 10
      interval_sec = 60
    }
    ban_duration_sec = 3600
    ban_threshold {
      count        = 20
      interval_sec = 60
    }
  }
}

Dans cette règle, nous appliquons une limitation de nombre requêtes sur le path “/” en se basant sur l’ip du client. Vous pouvez également définir des règles avec des conditions de correspondance se basant soit sur des listes d'adresses/de plages IP ou des expressions comprenant plusieurs sous-expressions pour mettre en correspondance divers attributs d'une requête entrante tel que le code de la région, le Schéma d'URL HTTP, l’asn ...

Dans cet exemple, si le nombre de requêtes sur un intervalle de 1 min est >= 10 et < 20 on renvoie une réponse 429 (au choix parmi 403, 404, 429 et 502). Sinon si le nombre de requêtes sur un intervalle de 1 min est >= 20 on renvoie une 403 pendant 1h.

⚠️

Attention avec ce genre de règles, vous pouvez bloquer les requêtes provenant de votre réseau d’entreprise qui n’a qu’un nombre limité d’adresses ip internet pour un nombre important d’utilisateurs. Pensez alors à avoir une requète de priorité plus faible autorisant le trafic légitime de ces sources.

Cloud Armor permet de prévisualiser les effets d’une règle avant de l’appliquer avec le mode preview=true. Cela permet de tester la règle et d’éviter de bloquer le trafic légitime.

Le détail de la requête est consigné dans Cloud Logging (il est recommandé d’activer la journalisation détaillée, à l'aide de l'option --log-level=VERBOSE, afin de déterminer pourquoi la règle a été déclenchée)

Gestion des bots

Cloud Armor permet également de protéger vos services de backend pour vous assurer que seuls des utilisateurs humains pourront accéder à vos services.

Ce service dépend de l’utilisation de la solution reCAPTCHA entreprise, qui est un autre produit de la suite de Google. Pour activer ce service en utilisant votre code terraform, voici un exemple d’implémentation:

rule {
  action      = "redirect"
  description = "redirect to recaptcha"
  match {
    expr {
      expression = "request.path.contains('/login')"
    }
  }
  preview  = true
  priority = 1004
  redirectOptions {
    type = "GOOGLE_RECAPTCHA"
  }
}

Dans cet exemple La requête de l'utilisateur dont le chemin est “/login” est redirigée vers reCAPTCHA Enterprise au niveau de la règle Cloud Armor, ensuite reCAPTCHA Enterprise associe un cookie d'exception au navigateur de l'utilisateur qui réussit l'évaluation reCAPTCHA.

Google Cloud Armor autorise l'accès aux requêtes comportant des cookies d'exception valides.

Utiliser l’IA pour filtrer les requêtes avec adaptative protection

Adaptative protection est probablement l’une des fonctions les plus intéressantes à utiliser et à mettre en place pour protéger vos services.

Dans sa version standard, cette fonctionnalité vous enverra des alertes lorsque Google détecte une activité anormale au niveau de vos load balancer.

Dans sa version Plus (cf. Formules Cloud Armor et FinOps), la fonctionnalité va, en plus de détecter les activités anormales, être capable de vous proposer de nouvelles règles de blocage à mettre en place pour bloquer cette activité et éviter qu’elle n’atteigne vos services.

Cloud armor vous détaillera également quelle proportion du trafic anormal sera détectée par cette nouvelle règle, mais aussi une évaluation du trafic légitime bloqué par cette dernière.

Lors de la mise en place d’une de ses règles suggérées par Cloud Armor, l’utilisation de la fonctionnalité de preview décrite précédemment vous permettra d’avoir une mesure pertinente de l’impact sur votre trafic légitime ou non avant de l’activer. Vous pouvez également utiliser la fonctionnalité de limitation de nombre de requêtes afin de ne pas bloquer du trafic légitime.

⚠️

Attention toutefois, par défaut, Google vous propose une règle avec un identifiant sans vous donner le détail de l’implémentation. Si vous souhaitez avoir plus d’informations et de détails sur la règle proposée, il reste possible de faire la demande auprès de Google pour activer cette fonctionnalité.

Tarification Cloud Armor et FinOps

Cloud Armor existe en deux formules qui auront deux méthodes facturations différentes

Dans sa version standard, Cloud Armor est facturé en mode “Pay as you go”, et sera donc facturé à l’usage selon trois critères:

Nombre de requêtes reçues
Nombre de security policy déployées
Nombre de règles déployées

En version plus, Cloud Armor demande un engagement minimum de 1 an, et sera facturé avec un montant mensuel incluant la protection de 100 ressources de backend, les ressources supplémentaires étant facturées en supplément. Vous serez également facturé pour le trafic sortant de vos ressources avec des tarifs dépendant de chacune des ressources. Si le contenu diffusé est utilisé avec Cloud CDN et est considéré comme pouvant être mis en cache, les frais de traitement des données pour Cloud CDN sont appliqués pour ce contenu.

L’offre standard est particulièrement intéressante si vous souhaitez vous lancer dans Cloud Armor, sans avoir de gros besoins, ou si vous n’avez pas de visibilité à long terme sur l’utilisation de Cloud Armor.

En revanche, comme toujours sur le Cloud, surveillez bien les coûts. Si votre adoption de Cloud Armor devient plus importante et que vous multipliez les règles, la formule Plus devient plus intéressante, et vous permettra de bénéficier de l’adaptive protection.

Mise en place de Cloud CDN

Cloud CDN va vous permettre de décharger vos services de certaines réponses pour améliorer la performance réseau.

⚠️

Attention ! L’utilisation combinée de Cloud Armor et de Cloud CDN peut avoir des effets inattendus. Cloud CDN est la première brique qui sera sollicitée pour répondre aux requêtes de vos utilisateurs. Il peut arriver de faire une erreur sur Cloud Armor qui bloquera les accès légitimes à vos services. Dans ce cas la réponse sera mise en cache est servie par Cloud CDN.

Choisir le mode de cache

Lors de la mise en place de Cloud CDN, vous avez la possibilité de choisir parmi 3 modes de cache différents: CACHE_ALL_STATIC, USE_ORIGIN_HEADERS et FORCE_CACHE_ALL. La configuration se fait au niveau de votre service de backend

cdn_policy  {
  cache_mode = "USE_ORIGIN_HEADERS"
  cache_key_policy {
    include_host = true
    include_protocol = true
    include_query_string = true
  }
}

Personnaliser les clefs de cache

Par défaut, les services de backend configurés pour utiliser Cloud CDN incluent tous les composants de l'URI de requête dans des clés de cache pour identifier les entrées de cache. Néanmoins, vous pouvez personnaliser la clé de cache en excluant un ou plusieurs composants (le protocole, l'hôte, la chaîne de requête, en-têtes HTTP, des cookies nommés … )

Autres options de Cloud CDN

Google Cloud CDN offre la possibilité de configurer la mise en cache négative à l’aide de l’option --negative-caching. La mise en cache négative s'applique à des codes d'état spécifiques: 300, 301, 308, 302, 307, 404, 405, 410, 451 et 501.

Google Cloud CDN permet également de diffuser du contenu lorsque le serveur d'origine est inaccessible ou renvoie des erreurs à Cloud CDN à l’aide de l’option --serve-while-stale=SECONDS.

Monitoring

L’activation de Google Cloud Armor n’est qu’une première étape, il est important d’ajuster et d’améliorer en permanence les règles.

Pour surveiller l'état et les volumes de trafic des requêtes (autorisées, bloquées ou pré-visualisées) par stratégie ou par service de backend, Google a mis en place un tableau de bord ‘Network Security Policies’ préconfiguré dans Cloud Monitoring.

Vous pouvez également consulter les logs des security policies à l’aide de cette requête: resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(SecurityPolicyName) dans Cloud Logging et créer vos propre metrics et alertes à partir des logs.

Google fournit également un tableau de bord pour superviser google cloud CDN, disponible dans le repo git monitoring-dashboard-samples

En plus de cela, vous pouvez consulter l'état de succès (hit), de défaut (miss) ou de revalidation de cache d'une requête diffusée par Cloud CDN : à l’aide de ces requêtes:

Succès de cache (hit) : jsonPayload.statusDetails=("response_from_cache" OR "byte_range_caching")
ou

httpRequest.cacheHit=true
httpRequest.cacheValidatedWithOriginServer!=true

Succès de cache (hit) validé avec le serveur d'origine: jsonPayload.statusDetails="response_from_cache_validated"
ou

httpRequest.cacheHit=true
httpRequest.cacheValidatedWithOriginServer=true

Défaut de cache (miss):
jsonPayload.statusDetails="response_sent_by_backend"
ou

httpRequest.cacheHit!=true
httpRequest.cacheLookup=true

Conclusion

Pour résumer, Google Cloud Armor et Google Cloud CDN sont tous les deux des outils puissants permettant d’améliorer considérablement la performance et la sécurité de votre site ou application web. Cloud armor offre une solution de sécurité robuste et personnalisable qui aide à se protéger contre les attaques tout en permettant une surveillance en temps réel pour détecter les menaces potentielles. Cloud CDN, quant à lui, assure une diffusion globale efficace du contenu et des temps de chargement plus rapides. Il est fortement recommandé de les considérer pour tout site ou application web déployés sur Google Cloud.