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.

Quando você configura uma regra com uma ação de proibição baseada na taxa, não é possível mudar para uma ação de restrição mais tarde. No entanto, quando você configura uma regra com uma ação de restrição, é possível mudar para uma ação de proibição baseada na taxa mais tarde. Para mais informações, consulte Limitação de taxa com base em várias chaves.

O Google Cloud Armor aplica o limite de limitação de taxa a cada back-end associado. Por exemplo, se você tiver dois serviços de back-end e configurar uma regra de limitação de taxa com um limite de 1.000 solicitações por minuto, cada serviço de back-end poderá receber 1.000 solicitações por minuto antes que o Google Cloud Armor aplique a ação da regra.

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 chave exclusiva 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 padrão da chave será TODOS se nenhum cabeçalho estiver presente ou se você tentar usar esse tipo de chave com um balanceador de carga de rede de proxy externo.
• 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 será o endereço IP padrão 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 rede de proxy externo.
• 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 padrão da chave será TODOS se nenhum cookie estiver presente ou se você tentar usar esse tipo de chave com um balanceador de carga de rede de proxy externo.
• HTTP_PATH: o caminho do URL da solicitação HTTP. O valor da chave é truncado nos primeiros 128 bytes.
• SNI: a indicação do nome do servidor na sessão TLS da solicitação HTTPS. O valor da chave é truncado nos primeiros 128 bytes. O tipo de chave é ALL por padrão em uma sessão HTTP.
• REGION_CODE: o país/região de origem da solicitação.
• TLS_JA3_FINGERPRINT: impressão digital TLS/SSL JA3 se o cliente se conectar usando HTTPS, HTTP/2 ou HTTP/3. Se não estiver disponível, o tipo de chave será ALL por padrão. Para mais informações sobre o JA3, consulte a referência da linguagem de regras.
• USER_IP: o endereço IP do cliente de origem, incluído nos cabeçalhos configurados em userIpRequestHeaders e cujo valor é preenchido por um proxy upstream. Se não houver uma configuração userIpRequestHeaders ou um endereço IP não puder ser resolvido, o tipo de chave será IP por padrão. Para mais informações, consulte a referência da linguagem de regras.

É possível usar as chaves anteriores individualmente ou aplicar uma limitação de taxa com base em uma combinação de até três chaves. É possível usar várias chaves HTTP-HEADER ou HTTP-COOKIE e apenas uma de cada tipo de chave. Para mais informações, consulte Limitação de taxa com base em várias chaves.

Observação: os dados de chave de limitação de taxa são classificados como dados de serviço, que são processados conforme descrito no Aviso de privacidade do Google Cloud. Os dados de chave de limitação de taxa não são tratados como dados do cliente. Se a carga de trabalho estiver sujeita a regimes regulamentares ou outros requisitos de conformidade que exigem transparência ou aprovação de acesso, analise os tipos de chave com valores que podem conter informações confidenciais.

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.

Quando a taxa de tráfego de um cliente está abaixo ou igual a rate_limit_threshold_count, 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_count 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.

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

• rate_limit_threshold_count: 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 é 1.000.000.
  • interval_sec: o número de segundos no intervalo de tempo. O valor precisa ser 10, 30, 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_count, 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 usar o código de resposta 429 (Too Many Requests).
  • redirect: a solicitação é redirecionada para a avaliação do reCAPTCHA 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_count. É sempre uma ação allow.

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

A ação rate_based_ban em uma regra permite que você aplique um limite por cliente para banir temporariamente clientes que excedem o limite aplicando a exceed_action configurada 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.

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_count 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_count. Nesse modo, o cliente será banido pelos ban_duration_sec segundos configurados somente se a taxa de solicitação cruzar o ban_threshold_count configurado. Se a taxa de solicitação não exceder o ban_threshold_count, as solicitações vão continuar sendo limitadas para rate_limit_threshold_count. Para a finalidade de ban_threshold_count, contabilizamos o total de solicitações do cliente, que consistem em todas as solicitações recebidas antes da limitação.

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

• rate_limit_threshold_count: 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 10, 30, 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_count, 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 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_count. É sempre uma ação allow.
• ban_threshold_count: é o número de solicitações por cliente permitido em um intervalo de tempo especificado, durante o qual o Google Cloud Armor proíbe solicitações. Se especificado, a chave será banida para o ban_duration_sec configurado quando o número de solicitações que exceder o rate_limit_threshold_count também exceder esse ban_threshold_count.
  • ban_threshold_interval_sec: o número de segundos no intervalo de tempo do ban_threshold_count. O valor precisa ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1.200, 1.800, 2.700 ou 3.600 segundos.
• 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.

Política de segurança de limitação de taxa padrão

Ao configurar uma política de segurança padrão durante a criação do balanceador de carga, o limite padrão é de 500 solicitações durante cada intervalo de um minuto (uma rate_limit_threshold_count e interval_sec de 500 e 60, respectivamente). Se você quiser selecionar um limite diferente, recomendamos usar as seguintes etapas para ajustar os parâmetros:

1. Ative o Cloud Logging e consulte o número máximo de solicitações que chegaram por endereço IP e por minuto ao longo de um dia ou mais no serviço de back-end protegido pelo Google Cloud Armor.

   Por exemplo, suponha que você acredita que 99% do tráfego de rede que você recebe não deve ser afetado pela regra de limite de taxa. Nesse cenário, recomendamos que você defina seu limite de taxa como o percentil 99 do número máximo de solicitações por endereço IP e por minuto da distribuição gerada a partir dos dados do Cloud Logging.

2. Se você ainda observar regras de limite de taxa padrão que bloqueiam tráfego legítimo, considere as seguintes etapas adicionais:

   1. Ative o armazenamento em cache (Cloud CDN ou Media CDN).
   2. Aumente o intervalo de tempo da limitação (solicitações recebidas por vários minutos, em vez de por 60 segundos)
   3. Você pode banir clientes para reduzir ainda mais o impacto de ataques após a etapa inicial. A ação rate_based_ban do Google Cloud Armor permite fazer isso banindo todos os clientes que excedem os limites muitas vezes em uma janela especificada pelo usuário. Por exemplo, os clientes que excederem os limites 10 vezes em um minuto poderão ser banidos por 15 minutos.

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

É possível aplicar a limitação de taxa a alguns recursos do reCAPTCHA 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, consulte a visão geral do gerenciamento de bots.

A seguir

• Configurar limitação de taxa