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 seus aplicativos com balanceamento de carga de ataque distribuído 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 uma implantação híbrida 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, você pode especificar condições que correspondam ao endereço IP, intervalo de IP, código do país ou cabeçalho da solicitação de entrada.

As políticas de segurança do Google Cloud Armor estão disponíveis apenas para serviços de back-end atrás de um balanceador de carga HTTP(S) externo. O balanceador de carga pode estar em nível Premium ou Padrão. Os protocolos HTTP, HTTPS, HTTP/2 e QUIC são todos compatíveis. Para obter informações sobre como configurar o Google Cloud Armor no Google Kubernetes Engine, consulte Como configurar o Google Cloud Armor através do Ingress.

No serviço de back-end podem ser usados VMs em um grupo de instâncias, grupos de endpoint de rede zonal (NEGs zonais) ou grupos de endpoint de rede da Internet (NEGs da Internet). Quando você usa o Google Cloud Armor para proteger uma implantação híbrida ou arquitetura de várias nuvens, os back-end devem ser NEGs da Internet.

Segurança de perímetro com as políticas de segurança do Google Cloud Armor

O Balanceamento de carga HTTP(S) do Google Cloud é implementado na borda da rede do Google nos pontos de presença do Google em todo o mundo. Na camada Premium, o tráfego do usuário direcionado para um balanceador de carga HTTP(S) externo entra no POP mais próximo do usuário e é balanceado em carga na rede global do Google para o back-end mais próximo com capacidade suficiente disponível. Na camada padrão, o tráfego do usuário entra na rede do Google por meio de peering, ISP ou redes de trânsito na região onde você implantou seus recursos do Google Cloud.

As políticas de segurança do Google Cloud Armor deixa que você permita ou negue acesso ao seu balanceador de carga HTTP(S) externo no perímetro do Google Cloud, o mais próximo possível da origem do tráfego recebido. 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 no perímetro da rede
Política do Google Cloud Armor no perímetro da rede (clique para ampliar)

Recursos do Google Cloud Armor

O Google Cloud Armor possui os seguintes recursos.

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

  • Capacidade de associar uma política de segurança do Google Cloud Armor a um ou mais serviços de back-end do balanceamento de carga HTTP(S).
  • Designe a prioridade (ordem de avaliação) quando várias regras estiverem configuradas.
  • As regras de negação podem ser configuradas para exibir um código de erro 403, 404 ou 502.

Regras de lista de permissões e negações de endereços IP em uma política de segurança do Google Cloud Armor

  • Negar a listagem do endereço IP / CIDR concede a capacidade de bloquear um endereço IP de origem ou um intervalo CIDR de acessar balanceadores de carga externos HTTP(S).
  • Permitir listagem para o endereço IP / CIDR concede a capacidade de permitir que um endereço IP de origem ou um intervalo CIDR acesse balanceadores de carga externos HTTP(S).
  • Os endereços IPv4 e IPv6 são compatíveis nas regras de lista de permissões e negações.

Linguagem de regras e mecanismo de imposição

  • Capacidade de escrever expressões de regra personalizadas que podem corresponder em vários atributos das camadas 3 a 7 das solicitações recebidas. O Google Cloud Armor fornece uma linguagem flexível para escrever condições de correspondência personalizadas.
  • Capacidade de combinar várias subexpressões em apenas uma regra.
  • Capacidade de negar ou permitir solicitações com base no código de região da solicitação recebida. Os códigos de região são baseados nos códigos ISO 3166-1 alpha 2.

Regras pré-configuradas para XSS e SQLi

  • Reduza os ataques de script entre sites (XSS) e injeção de SQL (SQLi) usando regras pré-configuradas.
  • As regras XSS e SQLi são baseadas no conjunto de regras principais OWASP Modsecurity versão 3.0.1.

Modo de visualização

  • Capacidade de visualizar os efeitos das regras em uma política de segurança nos registros do Cloud Monitoring sem impor as ações nas regras.
  • Ativar o modo de visualização em um nível por regra.

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 seu balanceador de carga HTTP(S) externo.

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 impor regras de firewall da camada de aplicativos que protegem serviços ou aplicativos externos. 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 for atendida. As condições podem ser tão simples quanto se o endereço IP de origem do tráfego de entrada corresponde a um endereço IP ou intervalo CIDR específico (também conhecido como regras de lista de permissões e negações de endereços IP). Como alternativa, usando a linguagem de regras personalizadas do Google Cloud Armor, você pode criar condições personalizadas que correspondam a vários atributos do tráfego recebido, como caminho do URL, método de solicitação ou 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. Quando você define a opção de visualização como verdadeira, a ação visualizada é registrada, mas não aplicada.

