Descripción general del límite de frecuencia

Google Cloud Armor ofrece funciones para proteger tus Google Cloud aplicaciones frente a diversos ataques de capa 3 y capa 7. Las reglas basadas en tarifas te ayudan a proteger tus aplicaciones frente a 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:

  • Evita que un cliente concreto agote los recursos de la aplicación.
  • Protege las instancias de tu aplicación frente a picos erráticos e impredecibles en la tasa de solicitudes de clientes.

Además, cuando un recurso recibe un gran volumen de tráfico de un número reducido de clientes, puedes evitar que otros clientes se vean afectados por grandes picos de tráfico de ese número reducido de clientes, lo que permite que tus recursos gestionen tantas solicitudes como sea posible.

Cloud Armor tiene dos tipos de reglas basadas en la frecuencia:

  1. Limitar: puedes aplicar un límite máximo de solicitudes por cliente o en todos los clientes limitando los clientes individuales a un umbral configurado por el usuario.
  2. Bloqueo basado en la frecuencia: puedes limitar la frecuencia de las solicitudes que coincidan con una regla por cliente y, a continuación, bloquear temporalmente a esos clientes durante un periodo configurado si superan un umbral configurado por el usuario.

Cuando configuras una regla con una acción de bloqueo basada en la frecuencia, no puedes cambiarla a una acción de limitación más adelante. Sin embargo, cuando configures una regla con una acción de limitación, podrás cambiarla a una acción de prohibición basada en la frecuencia más adelante. Para obtener más información, consulta Limitación de la frecuencia basada en varias claves.

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

Para previsualizar los efectos de las reglas de limitación de frecuencia en una política de seguridad, puedes usar el modo de vista previa y examinar los registros de solicitudes.

Identificar clientes para limitar la frecuencia

Cloud Armor identifica a los clientes individuales para limitar la frecuencia mediante los siguientes tipos de claves para agregar solicitudes y aplicar límites de frecuencia:

  • TODAS: una sola clave para todas las solicitudes que cumplan la condición de la regla.
  • IP: una clave única para cada dirección IP de origen de cliente cuyas solicitudes cumplan la condición de coincidencia de la regla.
  • HTTP_HEADER una clave única para cada valor de encabezado HTTP único cuyo nombre se haya configurado. El valor de la clave se trunca a los primeros 128 bytes del valor del encabezado. El tipo de clave predeterminado es ALL si no hay ningún encabezado de este tipo o si intentas usar este tipo de clave con un balanceador de carga de red de proxy externo.
  • XFF_IP una clave única para cada dirección IP de origen del cliente, es decir, la primera dirección IP de la lista de IPs especificada en el encabezado HTTP X-Forwarded-For. El tipo de clave predeterminado es la dirección IP si no se incluye este encabezado, si el valor no es una dirección IP válida o si intentas usar este tipo de clave con un balanceador de carga de red de proxy externo.
  • HTTP_COOKIE una clave única para cada valor de cookie HTTP cuyo nombre se haya configurado. El valor de la clave se trunca a los primeros 128 bytes del valor de la cookie. El tipo de clave es ALL de forma predeterminada si no hay ninguna cookie de este tipo o si intentas usar este tipo de clave con un balanceador de carga de red de proxy externo.
  • HTTP_PATH la ruta de la URL de la solicitud HTTP. El valor de la clave se trunca a los primeros 128 bytes.
  • SNI el indicador del 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 predeterminado es ALL en una sesión HTTP.
  • REGION_CODE el país o la región desde los que se origina la solicitud.
  • TLS_JA4_FINGERPRINT huella digital TLS/SSL de JA4 si el cliente se conecta mediante HTTPS, HTTP/2 o HTTP/3. Si no está disponible, el tipo de clave será ALL de forma predeterminada. Para obtener más información sobre JA4, consulta la referencia del lenguaje de reglas.
  • TLS_JA3_FINGERPRINT huella digital JA3 TLS/SSL si el cliente se conecta mediante HTTPS, HTTP/2 o HTTP/3. Si no está disponible, el tipo de clave será ALL de forma predeterminada.
  • USER_IP la dirección IP del cliente de origen, incluida en los encabezados configurados en userIpRequestHeaders y cuyo valor lo rellena un proxy upstream. Si no hay ninguna configuración de userIpRequestHeaders o no se puede resolver una dirección IP a partir de ella, el tipo de clave será IP de forma predeterminada. Para obtener más información, consulta la referencia del lenguaje de reglas.

