O Google Cloud Armor e o reCAPTCHA Enterprise fornecem ferramentas para ajudar você a avaliar e agir em solicitações recebidas que podem ser de clientes automatizados.
O reCAPTCHA Enterprise usa técnicas avançadas de análise de risco para distinguir usuários humanos de clientes automatizados. O reCAPTCHA Enterprise 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 Enterprise. Com base nos atributos do token, o Google Cloud Armor possibilita permitir, negar, limitar a taxa ou redirecionar as solicitações recebidas. Saiba mais na visão geral da integração do Google Cloud Armor com o reCAPTCHA Enterprise.
O gerenciamento de bots do Google Cloud Armor inclui os seguintes recursos integrados.
Desafio manual (página do teste reCAPTCHA)
- É preciso configurar uma regra de política de segurança para redirecionar uma solicitação de avaliação do reCAPTCHA Enterprise.
- É possível criar sua própria chave de site do reCAPTCHA Enterprise para 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.
- Só é possível permitir usuários finais que passem no desafio manual do reCAPTCHA Enterprise se redirecionarem os usuários finais para avaliação do reCAPTCHA Enterprise.
Aplique avaliações mais fáceis do reCAPTCHA Enterprise
- É possível realizar ações diferentes em solicitações recebidas com base na avaliação do reCAPTCHA Enterprise 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 do reCAPTCHA Enterprise: de ação, de sessão 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.
- Você precisa configurar uma regra de política de segurança que avalie os tokens do reCAPTCHA Enterprise.
- Para evitar o roubo de tokens, recomendamos associar suas próprias chaves do reCAPTCHA Enterprise para WAF à sua regra de 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 para o reCAPTCHA Enterprise para avaliar o cliente final e atender aos desafios manuais, se necessário, sem nenhuma outra implementação do reCAPTCHA Enterprise. 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:
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:
- Um usuário final acessa seu site pela primeira vez.
- O Google Cloud Armor avalia a solicitação e determina redirecioná-la para o reCAPTCHA Enterprise.
- O reCAPTCHA Enterprise responde com uma página HTML com o reCAPTCHA Enterprise JavaScript incorporado.
- 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 Enterprise emitirá um cookie de isenção, que é anexado automaticamente pelo navegador a cada uma das solicitações subsequentes ao mesmo site até que o cookie expire.
- Caso contrário, o reCAPTCHA Enterprise não emitirá um cookie de isenção.
Neste exemplo, apenas a Maya passa na avaliação do reCAPTCHA Enterprise e recebe um cookie de isenção, com acesso ao 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, você pode ver as métricas do reCAPTCHA Enterprise associadas à chave do site e treinar um modelo de segurança específico para ela. 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 Enterprise 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 avaliação do reCAPTCHA Enterprise
Quando há um token do reCAPTCHA Enterprise 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 do reCAPTCHA Enterprise
O reCAPTCHA Enterprise 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 do reCAPTCHA Enterprise 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 Enterprise para informar sua decisão. Para mais informações, consulte a comparação de casos de uso do reCAPTCHA Enterprise.
Depois de determinar qual tipo de token você quer usar, execute a implementação do reCAPTCHA Enterprise para que o token seja anexado com uma solicitação. Para informações sobre como implementar tokens no reCAPTCHA Enterprise, consulte as seguintes páginas:
- Aplicativos da Web
- Apps para dispositivos móveis
Por fim, use a linguagem de regras do Google Cloud Armor para configurar regras de políticas de segurança e avaliar os tokens reCAPTCHA Enterprise anexados à solicitação. Para evitar o roubo de tokens, recomendamos associar suas chaves do reCAPTCHA Enterprise à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 teste do reCAPTCHA Enterprise sem complicação.
A figura a seguir demonstra o fluxo de aplicação de tokens reCAPTCHA Enterprise.
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 a avaliação do reCAPTCHA Enterprise ou 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 do reCAPTCHA Enterprise 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 Enterprise 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 identificar um cookie ou token de isenção do reCAPTCHA Enterprise como a chave em uma regra 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: redireciona a solicitação para a avaliação do reCAPTCHA Enterprise.
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.
É possível configurar regras de políticas de segurança semelhantes para aplicar a avaliação do token de sessão reCAPTCHA Enterprise.
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 avaliação do reCAPTCHA Enterprise, 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 esteja abaixo do limite definido. - Regra 4: negar a solicitação.
É possível configurar regras de políticas de segurança semelhantes para aplicar a avaliação do token de sessão reCAPTCHA Enterprise 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
- Configurar o gerenciamento de bots
- Ver a referência da linguagem de regras
- Ver registros
- Resolver problemas