Información general sobre la gestión de bots de Cloud Armor

Google Cloud Armor y reCAPTCHA ofrecen herramientas para evaluar y tomar medidas en relación con las solicitudes entrantes que puedan proceder de clientes automatizados.

reCAPTCHA usa técnicas avanzadas de análisis de riesgos para distinguir entre usuarios humanos y clientes automatizados. reCAPTCHA evalúa al usuario en función de la configuración de las claves de sitio de reCAPTCHA WAF. A continuación, emite un token cifrado con atributos que representan el riesgo asociado. Cloud Armor descifra este token de forma directa, sin necesidad de enviar una solicitud o una respuesta adicional al servicio reCAPTCHA. En función de los atributos del token, Cloud Armor te permite permitir, denegar, limitar la frecuencia o redirigir las solicitudes entrantes. Para obtener más información, consulta la descripción general de la integración de Cloud Armor y reCAPTCHA.

La gestión de bots de Cloud Armor incluye las siguientes funciones integradas.

  • Prueba manual (página de prueba reCAPTCHA)

    • Debes configurar una regla de política de seguridad para redirigir una solicitud de evaluación de reCAPTCHA.
    • Puedes crear tu propia clave de sitio de reCAPTCHA WAF y asociarla a tu política de seguridad. Te recomendamos encarecidamente que lo hagas. Para obtener más información, consulta Implementar una prueba reCAPTCHA.
    • Solo puede permitir que los usuarios finales que superen la prueba manual de reCAPTCHA accedan a su sitio web. Para ello, debe redirigir a los usuarios finales para que se sometan a la evaluación de reCAPTCHA.

  • Aplicar la evaluación sin fricciones de reCAPTCHA

    • Puedes tomar diferentes medidas en las solicitudes entrantes en función de la evaluación de reCAPTCHA sobre el riesgo de que la solicitud proceda de un bot. Puedes escribir reglas de políticas de seguridad para evaluar y filtrar el tráfico en función de la puntuación del token y otros atributos del token.
    • Debes implementar tokens de acción de reCAPTCHA, tokens de sesión o ambos. Los tokens de acción de reCAPTCHA se admiten en aplicaciones que se ejecutan en sitios web, iOS y Android. Los tokens de sesión de reCAPTCHA solo se admiten en sitios web. Para obtener más información sobre los tokens de reCAPTCHA, consulta los tokens de acción de reCAPTCHA y los tokens de sesión de reCAPTCHA.
    • Debe configurar una regla de política de seguridad que evalúe los tokens de reCAPTCHA.
    • Para evitar el robo de tokens, te recomendamos que asocies tus propias claves de reCAPTCHA para WAF con tu regla de política de seguridad.

La gestión de bots de Cloud Armor también incluye las siguientes funciones.

  • Redirección (302)
    • Puedes redirigir las solicitudes a la URL alternativa configurada configurando Cloud Armor para que envíe una respuesta HTTP 302 al cliente.
  • Decorate request
    • Puedes insertar encabezados personalizados en las solicitudes y valores estáticos en esos encabezados antes de proxyar una solicitud a tus back-ends.

Casos prácticos

En esta sección se describe cómo puedes usar las funciones de gestión de bots de Cloud Armor para mitigar el riesgo de los bots y controlar el acceso de los clientes automatizados.

Usar un reto manual para distinguir entre usuarios legítimos y clientes automatizados

Puedes redirigir una solicitud a reCAPTCHA para evaluar al cliente final y mostrar desafíos manuales si es necesario, sin ninguna implementación adicional de reCAPTCHA. Cuando los usuarios humanos comparten la misma firma (como rutas de URL u otras firmas de nivel 7) que un bot o un sistema abusivo, esta acción les permite demostrar que son humanos. Solo los usuarios que superen la evaluación podrán acceder a tu servicio.

En el siguiente diagrama se muestra cómo una verificación manual distingue si una solicitud procede de un usuario o de un cliente automatizado:

Ejemplo de redirección a reCAPTCHA.
Ejemplo de redirección a reCAPTCHA (haz clic para ampliar).

Supongamos que una usuaria llamada Maya y un bot están navegando por la página de inicio de sesión (/login.html) de tu sitio. Para permitir el acceso a Maya sin conceder acceso al bot, puedes configurar una regla de política de seguridad con la expresión de coincidencia avanzada request.path.matches("/login.html") y una acción redirect de tipo GOOGLE_RECAPTCHA. La experiencia de usuario integral es la siguiente:

  1. Un usuario final visita su sitio por primera vez.
  2. Cloud Armor evalúa la solicitud y determina si debe redirigirla a reCAPTCHA.
  3. reCAPTCHA responde con una página HTML con el JavaScript de reCAPTCHA insertado.
  4. Cuando se renderiza la respuesta, se ejecuta el JavaScript insertado para evaluar al usuario y, si es necesario, se le proponen retos manuales.
    • Si el usuario supera la evaluación, reCAPTCHA emite una cookie de exención, que el navegador adjunta automáticamente a cada una de las solicitudes posteriores al mismo sitio hasta que caduca la cookie.
    • De lo contrario, reCAPTCHA no emitirá una cookie de exención.

