Visão geral da política de segurança do Google Cloud Armor

Use as políticas de segurança do Google Cloud Armor para proteger os aplicativos executados por trás de um balanceador de carga contra ataques distribuídos de negação de serviço (DDoS, na sigla em inglês) e outros ataques baseados na Web, sejam eles implantados no Google Cloud, em um ambiente híbrido{ 101}implantação ou em uma arquitetura de várias nuvens.

As políticas de segurança do Google Cloud Armor são compostas por regras que filtram o tráfego com base nos atributos das camadas 3, 4 e 7. Por exemplo, para uma solicitação recebida, você pode especificar condições que correspondam ao endereço IP, ao intervalo de IP, ao código da região ou aos cabeçalhos de solicitação.

As políticas de segurança do Google Cloud Armor estão disponíveis apenas para serviços de back-end que estiverem atrás de um balanceador de carga HTTP(S) externo. O balanceador de carga pode estar no nível Premium ou Standard. A proteção contra DDoS é fornecida automaticamente para balanceamento de carga HTTP(S), proxy SSL e proxy TCP.

Os protocolos HTTP, HTTPS, HTTP/2 e QUIC são compatíveis. Para informações sobre como configurar o Google Cloud Armor no Google Kubernetes Engine (GKE), consulte Como configurar o Google Cloud Armor por meio do Ingress.

Os back-ends do serviço de back-end podem ser instâncias de máquina virtual (VM) em um grupo de instâncias, grupos de endpoints de rede zonais (NEGs por zona) ou grupos de endpoints de rede de Internet (NEGs na Internet). Ao usar o Google Cloud Armor para proteger uma implantação híbrida ou arquitetura de várias nuvens, os back-ends precisam ser NEGs da Internet.

Segurança da borda com as políticas de segurança do Google Cloud Armor

O balanceamento de carga HTTP(S) é implementado na extremidade da rede do Google nos pontos de presença (PoPs, na sigla em inglês) do Google em todo o mundo. No nível Premium, o tráfego de usuários direcionado para um balanceador de carga HTTP(S) externo entra no PoP mais próximo do usuário. Em seguida, a carga é balanceada na rede global do Google até o back-end mais próximo que tem capacidade suficiente disponível. No nível Standard, o tráfego do usuário entra na rede do Google por meio de peering, ISP ou redes de trânsito na região em que você implantou os recursos do Google Cloud.

Com as políticas de segurança do Google Cloud Armor, você permite ou nega acesso ao balanceador de carga HTTP(S) externo na borda do Google Cloud, o mais próximo possível da origem do tráfego de entrada. Isso evita que o tráfego indesejável consuma recursos ou entre nas redes da nuvem privada virtual (VPC, na sigla em inglês).

O diagrama a seguir ilustra a localização dos balanceadores de carga externos HTTP(S), a rede e os data centers do Google.

Política do Google Cloud Armor na borda da rede
Política do Google Cloud Armor na borda da rede (clique para ampliar)

Requisitos

Estes são os requisitos das políticas de segurança do Google Cloud Armor:

  • O balanceador de carga precisa ser um balanceador de carga HTTP(S) externo.
  • O esquema de balanceamento de carga do serviço de back-end precisa ser EXTERNAL.
  • O protocolo do serviço de back-end precisa ser HTTP, HTTPS ou HTTP/2.

Recursos da política de segurança

As políticas de segurança do Google Cloud Armor têm os seguintes recursos principais.

  • Como opção, você pode usar o protocolo QUIC com balanceadores de carga que usam o Google Cloud Armor.

  • É possível usar o Google Cloud Armor com balanceadores de carga HTTP(S) externos que estão no nível Premium ou Standard.

  • É possível usar políticas de segurança com o GKE e o controlador Ingress padrão.

Políticas de segurança do balanceamento de carga HTTP(S)

Cada serviço de back-end de um balanceador de carga HTTP(S) externo pode referir-se a uma única política de segurança do Google Cloud Armor. É possível usar a mesma política de segurança com mais de um serviço de back-end nos mesmos balanceadores de carga HTTP(S) externos ou em outros.

