Visão geral da política de segurança

As políticas de segurança do Google Cloud Armor protegem seu aplicativo controlando quais solicitações tem permissão ou negação de acesso ao balanceador de carga. Cada política de segurança é composta por um conjunto de regras que filtram o tráfego com base em condições, como o endereço IP de uma solicitação recebida, o intervalo IP, o código da região ou os cabeçalhos das solicitações.

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.

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). Quando você usa o Google Cloud Armor para proteger uma implantação híbrida ou uma arquitetura de várias nuvens, com o Traffic Director em uma implantação local ou de vários ambientes, os back-ends precisam ser NEGs da Internet ou de conectividade híbrida. O Google Cloud Armor também protege os NEGs sem servidor quando o tráfego é roteado por um balanceador de carga. Para garantir que apenas o tráfego roteado pelo seu balanceador de carga chegue ao NEG, consulte Controles de entrada.

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.

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 correspondem a atributos do L3 ao L7 para proteger aplicativos ou serviços 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 é 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 solicitação recebida corresponde a uma condição em uma regra de política de segurança, o Google Cloud Armor permite ou nega a solicitação, com base na regra de permissão ou regra de negação.

É possível associar uma política de segurança do Google Cloud Armor a um ou mais serviços de back-end. Apenas uma política de segurança pode estar associada a um serviço de back-end, mas seus serviços de back-end não precisam estar associados à mesma política de segurança.

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)

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.

  • Use o Google Cloud Armor com balanceadores de carga HTTP(S) externos que estejam em um dos seguintes níveis de serviço de rede:

    • Nível Premium
    • Nível Standard

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

Ordem de avaliação da regra

A ordem de avaliação da regra é determinada pela prioridade da regra, do menor número para o maior. 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 o número dela 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, incluindo ambos. 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 quando as solicitações HTTP POST são avaliadas em relação a regras pré-configuradas que usam evaluatePreconfiguredExpr(). A exceção está descrita abaixo.

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, mas o corpo POST com conteúdo potencialmente mal-intencionado estará 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 da regra padrão é permitir, mas é possível alterar a ação para negar.

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 é obtida ao exportar ou descrever a política (usando EXPORT ou DESCRIBE, respectivamente).

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, execute o comando DESCRIBE.

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.

Tipos de regras

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: Veja alguns exemplos:

  • 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).

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.2 do conjunto de regras principais do OWASP Modsecurity (em inglês).

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 visualizar regras individuais ou todas as regras da política de segurança.

Ative o modo de visualização em 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.

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).

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.

  • 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.

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.

A seguir