Vista geral da limitação de velocidade

O Google Cloud Armor oferece capacidades para ajudar a proteger as suas Google Cloud aplicações contra uma variedade de ataques de camada 3 e camada 7. As regras baseadas em taxas ajudam a proteger as suas aplicações de um grande volume de pedidos que inundam as suas instâncias e bloqueiam o acesso a utilizadores legítimos.

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

• Impedir que um cliente específico esgote os recursos da aplicação.
• Proteja as instâncias da sua aplicação contra picos erráticos e imprevisíveis na taxa de pedidos de clientes.

Além disso, quando um recurso é apresentado com um volume elevado de tráfego de um pequeno número de clientes, pode impedir que os seus outros clientes sejam afetados por picos elevados de tráfego desse pequeno número de clientes, o que permite que os seus recursos processem o maior número possível de pedidos.

O Cloud Armor tem dois tipos de regras baseadas em taxas:

1. Limitar: pode aplicar um limite máximo de pedidos por cliente ou em todos os clientes limitando os clientes individuais a um limite configurado pelo utilizador.
2. Proibição baseada na taxa: pode limitar a taxa de pedidos que correspondem a uma regra com base no cliente e, em seguida, proibir temporariamente esses clientes durante um período configurado se excederem um limite configurado pelo utilizador.

Quando configura uma regra com uma ação de proibição baseada em taxa, não pode alterá-la posteriormente para uma ação de limitação. No entanto, quando configura uma regra com uma ação de restrição, pode alterá-la posteriormente para uma ação de proibição baseada na taxa. Para mais informações, consulte o artigo Limitação de taxa com base em várias chaves.

O Cloud Armor aplica o limite de limitação de velocidade a cada back-end associado. Por exemplo, se tiver dois serviços de back-end e configurar uma regra de limitação de taxa com um limite de 1000 pedidos por minuto, cada serviço de back-end pode receber 1000 pedidos por minuto antes de o Cloud Armor aplicar a ação da regra.

Pode pré-visualizar os efeitos das regras de limitação de taxa numa política de segurança usando o modo de pré-visualização e examinando os registos de pedidos.

Identificar clientes para a limitação de taxas

O Cloud Armor identifica clientes individuais para a limitação de taxa através dos seguintes tipos de chaves para agregar pedidos e aplicar limites de taxa:

• TUDO: uma única chave para todos os pedidos que satisfazem a condição de correspondência da regra.
• IP: uma chave única para cada endereço IP de origem do cliente cujos pedidos satisfazem a condição de correspondência da regra.
• HTTP_HEADER: uma chave exclusiva para cada valor de cabeçalho HTTP exclusivo cujo nome está configurado. O valor da chave é truncado para os primeiros 128 bytes do valor do cabeçalho. O tipo de chave é predefinido como ALL se não estiver presente nenhum cabeçalho deste tipo ou se tentar usar este tipo de chave com um equilibrador de carga de rede de proxy externo.
• XFF_IP: uma chave única 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 é predefinido para o endereço IP se não existir nenhum cabeçalho deste tipo, se o valor não for um endereço IP válido ou se tentar usar este tipo de chave com um equilibrador de carga de rede de proxy externo.
• HTTP_COOKIE: uma chave única para cada valor de cookie HTTP cujo nome está configurado. O valor da chave é truncado para os primeiros 128 bytes do valor do cookie. O tipo de chave é predefinido como ALL se não existir nenhum cookie desse tipo ou se tentar usar este tipo de chave com um equilibrador de carga de rede de proxy externo.
• HTTP_PATH: o caminho do URL do pedido HTTP. O valor da chave é truncado para os primeiros 128 bytes.
• SNI: a indicação do nome do servidor na sessão TLS do pedido HTTPS. O valor da chave é truncado para os primeiros 128 bytes. O tipo de chave é predefinido como TUDO numa sessão HTTP.
• REGION_CODE: o país/região de origem do pedido.
• TLS_JA4_FINGERPRINT: a impressão digital TLS/SSL JA4 se o cliente se ligar através de HTTPS, HTTP/2 ou HTTP/3. Se não estiver disponível, o tipo de chave é predefinido como ALL. Para mais informações acerca do JA4, consulte a referência da linguagem de regras.
• TLS_JA3_FINGERPRINT: a impressão digital JA3 TLS/SSL se o cliente se ligar através de HTTPS, HTTP/2 ou HTTP/3. Se não estiver disponível, o tipo de chave é predefinido como ALL.
• 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 a montante. Se não existir uma configuração userIpRequestHeaders ou não for possível resolver um endereço IP a partir da mesma, o tipo de chave é IP por predefinição. Para mais informações, consulte a referência de linguagem das regras.

