Panoramica di Google Cloud Armor Adaptive Protection

Google Cloud Armor Adaptive Protection ti aiuta a proteggere le tue applicazioni Google Cloud , i tuoi siti web e i tuoi servizi dagli attacchi DDoS (distributed denial-of-service) L7, come gli attacchi HTTP flood e altre attività dannose di livello 7 (a livello di applicazione) ad alta frequenza. Adaptive Protection crea dei modelli di machine learning che svolgono le seguenti operazioni:

  1. Rilevare e inviare avvisi in caso di attività anomale
  2. Generare una firma che descriva il potenziale attacco
  3. Generare una regola WAF di Cloud Armor personalizzata per bloccare la firma

Puoi abilitare o disabilitare Adaptive Protection in base alla singola policy di sicurezza.

Gli avvisi relativi al traffico anomalo (potenziali attacchi), che includono le firme degli attacchi, vengono visualizzati nella dashboard degli eventi di Adaptive Protection con i log eventi inviati a Cloud Logging, dove possono essere analizzati direttamente o inoltrati a un workflow di monitoraggio dei log downstream o degli eventi di sicurezza. Gli avvisi sui potenziali attacchi vengono generati anche come risultati in Security Command Center.

Disponibilità di Adaptive Protection

Gli avvisi completi di Adaptive Protection sono disponibili solo se ti abboni a Google Cloud Armor Enterprise. In caso contrario, riceverai solo un avviso di base. Un avviso di base contiene solo informazioni minime, come un punteggio di confidenza del rilevamento e le dimensioni dell'attacco. Un avviso di base non include alcuna firma dell'attacco o suggerimenti per gli utenti sulle regole di cui eseguire il deployment.

Se i tuoi progetti non sono ancora registrati in Cloud Armor Enterprise, consulta Utilizzo di Cloud Armor Enterprise per sapere come registrarti.

Cloud Logging e Cloud Monitoring

Per utilizzare in modo efficace Adaptive Protection è necessario comprendere il funzionamento di logging e avvisi in Google Cloud, dunque ti consigliamo di acquisire familiarità con Cloud Logging, gli avvisi e le policy di avviso.

Per garantire logging e segnalazioni corretti, Cloud Armor richiede l'accesso ai seguenti log. Questi devono essere archiviati in Cloud Logging o indirizzati a un bucket di log a cui Cloud Armor può accedere.

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

Configura e ottimizza gli avvisi

Puoi abilitare Adaptive Protection nei progetti in cui le policy di sicurezza di Cloud Armor proteggono già le tue applicazioni. Quando abiliti Adaptive Protection per una determinata policy di sicurezza, Adaptive Protection viene attivato per tutti i servizi di backend a cui è associata la policy di sicurezza.

Dopo l'attivazione, è previsto un periodo di addestramento di almeno un'ora prima che Adaptive Protection sviluppi una base di riferimento affidabile e inizi a monitorare il traffico e a generare avvisi. Durante il periodo di addestramento, Adaptive Protection modella il traffico in entrata e i pattern di utilizzo specifici per ogni servizio di backend, in modo da sviluppare la base di riferimento per ciascun servizio di backend. Al termine del periodo di addestramento, riceverai avvisi in tempo reale quando Adaptive Protection identifica anomalie ad alta frequenza o volume elevato nel traffico indirizzato a uno dei servizi di backend associati a questa policy di sicurezza.

Puoi ottimizzare gli avvisi di Adaptive Protection in base a diverse metriche. Gli avvisi, inviati a Cloud Logging, includono un livello di confidenza, una firma dell'attacco, una regola suggerita e un tasso di impatto sulla base di riferimento stimato associato alla regola suggerita.

  • Il livello di confidenza indica l'affidabilità con cui i modelli di Adaptive Protection prevedono che la variazione osservata nel modello di traffico sia anomala.
  • I tassi di impatto sulla base di riferimento associati alla regola suggerita rappresentano la percentuale di traffico della base di riferimento esistente intercettato dalla regola. Vengono forniti due tassi: il primo è la percentuale relativa al traffico in entrata del servizio di backend specifico sotto attacco, il secondo è la percentuale rispetto a tutto il traffico che passa attraverso la policy di sicurezza, inclusi tutti i target del servizio di backend configurati (non solo quello attaccato).

