Descripción general del límite de frecuencia

Google Cloud Armor proporciona protección para tus aplicaciones de Google Cloud contra una variedad de ataques de la capa 3 y la capa 7. Las reglas basadas en tarifas te ayudarán a proteger tus aplicaciones de un gran volumen de solicitudes que llenan tus instancias y bloquean el acceso de los usuarios legítimos.

El límite de frecuencia puede hacer lo siguiente:

• Evitar que un cliente en particular agote los recursos de aplicaciones
• Protege tus instancias de aplicación contra aumentos erráticos e impredecibles en la tasa de solicitudes de los clientes.

Además, cuando un recurso se presenta a un gran volumen de tráfico desde una pequeña cantidad de clientes, puedes evitar que tus otros clientes se vean afectados por grandes aumentos de tráfico de esa pequeña cantidad de clientes, lo que habilita tus recursos para manejar la mayor cantidad de solicitudes posible.

Google Cloud Armor tiene dos tipos de reglas basadas en tarifas:

1. Limitación: Puedes aplicar un límite de solicitud máximo por cliente o en todos los clientes si regulas los clientes individuales a un umbral configurado por el usuario.
2. Bloqueo basado en tarifa: Puedes limitar la cantidad de solicitudes que coinciden con una regla por cliente y, luego, bloquear de forma temporal a esos clientes durante un período configurado si exceden un límite configurado por el usuario.

Google Cloud Armor aplica el umbral de límite de frecuencia a cada backend asociado. Por ejemplo, si tienes dos servicios de backend y configuras una regla de límite de frecuencia con un umbral de 1,000 solicitudes por minuto, cada servicio de backend puede recibir 1,000 solicitudes por minuto antes de que Google Cloud Armor aplique la acción de la regla.

Puedes obtener una vista previa de los efectos de las reglas de límite de frecuencia en una política de seguridad mediante el modo de vista previa y examinando los registros de tu solicitud.

Identifica clientes para el límite de frecuencia

Google Cloud Armor identifica clientes individuales para el límite de frecuencia mediante los siguientes tipos de claves a fin de agregar solicitudes y aplicar límites de frecuencia:

• TODO: Es una clave única para todos los clientes cuyas solicitudes cumplen con la condición de coincidencia de la regla.
• IP: Es una clave única para cada dirección IP de origen de cliente cuyas solicitudes cumplen con la condición de coincidencia de la regla.
• HTTP_HEADER: Una clave única para cada valor de encabezado HTTP único cuyo nombre se configura. El valor de la clave se trunca a los primeros 128 bytes del valor del encabezado. El tipo de clave se establece de forma predeterminada en ALL si no hay tal encabezado, o si intentas usarlo con un balanceador de cargas de red de proxy externo.
• XFF_IP: una clave única para cada dirección IP de origen original del cliente, es decir, la primera dirección IP de la lista de IP especificadas en el encabezado HTTP X-Forwarded-For. El tipo de clave se establece de forma predeterminada en la dirección IP si no hay tal encabezado, si el valor no es una dirección IP válida o si intentas usar este tipo de clave con un balanceador de cargas de red de proxy externo.
• HTTP_COOKIE: Una clave única para cada valor de cookie HTTP cuyo nombre se configura. El valor de la clave se trunca a los primeros 128 bytes del valor del encabezado. El tipo de clave se establece de forma predeterminada en ALL si no hay ninguna cookie presente o si intentas usarlo con un balanceador de cargas de red de proxy externo.
• HTTP_PATH: Es la ruta de URL de la solicitud HTTP. El valor de la clave se trunca a los primeros 128 bytes.
• SNI: La indicación de nombre del servidor en la sesión TLS de la solicitud HTTPS. El valor de la clave se trunca a los primeros 128 bytes. El tipo de clave se establece de forma predeterminada en ALL en una sesión de HTTP.
• REGION_CODE: Es el país o la región donde se origina la solicitud.
• TLS_JA3_FINGERPRINT: Es la huella digital TLS/SSL de JA3 si el cliente se conecta con HTTPS, HTTP/2 o HTTP/3. Si no está disponible, el tipo de clave se establece de forma predeterminada como ALL. Para obtener más información sobre JA3, consulta la referencia del lenguaje de reglas.
• USER_IP: Es la dirección IP del cliente de origen, incluida en los encabezados configurados en userIpRequestHeaders y cuyo valor se completa con un proxy ascendente. Si no hay una configuración userIpRequestHeaders o si no se puede resolver una dirección IP desde ella, el tipo de clave se establece de forma predeterminada como IP. Para obtener más información, consulta la referencia del lenguaje de reglas.

