Visão geral da limitação de taxa

O Google Cloud Armor fornece recursos para ajudar a proteger seus aplicativos do Google Cloud contra vários ataques de camada 3 e camada 7. As regras baseadas em taxa ajudam a proteger os aplicativos contra um grande volume de solicitações que sobrecarregam as instâncias e bloqueiam o acesso de usuários legítimos.

A limitação de taxa pode fazer o seguinte:

  • Impedir que um determinado cliente esgote os recursos do aplicativo.
  • Proteja suas instâncias de aplicativos contra picos erráticos e imprevisíveis na taxa de solicitações de clientes.

Além disso, quando um recurso é apresentado com um alto volume de tráfego de um pequeno número de clientes, você pode impedir que outros clientes sejam afetados por grandes picos de tráfego desse pequeno número de clientes, permitindo que você recursos para lidar com o maior número possível de solicitações.

O Google Cloud Armor tem dois tipos de regras com base em taxas:

  1. Limitação: é possível aplicar um limite máximo de solicitações por cliente ou em todos os clientes limitando os clientes individuais a um limite configurado pelo usuário.
  2. Proibição baseada em taxa: é possível classificar solicitações de limite que correspondem a uma regra por cliente e, em seguida, proibir temporariamente esses clientes por um período configurado, se eles excederem um limite configurado pelo usuário.

Visualize os efeitos das regras de limitação de taxa em uma política de segurança usando o modo de visualização e examinando os registros de solicitação.

Como identificar clientes para limitação de taxa

O Google Cloud Armor identifica clientes individuais para a limitação de taxa usando os seguintes tipos de chave para agregar solicitações e aplicar limites de taxa:

  • ALL: uma única chave para todos os clientes com solicitações que atendem à condição de correspondência de regra.
  • IP: uma única chave para cada endereço IP de origem do cliente cujas solicitações atendem à condição de correspondência da regra.
  • HTTP-HEADER: uma única chave para cada valor de cabeçalho HTTP exclusivo com nome configurado. O valor da chave é truncado para os primeiros 128 bytes do valor do cabeçalho. O tipo de chave assume o padrão ALL se nenhum cabeçalho estiver presente ou se você tentar usar esse tipo de chave com um balanceador de carga de proxy TCP ou de proxy SSL.
  • XFF-IP: uma chave exclusiva para cada endereço IP de origem original do cliente, ou seja, o primeiro endereço IP na lista de IPs especificados no cabeçalho HTTP X-Forwarded-For. O tipo de chave assume o padrão de endereço IP se nenhum cabeçalho estiver presente, se o valor não for um endereço IP válido ou se você tentar usar esse tipo de chave com um balanceador de carga de proxy TCP ou de proxy SSL.
  • HTTP-COOKIE: uma chave exclusiva para cada valor de cookie HTTP com o nome configurado. O valor da chave é truncado para os primeiros 128 bytes do valor do cookie. O tipo de chave assume o padrão ALL se não houver nenhum cookie presente ou se você tentar usar esse tipo de chave com um balanceador de carga de proxy TCP ou de proxy SSL.

Como limitar o tráfego

A ação throttle em uma regra permite que você aplique um limite de solicitação por cliente para proteger serviços de back-end. Essa regra impõe o limite para limitar o tráfego de cada cliente que satisfaça as condições de correspondência na regra. O limite é configurado como um número especificado de solicitações em um intervalo de tempo especificado.

Por exemplo, é possível definir o limite de solicitações para 2.000 solicitações em 1.200 segundos (20 minutos). Se um cliente enviar 2.500 solicitações em um período de 1.200 segundos, aproximadamente 20% do tráfego dele será limitado até que o volume de solicitações permitido seja igual ou inferior ao limite configurado.