Puedes usar las claves anteriores de forma individual o aplicar un límite de frecuencia basado en una combinación de hasta tres claves. Puedes usar varias teclas HTTP-HEADER o HTTP-COOKIE, pero solo una de cada uno de los demás tipos de teclas. Para obtener más información, consulta Limitación de la frecuencia basada en varias claves.

Elegir entre reglas de prohibición basadas en la frecuencia y reglas de limitación de la frecuencia

Las reglas de limitación de frecuencia de rate-based ban y throttle de Cloud Armor se diferencian en la forma en que gestionan el tráfico que supera el umbral configurado.

  • rate_based_ban: Cuando la tasa de solicitudes supera el umbral definido, Cloud Armor bloqueará todas las solicitudes posteriores de la fuente o el destino de esas solicitudes durante un periodo especificado.
  • throttle: en lugar de bloquear todo el tráfico, la limitación de frecuencia restringe el porcentaje de solicitudes a un máximo definido. De esta forma, se permite que pase algo de tráfico, pero a un ritmo controlado que evita la sobrecarga.

La regla más adecuada depende de tus necesidades específicas y del tipo de tráfico que estés gestionando. Por ejemplo, si sufres un ataque DDoS, una prohibición basada en la frecuencia podría ser más adecuada para bloquear rápidamente el tráfico malicioso. Por otro lado, si experimentas un aumento repentino del tráfico legítimo, la limitación puede ser una mejor opción para mantener la disponibilidad del servicio y evitar la sobrecarga.

Limitar el tráfico

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

Por ejemplo, puedes definir el umbral de solicitudes en 2000 solicitudes en un periodo de 1200 segundos (20 minutos). Si un cliente envía 2500 solicitudes en un periodo de 1200 segundos, aproximadamente el 20% del tráfico del cliente se limitará hasta que el volumen de solicitudes permitidas sea igual o inferior al umbral configurado.

Cuando la tasa de tráfico de un cliente es inferior o igual a rate_limit_threshold_count, las solicitudes siguen el conform_action, que siempre es una acción allow. La solicitud se permite a través de la política de seguridad y puede llegar a su destino. Cuando la tasa de tráfico de un cliente supera el rate_limit_threshold_count especificado, Cloud Armor aplica el exceed_action, que puede ser deny o redirect, a las solicitudes que superen el límite durante el resto del intervalo del umbral.

Estos parámetros se definen para controlar la acción:

  • rate_limit_threshold_count: número de solicitudes por cliente permitidas en un intervalo de tiempo especificado. El valor mínimo es 1 y el máximo es 1.000.000.
    • interval_sec: número de segundos del 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_count, Cloud Armor aplica el exceed_action configurado. Los valores posibles de exceed_action son los siguientes:
    • deny(status): se deniega la solicitud y se devuelve 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 redirige para que se evalúe con reCAPTCHA o a otra URL, en función del parámetro exceed_redirect_options.
  • exceed_redirect_options: Cuando exceed_action sea redirect, usa este parámetro para especificar la acción de redirección:
    • type: tipo de la acción de redirección, GOOGLE_RECAPTCHA o EXTERNAL_302.
    • target: URL de destino de la acción de redirección. Solo se aplica cuando type es EXTERNAL_302.
  • conform_action: es la acción que se lleva a cabo cuando el número de solicitudes es inferior a rate_limit_threshold_count. Esta acción siempre es allow.

Bloquear clientes en función de las tasas de solicitudes

La acción rate_based_ban de una regla te permite aplicar un umbral por cliente para prohibir temporalmente a los clientes que superen el límite. Para ello, se aplica el exceed_action configurado a todas las solicitudes del cliente durante un periodo configurable. El umbral se configura como un número de solicitudes especificado en un intervalo de tiempo especificado. Puede prohibir temporalmente el tráfico durante un periodo de tiempo configurado por el usuario ('ban_duration_sec'), siempre que el tráfico coincida con la condición de coincidencia especificada y supere el umbral configurado.

