Google Cloud Armor et reCAPTCHA fournissent des outils pour vous aider à évaluer et à traiter les requêtes entrantes susceptibles de provenir de clients automatisés.
reCAPTCHA utilise des techniques avancées d'analyse des risques pour distinguer entre les utilisateurs humains et les clients automatisés. reCAPTCHA évalue l'utilisateur en fonction de la configuration les clés de site reCAPTCHA WAF. 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 interaction requête/réponse supplémentaire avec le 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 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 vers l'évaluation reCAPTCHA.
- Vous pouvez créer votre propre clé de site reCAPTCHA WAF et l'associer avec 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 défi manuel reCAPTCHA en les redirigeant vers l'évaluation reCAPTCHA.
Appliquer l'évaluation fluide de reCAPTCHA
- Vous pouvez effectuer différentes actions sur les requêtes entrantes en fonction 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 ou de session reCAPTCHA, 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 qu'avec les sites Web. Pour en savoir plus sur les jetons reCAPTCHA, consultez 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 votre propre Clés reCAPTCHA pour WAF avec 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 afin d'évaluer le client final et de le soumettre si nécessaire à des questions d'authentification manuelle, sans aucune intégration supplémentaire de reCAPTCHA. 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 le rediriger vers reCAPTCHA.
- reCAPTCHA répond par une page HTML avec le code JavaScript reCAPTCHA 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 automatiquement associé par le navigateur à chacune des requêtes ultérieurement adressées au même site, jusqu'à l'expiration du cookie.
- Sinon, reCAPTCHA n'émet pas de cookie d'exception.
Dans cet exemple, seul l'utilisateur Maya réussit l'évaluation reCAPTCHA et reçoit un cookie d'exception permettant 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 à la clé de site. 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 l'é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 selon la stratégie de sécurité Google Cloud Armor intervient en périphérie du réseau de Google. Vos backends ne sont donc 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 ont aussi contenant des informations sur la clé reCAPTCHA que vous avez utilisée lorsque le jeton a été généré.
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 de reCAPTCHA pour vous aider à prendre votre décision. Pour plus consultez les Comparaison des cas d'utilisation de reCAPTCHA
Après avoir déterminé le type de jeton à utiliser, vous devez intégrer reCAPTCHA pour que le jeton soit associé à une requête. Pour en savoir plus sur l'implémentation des jetons dans reCAPTCHA, consultez les pages suivantes :
- Applications Web
- Applications mobiles
Enfin, utilisez le langage des règles Google Cloud Armor pour configurer des règles de stratégie de sécurité permettant 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 aux règles de votre 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 du 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 une évaluation reCAPTCHA simple.
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 d'ajouter des tags aux requêtes suspectes, afin de définir l'application d'un autre traitement en aval, par exemple la diffusion d'un honey-pot, ou bien une phase supplémentaire d'analyse et de surveillance. 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é avec 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 d'en-tête est écrasée par l'équilibreur de charge. Pour en savoir plus, consultez la section 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 vers une évaluation reCAPTCHA Enterprise, ou vers une autre URL lorsque le nombre de requêtes dépasse le seuil configuré. En outre, vous pouvez identifier les clients pour les tarifs en se basant sur les cookies ou les jetons d'exemption reCAPTCHA, limiter les demandes ou bannir les clients qui réutilisent ou utilisent le même cookie ou jeton ; à un taux 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é dans un 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 : rediriger la requête vers 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 l'é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 à celui d'un autre jeton prédéfini
(
0.5, par exemple), rediriger la demande pour évaluation reCAPTCHA, sauf s'il existe un cookie d'exception valide joint à la demande et le nombre d'utilisations du cookie d'exemption est en dessous du 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 l'évaluation reCAPTCHA des jetons de session avec des questions d'authentification manuelle.
Si vous n'ajustez pas les règles de limitation du débit,
n'impose aucune limite au nombre d'utilisations de chaque cookie d'exception reCAPTCHA,
"action-token" et "session-token". 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.
Étape suivante
- Configurer la gestion des bots
- Consulter la documentation de référence sur le langage des règles
- Afficher les journaux
- Dépannage