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

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

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

Os back-ends do serviço de back-end podem ser qualquer um destes:

• Grupos de instâncias
• Todos os tipos de grupo de endpoints de rede (NEG) compatíveis com o balanceador de carga

Ao usar o Cloud Armor para proteger uma implantação híbrida ou uma arquitetura multicloud, os back-ends precisam ser NEGs da Internet ou híbridos. O Cloud Armor também protege os NEGs sem servidor quando o tráfego é roteado por um balanceador de carga. Para informações sobre como rotear o tráfego pelo balanceador de carga antes que ele chegue ao NEG sem servidor, consulte Controles de entrada.

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

Com as políticas de segurança do Cloud Armor, é possível permitir, negar, limitar taxas ou redirecionar solicitações aos serviços de back-end na borda Trusted 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).

Requisitos

• O esquema de balanceamento de carga do serviço de back-end precisa ser EXTERNAL_MANAGED.
• O protocolo do serviço de back-end precisa ser HTTP, HTTPS, HTTP/2, UDP, TCP, SSL ou UNSPECIFIED.

Sobre as políticas de segurança do Cloud Armor

As políticas de segurança do Cloud Armor são conjuntos de regras que correspondem aos atributos das redes 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 Cloud Armor consiste em uma condição de correspondência e uma ação a ser tomada quando essa condição é atendida. Por exemplo, uma condição pode ser 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 Cloud Armor, é possível criar condições personalizadas que correspondam a vários atributos do tráfego de entrada, como o caminho do URL, o método de solicitação ou os 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 Cloud Armor permite, nega ou redireciona a solicitação, dependendo se a regra é de permissão, negação ou 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 no nível do serviço. As políticas de segurança hierárquicas são anexadas no nível da organização, da pasta ou do projeto, enquanto as políticas de segurança no nível do serviço são associadas a um ou mais serviços de back-end. Para mais informações sobre políticas de segurança hierárquicas, consulte Visão geral das políticas de segurança hierárquicas.

Um serviço de back-end pode ter duas políticas de segurança no nível do serviço associadas a ele ao mesmo tempo, mas não pode ter duas políticas de segurança de back-end ou duas políticas de segurança de borda ao mesmo tempo. No entanto, seus serviços de back-end não precisam estar associados às mesmas políticas de segurança. Para anexar e remover políticas de segurança de serviços e recursos de back-end compatíveis, consulte Anexar e remover políticas de segurança.

Se uma política de segurança do 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.

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

• Como opção, você pode usar o protocolo QUIC com balanceadores de carga que usam o Cloud Armor.

• É possível usar políticas de segurança de back-end com o GKE e o controlador de entrada padrão.

• É possível usar uma política de segurança padrão que limita o tráfego acima de um limite especificado pelo usuário ao configurar balanceadores de carga de aplicativo externos regionais.

Além disso, é possível configurar regras WAF pré-configuradas do Google Cloud Armor, que são regras complexas de firewall de aplicativos da Web (WAF) com dezenas de assinaturas compiladas de padrões do setor de código aberto. Cada assinatura corresponde a uma regra de detecção de ataque no conjunto de regras. O Google oferece essas regras como estão. Elas permitem que o Cloud Armor avalie dezenas de assinaturas de tráfego distintas consultando regras com nomes convenientes, em vez de exigir que você defina cada assinatura manualmente. Para mais informações sobre as regras WAF pré-configuradas, consulte a visão geral das regras WAF pré-configuradas.

Tipos de políticas de segurança

As tabelas a seguir mostram os tipos de políticas de segurança no nível do serviço 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íticas de segurança de back-end

As políticas de segurança de back-end têm o valor opcional de sinalização type CLOUD_ARMOR. Se você não definir a flag type, o valor padrão será CLOUD_ARMOR.

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

Com as políticas de segurança de serviço internas, é possível configurar a limitação de taxa de compartilhamento justo com o 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 bucket de back-end, anexe-a a uma política de endpoint do Cloud Service Mesh. Para saber mais sobre políticas de segurança de serviço interno, consulte Configurar a limitação de taxa com o Cloud Armor na documentação do Cloud Service Mesh.

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 ser diferentes. Essas lacunas permitem 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 válida de números de prioridade à qual 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 com um corpo são avaliadas em relação a regras pré-configuradas que usam evaluatePreconfiguredWaf. A exceção é a seguinte:

Para solicitações HTTP POST, o Cloud Armor recebe o cabeçalho da solicitação antes do corpo (payload). Como o 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 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, é 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 Cloud Armor recebe a solicitação HTTP POST com um corpo, 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 com conteúdo potencialmente mal-intencionado seja bloqueado. O Cloud Armor inspeciona até os 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 da solicitação. Para mais informações sobre essa limitação, consulte Limitação de inspeção do corpo de POST e PATCH.

A expressão evaluatePreconfiguredWaf() 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 Cloud Armor processa apenas solicitações POST e PATCH. A inspeção é limitada ao limite configurado, até os primeiros 64 kB (8 kB, 16 kB, 32 kB, 48 kB ou 64 kB) do corpo da solicitação e é decodificada como parâmetros de consulta de URL. O Cloud Armor pode analisar e aplicar regras WAF pré-configuradas para corpos POST formatados em JSON (Content-Type = "application/json"). No entanto, o Cloud Armor não é compatível com outros decodificadores HTTP Content-Type/Content-Encoding, como XML, Gzip ou UTF-16.

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 endereço 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: 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 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: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Regra padrão

