Visão geral da Proteção Adaptativa do Google Cloud Armor

A Proteção Adaptativa do Google Cloud Armor protege seus aplicativos, sites e serviços no Google Cloud contra ataques distribuídos de negação de serviço (DDoS) na camada 7, como ataques de inundação de HTTP e demais atividades mal-intencionadas de alta frequência na camada 7, no nível do aplicativo. A Proteção Adaptativa cria modelos de machine learning que:

  1. Detectam e geram alertas sobre atividades anômalas
  2. Geram uma assinatura que descreve o possível ataque
  3. Geram uma regra personalizada de WAF do Cloud Armor para bloquear essa assinatura

É possível ativar ou desativar a Proteção Adaptativa para cada política de segurança.

Os alertas sobre tráfego anômalo (ataques em potencial), que incluem as assinaturas dos ataques, aparecem no painel de eventos da Proteção Adaptativa, com os registros de eventos enviados ao Cloud Logging, permitindo análise direta ou o envio para um fluxo de trabalho de monitoramento de registros ou eventos de segurança. Os alertas sobre ataques em potencial também são gerados como indícios no Security Command Center.

Disponibilidade da Proteção Adaptativa

Os alertas detalhados da Proteção Adaptativa estão disponíveis exclusivamente para assinantes do Google Cloud Armor Enterprise. Se não for o caso, você recebe somente um alerta simples. Um alerta simples fornece somente informações essenciais, como a pontuação de confiança da detecção e a magnitude do ataque. Esse alerta simples não inclui a assinatura do ataque nem regras recomendadas para implantação.

Se seus projetos ainda não estão registrados no Cloud Armor Enterprise, acesse Como usar o Cloud Armor Enterprise para informações sobre o processo de inscrição.

Cloud Logging e Cloud Monitoring

Como usar a Proteção Adaptativa de forma eficaz exige entender como funcionam a geração de registros e os alertas no Google Cloud, recomendamos que você se familiarize com o Cloud Logging, a geração de alertas e as políticas de alertas.

Para que o Cloud Armor realize a geração de registros e de relatórios corretamente, é necessário que ele tenha acesso aos registros abaixo. Esses registros precisam estar armazenados no Cloud Logging ou encaminhados para um bucket de geração de registros acessível ao Cloud Armor.

  • networksecurity.googleapis.com/dos_attack
  • networksecurity.googleapis.com/network_dos_attack
  • networksecurity.googleapis.com/network_dos_attack_mitigations

Configurar e ajustar alertas

É possível ativar a Proteção Adaptativa em projetos que já contam com a proteção das políticas de segurança do Cloud Armor para os aplicativos. Ao ativar a Proteção Adaptativa para uma política de segurança específica, ela entra em vigor para todos os serviços de back-end associados a essa política.

Após a ativação da Proteção Adaptativa, há um período de treinamento de, no mínimo, uma hora antes que ela estabeleça um valor de referência confiável e comece a monitorar o tráfego e gerar alertas. Durante o período de treinamento, a Proteção Adaptativa modela o tráfego de entrada e os padrões de uso específicos dos serviços de back-end, para desenvolver o valor de referência correspondente a cada serviço. Após o fim do período de treinamento, a Proteção Adaptativa envia alertas em tempo real ao identificar tráfego anômalo de alta frequência ou grande volume em qualquer serviço de back-end associado à política de segurança.

É possível ajustar os alertas da Proteção Adaptativa com base em diversas métricas. Os alertas, enviados para o Cloud Logging, incluem um nível de confiança, uma assinatura de ataque, uma regra sugerida e uma estimativa da taxa de impacto no valor de referência associada à regra recomendada.

  • O nível de confiança indica o grau de certeza com que os modelos da Proteção Adaptativa preveem que uma alteração detectada no padrão de tráfego é anômala.
  • As taxas de impacto no valor de referência associadas à regra sugerida representam a porcentagem de valor de referência existente para o tráfego, que é capturada pela regra. Duas taxas são fornecidas. A primeira taxa corresponde à porcentagem em relação ao tráfego do serviço de back-end que está sofrendo o ataque. A segunda corresponde à porcentagem em relação a todo o tráfego gerenciado pela política de segurança, incluindo todos os serviços de back-end configurados e não apenas o que está sob ataque.

