Présentation des stratégies de sécurité Google Cloud Armor

Présentation

Utilisez les stratégies de sécurité Google Cloud Armor pour protéger vos applications à équilibrage de charge contre les attaques par déni de service distribué (DDoS) et d'autres attaques Web, qu'elles soient déployées sur Google Cloud, dans un déploiement hybride ou dans une architecture multicloud.

Les stratégies de sécurité Google Cloud Armor sont composées de règles qui filtrent le trafic en fonction d'attributs de couche 3, 4 et 7. Par exemple, vous pouvez spécifier des conditions qui correspondent à l'adresse IP, à la plage d'adresses IP, au code de région ou aux en-têtes d'une requête entrante.

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. La protection DDoS est automatiquement fournie pour l'équilibrage de charge HTTP(S), l'équilibrage de charge proxy SSL et l'équilibrage de charge proxy TCP.

Les protocoles HTTP, HTTPS, HTTP/2 et QUIC sont tous compatibles. Pour plus d'informations sur la configuration de Google Cloud Armor sur Google Kubernetes Engine, consultez la page Configurer Google Cloud Armor via un objet Ingress.

Les backends du service de backend peuvent être des machines virtuelles 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.

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

L'équilibrage de charge HTTP(S) Google Cloud est mis en œuvre à la périphérie du réseau Google dans les points de présence de Google à travers le monde. Dans le 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, puis fait l'objet d'un équilibrage de charge sur le réseau mondial de Google vers le 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 ou de refuser 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)

Exigences concernant 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.

Fonctionnalités de Google Cloud Armor

Les stratégies de sécurité de 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 relevant du niveau de service réseau Standard ou Premium.

  • Vous pouvez utiliser les règles de sécurité avec Google Kubernetes Engine et le contrôleur d'entrée par défaut. Pour en savoir plus, consultez la page Configurer Google Cloud Armor.

Stratégies de sécurité pour l'équilibrage de charge HTTP(S)

  • Chaque service de backend d'un équilibreur de charge HTTP(S) externe peut faire référence à une seule règle de sécurité Google Cloud Armor. Vous pouvez utiliser la même stratégie de sécurité avec plusieurs services de backend sur des équilibreurs de charge HTTP(S) externes identiques ou différents.
  • Vous désignez la priorité (ordre d'évaluation) lorsque plusieurs règles sont configurées.

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

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

  • Une liste de refus d'adresses IP/de plages CIDR permet d'empêcher une adresse IP source ou une plage CIDR d'accéder aux équilibreurs de charge HTTP(S) externes.
  • Une liste d'autorisation d'adresses IP/de plages CIDR permet d'autoriser une adresse IP source ou une plage CIDR à 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 refus.
  • Règles d'adresse IP qui bloquent ou autorisent des adresses IP sources ou CIDR 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).

Langage des règles et moteur d'application

  • 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 plusieurs sous-expressions dans une seule règle.
  • Possibilité de refuser ou d'autoriser des 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.

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

  • Atténuez les attaques suivantes à l'aide de règles préconfigurées :
    • 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.1.

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

  • Intègrent des listes d'adresses IP nommées de fournisseurs tiers à Google Cloud Armor
  • Simplifient la gestion des plages d'adresses IP autorisées ou refusées
  • Assurent une synchronisation quotidienne des listes de fournisseurs tiers
  • Augmentent 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 à une limite du 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.

Journalisation

  • 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) vers votre équilibreur de charge HTTP(S) externe. Vous devez activer la journalisation des requêtes HTTP(S) afin d'enregistrer les informations de journalisation Google Cloud Armor.

À 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 que vous définissez pour appliquer des règles de pare-feu de couche d'application protégeant 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 du langage de règles personnalisées de Google Cloud Armor, vous pouvez également créer des conditions personnalisées qui correspondent à divers attributs du trafic entrant, tels que le chemin de l'URL, la méthode de la requête ou les valeurs d'en-tête de requête.

Lorsqu'une condition est remplie, l'action consiste à autoriser ou à refuser le trafic. Par défaut, l'action est automatiquement appliquée. Notez toutefois qu'une option Aperçu est disponible. Lorsque vous définissez l'option d'aperçu sur "true", l'action prévisualisée est journalisée mais pas appliquée.

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é Google Cloud Armor.

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