Você pode 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 do Google Cloud Armor associada a ele.

Uma política de segurança do Google Cloud Armor não pode ser excluída se estiver associada a qualquer serviço de back-end. Um serviço de back-end pode ser excluído, independentemente de ter uma política de segurança associada ao Google Cloud Armor.

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

Na ilustração abaixo, 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 no perímetro da rede
Política de segurança do Google Cloud Armor no perímetro da rede (clique para ampliar)

Ordem de avaliação da regra

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

Você atribui uma prioridade às regras, do número mais baixo ao 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 deve ser definida como um número entre 0 e 2.147.483.646. O valor da prioridade 2.147.483.647 é 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 válida de números de prioridade à qual você pode adicionar regras numeradas de 6 a 8, 10 a 11 e 13 a 15 no futuro sem nenhuma alterar para as regras existentes, exceto para a alteração na ordem de execução.

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

Para solicitações POST HTTP, 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 regras que correspondem à ele, mas não corresponde a nenhuma regra pré-configurada no corpo. Se houver várias regras baseadas em cabeçalho, o Google Cloud Armor as avaliará com base em sua prioridade conforme o esperado.

Depois que o Google Cloud Armor recebe o corpo do POST HTTP, ele avalia as regras que se aplicam ao cabeçalho e ao corpo da solicitação. Como resultado, é possível que as regras de prioridade mais baixa que verificam o cabeçalho de uma solicitação sejam correspondidas antes das regras de prioridade mais alta que verificam o corpo da solicitação.

Exemplo

