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.
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, ao configurar uma regra com uma ação de limitação, você pode alterá-la para uma ação de proibição baseada em 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 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 cujo nome é configurada. 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 do JA3 se o cliente se conectar usando
HTTPS
,HTTP/2
ouHTTP/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
configurado em
userIpRequestHeaders
e cujo valor é preenchido por uma proxy upstream. Se não houver uma configuraçãouserIpRequestHeaders
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. Você pode usar vários 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.
Como limitar o tráfego
A ação throttle
em uma regra permite aplicar uma solicitação por cliente.
para proteger os 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 é 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_count
, o Google Cloud Armor aplica oexceed_action
configurado. Os valores possíveis paraexceed_action
são os seguintes:deny(status)
: a solicitação é negada e o código de erro especificado é retornado (os valores válidos são403
,404
,429
e502
). Recomendamos usar o código de resposta429 (Too Many Requests)
.redirect
: a solicitação é redirecionada para o reCAPTCHA. avaliação ou para um URL diferente, com base naexceed_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_RECAPTCHA
ouEXTERNAL_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_count
. É sempre uma açãoallow
.
Como banir clientes com base em taxas de solicitação
A ação rate_based_ban
em uma regra permite aplicar uma restrição por cliente
limite para banir temporariamente os clientes que excederem o limite, aplicando a
configurou exceed_action
para todas as solicitações do cliente para um objeto configurável
período. 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 para o ban_duration_sec
configurado somente se o
a taxa de solicitação cruza 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_count
. Para os fins de ban_threshold_count
, o valor total
do cliente, que consistem em todas as solicitações recebidas antes da limitação,
são contados.
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 excederate_limit_threshold_count
, o Google Cloud Armor aplica oexceed_action
configurado. Os valores possíveis paraexceed_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ão403
,404
,429
e502
. Recomendamos o uso do código de resposta429 (Too Many Requests)
.redirect
: a solicitação é redirecionada para a avaliação do reCAPTCHA 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_RECAPTCHA
ouEXTERNAL_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_count
. É sempre uma açãoallow
.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 oban_duration_sec
configurado quando o número de solicitações que exceder orate_limit_threshold_count
também exceder esseban_threshold_count
.ban_threshold_interval_sec
: o número de segundos no intervalo de tempo para seuban_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íodointerval_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:
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_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 limitação de taxa a alguns recursos reCAPTCHA para reduzir o abuso de tokens e limitar a reutilização deles. 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.