Si plusieurs règles de transfert pointent vers un service de backend auquel est associée une stratégie de sécurité Google Cloud Armor, les règles de la stratégie sont appliquées pour tout le trafic entrant vers les adresses IP concernées par ces règles de transfert.

Dans l'illustration ci-dessous, 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)

Ordre d'évaluation des règles

L'ordre d'évaluation des règles est déterminé par deux facteurs : la priorité de la règle et le type de règle.

Vous attribuez une priorité aux règles, de la valeur numérique la plus basse à la plus élevée. 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 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, de 10 à 11 et de 13 à 15 ultérieurement sans modifier les règles existantes, à l'exception de leur 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 lors de l'exécution de requêtes HTTP POST via des règles préconfigurées à l'aide de "evaluatePreconfiguredExpr()". L'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 des règles de priorité inférieure qui vérifient l'en-tête d'une requête soient mises en correspondance avant des règles de priorité supérieure qui vérifient le corps de la requête.

Exemple

Dans l'exemple suivant, les règles 1, 2 et 3 sont évaluées dans cet ordre pour les champs d'en-tête HTTP et d'adresse IP. Toutefois, si une adresse IP 9.9.9.1 lance une attaque XSS dans le corps 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 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. La règle par défaut est automatiquement associée à la priorité 2147483647 (INT-MAX) et figure toujours dans la stratégie de sécurité Google Cloud Armor. 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 un refus, mais vous pouvez modifier l'action pour qu'il s'agisse d'une autorisation.

Empreinte

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. Cependant, lorsque vous mettez à jour une stratégie de sécurité Google Cloud Armor, vous devez spécifier l'empreinte actuelle, que vous obtenez lorsque vous exportez ou décrivez la stratégie.

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é Google Cloud Armor a été mise à jour depuis la dernière récupération de l'empreinte. Décrivez la stratégie de sécurité Google Cloud Armor pour rechercher les différences et récupérer la dernière empreinte.

Gestion des connexions WebSocket

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

Stratégies de sécurité Google Cloud Armor pour les règles de pare-feu VPC et d'équilibrage de charge HTTP(S)

Les stratégies de sécurité Google Cloud Armor et les règles de pare-feu VPC ont différentes fonctions.

  • Les stratégies de sécurité Google Cloud Armor offrent une sécurité périphérique et agissent sur le trafic client vers les GFE (Google Front End).
  • Les règles de pare-feu VPC autorisent ou refusent le trafic vers et depuis vos backends. Vous devez créer des règles de pare-feu autorisant le trafic entrant, dont les cibles sont les VM de backend à équilibrage de charge et dont les sources sont des plages d'adresses IP utilisées par des équilibreurs de charge HTTP(S) externes. Ces règles autorisent les GFE et les systèmes de vérification de l'état à communiquer avec vos VM de backend.

Par exemple, supposons que vous souhaitiez n'autoriser que le trafic provenant des plages CIDR 100.1.1.0/24 et 100.1.2.0/24 à accéder à votre équilibreur de charge HTTP(S) externe. Votre objectif est de vous assurer que le trafic ne peut pas atteindre directement les instances backend à équilibrage de charge. En d'autres termes, seul le trafic externe transmis par proxy via l'équilibreur de charge HTTP(S) externe avec une stratégie de sécurité associée doit atteindre les instances.

Utiliser une stratégie de sécurité Google Cloud Armor avec des pare-feu d'entrée pour restreindre l'accès
Utiliser une stratégie de sécurité Google Cloud Armor avec des pare-feu d'entrée pour restreindre l'accès (cliquez pour agrandir)

