Como integrar o Cloud Armor a outros produtos do Google

As seções a seguir explicam como o Cloud Armor se integra a outros recursos e produtos do Google Cloud .

Cloud Armor e as regras de firewall 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 fornecem proteção de borda e atuam sobre o tráfego dos clientes para os Google Front Ends (GFEs).
  • As regras de firewall da VPC permitem ou negam o tráfego de entrada e saída dos back-ends. Você deve criar regras de firewall para a entrada, que permitam o tráfego e sejam direcionadas às VMs de back-end submetidas ao balanceamento de carga e provenientes dos intervalos de IP usados pelos balanceadores de carga de aplicativo externos globais ou clássicos. Essas regras permitem que os 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ê deseja permitir tráfego apenas dos intervalos CIDR 100.1.1.0/24 e 100.1.2.0/24 para acessar seu balanceador de carga de aplicativo externo global ou clássico. Sua meta é impedir que o tráfego chegue diretamente às instâncias de back-end com carga balanceada. Em outras palavras, somente o tráfego externo que é roteado pelo balanceador de carga de aplicativo externo global ou pelo balanceador de carga de aplicativo clássico com uma política de segurança associada pode acessar 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).

A configuração de implantação apresentada no diagrama anterior é a seguinte:

  1. Crie dois grupos de instâncias, um localizado na região us-west1 e outro na região europe-west1.
  2. Implante as instâncias do aplicativo de back-end nas VMs dos grupos de instâncias.
  3. 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 serviço de back-end único, com os dois grupos de instâncias criados na etapa anterior como back-ends. A regra de encaminhamento do balanceador de carga deve usar o endereço IP externo 120.1.1.1.
  4. Configure uma política de segurança do Cloud Armor que permita tráfego proveniente apenas dos intervalos 100.1.1.0/24 e 100.1.2.0/24, negando todo o restante.
  5. Associe essa política ao serviço de back-end do balanceador de carga. Para mais instruções, confira Configurar políticas de segurança do Cloud Armor. Os balanceadores de carga HTTP(S) externos com mapas de URL mais complexos podem referenciar diversos serviços de back-end. É possível associar a política de segurança a um ou mais serviços de back-end, de acordo com a necessidade.
  6. Configure regras de firewall para a entrada com objetivo de permitir o tráfego do balanceador de carga de aplicativo externo global ou clássico. Para mais informações, confira 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 tem permissão para acessar o aplicativo. Para ativar o IAP no balanceador de carga de aplicativo externo global ou no balanceador de carga de aplicativo clássico, use os serviços de back-end do balanceador. De forma semelhante, as políticas de segurança do Cloud Armor na borda 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 ambos ativos para um serviço de back-end, a ordem de avaliação vai depender do tipo do 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 a avaliará. Se o Cloud Armor permitir uma solicitação, o IAP realizará a avaliação. A solicitação será bloqueada se o IAP não a autenticar.

  • 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 realizará a avaliação. Se a solicitação falhar na autenticação do IAP, o Cloud Armor não a avaliará.

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

Para mais informações sobre o IAP e suas configurações, confira a documentação do Identity-Aware Proxy.

Cloud Armor com Google Kubernetes Engine (GKE)

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

Ingress do GKE

Após configurar uma política de segurança do Cloud Armor, você pode usar o Kubernetes Ingress para ativá-la no GKE.

É possível referenciar a política de segurança com um recurso BackendConfig, adicionando o nome da política ao BackendConfig. O seguinte manifesto BackendConfig 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 do Ingress, confira Configuração do Ingress.

Gateway do GKE

Após configurar uma política de segurança do Cloud Armor, você pode usar a API Gateway do Kubernetes para ativá-la no GKE.

Você pode referenciar a política de segurança adicionando o nome dela a um recurso de política GCPBackendPolicy. O seguinte manifesto de recurso de política GCPBackendPolicy 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, confira Configurar política de segurança de back-end do Cloud Armor para proteger os serviços de back-end.

Cloud Armor com Cloud CDN

Para proteger os servidores de origem do CDN, você pode usar o Cloud Armor em conjunto com o Cloud CDN. Com o Cloud Armor, o servidor de origem do CDN fica protegido contra ataques a aplicativos e riscos do OWASP Top 10, e conta com políticas de filtragem na camada 7. Existem dois tipos de políticas de segurança que influenciam como o Cloud Armor funciona com o Cloud CDN: as políticas de segurança de borda e as 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 que são acessados pelo balanceador de carga de aplicativo externo global ou pelo 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 veiculado do armazenamento em cache.

Políticas de segurança de back-end

Quando 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 afetam somente as solicitações enviadas para o serviço de back-end. Essas solicitações incluem pedidos de conteúdo dinâmico e de ausência no cache, configurando solicitações que não encontram ou ignoram o cache do Cloud CDN.

Se as políticas de segurança de borda e de back-end estiverem anexadas ao mesmo serviço de back-end, as políticas de segurança de back-end serão aplicadas apenas às solicitações de ausência no cache aprovadas pelas 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 são permitidas pelas políticas de segurança de borda.

Como usar políticas de segurança de back-end do Cloud Armor com o Cloud CDN.
Como usar 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, confira a documentação do Cloud CDN.

Cloud Armor com Cloud Run, App Engine ou Cloud Run functions

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

No entanto, ao usar o Cloud Armor com NEGs sem servidor, Cloud Run ou Cloud Run functions, todo o acesso ao endpoint sem servidor deve 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. Com isso, as políticas de segurança do Cloud Armor são ignoradas. Para evitar esse problema, desative o URL padrão que o Google Cloud atribui automaticamente aos serviços do Cloud Run ou às funções do Cloud Run functions (2ª geração). Para proteger os aplicativos do App Engine, você pode usar controles de entrada.

Se você estiver usando controles de entrada para aplicar os controles de acesso a todo o tráfego de entrada, é possível usar a configuração de entrada internal-and-gclb ao configurar o Cloud Run functions ou o Cloud Run. A configuração de entrada internal-and-gclb permite somente o tráfego interno e o tráfego enviado para um endereço IP externo fornecido 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 redes externas à sua rede particular será bloqueado. Isso impede que os usuários burlem controles de acesso (como as políticas de segurança do Cloud Armor) configurados por meio do balanceador de carga de aplicativo externo global ou do balanceador de carga de aplicativo clássico.

Para mais informações sobre NEGs sem servidor, confira Visão geral dos grupos de endpoints de rede sem servidor e Como configurar NEGs sem servidor.

Cloud Armor com Cloud Service Mesh

Você pode configurar políticas de segurança para serviços internos na malha de serviços a fim de aplicar a limitação de taxa global do lado do servidor por cliente, o que auxilia na distribuição justa da capacidade do serviço e reduz o risco de clientes mal-intencionados ou com comportamentos inadequados sobrecarregarem seus serviços. Anexe uma política de segurança a uma política de endpoint do Cloud Service Mesh para aplicar a limitação de taxa ao tráfego de entrada do lado do servidor. No entanto, se estiver usando roteamento TCP para o tráfego, não é permitido configurar uma política de segurança do Google Cloud Armor. Para mais informações sobre o uso do Cloud Armor com o Cloud Service Mesh, confira Configurar limitação de taxa com o Cloud Armor.

A seguir