Puoi filtrare gli avvisi in Cloud Logging in base al livello di confidenza, ai tassi di impatto sulla base di riferimento o a entrambi. Per saperne di più sull'ottimizzazione degli avvisi, consulta Gestione delle policy di avviso.

Adaptive Protection mira a proteggere i servizi di backend dagli attacchi DDoS di livello 7 con volume elevato. Nei seguenti scenari, le richieste non vengono conteggiate in Adaptive Protection:

  • Richieste gestite direttamente da Cloud CDN
  • Richieste rifiutate da una policy di sicurezza Cloud Armor

Modelli granulari

Per impostazione predefinita, Adaptive Protection rileva un attacco e suggerisce mitigazioni in base al traffico tipico indirizzato a ogni servizio di backend. Ciò significa che un backend dietro un servizio di backend può sovraccaricarsi, ma Adaptive Protection non interviene perché il traffico di attacco non è anomalo per il servizio di backend.

La funzionalità dei modelli granulari consente di configurare host o percorsi specifici come unità granulari analizzate da Adaptive Protection. Quando utilizzi i modelli granulari, le mitigazioni suggerite da Adaptive Protection filtrano il traffico in base ai prefissi di host o percorsi URL corrispondenti, contribuendo a ridurre i falsi positivi. Ognuno di questi host o percorsi è chiamato unità di traffico granulare.

Le firme di attacco identificate hanno come obiettivo solo il traffico di attacco in entrata nell'unità di traffico granulare; tuttavia, il filtro viene comunque applicato a tutte le richieste corrispondenti alla regola implementata, come avverrebbe senza le configurazioni granulari. Ad esempio, se vuoi che una regola con deployment automatico corrisponda solo a un'unità granulare di traffico specifica, valuta la possibilità di utilizzare una condizione di corrispondenza come evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ....

Oltre ai prefissi di host e percorsi URL, puoi configurare le soglie di avviso in base ad alcune o a tutte le seguenti opzioni. Puoi applicare queste soglie alle unità di traffico granulari o al servizio di backend nel suo complesso, ad eccezione della soglia di carico, che può essere applicata solo al servizio di backend:

  • Carico: il carico massimo per il servizio di backend, in base al bilanciatore del carico delle applicazioni configurato. Questa opzione non è disponibile per le unità di traffico granulari e per i backend serverless come Cloud Run, Cloud Run Functions o i backend con origine esterna.
  • Query al secondo (QPS) assolute: la quantità di traffico di picco, in query al secondo, ricevuta dal servizio di backend o dall'unità di traffico.
  • Rispetto alle QPS di riferimento: un multiplo del volume di traffico di riferimento medio a lungo termine. Ad esempio, un valore pari a 2 rappresenta un QPS doppio rispetto al volume di traffico della base di riferimento.

Per ulteriori informazioni sulla configurazione dei modelli granulari, consulta Configura Google Cloud Armor Adaptive Protection.

Utilizza e interpreta gli avvisi

Non appena Adaptive Protection rileva un attacco sospetto, genera un evento nella dashboard degli eventi di Adaptive Protection e una voce di log in Cloud Logging. L'avviso si trova nel payload JSON della voce di log. La voce di log viene generata nella risorsa Policy di sicurezza delle reti in Cloud Logging. Il messaggio di log identifica il servizio di backend sotto attacco e include un punteggio di confidenza che indica la sicurezza con cui Adaptive Protection considera anomala la variazione del pattern di traffico identificata. Il messaggio di log include anche una firma dell'attacco che illustra le caratteristiche del traffico dell'attacco, insieme alle regole Cloud Armor suggerite che puoi applicare per mitigare l'attacco.

Comprendi le firme degli attacchi

Un avviso di Adaptive Protection include una firma dell'attacco, ovvero una descrizione degli attributi di traffico del potenziale attacco. Utilizzi la firma per identificare e potenzialmente bloccare l'attacco. La firma assume due forme: una tabella leggibile dall'utente e una regola WAF di Cloud Armor predefinita che puoi implementare nella policy di sicurezza pertinente. Se non hai un abbonamento a Cloud Armor Enterprise, la firma dell'attacco non è inclusa nell'avviso di base.