Dans l'illustration précédente, vous atteignez vos objectifs de sécurité en configurant votre déploiement Google Cloud comme suit :

  1. Créez deux groupes d'instances, un dans la région us-west1 et l'autre dans la région europe-west1.
  2. Déployez des instances d'application backend sur les VM dans les groupes d'instances.
  3. Créez un équilibreur de charge HTTP(S) externe de niveau Premium. Configurez un mappage d'URL simple et un service de backend unique dont les backends sont les deux groupes d'instances que vous avez créés à l'étape précédente. Assurez-vous que la règle de transfert de l'équilibreur de charge utilise l'adresse IP externe 120.1.1.1.
  4. Configurez une stratégie de sécurité Google Cloud Armor qui autorise le trafic provenant des plages CIDR 100.1.1.0/24 et 100.1.2.0/24 et refuse tout autre trafic.
  5. Associez cette stratégie au service de backend de l'équilibreur de charge. Pour obtenir des instructions, consultez la page Configurer des stratégies de sécurité. Les équilibreurs de charge HTTP(S) externes avec des mappages d'URL plus complexes peuvent référencer plusieurs services de backend. Vous pouvez associer la stratégie de sécurité à un ou plusieurs des services de backend, si nécessaire.
  6. Configurez des règles de pare-feu autorisant le trafic entrant pour accepter le trafic provenant de l'équilibreur de charge HTTP(S) externe. Pour plus d'informations, consultez la section Règles de pare-feu.

Stratégies de sécurité Google Cloud Armor pour l'équilibrage de charge HTTP(S) et Identity-Aware Proxy

Identity-Aware Proxy (IAP) vérifie l'identité d'un utilisateur, puis détermine si cet utilisateur doit être autorisé à accéder à une application. L'activation d'IAP pour l'équilibreur de charge HTTP(S) externe doit être effectuée sur les services de backend de l'équilibreur de charge. De même, les stratégies de sécurité périphériques Google Cloud Armor sont associées aux services de backend d'un équilibreur de charge HTTP(S) externe.

Si les stratégies de sécurité Google Cloud Armor et IAP sont toutes deux activées pour un service de backend d'un équilibreur de charge HTTP(S) externe, l'évaluation IAP intervient en premier. Si IAP bloque une requête, Google Cloud Armor ne l'évalue pas. Si IAP authentifie une requête, celle-ci est ensuite évaluée par Google Cloud Armor. La requête est bloquée si une stratégie de sécurité Google Cloud Armor entraîne une décision de refus.

Utiliser des listes d'autorisation et de refus d'adresses IP avec IAP
Utiliser des listes d'autorisation et de refus d'adresses IP avec IAP (cliquez pour agrandir)

Pour plus d'informations sur IAP et les configurations associées, consultez la documentation Identity-Aware Proxy.

Google Cloud Armor avec des déploiements hybrides

Dans un déploiement hybride, un équilibreur de charge Google Cloud a besoin d'accéder à une source de contenu ou une application qui s'exécute en dehors de Google Cloud, par exemple, dans l'infrastructure d'un autre fournisseur cloud. Vous pouvez utiliser Google Cloud Armor pour protéger ce type de déploiements.

Dans le schéma suivant, l'équilibreur de charge comporte deux services de backend. L'un dispose d'un groupe d'instances comme backend. L'autre service de backend dispose d'un NEG Internet comme backend, lequel est associé à une application qui s'exécute dans le centre de données d'un fournisseur tiers.

Google Cloud Armor pour les déploiements hybrides
Google Cloud Armor pour les déploiements hybrides (cliquez pour agrandir)

Lorsque vous associez une stratégie de sécurité Google Cloud Armor au service de backend doté d'un NEG Internet comme backend, Google Cloud Armor inspecte chaque requête L7 qui parvient à l'équilibreur de charge HTTP(S) externe destiné à ce service de backend.

La protection Google Cloud Armor pour les déploiements hybrides est soumise aux mêmes limites que celles qui s'appliquent aux NEG Internet.

Google Cloud Armor avec Cloud CDN

Vous pouvez utiliser Google Cloud Armor avec Cloud CDN pour protéger les serveurs d'origine CDN. Google Cloud Armor garantit que le serveur d'origine CDN est protégé contre les attaques d'applications, atténue les risques répertoriés dans le top 10 OWASP et applique des stratégies de filtrage de couche 7.

Google Cloud Armor applique des stratégies de sécurité pour les services de backend sur lesquels Cloud CDN est activé uniquement pour les défauts de cache (miss), c'est-à-dire pour les requêtes qui manquent ou contournent le cache Cloud CDN.