Puedes usar las teclas anteriores de forma individual o aplicar el límite de frecuencia en función de una combinación de hasta tres claves. Puedes usar varias claves HTTP-HEADER o HTTP-COOKIE, y solo una del otro tipo de clave. Para obtener más información, consulta Límite de frecuencia basado en varias claves.

Nota: Los datos clave que limitan la frecuencia se clasifican como datos del servicio, que se procesan como se describe en el Aviso de Privacidad de Google Cloud. Los datos clave que limitan la frecuencia no se tratan como datos del cliente. Si tu carga de trabajo está sujeta a regímenes regulatorios o a otros requisitos de cumplimiento que requieren transparencia de acceso o aprobación de acceso, revisa los tipos de claves cuyos valores pueden contener información sensible.

Tráfico de regulación

La acción throttle en una regla te permite aplicar un umbral de solicitud por cliente a fin de proteger los servicios de backend. Esta regla aplica el umbral para limitar el tráfico de cada cliente que cumpla con las condiciones de coincidencia en la regla. El umbral se configura como una cantidad específica de solicitudes en un intervalo de tiempo determinado.

Por ejemplo, puedes establecer el límite de la solicitud en 2,000 solicitudes en 1,200 segundos (20 minutos). Si un cliente envía 2,500 solicitudes en un período de 1,200 segundos, se limita alrededor del 20% del tráfico del cliente hasta que el volumen de solicitudes permitido sea igual o inferior al umbral establecido.

Establece estos parámetros para controlar la acción:

• rate_limit_threshold: Es la cantidad de solicitudes por cliente permitidas dentro de un intervalo de tiempo especificado. El valor mínimo es 1, y el valor máximo es 10,000.
  • interval_sec: Es la cantidad de segundos en el intervalo de tiempo. El valor debe ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 segundos.
• exceed_action: Cuando una solicitud supera el rate_limit_threshold, Google Cloud Armor aplica el exceed_action configurado. Los valores posibles para exceed_action son los siguientes:
  • deny(status): Se rechaza la solicitud y se muestra el código de error especificado (los valores válidos son 403, 404, 429 y 502). Recomendamos usar el código de respuesta 429 (Too Many Requests).
  • redirect: La solicitud se redirecciona para la evaluación de reCAPTCHA Enterprise o a una URL diferente, según el parámetro exceed_redirect_options.
• exceed_redirect_options: Cuando exceed_action es redirect, usa este parámetro para especificar la acción de redireccionamiento:
  • type: Escribe para la acción de redireccionamiento, ya sea GOOGLE_RECAPTCHA o EXTERNAL_302.
  • target: Es el destino de URL para la acción de redireccionamiento. Solo es aplicable cuando type es EXTERNAL_302.
• conform_action: Esta es la acción que se realiza cuando la cantidad de solicitudes es menor que rate_limit_threshold. Siempre es una acción allow.

Cuando la tasa de tráfico de un cliente es inferior o igual a rate_limit_threshold, las solicitudes siguen el conform_action que siempre es una acción allow. La solicitud permite la política de seguridad y llega a su destino. Cuando la tasa de tráfico de un cliente supera el rate_limit_threshold especificado, Google Cloud Armor aplica exceed_action, que puede ser deny o redirect para las solicitudes para el resto del intervalo del umbral.

Bloquear clientes según los porcentajes de solicitudes