La firma è costituita da un insieme di attributi, come indirizzo IP di origine, regioni geografiche, cookie, user agent, referer e altre intestazioni delle richieste HTTP, nonché dall'insieme di valori di questi attributi ritenuti associati al potenziale traffico di attacco. Il set di attributi non è configurabile dall'utente. I valori degli attributi dipendono dai valori del traffico in entrata nel tuo servizio di backend.

Per ogni valore dell'attributo che Adaptive Protection ritiene indichi il potenziale attacco, Adaptive Protection elenca quanto segue:

  • Probabilità di attacco
  • La proporzione dell'attributo nell'attacco, ovvero la percentuale di traffico di attacco potenziale che aveva questo valore al momento del rilevamento dell'attacco
  • La proporzione dell'attributo nella base di riferimento, ovvero la percentuale di traffico della base di riferimento che possedeva questo valore dell'attributo al momento del rilevamento dell'attacco

Specifiche della voce di Cloud Logging contiene dettagli sulle informazioni in ogni avviso.

Di seguito è riportato un esempio di tabella leggibile dall'utente che contiene la firma di un potenziale attacco:

Nome attributo Valore Tipo di corrispondenza Probabilità di attacco Proporzione nell'attacco Proporzione nella base di riferimento
UserAgent "foo" Corrispondenza esatta 0,7 0,85 0,12
UserAgent "bar" Corrispondenza esatta 0,6 0,7 0,4
IP di origine "a.b.c.d" Corrispondenza esatta 0,95 0,1 0,01
IP di origine a.b.c.e Corrispondenza esatta 0,95 0,1 0,01
IP di origine a.b.c.f Corrispondenza esatta 0,05 0,1 0,1
RegionCode UK Corrispondenza esatta 0,64 0,3 0,1
RegionCode IN Corrispondenza esatta 0,25 0,2 0,3
RequestUri /urlpart Sottostringa 0,7 0,85 0,12

Un avviso di Adaptive Protection e il relativo log eventi di Cloud Logging contengono quanto segue:

  • Un ID avviso univoco o alertID, utilizzato per fare riferimento a un avviso specifico quando segnala il feedback dell'utente (maggiori dettagli di seguito)
  • Il servizio di backend sotto attacco, o backendService
  • Il punteggio di confidenza, o confidence, che è un numero compreso tra 0 e 1 che indica la sicurezza con cui il sistema Adaptive Protection considera l'evento rilevato come attacco dannoso

Ricevi inoltre un insieme di firme e regole che caratterizzano l'attacco rilevato. Nello specifico, il set fornisce un elenco di headerSignatures, ognuna corrispondente a un'intestazione HTTP e contenente un elenco di significantValues per l'intestazione specifica. Ogni valore significativo è un valore di intestazione osservato o una sua sottostringa.

Di seguito è riportata una firma di esempio:

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

L'avviso suggerisce che il valore foo.attacker.com nell'intestazione Referer è importante per caratterizzare l'attacco. Più nello specifico, il 60% del traffico di attacco (proportionInAttack) presenta il valore Referer e solo l'1% del traffico di riferimento in tutto il traffico (proportionInBaseline) presenta lo stesso valore Referer. Inoltre, per tutto il traffico corrispondente a questo valore Referer, il 95% è traffico di attacco (attackLikelihood).

Questi valori suggeriscono che se blocchi tutte le richieste con foo.attacker.com nel campo dell'intestazione Referer, bloccherai correttamente il 60% dell'attacco e anche l'1% del traffico della base di riferimento.

La proprietà matchType specifica la relazione tra l'attributo nel traffico di attacco e il valore significativo. Può essere MATCH_TYPE_CONTAINS o MATCH_TYPE_EQUALS.

La firma successiva corrisponde al traffico con una sottostringa /api? nell'URI della richiesta:

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

Esegui il deployment delle regole suggerite

Gli avvisi di Adaptive Protection forniscono anche una regola Cloud Armor suggerita espressa nel linguaggio di regole personalizzate. Questa regola può essere utilizzata per creare una regola in una policy di sicurezza di Cloud Armor per mitigare l'attacco. Oltre alla firma, l'avviso include un tasso di impatto sulla base di riferimento per aiutarti a valutare l'impatto dell'implementazione della regola. Il tasso di impatto sulla base di riferimento è una proporzione stimata del traffico della base di riferimento che corrisponde alla firma dell'attacco identificata da Adaptive Protection. Se non hai un abbonamento a Cloud Armor Enterprise, gli avvisi di base inviati da Adaptive Protection non includono una regola Cloud Armor suggerita da applicare.

