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 de balanceadores de carga HTTP(S) externos globais, balanceadores de carga HTTP(S) externos globais (clássicos), balanceadores de carga de proxy TCP ou balanceadores de carga de proxy SSL externos. 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.

O Google Cloud Armor também fornece proteção avançada contra DDoS de rede para balanceador de carga de rede TCP/UDP externo, encaminhamento de protocolo e VMs com endereços IP públicos. Para mais informações sobre a proteção avançada contra DDoS, consulte Configurar a proteção avançada contra DDoS da rede.

Proteger as implantações do Google Cloud com as políticas de segurança do Google Cloud Armor

O balanceamento de carga externo é 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 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.

As políticas de segurança do Google Cloud Armor permitem permitir, negar, limitar a taxa ou redirecionar os pedidos para o balanceador de carga HTTP(S) externo, balanceador de carga HTTP(S) externo (clássico) e balanceadores de carga de proxy TCP ou SSL externos 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 HTTP(S) externos e globais, da rede do Google e dos 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:

Ele precisa ser um balanceador de carga HTTP(S) externo, balanceador de carga HTTP(S) externo (clássico), balanceador de carga de proxy TCP ou balanceador de carga de proxy SSL externos.
O esquema de balanceamento de carga do serviço de back-end precisará ser EXTERNAL ou EXTERNAL_MANAGED se você estiver usando um balanceador de carga HTTP(S) externo global.
O protocolo do serviço de back-end precisa ser HTTP, HTTPS, HTTP/2, TCP ou SSL.

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.
É possível usar o Google Cloud Armor com balanceadores de carga que estão 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 endpoint
Tipo de front-end	Balanceador de carga HTTP(S) global externo/balanceador de carga HTTP(S) global (clássico)	Balanceador de carga de proxy TCP externo/balanceador de carga de proxy SSL externo	Balanceador de carga HTTP(S) externo/balanceador de carga HTTP(S) global (clássico)
Ponto de anexo (recurso protegido)	Serviço de back-end	Serviço de back-end	Serviço de back-end Bucket de back-end
Ações da regra	Permitir Negar Redirecionamento (GOOGLE_RECAPTCHA and EXTERNAL_302) Limitar Proibição com base na taxa	Permitir Negar Limitar Proibição com base na taxa	Permitir Negar
Endereço IP de origem	✔	✔	✔
País de origem	✔	✔	✔
ASN de origem	✔	✔
Limitação de taxa	✔	✔
Gerenciamento de bots	✔
Filtragem da camada 7	✔
WAF	✔
Proteção adaptável	✔
Listas de endereços IP nomeados	✔
Threat Intelligence (Visualização)	✔

Políticas de segurança de back-end

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

Ao usar um balanceador de carga de proxy TCP externo, o Google Cloud Armor aplica a ação da regra de política de segurança deny apenas em novas solicitações de conexão. A ação deny encerra a conexão TCP. Além disso, se você fornecer um código de status com sua ação deny, o código de status será ignorado.

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. Não é possível definir uma política de segurança de borda como uma política de back-end. As políticas de segurança de borda não são compatíveis com balanceadores de carga de proxy TCP ou SSL externos.

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.

Quando as políticas de segurança de borda e de back-end são anexadas ao mesmo serviço de back-end, as políticas de segurança de back-end são aplicadas somente a solicitações de ausência no cache que passaram por políticas de segurança de borda.

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. Observe que as ações redirect e a inserção de ações de cabeçalho personalizadas só funcionam durante a fase de processamento do cabeçalho. A ação redirect, se correspondida durante a fase de processamento do corpo a seguir, for convertida em uma ação deny. A ação de cabeçalho da solicitação personalizada, se houver correspondência durante a fase de processamento do corpo, não terá efeito.

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. O Google Cloud Armor inspeciona os primeiros 8 KB do corpo de POST. Para mais informações sobre essa limitação, consulte Limitação de inspeção do corpo do POST.