Defina estes parâmetros para controlar a ação:

  • rate_limit_threshold: o número de solicitações por cliente permitidas dentro de um intervalo de tempo especificado. O valor mínimo é 1, e o máximo é 10.000.
    • interval_sec: o número de segundos no intervalo de tempo. O valor precisa ser 60, 120, 180, 240, 300, 600, 900, 1.200, 1.800, 2.700 ou 3.600 segundos.
  • exceed_action: quando uma solicitação excede rate_limit_threshold, o Google Cloud Armor aplica o exceed_action configurado. Os valores possíveis para exceed_action são os seguintes:
    • deny(status): a solicitação é negada e o código de erro especificado é retornado (os valores válidos são 403, 404, 429 e 502). Recomendamos o uso do código de resposta 429 (Too Many Requests).
    • redirect: a solicitação é redirecionada para a avaliação do reCAPTCHA Enterprise ou para outro URL com base no parâmetro exceed_redirect_options.
  • exceed_redirect_options: quando exceed_action é redirect, use esse parâmetro para especificar a ação de redirecionamento:
    • type: digite para a ação de redirecionamento, GOOGLE_RECAPTCHA ou EXTERNAL_302.
    • target: o destino do URL da ação de redirecionamento. Aplicável somente quando o type é EXTERNAL_302.
  • conform_action: é a ação realizada quando o número de solicitações está abaixo de rate_limit_threshold. É sempre uma ação allow.

Quando a taxa de tráfego de um cliente está abaixo ou igual a rate_limit_threshold, as solicitações seguem o conform-action, que é sempre allow. A solicitação é permitida pela política de segurança e pode chegar ao destino. Quando a taxa de tráfego de um cliente excede o rate_limit_threshold especificado, o Google Cloud Armor aplica o exceed_action, que pode ser deny ou redirect, em solicitações acima do limite até o restante do intervalo limite.

Como banir clientes com base em taxas de solicitação

A ação rate_based_ban de uma regra permite que você aplique um limite por cliente para banir temporariamente clientes que excedem o limite aplicando a exceed_action em todas as solicitações feitas por um período configurável. O limite é configurado como um número especificado de solicitações em um intervalo de tempo especificado. É possível banir temporariamente o tráfego por um período configurado pelo usuário ('ban_duration_sec'), desde que o tráfego atenda à condição de correspondência especificada e exceda o limite configurado.

Por exemplo, é possível definir o limite de solicitações para 2.000 solicitações em 1.200 segundos (20 minutos). Se um cliente envia 2.500 solicitações em 1.200 segundos, o Google Cloud Armor aplica o exceed_action ao tráfego desse cliente, excedendo o limite de 2.000 solicitações, até que o total de 1.200 segundos tenha passado e durante os segundos extras que você definiu como o período de proibição. Quando o período da proibição é definido como 3600, por exemplo, o tráfego do cliente e proibido por 3.600 segundos (uma hora) além do final do intervalo de limite.

Estes parâmetros controlam a ação de uma regra rate_based_ban:

  • rate_limit_threshold: o número de solicitações por cliente permitidas dentro de um intervalo de tempo especificado. O valor mínimo de solicitações é 1, e o valor máximo é 10.000.
    • interval_sec: o número de segundos no intervalo de tempo. O valor precisa ser 60, 120, 180, 240, 300, 600, 900, 1.200, 1.800, 2.700 ou 3.600 segundos.
  • exceed_action: quando uma solicitação excede rate_limit_threshold, o Google Cloud Armor aplica o exceed_action configurado. Os valores possíveis para exceed_action são os seguintes:
    • deny(status): a solicitação é negada, e o código de erro especificado é retornado. Os valores válidos de código do erro são 403, 404, 429 e 502. Recomendamos o uso do código de resposta 429 (Too Many Requests).
    • redirect: a solicitação é redirecionada para a avaliação do reCAPTCHA Enterprise ou para outro URL com base no parâmetro exceed_redirect_options.
  • exceed_redirect_options: quando exceed_action é redirect, use esse parâmetro para especificar a ação de redirecionamento:
    • type: digite para a ação de redirecionamento, GOOGLE_RECAPTCHA ou EXTERNAL_302.
    • target: o destino do URL da ação de redirecionamento. Aplicável somente quando o type é EXTERNAL_302.
  • conform_action: é a ação realizada quando o número de solicitações está abaixo de rate_limit_threshold. É sempre uma ação allow.
  • ban_duration_sec: este é o número adicional de segundos em que um cliente é banido após o término do período interval_sec. O valor precisa ser 60, 120, 180, 240, 300, 600, 900, 1.200, 1.800, 2.700 ou 3.600 segundos.