Puoi trovare parte della firma dell'avviso e il tasso di impatto sulla base di riferimento nel messaggio di log inviato a Cloud Logging. Il seguente esempio mostra il payload JSON di un avviso di esempio insieme alle etichette delle risorse in base a cui puoi filtrare i log.

...
 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"
    }
 },
}
}
...

Puoi implementare le regole suggerite copiando l'espressione CEL dalla firma della regola e incollandola nella condizione di corrispondenza di una regola appena creata oppure facendo clic sul pulsante Applica nella dashboard di Adaptive Protection nell'interfaccia utente di Cloud Armor.

Per eseguire il deployment della regola, crea una nuova regola nella policy di sicurezza di Cloud Armor che protegge i servizi di backend target identificati dall'avviso. Successivamente, durante la configurazione della regola, copia e incolla l'espressione CEL dall'avviso nel campo Condizione di corrispondenza della regola e imposta l'azione della regola su deny. Nell'esempio precedente, copia l'espressione evaluateAdaptiveProtection('11275630857957031521') dalla sezione suggestedRule dell'avviso.

Ti consigliamo vivamente di eseguire il deployment della regola prima in modalità di anteprima in modo da poter valutare l'impatto della regola sul traffico di produzione. In questo modo, Cloud Armor registra l'azione e il traffico associato ogni volta che la regola viene attivata, ma non viene intrapresa alcuna azione sul traffico corrispondente.

Inoltre, se la tua policy di sicurezza è collegata a più servizi di backend, puoi verificare se gli effetti della nuova regola hanno effetti indesiderati in uno dei servizi di backend. In questo caso, configura nuove policy di sicurezza per mitigare gli effetti indesiderati e collegale ai servizi di backend corretti.

Ti consigliamo di impostare la priorità della nuova regola su un valore superiore a quello di qualsiasi regola con azione consentita. Questo perché, per avere l'impatto previsto e massimizzare l'effetto di mitigazione dell'attacco, la regola deve essere implementata nella posizione con la priorità logica più alta per garantire che tutto il traffico corrispondente venga bloccato dalla regola. Le regole di una policy di sicurezza di Cloud Armor vengono valutate in ordine di priorità e la valutazione termina dopo l'attivazione della prima regola corrispondente e l'esecuzione dell'azione della regola associata. Se devi stabilire un'eccezione per alcuni tipi di traffico o client specifici per questa regola, puoi creare una regola "allow" con priorità più elevata, ovvero con un valore numerico inferiore. Per saperne di più sulla priorità delle regole, consulta Ordine di valutazione delle regole.

Esegui automaticamente il deployment delle regole suggerite

Puoi anche configurare Adaptive Protection per eseguire automaticamente il deployment delle regole suggerite. Per attivare l'implementazione automatica delle regole, crea una regola segnaposto con la priorità e l'azione che preferisci utilizzando l'espressione evaluateAdaptiveProtectionAutoDeploy() nella condizione di corrispondenza. Questa regola restituisce true per le richieste che Adaptive Protection identifica come traffico di attacco e Cloud Armor applica l'azione alla richiesta di attacco. Sono supportati tutti i tipi di azione Cloud Armor, come allow, deny, throttle e redirect. Inoltre, puoi utilizzare la modalità di anteprima per registrare l'attivazione della regola, senza eseguire l'azione configurata.

Se utilizzi un proxy upstream come una CDN di terze parti davanti al bilanciatore del carico delle applicazioni esterno, ti consigliamo di configurare il campo userIpRequestHeaders per aggiungere l'indirizzo IP (o gli intervalli di indirizzi IP) del tuo provider a una lista consentita. In questo modo, Adaptive Protection non identifica erroneamente l'indirizzo IP di origine del proxy come partecipante a un attacco. Esamina invece il campo configurato dall'utente per l'indirizzo IP di origine del traffico prima che arrivasse al proxy.

Per saperne di più sulla configurazione del deployment automatico delle regole, consulta Esegui il deployment automatico delle regole suggerite di Adaptive Protection.