Pode usar as chaves anteriores individualmente ou aplicar limites de taxa com base numa combinação de até três chaves. Pode usar várias chaves HTTP-HEADER ou HTTP-COOKIE e apenas um de cada outro tipo de chave. Para mais informações, consulte Limitação de taxa com base em várias chaves.

Nota: os dados da chave de limitação de taxa são classificados como dados de serviço, que são processados conforme descrito no Google Cloud Aviso de Privacidade. Os dados de chaves de limitação de taxa não são tratados como dados de clientes. Se a sua carga de trabalho estiver sujeita a regimes regulamentares ou outros requisitos de conformidade que exijam transparência de acesso ou aprovação de acesso, reveja os tipos de chaves cujos valores podem conter informações confidenciais.

Escolha entre a proibição baseada na taxa e as regras de limitação da taxa de restrição

As regras de limitação de taxa do Cloud Armor rate-based ban e throttle diferem na forma como processam o tráfego que excede o limite configurado.

• rate_based_ban: quando a taxa de pedidos excede o limite definido, o Cloud Armor bloqueia todos os pedidos adicionais da origem ou do destino desses pedidos durante um período especificado.
• throttle: em vez de bloquear todo o tráfego, a limitação de velocidade limita a taxa de pedidos a um máximo definido. Isto permite a passagem de algum tráfego, mas a uma taxa controlada que evita a sobrecarga.

A regra mais adequada depende das suas necessidades específicas e do tipo de tráfego com que está a lidar. Por exemplo, se estiver a enfrentar um ataque DDoS, uma proibição baseada na taxa pode ser mais adequada para bloquear rapidamente o tráfego malicioso. Por outro lado, se estiver a sentir um aumento repentino no tráfego legítimo, a limitação pode ser uma melhor opção para manter a disponibilidade do serviço e evitar a sobrecarga.

Limitar o tráfego

A ação throttle numa regra permite-lhe aplicar um limite por pedido do cliente para proteger os serviços de back-end. Esta regra aplica o limite máximo para limitar o tráfego de cada cliente que satisfaz as condições de correspondência na regra. O limite é configurado como um número especificado de pedidos num intervalo de tempo especificado.

Por exemplo, pode definir o limite máximo de pedidos para 2000 pedidos num período de 1200 segundos (20 minutos). Se um cliente enviar 2500 pedidos num período de 1200 segundos, aproximadamente 20% do tráfego do cliente é limitado até que o volume de pedidos permitido esteja igual ou abaixo do limite configurado.

Quando a taxa de tráfego de um cliente é inferior ou igual a rate_limit_threshold_count, os pedidos seguem a conform_action, que é sempre uma ação allow. O pedido é permitido através da política de segurança e tem autorização para chegar ao seu destino. Quando a taxa de tráfego de um cliente excede o valor rate_limit_threshold_count especificado, o Cloud Armor aplica a ação exceed_action, que pode ser deny ou redirect, para pedidos acima do limite durante o resto do intervalo do limite.

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

• rate_limit_threshold_count: o número de pedidos por cliente permitidos num intervalo de tempo especificado. O valor mínimo é 1 e o valor máximo é 1 000 000.
  • interval_sec: o número de segundos no intervalo de tempo. O valor tem de ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 ou 3600 segundos.
• exceed_action: quando um pedido excede o rate_limit_threshold_count, o Cloud Armor aplica o exceed_action configurado. Os valores possíveis para exceed_action são os seguintes:
  • deny(status): O pedido é recusado e o código de erro especificado é devolvido (os valores válidos são 403, 404, 429 e 502). Recomendamos que use o código de resposta 429 (Too Many Requests).
  • redirect: o pedido é redirecionado para uma avaliação do reCAPTCHA ou para um URL diferente, com base no parâmetro exceed_redirect_options.
• exceed_redirect_options: quando o valor de exceed_action é redirect, use este parâmetro para especificar a ação de redirecionamento:
  • type: tipo da ação de redirecionamento, GOOGLE_RECAPTCHA ou EXTERNAL_302.
  • target: URL de destino da ação de redirecionamento. Apenas aplicável quando o type é EXTERNAL_302.
• conform_action: esta é a ação realizada quando o número de pedidos é inferior ao rate_limit_threshold_count. Esta é sempre uma ação allow.

Proibir clientes com base nas taxas de pedidos

A ação rate_based_ban numa regra permite-lhe aplicar um limite por cliente para banir temporariamente clientes que excedam o limite aplicando o exceed_action configurado a todos os pedidos do cliente durante um período configurável. O limite é configurado como um número especificado de pedidos num intervalo de tempo especificado. Pode banir temporariamente o tráfego durante um período configurado pelo utilizador ('ban_duration_sec'), desde que o tráfego corresponda à condição de correspondência especificada e exceda o limite configurado.

