Visão geral do gerenciamento de bots do Google Cloud Armor

O Google Cloud Armor e o reCAPTCHA fornecem ferramentas para ajudar você a avaliar e agir em relação a solicitações recebidas que podem ser de clientes automatizados.

O reCAPTCHA usa técnicas avançadas de análise de risco para distinguir usuários humanos de clientes automatizados. O reCAPTCHA avalia o usuário com base na configuração das chaves do site do reCAPTCHA WAF. Em seguida, ele emite um token criptografado com atributos que representam o risco associado. O Google Cloud Armor decifra esse token em linha, sem uma solicitação ou resposta adicional ao serviço reCAPTCHA. Com base nos atributos do token, o Google Cloud Armor possibilita permitir, negar, limitar a taxa ou redirecionar as solicitações recebidas. Para mais informações, consulte a visão geral da integração do Google Cloud Armor e do reCAPTCHA.

O gerenciamento de bots do Google Cloud Armor inclui os seguintes recursos integrados.

  • Desafio manual (página do teste reCAPTCHA)

    • É necessário configurar uma regra de política de segurança para redirecionar uma solicitação de teste reCAPTCHA.
    • É possível criar sua própria chave de site reCAPTCHA WAF e associá-la à sua política de segurança. É altamente recomendável que você faça isso. Para mais informações, consulte Implementar um desafio reCAPTCHA.
    • Você pode permitir apenas usuários finais que passarem no desafio manual do reCAPTCHA redirecionando os usuários finais para a avaliação do reCAPTCHA.
  • Aplique a avaliação sem atrito do reCAPTCHA

    • É possível realizar ações diferentes nas solicitações recebidas com base na avaliação do reCAPTCHA sobre o risco de uma solicitação ser originada de um bot. É possível escrever regras de política de segurança para avaliar e filtrar o tráfego com base na pontuação do token e em outros atributos do token.
    • Você precisa implementar tokens de ação reCAPTCHA, tokens de sessão ou ambos. Os tokens de ação reCAPTCHA são compatíveis com aplicativos executados em sites, iOS e Android. Os tokens de sessão reCAPTCHA são compatíveis apenas com sites. Para mais informações sobre os tokens do reCAPTCHA, consulte tokens de ação do reCAPTCHA e tokens de sessão do reCAPTCHA.
    • É necessário configurar uma regra de política de segurança que avalie os tokens de reCAPTCHA.
    • Para evitar o roubo de tokens, recomendamos associar suas próprias chaves reCAPTCHA para WAF à regra da política de segurança.

O gerenciamento de bots do Google Cloud Armor também inclui os seguintes recursos.

  • Redirecionamento (302)
    • É possível redirecionar solicitações para o URL alternativo configurado configurando o Google Cloud Armor para exibir uma resposta HTTP 302 ao cliente.
  • Decorar solicitação
    • É possível inserir cabeçalhos personalizados em solicitações e valores estáticos nesses cabeçalhos antes de fazer o proxy de uma solicitação para os back-ends.

Casos de uso

Nesta seção, descrevemos como usar os recursos de gerenciamento de bots do Google Cloud Armor para reduzir o risco de bots e controlar o acesso de clientes automatizados.

Usar um desafio manual para distinguir entre usuários legítimos e clientes automatizados

É possível redirecionar uma solicitação ao reCAPTCHA para avaliar o cliente final e exibir desafios manuais, se necessário, sem nenhuma outra implementação do reCAPTCHA. Quando usuários humanos compartilham a mesma assinatura (como caminhos de URL ou outras assinaturas L7) como um bot ou um sistema abusivo, essa ação fornece uma maneira de provar que eles são humanos. Somente os usuários que passarem na avaliação podem ter acesso ao seu serviço.

O diagrama a seguir mostra como um desafio manual distingue se uma solicitação vem de um cliente humano ou automatizado:

Exemplo de redirecionamento para o reCAPTCHA.
Exemplo de redirecionamento para o reCAPTCHA (clique para ampliar).

Suponha que um usuário Maya e um bot naveguem pela página de login (/login.html) no site. Para permitir o acesso ao Maya sem conceder acesso ao bot, configure uma regra de política de segurança com a expressão de correspondência avançada request.path.matches("/login.html"), com uma ação redirect do tipo GOOGLE_RECAPTCHA. A experiência do usuário de ponta a ponta é a seguinte:

  1. Um usuário final acessa seu site pela primeira vez.
  2. O Google Cloud Armor avalia a solicitação e determina o redirecionamento para o reCAPTCHA.
  3. O reCAPTCHA responde com uma página HTML com o JavaScript do reCAPTCHA incorporado.
  4. Quando a resposta é renderizada, o JavaScript incorporado é executado para avaliar o usuário e atende aos desafios manuais, se necessário.
    • Se o usuário for aprovado na avaliação, o reCAPTCHA emite um cookie de isenção, que é anexado automaticamente pelo navegador a cada uma das solicitações subsequentes para o mesmo site até que o cookie expire.
    • Caso contrário, o reCAPTCHA não emite um cookie de isenção.