Stato della regola

Se non viene visualizzata alcuna regola quando tenti di eseguire il deployment di una regola suggerita, puoi utilizzare il campo ruleStatus per determinarne la causa.

Il valore del campo attackSize è espresso in query al secondo (QPS).

 ]
ruleStatus: RULE_GENERATED
attackSize: 5000
}

La tabella seguente descrive i possibili valori del campo e il loro significato.

Stato della regola Descrizione
RULE_GENERATED È stata normalmente generata una regola utilizzabile.
BASELINE_TOO_RECENT Tempo insufficiente per accumulare un traffico della base di riferimento affidabile. La generazione delle regole richiede fino a un'ora.
NO_SIGNIFICANT_VALUE_DETECTED Nessuna intestazione ha valori significativi associati al traffico di attacco, pertanto non è stato possibile generare alcuna regola.
NO_USABLE_RULE_FOUND Non è stato possibile creare alcuna regola utilizzabile.
ERROR Si è verificato un errore non specificato durante la creazione della regola.

Monitoraggio, feedback e segnalazione degli errori degli eventi

Per visualizzare la dashboard di Adaptive Protection o interagirvi, devi disporre delle seguenti autorizzazioni.

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

Dopo aver abilitato Adaptive Protection in qualsiasi policy di sicurezza di Cloud Armor, puoi visualizzare la seguente pagina nel riquadro Sicurezza della rete > Cloud Armor. Mostra il volume di traffico nel tempo per il servizio di backend e la policy di sicurezza selezionati, nonché la durata selezionata. Tutte le istanze di potenziali attacchi segnalate da Adaptive Protection sono annotate sul grafico ed elencate al di sotto. Quando fai clic su un evento di attacco specifico, viene visualizzata una finestra laterale con la firma dell'attacco e la regola suggerita in formato tabulare. Si tratta delle stesse informazioni contenute nelle voci di log di Cloud Logging descritte in Specifiche delle voci di Cloud Logging. Fai clic sul pulsante Applica per aggiungere la regola suggerita alla stessa policy di sicurezza.

Dashboard di Adaptive Protection
Dashboard di Adaptive Protection (fai clic per ingrandire)
Dettagli dell'avviso di Adaptive Protection
Dashboard di Adaptive Protection (fai clic per ingrandire)

Non ogni risultato di Adaptive Protection viene considerato un attacco, dato il contesto unico e i fattori ambientali del servizio di backend protetto. Se determini che il potenziale attacco descritto dall'avviso è un comportamento normale o accettato, puoi segnalare l'evento errato per contribuire all'addestramento dei modelli di Adaptive Protection. Accanto a ogni evento di attacco elencato sotto il grafico è presente un pulsante che apre una finestra interattiva per segnalare un evento errato ed eventualmente aggiungere del contesto. Segnalare un evento errato contribuisce a ridurre la probabilità di errori simili in futuro. Nel tempo, questo aumenta l'accuratezza di Adaptive Protection.

Monitoraggio, avvisi e logging

La telemetria di Adaptive Protection viene inviata a Cloud Logging e a Security Command Center. Il messaggio di log di Adaptive Protection inviato a Cloud Logging è descritto nelle sezioni precedenti di questo documento. Ogni volta che Adaptive Protection rileva un potenziale attacco viene generata una voce di log; ogni voce contiene un punteggio di confidenza che descrive il livello di certezza dei modelli riguardo l'anomalia del traffico osservato. Per perfezionare gli avvisi, è possibile configurare una policy di avviso in Cloud Logging per attivare un avviso solo quando un messaggio di log di Adaptive Protection ha un punteggio di confidenza superiore a una soglia specificata dall'utente. Ti consigliamo di iniziare con una soglia bassa, con un livello di confidenza > 0,5, per evitare di non ricevere avvisi su potenziali attacchi. La soglia di confidenza nella policy di avviso può essere aumentata nel tempo se gli avvisi hanno un tasso di impatto sulla base di riferimento non accettabile.

