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

As políticas de segurança do Google Cloud Armor protegem seu aplicativo fornecendo filtragem de camada 7 e limpando solicitações de entrada para ataques comuns da Web ou outros atributos de camada 7 para potencialmente bloquear o tráfego antes que ele alcance seus serviços ou buckets de back-end com carga balanceada. 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 qualquer um destes:

Grupos de instâncias
Grupos de endpoints de rede (NEGs) zonais
NEGs sem servidor: um ou mais serviços do App Engine, do Cloud Run ou do Cloud Functions
NEGs da Internet para back-ends externos
Buckets no Cloud Storage

Ao usar o Google Cloud Armor para proteger uma implantação híbrida ou uma arquitetura de várias nuvens, os back-ends precisam ser NEGs da Internet. 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 balanceador de carga chegue ao NEG, consulte Controles de entrada.

Proteger as implantações do Google Cloud 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, nega ou redireciona a solicitação 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 (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 aos atributos da camada 3 à camada 7 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, nega ou redireciona a solicitação, dependendo se a regra é uma regra de permissão, uma regra de negação ou uma regra de redirecionamento. Pode haver outros parâmetros de ação para aplicar, como a inserção de cabeçalhos de solicitação. Esse recurso faz parte do gerenciamento de bots do Google Cloud Armor. Para mais informações, consulte a visão geral do gerenciamento de bots.

É 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 (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.

Tipos de políticas de segurança

A tabela a seguir mostra os tipos de política de segurança e o que é possível fazer com elas. Uma marca de seleção (✔) indica que o tipo de política de segurança é compatível com o recurso.

	Política de segurança de back-end	Política de segurança do Edge (visualização)
Ponto de anexo (recurso protegido)	Serviço de back-end	Serviço de back-end Bucket de back-end
Ações da regra	Permitir Negar Redirecionar (GOOGLE_RECAPTCHA e EXTERNAL_302); Prévia	Permitir Negar
Endereço IP de origem	✔	✔
País de origem	✔	✔
Gerenciamento de bots	✔ (Prévia)
Filtragem da camada 7	✔
WAF	✔
Proteção adaptável	✔
Listas de endereços IP nomeados	✔

Políticas de segurança de back-end

As políticas de segurança de back-end são usadas para proteger os serviços de back-end expostos por um balanceador de carga HTTP(S) externo. Elas podem ser usadas para filtrar solicitações e proteger serviços de back-end contendo grupos de instâncias ou grupos de endpoints de rede (NEGs, na sigla em inglês), incluindo NEGs de Internet, zona e sem servidor.

Políticas de segurança de borda

As políticas de segurança de borda permitem que os usuários configurem as políticas de filtragem e controle de acesso do conteúdo armazenado em cache. Isso inclui endpoints como serviços de back-end ativados para o Cloud CDN e buckets do Cloud Storage. As políticas de segurança da borda são compatíveis com a filtragem com base em um subconjunto de parâmetros em comparação com as políticas de segurança de back-end.

As políticas de segurança de borda podem ser configuradas para filtrar solicitações antes que a solicitação seja exibida ao cache do Google. As políticas de segurança de borda são implantadas e aplicadas no perímetro mais externo da rede do Google, acima de onde o cache do Cloud CDN reside. As políticas de segurança de borda podem coexistir com as políticas de segurança de back-end para fornecer duas camadas de proteção. Elas podem ser aplicadas simultaneamente a um serviço de back-end, independentemente dos recursos para os quais o serviço de back-end aponta (por exemplo, grupos de instâncias ou grupos de endpoints de rede). Somente políticas de segurança de borda podem ser aplicadas a buckets de back-end.

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 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, 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:

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

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 de ação excedida podem retornar um HTTP 429 (muitas solicitações).

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 de gerenciamento de bots

Você pode usar regras de gerenciamento de bots para fazer o seguinte:

Redirecione as solicitações de avaliação do reCAPTCHA Enterprise com desafios manuais opcionais.
Avalie os tokens do reCAPTCHA Enterprise anexados a uma solicitação e aplique a ação configurada com base nos atributos do token.
Redirecione as solicitações para seu URL alternativo configurado com uma resposta 302.
Insira cabeçalhos personalizados nas solicitações antes de encaminhá-los aos back-ends.

Para mais informações sobre o gerenciamento de bots, consulte a visão geral de gerenciamento de bots.

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.

Regras de limitação de taxa

Você pode usar regras de limitação de taxa para fazer o seguinte:

Limite as solicitações por cliente com base em um limite que você configura
Para banir temporariamente um cliente que exceda um limite de solicitação, defina por um período configurado.

Para mais informações sobre a limitação de taxa e como ela funciona, consulte Visão geral da limitação de taxa.

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 Google Cloud Armor tem uma geração de registros extensiva e permite definir o nível de detalhes da geração de registros. Para informações completas sobre a geração de registros, consulte Como usar a geração de registros de solicitação.

Análise JSON e registro detalhado

Por padrão, o Google Cloud Armor não analisa o conteúdo JSON de corpos POST quando as regras WAF pré-configuradas são avaliadas. Isso pode fazer com que as regras do WAF sejam barulhentas e potencialmente gerem correspondências positivas falsas nas solicitações recebidas se as cargas de trabalho protegidas veicularem APIs REST ou receberem solicitações com JSON no corpo do POST (Content-Type = "application/json").

Uma regra com ruído é acionada por solicitações que você provavelmente consideraria falsos positivos. Por exemplo, um corpo de solicitação JSON, como '{"test": "123"}', aciona a regra de injeção de SQL owasp-crs-v030001-id942431-sqli se a análise de JSON não estiver ativada.

Recomendamos que você ative a análise JSON se espera que sua carga de trabalho receba solicitações com Content-Type = "application/json", por exemplo, se estiver exibindo APIs REST.

Para reduzir o ruído e os falsos positivos, é possível configurar o Google Cloud Armor para analisar o conteúdo JSON dos corpos do POST. Isso significa que o Google Cloud Armor ignora os caracteres estruturais da mensagem JSON no corpo do POST e analisa apenas os valores fornecidos pelo usuário final na mensagem JSON. Para mais informações sobre as regras WAF pré-configuradas, consulte Como ajustar as regras WAF do Google Cloud Armor.

Além disso, talvez não seja possível saber por que uma regra pré-configurada do WAF foi acionada por uma solicitação específica. Os registros de eventos padrão do Google Cloud Armor contêm a regra que foi acionada, bem como a subassinatura. No entanto, talvez seja necessário identificar os detalhes da solicitação recebida que acionou a regra para solucionar problemas, validar ou ajustar a regra.

É possível ajustar o nível de detalhe registrado nos registros. Recomendamos que você ative o registro detalhado apenas ao criar uma política, fazer alterações ou solucionar problemas. Se você ativar o registro detalhado, ele estará em vigor para regras no modo de visualização, bem como para regras ativas (não visualizadas) durante as operações padrão.

Para mais informações sobre o registro detalhado, consulte Como usar o registro de solicitações.

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

Cada solicitação HTTP(S) avaliada em relação a uma política de segurança do Google Cloud Armor é registrada pelo 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 cada serviço de back-end protegido por uma política de segurança.

Para mais informações, consulte Geração de registros e monitoramento de balanceamento de carga HTTP(S) e Como usar a geração de registros de solicitação.

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

Limitações

As políticas de segurança de back-end são aplicadas somente para solicitações de ausência no cache que passaram nas políticas de segurança de borda.

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.