A expressão evaluatePreconfiguredExpr() para regras pré-configuradas é a única que é avaliada em relação ao corpo da solicitação. Todas as demais expressões são avaliadas apenas no cabeçalho da solicitação. Entre os tipos de solicitações HTTP com um corpo de solicitação, o Google Cloud Armor processa apenas solicitações POST. A inspeção é limitada aos primeiros 8 KB do corpo do POST e é decodificada como parâmetros de consulta de URL. O Google Cloud Armor pode analisar e aplicar regras WAF pré-configuradas para corpos POST com formatação JSON (conteúdo- tipo='aplicação/json'). No entanto, o Google Cloud Armor não é compatível com outros decodificadores baseados em HTTP Content-Type/Content-Encoding, como XML, Gzip ou UTF-16.

Examples

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 a regra padrão é deny, mas é possível alterar para allow.

Impressão digital

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

O Google Cloud Armor tem os seguintes 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 lista de bloqueio do endereço IP/CIDR permite bloquear o acesso de um endereço IP de origem ou de um intervalo CIDR aos balanceadores de carga compatíveis.
A listagem de permissões de endereços IP/CIDR possibilita que um endereço IP de origem ou um intervalo CIDR acesse balanceadores de carga compatíveis.
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.
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.
Banir temporariamente clientes que excedam um limite de solicitação que você definiu para uma duração configurada.

Quando você usa a limitação de taxa com balanceadores de carga de proxy TCP ou proxy SSL externos, as seguintes restrições se aplicam:

O Google Cloud Armor aplica apenas ações de limitação de taxa, como limitação ou banimento de novas solicitações de conexão dos clientes.
Somente os tipos de chave ALL e IP são compatíveis com balanceamento de carga de proxy TCP externo e de proxy SSL externo.
Se você tentar usar o tipo de chave HTTP-HEADER ou HTTP-COOKIE com balanceadores de carga TCP/SSL, o tipo de chave será interpretado como ALL, e XFF-IP como IP.

Para mais informações sobre a limitação de taxa e como ela funciona, consulte a 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.

É possível ativar o modo de visualização para uma regra usando a Google Cloud CLI 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 Google Cloud.

Se uma solicitação acionar uma visualização, o Google Cloud Armor continuará avaliando outras regras até encontrar uma correspondência. As regras correspondente e de visualização estarão disponíveis nos registros.

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 dos corpos POST quando as regras WAF (firewalls de aplicativos da Web) 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. Por padrão, esta opção está desativada. A sintaxe da sinalização é a seguinte:

--json-parsing=[STANDARD | DISABLED]

A sinalização está disponível apenas com gcloud compute security-policies update. Não é possível criar uma nova política de segurança com essa opção, a menos que você crie uma política de segurança em um arquivo e importe esse arquivo.

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.

Geração de registros de solicitação de balanceamento de carga de proxy TCP e SSL externos

É possível configurar a geração de registros do balanceamento de carga de proxy TCP externo e de SSL externo usando os comandos da CLI do Google Cloud, conforme listado em Geração de registros e monitoramento de balanceamento de carga HTTP(S). Não é possível ativar a geração de registros para o balanceamento de carga de proxy TCP e SSL externos usando o console do Google Cloud.

Limitações

Nas seções a seguir, detalhamos as limitações de políticas de segurança.

Limitação de inspeção do corpo

A expressão evaluatePreconfiguredExpr() das regras pré-configuradas é a única expressão que o Google Cloud Armor avalia em relação ao corpo da solicitação. Entre os tipos de solicitações HTTPS com um corpo de solicitação, o Google Cloud Armor processa apenas solicitações POST.

A inspeção é limitada aos primeiros 8 KB do corpo POST e é decodificada como parâmetros de consulta de URL. O restante do corpo POST pode conter código malicioso, que o aplicativo pode aceitar. Para reduzir o risco de corpos POST com tamanho maior que 8 KB, consulte o guia de solução de problemas.

O Google Cloud Armor pode analisar e aplicar regras WAF pré-configuradas para corpos POST padrão codificados em URL e formatados em JSON (Content-Type='application/json'). Nesse caso, as regras são aplicadas de maneira independente nos nomes decodificados e valores nos dados. Para outros tipos de conteúdo e de codificação, o Google Cloud Armor não decodifica os dados, mas aplica as regras pré-configuradas nos dados brutos.

Como as conexões WebSocket são processadas

O balanceador de carga HTTP(S) externo global é compatível com 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.