É possível filtrar os alertas no Cloud Logging com base no nível de confiança, nas taxas de impacto no valor de referência, ou em ambos. Para mais informações sobre como ajustar alertas, confira Como gerenciar políticas de alertas.

O objetivo da Proteção Adaptativa é proteger os serviços de back-end contra ataques DDoS de alto volume na camada 7. Nos casos abaixo, as solicitações não são consideradas pela Proteção Adaptativa:

  • Solicitações veiculadas diretamente pelo Cloud CDN
  • Solicitações rejeitadas por uma política de segurança do Cloud Armor

Modelos granulares

Por padrão, a Proteção Adaptativa detecta um ataque e sugere medidas de mitigação com base no padrão de tráfego direcionado a cada serviço de back-end. Isso significa que um back-end associado a um serviço de back-end pode ficar sobrecarregado, mas a Proteção Adaptativa não intervém, pois, o tráfego relacionado ao ataque não é considerado anômalo para o serviço de back-end.

Com o recurso de modelos granulares, é possível configurar hosts ou caminhos específicos como as unidades granulares que a Proteção Adaptativa analisa. Ao usar modelos granulares, as medidas de mitigação sugeridas pela Proteção Adaptativa filtram o tráfego com base nos hosts ou prefixos de caminhos do URL correspondentes, ajudando a reduzir falsos positivos. Cada um desses hosts ou caminhos é considerado uma unidade granular de tráfego.

As assinaturas de ataque identificadas se direcionam apenas ao tráfego de ataque que atinge a unidade granular de tráfego. No entanto, o filtro é aplicado a todas as solicitações correspondentes à regra em vigor, assim como seria sem o uso de configurações granulares. Por exemplo, se a intenção é que uma regra implantada automaticamente corresponda somente a uma unidade granular de tráfego específica, você pode usar uma condição de correspondência do tipo evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ....

Além de hosts e prefixos de caminhos do URL, é possível configurar limites de alerta considerando algumas ou todas as opções a seguir. Você pode aplicar esses limites às unidades granulares de tráfego ou ao serviço de back-end como um todo, com exceção do limite de carga, que só pode ser aplicado ao serviço de back-end:

  • Carga: a carga máxima suportada pelo serviço de back-end, segundo a configuração do balanceador de carga de aplicativo. Essa opção não está disponível para unidades granulares de tráfego e também não pode ser usada em back-ends sem servidores, como Cloud Run, Cloud Run functions ou back-ends de origem externa.
  • Consultas por segundo (QPS) absolutas: a quantidade máxima de tráfego, em consultas por segundo, que o serviço de back-end ou a unidade de tráfego recebe.
  • Comparação com o valor de referência de QPS: um múltiplo do volume médio de tráfego com base no valor de referência a longo prazo. Por exemplo, um valor 2 representa um valor de QPS equivalente ao dobro do volume de tráfego de referência.

Para mais informações sobre como configurar modelos granulares, confira Configurar a Proteção Adaptativa do Google Cloud Armor.

Consumir e interpretar alertas

Assim que a Proteção Adaptativa detecta um ataque suspeito, ela gera um evento no painel de eventos correspondente e cria um item de registro no Cloud Logging. O alerta está no payload JSON do item de registro. Esse item de registro é gerado no recurso Política de segurança de rede no Cloud Logging. A mensagem de registro identifica o serviço de back-end sob ataque e inclui uma pontuação de confiança que indica o grau de certeza da Proteção Adaptativa sobre a anomalia identificada na alteração do padrão de tráfego. A mensagem de registro também inclui uma assinatura de ataque que ilustra as características do tráfego de ataque, junto com regras sugeridas do Cloud Armor que você pode aplicar para mitigar o ataque.

