Integrar o Cloud Armor com outros produtos Google

As secções seguintes abordam a forma como o Cloud Armor interage com outras Google Cloud funcionalidades e produtos.

Regras de firewall da VPC e do Cloud Armor

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

Por exemplo, considere um cenário em que quer permitir o tráfego apenas do intervalo CIDR 100.1.1.0/24 e do intervalo CIDR 100.1.2.0/24 para aceder ao seu balanceador de carga de aplicações externo global ou balanceador de carga de aplicações clássico. O seu objetivo é bloquear o tráfego de forma que não alcance diretamente as instâncias com balanceamento de carga de back-end. Por outras palavras, apenas o tráfego externo encaminhado através do balanceador de carga de aplicações externo global ou do balanceador de carga de aplicações clássico com uma política de segurança associada pode alcançar as instâncias.

Usar a política de segurança do Cloud Armor com firewalls de entrada para restringir o acesso.
Usar a política de segurança do Cloud Armor com firewalls de entrada para restringir o acesso (clique para aumentar).

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

  1. Crie dois grupos de instâncias, um na região us-west1 e outro na região europe-west1.
  2. Implemente instâncias de aplicações de back-end nas VMs nos grupos de instâncias.
  3. Crie um balanceador de carga de aplicações externo global ou um balanceador de carga de aplicações clássico no nível Premium. Configure um mapa de URLs e um único serviço de back-end cujos back-ends são os dois grupos de instâncias que criou no passo anterior. A regra de encaminhamento do balanceador de carga tem de usar o 120.1.1.1 endereço IP externo.
  4. 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 todo o outro tráfego.
  5. Associe esta política ao serviço de back-end do balanceador de carga. Para ver instruções, consulte o artigo Configure políticas de segurança do Cloud Armor. Os balanceadores de carga HTTP(S) externos com mapas de URLs mais complexos podem referenciar vários serviços de back-end. Pode associar a política de segurança a um ou mais dos serviços de back-end, conforme necessário.
  6. Configure regras de firewall de permissão de entrada para permitir o tráfego do balanceador de carga de aplicações externo global ou do balanceador de carga de aplicações clássico. Para mais informações, consulte as Regras da firewall.

Cloud Armor com balanceadores de carga de aplicações externos e IAP

O Identity-Aware Proxy (IAP) valida a identidade de um utilizador e, em seguida, determina se esse utilizador pode aceder a uma aplicação. Para ativar o IAP para o Application Load Balancer externo global ou o Application Load Balancer clássico, use os serviços de back-end do balanceador de carga. Da mesma forma, as políticas de segurança do Cloud Armor de limite estão associadas aos serviços de back-end de um Application Load Balancer externo global ou de um Application Load Balancer clássico.

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

  • Para um serviço de back-end de um Application Load Balancer externo global, a avaliação do Cloud Armor ocorre primeiro. Se o Cloud Armor bloquear um pedido, o IAP não avalia o pedido. Se o Cloud Armor permitir um pedido, o IAP avalia o pedido. O pedido é bloqueado se o IAP não autenticar o pedido.

  • Para um serviço de back-end de um Application Load Balancer clássico, a avaliação do IAP ocorre primeiro. Se o IAP autenticar um pedido, o Cloud Armor avalia o pedido. Se um pedido falhar a autenticação IAP, o Cloud Armor não avalia o pedido.

Usar listas de autorizações e listas de recusa de endereços IP com a IAP.
Usar listas de negação e listas de autorização de endereços IP com o IAP (clique para aumentar).

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

Cloud Armor com implementações híbridas

Numa implementação híbrida, um Application Load Balancer externo global ou um Application Load Balancer clássico precisa de acesso a uma aplicação ou a uma origem de conteúdo que é executada fora Google Cloud, por exemplo, na infraestrutura de outro fornecedor de nuvem. Pode usar o Cloud Armor para proteger estas implementações.

No diagrama seguinte, o balanceador de carga tem dois serviços de back-end. Um tem um grupo de instâncias como back-end. O outro serviço de back-end tem um NEG da Internet como back-end e o NEG da Internet está associado a uma aplicação que está a ser executada no centro de dados de um fornecedor externo.

Cloud Armor para implementações híbridas.
Cloud Armor para implementações híbridas (clique para aumentar).

Quando anexa 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 cada pedido da camada 7 que chega ao Application Load Balancer externo global ou ao Application Load Balancer clássico destinado a esse serviço de back-end.

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

Cloud Armor com o Google Kubernetes Engine (GKE)

As secções seguintes descrevem como o Cloud Armor funciona com o GKE.

Entrada do GKE

Depois de configurar uma política de segurança do Cloud Armor, pode usar o Kubernetes Ingress para a ativar com o GKE.