No exemplo a seguir, as regras 1, 2 e 3 são avaliadas nessa ordem para os campos de cabeçalho IP e HTTP. Mas, se um IP 9.9.9.1 iniciar um ataque XSS no corpo do POST HTTP, apenas o corpo será bloqueado (pela regra 2); o cabeçalho HTTP passa para o back-end (pela 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 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 correspondente se nenhuma das regras de prioridade mais alta for correspondente ou se não houver outras regras na política. A regra padrão recebe automaticamente uma prioridade 2.147.483.647 (max int32) e está sempre presente na política de segurança do Google Cloud Armor. Não é possível excluir a regra padrão, mas pode-se 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ê fornecer um valor, ele será ignorado. No entanto, ao atualizar uma política de segurança do Google Cloud Armor, você deve especificar a impressão digital atual, que você obtém ao exportar ou descrever a política.

A impressão digital protege você de substituir a atualização de outro usuário. Se a impressão digital que você fornecer estiver desatualizada, significa que a política de segurança do Google Cloud Armor foi atualizada desde a última vez que você recuperou a impressão digital. Descreva a política de segurança do Google Cloud Armor para verificar se há diferenças e recuperar a impressão digital mais recente.

Políticas de segurança do Google Cloud Armor para regras de firewall de VPC e balanceamento de carga HTTP(S)

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 fornecem segurança de ponta e agem no tráfego do cliente para o Google Front Ends (GFEs).
  • As regras de firewall da VPC permitem ou negam tráfego de e para seus back-end. Você deve criar 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 suas VMs de back-end.

Por exemplo, considere um cenário no qual você queira permitir o tráfego apenas dos intervalos CIDR 100.1.1.0/24 e CIDR 100.1.2.0/24 para acessar seu balanceador de carga HTTP(S) externo. Seu objetivo é garantir que o tráfego não atinja diretamente as instâncias balanceadas de carga de back-end; ou seja, apenas o tráfego externo direcionado por meio do balanceador de carga HTTP(S) externo com uma política de segurança associada deve alcançar as instâncias.

Usando a política de segurança do Google Cloud Armor com firewalls de entrada para restringir o acesso
Usando 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 seus objetivos de segurança configurando sua 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. Consulte Como configurar políticas de segurança para mais instruções. 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. Você pode 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. Para mais informações, consulte Regras de firewall.

Políticas de segurança do Google Cloud Armor para Identity-Aware Proxy e balanceamento de carga HTTP(S)

O Identity-Aware Proxy (IAP) verifica a identidade de um usuário e determina se esse usuário deve 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 de ponta do Google Cloud Armor são anexadas 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, o resultado da avaliação da política de segurança do Google Cloud Armor e o resultado do IAP serão usados juntos para determinar se o tráfego deve ser permitido ou negado no perímetro. O tráfego é bloqueado quando uma configuração de política de segurança do Google Cloud Armor ou IAP resulta em uma decisão de negação. No entanto, a avaliação do IAP ocorre primeiro, portanto, os usuários podem receber uma página solicitando autenticação, mesmo que sua solicitação possa ser negada por uma política de segurança.

Como usar listas de negação de IP e listas de permissão com IAP
Como usar listas de negação de IP e listas de permissão com IAP (clique para ampliar)

Para mais informações sobre IAP e configurações relacionadas, consulte a 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 seja executado fora do Google Cloud, por exemplo, na infraestrutura de outro provedor de nuvem. Você pode 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 de Internet como back-end, que está associado a um aplicativo que está sendo executado no datacenter de um provedor de terceiros.

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

Quando você anexa um beck-end de política de segurança do Google Cloud Armor que possui um NEG de 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 de Internet.

Google Cloud Armor com Cloud CDN

Você pode usar o Google Cloud Armor com Cloud CDN para proteger os servidores de origem da CDN. O Google Cloud Armor garante que o servidor de origem CDN esteja protegido contra ataques a aplicativos, atenua os 10 principais riscos da OWASP e aplica políticas de filtragem da camada 7.

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

Quando uma política de segurança é anexada a um serviço de back-end habilitado para Cloud CDN, o Google Cloud Armor avalia as solicitações recebidas que não podem ser atendidas do cache com relação à política de segurança para determinar se elas devem 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 conectadas a um serviço de back-end habilitado para Cloud CDN não são aplicadas a ocorrências de cache. Se uma solicitação puder ser atendida a partir do cache, ela será atendida a qualquer cliente válido de outra forma, independente do que a política de segurança teria feito para essa solicitação.

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

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

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: como 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 atrás do seu balanceador de carga. Esses usuários têm endereços IP ou blocos de endereços atribuídos pela sua organização. Você pode 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 do 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)

Você controla 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 seu balanceador de carga é permitido. A seção a seguir descreve 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 do Google Cloud Armor, adicione uma regra que permita listas 203.0.113.0/24 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 allow para uma regra deny. A regra padrão controla o tráfego que não corresponde a nenhuma das regras anteriores. É a última regra na política. Alterar a regra de allow para deny bloqueia todo o 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: como bloquear tráfego não autorizado ou malicioso no perímetro 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 possui 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 do balanceador de carga com uma lista de negação
Como restringir o acesso do balanceador de carga com uma lista de negações (clique para ampliar)

Caso de uso 3: como permitir tráfego para o balanceador de carga HTTP(S) externo apenas de um provedor de segurança de terceiros e de outros usuários autorizados que estão em uma lista de permissões

Se sua organização usa um provedor de segurança de terceiros para depurar o tráfego, você pode permitir a lista do endereço IP do provedor de segurança para garantir que apenas o tráfego depurado possa acessar o balanceador de carga HTTP(S) externo e os back-end.

Na ilustração abaixo, 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, permitindo listar o tráfego de um provedor de segurança de terceiros
Como restringir o acesso ao balanceador de carga, permitindo listar o tráfego de um provedor de segurança de terceiros (clique para ampliar)

Caso de uso 4: como particularizar 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 de linguagem das regras personalizadas do Google Cloud Armor.

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

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

origin.region_code == "AU" && inIpRange(origin.ip, '1.2.3.0/24')

O exemplo a seguir corresponde às solicitações de 1.2.3.4 e a um agente do usuário 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 exemplos adicionais, consulte Exemplos de expressões na referência de linguagem de regras. Para informações sobre regras de ajuste, consulte Como ajustar as regras WAF do Google Cloud Armor.

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 aplicativos, como XSS e SQLi. Regras pré-configuradas são conjuntos de expressões predefinidos que você pode adicionar a uma política de segurança do Google Cloud Armor. Para adicionar esses conjuntos de expressões a uma regra, use o console ou sinalizador gcloud --expression. Para mais informações, consulte Como criar políticas e regras de segurança do Google Cloud Armor.

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