Entender as assinaturas de ataque

Um alerta da Proteção Adaptativa inclui uma assinatura de ataque, que é uma descrição dos atributos de tráfego do ataque em potencial. Você usa a assinatura para identificar e, eventualmente, bloquear o ataque. A assinatura aparece de duas formas: como uma tabela legível para o usuário e como uma regra de WAF do Cloud Armor estabelecida previamente, que pode ser implantada na política de segurança relevante. Se você não for assinante do Cloud Armor Enterprise, a assinatura de ataque não está incluída no alerta simples.

A assinatura consiste em um conjunto de atributos, como endereço IP de origem, regiões geográficas, cookies, user agents, referenciadores e outros cabeçalhos das solicitações HTTP, além do conjunto de valores desses atributos, como se estivessem associados com o tráfego de ataque em potencial. O conjunto de atributos não pode ser configurado pelo usuário. Os valores dos atributos dependem dos valores presentes no tráfego de entrada para o seu serviço de back-end.

Para cada valor do atributo que a Proteção Adaptativa considera indicativo de um ataque em potencial, ela lista o seguinte:

  • A probabilidade de ataque
  • A proporção do atributo no ataque, ou seja, a porcentagem do tráfego de ataque em potencial que tinha esse valor no momento em que o ataque foi detectado
  • A proporção do atributo no valor de referência, ou seja, a porcentagem do tráfego de referência que tinha esse valor do atributo no momento em que o ataque foi detectado

A especificação de entradas do Cloud Logging contém detalhes sobre as informações de cada alerta.

A seguir, apresentamos um exemplo de tabela legível para o usuário que contém a assinatura de um possível ataque:

Nome do atributo Valor Tipo de correspondência Probabilidade do ataque Proporção no ataque Proporção no valor de referência
UserAgent “foo” Correspondência exata 0,7 0,85 0,12
UserAgent “bar” Correspondência exata 0,6 0,7 0,4
IP de origem “a.b.c.d” Correspondência exata 0,95 0,1 0,01
IP de origem a.b.c.e Correspondência exata 0,95 0,1 0,01
IP de origem a.b.c.f Correspondência exata 0,05 0,1 0,1
RegionCode Reino Unido Correspondência exata 0,64 0,3 0,1
RegionCode Índia Correspondência exata 0,25 0,2 0,3
RequestUri /urlpart Substring 0,7 0,85 0,12

Um alerta da Proteção Adaptativa e o registro de evento relevante no Cloud Logging contêm o seguinte:

  • Um ID de alerta único, ou alertID, que é usado para se referir a um alerta específico ao registrar feedback do usuário (mais detalhes abaixo)
  • O serviço de back-end sob ataque, ou backendService
  • A pontuação de confiança, ou confidence, que é um número variável de 0 a 1 para indicar o grau de certeza do sistema da Proteção Adaptativa de que o evento detectado é um ataque mal-intencionado

Você também recebe um conjunto de assinaturas e regras que caracterizam o ataque detectado. O conjunto fornece uma lista de headerSignatures, cada uma relacionada a um cabeçalho HTTP e contendo os significantValues correspondentes. Cada valor significativo corresponde a um valor observado no cabeçalho ou em uma substring dele.

A seguir, apresentamos um exemplo de assinatura:

