Como integrar o Google Cloud Armor a outros produtos do Google

As seções a seguir discutem como o Google Cloud Armor interage com outros recursos e produtos do Google Cloud.

Regras de firewall da VPC do Google Cloud e da VPC

As políticas de segurança do Google Cloud Armor e as regras de firewall da VPC têm funções diferentes.

  • As políticas de segurança do Google Cloud Armor oferecem segurança na borda e atuam no tráfego de clientes para o Google Front Ends (GFEs).
  • As regras de firewall da VPC permitem ou negam tráfego que entra ou sai dos back-ends. Crie regras de firewall de permissão de entrada, cujos destinos são as VMs de back-end com balanceamento de carga e cujas fontes são intervalos IP usados por balanceadores de carga HTTP(S) externos. Essas regras permitem que as GFEs e os sistemas de verificação de integridade se comuniquem com as VMs de back-end.

Por exemplo, considere um cenário em que você quer permitir que o tráfego apenas do intervalo de CIDR 100.1.1.0/24 e do intervalo de CIDR 100.1.2.0/24 acesse seu balanceador de carga HTTP(S) externo. O objetivo é garantir que o tráfego não alcance diretamente as instâncias do balanceamento de carga de back-end. Em outras palavras, somente o tráfego externo por meio do balanceador de carga HTTP(S) externo com uma política de segurança associada precisa alcançar as instâncias.

Como usar a política de segurança do Google Cloud Armor com firewalls de entrada
       para restringir o acesso
Como usar a política de segurança do Google Cloud Armor com firewalls de entrada para restringir o acesso (clique para ampliar)

Na ilustração anterior, você atinge os objetivos de segurança configurando a implantação do Google Cloud da seguinte maneira:

  1. Crie dois grupos de instâncias, um na região us-west1 e outro na região europe-west1.
  2. Implante instâncias de aplicativos de back-end nas VMs nos grupos de instâncias.
  3. Crie um balanceador de carga HTTP(S) externo no nível Premium. Configure um mapa de URL simples e apenas um serviço de back-end que esteja nos dois grupos de instâncias que você criou na etapa anterior. Verifique se a regra de encaminhamento do balanceador de carga usa o endereço IP externo 120.1.1.1.
  4. Configure uma política de segurança do Google Cloud Armor que permita o tráfego de 100.1.1.0/24 e 100.1.2.0/24 e negue qualquer outro tráfego.
  5. Associe esta política ao serviço de back-end do balanceador de carga. Para instruções, consulte Como configurar políticas de segurança. Os balanceadores de carga HTTP(S) externos com mapas de URL mais complexos podem fazer referência a vários serviços de back-end. É possível associar a política de segurança a um ou mais serviços de back-end, conforme necessário.
  6. Configure regras de firewall de permissão de entrada para autorizar o tráfego do balanceador de carga HTTP(S) externo. Saiba mais em Regras de firewall.

Google Cloud Armor com balanceamento de carga HTTP(S) e IAP

O Identity-Aware Proxy (IAP) verifica a identidade de um usuário e determina se esse usuário pode ter permissão para acessar um aplicativo. Para habilitar o IAP para o balanceador de carga HTTP(S) externo, ative-o nos serviços de back-end do balanceador de carga. Da mesma forma, as políticas de segurança da borda do Google Cloud Armor são atreladas aos serviços de back-end de um balanceador de carga HTTP(S) externo.

Se as políticas de segurança do Google Cloud Armor e o IAP estiverem ativados para um serviço de back-end de um balanceador de carga HTTP(S) externo, a avaliação do IAP ocorrerá primeiro. Se o IAP bloquear uma solicitação, o Google Cloud Armor não avaliará a solicitação. Se o IAP autenticar uma solicitação, o Google Cloud Armor avaliará a solicitação. A solicitação será bloqueada se uma política de segurança do Google Cloud Armor produzir uma decisão de negação.

Como usar listas de proibições e endereços de IP com o IAP.
Como usar listas de proibições e endereços de IP com o IAP (clique para ampliar)

Saiba mais sobre o IAP e as configurações relacionadas na documentação do Identity-Aware Proxy.

Google Cloud Armor com implantações híbridas

Em uma implantação híbrida, um balanceador de carga HTTP(S) externo precisa ter acesso a um aplicativo ou origem de conteúdo que é executado fora do Google Cloud, por exemplo, na infraestrutura de outro provedor de nuvem. Use o Google Cloud Armor para proteger essas implantações.

