Esta página foi traduzida pela API Cloud Translation.

Como integrar o Cloud Armor a outros produtos do Google

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

Regras de firewall do Cloud Armor e da VPC

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

As políticas de segurança do 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. É preciso criar regras de firewall de permissão de entrada, que tenham como destinos as VMs de back-end com carga balanceada e origens que sejam intervalos de IP usados por balanceadores de carga de aplicativo externos globais ou balanceadores de carga de aplicativo clássicos. 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 tráfego apenas do intervalo CIDR 100.1.1.0/24 e do intervalo CIDR 100.1.2.0/24 para acessar seu balanceador de carga de aplicativo externo global ou o balanceador de carga clássico do aplicativo. O objetivo é bloquear o tráfego para que ele não alcance diretamente as instâncias com carga balanceada do back-end. Em outras palavras, apenas o tráfego externo por proxy por meio do balanceador de carga de aplicativo externo global ou do balanceador de carga de aplicativo clássico com uma política de segurança associada pode alcançar as instâncias.

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

O diagrama anterior mostra a seguinte configuração de implantação:

Crie dois grupos de instâncias, um na região us-west1 e outro na região europe-west1.
Implante instâncias de aplicativos de back-end nas VMs nos grupos de instâncias.
Crie um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico no nível Premium. Configure um mapa de URL e um único serviço de back-end que esteja nos dois grupos de instâncias que você criou na etapa anterior. A regra de encaminhamento do balanceador de carga precisa usar o endereço IP externo 120.1.1.1.
Configure uma política de segurança do 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.
Associe esta política ao serviço de back-end do balanceador de carga. Para instruções, consulte Configurar políticas de segurança do Cloud Armor. 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.
Configure as regras de firewall de permissão de entrada para permitir o tráfego do balanceador de carga de aplicativo externo global ou do balanceador de carga de aplicativo clássico. Saiba mais em Regras de firewall.

Cloud Armor com balanceadores de carga de aplicativo externos e IAP

O Identity-Aware Proxy (IAP) verifica a identidade de um usuário e determina se ele pode acessar um aplicativo. Para ativar o IAP para o balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico, use os serviços de back-end do balanceador de carga. Da mesma forma, as políticas de segurança de borda do Cloud Armor são anexadas aos serviços de back-end de um balanceador de carga de aplicativo externo global ou clássico.

Se as políticas de segurança do Cloud Armor e o IAP estiverem ativados para um serviço de back-end, a ordem da avaliação dependerá do tipo de balanceador de carga:

Para um serviço de back-end de um balanceador de carga de aplicativo externo global, a avaliação do Cloud Armor acontece primeiro. Se o Cloud Armor bloquear uma solicitação, o IAP não vai avaliá-la. Se o Cloud Armor permitir uma solicitação, o IAP vai avaliá-la. A solicitação será bloqueada se o IAP não autenticar a solicitação.
Para um serviço de back-end de um balanceador de carga de aplicativo clássico, a avaliação do IAP acontece primeiro. Se o IAP autenticar uma solicitação, o Cloud Armor vai avaliá-la. Se uma solicitação falhar na autenticação do IAP, o Cloud Armor não vai avaliá-la.

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.

Cloud Armor com implantações híbridas

Em uma implantação híbrida, um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico precisa acessar um aplicativo ou uma origem de conteúdo que é executada fora do Google Cloud, por exemplo, na infraestrutura de outro provedor de nuvem. Google CloudUse o 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.

Ao anexar uma política de segurança do Cloud Armor ao serviço de back-end que tem um NEG da Internet como back-end, o Cloud Armor inspeciona todas as solicitações da camada 7 que chegam ao balanceador de carga de aplicativo externo global ou clássico destinado a esse serviço de back-end.

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

Cloud Armor com Google Kubernetes Engine (GKE)

As seções a seguir descrevem como o Cloud Armor funciona com o GKE.

Entrada do GKE

Depois de configurar uma política de segurança do Cloud Armor, use o Kubernetes Ingress para ativá-la 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 de entrada, consulte Configuração de entrada.

Gateway GKE

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

É possível referenciar a política de segurança adicionando o nome dela a um recurso de política GCPBackendPolicy. O manifesto de recurso de política GCPBackendPolicy a seguir especifica uma política de segurança de back-end chamada example-security-policy:

Serviço

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Serviço em vários clusters

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Para mais informações sobre como configurar políticas de segurança de back-end do Cloud Armor, consulte Configurar a política de segurança de back-end do Cloud Armor para proteger seus serviços de back-end.

Cloud Armor com Cloud CDN

Para proteger os servidores de origem da CDN, use o Cloud Armor com o Cloud CDN. O 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. Há dois tipos de políticas de segurança que afetam como o Cloud Armor funciona com o Cloud CDN: políticas de segurança de borda e políticas de segurança de back-end.

Políticas de segurança de borda

É possível usar políticas de segurança de borda para serviços de back-end ativados para o Cloud CDN e buckets de back-end do Cloud Storage por trás do balanceador de carga de aplicativo externo global ou do balanceador de carga de aplicativo clássico. Use as políticas de segurança de borda para filtrar solicitações antes que o conteúdo seja exibido no cache.

Políticas de segurança de back-end

Quando as políticas de segurança de back-end do Cloud Armor são aplicadas a serviços de back-end com o Cloud CDN ativado, elas se aplicam apenas às solicitações roteadas ao serviço de back-end. Essas solicitações incluem solicitações de conteúdo dinâmico e falhas de cache, ou seja, solicitações que perdem ou ignoram o cache do Cloud CDN.

Quando as políticas de segurança de borda e de back-end são anexadas ao mesmo serviço de back-end, as políticas de segurança de back-end são aplicadas somente a solicitações de ausência no cache que passaram por políticas de segurança de borda.

O diagrama a seguir mostra exclusivamente como as políticas de segurança de back-end funcionam com as origens do Cloud CDN, depois que as solicitações forem permitidas pelas políticas de segurança de borda.

Como usar as políticas de segurança de back-end do Cloud Armor com o Cloud CDN. — Como usar as políticas de segurança de back-end do Cloud Armor com o Cloud CDN (clique para ampliar).

Para mais informações sobre o Cloud CDN, consulte a documentação do Cloud CDN.

Cloud Armor com Cloud Run, App Engine ou funções do Cloud Run

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

No entanto, ao usar o Cloud Armor com NEGs sem servidor, o Cloud Run ou as funções do Cloud Run, todo o acesso ao endpoint sem servidor precisa ser filtrado por uma política de segurança do Cloud Armor.

Os usuários que têm o URL padrão de um aplicativo sem servidor podem ignorar o balanceador de carga e acessar diretamente o URL do serviço. Isso ignora as políticas de segurança do Cloud Armor. Para resolver isso, desative o URL padrão que Google Cloud atribui automaticamente aos serviços do Cloud Run ou às funções do Cloud Run functions (2ª geração). Para proteger aplicativos do App Engine, use controles de entrada.

Se você estiver usando controles de entrada para aplicar seus controles de acesso a todo o tráfego de entrada, use a configuração de entrada internal-and-gclb ao configurar Cloud Run functions ou Cloud Run. A configuração de entrada internal-and-gclb permite apenas o tráfego interno e o tráfego enviado para um endereço IP externo exposto pelo balanceador de carga de aplicativo externo global ou pelo balanceador de carga de aplicativo clássico. O tráfego enviado para esses URLs padrão de fora da sua rede particular é bloqueado. Isso impede que os usuários burlem qualquer controle de acesso (como políticas de segurança do Cloud Armor) configurado pelo balanceador de carga de aplicativo externo global ou pelo balanceador de carga de aplicativo clássico.

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

Cloud Armor com o Cloud Service Mesh

É possível configurar políticas de segurança de serviço interno para sua malha de serviço e aplicar a limitação de taxa global do lado do servidor por cliente, ajudando você a compartilhar de maneira justa a capacidade disponível do seu serviço e mitigando o risco de clientes maliciosos ou com comportamento inadequado sobrecarregarem seus serviços. Você anexa uma política de segurança a uma política de endpoint do Cloud Service Mesh para aplicar a limitação de taxa no tráfego de entrada do lado do servidor. No entanto, não é possível configurar uma política de segurança do Google Cloud Armor se você estiver usando o roteamento de tráfego TCP. Para mais informações sobre como usar o Cloud Armor com o Cloud Service Mesh, consulte Configurar a limitação de taxa com o Cloud Armor.