Cada política de segurança do 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 Cloud Armor tem 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 Cloud Armor fornece atributos de linguagem de regras personalizadas para escrever condições de correspondência personalizadas.

• A capacidade de combinar até cinco 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 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:

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

• Ao adicionar um endereço IP ou um intervalo de CIDR a uma lista de bloqueio, você impede que um endereço IP de origem ou um intervalo de CIDR acesse os balanceadores de carga compatíveis.

• Ao adicionar um endereço IP ou um intervalo CIDR a uma lista de permissões, você permite 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 negação podem retornar um código de status HTTP 403 Unauthorized, 404 Access Denied ou 502 Bad Gateway.

• Regras de ação excedida podem retornar um código de status HTTP 429 Too Many Requests.

Regras geográficas de origem

É possível permitir ou recusar solicitações originadas de áreas geográficas selecionadas definidas pelo código de país Unicode.

O Cloud Armor usa nosso próprio banco de dados de geolocalização de IPs para identificar o local geográfico da solicitação. O banco de dados é atualizado regularmente. Embora não seja possível garantir uma cadência de atualização específica, durante as operações normais, os mapeamentos que o Cloud Armor usa são atualizados aproximadamente uma vez por semana.

Os mapeamentos atualizados precisam ser propagados para a infraestrutura do Google globalmente. O processo de lançamento acontece gradualmente, geralmente ao longo de vários dias, em várias zonas e regiões em que o Cloud Armor é implantado. Devido a esse processo de lançamento gradual, é possível ver solicitações do mesmo endereço IP de origem sendo processadas de maneira inconsistente durante um lançamento quando o mapeamento de geolocalização do endereço IP de origem muda.

Regras pré-configuradas do WAF

O Cloud Armor fornece uma lista abrangente de regras WAF pré-configuradas com base no conjunto de regras principais do OWASP (CRS) para ajudar você a detectar o seguinte:

• Ataques de injeção de SQL
• Ataques de scripting em vários sites
• Ataques de inclusão de arquivo local
• Ataques de inclusão de arquivo remoto
• Ataques de execução remota de código
• Ataques de aplicação de métodos
• Ataques de detecção de verificação
• Ataques de protocolo
• Ataques de injeção de PHP
• Ataques de fixação de sessão
• Ataques de Java
• Ataques em NodeJS

Para mais detalhes, consulte a visão geral das regras WAF pré-configuradas do Cloud Armor.

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 rede de proxy externo global ou de proxy clássico, as seguintes restrições se aplicam:

• O 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.
• 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.

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. Você vai pagar a taxa normal por solicitação para regras no modo de visualização.

É possível ativar o modo de visualização para uma regra usando a Google Cloud CLI e a sinalização --preview do comando gcloud compute security-policies rules update.

Para desativar o modo de visualização, use a flag --no-preview. Também é possível usar o console Trusted Cloud .

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

Respostas de erro personalizadas

Ao usar um balanceador de carga de aplicativo externo global, é possível configurar respostas de erro personalizadas para códigos de status HTTP de erros gerados por balanceadores de carga ou instâncias de back-end. Além disso, é possível configurar códigos de erro personalizados para o tráfego que o Cloud Armor nega ao configurar páginas de resposta personalizadas para os mesmos códigos de status da série 4xx ou 5xx usados pelas regras da política de segurança atual.

Para mais informações sobre respostas de erro personalizadas, consulte a Visão geral da resposta de erro personalizada. Para ver as etapas de configuração, consulte Configurar respostas de erro personalizadas.

Logging

O Cloud Armor tem uma geração de registros extensiva e permite definir o nível de detalhes da geração de registros. Os registros do Cloud Armor são gerados com base na primeira regra (de maior prioridade) que corresponde a uma solicitação recebida, esteja ou não a política de segurança no modo de visualização. Isso significa que os registros não são gerados para regras que não correspondem nem para regras correspondentes com prioridades mais baixas.

Para informações completas sobre a geração de registros, consulte Como usar a geração de registros de solicitação. Para mais informações sobre o registro detalhado, consulte Registro detalhado. Para ver os registros do Cloud Armor, consulte Como visualizar registros.

Limitações

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

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

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

A inspeção é limitada ao limite configurado, até os primeiros 64 kB (8 kB, 16 kB, 32 kB, 48 kB ou 64 kB) do corpo POST ou PATCH. Para saber mais sobre como configurar o limite de inspeção para o corpo da solicitação ao usar regras WAF pré-configuradas, consulte Atualizar o limite de inspeção para regras WAF pré-configuradas.

O restante do corpo da solicitação pode conter payloads que corresponderiam a uma assinatura de regra do WAF, que seu aplicativo pode aceitar. Para reduzir o risco de corpos de solicitação com tamanho maior que o limite de inspeção configurado, até os primeiros 64 kB (8 kB, 16 kB, 32 kB, 48 kB ou 64 kB), consulte Reduzir o risco em corpos de solicitação que excedem o limite de inspeção configurado.

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

Como as conexões WebSocket são processadas

Os balanceadores de carga de aplicativo externos globais têm suporte integrado para o protocolo WebSocket. Os canais WebSocket são iniciados a partir de solicitações HTTP(S). O 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 Cloud Armor não avalia nenhuma mensagem após a primeira solicitação.

A seguir

• Configurar políticas de segurança do Cloud Armor
• Resolver problemas do Cloud Armor