Esta página descreve como usar as políticas de segurança do Google Cloud Armor para proteger suas implantações do Google Cloud.
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 podem ser configuradas em atributos da camada 3 até a 7. As regras podem filtrar o tráfego com base em condições, como o IP da solicitação recebida endereço IP, intervalo de IP, código de região ou cabeçalhos de solicitação.
As políticas de segurança do Google Cloud Armor estão disponíveis para os seguintes tipos de endpoint e balanceador de carga:
- Balanceador de carga de aplicativo externo global (HTTP/HTTPS)
- Balanceador de carga de aplicativo clássico (HTTP/HTTPS)
- Balanceador de carga de aplicativo externo regional (HTTP/HTTPS)
- Balanceador de carga de aplicativo interno regional (HTTP/HTTPS)
- 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 externa (TCP/UDP)
- Encaminhamento de protocolo
- VMs com endereços IP públicos
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 sobre App Engine, Cloud Run, ou dos serviços de funções do Cloud Run
- 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 multicloud, 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 balanceadores de carga de rede de passagem externos, 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.
Com as políticas de segurança do Google Cloud Armor é possível permitir, negar, limitar taxas ou redirecionar solicitações aos serviços de back-end 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 o local dos balanceadores de carga de aplicativo externos globais, do balanceador de carga clássico do aplicativo, da rede do Google e dos data centers do Google.
Requisitos
Estes são os requisitos das políticas de segurança do Google Cloud Armor:
- O esquema de balanceamento de carga do serviço de back-end precisa ser
EXTERNAL,EXTERNAL_MANAGEDouINTERNAL_MANAGED. - O protocolo do serviço de back-end precisa ser
HTTP,HTTPS,HTTP/2,UDP,TCP,SSLouUNSPECIFIED.
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. Um serviço de back-end só pode ter uma política de segurança associada mas não é preciso associar todos os serviços de back-end ao a 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.
As políticas de segurança do Google Cloud Armor têm os seguintes recursos:
Como opção, você pode usar o protocolo
QUICcom 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 Padrão
É possível usar políticas de segurança 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 um dos seguintes balanceadores de carga:
- Balanceador de carga de aplicativo externo global
- Balanceador de carga de aplicativo clássico
- Balanceador de carga de aplicativo externo regional
- Balanceador de carga de aplicativo interno regional
- Balanceador de carga de rede de proxy externo global
- Balanceador de carga de rede de proxy clássico
- Balanceador de carga de rede de passagem externa
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 Google 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 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 são usadas com serviços de back-end expostos pelos seguintes tipos de balanceador de carga:
- Balanceador de carga de aplicativo externo global
- Balanceador de carga de aplicativo clássico
- Balanceador de carga de aplicativo externo regional
- Balanceador de carga de aplicativo interno regional
- Balanceador de carga de rede de proxy externo global
- Balanceador de carga de rede de proxy clássico
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, híbrida e sem servidor. Nem todos os balanceadores de carga são compatíveis com todos os tipos de NEG. Para mais informações sobre os NEGs compatíveis com o balanceador de carga, consulte a Visão geral dos grupos de endpoints de rede.
Ao usar balanceadores de carga de rede de proxy externos globais ou balanceadores de carga de rede de proxy clássicos,
O Google Cloud Armor aplica a política de segurança
ação da regra deny somente 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.
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 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 são compatíveis com os seguintes endpoints:
- Balanceador de carga de aplicativo externo global
- Balanceador de carga de aplicativo clássico
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 próximo 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.
As políticas de segurança de borda são avaliadas e aplicadas antes do Identity-Aware Proxy (IAP). Uma solicitação bloqueada por uma política de segurança de borda é negada antes que o IAP avalie a identidade do solicitante. Bloquear uma solicitação com uma regra na política de segurança de borda impede que o IAP exiba uma página de login ou tente autenticar o usuário de outra forma.
As políticas de segurança de borda têm o valor de sinalização type CLOUD_ARMOR_EDGE.
Políticas de segurança de borda de rede
As políticas de segurança de borda de rede permitem configurar regras para bloquear o tráfego na borda da rede do Google. A aplicação de políticas de segurança de borda de rede não consome recursos de VM ou host, o que ajuda a evitar que o tráfego de alto volume esgote recursos na carga de trabalho de destino ou cause uma negação de serviço. É possível configurar políticas de segurança de borda de rede para os seguintes recursos:
- Balanceadores de carga de rede de passagem externa
- Encaminhamento de protocolo
- VMs com endereços IP públicos
As políticas de segurança de borda de rede são compatíveis com filtragem com base em alguns dos mesmos parâmetros que as políticas de segurança de back-end e são o único tipo de política compatível com a filtragem de deslocamento de bytes. Consulte a tabela Tipos de políticas de segurança para ver uma lista completa de parâmetros disponíveis.
As políticas de segurança de borda de rede têm o valor de sinalização type CLOUD_ARMOR_NETWORK.
Para configurar políticas de segurança de borda de rede, primeiro você precisa configurar 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 avançada contra DDoS, consulte
Configurar a proteção avançada contra DDoS da rede.
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
(Content-Type = "application/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.
Exemplos
No exemplo a seguir, as regras 1, 2 e 3 são avaliadas nessa ordem para os campos de cabeçalho IP e HTTP. No entanto, se um IP 9.9.9.1 iniciar um ataque XSS no corpo HTTP POST, somente o corpo será bloqueado (por regra 2). o cabeçalho HTTP passa ao back-end (por regra 3).
Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX
No exemplo a seguir, a política permite IP 9.9.9.1 sem verificação contra ataques XSS:
Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX
Regra padrão
Cada política de segurança do Google Cloud Armor contém uma regra padrão que é
correspondida se nenhuma das regras de prioridade mais alta corresponder ou se não
houver outras regras na política. A regra padrão recebe automaticamente a prioridade 2147483647 (INT-MAX) e está sempre presente na política de segurança.
Não é possível excluir a regra padrão, mas você pode modificá-la. A ação padrão
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
política nova, 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.
Capacidade de combinar até 5 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 ISO 3166-1 Alfa 2 e códigos personalizados. À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
USinclui 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 de endereços 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 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 uma resposta HTTP
403(não autorizado),404(acesso negado) ou502(gateway inválido).Regras de ação excedida podem retornar um HTTP
429(muitas solicitações).
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 Google 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 Google 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 Google 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 endereço IP de origem tem uma alteração no mapeamento de geolocalização.
Regras pré-configuradas do WAF
O Google Cloud Armor oferece uma lista abrangente de regras WAF pré-configuradas com base no conjunto de regras principais (CRS) do OWASP ModSecurity para ajudar você a detectar o seguinte:
- Ataques de injeção de SQL
- Ataques de scripting em vários locais
- Ataques de inclusão de arquivos locais
- Ataques de inclusão remota de arquivos
- 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 pré-configuradas do WAF do Google Cloud Armor.
Regras de gerenciamento de bots
Você pode usar regras de gerenciamento de bots para fazer o seguinte:
- Redirecionar solicitações para teste reCAPTCHA com opções e desafios manuais.
- Avalie os tokens reCAPTCHA 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 rede de proxy externos globais ou balanceadores de carga de rede de proxy clássicos, 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
ALLeIPsão compatíveis. - Se você tentar usar o tipo de chave
HTTP-HEADERouHTTP-COOKIEcom balanceadores de carga TCP/SSL, o tipo de chave será interpretado comoALL, eXFF-IPcomoIP.
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 receber a cobrança 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 de
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 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.
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 que balanceadores de carga ou instâncias de back-end gerar. Além disso, é possível configurar códigos de erro personalizados para o tráfego que o Google Cloud Armor nega, configurando páginas de resposta personalizadas para os mesmos códigos de erro da série 4xx ou 5xx usados pelas regras de política de segurança.
Para mais informações sobre respostas de erro personalizadas, consulte a Visão geral da resposta de erro personalizada. Para conferir as etapas de configuração, consulte Configurar respostas de erro personalizadas.
Geração de registros
O Google Cloud Armor tem uma geração de registros extensiva e permite definir quão detalhados da geração de registros. Os registros do Google Cloud Armor são gerados com base (prioridade mais alta) que corresponde a uma solicitação recebida, independentemente de o política de segurança está 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 Usar a geração de registros de solicitação. Para mais informações sobre o registro detalhado, consulte Registro detalhado. Para conferir os registros do Google Cloud Armor, consulte Como visualizar registros.
Geração de registros de solicitações do balanceador de carga de aplicativos externo
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 do balanceador de carga de aplicativo externo.
Geração de registros de solicitações do balanceador de carga de rede de proxy externo
É possível configurar a geração de registros para balanceadores de carga de rede de proxy externo usando os comandos da Google Cloud CLI, conforme listado em Geração de registros e monitoramento de balanceamento de carga de proxy TCP/SSL. Não é possível ativar a geração de registros para balanceadores de carga de rede de proxy externo 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 evaluatePreconfiguredWaf() 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
codificados em URL e JSON formatados como JSON (Content-Type = "application/json").
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 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
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 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. No entanto, as atualizações transações no canal não estiverem em conformidade com o protocolo HTTP, e O Google Cloud Armor não avalia nenhuma mensagem após a primeira solicitação.
A seguir
- Configure políticas, regras e expressões de segurança
- Saiba mais sobre os recursos dos níveis do Cloud Armor Enterprise
- Saiba mais sobre listas de endereços IP nomeados
- Resolver problemas