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

O Google Cloud Armor e o reCAPTCHA oferecem ferramentas para ajudar você a avaliar e agir em 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 WAF do reCAPTCHA. Em seguida, ele emite um token criptografado com atributos que representam o risco associado. O Google Cloud Armor decodifica esse token in-line sem uma solicitação ou resposta adicional para o 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 as 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)

    • Você precisa configurar uma regra de política de segurança para redirecionar uma solicitação de avaliação do reCAPTCHA.
    • É possível criar sua própria chave de site reCAPTCHA WAF e associar com sua política de segurança. É altamente recomendável que você faça isso. Para mais informações, consulte Implementar um desafio reCAPTCHA.
    • Só é possível permitir usuários finais que passem no desafio manual do reCAPTCHA se redirecionarem os usuários finais para avaliação do reCAPTCHA.
  • Aplique a avaliação sem atrito do reCAPTCHA

    • É possível realizar ações diferentes em solicitações recebidas com base na avaliação do reCAPTCHA do risco de origem de uma solicitação 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.
    • É preciso implementar tokens de ação ou de sessão do reCAPTCHA, ou ambos. Os tokens de ação do reCAPTCHA são compatíveis com aplicativos executados em sites, no iOS e Android. Os tokens de sessão do reCAPTCHA são aceitos apenas em sites. Para mais informações sobre os tokens do reCAPTCHA, consulte tokens de ação do reCAPTCHA e tokens de sessão do reCAPTCHA.
    • Configure uma regra de política de segurança que avalie os tokens do reCAPTCHA.
    • Para evitar o roubo de tokens, recomendamos que você associe seu próprio token Chaves reCAPTCHA para WAF com sua regra de política de segurança.

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

  • Redirecionar (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 para o reCAPTCHA para avaliar o cliente final e atender aos 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 redirecioná-la para o reCAPTCHA.
  3. O reCAPTCHA responde com uma página HTML 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 passar na avaliação, o reCAPTCHA emite uma de isenção, que é anexado automaticamente pelo navegador a cada um as solicitações subsequentes para o mesmo site até que o cookie expire.
    • Caso contrário, o reCAPTCHA não emitirá um cookie de isenção.

Neste exemplo, apenas Maya passa teste reCAPTCHA e recebe um cookie de isenção, obtendo 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. Assim, é possível visualizar métricas reCAPTCHA associadas aos e treinar um modelo de segurança específico para essa chave. Para mais informações, consulte Criar uma chave do site para o desafio reCAPTCHA WAF.

Se você não criar e associar uma chave de site, o reCAPTCHA usará uma chave de 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 do 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 no 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: tokens de ação e tokens 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 ao gerar o token.

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 que você leia a documentação do reCAPTCHA para informar sua decisão. Para mais mais informações, consulte a Comparação de casos de uso de reCAPTCHA.

Depois de determinar o tipo de token que você quer usar, implemente reCAPTCHA para o token a ser anexado a um 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 a segurança regras de política para avaliar os tokens reCAPTCHA anexados com a solicitação. Para evitar o roubo de tokens, é altamente recomendável associar as chaves reCAPTCHA às suas 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 a avaliação sem atrito do reCAPTCHA (link em inglês).

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

Fluxo de aplicação de token reCAPTCHA.
Fluxo de aplicação de 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, é possível redirecionar uma solicitação para o reCAPTCHA ou redirecionar para outro URL quando o número de solicitações ultrapassar o limite configurado. Além disso, é possível identificar clientes para limitação de taxa com base em cookies ou tokens de isenção do reCAPTCHA para limitar solicitações ou banir clientes que reutilizam ou abusam do mesmo cookie ou token a uma taxa que excede o limite configurado de usuários.

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 um de limitação de taxa.

Recurso 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 do 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 Avaliação do token de sessão 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 é maior que a de um token predefinido diferente limite (0.5, por exemplo), redirecione a solicitação para Teste reCAPTCHA, a menos que haja um cookie de isenção válido anexado à solicitação, e o número de usos do cookie de isenção é 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íticas de segurança semelhantes para aplicar a avaliação do token de sessão 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