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:
- 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.
- 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.
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 de 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 exclusivo de cabeçalho HTTP com um 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 um 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: país/região de origem da solicitação.
- TLS_JA3_FINGERPRINT: impressão digital TLS/SSL do JA3 se o cliente se conectar usando
HTTPS,HTTP/2ouHTTP/3. Se não estiver disponível, o tipo de chave será definido como ALL por padrão. Para mais informações sobre o JA3, consulte a referência de linguagem de regras. - USER_IP: o endereço IP do cliente de origem, incluído nos cabeçalhos
configurados em
userIpRequestHeaderse com valor preenchido por um proxy upstream. Se não houver configuraçãouserIpRequestHeadersou se um endereço IP não puder ser resolvido a partir dele, o tipo de chave será IP por padrão. Para mais informações, consulte a referência de linguagem das 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 umas das outras. Para mais informações, consulte Limitação de taxa com base em várias chaves.
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 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 excederate_limit_threshold, o Google Cloud Armor aplica oexceed_actionconfigurado. Os valores possíveis paraexceed_actionsão os seguintes:deny(status): a solicitação é negada e o código de erro especificado é retornado (os valores válidos são403,404,429e502). Recomendamos usar o código de resposta429 (Too Many Requests).redirect: a solicitação é redirecionada para a avaliação do reCAPTCHA Enterprise ou para outro URL com base no parâmetroexceed_redirect_options.
exceed_redirect_options: quandoexceed_actionéredirect, use esse parâmetro para especificar a ação de redirecionamento:type: digite para a ação de redirecionamento,GOOGLE_RECAPTCHAouEXTERNAL_302.target: o destino do URL da ação de redirecionamento. Aplicável somente quando otypeéEXTERNAL_302.
conform_action: é a ação realizada quando o número de solicitações está abaixo derate_limit_threshold. É sempre uma açãoallow.
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 em uma regra permite aplicar um limite por cliente
para banir temporariamente clientes que excedem o limite aplicando o
exceed_action configurado para todas as solicitações do cliente 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 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 excederate_limit_threshold, o Google Cloud Armor aplica oexceed_actionconfigurado. Os valores possíveis paraexceed_actionsã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ão403,404,429e502. Recomendamos o uso do código de resposta429 (Too Many Requests).redirect: a solicitação é redirecionada para a avaliação do reCAPTCHA Enterprise ou para outro URL com base no parâmetroexceed_redirect_options.
exceed_redirect_options: quandoexceed_actionéredirect, use esse parâmetro para especificar a ação de redirecionamento:type: digite para a ação de redirecionamento,GOOGLE_RECAPTCHAouEXTERNAL_302.target: o destino do URL da ação de redirecionamento. Aplicável somente quando otypeéEXTERNAL_302.
conform_action: é a ação realizada quando o número de solicitações está abaixo derate_limit_threshold. É sempre uma açãoallow.ban_threshold_count: é o número de solicitações por cliente em que o Google Cloud Armor proíbe solicitações. Se especificado, a chave será banida para oban_duration_secconfigurado quando o número de solicitações que excedem orate_limit_threshold_counttambém excederem esseban_threshold_count.ban_duration_sec: este é o número adicional de segundos em que um cliente é banido após o término do períodointerval_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_count. Nesse modo,
o cliente será banido para o ban_duration_sec configurado somente se a
taxa de solicitação ultrapassar o ban_threshold_count configurado. Se a taxa de solicitação
não exceder ban_threshold_count, as solicitações continuarão sendo limitadas
para rate_limit_threshold. Para a finalidade de ban_threshold_count, é contado o total de solicitações do cliente, que consiste em todas as solicitações recebidas antes da limitação.
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 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:
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.
Se você ainda observar regras de limite de taxa padrão que bloqueiam tráfego legítimo, considere as seguintes etapas adicionais:
- Ative o armazenamento em cache (Cloud CDN ou Media CDN).
- Aumente o intervalo de tempo da limitação (solicitações recebidas por vários minutos, em vez de por 60 segundos)
- Você pode banir clientes para reduzir ainda mais o impacto de ataques após a
etapa inicial. A ação
rate_based_bando 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.
Geração de registros
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.