Vista geral da política de segurança

Esta página descreve como pode usar as políticas de segurança do Google Cloud Armor para proteger as suas implementações. Google Cloud

As políticas de segurança do Google Cloud Armor protegem a sua aplicação através do fornecimento de filtragem da camada 7 e da limpeza de pedidos recebidos para ataques Web comuns ou outros atributos da camada 7 para bloquear potencialmente o tráfego antes de chegar aos seus serviços de back-end com balanceamento de carga ou contentores de back-end. Cada política de segurança é composta por um conjunto de regras que podem ser configuradas em atributos da camada 3 à camada 7. As regras podem filtrar o tráfego com base em condições como o endereço IP, o intervalo de IPs, o código da região ou os cabeçalhos de pedidos de um pedido recebido.

As políticas de segurança do Cloud Armor estão disponíveis para os seguintes tipos de balanceadores de carga e pontos finais:

  • Todos os balanceadores de carga de aplicações externos, incluindo os balanceadores de carga de aplicações clássicos
  • Balanceador de carga de aplicações interno regional
  • Balanceador de carga de rede de proxy externo global (TCP/SSL)
  • Balanceador de carga de rede de proxy clássico (TCP/SSL)
  • Balanceador de carga de rede de passagem externo (TCP/UDP)
  • Encaminhamento de protocolos externos
  • VMs com endereços IPv4 externos ou intervalos de endereços IPv6 externos atribuídos a uma interface de rede (NIC)

O balanceador de carga pode estar no nível Premium ou no nível Standard.

Os backends do serviço de backend podem ser qualquer um dos seguintes:

Quando usa o Cloud Armor para proteger uma implementação híbrida ou uma arquitetura de várias nuvens, os back-ends têm de ser NEGs da Internet ou NEGs híbridos. O Cloud Armor também protege os NEGs sem servidor quando o tráfego é encaminhado através de um equilibrador de carga. Para obter informações sobre como encaminhar o tráfego através do balanceador de carga antes de chegar ao NEG sem servidor, consulte os controlos de entrada.

O Cloud Armor também oferece proteção avançada contra DDoS de rede para balanceadores de carga de rede de passagem externos, encaminhamento de protocolos e VMs com endereços IP públicos. Para mais informações sobre a proteção DDoS avançada, consulte o artigo Configure a proteção DDoS de rede avançada.

Proteja as suas Google Cloud implementações com políticas de segurança do Cloud Armor

O equilíbrio de carga externo é implementado no limite da rede da Google nos pontos de presença (PoPs) da Google em todo o mundo. No nível Premium, o tráfego de utilizadores direcionado para um equilibrador de carga externo entra no PoP mais próximo do utilizador. Em seguida, o tráfego é equilibrado na rede global da Google para o back-end mais próximo que tenha capacidade suficiente disponível. No nível padrão, o tráfego de utilizadores entra na rede da Google através de peering, ISP ou redes de trânsito na região onde implementou os seus Google Cloudrecursos.

As políticas de segurança do Cloud Armor permitem-lhe permitir, negar, limitar a velocidade ou redirecionar pedidos para os seus serviços de back-end no Google Cloud limite, o mais perto possível da origem do tráfego recebido. Isto impede que o tráfego indesejável consuma recursos ou entre nas suas redes da nuvem virtual privada (VPC).

O diagrama seguinte mostra a localização dos balanceadores de carga de aplicações externos globais, dos balanceadores de carga de aplicações clássicos, da rede Google e dos centros de dados da Google.

Política do Cloud Armor no limite da rede.
Política do Cloud Armor no limite da rede (clique para aumentar).

Requisitos

Seguem-se os requisitos para usar as políticas de segurança do Cloud Armor:

  • O esquema de balanceamento de carga do serviço de back-end tem de ser EXTERNAL, EXTERNAL_MANAGED ou INTERNAL_MANAGED.
  • O protocolo do serviço de back-end tem de ser um dos seguintes: HTTP, HTTPS, HTTP/2, UDP, TCP, SSL ou UNSPECIFIED.

Acerca das políticas de segurança do Cloud Armor

As políticas de segurança do Cloud Armor são conjuntos de regras que correspondem a atributos de redes da camada 3 à camada 7 para proteger aplicações ou serviços virados para o exterior. Cada regra é avaliada relativamente ao tráfego recebido.