Lorsqu'une stratégie de sécurité est associée à un service de backend sur lequel Cloud CDN est activé, Google Cloud Armor évalue les requêtes entrantes qui ne peuvent pas être diffusées à partir du cache par rapport à la stratégie de sécurité, afin de déterminer si elles doivent être transférées au serveur d'origine. Si une règle correspond à la requête, l'action configurée dans la règle est effectuée.

Cependant, les stratégies de sécurité associées à un service de backend sur lequel Cloud CDN est activé ne sont pas appliquées pour les succès de cache (hit) Si une requête peut être diffusée à partir du cache, elle est diffusée à tout client valide, quelle que soit l'action définie dans la stratégie de sécurité pour cette requête.

Le schéma suivant montre comment Google Cloud Armor fonctionne avec les origines Cloud CDN.

Utiliser Google Cloud Armor avec Cloud CDN
Utiliser Google Cloud Armor avec Cloud CDN (cliquez pour agrandir)

Utiliser Google Cloud Armor avec des applications sans serveur

Vous pouvez utiliser les règles de sécurité Google Cloud Armor avec un backend NEG sans serveur qui pointe vers un service Cloud Run, App Engine, ou Cloud Functions.

Toutefois, lorsque vous utilisez Google Cloud Armor avec des NEG sans serveur et Cloud Functions, vous devez prendre des mesures spéciales pour contourner un problème de sécurité.

Les utilisateurs disposant de l'URL par défaut d'un service Cloud Functions peuvent contourner l'équilibreur de charge et accéder directement à l'URL du service. Cela permet de contourner les règles de sécurité de Google Cloud Armor. Vous ne pouvez pas désactiver les URL que Google Cloud attribue automatiquement aux services Cloud Functions.

Pour éviter ce risque de sécurité, vous pouvez utiliser internal-and-gclb lorsque vous configurez Cloud Functions, qui n'autorise que le trafic interne et le trafic envoyé à une adresse IP publique exposée par l'équilibreur de charge HTTP(S) externe. Le trafic envoyé à cloudfunctions.net ou à tout autre domaine personnalisé configuré via Cloud Functions est bloqué. Cela empêche les utilisateurs de contourner les contrôles d'accès (tels que les règles de sécurité Google Cloud Armor) configurés via l'équilibreur de charge HTTP(S) externe.

Pour en savoir plus sur les NEG sans serveur, consultez les pages Présentation des groupes de points de terminaison du réseau sans serveur et Configurer des NEG sans serveur.

Cas d'utilisation généraux

Cette section présente plusieurs cas d'utilisation courants pour les stratégies de sécurité Google Cloud Armor.

Cas d'utilisation 1 : Limiter l'accès à l'équilibreur de charge HTTP(S) externe Google Cloud

L'inscription sur une liste d'autorisation d'adresses IP associées à certains utilisateurs est généralement employée lorsqu'un équilibreur de charge HTTP(S) externe est utilisé uniquement par un ensemble spécifique d'utilisateurs. Dans l'exemple suivant, seuls les utilisateurs de votre organisation sont autorisés à accéder aux services situés derrière votre équilibreur de charge. Ces utilisateurs disposent d'adresses IP ou de blocs d'adresses attribués par votre organisation. Vous pouvez placer ces adresses IP ou plages CIDR sur une liste d'autorisation afin que seuls ces utilisateurs aient accès à l'équilibreur de charge.

Restreindre l'accès à l'équilibreur de charge grâce à une liste d'autorisation
Restreindre l'accès à l'équilibreur de charge grâce à une liste d'autorisation (cliquez pour agrandir)

Pour contrôler l'accès à l'équilibreur de charge HTTP(S) externe, configurez une liste d'autorisation avec les adresses IP sources ou les plages CIDR sources à partir desquelles l'accès à votre équilibreur de charge est autorisé. La section suivante décrit plus en détail cette configuration.

