Descripción general del límite de frecuencia

Google Cloud Armor ofrece funciones para proteger tus Cloud de Confiance by S3NS 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:

  • Limitación. 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.
  • Bloqueo basado en tarifa. Puedes limitar la frecuencia de las solicitudes que coincidan con una regla por cliente y, a continuación, prohibir temporalmente el acceso a esos clientes durante un periodo configurado por el usuario 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 Cambiar una regla de limitación a una regla de prohibición basada en la frecuencia.

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 concordancia 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 es ALL de forma predeterminada si no se incluye este encabezado 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 la indicación 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 tiene el valor predeterminado 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 JA4 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. 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 frecuencia

Las reglas de limitación de frecuencia de rate-based banthrottle y 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 bloquea 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 reduce la tasa de solicitudes a un máximo definido. La limitación 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 estás sufriendo un ataque DDoS, puede que sea más adecuado usar una prohibición basada en la frecuencia para bloquear rápidamente el tráfico malicioso. Por otro lado, si experimentas un aumento repentino del tráfico legítimo, puede que sea mejor opción limitar la velocidad 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 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 al 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. A continuación, se indican los valores posibles de exceed_action:
    • deny(status): se rechaza la solicitud y se devuelve el código de estado especificado. Los valores válidos son 403 Forbidden, 404 Page Not Found, 429 Too Many Requests y 502 Bad Gateway. Te recomendamos que uses el código de estado 429 Too Many Requests.
    • redirect: la solicitud se redirige para la evaluación de 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 el valor de type es EXTERNAL_302.
  • conform_action: acción que se realiza cuando el número de solicitudes es inferior a rate_limit_threshold_count. Esta acción siempre es una acción 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 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 frecuencia de solicitudes de un cliente está por debajo del umbral de limitación de frecuencia, la solicitud puede pasar inmediatamente al servicio backend. Cuando el 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 el valor de 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 rechaza la solicitud y se devuelve el código de estado especificado. Los valores válidos son 403 Forbidden, 404 Page Not Found, 429 Too Many Requests y 502 Bad Gateway. Te recomendamos que uses el código de estado 429 Too Many Requests.
    • redirect: la solicitud se redirige para la evaluación de 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: el tipo de acción de redirección, que puede ser GOOGLE_RECAPTCHA o EXTERNAL_302.
    • target: la URL de destino de la acción de redirección. Esta URL de destino solo se aplica cuando type es EXTERNAL_302.
  • conform_action: acción que se realiza cuando el número de solicitudes es inferior a rate_limit_threshold_count. Esta acción siempre es una acción allow.
  • ban_threshold_count: número de solicitudes por cliente permitidas en un intervalo de tiempo especificado, durante el cual Cloud Armor prohíbe 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 de ban_threshold_interval_sec debe ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 segundos.
  • ban_duration_sec: número adicional de segundos durante los que se suspende a un cliente después de que transcurra el periodo interval_sec. El valor de ban_duration_sec 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 crees que el 99% del tráfico de red que recibes no se ve 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 prohibir 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 Cloud de Confiance 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 aplica el umbral de limitación de frecuencia configurado a cada clave, por lo que tu servicio de backend puede 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 de 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 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 aplicaciones y servicios, y no para aplicar cuotas estrictas o requisitos de licencia.

La limitación de frecuencia basada en REGION_CODE tiene en cuenta la región desde la que se origina la solicitud y no la región de los backends del servicio de backend, independientemente de su tipo. Los backends incluyen grupos de instancias, cualquier tipo de grupo de puntos finales de red (NEG) compatible con los balanceadores de carga y segmentos de Cloud Storage. Puedes consultar los back-ends admitidos en la información general sobre la política de seguridad.

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.

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 reducir 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 Configurar la limitación de frecuencia con Cloud Armor.

Siguientes pasos