...
headerSignatures: [
  0: {
   name: "Referer"
   significantValues: [
    0: {
     attackLikelihood: 0.95
     matchType: "MATCH_TYPE_EQUALS"
     proportionInAttack: 0.6
     proportionInBaseline: 0.01
     value: "foo.attacker.com"
    }
   ]
  }
...

O alerta sugere que o valor foo.attacker.com no cabeçalho Referer é importante para caracterizar o ataque. Mais especificamente, 60% do tráfego relacionado ao ataque (proportionInAttack) tem esse valor de Referer, enquanto apenas 1% do tráfego de referência (proportionInBaseline) apresenta o mesmo valor para Referer. Além disso, entre todo o tráfego que contém esse valor de Referer, 95% corresponde ao tráfego de ataque (attackLikelihood).

Esses valores sugerem que, se você bloqueasse todas as solicitações com foo.attacker.com no campo de cabeçalho Referer, também iria bloquear com sucesso 60% do ataque e 1% do tráfego de referência.

A propriedade matchType especifica a relação entre o atributo no tráfego de ataque e o valor significativo. Os valores possíveis são MATCH_TYPE_CONTAINS ou MATCH_TYPE_EQUALS.

A assinatura a seguir corresponde ao tráfego que contém uma substring /api? no URI de solicitação:

...
headerSignatures: [
  0: {
   name: "RequestUri"
   significantValues: [
    0: {
     attackLikelihood: 0.95
     matchType: "MATCH_TYPE_CONTAINS"
     proportionInAttack: 0.9
     proportionInBaseline: 0.01
     value: "/api?"
    }
   ]
  }
...

Implantar regras sugeridas

Os alertas da Proteção Adaptativa também fornecem uma regra sugerida do Cloud Armor expressa na linguagem das regras personalizadas. Essa regra pode ser usada para criar uma regra em uma política de segurança do Cloud Armor para mitigar o ataque. Além da assinatura, o alerta inclui uma taxa de impacto no valor de referência do tráfego para ajudar você a avaliar o impacto da implantação da regra. A taxa de impacto no valor de referência do tráfego é uma proporção projetada do tráfego de referência que corresponde à assinatura de ataque identificada pela Proteção Adaptativa. Se você não for assinante do Cloud Armor Enterprise, os alertas simples enviados pela Proteção Adaptativa não vão incluir uma regra sugerida do Cloud Armor para aplicação.

É possível encontrar parte da assinatura de alerta e a taxa de impacto no valor de referência na mensagem de registro enviada para o Cloud Logging. O exemplo a seguir mostra o payload JSON de um alerta de amostra, com os rótulos de recurso que podem ser usados para filtrar os registros.

...
 jsonPayload: {
   alertId: "11275630857957031521"
   backendService: "test-service"
   confidence: 0.71828485
   headerSignatures: [

    0: {
     name: "RequestUri"
     significantValues: [
      0: {
       attackLikelihood: 0.88
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.85
       proportionInBaseline: 0.01
       value: "/"
      }
     ]
    }
    1: {
     name: "RegionCode"
     significantValues: [
      0: {
       attackLikelihood: 0.08
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.17
       proportionInBaseline: 0.28
       value: "US"
      }
      1: {
       attackLikelihood: 0.68
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.09
       proportionInBaseline: 0.01
       value: "DE"
      }
      2: {
       attackLikelihood: 0.74
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.05
       proportionInBaseline: 0
       value: "MD"
      }
     ]
    }
     2: {
     name: "UserAgent"
     significantValues: [
      0: {
       attackLikelihood: 0.92
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.85
       proportionInBaseline: 0
       value: "Unusual browser"
      }
      1: {
       attackLikelihood: 0.87
       proportionInAttack: 0.7
       proportionInBaseline: 0.1
       missing: true
      }
     ]
    }
   ]
   suggestedRule: [
    0: {
     action: "DENY"
     evaluation: {
       impactedAttackProportion: 0.95
       impactedBaselineProportion: 0.001
       impactedBaselinePolicyProportion: 0.001
     }
     expression: "evaluateAdaptiveProtection('11275630857957031521')"
    }
   ]
   ruleStatus: RULE_GENERATED
   attackSize: 5000
 }
 resource: {
    type: "network_security_policy",
    labels: {
      project_id: "your-project",
      policy_name: "your-security-policy-name"
    }
 },
}
}
...

Você pode implantar as regras sugeridas copiando a expressão CEL da assinatura da regra e colando-a na condição de correspondência de uma regra recém-criada, ou clicando no botão Aplicar no painel de Proteção Adaptativa da interface do Cloud Armor.