Dans cette configuration, vous souhaitez n'autoriser l'accès à l'équilibreur de charge HTTP(S) externe qu'aux utilisateurs de votre organisation qui possèdent des adresses IP comprises dans la plage 203.0.113.0/24. Vous voulez que tout le reste du trafic soit refusé.

Pour créer cette configuration, procédez comme suit :

  1. Créez une stratégie de sécurité Google Cloud Armor.
  2. Dans la stratégie de sécurité Google Cloud Armor, ajoutez une règle qui autorise la plage 203.0.113.0/24 comme première règle. Cette règle a pour description "autoriser 203.0.113.0/24".
  3. Remplacez la valeur de la règle par défaut de la stratégie allow par deny. La règle par défaut régit le trafic qui ne correspond à aucune des règles précédentes. Il s'agit de la dernière règle de la stratégie. Le fait de remplacer la valeur de la règle allow par deny bloque tout le trafic qui ne provient pas de la plage 203.0.113.0/24, qui se trouve sur une liste d'autorisation.
  4. Associez cette stratégie au service de backend de l'équilibreur de charge HTTP(S) externe.

Cas d'utilisation 2 : Bloquer le trafic non autorisé ou malveillant à la périphérie du réseau avec des listes de refus

Utilisez des listes de refus pour créer des stratégies de sécurité Google Cloud Armor qui rejettent le trafic provenant d'une adresse IP ou d'une plage CIDR. Dans l'illustration suivante, la stratégie de sécurité Google Cloud Armor comporte une règle deny qui bloque le trafic provenant de l'adresse IP 198.51.100.1, où un utilisateur malveillant a été identifié.

Restreindre l'accès à l'équilibreur de charge grâce à une liste de refus
Restreindre l'accès à l'équilibreur de charge grâce à une liste de refus (cliquez pour agrandir)

Cas d'utilisation 3 : Autoriser le trafic vers l'équilibreur de charge HTTP(S) externe uniquement à partir d'un fournisseur de sécurité tiers et d'autres utilisateurs figurant sur une liste d'autorisation

Si votre organisation utilise un fournisseur de sécurité tiers pour "nettoyer" le trafic, vous pouvez inscrire son adresse IP sur une liste d'autorisation pour vous assurer que seul le trafic nettoyé pourra accéder à l'équilibreur de charge HTTP(S) externe et aux backends.

Dans l'illustration ci-dessous, le fournisseur tiers est identifié par la plage CIDR 192.0.2.0/24, et cette plage se trouve sur une liste d'autorisation.

Restreindre l'accès à un équilibreur de charge en inscrivant sur une liste d'autorisation le trafic provenant d'un fournisseur de sécurité tiers
Restreindre l'accès à un équilibreur de charge en inscrivant sur une liste d'autorisation le trafic provenant d'un fournisseur de sécurité tiers (cliquez pour agrandir)

Cas d'utilisation 4 : Personnaliser les défenses avec des règles personnalisées qui correspondent aux paramètres des couches 3 à 7

Utilisez le langage de règles personnalisées de Google Cloud Armor pour définir une ou plusieurs expressions dans la condition de correspondance d'une règle. Lorsque Google Cloud Armor reçoit une requête, il l'évalue par rapport à ces expressions. En cas de correspondance, l'action de la règle prend effet, c'est-à-dire refuse ou autorise le trafic entrant.

Les exemples suivants sont des expressions écrites dans l'extension Google Cloud Armor de Common Expression Language (CEL). Pour plus d'informations, consultez la documentation de référence sur le langage de règles personnalisées de Google Cloud Armor.

Pour définir des expressions dans une règle, utilisez l'option gcloud --expression ou Google Cloud Console. Pour plus d'informations, consultez la section Créer une stratégie et des règles de sécurité Google Cloud Armor.

Dans l'exemple suivant, les requêtes provenant de 2001:db8::/32 (comme vos testeurs alpha) dans la région AU correspondent à l'expression suivante :

origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')

L'exemple suivant correspond aux requêtes provenant de 1.2.3.4 et à un en-tête user-agent qui contient la chaîne WordPress :

inIpRange(origin.ip, '1.2.3.4/32') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