No diagrama a seguir, o balanceador de carga possui dois serviços de back-end. Um deles tem um grupo de instâncias como back-end. O outro serviço possui um NEG da Internet como back-end. Esse NEG está associado a um aplicativo que está sendo executado no data center de um provedor terceirizado.

Google Cloud Armor para implantações híbridas
Google Cloud Armor para implantações híbridas (clique para ampliar)

Ao atrelar uma política de segurança do Google Cloud Armor a um serviço de back-end que tem um NEG da Internet como back-end, o Google Cloud Armor inspeciona todas as solicitações L7 que chegam ao balanceador de carga HTTP(S) externo destinado a esse serviço de back-end.

A proteção do Google Cloud Armor para implantações híbridas está sujeita às mesmas limitações que se aplicam aos NEGs da Internet.

Google Cloud Armor com Entrada do Google Kubernetes Engine (GKE)

Depois de configurar uma política de segurança do Google Cloud Armor, use o Kubernetes Ingress para ativá-lo com o GKE.

Você pode referenciar sua política de segurança com um recurso BackendConfig adicionando o nome da sua política de segurança ao BackendConfig. O manifesto BackendConfig a seguir especifica uma política de segurança chamada example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Para mais informações sobre os recursos da Entrada, consulte Como configurar os recursos de entrada.

Google Cloud Armor com Cloud CDN

Para proteger os servidores de origem da CDN, use o Google Cloud Armor com o Cloud CDN. O Google Cloud Armor protege o servidor de origem da CDN de ataques de aplicativos, atenua os 10 principais riscos do OWASP e aplica políticas de filtragem da camada 7.

O Google Cloud Armor aplica políticas de segurança em serviços de back-end com o Cloud CDN ativado apenas para ausências no cache, isto é, para solicitações que perdem ou ignoram o cache do Cloud CDN.

Quando uma política de segurança é atrelada a um serviço de back-end que tem o Cloud CDN ativado, o Google Cloud Armor avalia as solicitações recebidas que não podem ser exibidas no cache em relação à política de segurança para determinar se elas precisam ser encaminhadas ao servidor de origem. Se uma regra corresponder à solicitação, a ação configurada na regra será executada.

No entanto, as políticas de segurança atreladas a um serviço de back-end que tem o Cloud CDN ativado não são aplicadas a ocorrências em cache. Se uma solicitação puder ser exibida no cache, ela será exibida para qualquer cliente válido, independentemente do que a política de segurança tenha feito para essa solicitação.

O diagrama a seguir mostra como o Google Cloud Armor funciona com as origens do Cloud CDN.

Como usar o Google Cloud Armor com Cloud CDN \
Google Cloud Armor com Cloud CDN (clique para ampliar)

Google Cloud Armor com aplicativos sem servidor

Use as políticas de segurança do Google Cloud Armor com um back-end NEG sem servidor que direciona para um serviço do Cloud Run, App Engine ou Cloud Functions.

No entanto, ao usar o Google Cloud Armor com NEGs e Cloud Functions sem servidor, tome medidas especiais para garantir que todo o acesso ao endpoint sem servidor seja filtrado por uma política de segurança do Google Cloud Armor.

Os usuários que têm o URL padrão de um serviço do Cloud Functions podem ignorar o balanceador de carga e ir diretamente para o URL. Isso ignora as políticas de segurança do Google Cloud Armor. Não é possível desativar os URLs que o Google Cloud atribui automaticamente aos serviços do Cloud Functions.

Para garantir que seus controles de acesso sejam aplicados a todo o tráfego de entrada, use internal-and-gclb ao configurar o Cloud Functions. Ele permite apenas o tráfego interno e o tráfego enviado para um endereço IP público exposto pelo balanceador de carga HTTP(S) externo. O tráfego enviado para cloudfunctions.net ou qualquer outro domínio personalizado configurado por meio do Cloud Functions é bloqueado. Isso evita que os usuários burlem qualquer controle de acesso (como as políticas de segurança do Google Cloud Armor) configurado por meio do balanceador de carga HTTP(S) externo.

Saiba mais sobre NEGs sem servidor em Visão geral dos grupos de endpoints de rede sem servidor e Como configurar NEGs sem servidor.

A seguir