Para implantar a regra, crie uma nova regra na política de segurança do Cloud Armor para proteger os serviços de back-end identificados pelo alerta. Na sequência, durante a configuração da regra, copie e cole a expressão CEL do alerta para o campo Condição de correspondência e ajuste a ação da regra para deny. Conforme o exemplo acima, copie a expressão evaluateAdaptiveProtection('11275630857957031521') que está na seção suggestedRule do alerta.

Recomendamos que a implantação inicial da regra seja no modo de visualização para que seja possível avaliar o impacto dela no tráfego de produção. Ao realizar esse procedimento, o Cloud Armor mantém um registro da ação e do tráfego relacionado sempre que a regra é acionada, sem que nenhuma ação seja aplicada ao tráfego correspondente.

Além disso, se sua política de segurança estiver anexada a diversos serviços de back-end, verifique se os efeitos da nova regra não causam impactos indesejados em algum desses serviços. Se isso ocorrer, configure novas políticas de segurança para mitigar os efeitos indesejados e as associe aos serviços de back-end apropriados.

Recomendamos que você configure a nova regra com prioridade superior às regras que tenham a ação definida como “allow”. O motivo é que, para atingir o impacto previsto e garantir o máximo efeito na mitigação do ataque, a regra deve estar na posição de prioridade lógica mais elevada, de modo que todo tráfego correspondente seja bloqueado por ela. As regras em uma política de segurança do Cloud Armor são avaliadas por ordem de prioridade, com a avaliação sendo interrompida assim que a primeira regra correspondente é acionada e a ação associada à regra é aplicada. Se você precisar conceder uma exceção para algum tráfego ou clientes específicos em relação a esta regra, é possível criar uma regra “allow” com prioridade mais elevada, ou seja, com um valor numérico menor. Para mais informações sobre a prioridade de regras, confira Ordem de avaliação das regrar.

Implantar automaticamente as regras sugeridas

Você também pode configurar a Proteção Adaptativa para implantar automaticamente as regras sugeridas. Para ativar a implantação automática de regras, crie uma regra de marcador de posição com a prioridade e a ação escolhidas, inserindo a expressão evaluateAdaptiveProtectionAutoDeploy() no campo de condição de correspondência. Essa regra é considerada true para solicitações em que a Proteção Adaptativa identifica tráfego de ataque, e o Cloud Armor aplica a ação correspondente à solicitação de ataque. Todos os tipos de ação do Cloud Armor, como allow, deny, throttle e redirect, são compatíveis. Além disso, você pode usar o modo de visualização para registrar que a regra foi acionada, sem executar a ação configurada.

Se você usar um proxy que atua na etapa anterior da conexão, como uma CDN de terceiros, antes do balanceador de carga de aplicativo externo, recomendamos configurar o campo userIpRequestHeaders para adicionar o endereço IP do seu provedor (ou intervalos de endereços IP) a uma lista de permissões. Isso impede que a Proteção Adaptativa classifique equivocadamente o endereço IP de origem do proxy como parte de um ataque. Em vez disso, ela verifica o campo configurado pelo usuário para o endereço IP de origem do tráfego antes de chegar ao proxy.

Para mais informações sobre como configurar a implantação automática de regras, confira Implantar automaticamente as regras sugeridas pela Proteção Adaptativa.

Status da regra

Se, ao tentar implantar uma regra sugerida, nenhuma regra for exibida, é possível verificar o campo ruleStatus para descobrir o motivo do problema.

O valor do campo attackSize está em consultas por segundo (QPS).

 ]
ruleStatus: RULE_GENERATED
attackSize: 5000
}

A tabela a seguir descreve os valores possíveis para o campo e seus respectivos significados.