Pour obtenir des exemples supplémentaires, consultez la section Exemples d'expressions dans la documentation de référence sur le langage de règles. Pour plus d'informations sur l'ajustement des règles, consultez la page Ajuster les règles WAF Google Cloud Armor.

Cas d'utilisation 5 : Atténuer les attaques de la couche d'application à l'aide de règles préconfigurées

Utilisez des règles préconfigurées pour détecter et bloquer les attaques de couche d'application courantes, telles que XSS et SQLi. Les règles préconfigurées sont des ensembles d'expressions prédéfinis que vous pouvez ajouter à une stratégie de sécurité Google Cloud Armor. Pour ajouter ces ensembles d'expressions à une règle, utilisez l'option gcloud --expression ou Cloud Console. Pour plus d'informations, consultez la section Créer une stratégie et des règles de sécurité Google Cloud Armor.

Pour plus d'informations sur les règles préconfigurées, consultez la section Règles préconfigurées dans la documentation de référence sur le langage de règles.

L'exemple suivant utilise une règle préconfigurée pour atténuer les attaques par script intersites (XSS) :

evaluatePreconfiguredExpr('xss-stable')

L'exemple suivant utilise une règle préconfigurée pour atténuer les attaques par injection SQL (SQLi) :

evaluatePreconfiguredExpr('sqli-stable')

Vous pouvez également combiner des règles préconfigurées avec d'autres expressions. L'exemple suivant utilise une règle préconfigurée pour atténuer les attaques SQLi provenant de la plage d'adresses IP 1.2.3.0/24 :

inIpRange(origin.ip, '1.2.3.0/24') && evaluatePreconfiguredExpr('sqli-stable')

Cas d'utilisation pour les déploiements hybrides

Cette section présente les cas d'utilisation des stratégies de sécurité Google Cloud Armor avec des déploiements hybrides.

Atténuation des risques répertoriés dans le top 10 OWASP pour les charges de travail hybrides

Google Cloud Armor propose des fonctionnalités d'atténuation des risques liés aux attaques par injection SQL (SQLi) et par script intersites (XSS) pour vos applications, qu'elles soient déployées dans Google Cloud, sur site ou chez un fournisseur tiers. Vous pouvez utiliser ces fonctionnalités pour atténuer certains des risques les plus courants concernant la sécurité des applications Web, y compris ceux identifiés dans la liste Top 10 OWASP.

Les règles WAF préconfigurées de Google Cloud Armor peuvent être ajoutées à une stratégie de sécurité pour détecter et refuser les requêtes de couche 7 indésirables contenant des tentatives d'attaques SQLi ou XSS. Google Cloud Armor détecte les requêtes malveillantes et les abandonne à la périphérie de l'infrastructure de Google. Les requêtes ne sont pas transmises par proxy au service de backend, quel que soit l'endroit où le service de backend est déployé.

Pour défendre une charge de travail non hébergée par Google Cloud contre les attaques SQLi ou XSS à la périphérie du réseau de Google, procédez comme suit :

  1. Configurez un équilibreur de charge HTTP(S) externe avec un service de backend doté d'un NEG Internet comme backend.
  2. Créez une stratégie de sécurité Google Cloud Armor.
  3. Ajoutez des règles SQLi et XSS à la stratégie.
  4. Associez la stratégie de sécurité au service de backend que vous avez créé à l'étape 1.
  5. Surveillez l'activité de Google Cloud Armor avec Operations Logging, Operations Monitoring et les résultats envoyés à Cloud Security Command Center.

Défense contre les attaques par DDoS des serveurs d'origine externes Cloud CDN et surveillance de couche 7

Les déploiements Cloud CDN avec un serveur d'origine externe peuvent avoir l'infrastructure périphérique de Google comme interface pour la transmission par proxy, la mise en cache et le filtrage de couche 7 de Google Cloud Armor. À l'aide de NEG Internet, le serveur d'origine peut être situé sur site ou chez un fournisseur d'infrastructure tiers.

Google Cloud Armor et le reste de l'infrastructure périphérique de Google atténuent et suppriment les attaques L3/L4, émettent des alertes en cas d'activités suspectes de couche 7 et se tiennent prêts à refuser les requêtes indésirables de couche 7 à l'aide de règles personnalisées. La journalisation et la télémétrie de Google Cloud Armor via Operations Logging, Operations Monitoring et Cloud Security Command Center fournissent des informations exploitables pour les applications protégées, quel que soit leur emplacement de déploiement.

