Descripción general de la límite de frecuencia del servicio

Las políticas de límite de frecuencia del servicio te permiten mantener la disponibilidad del servicio entre los clientes de confianza que podrían consumir una cantidad excesiva de recursos. Las políticas logran esto priorizando el tráfico esencial del cliente durante las sobrecargas del servicio y limitando a los clientes que superan los umbrales predefinidos.

Puedes combinar las políticas de límite de frecuencia del servicio con otros tipos de límite de frecuencia, como las políticas de seguridad de Cloud Armor que prohíben explícitamente a los clientes que no son de confianza para evitar el abuso. Para obtener más información sobre las políticas de seguridad, consulta la Descripción general de las políticas de seguridad y la Descripción general del límite de frecuencia de Cloud Armor.

Debes adjuntar las políticas de límite de frecuencia del servicio a las reglas de reenvío de los balanceadores de cargas compatibles o a los recursos de la puerta de enlace de Secure Web Proxy. Para obtener más información sobre el uso de políticas de límite de frecuencia del servicio con instancias de Secure Web Proxy, consulta Configura políticas de límite de frecuencia del servicio.

Categorías admitidas

Las políticas de límite de frecuencia del servicio están disponibles para los siguientes destinos:

  • Balanceadores de cargas de aplicaciones internos regionales
  • Secure Web Proxy

Orden de filtrado de solicitudes

Las políticas de límite de frecuencia del servicio son solo un tipo de filtro que se aplica a las solicitudes. En el siguiente diagrama, se muestra el orden en que se aplican los filtros:

Es el orden de evaluación para el filtrado de solicitudes.
Orden de evaluación para el filtrado de solicitudes (haz clic para ampliar).

Reglas

Cada política de límite de frecuencia del servicio contiene una lista de reglas HTTP. Cada regla especifica una condición de coincidencia y un conjunto de acciones de límite de frecuencia. Cuando una solicitud satisface las condiciones de coincidencia de la regla, se evalúa en función de uno o más de tus buckets de límite de frecuencia configurados.

Condiciones de coincidencia

Las condiciones de coincidencia y sus propiedades son las siguientes. Cada propiedad puede coincidir con una cadena exacta, un prefijo, un sufijo o una subcadena:

  • Source: Es la fuente de la solicitud.
    • principal: Es una lista de identidades derivadas del certificado del cliente. Se produce una coincidencia cuando cualquier principal coincide con la regla. Para obtener más información sobre el uso de principales para el límite de frecuencia del servicio, consulta Usa principales para el límite de frecuencia del servicio.
  • Destination: Es el destino de la solicitud. Si especificas varias propiedades, se combinan con un operador lógico AND.
    • header_set: Es una lista de encabezados HTTP. Se produce una coincidencia cuando todos los encabezados de header_set coinciden con la regla.
    • hosts: Es una lista de hosts HTTP. Se produce una coincidencia cuando la solicitud va a cualquiera de los hosts especificados en la lista.
    • paths: Es una lista de rutas de URL. Se produce una coincidencia cuando la solicitud usa cualquiera de las rutas de acceso especificadas en la lista.
    • methods: Es una lista de métodos HTTP válidos (como GET o POST). Se produce una coincidencia cuando la solicitud usa cualquiera de los métodos especificados en la lista.

Ten en cuenta que las propiedades de origen y destino se combinan con un operador lógico AND para determinar si una regla coincide con una solicitud. Esto significa que, si especificas una fuente y un destino, una solicitud debe coincidir con ambos para satisfacer las condiciones de coincidencia. Además, las reglas vacías coinciden con todas las solicitudes.

Orden de evaluación de reglas

Las reglas se evalúan en orden desde la primera regla definida en la política hasta la última. La primera regla que coincide con una solicitud aplica sus acciones de límite de frecuencia a la solicitud y no se evalúan más reglas. Si una regla tiene varias acciones de límite de frecuencia y alguna de ellas supera el umbral configurado, se limita la solicitud.

Buckets de límite de frecuencia

Configuras uno o más buckets de límite de frecuencia, cada uno de los cuales tiene una o más claves de límite de frecuencia. Cuando una solicitud coincide con las condiciones de coincidencia de una regla, se evalúa en función de uno o más de tus buckets de límite de frecuencia configurados. Luego, el bucket aplica su clave de límite de frecuencia configurada para identificar clientes individuales y aplica el límite.

