Google Cloud Armor et reCAPTCHA fournissent des outils pour vous aider à évaluer et à traiter les requêtes entrantes pouvant provenir de clients automatisés.
reCAPTCHA utilise des techniques avancées d'analyse des risques pour distinguer les utilisateurs humains des clients automatisés. reCAPTCHA évalue l'utilisateur en fonction de la configuration des clés de site WAF reCAPTCHA. Il émet ensuite un jeton chiffré avec des attributs qui représentent le risque associé. Google Cloud Armor déchiffre ce jeton en ligne, sans requête ni réponse supplémentaire au service reCAPTCHA. En fonction des attributs de jeton, Google Cloud Armor vous permet d'autoriser les requêtes entrantes, de les refuser, d'en limiter le débit ou de les rediriger. Pour en savoir plus, consultez la présentation de l'intégration de Google Cloud Armor et de reCAPTCHA.
La gestion des bots de Google Cloud Armor intègre les fonctionnalités suivantes.
Test manuel (page de test reCAPTCHA)
- Vous devez configurer une règle de stratégie de sécurité pour rediriger une requête d'évaluation reCAPTCHA.
- Vous pouvez créer votre propre clé de site reCAPTCHA WAF et l'associer à votre stratégie de sécurité. Nous vous recommandons vivement de le faire. Pour plus d'informations, consultez la section Mettre en œuvre un test reCAPTCHA.
- Vous ne pouvez autoriser que les utilisateurs finaux qui réussissent le test manuel reCAPTCHA en les redirigeant pour une évaluation reCAPTCHA.
Appliquez une évaluation simplifiée reCAPTCHA
- Vous pouvez effectuer différentes actions sur les requêtes entrantes en fonction de l'évaluation par reCAPTCHA du risque que la requête provient d'un bot. Vous pouvez écrire des règles de stratégie de sécurité pour évaluer et filtrer le trafic en fonction du score de jeton et d'autres attributs de jeton.
- Vous devez implémenter des jetons d'action reCAPTCHA, des jetons de session ou les deux. Les jetons d'action reCAPTCHA sont compatibles avec les applications exécutées sur des sites Web, iOS et Android. Les jetons de session reCAPTCHA ne sont compatibles que sur les sites Web. Pour en savoir plus sur les jetons reCAPTCHA, consultez les sections Jetons d'action reCAPTCHA et Jetons de session reCAPTCHA.
- Vous devez configurer une règle de stratégie de sécurité qui évalue les jetons reCAPTCHA.
- Pour éviter le vol de jetons, nous vous recommandons d'associer vos propres clés reCAPTCHA pour WAF à votre règle de stratégie de sécurité.
La gestion des bots Google Cloud Armor inclut également les fonctionnalités suivantes.
- Redirection (302)
- Vous pouvez rediriger les requêtes vers l'URL alternative que vous avez configurée, en paramétrant Google Cloud Armor pour diffuser une réponse HTTP 302 au client.
- Décorer la requête
- Vous pouvez insérer des en-têtes personnalisés dans les requêtes, et des valeurs statiques dans ces en-têtes, avant d'envoyer par proxy les requêtes vers vos backends.
Cas d'utilisation
Cette section explique comment utiliser les fonctionnalités de gestion des bots de Google Cloud Armor pour limiter les risques liés aux bots et contrôler les accès émanant de clients automatisés.
Utiliser un défi d'authentification manuel pour distinguer les utilisateurs légitimes des clients automatisés
Vous pouvez rediriger une requête vers reCAPTCHA pour évaluer le client final et répondre à des tests manuels si nécessaire, sans aucune implémentation reCAPTCHA supplémentaire. Lorsque des utilisateurs humains partagent la même signature (par exemple des chemins d'URL ou d'autres signatures L7) qu'un bot ou qu'un système défini comme abusif, cette action leur permet de prouver qu'ils sont humains. Seuls les utilisateurs qui réussissent l'évaluation peuvent accéder à votre service.
Le schéma suivant montre comment un défi d'authentification manuel distingue si une requête provient d'un client humain ou automatisé :
Supposons qu'un utilisateur Maya et un bot parcourent tous les deux la page de connexion (/login.html) de votre site. Pour autoriser l'accès à l'utilisateur Maya sans accorder l'accès au bot, vous pouvez configurer une règle de stratégie de sécurité avec l'expression de correspondance avancée request.path.matches("/login.html"), avec une action redirect de typeGOOGLE_RECAPTCHA. Voici comment se déroule l'ensemble de l'expérience utilisateur :
- Un utilisateur final visite votre site pour la première fois.
- Google Cloud Armor évalue la requête et détermine comment la rediriger vers reCAPTCHA.
- reCAPTCHA renvoie une page HTML dans laquelle le code JavaScript reCAPTCHA est intégré.
- Une fois la réponse affichée, le code JavaScript intégré s'exécute afin d'évaluer l'utilisateur, en le soumettant si nécessaire à des questions d'authentification manuelle.
- Si l'utilisateur réussit l'évaluation, reCAPTCHA émet un cookie d'exception, qui est associé automatiquement par le navigateur à chacune des requêtes ultérieures adressées au même site jusqu'à l'expiration du cookie.
- Sinon, reCAPTCHA n'émet pas de cookie d'exception.
Dans cet exemple, seule Maya réussit l'évaluation reCAPTCHA et reçoit un cookie d'exception, ce qui lui permet d'accéder à votre site.
Lorsque vous utilisez des questions d'authentification manuelle, nous vous recommandons de créer votre propre clé de site WAF reCAPTCHA et de l'associer à la stratégie de sécurité. Cela vous permet d'afficher les métriques reCAPTCHA associées à la clé de site et d'entraîner un modèle de sécurité spécifique à cette clé. Pour en savoir plus, consultez la section Créer une clé de site de test WAF reCAPTCHA.
Si vous ne créez et n'associez pas de clé de site, reCAPTCHA utilise une clé de site gérée par Google lors de l'évaluation. Vous ne pouvez pas afficher les métriques reCAPTCHA associées à des clés de site qui ne vous appartiennent pas, y compris les clés de site gérées par Google.
Appliquer une évaluation reCAPTCHA
Lorsqu'un jeton reCAPTCHA est associé à une requête entrante, Google Cloud Armor évalue la requête et applique l'action configurée en fonction des attributs individuels du jeton. L'évaluation des règles de sécurité Google Cloud Armor s'effectue à la périphérie du réseau de Google, de sorte que vos backends ne sont pas impliqués dans le déchiffrement du jeton.
Jetons reCAPTCHA
reCAPTCHA émet deux types de jetons: les jetons d'action et les jetons de session. Les deux types de jetons renvoient un score pour chaque requête en fonction des interactions avec votre site ou votre application. Les deux types de jetons contiennent des attributs, y compris un score qui représente le risque associé à l'utilisateur. Ils contiennent également des informations sur la clé reCAPTCHA que vous avez utilisée lors de la génération du jeton.
Avant de configurer des règles de stratégie de sécurité, vous devez décider si vous allez utiliser des jetons d'action, des jetons de session, ou bien les deux. Nous vous recommandons de lire la documentation reCAPTCHA pour prendre votre décision. Pour en savoir plus, consultez la comparaison des cas d'utilisation de reCAPTCHA.
Après avoir déterminé le type de jeton à utiliser, vous allez implémenter reCAPTCHA pour que le jeton soit associé à une requête. Pour en savoir plus sur l'implémentation de jetons dans reCAPTCHA, consultez les pages suivantes:
- Applications Web
- Applications mobiles
Enfin, utilisez le langage des règles Google Cloud Armor pour configurer les règles de stratégie de sécurité afin d'évaluer les jetons reCAPTCHA associés à la requête. Pour éviter le vol de jetons, nous vous recommandons vivement d'associer vos clés reCAPTCHA à vos règles de stratégie de sécurité. Lorsque vous associez des clés reCAPTCHA à une règle de stratégie de sécurité, Google Cloud Armor effectue une validation supplémentaire sur le jeton en comparant la clé reCAPTCHA du jeton aux clés reCAPTCHA associées à la règle. Google Cloud Armor considère un jeton avec une clé reCAPTCHA inconnue comme non valide. Pour en savoir plus, consultez Appliquer l'évaluation simplifiée reCAPTCHA.
La figure suivante illustre le flux d'application des jetons reCAPTCHA.
Redirection (réponse 302)
Vous pouvez utiliser une action de redirection basée sur l'URL pour rediriger les requêtes en externe vers un point de terminaison différent. Vous fournissez une cible de redirection sous la forme d'une URL, et Google Cloud Armor redirige la requête en envoyant une réponse HTTP 302 au client.
Décorer la requête
Google Cloud Armor peut insérer des en-têtes de requêtes personnalisés avec des valeurs définies par l'utilisateur, avant de transmettre les requêtes par proxy à votre application. Cette option vous permet de taguer les requêtes suspectes pour un traitement alternatif en aval, comme la livraison d'un pot de miel, ou pour une analyse et une surveillance supplémentaires. Notez que ce paramètre d'action doit être ajouté à une action allow existante.
En-têtes personnalisés
Si vous avez configuré Google Cloud Armor pour insérer un en-tête ou une valeur personnalisés ayant le même nom d'en-tête que l'un des en-têtes personnalisés pour l'équilibreur de charge d'application externe global ou l'équilibreur de charge d'application classique, la valeur de l'en-tête est remplacée par l'équilibreur de charge. Pour en savoir plus, consultez la page Créer des en-têtes personnalisés dans les services de backend.
En outre, si vous choisissez un nom d'en-tête déjà présent dans la requête, y compris les en-têtes HTTP standards, la valeur d'origine de cet en-tête est écrasée par la valeur définie par l'utilisateur dans la règle Google Cloud Armor.
Intégrer avec une limitation de débit
Les règles de limitation de débit de Google Cloud Armor sont compatibles avec les fonctionnalités de gestion des bots. Par exemple, vous pouvez rediriger une requête pour une évaluation reCAPTCHA ou rediriger l'utilisateur vers une autre URL lorsque le nombre de requêtes dépasse le seuil configuré. En outre, vous pouvez identifier les clients pour la limitation du débit en fonction de cookies ou de jetons d'exception reCAPTCHA, afin de limiter les requêtes ou d'interdire les clients qui réutilisent ou utilisent le même cookie ou jeton à un débit dépassant le seuil configuré par l'utilisateur.
Cookies ou jetons d'exception reCAPTCHA de limitation du débit
Pour des raisons de sécurité, nous vous recommandons de configurer des règles de limitation de débit pour éviter l'utilisation abusive de jetons, en détectant les cas d'utilisations multiples pour un même jeton d'action, jeton de session ou cookie d'exception reCAPTCHA. Le tableau suivant montre comment identifier un cookie ou un jeton d'exception reCAPTCHA en tant que clé d'une règle de limitation du débit.
| Ressource | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| Cookie d'exception | HTTP-COOKIE |
recaptcha-ca-e |
| Jeton d'action | HTTP-HEADER |
X-Recaptcha-Token |
| Jeton de session | HTTP-COOKIE |
recaptcha-ca-t |
Vous pouvez limiter les requêtes ou exclure les clients qui dépendent du même cookie d'exception ou du même jeton, et qui dépassent le seuil configuré. Pour plus d'informations sur les paramètres de limitation de débit, consultez la section Appliquer la limitation du débit.
Exemples de limitation du débit
Supposons tout d'abord que vous n'utilisiez que des questions d'authentification manuelle sur une sélection d'URL (/login.html, par exemple) de votre site. Pour ce faire, configurez les règles de stratégie de sécurité comme suit :
- Règle 1 : si un cookie d'exception valide est associé à la requête et que le nombre d'utilisations du cookie d'exception est inférieur au seuil défini, alors autoriser la requête.
- Règle 2: Redirigez la requête pour l'évaluation reCAPTCHA.
Ensuite, supposons que vous n'utilisiez que des jetons d'action ou de session sur votre site.
Par exemple, vous pouvez utiliser des jetons d'action pour protéger les actions utilisateur les plus significatives, telles que /login.html. Pour ce faire, engagez des actions en fonction du score du jeton d'action, selon les règles suivantes :
- Règle 1 : lorsque le score du jeton d'action est supérieur à un seuil prédéfini (
0.8, par exemple), autoriser la requête si le nombre d'utilisations du jeton d'action est inférieur au seuil défini. - Règle 2 : refuser la requête.
Vous pouvez configurer des règles de stratégie de sécurité similaires pour appliquer une évaluation des jetons de session reCAPTCHA.
Supposons enfin que vous combiniez des jetons d'action ou des jetons de session avec des questions d'authentification manuelle sur une sélection d'URL (telles que /login.html) et que vous souhaitiez engager des actions en fonction du score du jeton d'action. En outre, vous voulez donner une deuxième chance à l'utilisateur en le soumettant à des questions d'authentification si le score n'est pas satisfaisant. Pour ce faire, configurez les règles de stratégie de sécurité comme suit :
- Règle 1 : lorsque le score du jeton d'action est supérieur à un seuil prédéfini (
0.8, par exemple), autoriser la requête si le nombre d'utilisations du jeton d'action est inférieur au seuil défini. - Règles 2 et 3: lorsque le score du jeton d'action est supérieur à un seuil prédéfini différent (
0.5, par exemple), redirigez la requête d'évaluation reCAPTCHA, sauf si un cookie d'exception valide est associé à la requête et que le nombre d'utilisations du cookie d'exception est inférieur au seuil que vous avez défini. - Règle 4 : refuser la requête.
Vous pouvez configurer des règles de stratégie de sécurité similaires pour appliquer une évaluation reCAPTCHA de jeton de session à l'aide d'authentifications manuelles.
Si vous n'ajustez pas les règles de limitation du débit, Google Cloud Armor n'impose aucune limite au nombre d'utilisations pour chaque cookie d'exception reCAPTCHA, jeton d'action et jeton de session. Pour les jetons d'action, nous vous recommandons d'utiliser un seuil faible (1, par exemple) et un intervalle de temps élevé (30 minutes, par exemple, car les jetons d'action sont valides pendant 30 minutes). Nous vous recommandons de déterminer le seuil en fonction de vos statistiques de trafic.
Étapes suivantes
- Configurer la gestion des bots
- Consulter la documentation de référence sur le langage des règles
- Afficher les journaux
- Dépannage