Por exemplo, pode definir o limite máximo de pedidos para 2000 pedidos num período de 1200 segundos (20 minutos). Se um cliente enviar 2500 pedidos num período de 1200 segundos, o Cloud Armor aplica a exceed_action ao tráfego desse cliente que exceda o limite de 2000 pedidos até decorrerem os 1200 segundos completos e durante um número adicional de segundos que definir como o período de duração da proibição. Se o período de duração da proibição estiver definido como 3600, por exemplo, o tráfego do cliente seria proibido durante 3600 segundos (uma hora) após o fim do intervalo do limite.

Quando a taxa de pedidos de um cliente está abaixo do limite máximo, isto permite imediatamente que o pedido avance para o serviço de back-end. Quando a taxa de tráfego de um cliente excede o valor rate_limit_threshold_count especificado, o Cloud Armor aplica o valor exceed_action a todos os pedidos recebidos do cliente durante o resto do intervalo do limite e durante os ban_duration_sec segundos seguintes, independentemente de o limite ser excedido ou não.

Com esta configuração, é possível banir acidentalmente clientes legítimos que excedam apenas ocasionalmente a taxa de pedidos permitida. Para evitar esta situação e banir apenas os clientes que excedem frequentemente a taxa de pedidos, pode, opcionalmente, acompanhar o total de pedidos de clientes em função de uma configuração de limite adicional, de preferência, mais longo, denominada ban_threshold_count. Neste modo, o cliente é banido durante o período ban_duration_sec configurado apenas se a taxa de pedidos exceder o valor ban_threshold_count configurado. Se a taxa de pedidos não exceder ban_threshold_count, os pedidos continuam a ser limitados a rate_limit_threshold_count. Para efeitos de ban_threshold_count, são contabilizados os pedidos totais do cliente, que consistem em todos os pedidos recebidos antes da limitação.

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

• rate_limit_threshold_count: o número de pedidos por cliente permitidos num intervalo de tempo especificado. O valor mínimo é 1 pedido e o valor máximo é de 10 000 pedidos.
  • interval_sec: o número de segundos no intervalo de tempo. O valor tem de ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 ou 3600 segundos.
• exceed_action: quando um pedido excede o rate_limit_threshold_count, o Cloud Armor aplica o exceed_action configurado. Os valores possíveis para exceed_action são os seguintes:
  • deny(status): o pedido é recusado e o código de erro especificado é devolvido. Os valores válidos para o código de erro são 403, 404, 429 e 502. Recomendamos que use o código de resposta 429 (Too Many Requests).
  • redirect: o pedido é redirecionado para uma avaliação do reCAPTCHA ou para um URL diferente, com base no parâmetro exceed_redirect_options.
• exceed_redirect_options: quando o valor de exceed_action é redirect, use este parâmetro para especificar a ação de redirecionamento:
  • type: tipo da ação de redirecionamento, GOOGLE_RECAPTCHA ou EXTERNAL_302.
  • target: URL de destino da ação de redirecionamento. Apenas aplicável quando o type é EXTERNAL_302.
• conform_action: esta é a ação realizada quando o número de pedidos é inferior ao rate_limit_threshold_count. Esta é sempre uma ação allow.
• ban_threshold_count: este é o número de pedidos por cliente permitidos num intervalo de tempo especificado, acima do qual o Cloud Armor proíbe pedidos. Se for especificado, a chave é proibida para o período configurado ban_duration_sec quando o número de pedidos que excedem o limite rate_limit_threshold_count também exceder este ban_threshold_count.
  • ban_threshold_interval_sec: o número de segundos no intervalo de tempo para o seu ban_threshold_count. O valor tem de ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 ou 3600 segundos.
• ban_duration_sec: este é o número adicional de segundos durante os quais um cliente é banido após o período de interval_sec. O valor tem de ser 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 ou 3600 segundos.

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

Quando configura uma política de segurança predefinida durante a criação do equilibrador de carga, o limite predefinido é de 500 pedidos durante cada intervalo de um minuto (um rate_limit_threshold_count e um interval_sec de 500 e 60, respetivamente). Se quiser selecionar um limite diferente, recomendamos que use os seguintes passos para ajustar os parâmetros:

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

   Por exemplo, suponha que considera que 99% do tráfego de rede que recebe não deve ser afetado pela regra de limite de taxa. Neste cenário, recomendamos que defina o limite máximo da taxa para o percentil 99 do número máximo de pedidos por endereço IP e por minuto da distribuição gerada a partir dos dados do Cloud Logging.