Uma regra de política de segurança do Cloud Armor consiste numa condição de correspondência e numa ação a tomar quando essa condição é cumprida. Por exemplo, uma condição pode ser se o endereço IP de origem do tráfego recebido corresponde a um endereço IP específico ou a um intervalo CIDR (também conhecido como regras de lista de autorizações e lista de recusas de endereços IP). Em alternativa, através da referência da linguagem de regras personalizadas do Cloud Armor, pode criar condições personalizadas que correspondam a vários atributos do tráfego de entrada, como o caminho do URL, o método de pedido ou os valores do cabeçalho do pedido.

Quando um pedido recebido corresponde a uma condição numa regra de política de segurança, o Cloud Armor permite, nega ou redireciona o pedido, com base no facto de a regra ser uma regra de permissão, uma regra de negação ou uma regra de redirecionamento. Podem existir parâmetros de ação adicionais a aplicar, como a inserção de cabeçalhos de pedidos. Esta funcionalidade faz parte da gestão de bots do Cloud Armor. Para mais informações sobre a gestão de bots, consulte a vista geral da gestão de bots.

O Cloud Armor oferece duas categorias de políticas de segurança: políticas de segurança hierárquicas e políticas de segurança ao nível do serviço. As políticas de segurança hierárquicas são anexadas ao nível da organização, da pasta ou do projeto, enquanto as políticas de segurança ao nível do serviço estão associadas a um ou mais serviços de back-end. Para mais informações sobre as políticas de segurança hierárquicas, consulte o artigo Vista geral das políticas de segurança hierárquicas.

Um serviço de back-end pode ter duas políticas de segurança ao nível do serviço associadas ao mesmo tempo, mas não pode ter duas políticas de segurança de back-end nem duas políticas de segurança de limite ao mesmo tempo. No entanto, não é necessário que todos os seus serviços de back-end estejam associados às mesmas políticas de segurança. Para anexar e remover políticas de segurança de serviços e funcionalidades de back-end suportados, consulte o artigo Anexe e remova políticas de segurança.

Se uma política de segurança do Cloud Armor estiver associada a qualquer serviço de back-end, não pode ser eliminada. É possível eliminar um serviço de back-end, independentemente de ter 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, as regras da política são aplicadas a todo o tráfego que entra em cada um dos endereços IP da regra de encaminhamento.

No diagrama seguinte, a política de segurança do Cloud Armor internal-users-policy está associada ao serviço de back-end test-network.

Política de segurança do Cloud Armor no limite da rede.
Política de segurança do Cloud Armor no limite da rede (clique para aumentar).
As políticas de segurança do Cloud Armor têm as seguintes funcionalidades:

  • Opcionalmente, pode usar o protocolo QUIC com equilibradores de carga que usam o Cloud Armor.

  • Pode usar o Cloud Armor com equilibradores de carga que se encontram num dos seguintes níveis de serviço de rede:

    • Nível premium
    • Nível Standard

  • Pode usar políticas de segurança de back-end com o GKE e o controlador de entrada predefinido.

  • Pode usar uma política de segurança predefinida que limita o tráfego acima de um limite especificado pelo utilizador quando configura um dos seguintes equilibradores de carga:

    • Balanceador de carga de aplicações externo global
    • Balanceador de carga de aplicações clássico
    • Balanceador de carga de aplicações externo regional
    • Balanceador de carga de aplicações interno regional
    • Balanceador de carga de rede de proxy externo global (TCP/SSL)
    • Balanceador de carga de rede de proxy clássico (TCP/SSL)

Além disso, pode configurar regras de WAF pré-configuradas do Google Cloud Armor, que são regras complexas de firewall de aplicações Web (WAF) com dezenas de assinaturas compiladas a partir de normas da indústria de código aberto. Cada assinatura corresponde a uma regra de deteção de ataques no conjunto de regras. A Google oferece estas regras tal como estão. As regras permitem que o Cloud Armor avalie dezenas de assinaturas de tráfego distintas, consultando regras com nomes convenientes, em vez de exigir que defina cada assinatura manualmente. Para mais informações sobre as regras da WAF pré-configuradas, consulte a vista geral das regras da WAF pré-configuradas.

Tipos de políticas de segurança