La acción rate_based_ban en una regla te permite aplicar un umbral por cliente para bloquear de forma temporal los clientes que exceden el límite mediante la aplicación de la exceed_action configurada en todas las solicitudes del cliente durante un período configurable. El umbral se configura como una cantidad específica de solicitudes en un intervalo de tiempo determinado. Puedes bloquear el tráfico de forma temporal durante un período configurado por el usuario ('ban_duration_sec'), siempre que el tráfico coincida con la condición de coincidencia especificada y exceda el umbral configurado.

Por ejemplo, puedes establecer el límite de la solicitud en 2,000 solicitudes en 1,200 segundos (20 minutos). Si un cliente envía 2,500 solicitudes en un plazo de 1,200 segundos, Google Cloud Armor aplica el exceed_action al tráfico de ese cliente que supere los 2,000 segundos hasta que hayan transcurrido 1,200 segundos completos y por un tiempo adicional la cantidad de segundos que estableces como período de duración del bloqueo. Si el período de duración del bloqueo se establece en 3600, por ejemplo, el tráfico del cliente se prohibiría durante 3,600 segundos (una hora) después del final del intervalo límite.

Estos parámetros controlan la acción de una regla rate_based_ban:

• rate_limit_threshold: Es la cantidad de solicitudes por cliente permitidas dentro de un intervalo de tiempo especificado. El valor mínimo es 1 y el valor máximo es 10,000.
  • interval_sec: Es la cantidad de segundos en el intervalo de tiempo. El valor debe ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 segundos.
• exceed_action: Cuando una solicitud supera el rate_limit_threshold, Google Cloud Armor aplica el exceed_action configurado. Los valores posibles para exceed_action son los siguientes:
  • deny(status): Se rechaza la solicitud y se muestra el código de error especificado. Los valores válidos para el código de error son 403, 404, 429 y 502. Recomendamos usar el código de respuesta 429 (Too Many Requests).
  • redirect: La solicitud se redirecciona para la evaluación de reCAPTCHA Enterprise o a una URL diferente, según el parámetro exceed_redirect_options.
• exceed_redirect_options: Cuando exceed_action es redirect, usa este parámetro para especificar la acción de redireccionamiento:
  • type: Escribe para la acción de redireccionamiento, ya sea GOOGLE_RECAPTCHA o EXTERNAL_302.
  • target: Es el destino de URL para la acción de redireccionamiento. Solo es aplicable cuando type es EXTERNAL_302.
• conform_action: Esta es la acción que se realiza cuando la cantidad de solicitudes es menor que rate_limit_threshold. Siempre es una acción allow.
• ban_threshold_count: Esta es la cantidad de solicitudes por cliente en las que Google Cloud Armor bloquea las solicitudes. Si se especifica, la clave se bloquea para el ban_duration_sec configurado cuando la cantidad de solicitudes que exceden el rate_limit_threshold_count también supera este ban_threshold_count.
• ban_duration_sec: Esta es la cantidad adicional de segundos en los que se bloquea a un cliente después de que transcurrió el período interval_sec. El valor debe ser 60, 120, 180, 240, 300, 600, 900, 1,200, 1,800, 2,700 o 3,600 segundos.

Cuando el porcentaje de solicitudes de un cliente está por debajo del límite de frecuencia, se permite de inmediato que la solicitud continúe con el servicio de backend. Cuando la tasa de tráfico de un cliente supera el rate_limit_threshold especificado, Google Cloud Armor aplica el exceed_action a todas las solicitudes entrantes del cliente durante el resto del intervalo límite y el siguiente ban_duration_sec segundos, sin importar si se superó o no el umbral.

Con esta configuración, es posible bloquear de manera accidental los clientes de bienvenida que solo excedan la tasa de solicitudes permitidas. Para evitar esto y bloquear solo a los clientes que suelen superar el porcentaje de solicitudes, tiene la opción de realizar un seguimiento de las solicitudes totales de los clientes en comparación con una configuración de umbral adicional, preferentemente más larga, llamada ban_threshold_count. En este modo, se bloquea al cliente para el ban_duration_sec configurado solo si la tasa de solicitudes supera el ban_threshold_count configurado. Si el porcentaje de solicitudes no supera el ban_threshold_count, las solicitudes se limitan a rate_limit_threshold. Para los fines de ban_threshold_count, se cuentan las solicitudes totales del cliente, que constan de todas las solicitudes entrantes antes de la limitación.