2. Se continuar a notar que as regras de limite de taxa predefinidas estão a bloquear tráfego legítimo, considere os seguintes passos adicionais:

   1. Ative o armazenamento em cache (Cloud CDN ou Media CDN).
   2. Aumente o intervalo de tempo de limitação (pedidos recebidos por vários minutos, em vez de por 60 segundos).
   3. Pode banir clientes para reduzir ainda mais o impacto do ataque após a onda inicial. A ação rate_based_ban do Cloud Armor permite-lhe fazê-lo proibindo todos os clientes que excedam os limites demasiadas vezes num período especificado pelo utilizador. Por exemplo, os clientes que excedam os limites 10 vezes num minuto podem ser banidos durante 15 minutos.

Aplicação de limites

Os limites configurados para a restrição e as proibições baseadas em taxas são aplicados de forma independente em cada uma das Google Cloud regiões onde os seus serviços de back-end HTTP(S) estão implementados. Por exemplo, se o seu serviço estiver implementado em duas regiões, cada uma das duas regiões limita a taxa de cada chave ao limite configurado. Assim, o seu serviço de back-end pode registar volumes de tráfego agregados entre regiões que são o dobro do limite configurado. Se o limite configurado for de 5000 pedidos, o serviço de back-end pode receber 5000 pedidos de uma região e 5000 pedidos da segunda região.

No entanto, para o endereço IP do tipo de chave, é razoável assumir que o tráfego do mesmo endereço IP do cliente é direcionado para a região mais próxima da região onde os seus back-ends estão implementados. Neste caso, a limitação de velocidade pode ser considerada aplicada ao nível do serviço de back-end, independentemente das regiões em que está implementada.

É importante ter em atenção que os limites de taxa aplicados são aproximados e podem não ser rigorosamente precisos em comparação com os limites configurados. Além disso, em casos raros, devido ao comportamento de encaminhamento interno, é possível que a limitação de taxa possa ser aplicada em mais regiões do que as regiões em que está implementado, o que afeta a precisão. Por estes motivos, recomendamos que use a limitação de taxa apenas para mitigar o abuso ou manter a disponibilidade da aplicação e do serviço, e não para aplicar requisitos rigorosos de quota ou licenciamento.

Registo

O Cloud Logging regista o nome da política de segurança, a prioridade da regra de limite de taxa correspondente, o ID da regra, a ação associada e outras informações nos registos de pedidos. Para mais informações sobre o registo, consulte o artigo Usar o registo de pedidos.

Integração com o reCAPTCHA

Pode aplicar a limitação de taxa a alguns recursos do reCAPTCHA para mitigar o abuso de tokens e limitar a reutilização de tokens. Estes recursos incluem tokens de ação, tokens de sessão e cookies de isenção. Para mais informações sobre a utilização da limitação de taxa com o reCAPTCHA, consulte a vista geral da gestão de bots.

Respostas de erro personalizadas

Pode aplicar respostas de erro personalizadas à limitação de taxa do Cloud Armor, incluindo tráfego throttle e rate_based_ban. Quando estes limites são aplicados, são enviadas mensagens de erro personalizadas aos utilizadores finais. Além disso, pode configurar respostas de erro personalizadas para códigos de estado HTTP específicos gerados por balanceadores de carga ou instâncias de back-end quando usa um balanceador de carga de aplicações externo global.

Para mais informações sobre respostas de erro personalizadas, consulte a Vista geral das respostas de erro personalizadas. Para configurar respostas de erro personalizadas, consulte o artigo Configure respostas de erro personalizadas.

Cloud Armor com Cloud Service Mesh

Nota: a ação de limitação de taxa fairshare só está disponível para regras nas políticas de segurança de serviços internos.

Pode configurar políticas de segurança de serviços internos para a sua malha de serviços de modo a aplicar limites de taxa globais do lado do servidor por cliente, o que ajuda a partilhar de forma justa a capacidade disponível do seu serviço e a mitigar o risco de clientes maliciosos ou com comportamento inadequado sobrecarregarem os seus serviços. Anexa uma política de segurança a uma política de pontos finais do Cloud Service Mesh para aplicar limites de taxa ao tráfego de entrada no lado do servidor. No entanto, não pode configurar uma política de segurança do Google Cloud Armor se estiver a usar o encaminhamento de tráfego TCP. Para mais informações sobre a utilização do Cloud Armor com a malha de serviços do Google Cloud, consulte o artigo Configure a limitação de taxa com o Cloud Armor.

O que se segue?

• Configure a limitação de taxa