As tabelas seguintes mostram os tipos de políticas de segurança ao nível do serviço e o que pode fazer com elas. Uma marca de verificação () indica que o tipo de política de segurança suporta a funcionalidade.

Políticas de segurança do back-end

As políticas de segurança de back-end são usadas com serviços de back-end expostos pelos seguintes tipos de balanceadores de carga:

  • Balanceador de carga de aplicações externo global
  • Balanceador de carga de aplicações clássico
  • Balanceador de carga de aplicações externo regional
  • Balanceador de carga de aplicações interno regional
  • Balanceador de carga de rede de proxy externo global
  • Balanceador de carga de rede de proxy clássico

Usa políticas de segurança de back-end para filtrar pedidos e proteger serviços de back-end que referenciam grupos de instâncias ou qualquer um dos tipos de NEG suportados atrás dos tipos de balanceadores de carga indicados anteriormente. Para mais informações sobre os NEGs suportados pelo seu equilibrador de carga, consulte a vista geral dos grupos de pontos finais de rede.

Quando usar equilibradores de carga de rede de proxy externos globais ou equilibradores de carga de rede de proxy clássicos, o Cloud Armor aplica a ação da regra da política de segurança deny apenas em novos pedidos de ligação. A ação deny termina a ligação TCP. Além disso, se fornecer um código de estado com a ação deny, o código de estado é ignorado.

As políticas de segurança do back-end têm o valor da flag type opcional CLOUD_ARMOR. Se não definir a flag type, o valor predefinido é CLOUD_ARMOR.

Políticas de segurança de edge

As políticas de segurança de limite permitem que os utilizadores configurem políticas de filtragem e controlo de acesso para conteúdo armazenado na cache. Isto inclui pontos finais como serviços de back-end ativados para a CDN do Google Cloud e contentores do Cloud Storage. As políticas de segurança de limite suportam a filtragem com base num subconjunto de parâmetros em comparação com as políticas de segurança de back-end. Não pode definir uma política de segurança de limite como uma política de back-end. As políticas de segurança de Edge são suportadas para os seguintes pontos finais:

  • Balanceador de carga de aplicações externo global
  • Balanceador de carga de aplicações clássico

As políticas de segurança de limite podem ser configuradas para filtrar pedidos antes de o pedido ser publicado a partir da cache da Google. As políticas de segurança de limite são implementadas e aplicadas perto do perímetro mais exterior da rede da Google, a montante de onde reside a cache do Cloud CDN. As políticas de segurança de edge podem coexistir com as políticas de segurança de back-end para oferecer duas camadas de proteção. 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 pontos finais de rede. Apenas as políticas de segurança de limite podem ser aplicadas a contentores de back-end.

Quando as políticas de segurança de edge e as políticas de segurança de back-end estão anexadas ao mesmo serviço de back-end, as políticas de segurança de back-end só são aplicadas a pedidos de cache miss que passaram pelas políticas de segurança de edge.

As políticas de segurança de Edge são avaliadas e aplicadas antes do Identity-Aware Proxy (IAP). Um pedido bloqueado por uma política de segurança de limite é recusado antes de o IAP avaliar a identidade do requerente. O bloqueio de um pedido com uma regra na política de segurança de limite impede que o IAP apresente uma página de início de sessão ou tente autenticar o utilizador de outra forma.

As políticas de segurança de Edge têm o valor de flag typeCLOUD_ARMOR_EDGE.

Políticas de segurança de limite de rede

As políticas de segurança de limite de rede permitem-lhe configurar regras para bloquear tráfego no limite da rede da Google. A aplicação de políticas de segurança de limite de rede não consome recursos de VMs nem de anfitriões, o que ajuda a evitar que o tráfego de volume elevado esgote os recursos na carga de trabalho de destino ou cause uma negação de serviço. Pode configurar políticas de segurança de limite de rede para os seguintes recursos:

  • Balanceadores de carga de rede de encaminhamento externos
  • Encaminhamento de protocolos
  • VMs com endereços IP públicos

As políticas de segurança do limite da rede suportam a filtragem com base em alguns dos mesmos parâmetros que as políticas de segurança do back-end e são o único tipo de política de segurança que suporta a filtragem de deslocamento de bytes. Para ver uma lista completa dos parâmetros disponíveis, consulte a tabela Tipos de políticas de segurança.