Por ejemplo, puedes definir el umbral de solicitudes en 2000 solicitudes en un periodo de 1200 segundos (20 minutos). Si un cliente envía 2500 solicitudes en un periodo de 1200 segundos, Cloud Armor aplica la exceed_action al tráfico de ese cliente que supere el umbral de 2000 solicitudes hasta que transcurran los 1200 segundos y durante un número adicional de segundos que hayas definido como periodo de bloqueo. Si el periodo de duración de la prohibición es de 3600, por ejemplo, el tráfico del cliente se prohibirá durante 3600 segundos (una hora) después del final del intervalo del umbral.

Cuando la tasa de solicitudes de un cliente está por debajo del umbral del límite de frecuencia, la solicitud puede enviarse inmediatamente al servicio backend. Cuando la tasa de tráfico de un cliente supera el rate_limit_threshold_count especificado, Cloud Armor aplica el exceed_action a todas las solicitudes entrantes del cliente durante el resto del intervalo del umbral y durante los ban_duration_sec segundos siguientes, independientemente de si se supera o no el umbral.

Con esta configuración, es posible que se baneen por error clientes que solo superan ocasionalmente la tasa de solicitudes permitida. Para evitarlo y prohibir solo a los clientes que superen con frecuencia la tasa de solicitudes, puedes hacer un seguimiento opcional del total de solicitudes de clientes en comparación con una configuración de umbral adicional, preferiblemente más larga, llamada ban_threshold_count. En este modo, el cliente se veta durante el tiempo ban_duration_sec configurado solo si la tasa de solicitudes supera el valor ban_threshold_count configurado. Si la tasa de solicitudes no supera ban_threshold_count, las solicitudes se seguirán limitando a rate_limit_threshold_count. A efectos de ban_threshold_count, se contabilizan todas las solicitudes entrantes del cliente antes de que se aplique la limitación.

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

  • rate_limit_threshold_count: número de solicitudes por cliente permitidas en un intervalo de tiempo especificado. El valor mínimo es 1 solicitud y el máximo es 10.000 solicitudes.
    • interval_sec: número de segundos del 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_count, Cloud Armor aplica el exceed_action configurado. Los valores posibles de exceed_action son los siguientes:
    • deny(status): se deniega la solicitud y se devuelve el código de error especificado. Los valores válidos del código de error son 403, 404, 429 y 502. Te recomendamos que uses el código de respuesta 429 (Too Many Requests).
    • redirect: La solicitud se redirige para que se evalúe con reCAPTCHA o a otra URL, en función del parámetro exceed_redirect_options.
  • exceed_redirect_options: Cuando exceed_action sea redirect, usa este parámetro para especificar la acción de redirección:
    • type: tipo de la acción de redirección, GOOGLE_RECAPTCHA o EXTERNAL_302.
    • target: URL de destino de la acción de redirección. Solo se aplica cuando type es EXTERNAL_302.
  • conform_action: es la acción que se lleva a cabo cuando el número de solicitudes es inferior a rate_limit_threshold_count. Esta acción siempre es allow.
  • ban_threshold_count: es el número de solicitudes por cliente permitidas en un intervalo de tiempo especificado. Si se supera este número, Cloud Armor bloquea las solicitudes. Si se especifica, la clave se inhabilita durante el tiempo ban_duration_sec configurado cuando el número de solicitudes que superan el valor rate_limit_threshold_count también supera este valor ban_threshold_count.
    • ban_threshold_interval_sec: número de segundos del intervalo de tiempo de tu ban_threshold_count. El valor debe ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 segundos.
  • ban_duration_sec: es el número adicional de segundos durante los que se suspende a un cliente después de que transcurra el periodo interval_sec. El valor debe ser 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 segundos.

Política de seguridad de limitación de frecuencia predeterminada

Cuando configuras una política de seguridad predeterminada durante la creación del balanceador de carga, el umbral predeterminado es de 500 solicitudes durante cada intervalo de un minuto (un rate_limit_threshold_count y un interval_sec de 500 y 60, respectivamente). Si quieres seleccionar otro umbral, te recomendamos que sigas estos pasos para ajustar los parámetros:

  1. Habilita Cloud Logging y consulta el número máximo de solicitudes que han llegado por dirección IP y por minuto durante un día o más en tu servicio de backend protegido por Cloud Armor.

    Por ejemplo, supongamos que cree que el 99% del tráfico de red que recibe no debería verse afectado por la regla de limitación de frecuencia. En este caso, le recomendamos que defina el umbral del límite de frecuencia en el percentil 99 del número máximo 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 sigues observando que las reglas de limitación de frecuencia predeterminadas bloquean tráfico legítimo, te recomendamos que sigas estos pasos adicionales:

    1. Habilita el almacenamiento en caché (Cloud CDN o Media CDN).
    2. Aumentar el intervalo de tiempo de limitación (solicitudes recibidas por varios minutos, en lugar de por cada 60 segundos).
    3. Puedes prohibir el acceso a los clientes para reducir aún más el impacto del ataque después de la oleada inicial. La acción rate_based_ban de Cloud Armor te permite hacerlo prohibiendo el acceso a todos los clientes que superen los límites demasiadas veces en un periodo especificado por el usuario. Por ejemplo, los clientes que superen los límites 10 veces en un minuto pueden ser vetados durante 15 minutos.

