Esta página fornece as práticas recomendadas para otimizar e ajustar implantações do Google Cloud Armor.
O Google Cloud Armor é implantado com o balanceador de carga de aplicativo externo global, o balanceador de carga de aplicativo clássico ou o balanceador de carga de rede de proxy externo. Ao implantar o Google Cloud Armor, você anexa uma política de segurança ao serviço de back-end do balanceador de carga que quer proteger. Uma política de segurança consiste em um conjunto de regras personalizadas e pré-configuradas que você determina.
Política de segurança e criação de regras
As seções a seguir contêm práticas recomendadas e recomendações para novas políticas e regras de segurança.
Fornecer descrições de regras
Use descrições de regras para fornecer mais contexto sobre por que cada regra foi criada e a função pretendida da regra. O campo description é limitado a 64 caracteres. Por isso, a referência ao banco de dados de gerenciamento de configuração ou outros repositórios é a maneira mais eficiente de capturar contexto.
Considerar o espaçamento prioritário
Quando você configurar inicialmente as regras, deixe um intervalo de pelo menos 10 entre cada valor de prioridade de regra. Por exemplo, as duas primeiras regras em uma política de segurança podem ter as prioridades 20 e 30. Isso permite que você insira mais regras quando precisar delas. Além disso, recomendamos que você agrupe regras semelhantes em blocos, deixando intervalos maiores entre os grupos.
Usar o modo de visualização
As regras de política de segurança, incluindo as assinaturas do Open Web Application Security Project (OWASP), podem causar efeitos imprevisíveis no app. Use o modo de visualização para avaliar se a introdução de uma regra terá um impacto negativo no tráfego de produção.
Ativar a Proteção adaptável do Google Cloud Armor
Ative a Proteção adaptável para aumentar a proteção dos seus apps. A Proteção adaptável monitora o tráfego e, conforme necessário, recomenda novas regras para suas políticas de segurança. Além disso, recomendamos implementar uma política de alertas para garantir que as pessoas certas sejam alertadas sobre possíveis ataques. A Proteção adaptável é mais adequada para proteção volumétrica. Ataques que não são volumétricos podem não acionar a Proteção adaptável.
Ativar a análise JSON
Se o app enviar conteúdo JSON no corpo de solicitações POST,
ative a análise JSON. Se você não ativar a análise JSON,
o Google Cloud Armor não analisará o conteúdo JSON dos corpos POST para
regras WAF pré-configuradas, e os resultados poderão ter ruídos e gerar falsos
positivos. Para mais informações, consulte
Análise JSON.
Testar a lógica
Uma regra é acionada quando a condição de correspondência é avaliada como verdadeira. Por exemplo, a
condição de correspondência origin.region_code == 'AU' será avaliada como verdadeira se o código da
região da solicitação for AU. Se uma regra de prioridade mais alta for avaliada como verdadeira, a
ação em uma regra de prioridade mais baixa será ignorada. No exemplo a seguir,
imagine que você quer criar uma política de segurança para bloquear usuários da região
AU, exceto para o tráfego dentro do intervalo de endereços IP 10.10.10.0/24. Considere
a seguinte política de segurança com duas regras:
Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2
Neste exemplo, Rule1 permite o tráfego proveniente do intervalo de endereços IP
10.10.10.0/24. Como Rule1 é a regra de maior prioridade, esse tráfego
é permitido antes de ser avaliado em relação a Rule2. Isso significa que
o Google Cloud Armor não o avalia em relação a Rule2 (ou qualquer outra
regra restante).
Ao criar políticas do Google Cloud Armor, teste a lógica de suas regras para garantir o comportamento pretendido. Para isso, é recomendável gerar tráfego sintético para entender quais regras estão bloqueando o tráfego e verificar se os resultados são consistentes com as decisões de design das regras. Se você não tiver certeza de como uma solicitação pode passar pelo sistema, use o modo de visualização para ver qual regra corresponde à solicitação.
Identificar os endereços IP de origem dos seus verificadores
Seus verificadores de segurança podem estar localizados dentro ou fora do Google. Se você quiser uma avaliação externa e não filtrada do aplicativo, poderá permitir explicitamente o tráfego com base no endereço IP (ou em outro token) antes de avaliá-lo em relação a outras regras.
Agrupar e classificar regras na sua política de segurança
Seus aplicativos podem atender a diferentes subconjuntos de clientes. No exemplo a seguir, você quer negar o tráfego de determinadas áreas geográficas ou intervalos de IP e, portanto, configura a primeira regra na política para negar esse tráfego. Além disso, você quer permitir explicitamente algum tráfego no aplicativo sem que a política de segurança o processe. Neste exemplo, recomendamos a seguinte estrutura de prioridade de regra, da prioridade mais alta à mais baixa:
- Regras de negação explícitas (ASN, região, intervalos de IP)
- Regras de permissão explícitas confiáveis (verificadores, sistemas confiáveis: uso com cautela)
- Regras de segurança (OWASP, regras personalizadas)
- Regras de permissão explícitas (ASN, presença de valor de cabeçalho, intervalo de IP)
- Regras de negação padrão
Usar o reCAPTCHA Enterprise para gerenciamento de bots
O Google Cloud Armor se integra ao reCAPTCHA Enterprise do Google para detecção de bots na camada WAF. Nessa integração, o reCAPTCHA Enterprise gera tokens reCAPTCHA, e o Google Cloud Armor executa o processo de avaliação de tokens em vez do reCAPTCHA Enterprise. Isso reduz a carga da origem, possivelmente reduzindo os custos, e deixa os controles de segurança mais próximos do usuário final do que dos back-ends. Para mais informações, consulte a visão geral de gerenciamento de bots.
Definir limites de limitação da taxa
A limitação de taxa é uma funcionalidade flexível e valiosa para evitar abuso e mitigar ameaças de alto volume, como preenchimento de credenciais ou ataques L7 de DDoS. Quando você implanta a limitação de taxa pela primeira vez, é importante escolher um limite que faça sentido para o aplicativo. Recomendamos que você comece a aplicar o modo de visualização. Ao analisar e entender o perfil de tráfego, é possível ajustar os parâmetros de limitação de taxa. Além disso, é importante considerar a prioridade que você atribui à regra de limitação de taxa. O tráfego pode ser explicitamente permitido ou negado por uma regra de prioridade mais alta antes de ser avaliado em relação à regra de limitação de taxa.
Ajuste de regras
Os aplicativos da Web podem permitir solicitações que parecem ser ataques e podem permitir ou até exigir que os usuários enviem solicitações correspondentes às assinaturas nas regras WAF pré-configuradas. É fundamental que você valide as regras do Google Cloud Armor em relação ao aplicativo e resolva todas as descobertas que não sejam relevantes para o aplicativo antes de promovê-la. Para isso, desative o modo de visualização em um aplicativo de produção. As seções a seguir contêm práticas recomendadas e recomendações para ajustar as regras WAF pré-configuradas.
Escolher o nível de sensibilidade da regra WAF pré-configurada
Ao implementar qualquer uma das regras WAF pré-configuradas, é possível escolher um nível de sensibilidade adequado com base nos cronogramas e requisitos de segurança. Recomendamos que você comece com um nível de confidencialidade 1 para a maioria dos aplicativos que precisam atender aos requisitos de segurança da sua organização. As regras configuradas para a sensibilidade 1 usam assinaturas de alta fidelidade e reduzem o potencial de ruído da regra. Assinaturas associadas a níveis mais altos de sensibilidade podem detectar e impedir um conjunto maior de tentativas de exploração, à custa de ruídos potenciais para alguns apps protegidos. No entanto, as cargas de trabalho sujeitas a requisitos de segurança mais rigorosos podem preferir o nível mais alto de confidencialidade. Nesses casos de uso, pode haver uma grande quantidade de ruído ou descobertas irrelevantes, que precisam ser ajustadas antes da política de segurança entrar em produção.
Ativar o registro detalhado
Se você precisar de mais informações sobre quais atributos de solicitação e payloads estão acionando uma regra WAF específica, ative o registro detalhado. A geração de registros detalhados fornece detalhes de solicitações que acionam regras específicas, incluindo um snippet da parte ofensiva da solicitação, o que é útil para solucionar problemas e ajustar o Google Cloud Armor. Como a geração de registros detalhados pode fazer com que o conteúdo da solicitação do usuário final seja registrado no Cloud Logging, é possível acumular PII de usuário final nos seus registros. Como resultado, não recomendamos executar cargas de trabalho de produção com o registro detalhado ativado por longos períodos.
Usar regras estáveis ou canário
Há dois tipos de regras WAF pré-configuradas do Google Cloud Armor: estável e canário. Quando novas regras são adicionadas ao conjunto de regras principais (CRS, na sigla em inglês) do ModSecurity, as publicamos nos builds de regras canário antes de publicá-las automaticamente nos builds de regras estáveis. Recomendamos que você implante as regras canário em um ambiente de teste para ver os efeitos de quaisquer alterações e adições no ambiente. Confira os nomes de regras na página Como ajustar as regras do WAF do Google Cloud Armor para verificar se o build canário está sincronizado com o build estável.
Geração de registros e monitoramento
As seções a seguir contêm práticas recomendadas e recomendações para configurar a geração de registros e o monitoramento.
Usar o Security Command Center
O Google Cloud Armor se integra automaticamente ao Security Command Center. O Google Cloud Armor exporta diferentes descobertas para o Security Command Center:
- Pico de tráfego permitido
- Aumento da taxa de negação
Confirme se a equipe de segurança da Web analisou essas descobertas.
Escolher uma taxa de amostragem do Cloud Logging
Os registros por solicitação do Google Cloud Armor usam o balanceador de carga de aplicativo externo global ou a infraestrutura de geração de registros do balanceador de carga de aplicativo clássico. Como resultado, a geração de registros do Google Cloud Armor está sujeita à taxa de amostragem de registros configurada no balanceador de carga. Recomendamos manter a taxa de amostragem como 1 quando você estiver ajustando e implementando o Google Cloud Armor. Após concluir o ajuste e a implementação do Google Cloud Armor, recomendamos que você mantenha o registro de solicitações completo ativado. No entanto, alguns clientes preferem diminuir a taxa de amostragem a uma taxa mais baixa. Tanto o balanceador de carga de aplicativo externo global quanto o balanceador de carga de aplicativo clássico não ativam registros por padrão. Portanto, é importante ativar o registro manualmente.
Usar o painel do Cloud Monitoring
É essencial ter uma visão clara do que está acontecendo na configuração do Google Cloud Armor. Para facilitar esse processo, use o painel de segurança. Além disso, é possível exportar os registros do Google Cloud Armor diretamente do Logging para sua própria plataforma. Se você estiver usando a Proteção adaptável, é importante ter um caminho de encaminhamento para todos os alertas de proteção adaptativa que forem acionados.
Gerenciamento geral
Veja a seguir práticas recomendadas e recomendações para configurar o Google Cloud Armor.
Configurar o controle de acesso do Identity and Access Management
De acordo com as práticas recomendadas gerais do Google Cloud IAM,
verifique se as pessoas certas têm acesso ao Cloud Armor. O papel de
administrador de segurança do Compute é necessário para configurar, modificar, atualizar e excluir
as políticas de segurança do Google Cloud Armor. Além disso, o papel de administrador da rede
do Compute ou a permissão compute.backendServices.setSecurityPolicy é necessária para
anexar uma política de segurança do Google Cloud Armor a um serviço de back-end.
Minimizar o número de políticas
Uma política do Google Cloud Armor pode ser reutilizada em vários serviços de back-end. Recomendamos que você tenha um conjunto consistente de políticas de segurança reutilizáveis.
Usar o Terraform
Para garantir que as configurações possam ser facilmente revertidas e reproduzidas em projetos, recomendamos o uso do Terraform. O Google Cloud Armor tem uma integração completa com o Terraform para recursos do GA.
Como configurar o Google Cloud Armor com o Google Kubernetes Engine
Se você estiver usando o GKE, precisará configurar
o Google Cloud Armor e outros recursos de entrada por meio de parâmetros
BackendConfig. Não configure manualmente um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico para servir como ponto de entrada. Para mais informações sobre como configurar
o Google Cloud Armor com o GKE, consulte
Como configurar recursos de entrada.