Neste exemplo, apenas Maya passa teste reCAPTCHA e recebe um cookie de isenção, tendo acesso ao seu site.

Ao usar desafios manuais, recomendamos que você crie sua própria chave de site do WAF reCAPTCHA e associe-a à política de segurança. Isso permite visualizar as métricas reCAPTCHA associadas à chave do site e treinar um modelo de segurança específico para a chave do site. Para mais informações, consulte Criar uma chave do site para o desafio reCAPTCHA WAF.

Se você não criar e associar uma chave do site, o reCAPTCHA usará uma chave do site gerenciada pelo Google durante a avaliação. Não é possível visualizar métricas do reCAPTCHA associadas a chaves de sites que não sejam de sua propriedade, incluindo chaves de sites gerenciadas pelo Google.

Aplicar teste reCAPTCHA

Quando há um token reCAPTCHA anexado a uma solicitação recebida, o Google Cloud Armor avalia a solicitação e aplica a ação configurada com base nos atributos individuais do token. A avaliação da política de segurança do Google Cloud Armor acontece na borda da rede do Google e, portanto, seus back-ends não estão envolvidos na decodificação do token.

Tokens reCAPTCHA

O reCAPTCHA emite dois tipos de tokens: de ação e de sessão. Os dois tipos de token retornam uma pontuação para cada solicitação com base nas interações com seu site ou aplicativo. Ambos contêm atributos, incluindo uma pontuação que representa o risco associado ao usuário. Eles também contêm informações sobre a chave reCAPTCHA que você usou quando o token foi gerado.

Antes de configurar as regras da política de segurança, é preciso decidir se você quer usar tokens de ação, tokens de sessão ou ambos. Recomendamos a leitura da documentação do reCAPTCHA para fundamentar sua decisão. Para mais informações, consulte a comparação de casos de uso do reCAPTCHA.

Depois de determinar o tipo de token que você quer usar, implemente o reCAPTCHA para que o token seja anexado a uma solicitação. Para informações sobre como implementar tokens no reCAPTCHA, consulte as seguintes páginas:

Por fim, use a linguagem de regras do Google Cloud Armor para configurar regras de política de segurança e avaliar os tokens reCAPTCHA anexados à solicitação. Para evitar o roubo de tokens, é altamente recomendável associar suas chaves reCAPTCHA às regras de política de segurança. Ao associar chaves do reCAPTCHA a uma regra de política de segurança, o Google Cloud Armor realiza outra validação no token comparando a chave do reCAPTCHA no token com as chaves do reCAPTCHA associadas à regra. O Google Cloud Armor considera inválido um token com uma chave do reCAPTCHA desconhecida. Para mais informações, consulte Aplicar avaliação sem atrito do reCAPTCHA.

A figura a seguir demonstra o fluxo de aplicação do token reCAPTCHA.

Fluxo de aplicação de token reCAPTCHA.
Fluxo de aplicação do token reCAPTCHA (clique para ampliar).

Redirecionar (resposta 302)

É possível usar uma ação de redirecionamento baseado em URL para redirecionar solicitações externamente para um endpoint diferente. Você fornece um destino de redirecionamento na forma de um URL, e o Google Cloud Armor redireciona a solicitação exibindo uma resposta HTTP 302 para o cliente.

Decorar solicitação

O Google Cloud Armor pode inserir cabeçalhos de solicitação personalizados com valores estáticos definidos pelo usuário antes de enviar proxy para as solicitações ao seu aplicativo. Essa opção permite marcar solicitações suspeitas para processamento downstream alternativo, como exibir um honey-pot ou para análise e monitoramento adicionais. Esse parâmetro de ação precisa ser adicionado a uma ação allow existente.

Cabeçalhos personalizados

Se você tiver configurado o Google Cloud Armor para inserir um cabeçalho ou valor personalizado com o mesmo nome de cabeçalho de um dos cabeçalhos personalizados globais do balanceador de carga de aplicativo externo ou do balanceador de carga de aplicativo clássico, o valor do cabeçalho será substituído pelo balanceador de carga. Para mais informações, consulte Como criar cabeçalhos personalizados em serviços de back-end.

