O Google Cloud Armor e o reCAPTCHA oferecem ferramentas que ajudam a avaliar e a tomar medidas em relação a pedidos recebidos que possam ser de clientes automatizados.
O reCAPTCHA usa técnicas avançadas de análise de risco para distinguir entre utilizadores humanos e clientes automatizados. O reCAPTCHA avalia o utilizador com base na configuração das chaves de site do reCAPTCHA WAF. Em seguida, emite um token encriptado com atributos que representam o risco associado. O Cloud Armor decifra este token em linha, sem um pedido ou uma resposta adicionais ao serviço reCAPTCHA. Com base nos atributos do token, o Cloud Armor permite-lhe permitir, recusar, limitar a taxa ou redirecionar os pedidos recebidos. Para mais informações, consulte a vista geral da integração do Cloud Armor e do reCAPTCHA.
A gestão de bots do Cloud Armor inclui as seguintes capacidades integradas.
Desafio manual (página de desafio reCAPTCHA)
- Tem de configurar uma regra de política de segurança para redirecionar um pedido de avaliação do reCAPTCHA.
- Pode criar a sua própria chave de site do WAF do reCAPTCHA e associá-la à sua política de segurança. Recomendamos vivamente que o faça. Para mais informações, consulte o artigo Implemente um desafio reCAPTCHA.
- Pode permitir apenas utilizadores finais que passem o desafio manual do reCAPTCHA redirecionando os utilizadores finais para a avaliação do reCAPTCHA.
Aplique a avaliação sem atrito do reCAPTCHA
- Pode tomar diferentes medidas em pedidos recebidos com base na avaliação do reCAPTCHA do risco de o pedido ter origem num bot. Pode escrever regras de política de segurança para avaliar e filtrar o tráfego com base na pontuação do token e noutros atributos do token.
- Tem de implementar tokens de ação, tokens de sessão ou ambos do reCAPTCHA. Os tokens de ação do reCAPTCHA são suportados em aplicações executadas em Websites, iOS e Android. Os tokens de sessão do reCAPTCHA só são suportados em Websites. Para mais informações acerca dos tokens reCAPTCHA, consulte os tokens de ação do reCAPTCHA e os tokens de sessão do reCAPTCHA.
- Tem de configurar uma regra de política de segurança que avalie os tokens do reCAPTCHA.
- Para evitar o roubo de tokens, recomendamos que associe as suas próprias chaves do reCAPTCHA para WAF à regra da política de segurança.
A gestão de bots do Cloud Armor também inclui as seguintes capacidades.
- Redirecionamento (302)
- Pode redirecionar pedidos para o URL alternativo configurado configurando o Cloud Armor para publicar uma resposta HTTP 302 ao cliente.
- Pedido de decoração
- Pode inserir cabeçalhos personalizados em pedidos e valores estáticos nesses cabeçalhos antes de encaminhar pedidos para os seus back-ends.
Exemplos de utilização
Esta secção descreve como pode usar as capacidades de gestão de bots do Cloud Armor para mitigar o risco de bots e controlar o acesso de clientes automatizados.
Use um desafio manual para distinguir entre utilizadores legítimos e clientes automatizados
Pode redirecionar um pedido para o reCAPTCHA para avaliar o cliente final e apresentar desafios manuais, se necessário, sem qualquer implementação adicional do reCAPTCHA. Quando os utilizadores humanos partilham a mesma assinatura (como caminhos de URL ou outras assinaturas da camada 7) que um bot ou um sistema abusivo, esta ação permite-lhes provar que são humanos. Apenas os utilizadores que passarem na avaliação podem aceder ao seu serviço.
O diagrama seguinte mostra como um desafio manual distingue se um pedido é proveniente de um humano ou de um cliente automatizado:
Suponhamos que uma utilizadora, a Maya, e um bot estão a navegar na página de início de sessão (/login.html) no seu site. Para permitir o acesso ao Maya sem conceder acesso ao bot, pode configurar 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 utilizador completa é a seguinte:
- Um utilizador final visita o seu site pela primeira vez.
- O Cloud Armor avalia o pedido e determina que o redireciona para o reCAPTCHA.
- O reCAPTCHA responde com uma página HTML com o JavaScript do reCAPTCHA incorporado.
- Quando a resposta é renderizada, o JavaScript incorporado é executado para avaliar o utilizador e publica desafios manuais, se necessário.
- Se o utilizador passar na avaliação, o reCAPTCHA emite um cookie de isenção, que é anexado automaticamente pelo navegador a cada um dos pedidos subsequentes ao mesmo site até o cookie expirar.
- Caso contrário, o reCAPTCHA não emite um cookie de isenção.
Neste exemplo, apenas a Maya passa na avaliação do reCAPTCHA e recebe um cookie de isenção, obtendo acesso ao seu site.
Quando usa desafios manuais, recomendamos que crie a sua própria chave do site do reCAPTCHA WAF e a associe à política de segurança. Isto permite-lhe ver as métricas do reCAPTCHA associadas à chave de site e formar um modelo de segurança específico para a chave de site. Para mais informações, consulte o artigo Crie uma chave de site de desafio do WAF do reCAPTCHA.
Se não criar nem associar uma chave de site, o reCAPTCHA usa uma chave de site gerida pela Google durante a avaliação. Não pode ver métricas do reCAPTCHA associadas a chaves de site que não lhe pertencem, incluindo chaves de site geridas pela Google.
Aplique a avaliação do reCAPTCHA
Quando existe um token do reCAPTCHA anexado a um pedido recebido, o Cloud Armor avalia o pedido e aplica a ação configurada com base nos atributos individuais no token. A avaliação da política de segurança do Cloud Armor ocorre no limite da rede da Google, pelo que os seus back-ends não estão envolvidos na descifragem do token.
Tokens do reCAPTCHA
O reCAPTCHA emite dois tipos de tokens: tokens de ação e tokens de sessão. Ambos os tipos de tokens devolvem uma pontuação para cada pedido com base nas interações com o seu site ou app. Ambos os tipos de tokens contêm atributos, incluindo uma pontuação que representa o risco associado ao utilizador. Também contêm informações sobre a chave do reCAPTCHA que usou quando o token foi gerado.
Antes de configurar as regras da política de segurança, tem de decidir se quer usar tokens de ação, tokens de sessão ou ambos. Recomendamos que leia a documentação do reCAPTCHA para tomar uma decisão informada. Para mais informações, consulte a comparação de exemplos de utilização do reCAPTCHA.
Depois de determinar que tipo de token quer usar, implemente o reCAPTCHA para que o token seja anexado a um pedido. Para informações sobre a implementação de tokens no reCAPTCHA, consulte as seguintes páginas:
- Apps Web
- Aplicações para dispositivos móveis
Por fim, use a linguagem de regras do Cloud Armor para configurar regras de políticas de segurança para avaliar tokens do reCAPTCHA anexados ao pedido. Para evitar o roubo de tokens, recomendamos vivamente que associe as suas chaves do reCAPTCHA às regras da sua política de segurança. Quando associa chaves do reCAPTCHA a uma regra de política de segurança, o Cloud Armor executa uma validação adicional no token comparando a chave do reCAPTCHA no token com as chaves do reCAPTCHA associadas à regra. O Cloud Armor considera um token com uma chave reCAPTCHA desconhecida como inválido. Para mais informações, consulte o artigo Aplique a avaliação sem atrito do reCAPTCHA.
A figura seguinte demonstra o fluxo de aplicação do token reCAPTCHA.
Redirecionamento (resposta 302)
Pode usar uma ação de redirecionamento baseada em URL para redirecionar externamente pedidos para um ponto final diferente. Fornece um destino de redirecionamento sob a forma de um URL e o Cloud Armor redireciona o pedido através da publicação de uma resposta HTTP 302 ao cliente.
Pedido de decoração
O Cloud Armor pode inserir cabeçalhos de pedidos personalizados com valores estáticos definidos pelo utilizador antes de encaminhar os pedidos para a sua aplicação. Esta opção permite-lhe etiquetar pedidos suspeitos para processamento a jusante alternativo, como publicar um honeypot, ou para análise e monitorização adicionais. Tenha em atenção que este parâmetro de ação tem de ser adicionado a uma ação allow existente.
Cabeçalhos personalizados
Se configurou o Cloud Armor para inserir um cabeçalho ou um valor personalizado com o mesmo nome de cabeçalho que um dos cabeçalhos personalizados para o Application Load Balancer externo global ou o Application Load Balancer clássico, o valor do cabeçalho é substituído pelo balanceador de carga. Para mais informações, consulte o artigo Criar cabeçalhos personalizados em serviços de back-end.
Além disso, se escolher um nome de cabeçalho que já exista no pedido, incluindo cabeçalhos HTTP padrão, o valor original nesse cabeçalho é substituído pelo valor definido pelo utilizador fornecido à regra do Cloud Armor.
Integre com a limitação de velocidade
As regras de limitação de taxa do Cloud Armor são compatíveis com as capacidades de gestão de bots. Por exemplo, pode redirecionar um pedido de avaliação do reCAPTCHA ou redirecionar para um URL diferente quando o número de pedidos excede o limite configurado. Além disso, pode identificar clientes para limitar a taxa com base em cookies ou tokens de isenção do reCAPTCHA, para restringir pedidos ou banir clientes que reutilizam ou abusam do mesmo cookie ou token a uma taxa que excede o limite configurado pelo utilizador.
Limite a taxa de cookies ou tokens de isenção do reCAPTCHA
Por motivos de segurança, recomendamos que configure regras de limitação de taxa para impedir o abuso de tokens através de várias utilizações por token de ação, token de sessão ou cookie de isenção reCAPTCHA únicos. A tabela seguinte ilustra como pode identificar um cookie ou um token de isenção do reCAPTCHA como a chave numa regra de limitação de taxa.
| Recurso | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| Cookie de isenção | HTTP-COOKIE |
recaptcha-ca-e |
| Action-token | HTTP-HEADER |
X-Recaptcha-Token |
| Session-token | HTTP-COOKIE |
recaptcha-ca-t |
Pode limitar as solicitações ou banir clientes que dependam do mesmo cookie ou token de isenção e que excedam o limite configurado. Para mais informações acerca dos parâmetros de limitação de taxa, consulte Aplique a limitação de taxa.
Exemplos de limitação de velocidade
Primeiro, suponha que só usa desafios manuais em URLs selecionados (/login.html, por exemplo) no seu site. Para isso, configure as regras da política de segurança da seguinte forma:
- Regra 1: se existir um cookie de isenção válido anexado ao pedido e o número de utilizações do cookie de isenção estiver abaixo do limite definido, permita o pedido.
- Regra 2: redirecione o pedido de avaliação do reCAPTCHA.
Em segundo lugar, suponha que usa apenas tokens de ação ou tokens de sessão no seu site.
Por exemplo, pode usar tokens de ação para proteger ações de utilizadores de relevo, como /login.html. Para o fazer, tome medidas com base na pontuação do action-token da seguinte forma:
- Regra 1: quando a pontuação do token de ação for superior a um limite predefinido (
0.8, por exemplo), permita o pedido se o número de utilizações do token de ação estiver abaixo do limite definido. - Regra 2: negar o pedido.
Pode configurar regras de políticas de segurança semelhantes para aplicar a avaliação do token de sessão do reCAPTCHA.
Em terceiro lugar, suponha que combina tokens de ação ou tokens de sessão com desafios manuais
em URLs selecionados (como /login.html) no seu site e quer tomar medidas
com base na pontuação do token de ação. Além disso, quer dar ao utilizador uma segunda oportunidade resolvendo desafios se a pontuação não for suficientemente satisfatória. Para o fazer,
configure as regras da política de segurança da seguinte forma:
- Regra 1: quando a pontuação do token de ação for superior a um limite predefinido (
0.8, por exemplo), permita o pedido se o número de utilizações do token de ação estiver abaixo do limite definido. - Regras 2 e 3: quando a pontuação do token de ação é superior a um limite
predefinido diferente (por exemplo,
0.5), redirecione o pedido para avaliação do reCAPTCHA, a menos que exista um cookie de isenção válido anexado ao pedido e o número de utilizações do cookie de isenção seja inferior ao limite definido. - Regra 4: negar o pedido.
Pode configurar regras de política de segurança semelhantes para aplicar a avaliação de tokens de sessão do reCAPTCHA com desafios manuais.
Se não ajustar as regras de limitação de taxa, o Cloud Armor não impõe nenhum limite ao número de utilizações para cada cookie de isenção do reCAPTCHA, token de ação e token de sessão. Para tokens de ação, recomendamos que use um limite baixo (por exemplo, 1) e um intervalo de tempo elevado (por exemplo, 30 minutos, uma vez que os tokens de ação são válidos durante 30 minutos). Recomendamos que derive o limite com base nas estatísticas de tráfego.