Google Cloud Armor y reCAPTCHA proporcionan herramientas para ayudarte a evaluar y reaccionar ante solicitudes entrantes que podrían venir 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 del sitio de reCAPTCHA WAF. 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 del 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 del sitio de reCAPTCHA WAF 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 a los usuarios finales que pasen el desafío manual de reCAPTCHA mediante el redireccionamiento 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 sobre el riesgo de que la solicitud se origine en 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, de sesión o ambos de reCAPTCHA. 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 se admiten en 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 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 publicar verificaciones 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 reCAPTCHA JavaScript 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 aprueba 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 venza la cookie.
- De lo contrario, reCAPTCHA no emitirá una cookie de exención.
En este ejemplo, solo Maya aprueba la evaluación de reCAPTCHA y recibe una cookie de exención, lo que obtiene 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 ella. Para obtener más información, consulta Crea una clave de sitio de desafío del WAF de reCAPTCHA.
Si no creas ni asocias una clave de sitio, reCAPTCHA usará 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.
Aplicar la evaluación de reCAPTCHA
Cuando hay un token de reCAPTCHA adjunto 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 ocurre en el perímetro de la red de Google, por lo que los backends 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 token muestran una puntuación para cada solicitud según las interacciones con tu sitio o app. 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 que leas la documentación de reCAPTCHA para fundamentar 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 quieres usar, debes implementar reCAPTCHA para que el token se adjunte 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 las reglas de la política de seguridad y evaluar los tokens de reCAPTCHA que se adjuntan a 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 en el token mediante la comparación de la clave de reCAPTCHA en el token con las claves de reCAPTCHA asociadas a la regla. Google Cloud Armor considera no válido un token con una clave de reCAPTCHA desconocida. Para obtener más información, consulta Aplica la evaluación sin inconvenientes de reCAPTCHA.
En la siguiente imagen, se muestra el flujo de aplicación de tokens 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 un procesamiento posterior alternativo, como la entrega de un honey pot, o para un análisis y 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 valor personalizado con el mismo nombre que uno de los encabezados personalizados para el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico, 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 de evaluación de reCAPTCHA o una URL diferente cuando la cantidad de solicitudes supere el umbral configurado. Además, puedes identificar clientes para el límite de frecuencia en función de las cookies o los tokens de exención de reCAPTCHA, para limitar las solicitudes o bloquear a los clientes que reutilizan o abusan de la misma cookie o token a una frecuencia que supere el umbral configurado por el usuario.
Límite de 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 muestra cómo identificar una cookie o un token 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 utilizas tokens de acción o 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 similares de políticas de seguridad 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 superior a un umbral
predefinido diferente (por ejemplo,
0.5), redirecciona la solicitud de 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 no supere el umbral definido. - Regla 4: Rechaza la solicitud.
Puedes configurar reglas similares de políticas de seguridad para aplicar la evaluación de tokens de sesión de reCAPTCHA con verificaciones manuales.
Si no ajustas las reglas de límite de frecuencia, Google Cloud Armor
no impone límites en la cantidad de usos para cada cookie de exención de reCAPTCHA,
token de acción y token de sesión. 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