Cas d'utilisation courants des stratégies de sécurité

Cette page présente des cas d'utilisation courants des stratégies de sécurité Google Cloud Armor. Les stratégies de sécurité Google Cloud Armor peuvent protéger votre application avec des fonctionnalités telles que les listes d'autorisations d'adresses IP et les listes d'interdiction, ainsi que les règles préconfigurées pour dissuader les attaques Web courantes.

Contrôler l'accès à vos applications et services Web

Cette section décrit plusieurs manières d'utiliser les stratégies de sécurité Google Cloud Armor pour contrôler l'accès à vos applications ou services.

Autoriser l'accès des utilisateurs à des adresses IP spécifiques à l'aide de listes d'autorisations

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 d'application externe global ou un équilibreur de charge d'application classique n'est accessible qu'à 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.

Pour contrôler l'accès à l'équilibreur de charge d'application externe global ou à l'équilibreur de charge d'application classique, 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 autoriser uniquement les utilisateurs de votre organisation dotés d'adresses IP appartenant à une plage d'adresses IP à accéder à l'équilibreur de charge d'application externe global ou à l'équilibreur de charge d'application classique. 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é, ajoutez une règle qui ajoute la plage à la liste blanche en tant que première règle. Cette règle comporte la description allow [RANGE], où [RANGE] est la plage d'adresses IP souhaitée.
3. Remplacez la règle par défaut de la stratégie, qui est une règle d'autorisation, par une règle de blocage. 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. La modification de la règle allow en deny bloque tout le trafic ne provenant pas de la plage de la liste autorisée.
4. Associez cette stratégie au service de backend de l'équilibreur de charge d'application externe global ou de l'équilibreur de charge d'application classique.

Si votre organisation utilise un fournisseur de sécurité tiers pour "nettoyer" le trafic, vous pouvez ajouter son adresse IP à une liste d'autorisation pour vous assurer que seul le trafic nettoyé peut accéder à l'équilibreur de charge d'application externe global ou à l'équilibreur de charge d'application classique et aux backends.

Dans l'illustration suivante, le fournisseur tiers est identifié par la plage CIDR 192.0.2.0/24, et cette plage figure sur une liste d'autorisation.

Bloquer l'accès des utilisateurs d'adresses IP spécifiques avec des listes d'autorisations

Utilisez des listes de blocage 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é.

Règles personnalisées pour effectuer un filtrage en fonction des paramètres de niveaux 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 en savoir plus, consultez la documentation de référence sur le langage des règles personnalisées.

Pour définir des expressions dans une règle, utilisez l'option gcloud --expression ou Google Cloud Console. Pour en savoir plus, consultez la section Créer des stratégies, des règles et des expressions 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 192.0.2.0/24 et à un en-tête user-agent qui contient la chaîne WordPress :

inIpRange(origin.ip, '192.0.2.0/24') && 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 des règles personnalisées.

Protégez votre déploiement contre les attaques des couches d'application et réduisez les dix risques les plus importants d'OWASP

Vous pouvez utiliser Google Cloud Armor pour protéger un serveur d'origine Cloud CDN contre les attaques de couche d'application (L7), telles que les injections SQL (SQLi) et les scripts 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 limiter les risques, procédez comme suit :

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

Vous pouvez également utiliser des règles préconfigurées pour détecter et bloquer les attaques courantes de couches d'application. 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 Google Cloud Console ou l'option gcloud --expression. Pour en savoir plus, consultez la page Créer des stratégies, règles et expressions de sécurité.

Pour en savoir plus 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 des règles personnalisées.

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 192.0.2.1/24 :

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

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

Google Cloud Armor permet d'atténuer les attaques suivantes, qu'elles soient déployées dans Google Cloud, sur site ou chez un fournisseur tiers :

• Injection SQL (SQLi)
• Script intersites (XSS)
• Inclusion de fichiers locaux (LFI)
• Inclusion de fichiers à distance (RFI)
• Exécution de code à distance (RCE)

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 figurant dans la liste Top 10 de l'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 bloquer 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 protéger une charge de travail non hébergée par Google Cloud contre ces attaques à la périphérie du réseau de Google, procédez comme suit :

1. Configurez un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique 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 préconfigurées à 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 à l'aide de Cloud Logging, de Cloud Monitoring et des résultats envoyés à 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 Cloud Logging, Cloud Monitoring et Security Command Center fournissent des informations exploitables pour les applications protégées, quel que soit leur emplacement de déploiement.

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

1. Configurez un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique 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.

En outre, vous pouvez utiliser les stratégies de sécurité périphériques pour protéger le contenu stocké dans le cache. Pour en savoir plus sur les stratégies de sécurité périphériques, consultez la page Présentation des stratégies de sécurité.

Attaques de contournement du cache et Contrôles d'accès de couche 7

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, la règle suivante bloque 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é.

Étape suivante

• Configurer des stratégies de sécurité
• En savoir plus sur le langage des règles personnalisées
• Ajuster les règles WAF