Você designa a prioridade (ordem de avaliação da regra) quando várias regras são configuradas.

Regras de listas de permissões e negações de endereços IP

É possível criar regras de listas de permissões e negações de endereços IP em uma política de segurança: Os exemplos incluem:

  • A negação da lista de endereços IP/CIDR permite que você bloqueie um endereço IP de origem ou intervalo de CIDR de acessar balanceadores de carga HTTP(S) externos.

  • A lista de endereços IP/CIDR permite que você permita que um endereço IP ou intervalo de CIDR acesse os balanceadores de carga HTTP(S) externos.

  • Os endereços IPv4 e IPv6 são compatíveis com as regras de listas de permissões e negações.

  • As regras de endereço IP podem bloquear ou permitir endereços IP ou CIDRs de origem individuais. Os endereços de origem IPv4 e IPv6 são compatíveis, mas os endereços IPv6 precisam ter máscaras de sub-rede de até /64.

  • As regras de negação podem retornar uma resposta HTTP 403 (não autorizado), 404 (acesso negado) ou 502 (gateway inválido).

Linguagem de regras e mecanismo de imposição

A linguagem de regras e o mecanismo de aplicação oferecem o seguinte:

  • A capacidade de escrever expressões de regras personalizadas que podem corresponder a vários atributos da camada 7 até a camada 7 das solicitações recebidas. O Google Cloud Armor fornece uma linguagem flexível para escrever condições de correspondência personalizadas.

  • A capacidade de combinar várias subexpressões em uma única regra.

  • A capacidade de negar ou permitir solicitações com base no código da região da solicitação recebida. Os códigos de região são baseados nos códigos ISO 3166-1 alpha 2. Às vezes, os códigos de região correspondem a países específicos, mas alguns abrangem um país e também áreas ligadas a ele. Por exemplo, o código US inclui todos os estados dos Estados Unidos, um distrito e seis áreas remotas.

Regras pré-configuradas para XSS, SQLi, LFI, RFI e RCE

É possível usar regras pré-configuradas para reduzir os seguintes ataques:

  • Scripting em vários locais (XSS)
  • Ataques de injeção de SQL (SQLi)
  • Ataques de inclusão de arquivo local (LFI)
  • Ataques de inclusão de arquivo remoto (RFI)
  • Ataques de execução remota de código (RCE)

Essas regras são baseadas na versão 3.0.1 do conjunto de regras principais do OWASP Modsecurity.

Regras pré-configuradas para listas de endereços IP com nome

As regras pré-configuradas para listas de endereços IP nomeadas fornecem o seguinte:

  • Integre listas de endereços IP nomeados de provedores de terceiros com o Google Cloud Armor.

  • Simplifique a manutenção de intervalos de endereços IP permitidos ou negados.

  • Sincronize as listas de provedores de terceiros diariamente.

  • Aumentar sua capacidade de configurar endereços IP e intervalos em políticas de segurança porque as listas de endereços IP nomeados não estão sujeitas aos limites no número de endereços IP por regra.

Modo de visualização

É possível ver os efeitos de uma regra sem aplicá-la. No modo de visualização, as ações são observadas no Cloud Monitoring. É possível ver regras individuais de uma política de segurança ou visualizar todas as regras da política.

Logging

O nome da política de segurança do Google Cloud Armor, a prioridade de regra correspondente, a ação associada e as informações relacionadas são registradas para solicitações HTTP(S) no balanceador de carga HTTP(S) externo. Para gravar informações de registro do Google Cloud Armor, você precisa ativar a geração de registros para solicitações HTTP(S).

Sobre as políticas de segurança do Google Cloud Armor

As políticas de segurança do Google Cloud Armor são conjuntos de regras que você define para aplicar regras de firewall da camada de aplicativo que protegem aplicativos ou serviços voltados para fora. Cada regra é avaliada em relação ao tráfego recebido.