As políticas de segurança de limite de rede têm o valor da flag type CLOUD_ARMOR_NETWORK. Para configurar políticas de segurança de limite de rede, tem de configurar primeiro a proteção avançada contra DDoS de rede na região em que pretende criar as políticas. Para mais informações sobre a proteção DDoS avançada, consulte o artigo Configure a proteção DDoS de rede avançada.

Políticas de segurança de serviços internos

As políticas de segurança de serviços internos permitem-lhe configurar a limitação de taxa de partilha equitativa com a Cloud Service Mesh. Em vez de anexar uma política de segurança de serviço interno a um serviço de back-end ou a um contentor de back-end, anexa-a a uma política de endpoint do Cloud Service Mesh. Para saber mais acerca das políticas de segurança dos serviços internos, consulte o artigo Configure a limitação de taxa com o Cloud Armor na documentação do Cloud Service Mesh.

Ordem de avaliação das regras

A ordem de avaliação das regras é determinada pela prioridade das regras, do número mais baixo para o mais alto. A regra com o valor numérico mais baixo atribuído tem a prioridade lógica mais elevada 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 respetivo número aumenta (1, 2, 3, N+1). Não pode configurar duas ou mais regras com a mesma prioridade. A prioridade de cada regra tem de ser definida como um número de 0 a 2147483646, inclusive. O valor de prioridade 2147483647, também conhecido como INT-MAX, está reservado para a regra predefinida.

Os números de prioridade podem ter lacunas. Estas lacunas permitem-lhe adicionar ou remover regras no futuro sem afetar as restantes regras. Por exemplo, 1, 2, 3, 4, 5, 9, 12, 16 é uma série válida de números de prioridade à qual pode adicionar regras numeradas de 6 a 8, de 10 a 11 e de 13 a 15 no futuro. Não precisa de alterar as regras existentes, exceto a ordem de execução.

Normalmente, é aplicada a regra de prioridade mais elevada que corresponde ao pedido. No entanto, existe uma exceção quando os pedidos HTTP POSTcom um corpo são avaliados em função de regras pré-configuradas que usam evaluatePreconfiguredWaf. A exceção é a seguinte:

Para pedidos HTTP POST, o Cloud Armor recebe o cabeçalho do pedido antes do corpo (payload). Uma vez que o Cloud Armor recebe primeiro as informações do cabeçalho, avalia as regras que correspondem ao cabeçalho, mas não corresponde a nenhuma regra pré-configurada no corpo. Se existirem várias regras baseadas em cabeçalhos, o Cloud Armor avalia-as com base na respetiva prioridade, conforme esperado. Tenha em atenção 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 for correspondente durante a seguinte fase de processamento do corpo, é traduzida numa ação deny. A ação do cabeçalho do pedido personalizado, se for encontrada durante a fase de processamento do corpo, não entra em vigor.

Depois de o Cloud Armor receber o pedido HTTP POST com um corpo, avalia as regras que se aplicam aos cabeçalhos e ao corpo do pedido. Como resultado, é possível que as regras de prioridade mais baixa que permitem o cabeçalho de um pedido sejam correspondidas antes das regras de prioridade mais elevada que bloqueiam o corpo do pedido. Nestes casos, é possível que a parte do cabeçalho HTTP do pedido seja enviada para o serviço de back-end de destino, mas o corpo que contém conteúdo potencialmente malicioso é bloqueado. O Cloud Armor inspeciona até aos primeiros 64 KB (de acordo com o limite de inspeção configurado de 8 KB, 16 KB, 32 KB, 48 KB ou 64 KB) do corpo do pedido. Para mais informações acerca desta limitação, consulte a secção Limitação da inspeção do corpo de POST e PATCH.

A expressão evaluatePreconfiguredWaf() para regras pré-configuradas é a única expressão que é avaliada em relação ao corpo do pedido. Todas as outras expressões são avaliadas apenas em relação ao cabeçalho do pedido. Entre os HTTP tipos de pedidos com um corpo do pedido, o Cloud Armor processa apenas pedidos POST e PATCH. A inspeção está limitada ao limite de inspeção configurado, até aos primeiros 64 KB (8 KB, 16 KB, 32 KB, 48 KB ou 64 KB) do corpo do pedido e é descodificada como parâmetros de consulta de URL. O Cloud Armor pode analisar e aplicar regras de WAF pré-configuradas para corpos POSTformatados em JSONContent-Type = "application/json". No entanto, o Cloud Armor não suporta outros descodificadores baseados em Content-Type/Content-Encoding HTTP, como XML, Gzip ou UTF-16.