Quando a taxa de solicitação de um cliente está abaixo do limite de taxa, isso permite imediatamente que a solicitação continue para o serviço de back-end. Quando a taxa de tráfego de um cliente excede o rate_limit_threshold especificado, o Google Cloud Armor aplica o exceed_action a todas as solicitações recebidas do cliente no restante do intervalo limite e nos próximos segundos ban-duration_sec, independentemente de o limite ser excedido ou não.

Com essa configuração, é possível banir acidentalmente clientes de boas-vindas que excedem ocasionalmente a taxa de solicitação permitida. Para evitar isso e proibir apenas clientes que excedem com frequência a taxa de solicitação, é possível rastrear o total de solicitações de clientes em relação a uma configuração de limite adicional, preferencialmente mais longa, chamada ban_threshold. Nesse modo, o cliente será banido pelos ban_duration segundos configurados somente se a taxa de solicitação cruzar o ban-threshold configurado. Se a taxa de solicitação não exceder ban-threshold, as solicitações continuarão sendo limitadas para rate_limit_threshold. Para a finalidade de ban_threshold, contabilizamos o total de solicitações do cliente, que consistem em todas as solicitações recebidas antes da limitação.

Aplicação do limite

Os limites configurados para limitação e restrições baseadas em taxa são aplicados independentemente em cada uma das regiões do Google Cloud em que seus serviços de back-end HTTP(S) são implantados. Por exemplo, se o serviço é implantado em duas regiões, cada uma das duas regiões limita a taxa de cada chave ao limite configurado, de modo que seu serviço de back-end pode experimentar volumes de tráfego agregados entre regiões que são duas vezes o limite configurado. Se o limite configurado for definido como 5.000 solicitações, o serviço de back-end poderá receber 5.000 solicitações de uma região e 5.000 solicitações da segunda região.

No entanto, para o endereço IP do tipo de chave, é razoável presumir que o tráfego do mesmo endereço IP do cliente é direcionado para a região mais próxima da região onde seus back-ends são implantados. Nesse caso, a limitação de taxa pode ser considerada aplicada em um nível de serviço de back-end, independentemente das regiões em que ela é implantada.

É importante observar que os limites de taxa aplicados são aproximados e podem não ser estritamente precisos em comparação com os limites configurados. Além disso, em casos raros, devido ao comportamento de roteamento interno, é possível que a limitação de taxa seja aplicada em mais regiões do que as regiões em que você é implantado, impactando a precisão. Por esses motivos, recomendamos que você use a limitação de taxa apenas para mitigar abusos ou manter a disponibilidade de aplicativos e serviços, não para impor requisitos rígidos de cota ou licenciamento.

Logging

O Cloud Logging registra o nome da política de segurança, a prioridade da regra de limite de correspondência, o ID da regra, a ação associada e outras informações nos registros da solicitação. Para mais informações sobre registros, consulte Como usar o registro de solicitações.

Integração com o reCAPTCHA Enterprise

É possível aplicar a limitação de taxa a alguns recursos do reCAPTCHA Enterprise para minimizar o abuso de tokens e limitar a reutilização. Esses recursos incluem tokens de ação, tokens de sessão e cookies de isenção. Para mais informações sobre como usar a limitação de taxa com o reCAPTCHA Enterprise, consulte a visão geral do gerenciamento de bots.

A seguir