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.
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
ouHTTP/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
.
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) ou502
(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
- Configure políticas, regras e expressões de segurança
- Saiba mais sobre os recursos nos níveis de proteção gerenciada
- Saiba mais sobre listas de endereços IP nomeados
- Resolver problemas