Aplicación de umbrales

Los umbrales configurados para la limitación y las prohibiciones basadas en la frecuencia se aplican de forma independiente en cada una de las Google Cloud regiones en las que se implementan tus servicios de backend HTTP(S). Por ejemplo, si tu servicio se ha desplegado en dos regiones, cada una de ellas limitará la frecuencia de cada clave al umbral configurado, por lo que tu servicio de backend podría experimentar volúmenes de tráfico agregados entre regiones que dupliquen el umbral configurado. Si el umbral configurado es de 5000 solicitudes, el servicio de backend puede recibir 5000 solicitudes de una región y 5000 solicitudes de la segunda región.

Sin embargo, en el caso del tipo de clave de dirección IP, es razonable suponer que el tráfico de la misma dirección IP del cliente se dirige a la región más cercana a la región en la que se han desplegado tus back-ends. En este caso, se puede considerar que la limitación de la frecuencia se aplica a nivel de servicio de backend, independientemente de las regiones en las que se haya implementado.

Es importante tener en cuenta que los límites de frecuencia obligatorios son aproximados y es posible que no sean estrictamente precisos en comparación con los umbrales configurados. Además, en casos excepcionales, debido al comportamiento de enrutamiento interno, es posible que se aplique la limitación de frecuencia en más regiones de las que tienes implementadas, lo que afectará a la precisión. Por estos motivos, te recomendamos que uses la limitación de frecuencia solo para mitigar el abuso o mantener la disponibilidad de las aplicaciones y los servicios, y no para aplicar cuotas estrictas o requisitos de licencia.

Almacenamiento de registros

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

Integración con reCAPTCHA

Puedes aplicar límites de frecuencia a algunos recursos de reCAPTCHA para mitigar el uso inadecuado de tokens y limitar la reutilización de tokens. Entre estos recursos se incluyen tokens de acción, tokens de sesión y cookies de exención. Para obtener más información sobre cómo usar la limitación de frecuencia con reCAPTCHA, consulta la descripción general de la gestión de bots.

Respuestas de error personalizadas

Puedes aplicar respuestas de error personalizadas a la limitación de frecuencia de Cloud Armor, incluido el tráfico throttle y rate_based_ban. Cuando se aplican estos límites, se envían mensajes de error personalizados a los usuarios finales. Además, puedes configurar respuestas de error personalizadas para códigos de estado HTTP específicos generados por balanceadores de carga o instancias de backend cuando usas un balanceador de carga de aplicaciones externo global.

Para obtener más información sobre las respuestas de error personalizadas, consulta el artículo Descripción general de las respuestas de error personalizadas. Para configurar respuestas de error personalizadas, consulta Configurar respuestas de error personalizadas.

Cloud Armor con Cloud Service Mesh

Puedes configurar políticas de seguridad de servicios internos para tu malla de servicios con el fin de aplicar límites de frecuencia globales del lado del servidor por cliente, lo que te ayudará a compartir de forma equitativa la capacidad disponible de tu servicio y a mitigar el riesgo de que los clientes maliciosos o que no se comporten correctamente sobrecarguen tus servicios. Puedes asociar una política de seguridad a una política de endpoints de Cloud Service Mesh para aplicar la limitación de frecuencia al tráfico entrante del lado del servidor. Sin embargo, no puedes configurar una política de seguridad de Google Cloud Armor si usas el enrutamiento de tráfico TCP. Para obtener más información sobre cómo usar Cloud Armor con Cloud Service Mesh, consulta el artículo Configurar la limitación de frecuencia con Cloud Armor.

Siguientes pasos