Uma regra de política de segurança do Google Cloud Armor consiste em uma condição de correspondência e uma ação a ser tomada quando essa condição é atendida. As condições podem ser tão simples quanto a correspondência entre o endereço IP de origem do tráfego de entrada e um endereço IP ou intervalo CIDR específico (também conhecido como regras de listas de permissões e negações de endereços IP). Como alternativa, usando a referência de linguagem das regras personalizadas do Google Cloud Armor, é possível criar condições personalizadas que correspondam a vários atributos do tráfego de entrada, como o caminho do URL, ou de valores de cabeçalho de solicitação.

Quando uma condição é atendida, a ação é permitir ou negar tráfego. Por padrão, essa ação é imposta, mas uma opção de visualização está disponível. Ao definir a opção de visualização como verdadeira, a ação visualizada é registrada, mas não aplicada.

É possível associar uma política de segurança do Google Cloud Armor a um ou mais serviços de back-end. Um serviço de back-end pode ter apenas uma política de segurança associada a ele.

Se uma política de segurança do Google Cloud Armor estiver associada a qualquer serviço de back-end, ela não poderá ser excluída. Um serviço de back-end pode ser excluído, independentemente de ter ou não uma política de segurança associada.

Se várias regras de encaminhamento apontarem para um serviço de back-end que tenha uma política de segurança associada, elas serão aplicadas a todo o tráfego que chega a cada um dos endereços IP da regra de encaminhamento.

Na ilustração a seguir, a política de segurança do Google Cloud Armor internal-users-policy está associada ao serviço de back-end test-network.

Política de segurança do Google Cloud Armor na borda da rede
Política de segurança do Google Cloud Armor na borda da rede (clique para ampliar)

Ordem de avaliação da regra

A ordem de avaliação da regra é determinada por dois fatores: prioridade da regra e tipo de regra.

Você atribui uma prioridade às regras, do número mais baixo para o mais alto. A regra com o menor valor numérico atribuído tem a maior prioridade lógica e é avaliada antes das regras com prioridades lógicas mais baixas. A prioridade numérica mínima é 0. A prioridade de uma regra diminui à medida que seu número aumenta (1, 2, 3, N+1). Não é possível configurar duas ou mais regras com a mesma prioridade. A prioridade de cada regra precisa ser definida como um número entre 0 e 2.147.483.646, inclusive. O valor de prioridade 2.147.483.647, também conhecido como INT-MAX, está reservado para a regra padrão.

Os números de prioridade podem ter lacunas, o que permite adicionar ou remover regras no futuro sem afetar o restante das regras. Por exemplo, 1, 2, 3, 4, 5, 9, 12, 16 é uma série de números de prioridade válidos aos quais você pode adicionar regras numeradas de 6 a 8, 10 a 11 e 13 a 15 no futuro. Não é necessário alterar as regras existentes, exceto pela ordem de execução.

Normalmente, é aplicada a regra de prioridade mais alta que corresponde à solicitação. No entanto, há uma exceção ao executar solicitações HTTP POST por meio de regras pré-configuradas configuradas usando evaluatePreconfiguredExpr(). A exceção é a seguinte.

Para solicitações HTTP POST, o Google Cloud Armor recebe o cabeçalho da solicitação antes do corpo (payload). Como o Google Cloud Armor recebe as informações do cabeçalho primeiro, ele avalia as regras que correspondem ao cabeçalho, mas não faz correspondência de nenhuma regra pré-configurada com o corpo. Se houver várias regras baseadas em cabeçalho, o Google Cloud Armor as avaliará com base na prioridade delas conforme previsto.

Depois que o Google Cloud Armor recebe o corpo HTTP POST, ele avalia regras que se aplicam aos cabeçalhos e ao corpo da solicitação. Como resultado, é possível que regras de prioridade mais baixa que permitam o cabeçalho de uma solicitação sejam correspondidas antes de regras de prioridade mais alta que bloqueiam o corpo da solicitação. Nesses casos, é possível que a parte do cabeçalho HTTP da solicitação seja enviada para o serviço de back-end de destino enquanto o corpo POST com conteúdo potencialmente mal-intencionado está bloqueado.

