Esta página fornece práticas recomendadas para otimizar e ajustar as implementações do Google Cloud Armor.
O Cloud Armor é implementado com o balanceador de carga de aplicações externo global, o balanceador de carga de aplicações clássico ou o balanceador de carga de rede de proxy externo. Quando implementa o Cloud Armor, associa uma política de segurança ao serviço de back-end do equilibrador de carga que quer proteger. Uma política de segurança consiste numa coleção de regras pré-configuradas e personalizadas que são determinadas por si.
Para configurar uma política do Cloud Armor que se aplica automaticamente a todos os projetos na sua organização e permite que os projetos individuais adicionem as suas próprias regras específicas, consulte o guia sobre como gerir o Cloud Armor através de restrições personalizadas. Esta abordagem oferece uma forma centralizada de aplicar políticas de segurança em toda a sua organização, ao mesmo tempo que mantém a flexibilidade para as necessidades individuais dos projetos.
Criação de regras e políticas de segurança
As secções seguintes contêm práticas recomendadas e recomendações para novas políticas e regras de segurança.
Indique descrições das regras
Use descrições de regras para fornecer contexto adicional sobre o motivo da criação de cada regra e a função pretendida da regra. O campo description está limitado a 64 carateres, pelo que as referências a bases de dados de gestão de configuração ou outros repositórios são a forma mais eficiente de captar o contexto.
Considere o espaçamento prioritário
Quando configurar as regras inicialmente, deixe um intervalo de, pelo menos, 10 entre cada valor de prioridade das regras. Por exemplo, as duas primeiras regras numa política de segurança podem ter as prioridades 20 e 30. Isto permite-lhe inserir mais regras quando precisar delas. Além disso, recomendamos que agrupe regras semelhantes em blocos, deixando intervalos maiores entre os grupos.
Use o modo de pré-visualização
As regras da política de segurança, incluindo as assinaturas do Open Web Application Security Project (OWASP), podem ter efeitos imprevisíveis na sua aplicação. Use o modo de pré-visualização para avaliar se a introdução de uma regra terá um impacto negativo no tráfego de produção.
Ative a análise JSON
Se a sua aplicação enviar conteúdo JSON no corpo dos pedidos POST, certifique-se de que ativa a análise JSON. Se não ativar a análise JSON, o Cloud Armor não analisa o conteúdo JSON dos corpos POST para regras de WAF pré-configuradas, e os resultados podem ser ruidosos e gerar falsos positivos. Para mais informações, consulte o artigo sobre a
análise JSON.
Teste a sua lógica
Uma regra é acionada quando a respetiva condição de correspondência é avaliada como verdadeira. Por exemplo, a condição de correspondência origin.region_code == 'AU' é avaliada como verdadeira se o código da região do pedido for AU. Se uma regra de prioridade mais elevada for avaliada como verdadeira, a ação numa regra de prioridade mais baixa é ignorada. No exemplo seguinte,
imagine que quer criar uma política de segurança para bloquear utilizadores da AU
região, exceto para o tráfego no 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 que tem origem no intervalo de endereços IP 10.10.10.0/24. Uma vez que Rule1 é a regra de prioridade mais elevada, esse tráfego é permitido antes de ser avaliado em relação a Rule2, o que significa que o Cloud Armor não o avalia em relação a Rule2 (nem a quaisquer outras regras restantes).
Quando cria políticas do Cloud Armor, teste a lógica das suas regras para garantir que alcança o comportamento pretendido. Para tal, recomendamos que gere tráfego sintético para compreender que regras estão a bloquear o tráfego e verifique se os resultados são consistentes com as suas decisões de conceção de regras. Se não tiver a certeza de como um pedido pode fluir através do sistema, use o modo de pré-visualização para ver que regra corresponde ao pedido.
Identifique os endereços IP de origem dos seus scanners
Os seus scanners de segurança podem estar localizados dentro ou fora da Google. Se quiser uma avaliação externa e não filtrada da sua aplicação, pode permitir explicitamente tráfego com base no endereço IP (ou noutro token) antes de o avaliar em relação a quaisquer outras regras.
Agrupe e ordene as regras na sua política de segurança
As suas aplicações podem publicar diferentes subconjuntos dos seus clientes. No exemplo seguinte, quer recusar tráfego de determinadas áreas geográficas ou intervalos de IP e, por isso, configura a primeira regra na sua política para recusar esse tráfego. Além disso, quer permitir explicitamente algum tráfego na aplicação sem que a política de segurança o processe. Para este exemplo, recomendamos a seguinte estrutura de prioridade das regras, da maior para a menor prioridade:
- Regras de negação explícitas (ASN, região, intervalos de IP)
- Regras de autorização explícitas fidedignas (scanners, sistemas fidedignos – use com extrema precaução)
- Regras de segurança (OWASP, regras personalizadas)
- Regras de permissão explícitas (ASN, presença de valor do cabeçalho, intervalo de IPs)
- Regras de recusa predefinidas
Defina limites de limitação de velocidade
A limitação da taxa é uma capacidade flexível e valiosa para evitar o abuso e mitigar ameaças de elevado volume, como o preenchimento de credenciais ou ataques DDoS de camada 7. Quando implementar a limitação de taxa pela primeira vez, é importante escolher um limite que faça sentido para a sua aplicação. Recomendamos que comece com a aplicação no modo de pré-visualização. À medida que analisa e compreende o perfil de tráfego, pode ajustar os parâmetros de limitação de taxa. Além disso, é importante considerar a prioridade que atribui à regra de limitação de taxa. O tráfego pode ser explicitamente permitido ou recusado por uma regra de prioridade mais elevada antes de ser avaliado em função da regra de limitação de taxa.
Ajuste de regras
As aplicações Web podem permitir pedidos que parecem ser ataques e podem permitir, ou até exigir, que os utilizadores enviem pedidos que correspondam às assinaturas nas regras de WAF pré-configuradas. É fundamental que valide as regras do Cloud Armor em relação à sua aplicação e resolva todas as conclusões que possam não ser relevantes para a sua aplicação antes de promover a regra desativando o modo de pré-visualização numa aplicação de produção. As secções seguintes contêm práticas recomendadas e recomendações para otimizar as regras da WAF pré-configuradas.
Escolha o nível de sensibilidade da regra de WAF pré-configurada
Quando implementa qualquer uma das regras da WAF pré-configuradas, pode escolher um nível de sensibilidade adequado com base nos seus requisitos de segurança e prazos. Recomendamos que comece com um nível de sensibilidade de 1 para a maioria das aplicações que têm de cumprir os requisitos de segurança da sua organização. As regras configuradas para a sensibilidade 1 usam assinaturas de alta fidelidade e reduzem o potencial ruído da regra. As assinaturas associadas a sensibilidades mais elevadas podem detetar e impedir um conjunto maior de tentativas de exploração, à custa de potencial ruído para algumas aplicações protegidas. No entanto, as cargas de trabalho sujeitas a requisitos de segurança mais rigorosos podem preferir o nível de sensibilidade mais elevado. Para estes exemplos de utilização, pode haver uma grande quantidade de ruído ou resultados irrelevantes, que tem de resolver através da otimização antes de a política de segurança entrar em produção.
Ative o registo verboso
Se precisar de informações adicionais sobre que atributos de pedidos e payloads estão a acionar uma regra de WAF específica, ative o registo detalhado. O registo detalhado fornece detalhes de pedidos que acionam regras específicas, incluindo um fragmento da parte ofensiva do pedido, o que é útil para resolver problemas e ajustar o Cloud Armor. Uma vez que o registo detalhado pode fazer com que o conteúdo do pedido do utilizador final seja registado no Cloud Logging, existe a possibilidade de acumular PII do utilizador final nos seus registos. Como tal, não recomendamos a execução de cargas de trabalho de produção com o registo detalhado ativado durante longos períodos.
Use regras estáveis ou canary
Existem dois tipos de regras de WAF pré-configuradas do Cloud Armor: estáveis e canárias. Quando são adicionadas novas regras ao conjunto de regras principais (CRS) da OWASP atual, publicamo-las nas compilações de regras de teste antes de as publicar automaticamente nas compilações de regras estáveis. Recomendamos que implemente as regras de teste canário num ambiente de teste para poder ver os efeitos de quaisquer alterações e adições no seu ambiente. Pode verificar os nomes das regras na página Ajustar regras do WAF do Cloud Armor para verificar se a compilação de teste está sincronizada com a compilação estável.
Registo e monitorização
As secções seguintes contêm práticas recomendadas e recomendações para configurar o registo e a monitorização.
Escolha uma taxa de amostragem do Cloud Logging
Os registos por pedido do Cloud Armor usam o Application Load Balancer externo global ou a infraestrutura de registo do Application Load Balancer clássico. Consequentemente, a geração de registos do Cloud Armor está sujeita à taxa de amostragem de registos configurada no equilibrador de carga. Recomendamos que mantenha a taxa de amostragem em 1 quando estiver a ajustar e a implementar ativamente o Cloud Armor. Depois de concluir a otimização e a implementação do Cloud Armor, recomendamos que mantenha o registo completo de pedidos ativado. No entanto, pode preferir reduzir a amostragem para uma taxa inferior. O balanceador de carga de aplicações externo global e o balanceador de carga de aplicações clássico não ativam os registos por predefinição, pelo que é importante ativá-los manualmente.
Use o painel de controlo do Cloud Monitoring
Ter uma visão clara do que está a acontecer na sua configuração do Cloud Armor é essencial. Para facilitar este processo, pode usar o painel de controlo de segurança. Além disso, pode exportar os registos do Cloud Armor diretamente do Logging para a sua própria plataforma.
Gestão geral
As seguintes secções contêm práticas recomendadas e recomendações adicionais para configurar o Cloud Armor.
Configure o controlo de acesso da gestão de identidade e de acesso
De acordo com as Trusted Cloud práticas recomendadas gerais da IAM
, certifique-se de que as pessoas certas têm acesso ao Cloud Armor. É necessária a função de administrador de segurança do Compute para configurar, modificar, atualizar e eliminar políticas de segurança do Cloud Armor. Além disso, é necessário o papel de administrador de rede do Compute ou a autorização compute.backendServices.setSecurityPolicy para anexar uma política de segurança do Cloud Armor a um serviço de back-end.
Minimize o número de políticas
Uma política do Cloud Armor pode ser reutilizada em vários serviços de back-end. Recomendamos que tenha um conjunto consistente de políticas de segurança reutilizáveis.
Use o Terraform
Para garantir que as configurações podem ser revertidas facilmente, bem como reproduzidas em vários projetos, recomendamos que use o Terraform. O Cloud Armor tem uma integração total com o Terraform para funcionalidades de disponibilidade geral.