Google Cloud Armor y reCAPTCHA proporcionan herramientas que te ayudan a evaluar y actuar sobre las solicitudes entrantes que podrían ser 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 según la configuración de las claves de sitios del WAF de reCAPTCHA. Luego, emite un token encriptado con atributos que representan el riesgo asociado. Google Cloud Armor descifra este token en línea, sin una solicitud o respuesta adicional al servicio de reCAPTCHA. Según los atributos del token, Google Cloud Armor te deja permitir, denegar, limitar la frecuencia o redireccionar las solicitudes entrantes. Para obtener más información, consulta la descripción general de la integración de Google Cloud Armor y reCAPTCHA.
La administración de bots de Google Cloud Armor incluye las siguientes capacidades integradas.
Desafío manual (página de desafío de reCAPTCHA)
- Debes configurar una regla de política de seguridad para redireccionar una solicitud de evaluación de reCAPTCHA.
- Puedes crear tu propia clave de sitio del WAF de reCAPTCHA y asociarla con tu política de seguridad. Te recomendamos que lo hagas. Para obtener más información, consulta Implementa un desafío de reCAPTCHA.
- Solo puedes permitir usuarios finales que aprueben el desafío manual de reCAPTCHA mediante la redirección de usuarios finales para la evaluación de reCAPTCHA.
Aplica la evaluación sin inconvenientes de reCAPTCHA
- Puedes realizar diferentes acciones en las solicitudes entrantes según la evaluación de reCAPTCHA del riesgo que se origina en la solicitud desde un bot. Puedes escribir reglas de políticas de seguridad para evaluar y filtrar el tráfico según la puntuación del token y otros atributos del token.
- Debes implementar tokens de acción o de sesión de reCAPTCHA, o ambos. Los tokens de acción de reCAPTCHA son compatibles con aplicaciones que se ejecutan en sitios web, iOS y Android. Los tokens de sesión de reCAPTCHA solo son compatibles con sitios web. Para obtener más información sobre los tokens de reCAPTCHA, consulta Tokens de acción de reCAPTCHA y Tokens de sesión de reCAPTCHA.
- Debes 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 el WAF con la regla de tu política de seguridad.
La administración de bots de Google Cloud Armor también incluye las siguientes capacidades.
- Redireccionamiento (302)
- Puedes redireccionar las solicitudes a la URL alternativa configurada si configuras Google Cloud Armor para que entregue una respuesta HTTP 302 al cliente.
- Decora la solicitud
- Puedes insertar encabezados personalizados en las solicitudes y valores estáticos en esos encabezados antes de enviar una solicitud a tus backends mediante un proxy.
Casos de uso
En esta sección, se describe cómo puedes usar las capacidades de administración de bots de Google Cloud Armor para mitigar el riesgo de bots y controlar el acceso desde clientes automatizados.
Usa un desafío manual para distinguir entre usuarios legítimos y clientes automatizados
Puedes redireccionar una solicitud a reCAPTCHA para evaluar al cliente final y entregar desafíos manuales si es necesario, sin ninguna implementación adicional de reCAPTCHA. Cuando los usuarios humanos comparten la misma firma (como las rutas de URL u otra firma L7) como un bot o un sistema abusivo, esta acción les proporciona una forma de demostrar que son humanos. Solo los usuarios que aprueban la evaluación pueden obtener acceso a tu servicio.
En el siguiente diagrama, se muestra cómo un desafío manual distingue si una solicitud proviene de un cliente humano o de un cliente automatizado:
Supongamos que el usuario Maya y un bot están navegando por la página de acceso (/login.html) de tu sitio. Para permitir que Maya acceda sin otorgar acceso al bot, puedes configurar una regla de política de seguridad con la expresión de coincidencia avanzada request.path.matches("/login.html"), con una acción redirect de tipo GOOGLE_RECAPTCHA. La experiencia del usuario de extremo a extremo es la siguiente:
- Un usuario final visita tu sitio por primera vez.
- Google Cloud Armor evalúa la solicitud y determina que se debe redireccionar a reCAPTCHA.
- reCAPTCHA responde con una página HTML con el código JavaScript de reCAPTCHA incorporado.
- Cuando la respuesta se renderiza, el JavaScript incorporado se ejecuta para evaluar al usuario y entrega desafíos manuales si es necesario.
- Si el usuario pasa 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 la cookie venza.
- De lo contrario, reCAPTCHA no emite una cookie de exención.
En este ejemplo, solo Maya pasa la evaluación de reCAPTCHA y recibe una cookie de exención para obtener acceso a tu sitio.
Cuando uses desafíos manuales, te recomendamos crear tu propia clave de sitio del WAF de reCAPTCHA y asociarla con la política de seguridad. Esto te permite ver las métricas de reCAPTCHA asociadas con la clave del sitio y entrenar un modelo de seguridad específico para la clave del sitio. Para obtener más información, consulta Crea una clave de sitio de desafío del WAF de reCAPTCHA.
Si no creas y asocias una clave de sitio, reCAPTCHA usa una clave de sitio administrada por Google durante la evaluación. No puedes ver las métricas de reCAPTCHA asociadas con claves de sitio que no te pertenecen, incluidas las claves de sitio administradas por Google.
Aplica la evaluación de reCAPTCHA
Cuando hay un token de reCAPTCHA conectado a una solicitud entrante, Google 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 Google Cloud Armor se realiza en el perímetro de la red de Google, por lo que los backends no participan en la desencriptación del token.
Tokens de reCAPTCHA
reCAPTCHA emite dos tipos de tokens: tokens de acción y tokens de sesión. Ambos tipos de token muestran una puntuación para cada solicitud según las interacciones con tu sitio o aplicación. Ambos tipos de tokens contienen atributos, incluida una puntuación que representa el riesgo asociado con el usuario. También contienen información sobre la clave de reCAPTCHA que usaste cuando se generó el token.
Antes de configurar las reglas de la política de seguridad, debes decidir si usas tokens de acción, tokens de sesión o ambos. Te recomendamos leer la documentación de reCAPTCHA para informar tu decisión. Para obtener más información, consulta la comparación de casos de uso de reCAPTCHA.
Después de determinar qué tipo de token deseas usar, implementa reCAPTCHA para que el token se conecte con una solicitud. Para obtener información sobre la implementación de tokens en reCAPTCHA, consulta las siguientes páginas:
- Aplicaciones web
- Aplicaciones para dispositivos móviles
Por último, usa el lenguaje de reglas de Google Cloud Armor para configurar reglas de políticas de seguridad a fin de evaluar los tokens de reCAPTCHA que se adjuntan con la solicitud. Para evitar el robo de tokens, te recomendamos que asocies tus claves de reCAPTCHA con las reglas de tu política de seguridad. Cuando asocias claves de reCAPTCHA con una regla de política de seguridad, Google Cloud Armor realiza una validación adicional del token comparando la clave de reCAPTCHA en el token con las claves de reCAPTCHA asociadas con la regla. Google Cloud Armor considera que un token con una clave de reCAPTCHA desconocida es no válido. Para obtener más información, consulta Aplica la evaluación sin inconvenientes de reCAPTCHA.
En la siguiente figura, se muestra el flujo de aplicación del token de reCAPTCHA.
Redireccionamiento (respuesta 302)
Puedes usar una acción de redireccionamiento basada en URL para redireccionar solicitudes de forma externa a un extremo diferente. Proporcionas un destino de redireccionamiento en forma de una URL, y Google Cloud Armor redirecciona la solicitud mediante la entrega de una respuesta HTTP 302 al cliente.
Decora la solicitud
Google Cloud Armor puede insertar encabezados de solicitud personalizados con valores estáticos definidos por el usuario antes de enviar las solicitudes a tu aplicación mediante proxy. Esta opción te permite etiquetar solicitudes sospechosas para el procesamiento posterior alternativo, como entregar un honey-pot, o para un análisis y una supervisión adicionales. Ten en cuenta que este parámetro de acción debe agregarse a una acción allow existente.
Encabezados personalizados
Si configuraste Google Cloud Armor para insertar un encabezado o un valor personalizado con el mismo nombre de encabezado que uno de los encabezados personalizados para el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico, entonces el balanceador de cargas reemplazará el valor del encabezado. Para obtener más información, consulta Crea encabezados personalizados en servicios de backend.
Además, si eliges un nombre de encabezado que ya existe en la solicitud, incluidos los encabezados HTTP estándar, el valor original en ese encabezado se reemplazará por el valor definido por el usuario proporcionado a la regla de Google Cloud Armor.
Integra con el límite de frecuencia
Las reglas de límite de frecuencia de Google Cloud Armor son compatibles con las capacidades de administración de bots. Por ejemplo, puedes redireccionar una solicitud para la evaluación de reCAPTCHA o redireccionar a una URL diferente cuando la cantidad de solicitudes supera el umbral configurado. Además, puedes identificar clientes para límites de frecuencia basados en cookies o tokens de exención de reCAPTCHA a fin de limitar las solicitudes o bloquear a los clientes que reutilizan o abusan del mismo token o cookie a una frecuencia que excede el umbral configurado por el usuario.
Limita la frecuencia de cookies o tokens de exención de reCAPTCHA
Por seguridad, recomendamos que configures las reglas de límite de frecuencia para evitar el abuso de tokens a través de varios usos por cookie de exención, token de sesión o token de acción de reCAPTCHA único. En la siguiente tabla, se ilustra cómo puedes identificar un token o cookie de exención de reCAPTCHA como la clave en una regla de límite de frecuencia.
| Recurso | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| Cookie de exención | HTTP-COOKIE |
recaptcha-ca-e |
| Token de acción | HTTP-HEADER |
X-Recaptcha-Token |
| Token de sesión | HTTP-COOKIE |
recaptcha-ca-t |
Puedes limitar las solicitudes o bloquear los clientes que dependan del mismo token o cookie de exención y que excedan el umbral configurado. Para obtener más información sobre los parámetros de límite de frecuencia, consulta Aplica el límite de frecuencia.
Ejemplos de límite de frecuencia
Primero, supongamos que solo usas desafíos manuales en URL seleccionadas (/login.html, por ejemplo) en tu sitio. Para lograrlo, configura las reglas de políticas de seguridad de la siguiente manera:
- Regla 1: Si hay una cookie de exención válida adjunta a la solicitud y la cantidad de usos de la cookie de exención está por debajo del umbral definido, permite la solicitud.
- Regla 2: Redirecciona la solicitud para la evaluación de reCAPTCHA.
En segundo lugar, supongamos que solo usas tokens de acción o tokens de sesión en tu sitio.
Por ejemplo, puedes usar tokens de acción para proteger acciones de usuarios de alto perfil, como /login.html. Para esto, realiza acciones basadas en la puntuación del token de acción de la siguiente manera:
- Regla 1: Cuando la puntuación del token de acción es mayor que un umbral predefinido (
0.8, por ejemplo), permite la solicitud si la cantidad de usos del token de acción es menor que tu umbral definido. - Regla 2: Rechaza la solicitud.
Puedes configurar reglas de políticas 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 tokens de sesión con desafíos manuales en URL seleccionadas (como /login.html) en tu sitio y deseas realizar acciones según la puntuación del token de acción. Además, quieres darle al usuario una segunda oportunidad mediante la resolución de desafíos 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 es mayor que un umbral predefinido (
0.8, por ejemplo), permite la solicitud si la cantidad de usos del token de acción es menor que tu umbral definido. - Reglas 2 y 3: Cuando la puntuación del token de acción es mayor que un umbral predefinido diferente (
0.5, por ejemplo), redirecciona la solicitud para la evaluación de reCAPTCHA, a menos que haya una cookie de exención válida adjunta a la solicitud y la cantidad de usos de la cookie de exención esté por debajo del umbral definido. - Regla 4: Rechaza la solicitud.
Puedes configurar reglas de políticas de seguridad similares para aplicar la evaluación de tokens de sesión de reCAPTCHA con desafíos manuales.
Si no ajustas las reglas de límite de frecuencia, Google Cloud Armor no impone un límite a la cantidad de usos para cada token de acción, token de sesión y cookie de exención de reCAPTCHA. Para los tokens de acción, recomendamos usar un umbral bajo (por ejemplo, 1) y un intervalo de tiempo alto (por ejemplo, 30 minutos, ya que los tokens de acción son válidos durante 30 minutos). Te recomendamos calcular el umbral en función de las estadísticas de tráfico.
¿Qué sigue?
- Configura la administración de bots
- Consulta la referencia del lenguaje de reglas
- Ver registros
- Solucionar problemas