La dashboard di Security Command Center contiene anche i risultati di Adaptive Protection. Questi si trovano nella scheda Cloud Armor nella categoria Attacchi DDoS alle applicazioni. Ogni risultato include i dettagli del servizio, il livello di confidenza riguardo l'attacco, la firma associata all'attacco e un link all'avviso specifico nella dashboard di Adaptive Protection. Lo screenshot seguente è un esempio del risultato di un tentativo di attacco DDoS all'applicazione:

Risultato di un attacco DDoS all'applicazione.
Risultato di unattacco DDoS all'applicazione (fai clic per ingrandire).

Specifica delle voci di Cloud Logging

L'avviso di Adaptive Protection inviato a Cloud Logging è costituito da una voce di log contenente i seguenti elementi:

  • Confidenza dell'avviso: la sicurezza di Adaptive Protection riguardo il fatto che l'evento osservato sia un attacco.
  • Deployment automatico: un valore booleano che indica se è stata attivata una difesa automatica.
  • Firma dell'attacco
    • Nome dell'attributo: il nome dell'attributo che corrisponde a Value di seguito, ad esempio un nome di intestazione della richiesta specifico o un'origine geografica.
    • Valore: il valore a cui corrisponde l'attributo nel traffico dannoso.
    • Tipo di corrispondenza: la relazione tra Value e l'attributo nel traffico di attacco. Il valore è uguale a un attributo nel traffico di attacco o a una sua sottostringa.
    • Probabilità di attacco: la probabilità che una determinata richiesta sia dannosa, posto che l'attributo pertinente di questa richiesta corrisponda a Value.
    • Proporzione nell'attacco: la percentuale di potenziale traffico di attacco che corrisponde a Value.
    • Proporzione nella base di riferimento: la percentuale di traffico normale di riferimento che corrisponde a Value.
  • Regola suggerita
    • Condizione di corrispondenza: l'espressione da utilizzare nella condizione di corrispondenza della regola per identificare il traffico dannoso.
    • Tasso di impatto sulla base di riferimento: la percentuale stimata di traffico valido per il servizio di backend specifico sotto attacco che verrà bloccato dalla regola suggerita.
    • Tasso di impatto sulla base di riferimento nella policy: la percentuale stimata di traffico valido verso tutti i servizi di backend nella stessa policy di sicurezza bloccato dalla regola suggerita.
    • Tasso di attacco interessato: la percentuale prevista di traffico di attacco bloccato dalla regola suggerita.
  • Stato della regola: ulteriori dettagli sulla generazione della regola.

Panoramica del machine learning e privacy

  • Dati di addestramento e dati di rilevamento
    • Adaptive Protection crea più modelli per rilevare potenziali attacchi e identificare le loro firme. I segnali utilizzati da questi modelli per determinare se è in corso un attacco derivano dai metadati osservati nel traffico di richieste in entrata dei tuoi progetti. Questi metadati includono: indirizzo IP di origine, area geografica di origine e valori di alcune intestazioni delle richieste HTTP.
    • Le funzionalità effettive utilizzate dai modelli sono proprietà statistiche derivate degli indicatori menzionati in precedenza. Ciò significa che i dati di addestramento per i modelli non includono i valori effettivi di alcun metadato, ad esempio indirizzi IP e/o valori delle intestazioni delle richieste.
    • Quando Adaptive Protection viene attivato per la prima volta, per determinare se è in corso un attacco avrai accesso a un set di modelli di rilevamento addestrati solo con dati artificiali e comuni per tutti i clienti. Dopo che avrai segnalato un evento di attacco falso e i modelli saranno aggiornati utilizzando indicatori di traffico specifici per i tuoi progetti, questi modelli diventano esclusivi per i tuoi progetti e non verranno utilizzati per altri clienti.
  • Dati di generazione della firma
    • Dopo aver stabilito che è in corso un potenziale attacco, Adaptive Protection genera una firma dell'attacco efficace per aiutare l'obiettivo a mitigare rapidamente l'attacco. Per farlo, dopo aver abilitato Adaptive Protection su una policy di sicurezza, le metriche del traffico e i metadati delle richieste a un servizio di backend (associato alla policy di sicurezza) vengono registrati continuamente per apprendere le caratteristiche del traffico di riferimento.
    • Poiché Adaptive Protection deve acquisire informazioni sul traffico di riferimento, la generazione delle regole per mitigare i potenziali attacchi potrebbe richiedere fino a un'ora.

Passaggi successivi