Además de los tipos de claves, puedes configurar las siguientes propiedades de bucket:

  • Ejecución de prueba: en el modo de ejecución de prueba, se evalúa la regla y se realiza un seguimiento de las coincidencias, pero no se aplica la acción de la regla. Esto te permite probar tus reglas de límite de frecuencia sin limitar a los clientes ni afectar el tráfico de producción.
  • Anulaciones de usuario: puedes anular los límites de solicitud predeterminados para valores clave específicos. Por ejemplo, si tuvieras un bucket con un límite predeterminado de 100 solicitudes por minuto por cliente y ese bucket usara el tipo de clave SOURCE_IP, podrías anular el límite para una dirección IP específica y, en su lugar, imponer un límite de 200 solicitudes por minuto.

Tipos de claves

Puedes identificar clientes individuales para el límite de frecuencia con los siguientes tipos de claves para agregar solicitudes y aplicar límites de frecuencia:

  • ALL: Es una sola clave para todas las solicitudes que satisfacen la condición de coincidencia de la regla.
  • SOURCE_IP: Es una clave única para cada dirección IP de cliente cuyas solicitudes satisfacen la condición de coincidencia de la regla.
  • HTTP_HEADER: Es una clave única para cada valor de encabezado HTTP único cuyo nombre está configurado. El valor de la clave se trunca a los primeros 128 bytes del valor del encabezado. El tipo de clave se establece en ALL de forma predeterminada si no existe tal encabezado.
  • HTTP_PATH: Es la ruta de URL de la solicitud HTTP. El valor de la clave se trunca a los primeros 128 bytes.
  • PRINCIPAL: Es una cadena que representa una identidad, que se deriva de l certificado del cliente. El único tipo principal compatible es CLIENT_CERT_COMMON_NAME.

Puedes especificar uno o más tipos de claves en cada regla. Si especificas varios tipos de claves, la combinación total de claves para cada cliente se usa como una clave única. Por ejemplo, puedes usar una combinación de SOURCE_IP y HTTP_PATH para aplicar límites de frecuencia sobre la frecuencia con la que una dirección IP específica puede acceder a un extremo específico.

Usa principales para el límite de frecuencia del servicio

Para identificar la fuente de tráfico con alta granularidad, puedes configurar políticas de límite de frecuencia del servicio basadas en identidades derivadas del certificado de un cliente. Este método requiere que se habilite la mTLS de frontend en el balanceador de cargas y usa el atributo Nombre común del certificado de cliente (CLIENT_CERT_COMMON_NAME) como un selector principal para la identificación.

Si no se especifica ningún selector principal para la identificación, se usa CLIENT_CERT_URI_SAN como el selector principal predeterminado. Esto significa que se evalúan los SAN de URI del certificado de cliente cuando se toman decisiones de límite de frecuencia.

Para que funcione el límite de frecuencia basado en principales, se deben aplicar las siguientes condiciones:

  • Se debe habilitar la mTLS de frontend. Si mTLS de frontend no está habilitada, el cliente no presenta un certificado. Como resultado, ninguna regla basada en principales en la política de límite de frecuencia del servicio encuentra información de certificado para evaluar. Por ejemplo, una regla que verifica CLIENT_CERT_URI_SAN ve un valor vacío.

  • Debe haber un certificado de cliente válido. Incluso con la mTLS habilitada, no se usa un certificado de cliente para el límite de frecuencia si la conexión se estableció con un certificado faltante o no válido. Esta situación ocurre cuando el modo de validación de cliente de mTLS se establece en el modo permisivo ALLOW_INVALID_OR_MISSING_CLIENT_CERT. En este caso, tampoco, ninguna regla basada en principales en la política de límite de frecuencia del servicio encuentra información de certificado para evaluar. Por ejemplo, una regla que verifica CLIENT_CERT_URI_SAN ve un valor vacío.

Impacto de los límites de tamaño de los atributos

Las decisiones de límite de frecuencia son sensibles al tamaño de los atributos del certificado de cliente. Se rechaza una solicitud si un atributo supera su límite de tamaño y la política está configurada para validar ese atributo específico.

Se puede producir un rechazo cuando la política valida en función de CLIENT_CERT_COMMON_NAME y el asunto del certificado (que contiene el nombre común) supera el límite de tamaño.

¿Qué sigue?