Além disso, se você escolher um nome de cabeçalho que já exista na solicitação, incluindo cabeçalhos HTTP padrão, o valor original nesse cabeçalho será substituído pelo valor definido pelo usuário fornecido para a regra do Google Cloud Armor.

Integração com limitação de taxa

As regras de limitação de taxa do Google Cloud Armor são compatíveis com os recursos de gerenciamento de bots. Por exemplo, será possível redirecionar uma solicitação de avaliação reCAPTCHA ou redirecionar para um URL diferente quando o número de solicitações exceder o limite configurado. Além disso, é possível identificar clientes para limitação de taxa com base em cookies ou tokens de isenção reCAPTCHA para limitar solicitações ou banir clientes que reutilizam ou abusam do mesmo cookie ou token a uma taxa acima do limite configurado pelo usuário.

Cookies ou tokens de isenção do reCAPTCHA com limite de taxa

Por segurança, recomendamos que você configure regras de limitação de taxa para evitar abuso de tokens por meio de vários usos por token de ação reCAPTCHA, token de sessão ou cookie de isenção exclusivos. A tabela a seguir ilustra como é possível identificar um cookie ou token de isenção reCAPTCHA como a chave em uma regra de limitação de taxa.

Resource enforce_on_key enforce_on_key_name
Cookie de isenção HTTP-COOKIE recaptcha-ca-e
Token de ação HTTP-HEADER X-Recaptcha-Token
Token da sessão HTTP-COOKIE recaptcha-ca-t

Você pode limitar solicitações ou banir clientes que dependem do mesmo cookie ou token de isenção e que excedem o limite configurado. Para mais informações sobre parâmetros de limitação de taxa, consulte Aplicar limitação de taxa.

Exemplos de limitação de taxa

Primeiro, suponha que você use somente os desafios manuais nos URLs selecionados (/login.html, por exemplo) no seu site. Para isso, configure regras de política de segurança da seguinte maneira:

  • Regra 1: se houver um cookie de isenção válido anexado à solicitação e o número de usos dele estiver abaixo do limite definido, permita a solicitação.
  • Regra 2: redirecionar a solicitação para teste reCAPTCHA.
Aplicar desafios manuais.
Aplicar desafios manuais (clique para ampliar).

Em segundo lugar, suponha que você use apenas tokens de ação ou de sessão no seu site. Por exemplo, você pode usar tokens de ação para proteger ações importantes do usuário, como /login.html. Para fazer isso, execute ações com base na pontuação do token de ação da seguinte maneira:

  • Regra 1: quando a pontuação do token de ação for maior que um limite predefinido (0.8, por exemplo), permitir a solicitação se o número de usos do token de ação estiver abaixo do limite definido.
  • Regra 2: negar a solicitação.
Aplique a avaliação do token de ação reCAPTCHA.
Aplicar a avaliação do token de ação reCAPTCHA (clique para ampliar).

É possível configurar regras de política de segurança semelhantes para aplicar a avaliação de token de sessão do reCAPTCHA.

Suponha que você combine tokens de sessão ou de ação com desafios manuais em URLs selecionados (como /login.html) e queira realizar ações com base na pontuação de token de ação. E você quer dar ao usuário uma segunda chance de resolver desafios se a pontuação não for satisfatória o suficiente. Para fazer isso, configure as regras da política de segurança da seguinte maneira:

  • Regra 1: quando a pontuação do token de ação for maior que um limite predefinido (0.8, por exemplo), permitir a solicitação se o número de usos do token de ação estiver abaixo do limite definido.
  • Regras 2 e 3: quando a pontuação do token de ação for maior que um limite predefinido diferente (0.5, por exemplo), redirecione a solicitação para teste reCAPTCHA, a menos que haja um cookie de isenção válido anexado a ela e o número de usos do cookie de isenção esteja abaixo do limite definido.
  • Regra 4: negar a solicitação.
Aplique a avaliação do token de ação reCAPTCHA com desafios manuais.
Aplicar a avaliação do token de ação reCAPTCHA com desafios manuais (clique para ampliar).

É possível configurar regras de política de segurança semelhantes para aplicar a avaliação de token de sessão de reCAPTCHA com desafios manuais.

Se você não ajustar as regras de limitação de taxa, o Google Cloud Armor não vai impor limite ao número de usos para cada cookie de isenção reCAPTCHA, token de ação e token de sessão. Para tokens de ação, recomendamos usar um limite baixo (1, por exemplo) e um intervalo de tempo alto (30 minutos, por exemplo, já que os tokens de ação são válidos por 30 minutos). É recomendável derivar o limite com base nas estatísticas de tráfego.

A seguir