En este ejemplo, solo Maya supera la evaluación de reCAPTCHA y recibe una cookie de exención, por lo que puede acceder a tu sitio.

Cuando uses retos manuales, te recomendamos que crees tu propia clave de sitio de reCAPTCHA WAF y la asocies a la política de seguridad. De esta forma, puede ver las métricas de reCAPTCHA asociadas a la clave de sitio y entrenar un modelo de seguridad específico para esa clave. Para obtener más información, consulta Crear una clave de sitio de prueba de WAF de reCAPTCHA.

Si no creas ni asocias una clave de sitio, reCAPTCHA usará una clave de sitio gestionada por Google durante la evaluación. No puedes ver las métricas de reCAPTCHA asociadas a claves de sitio que no sean de tu propiedad, incluidas las claves de sitio gestionadas por Google.

Aplicar la evaluación de reCAPTCHA

Cuando se adjunta un token de reCAPTCHA a una solicitud entrante, Cloud Armor evalúa la solicitud y aplica la acción configurada en función de los atributos individuales del token. La evaluación de la política de seguridad de Cloud Armor se realiza en el perímetro de la red de Google, por lo que tus back-ends no participan en el descifrado del token.

Tokens de reCAPTCHA

reCAPTCHA emite dos tipos de tokens: tokens de acción y tokens de sesión. Ambos tipos de tokens devuelven una puntuación para cada solicitud en función de las interacciones con tu sitio o aplicación. Ambos tipos de tokens contienen atributos, incluida una puntuación que representa el riesgo asociado al usuario. También contienen información sobre la clave de reCAPTCHA que has usado cuando se ha generado el token.

Antes de configurar las reglas de la política de seguridad, debes decidir si quieres usar tokens de acción, tokens de sesión o ambos. Te recomendamos que leas la documentación de reCAPTCHA para tomar una decisión. Para obtener más información, consulta la comparativa de casos prácticos de reCAPTCHA.

Una vez que hayas determinado qué tipo de token quieres usar, implementa reCAPTCHA para que el token se adjunte a una solicitud. Para obtener información sobre cómo implementar tokens en reCAPTCHA, consulta las siguientes páginas:

Por último, usa el lenguaje de las reglas de Cloud Armor para configurar reglas de política de seguridad que evalúen los tokens de reCAPTCHA adjuntos a la solicitud. Para evitar el robo de tokens, te recomendamos encarecidamente que asocies tus claves de reCAPTCHA con las reglas de tu política de seguridad. Cuando asocia claves de reCAPTCHA a una regla de política de seguridad, Cloud Armor realiza una validación adicional del token comparando la clave de reCAPTCHA del token con las claves de reCAPTCHA asociadas a la regla. Cloud Armor considera que un token con una clave de reCAPTCHA desconocida no es válido. Para obtener más información, consulta Aplicar la evaluación sin fricciones de reCAPTCHA.

En la siguiente figura se muestra el flujo de aplicación de tokens de reCAPTCHA.

Flujo de aplicación de tokens de reCAPTCHA.
Flujo de aplicación de tokens de reCAPTCHA (haz clic para ampliar).

Redirección (respuesta 302)

Puedes usar una acción de redirección basada en URL para redirigir externamente las solicitudes a otro endpoint. Proporcionas un destino de redirección en forma de URL y Cloud Armor redirige la solicitud enviando una respuesta HTTP 302 al cliente.

Decorate request

Cloud Armor puede insertar encabezados de solicitud personalizados con valores estáticos definidos por el usuario antes de proxy las solicitudes a tu aplicación. Esta opción te permite etiquetar solicitudes sospechosas para que se procesen de forma alternativa, como servir un honeypot o para realizar análisis y monitorizaciones adicionales. Ten en cuenta que este parámetro de acción debe añadirse a una acción allow ya creada.

Cabeceras personalizadas

Si has configurado Cloud Armor para insertar un encabezado o un valor personalizado con el mismo nombre de encabezado que uno de los encabezados personalizados del balanceador de carga de aplicación externo global o del balanceador de carga de aplicación clásico, el balanceador de carga sobrescribirá el valor del encabezado. Para obtener más información, consulta Crear encabezados personalizados en servicios de backend.

Además, si elige un nombre de encabezado que ya exista en la solicitud, incluidos los encabezados HTTP estándar, el valor original de ese encabezado se sobrescribirá con el valor definido por el usuario proporcionado a la regla de Cloud Armor.