Exemplos

No exemplo a seguir, as regras 1, 2 e 3 são avaliadas nessa ordem para os campos de cabeçalho IP e HTTP. No entanto, se um IP 9.9.9.1 iniciar um ataque XSS no corpo HTTP POST, somente o corpo será bloqueado (por regra 2). o cabeçalho HTTP passa ao back-end (por regra 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

No exemplo a seguir, a política permite IP 9.9.9.1 sem verificação contra ataques XSS:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Regra padrão

Cada política de segurança do Google Cloud Armor contém uma regra padrão que é correspondida se nenhuma das regras de prioridade mais alta corresponder ou se não houver outras regras na política. A regra padrão recebe automaticamente a prioridade 2147483647 (INT-MAX) e está sempre presente na política de segurança.

Não é possível excluir a regra padrão, mas você pode modificá-la. A ação padrão para essa regra é negar, mas você pode alterar a ação para permitir.

Fingerprint

Cada política de segurança do Google Cloud Armor possui um campo fingerprint. A impressão digital é um hash do conteúdo armazenado na política. Ao criar uma nova política, não forneça o valor desse campo. Se você informar um valor, ele será ignorado. No entanto, ao atualizar uma política de segurança, é necessário especificar a impressão digital atual, que você recebe ao exportar ou descrever a política.

A impressão digital evita que você substitua a atualização de outro usuário. Se a impressão digital fornecida está desatualizada, isso significa que a política de segurança foi atualizada desde a última recuperação. Para verificar as diferenças e recuperar a impressão digital mais recente, descreva a política de segurança.

Como as conexões WebSocket são processadas

O balanceamento de carga HTTP(S) externo tem suporte integrado para o protocolo WebSocket. Os canais WebSocket são iniciados a partir de solicitações HTTP(S). O Google Cloud Armor pode impedir que um canal WebSocket seja estabelecido, por exemplo, se uma lista de negações de endereços IP bloquear o endereço IP de origem. Porém, as transações subsequentes no canal não estão em conformidade com o protocolo HTTP, e o Google Cloud Armor não avalia nenhuma mensagem após a primeira solicitação.

Políticas de segurança do Google Cloud Armor

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 do Google Cloud precisa acessar um aplicativo ou a origem de um conteúdo que é executado fora do Google Cloud, por exemplo, na infraestrutura de outro provedor de nuvem. É possível usar 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 Cloud CDN

Para proteger os servidores de origem da CDN, use o Google Cloud Armor com o Cloud CDN. O Google Cloud Armor faz com que o servidor de origem CDN fique protegido contra ataques a aplicativos, mitiga 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 sem servidor e o Cloud Functions, é preciso tomar medidas especiais para solucionar um problema de segurança.

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 evitar esse risco de segurança, use o internal-and-gclb ao configurar o Cloud Functions, que permite apenas o tráfego interno e o tráfego enviados para um endereço IP público exposto por o 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.

Casos de uso gerais

Esta seção apresenta vários casos de uso comuns para políticas de segurança do Google Cloud Armor.

Caso de uso 1: limitar o acesso ao balanceador de carga HTTP(S) externo do Google Cloud

Um caso de uso típico para colocar endereços IP do usuário em uma lista de permissões é quando o balanceador de carga HTTP(S) externo é usado apenas por um conjunto específico de usuários. No exemplo a seguir, somente usuários da sua organização têm acesso permitido a serviços que estão atrás do balanceador de carga. Esses usuários têm endereços IP ou blocos de endereços atribuídos pela organização. É possível colocar esses endereços IP ou intervalos CIDR em uma lista de permissões, para que apenas esses usuários tenham acesso ao balanceador de carga.

Como restringir o acesso ao balanceador de carga com uma lista de permissões
Como restringir o acesso ao balanceador de carga com uma lista de permissões (clique para ampliar)

É possível controlar o acesso ao balanceador de carga HTTP(S) externo configurando uma lista de permissões com endereços IP ou intervalos de CIDR de origem a partir dos quais o acesso ao balanceador de carga é permitido. A seção a seguir explica melhor essa configuração.

Nesta configuração, você permite apenas que os usuários da sua organização com endereços IP 203.0.113.0/24 acessem o balanceador de carga HTTP(S) externo. Qualquer outro tráfego será negado.

Para criar esta configuração, siga estes passos:

  1. Crie uma política de segurança do Google Cloud Armor.
  2. Na política de segurança, adicione uma regra que adicione 203.0.113.0/24 à lista de permissões como a primeira regra. Esta regra tem a descrição allow 203.0.113.0/24.
  3. Modifique a regra padrão na política de uma regra de permissão para uma regra de negação. A regra padrão controla o tráfego que não corresponde a nenhuma das regras anteriores. É a última regra da política. Alterar a regra de allow para deny bloqueia todo tráfego que não se origina no intervalo 203.0.113.0/24, que está em uma lista de permissões.
  4. Associe esta política ao serviço de back-end do balanceador de carga HTTP(S) externo.

Caso de uso 2: bloquear tráfego não autorizado ou malicioso na borda com listas de negação

Use as listas de negação para criar políticas de segurança do Google Cloud Armor que rejeitam o tráfego de um endereço IP ou intervalo CIDR. Na ilustração a seguir, a política de segurança do Google Cloud Armor tem uma regra deny que bloqueia o tráfego do endereço IP 198.51.100.1, no qual um usuário mal-intencionado foi identificado.

Como restringir o acesso ao balanceador de carga com uma lista de negação
Como restringir o acesso ao balanceador de carga com uma lista de negação (clique para ampliar)

Caso de uso 3: permitir tráfego para o balanceador de carga HTTP(S) externo somente de um provedor de segurança terceirizado e de outros usuários autorizados

Se sua organização usa um provedor de segurança terceirizado para limpar o tráfego, é possível adicionar o endereço IP desse provedor a uma lista de permissões para garantir que apenas esse tráfego possa acessar o balanceador de carga HTTP(S) externo e os back-ends.

Na ilustração a seguir, o provedor terceirizado é identificado pelo intervalo CIDR 192.0.2.0/24, e esse intervalo está em uma lista de permissões.

Como restringir o acesso ao balanceador de carga, colocando o tráfego de um provedor de segurança
       na lista de permissões
Como restringir o acesso ao balanceador de carga, colocando o tráfego de um provedor de segurança na lista de permissões (clique para ampliar)

Caso de uso 4: adaptar defesas com regras personalizadas que correspondam aos parâmetros das camadas 3 a 7

Use a linguagem de regras personalizadas do Google Cloud Armor para definir uma ou mais expressões na condição de correspondência de uma regra. Quando o Google Cloud Armor recebe uma solicitação, ele a avalia com base nessas expressões. Se houver uma correspondência, a ação da regra entrará em vigor, negando ou permitindo o tráfego de entrada.

Os exemplos a seguir são expressões escritas na extensão do Google Cloud Armor do Common Expression Language (CEL). Para mais informações, consulte a referência da linguagem de regras personalizadas.

Para definir expressões em uma regra, use a sinalização --expression do gcloud ou o Console do Google Cloud. Para mais informações, consulte Como criar políticas, regras e expressões de segurança do Google Cloud Armor.

No exemplo a seguir, solicitações de 2001:db8::/32 (como seus testadores alfa) na região AU correspondem à seguinte expressão:

origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')

O exemplo a seguir corresponde às solicitações de 1.2.3.4 e a um user agent que contém a string WordPress:

inIpRange(origin.ip, '1.2.3.4/32') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

Para mais exemplos, consulte Expressões de exemplo na referência da linguagem de regras personalizadas.

Caso de uso 5: como mitigar ataques da camada de aplicativo usando regras pré-configuradas

Use regras pré-configuradas para detectar e bloquear ataques comuns da camada de aplicativo, como XSS e SQLi. Regras pré-configuradas são conjuntos de expressões predefinidos que podem ser adicionadas a uma política de segurança do Google Cloud Armor. Para adicionar esses conjuntos de expressões a uma regra, use a sinalização --expression do gcloud ou o Console do Cloud. Para mais informações, consulte Como criar políticas, regras e expressões de segurança do Google Cloud Armor.

Para mais informações sobre regras pré-configuradas, consulte Regras pré-configuradas na referência da linguagem de regras personalizadas.

O exemplo a seguir usa uma regra pré-configurada para mitigar ataques de scripting em vários locais (XSS):

evaluatePreconfiguredExpr('xss-stable')

O exemplo a seguir usa uma regra pré-configurada para mitigar ataques de injeção de SQL (SQLi):

evaluatePreconfiguredExpr('sqli-stable')

Também é possível combinar regras pré-configuradas com outras expressões. O exemplo a seguir usa uma regra pré-configurada para mitigar ataques SQLi do intervalo de endereços IP 1.2.3.0/24:

inIpRange(origin.ip, '1.2.3.0/24') && evaluatePreconfiguredExpr('sqli-stable')

Casos de uso para implantações híbridas

Esta seção apresenta casos de uso para políticas de segurança do Google Cloud Armor com implantações híbridas.

Caso de uso: mitigação de 10 OWASP para cargas de trabalho híbridas

O Google Cloud Armor oferece mitigações de injeção de SQL (SQLi) e de scripting em vários locais (XSS) para seus aplicativos, estejam eles implantados no Google Cloud, localmente ou em um provedor terceirizado. É possível usar esses recursos para solucionar alguns dos riscos mais comuns de segurança de aplicativos da Web, incluindo esses riscos identificados na lista 10 principais do OWASP.

As regras do WAF pré-configuradas do Google Cloud Armor podem ser adicionadas a uma política de segurança para detectar e negar solicitações indesejadas da camada 7 que contêm tentativas de SQLi ou XSS. O Google Cloud Armor detecta as solicitações maliciosas e as barra na borda da infraestrutura do Google. As solicitações não são encaminhadas para o serviço de back-end, independentemente de onde o serviço está implantado.

Para proteger uma carga de trabalho não hospedada no Google Cloud de ataques SQLi ou XSS na extremidade da rede do Google, siga estas etapas:

  1. Configure um balanceador de carga HTTP(S) externo com um serviço de back-end que tenha um NEG da Internet como back-end.
  2. Crie uma política de segurança do Google Cloud Armor.
  3. Adicione regras de SQLi e XSS à política.
  4. Atrele a política de segurança ao serviço de back-end criado na etapa 1.
  5. Monitore a atividade do Google Cloud Armor usando o Cloud Logging, o Cloud Monitoring e as descobertas enviadas para o Security Command Center.

Caso de uso: defesa contra DDoS no servidor de origem externo do Cloud CDN e monitoramento da camada 7

As implantações do Cloud CDN com um servidor de origem externo podem ter a infraestrutura de borda do Google como front-end para proxy, cache e filtragem da camada 7 do Google Cloud Armor. Usando NEGs da Internet, o servidor de origem pode estar no local ou com um provedor de infraestrutura terceirizado.

O Google Cloud Armor e o restante da infraestrutura de borda do Google mitigam e barram ataques em L3/L4, alertam sobre atividades suspeitas da camada 7 e estão prontos para negar solicitações indesejadas da camada 7 com regras personalizadas. A geração de registros e a telemetria do Google Cloud Armor no Cloud Logging, no Cloud Monitoring e no Security Command Center oferecem insights acionáveis para aplicativos protegidos, independentemente de onde eles sejam implantados.

Para ativar a proteção do Google Cloud Armor para servidores de origens externas da CDN, siga estas etapas:

  1. Configure um balanceador de carga HTTP(S) externo com um serviço de back-end que tenha um NEG da Internet como back-end.
  2. Ative o Cloud CDN para este serviço de back-end.
  3. Crie uma política de segurança do Google Cloud Armor.
  4. Atrele a política de segurança ao serviço de back-end criado na etapa 1.
  5. Acesse alertas, geração de registros e telemetria do Google Cloud Armor no Security Command Center, Cloud Logging e Cloud Monitoring.

Casos de uso com o Cloud CDN

Esta seção apresenta dois casos de uso para o Google Cloud Armor com Cloud CDN.

Caso de uso: mitigação de SQLi e XSS

É possível usar o Google Cloud Armor para proteger um servidor de origem do Cloud CDN contra riscos como ataques de injeção de SQL (SQLi) e scripting em vários locais (XSS). O conteúdo de um cache é estático e supostamente não representa um risco de um ataque direcionado da Web. No entanto, o servidor de origem do conteúdo subjacente pode ser um aplicativo dinâmico com vulnerabilidades de aplicativos da Web potenciais ou conhecidas. Seus requisitos de segurança ou conformidade podem exigir a redução desses riscos para impedir que explorações de vulnerabilidades da Internet consigam atacar o servidor de origem.

Para atenuar os riscos, siga estas etapas:

  1. Crie ou identifique um serviço de back-end com o CDN ativado.
  2. Crie uma política de segurança do Google Cloud Armor.
  3. Crie uma ou mais regras na política de segurança para negar ataques XSS e SQLi.
  4. Configure um dos destinos da política de segurança para ser o serviço de back-end que você criou ou identificou na etapa 1.

Caso de uso: controles de acesso da camada 7 e ataques de bloqueio de cache

Dependendo da arquitetura do aplicativo, é possível configurar um serviço de back-end para disponibilizar solicitações para vários URLs, incluindo conteúdo armazenável em cache e não armazenável em cache. Nesses cenários de implantação, crie políticas de segurança do Google Cloud Armor que neguem tráfego indesejado em determinados caminhos de solicitação, mas permitam que todos os clientes acessem conteúdo estático em um caminho de solicitação diferente.

Em outras situações, mesmo que o conteúdo seja veiculado de maneira eficiente a partir do cache, um cliente mal-intencionado ou com falha pode gerar um alto volume de solicitações que resultam na ausência do cache e exige que o servidor de origem subjacente seja buscado ou {101 }gerem o conteúdo solicitado. Isso pode sobrecarregar recursos limitados e ter um impacto negativo na disponibilidade do aplicativo para todos os usuários. Crie uma política de segurança do Google Cloud Armor para corresponder à assinatura de qualquer cliente que esteja causando o problema e negar as solicitações antes que elas cheguem ao servidor de origem e afetem o desempenho.

Para fazer isso, siga estas etapas:

  1. Crie uma política de segurança do Google Cloud Armor.
  2. Configurar uma regra; por exemplo, a regra a seguir nega o acesso a "/admin":

    request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>'
    
  3. Atrele a política de segurança da etapa 1 ao serviço de back-end que tem o Cloud CDN ativado.

Registro de solicitação de balanceamento de carga HTTP(S)

Cada solicitação HTTP(S) é registrada por meio do Cloud Logging. Os registros fornecem detalhes como o nome da política de segurança aplicada, a regra de correspondência e se a regra foi aplicada. O registro de solicitações para novos recursos de serviço de back-end é desativado por padrão. Para garantir que as solicitações do Google Cloud Armor sejam registradas, ative a geração de registros HTTP(S).

Para mais informações, consulte Como gerar registros na lista de permissões/proibições de IP.

Saiba como ver os registros do Google Cloud Armor em Como visualizar registros.

Limitações

  • Uma lista de permissões/proibições de IP do balanceamento de carga HTTP(S) não é compatível com buckets de back-end do Cloud Storage.

  • O Google Cloud Armor não é compatível com o balanceamento de carga HTTP(S) interno.

  • As políticas de segurança são aplicadas apenas em ausências no cache do CDN. O conteúdo é exibido no cache mesmo que uma regra de uma política de segurança negue a solicitação.

  • É possível ativar o modo de visualização para uma regra usando a ferramenta de linha de comando gcloud e a sinalização --preview de gcloud compute security-policies rules update.

    Para desativar o modo de visualização, use a sinalização --no-preview, que não está documentada no momento. Também é possível usar o Console do Cloud.

A seguir