Pode fazer referência à 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 seguinte especifica uma política de segurança denominada 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 as funcionalidades do Ingress, consulte o artigo Configuração do Ingress.

GKE Gateway

Depois de configurar uma política de segurança do Cloud Armor, pode usar a API Kubernetes Gateway para a ativar com o GKE.

Pode fazer referência à sua política de segurança adicionando o nome da política de segurança a um recurso de política GCPBackendPolicy. O seguinte manifesto de recursos de políticas GCPBackendPolicy especifica uma política de segurança do back-end denominada 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 a configuração de políticas de segurança de back-end do Cloud Armor, consulte o artigo Configure a política de segurança de back-end do Cloud Armor para proteger os seus serviços de back-end.

Cloud Armor com Cloud CDN

Para proteger os servidores de origem da RFC, pode usar o Cloud Armor com o Cloud CDN. O Cloud Armor protege o servidor de origem da sua RFC contra ataques de aplicações, mitiga os riscos do OWASP Top 10 e aplica políticas de filtragem da camada 7. Existem dois tipos de políticas de segurança que afetam o funcionamento do Cloud Armor com o Cloud CDN: políticas de segurança de limite e políticas de segurança de back-end.

Políticas de segurança de edge

Pode usar políticas de segurança de limite para serviços de back-end ativados para o Cloud CDN e contentores de back-end do Cloud Storage atrás do Application Load Balancer externo global ou do Application Load Balancer clássico. Use políticas de segurança de limite para filtrar pedidos antes de o conteúdo ser publicado a partir da cache.

Políticas de segurança do 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, aplicam-se apenas a pedidos encaminhados para o serviço de back-end. Estes pedidos incluem pedidos de conteúdo dinâmico e falhas de cache, ou seja, pedidos que falham ou ignoram a cache da RFC na nuvem.

Quando as políticas de segurança de edge e as políticas de segurança de back-end estão anexadas ao mesmo serviço de back-end, as políticas de segurança de back-end só são aplicadas a pedidos de cache miss que tenham passado pelas políticas de segurança de edge

O diagrama seguinte mostra exclusivamente como as políticas de segurança do back-end funcionam com as origens do Cloud CDN, depois de os pedidos terem sido permitidos pelas políticas de segurança de limite.

Usar políticas de segurança de back-end do Cloud Armor com o Cloud CDN.
Usar políticas de segurança de back-end do Cloud Armor com o Cloud CDN (clique para aumentar).

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

Pode usar 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, quando usa o Cloud Armor com NEGs sem servidor, o Cloud Run ou as funções do Cloud Run, todo o acesso ao ponto final sem servidor tem de ser filtrado através de uma política de segurança do Cloud Armor.

Os utilizadores que têm o URL predefinido de uma aplicação sem servidor podem ignorar o equilibrador de carga e aceder diretamente ao URL do serviço. Isto ignora as políticas de segurança do Cloud Armor. Para resolver este problema, desative o URL predefinido que Google Cloud é automaticamente atribuído aos serviços do Cloud Run ou às funções do Cloud Run (2.ª geração). Para proteger as aplicações do App Engine, pode usar controlos de entrada.

Se estiver a usar controlos de entrada para aplicar os controlos de acesso a todo o tráfego recebido, pode usar a definição de entrada internal-and-gclb quando configurar funções do Cloud Run ou o Cloud Run. A definição de entrada internal-and-gclb permite apenas tráfego interno e tráfego enviado para um endereço IP externo exposto pelo Application Load Balancer externo global ou pelo Application Load Balancer clássico. O tráfego enviado para estes URLs predefinidos a partir de fora da sua rede privada é bloqueado. Isto impede que os utilizadores contornem quaisquer controlos de acesso (como as políticas de segurança do Cloud Armor) configurados através do Application Load Balancer externo global ou do Application Load Balancer clássico.

Para mais informações sobre NEGs sem servidor, consulte os artigos Vista geral dos grupos de pontos finais de rede sem servidor e Configurar NEGs sem servidor.

Cloud Armor com Cloud Service Mesh

Pode configurar políticas de segurança de serviços internos para a sua malha de serviços de modo a aplicar limites de taxa globais do lado do servidor por cliente, o que ajuda a partilhar de forma justa a capacidade disponível do seu serviço e a mitigar o risco de clientes maliciosos ou com comportamento inadequado sobrecarregarem os seus serviços. Anexa uma política de segurança a uma política de pontos finais do Cloud Service Mesh para aplicar limites de taxa ao tráfego de entrada no lado do servidor. No entanto, não pode configurar uma política de segurança do Google Cloud Armor se estiver a usar o encaminhamento de tráfego TCP. Para mais informações sobre a utilização do Cloud Armor com a malha de serviços do Google Cloud, consulte o artigo Configure a limitação de taxa com o Cloud Armor.

O que se segue?