O exemplo a seguir usa uma regra pré-configurada para reduzir ataques de script entre sites (XSS):

evaluatePreconfiguredExpr('xss-stable')

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

evaluatePreconfiguredExpr('sqli-stable')

Você também pode combinar regras pré-configuradas com outras expressões. O exemplo a seguir usa uma regra pré-configurada para reduzir 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 implementaçõ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.

Mitigações da OWASP Top 10 para cargas de trabalho híbridas

O Google Cloud Armor oferece redução de injeção SQL (SQLi) e de script entre sites (XSS) para seus aplicativos, estejam eles implantados no Google Cloud, no local ou em um provedor de terceiros. Você pode usar esses recursos para solucionar alguns dos riscos de segurança de aplicativos da web mais comuns, incluindo os identificados na lista OWASP Top 10.

As regras 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 solicitações maliciosas e as coloca no perímetro da infraestrutura do Google. As solicitações não são direcionadas para o serviço de back-end, independentemente de onde o serviço esteja implantado.

Para defender uma carga de trabalho não hospedada no Google Cloud contra ataques SQLi ou XSS no perímetro da rede do Google:

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

Defesa DDoS do servidor de origem externa Cloud CDN e monitoramento da camada 7

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

O Google Cloud Armor e o restante da infraestrutura de perímetro do Google atenuam e descartam ataques L3/L4, alertas sobre atividades suspeitas da camada 7 e estão prontos para negar solicitações indesejadas da camada 7 com regras personalizadas. O registro e a telemetria do Google Cloud Armor no Logging, no Monitoring e no Cloud Security Command Center fornecem informações acionáveis para aplicativos protegidos, independente de onde estejam 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 de 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. Anexe a política de segurança ao serviço de back-end que você criou na etapa 1.
  5. Acesse alertas, registro 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 SQLi e XSS

Você pode usar o Google Cloud Armor para proteger um servidor de origem do Cloud CDN contra riscos como ataques de injeção SQL (SQLi) e scripts entre sites (XSS). O conteúdo de um cache é estático e provavelmente 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 potenciais ou conhecidas de aplicativos da web. Seus requisitos de segurança ou conformidade podem exigir a redução desses riscos para impedir que explorações de vulnerabilidades da Internet ataquem com êxito o servidor de origem.

Para mitigar os riscos siga estas etapas:

  1. Crie ou identifique um serviço de back-end com a CDN ativada.
  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, você pode configurar um serviço de back-end para atender a solicitações de uma variedade de URLs, incluindo conteúdo armazenável e não armazenável em cache. Nesses cenários de implantação, crie políticas de segurança do Google Cloud Armor que negam tráfego indesejado em determinados caminhos de solicitação, mas permitem 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 esteja sendo veiculado com eficiência no cache, um cliente mal-intencionado ou defeituoso pode estar gerando um grande volume de solicitações que resultam em uma falta de cache e exige que o servidor de origem subjacente busque ou gere o conteúdo solicitado. Isso pode sobrecarregar recursos limitados e ter um impacto negativo na disponibilidade do aplicativo para todos os usuários. Você pode criar 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 atinjam o servidor de origem e afetem o desempenho.

Você pode fazer isso executando as seguintes etapas:

  1. Crie uma política de segurança do Google Cloud Armor
  2. Configure uma regra; por exemplo, isso nega acesso a "/admin": request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>'
  3. Anexe a política de segurança da etapa 1 ao serviço de back-end que possui o Cloud CDN ativado.

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

Cada solicitação HTTP(S) é registrada através do Cloud Monitoring 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. Para mais informações, consulte Logging na documentação do HTTP(S) Load Balancing.

Para visualizar os registros do Google Cloud Armor, consulte Como visualizar registros.

Restrições

  • A lista de negação de IP / lista de permissões para o balanceamento de carga HTTP(S) não é suportada para 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 para falhas de cache da CDN.
    • O conteúdo é veiculado no cache mesmo que uma regra em uma política de segurança negue a solicitação.

A seguir