Status da regra Descrição
RULE_GENERATED Uma regra válida foi gerada com sucesso.
BASELINE_TOO_RECENT Não houve tempo suficiente para coletar tráfego de referência confiável. Pode ser necessário aguardar até uma hora para que as regras sejam geradas.
NO_SIGNIFICANT_VALUE_DETECTED Nenhum cabeçalho apresentou valores significativos associados ao tráfego de ataque, por isso não foi possível gerar uma regra.
NO_USABLE_RULE_FOUND Não foi possível criar uma regra válida.
ERROR Ocorreu um erro não especificado ao criar a regra.

Como monitorar, enviar feedback e reportar erros sobre eventos

Para visualizar ou interagir com o painel da Proteção Adaptativa, você precisa das permissões listadas a seguir.

  • compute.securityPolicies.list
  • compute.backendServices.list
  • logging.logEntries.list

Após ativar a Proteção Adaptativa em qualquer política de segurança do Google Cloud Armor, a página abaixo estará disponível no painel Segurança da rede > Google Cloud Armor. O painel apresenta o volume de tráfego ao longo do tempo para a política de segurança e o serviço de back-end selecionados, de acordo com o intervalo de tempo definido. Qualquer ocorrência de ataque potencial detectada pela Proteção Adaptativa é anotada no gráfico e listada abaixo dele. Ao clicar em um evento de ataque específico, uma janela lateral é exibida mostrando a assinatura do ataque e a regra sugerida em formato de tabela. Esta informação é idêntica à das entradas de registros do Cloud Logging, conforme detalhado na especificação de entradas do Cloud Logging. Para adicionar a regra sugerida à política de segurança atual, clique em Aplicar.

Painel da Proteção Adaptativa
Painel da Proteção Adaptativa (clique para ampliar)
Detalhes do alerta da Proteção Adaptativa
Painel da Proteção Adaptativa (clique para ampliar)

Nem todo indício da Proteção Adaptativa é interpretado como um ataque, já que isso depende do contexto específico e das condições do ambiente do serviço de back-end protegido. Se for determinado que o possível ataque descrito no alerta corresponde a um comportamento normal ou aceitável, você pode relatar um erro de evento para aprimorar o treinamento dos modelos da Proteção Adaptativa. Ao lado de cada evento de ataque listado abaixo do gráfico, há um botão que abre uma janela interativa, permitindo o relato de um erro de evento acompanhado de informações contextuais opcionais. O relato de um erro de evento auxilia na redução da ocorrência de erros semelhantes em ocasiões futuras. Ao longo do tempo, essa prática contribui para aprimorar a acurácia da Proteção Adaptativa.

Monitorar, gerar alertas e realizar geração de registros

Os dados de telemetria da Proteção Adaptativa são enviados para o Cloud Logging e também para o Security Command Center. A mensagem de registro da Proteção Adaptativa, que é enviada ao Cloud Logging, está descrita nas seções anteriores deste documento. Uma entrada de registro é gerada sempre que a Proteção Adaptativa detecta um possível ataque, contendo uma pontuação de confiança que descreve o grau de confiança dos modelos de que o tráfego observado apresenta comportamento anômalo. Para ajustar a geração de alertas, uma política de alertas pode ser configurada no Cloud Logging para acionar um alerta apenas quando uma mensagem de registro da Proteção Adaptativa apresentar uma pontuação de confiança acima do limite especificado pelo usuário. Recomendamos iniciar com um limite baixo, em que a pontuação de confiança seja maior que 0,5, para não deixar passar avisos de possíveis ataques. O limite de confiança na política de alertas pode ser aumentado ao longo do tempo se os alertas apresentarem uma taxa de impacto no valor de referência considerada inaceitável.

O painel do Security Command Center também contém indícios da Proteção Adaptativa. Eles estão localizados no card do Cloud Armor na categoria Ataques DDoS de aplicativos. Cada indício contém os detalhes do serviço, o grau de confiança referente ao ataque, a assinatura a ele associada e um link que direciona ao alerta específico no painel da Proteção Adaptativa. A captura de tela a seguir é um exemplo de um indício de tentativa de ataque DDoS em um aplicativo:

Indício de ataque DDoS em um aplicativo.
Indício de ataque DDoS em um aplicativo (clique para ampliar).

Especificação da entrada do Cloud Logging

O alerta da Proteção Adaptativa enviado ao Cloud Logging consiste em uma entrada de registro que contém os seguintes elementos:

  • Confiança do alerta: grau de confiança da Proteção Adaptativa de que o evento detectado corresponde a um ataque.
  • Implantação automática: valor booleano que indica se uma defesa automática foi acionada.
  • Assinatura do ataque
    • Nome do atributo: designação do atributo que corresponde ao Value apresentado a seguir, podendo representar, por exemplo, o nome de um cabeçalho da solicitação específico ou a origem geográfica.
    • Valor: representa o valor que corresponde ao atributo identificado no tráfego mal-intencionado.
    • Tipo de correspondência: a relação entre o Value e o atributo presente no tráfego de ataque. Esse valor pode ser idêntico ao atributo do tráfego de ataque ou representar uma substring dele.
    • Probabilidade de ataque: a probabilidade de que uma determinada solicitação seja mal-intencionada, considerando que o atributo relevante dessa solicitação corresponde ao Value especificado.
    • Proporção no ataque: a porcentagem do tráfego de ataque potencial que corresponde ao Value especificado.
    • Proporção no valor de referência: a porcentagem do tráfego normal, usado como referência, que corresponde ao Value especificado.
  • Regra sugerida
    • Condição de correspondência: a expressão a ser usada na condição de correspondência das regras para identificar tráfego mal-intencionado.
    • Taxa de impacto no valor de referência: representa a porcentagem prevista do tráfego legítimo ao serviço de back-end em ataque que seria capturada pela regra sugerida.
    • Taxa de impacto no valor de referência na política: representa a porcentagem prevista do tráfego legítimo para todos os serviços de back-end na mesma política de segurança que seria capturada pela regra sugerida.
    • Taxa de ataque impactada: representa a porcentagem prevista do tráfego de ataque que seria capturada pela regra sugerida.
  • Status da regra: detalhes adicionais sobre a geração de regras.

Visão geral de machine learning e privacidade

  • Dados de treinamento e de detecção
    • A Proteção Adaptativa cria vários modelos para detectar possíveis ataques e identificar as respectivas assinaturas. Os sinais usados por esses modelos para determinar se um ataque está em andamento são derivados dos metadados observados no tráfego de solicitações provenientes de seus projetos. Os metadados incluem: endereço IP de origem, localização geográfica de origem e os valores de alguns cabeçalhos das solicitações HTTP.
    • Os atributos reais usados pelos modelos são propriedades estatísticas derivadas dos sinais mencionados acima. Portanto, os dados de treinamento dos modelos não incluem os valores reais de nenhum metadado, como endereços IP e/ou valores de cabeçalhos das solicitações.
    • Um conjunto comum de modelos de detecção, treinados apenas com dados artificiais, é compartilhado entre todos os clientes para determinar se um ataque está ocorrendo, quando a Proteção Adaptativa é ativada pela primeira vez. Após você reportar um evento de ataque falso e os modelos serem atualizados com sinais de tráfego específicos dos seus projetos, esses modelos se tornam locais aos seus projetos e deixam de ser usados por outros clientes.
  • Dados de geração da assinatura
    • Depois que a Proteção Adaptativa determina que um ataque potencial está em andamento, ela gera uma assinatura de ataque eficaz para ajudar o alvo a mitigar rapidamente o ataque. Para isso, uma vez que a Proteção Adaptativa seja ativada em uma política de segurança, métricas de tráfego e metadados das solicitações a um serviço de back-end associado à política de segurança são continuamente registrados para o aprendizado das características dos valores de referência do tráfego.
    • Como a Proteção Adaptativa precisa adquirir conhecimento sobre os valores de referência do tráfego, o processo de geração de regras para mitigar ataques potenciais pode levar até uma hora.

A seguir