Pour activer la protection Google Cloud Armor pour les serveurs d'origine externe CDN, procédez comme suit :

  1. Configurez un équilibreur de charge HTTP(S) externe avec un service de backend doté d'un NEG Internet comme backend.
  2. Activez Cloud CDN pour ce service de backend.
  3. Créez une stratégie de sécurité Google Cloud Armor.
  4. Associez la stratégie de sécurité au service de backend que vous avez créé à l'étape 1.
  5. Accédez aux alertes, à la journalisation et à la télémétrie de Google Cloud Armor dans Security Command Center, Cloud Logging et Cloud Monitoring.

Cas d'utilisation avec Cloud CDN

Cette section présente deux cas d'utilisation de Google Cloud Armor avec Cloud CDN.

Cas d'utilisation : atténuation des attaques SQLi et XSS

Vous pouvez utiliser Google Cloud Armor pour protéger un serveur d'origine Cloud CDN contre des risques tels que les attaques par injection SQL (SQLi) et par script intersites (XSS). Le contenu d'un cache est statique et ne présente vraisemblablement pas de risque d'attaque ciblée depuis le Web. Cependant, le serveur d'origine du contenu sous-jacent peut être une application dynamique présentant des failles connues ou potentielles d'applications Web. Vos exigences de sécurité ou de conformité peuvent vous obliger à atténuer ces risques pour empêcher l'exploitation de ces failles depuis Internet visant à attaquer le serveur d'origine.

Pour atténuer les risques :

  1. Créez ou identifiez un service de backend sur lequel CDN est activé.
  2. Créez une stratégie de sécurité Google Cloud Armor.
  3. Créez une ou plusieurs règles dans la stratégie de sécurité pour refuser les attaques XSS et SQLi.
  4. Configurez l'une des cibles de la stratégie de sécurité pour la désigner comme service de backend que vous avez créé ou identifié à l'étape 1.

Cas d'utilisation : contrôles d'accès de couche 7 et attaques par cache busting

Selon l'architecture de l'application, vous pouvez configurer un service de backend de sorte qu'il diffuse les requêtes de diverses URL, y compris le contenu pouvant et ne pouvant pas être mis en cache. Dans de tels scénarios de déploiement, créez des stratégies de sécurité Google Cloud Armor qui refusent le trafic indésirable sur certains chemins de requête, mais autorisent tous les clients à accéder au contenu statique sur un chemin de requête différent.

Dans d'autres situations, même si le contenu est diffusé efficacement à partir du cache, un client malveillant ou défaillant peut générer un volume élevé de requêtes qui entraînent un défaut de cache (miss) et nécessitent que le serveur d'origine sous-jacent extraie ou génère le contenu demandé. Cela peut mettre à rude épreuve les ressources déjà limitées et avoir un impact négatif sur la disponibilité de l'application pour tous les utilisateurs. Vous pouvez créer une stratégie de sécurité Google Cloud Armor pour mettre en correspondance la signature de tous les clients à l'origine du problème et refuser les requêtes avant qu'elles n'atteignent le serveur d'origine et n'affectent les performances.

Pour ce faire, procédez comme suit :

  1. Créez une stratégie de sécurité Google Cloud Armor.
  2. Configurez une règle, par exemple qui refuse l'accès à "/admin" : request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>'.
  3. Associez la stratégie de sécurité de l'étape 1 au service de backend sur lequel Cloud CDN est activé.

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 dans la documentation sur l'équilibrage de charge HTTP(S).

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

Limites

  • La liste de refus/d'autorisation d'adresses IP pour l'équilibrage de charge HTTP(S) n'est pas prise en charge pour les buckets backend Cloud Storage.
  • Google Cloud Armor n'est pas pris en charge avec l'équilibrage de charge HTTP(S) interne.
  • 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.
  • 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 actuellement pas documentée. Vous pouvez également utiliser Cloud Console.

Étape suivante