Política de seguridad de límite de frecuencia predeterminada

Cuando configuras unapolítica de seguridad predeterminada durante la creación del balanceador de cargas, el umbral predeterminado es de 500 solicitudes durante cada intervalo de un minuto (un rate_limit_threshold y interval_sec de 500 y 60, respectivamente). Si deseas seleccionar un umbral diferente, te recomendamos que sigas los pasos que se indican a continuación para ajustar los parámetros:

1. Habilita Cloud Logging y consulta la cantidad máxima de solicitudes que llegaron por dirección IP y por minuto durante un día o más en tu servicio de backend protegido por Google Cloud Armor.

   Por ejemplo, supongamos que crees que el 99% del tráfico de red que recibes no debería verse afectado por la regla de límite de frecuencia. En esta situación, recomendamos que establezcas el umbral de tu límite de frecuencia en el percentil 99 de la cantidad máxima de solicitudes por dirección IP y por minuto de la distribución que se genera a partir de los datos de Cloud Logging.

2. Si aún observas reglas de límite de frecuencia predeterminadas que bloquean el tráfico legítimo, considera realizar los siguientes pasos adicionales:

   1. Habilita el almacenamiento en caché (Cloud CDN o Media CDN).
   2. Aumenta el intervalo de tiempo de la limitación (solicitudes recibidas por varios minutos, en lugar de por 60 segundos).
   3. Puedes bloquear a los clientes para reducir aún más el impacto del ataque después de la ola inicial. La acción rate_based_ban de Google Cloud Armor te permite hacerlo mediante el bloqueo de todos los clientes que excedan los límites demasiadas veces dentro de un período especificado por el usuario. Por ejemplo, se puede bloquear durante 15 minutos a los clientes que superen los límites 10 veces en un minuto.

Aplicación de umbrales

Los límites configurados para la regulación y las bloqueos basadas en tasas se aplican de forma independiente en cada una de las regiones de Google Cloud en las que se implementan tus servicios de backend HTTP(S). Por ejemplo, si tu servicio se implementa en dos regiones, cada una de las dos regiones limita cada clave al umbral configurado, por lo que tu servicio de backend puede experimentar volúmenes de tráfico agregado entre regiones que son el doble del límite configurado. Si el umbral configurado se establece en 5,000 solicitudes, el servicio de backend puede recibir 5,000 solicitudes de una región y 5,000 solicitudes de la segunda región.

Sin embargo, para la dirección IP del tipo de clave, es razonable suponer que el tráfico de la misma dirección IP de cliente se dirige a la región más cercana a la región en la que se implementan los backends. En este caso, el límite de frecuencia se puede considerar como aplicable a nivel de servicio de backend, sin importar las regiones en las que se implemente.

Es importante tener en cuenta que los límites de frecuencia que se aplican son aproximados y pueden no ser estrictamente precisos en comparación con los umbrales configurados. Además, en casos excepcionales, debido al comportamiento de enrutamiento interno, es posible que el límite de frecuencia se aplique en más regiones que las regiones en las que se implementan, lo que afecta la exactitud. Por estos motivos, te recomendamos que uses el límite de frecuencia solo para la mitigación de abusos o a fin de mantener la disponibilidad de las aplicaciones y los servicios, no para aplicar requisitos estrictos de cuota o licencia.

Logging

Cloud Logging registra el nombre de la política de seguridad, la prioridad de la regla de límite de frecuencia coincidente, el ID de la regla, la acción asociada y otra información en tus registros de solicitudes. Para obtener más información sobre el registro detallado, consulta Usa el registro de solicitudes.

Integración en reCAPTCHA Enterprise

Puedes aplicar un límite de frecuencia a algunos recursos de reCAPTCHA Enterprise para mitigar el abuso de tokens y limitar su reutilización. Estos recursos incluyen tokens de acción, tokens de sesión y cookies de exención. Para obtener más información sobre el uso de límites de frecuencia con reCAPTCHA Enterprise, consulta la descripción general de la administración de bots.

¿Qué sigue?

• Configura el límite de frecuencia