Integración con el límite de frecuencia

Las reglas de limitación de frecuencia de Cloud Armor son compatibles con las funciones de gestión de bots. Por ejemplo, puedes redirigir una solicitud de evaluación de reCAPTCHA o redirigir a otra URL cuando el número de solicitudes supere el umbral configurado. Además, puede identificar a los clientes para limitar la frecuencia en función de las cookies o los tokens de exención de reCAPTCHA para limitar las solicitudes o prohibir a los clientes que reutilicen o hagan un uso inadecuado de la misma cookie o token a una frecuencia que supere el umbral configurado por el usuario.

Limitar la frecuencia de cookies o tokens de exención de reCAPTCHA

Por motivos de seguridad, le recomendamos que configure reglas de limitación de frecuencia para evitar el abuso de tokens mediante varios usos por token de acción, token de sesión o cookie de exención únicos de reCAPTCHA. En la siguiente tabla se muestra cómo puede identificar una cookie o un token de exención de reCAPTCHA como clave en una regla de limitación de frecuencia.

Recurso enforce_on_key enforce_on_key_name
Cookie de exención HTTP-COOKIE recaptcha-ca-e
Action-token HTTP-HEADER X-Recaptcha-Token
Token de sesión HTTP-COOKIE recaptcha-ca-t

Puede limitar las solicitudes o prohibir los clientes que dependan de la misma cookie o token de exención y que superen el umbral configurado. Para obtener más información sobre los parámetros de limitación de frecuencia, consulta Aplicar la limitación de frecuencia.

Ejemplos de límite de frecuencia

Primero, supongamos que solo usas retos manuales en URLs seleccionadas (/login.html, por ejemplo) de tu sitio. Para ello, configura las reglas de la política de seguridad de la siguiente manera:

  • Regla 1: Si hay una cookie de exención válida adjunta a la solicitud y el número de usos de la cookie de exención es inferior al umbral que has definido, permite la solicitud.
  • Regla 2: Redirige la solicitud de evaluación de reCAPTCHA.
Fuerza los desafíos manuales.
Habilitar los retos manuales (haz clic en la imagen para ampliarla).

En segundo lugar, supongamos que solo usa tokens de acción o de sesión en su sitio. Por ejemplo, puedes usar tokens de acción para proteger las acciones de usuarios destacados, como /login.html. Para ello, toma medidas en función de la puntuación del token de acción de la siguiente manera:

  • Regla 1: Cuando la puntuación del token de acción sea superior a un umbral predefinido (0.8, por ejemplo), permite la solicitud si el número de usos del token de acción es inferior al umbral que hayas definido.
  • Regla 2: Rechaza la solicitud.
Aplicar la evaluación de tokens de acción de reCAPTCHA.
Aplicar la evaluación de tokens de acción de reCAPTCHA (haz clic para ampliar).

Puedes configurar reglas de política de seguridad similares para aplicar la evaluación de tokens de sesión de reCAPTCHA.

En tercer lugar, supongamos que combinas tokens de acción o de sesión con retos manuales en URLs seleccionadas (como /login.html) de tu sitio y quieres tomar medidas en función de la puntuación del token de acción. Además, quieres dar al usuario una segunda oportunidad para resolver retos si la puntuación no es lo suficientemente satisfactoria. Para ello, configura las reglas de la política de seguridad de la siguiente manera:

  • Regla 1: Cuando la puntuación del token de acción sea superior a un umbral predefinido (0.8, por ejemplo), permite la solicitud si el número de usos del token de acción es inferior al umbral que hayas definido.
  • Reglas 2 y 3: Cuando la puntuación del token de acción es superior a otro umbral predefinido (0.5, por ejemplo), redirige la solicitud de evaluación de reCAPTCHA, a menos que haya una cookie de exención válida adjunta a la solicitud y el número de usos de la cookie de exención sea inferior al umbral definido.
  • Regla 4: Deniega la solicitud.
Aplicar la evaluación de tokens de acción de reCAPTCHA con retos manuales.
Aplicar la evaluación de tokens de acción de reCAPTCHA con pruebas manuales (haz clic para ampliar).

Puedes configurar reglas de política de seguridad similares para aplicar la evaluación de tokens de sesión de reCAPTCHA con retos manuales.

Si no ajustas las reglas de limitación de frecuencia, Cloud Armor no impondrá ningún límite en el número de usos de cada cookie de exención de reCAPTCHA, token de acción y token de sesión. En el caso de los tokens de acción, recomendamos usar un umbral bajo (1, por ejemplo) y un intervalo de tiempo alto (30 minutos, por ejemplo, ya que los tokens de acción son válidos durante 30 minutos). Te recomendamos que derives el umbral a partir de tus estadísticas de tráfico.

Siguientes pasos