Exemplos

No exemplo seguinte, as regras 1, 2 e 3 são avaliadas nessa ordem para os campos de cabeçalho IP e HTTP. No entanto, se um endereço IP 9.9.9.1 iniciar um ataque XSS no corpo HTTP POST, apenas o corpo é bloqueado (pela regra 2); o cabeçalho HTTP é transmitido para o back-end (pela regra 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredWaf('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 seguinte, a política permite IP 9.9.9.1 sem verificar 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: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Regra predefinida

Cada política de segurança do Cloud Armor contém uma regra predefinida que tem correspondência se nenhuma das regras de prioridade mais alta tiver correspondência ou se não existirem outras regras na política. À regra predefinida é atribuída automaticamente uma prioridade de 2147483647 (INT-MAX) e está sempre presente na política de segurança.

Não pode eliminar a regra predefinida, mas pode modificá-la. A ação predefinida para a regra predefinida é deny, mas pode alterar a ação para allow.

Impressão digital

Cada política de segurança do Cloud Armor tem um campo fingerprint. A impressão digital é um hash do conteúdo armazenado na política. Quando cria uma nova política, não indique o valor deste campo. Se fornecer um valor, este é ignorado. No entanto, quando atualiza uma política de segurança, tem de especificar a impressão digital atual, que obtém quando exporta ou descreve a política (usando EXPORT ou DESCRIBE, respetivamente).

A impressão digital protege-o contra a substituição da atualização de outro utilizador. Se a impressão digital que fornecer estiver desatualizada, significa que a política de segurança foi atualizada desde a última vez que obteve a impressão digital. Para verificar se existem diferenças e obter a impressão digital mais recente, execute o comando DESCRIBE.

Idioma das regras e motor de aplicação

A linguagem de regras e o motor de aplicação oferecem o seguinte:

  • A capacidade de escrever expressões de regras personalizadas que podem corresponder a vários atributos da camada 3 à camada 7 de pedidos recebidos. O Cloud Armor fornece atributos de linguagem de regras personalizadas para escrever condições de correspondência personalizadas.

  • A capacidade de combinar até 5 subexpressões numa única regra.

  • A capacidade de recusar ou permitir pedidos com base no código da região do pedido recebido. Os códigos de região baseiam-se nos códigos ISO 3166-1 alfa-2. Por vezes, os códigos de região correspondem a países específicos, mas alguns abrangem um país e as respetivas áreas associadas. Por exemplo, o código US inclui todos os estados dos Estados Unidos, um distrito e seis áreas periféricas.

Tipos de regras

O Cloud Armor tem os seguintes tipos de regras.

Regras de listas de autorizações e listas de proibições de endereços IP

Pode criar regras de lista de autorizações e de lista de exclusões de endereços IP numa política de segurança. Alguns exemplos incluem o seguinte:

Pode criar regras de lista de permissões e lista de negações de endereços IP numa política de segurança. Alguns exemplos incluem o seguinte:

  • A adição de um endereço IP ou um intervalo CIDR a uma lista de recusa permite-lhe bloquear um endereço IP de origem ou um intervalo CIDR de aceder a equilibradores de carga suportados.

  • A adição de um endereço IP ou um intervalo CIDR a uma lista de autorizações permite-lhe autorizar um endereço IP de origem ou um intervalo CIDR a aceder a equilibradores de carga suportados.

  • Os endereços IPv4 e IPv6 são suportados nas regras de lista de autorizações e lista de recusas.

  • As regras de recusa podem devolver um código de estado HTTP 403 Unauthorized, 404 Access Denied ou 502 Bad Gateway.

  • As regras de ações excedidas podem devolver um Código de estado HTTP 429 Too Many Requests.

Regras de geografia de origem

Pode permitir ou recusar pedidos originados de áreas geográficas selecionadas definidas pelo código de país Unicode.

O Cloud Armor usa a nossa própria base de dados de geolocalização de IP para identificar a localização geográfica do pedido. A base de dados é atualizada regularmente. Embora não possamos garantir uma cadência de atualização específica, durante as operações normais, os mapeamentos que o Cloud Armor usa são atualizados cerca de uma vez por semana.

As associações atualizadas têm de ser propagadas à infraestrutura da Google a nível global. O processo de implementação ocorre gradualmente, normalmente ao longo de vários dias, em várias zonas e regiões nas quais o Cloud Armor está implementado. Devido a este processo de implementação gradual, é possível ver pedidos do mesmo endereço IP de origem a serem processados de forma inconsistente durante uma implementação quando o mapeamento de geolocalização do endereço IP de origem tiver sido alterado.

Regras de WAF pré-configuradas

O Cloud Armor oferece uma lista abrangente de regras de WAF pré-configuradas com base no OWASP Core Rule Set (CRS) para ajudar a detetar o seguinte:

  • Ataques de injeção SQL
  • Ataques de cross-site scripting
  • Ataques de inclusão de ficheiros locais
  • Ataques de inclusão de ficheiros remotos
  • Ataques de execução remota de código
  • Ataques de aplicação de métodos
  • Ataques de deteção de scanners
  • Ataques de protocolo
  • Ataques de injeção de PHP
  • Ataques de fixação de sessão
  • Ataques Java
  • Ataques NodeJS

Para ver detalhes, consulte a vista geral das regras de WAF pré-configuradas do Cloud Armor.

Regras de gestão de bots

Pode usar regras de gestão de bots para o seguinte:

  1. Redirecionar pedidos de avaliação do reCAPTCHA com desafios manuais opcionais.
  2. Avalie os tokens do reCAPTCHA anexados a um pedido e aplique a ação configurada com base nos atributos do token.
  3. Redirecionar pedidos para o URL alternativo configurado com um código de estado 302.
  4. Inserir cabeçalhos personalizados nos pedidos antes de os encaminhar para os seus backends.

Para mais informações sobre a gestão de bots, consulte a vista geral da gestão de bots.

Regras pré-configuradas para listas de endereços IP com nome

As regras pré-configuradas para listas de endereços IP nominados oferecem o seguinte:

  • Integre as listas de endereços IP nominados de fornecedores externos com o Cloud Armor.

  • Simplifique a manutenção de intervalos de endereços IP permitidos ou recusados.

  • Sincronize as listas de fornecedores externos diariamente.

  • Aumente a sua capacidade de configurar endereços IP e intervalos nas políticas de segurança, uma vez que as listas de endereços IP com nomes não estão sujeitas a limites no número de endereços IP por regra.

Regras de limitação de velocidade

Pode usar regras de limitação de taxa para fazer o seguinte:

  • Limite as solicitações por cliente com base num limite que configurar.
  • Banir temporariamente clientes que excedam um limite de pedidos que definir para uma duração configurada.

Quando usa a limitação de taxa com balanceadores de carga de rede de proxy externos globais ou balanceadores de carga de rede de proxy clássicos, aplicam-se as seguintes restrições:

  • O Cloud Armor aplica apenas ações de limitação de velocidade, como a limitação ou a proibição de pedidos de novas ligações de clientes.
  • Apenas são suportados os tipos de chaves ALL e IP.
  • Se tentar usar o tipo de chave HTTP-HEADER ou HTTP-COOKIE com balanceadores de carga TCP/SSL, o tipo de chave é interpretado como ALL e, da mesma forma, XFF-IP é interpretado como IP.

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

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

Modo de pré-visualização

Pode pré-visualizar os efeitos de uma regra sem a aplicar. No modo de pré-visualização, as ações são registadas no Cloud Monitoring. Pode optar por pré-visualizar regras individuais numa política de segurança ou pré-visualizar todas as regras na política. É-lhe cobrada a taxa normal por pedido para regras no modo de pré-visualização.

Pode ativar o modo de pré-visualização para uma regra através da CLI do Google Cloud e da flag --preview do comando gcloud compute security-policies rules update.

Para desativar o modo de pré-visualização, use a flag --no-preview. Também pode usar a Google Cloud consola.

Se um pedido acionar uma pré-visualização, o Cloud Armor continua a avaliar outras regras até encontrar uma correspondência. A regra correspondente e a regra de pré-visualização estão disponíveis nos registos.

Respostas de erro personalizadas

Quando usa um Application Load Balancer externo global, pode configurar respostas de erro personalizadas para códigos de estado HTTP para erros gerados por balanceadores de carga ou instâncias de back-end. Além disso, pode configurar códigos de erro personalizados para o tráfego que o Cloud Armor nega configurando páginas de resposta personalizadas para a mesma série de códigos de estado 4xx ou 5xx que as regras da política de segurança existentes usam.

Para mais informações sobre respostas de erro personalizadas, consulte a Vista geral das respostas de erro personalizadas. Para ver os passos de configuração, consulte o artigo Configure respostas de erro personalizadas.

Registo

O Cloud Armor tem um registo extenso e permite-lhe definir o nível de detalhe do seu registo. Os registos do Cloud Armor são gerados com base na primeira regra (prioridade mais alta) que corresponde a um pedido recebido, quer a política de segurança esteja ou não no modo de pré-visualização. Isto significa que não são gerados registos para regras que não correspondam nem para regras correspondentes com prioridades mais baixas.

Para ver informações completas sobre o registo, consulte o artigo Use request logging. Para mais informações sobre o registo detalhado, consulte o artigo Registo detalhado. Para ver os registos do Cloud Armor, consulte o artigo Ver registos.

Registo de pedidos do balanceador de carga de aplicações externo

Cada pedido HTTP(S) que é avaliado em função de uma política de segurança do Cloud Armor é registado através do Cloud Logging. Os registos fornecem detalhes como o nome da política de segurança aplicada, a regra correspondente e se a regra foi aplicada. Por predefinição, o registo de pedidos para novos recursos de serviços de back-end está desativado. Para registar pedidos do Cloud Armor, tem de ativar o registo HTTP(S) para cada serviço de back-end protegido por uma política de segurança.

Para mais informações, consulte o artigo Registo e monitorização do balanceador de carga de aplicações externo.

Registo de pedidos do balanceador de carga de rede de proxy externo

Pode configurar o registo para balanceadores de carga de rede de proxy externos através dos comandos da CLI gcloud, conforme indicado em Registo e monitorização do balanceamento de carga de proxy TCP/SSL. Não pode ativar o registo para equilibradores de carga de rede de proxy externos através da Google Cloud consola.

Limitações

As secções seguintes detalham as limitações das políticas de segurança.

Limitação da inspeção do corpo POST e PATCH

A expressão evaluatePreconfiguredWaf para regras pré-configuradas é a única expressão que o Cloud Armor avalia em relação ao corpo do pedido. Entre os tipos de pedidos HTTP com um corpo de pedido, o Cloud Armor processa apenas pedidos POST e PATCH.

A inspeção está limitada ao limite de inspeção configurado, até aos primeiros 64 KB (8 KB, 16 KB, 32 KB, 48 KB ou 64 KB) do corpo POST ou PATCH. Para saber mais acerca da configuração do limite de inspeção para o corpo do pedido quando usar regras de WAF pré-configuradas, consulte o artigo Atualize o limite de inspeção para regras de WAF pré-configuradas.

O resto do corpo do pedido pode conter payloads que corresponderiam a uma assinatura de regra de WAF, que a sua aplicação pode aceitar. Para mitigar o risco de corpos de pedidos cujo tamanho excede o limite de inspeção configurado, até aos primeiros 64 KB (8 KB, 16 KB, 32 KB, 48 KB ou 64 KB), consulte o artigo Mitigue o risco no corpo do pedido que excede o limite de inspeção configurado.

O Cloud Armor pode analisar e aplicar regras de WAF pré-configuradas para corpos POST e PATCH codificados por URL e formatados em JSON predefinidos (Content-Type = "application/json"). Nesse caso, as regras são aplicadas independentemente aos nomes e valores descodificados nos dados. Para outros tipos de conteúdo e tipos de codificação, o Cloud Armor não descodifica os dados, mas aplica as regras pré-configuradas aos dados não processados.

Como são processadas as ligações WebSocket

Os balanceadores de carga de aplicações externos globais têm suporte incorporado para o protocolo WebSocket. Os canais WebSocket são iniciados a partir de pedidos HTTP(S). O Cloud Armor pode impedir o estabelecimento de um canal WebSocket, por exemplo, se uma lista de negação de endereços IP bloquear o endereço IP de origem. No entanto, as transações subsequentes no canal não estão em conformidade com o protocolo HTTP e o Cloud Armor não avalia nenhuma mensagem após o primeiro pedido.

O que se segue?