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. Trusted Cloud by S3NS

As políticas de segurança do Cloud Armor estão disponíveis para balanceadores de carga de aplicações externos regionais.

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

• Grupos de instâncias
• Todos os tipos de grupos de pontos finais da rede (NEG) suportados pelo seu balanceador de carga

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.

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

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

Requisitos

• O esquema de balanceamento de carga do serviço de back-end tem de ser EXTERNAL_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.

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.

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

• 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 equilibradores de carga de aplicações externos regionais.

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

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?

• Configure as políticas de segurança do Cloud Armor
• Resolva problemas do Cloud Armor