Panoramica di Google Cloud Armor Adaptive Protection

Google Cloud Armor Adaptive Protection ti aiuta a proteggere le applicazioni, i siti web e i servizi Google Cloud da attacchi DDoS (Distributed Denial of Service) L7 come i flood HTTP e altre attività dannose di livello 7 (a livello di applicazione). Adaptive Protection crea modelli di machine learning che:

  1. Rileva e invia avvisi in caso di attività anomala
  2. Generare una firma che descrive il potenziale attacco
  3. Genera una regola WAF di Google Cloud Armor personalizzata per bloccare la firma

Puoi abilitare o disabilitare Adaptive Protection in base al criterio di sicurezza.

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

Disponibilità di Adaptive Protection

Gli avvisi di Adaptive Protection complete sono disponibili solo se ti abboni a Google Cloud Armor Enterprise. Altrimenti, riceverai solo un avviso di base, senza una firma di attacco o la possibilità di eseguire il deployment di una regola suggerita.

Se i progetti non sono ancora registrati in Cloud Armor Enterprise, consulta Utilizzo di Cloud Armor Enterprise per informazioni su come eseguire la registrazione.

Cloud Logging e Cloud Monitoring

Poiché utilizzare Adaptive Protection in modo efficace è necessario comprendere come funzionano il logging e gli avvisi in Google Cloud, pertanto ti consigliamo di acquisire familiarità con i criteri di Cloud Logging, avviso e avviso.

Configura e ottimizza gli avvisi

Puoi abilitare Adaptive Protection nei progetti in cui i criteri di sicurezza di Google Cloud Armor proteggono già le tue applicazioni. Quando abiliti Adaptive Protection per un determinato criterio di sicurezza, Adaptive Protection è attivo per tutti i servizi di backend a cui il criterio di sicurezza è associato.

Dopo l'abilitazione di Adaptive Protection, prevede 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 generare avvisi. Durante il periodo di addestramento, Adaptive Protection modella i modelli di traffico in entrata e di utilizzo specifici di ogni servizio di backend, in modo da sviluppare la base di riferimento per ogni servizio di backend. Al termine del periodo di addestramento, riceverai avvisi in tempo reale quando Adaptive Protection identifica anomalie ad alta frequenza o di volume elevato nel traffico indirizzato a uno dei servizi di backend associati al criterio di sicurezza.

Puoi regolare gli avvisi di Adaptive Protection in base a diverse metriche. Gli avvisi inviati a Cloud Logging includono un livello di confidenza, una firma di attacco, una regola suggerita e una stima del tasso di riferimento interessato associato alla regola suggerita.

  • Il livello di confidenza indica l'affidabilità con cui i modelli di Adaptive Protection prevedino che il cambiamento osservato nel modello di traffico è anomalo.
  • Le tariffe di riferimento interessate associate alla regola suggerita rappresentano la percentuale di traffico di riferimento esistente interessato dalla regola. Sono previste due tariffe. La prima è la percentuale relativa al traffico verso il servizio di backend specifico sotto attacco. La seconda è la percentuale relativa a tutto il traffico che passa attraverso il criterio di sicurezza, comprese tutte le destinazioni servizio di backend configurate (non solo quella oggetto dell'attacco).

Puoi filtrare gli avvisi in Cloud Logging in base al livello di confidenza, ai tassi di riferimento interessati o a entrambi. Per ulteriori informazioni sull'ottimizzazione degli avvisi, vedi Gestione dei criteri di avviso.

Adaptive Protection mira a proteggere i servizi di backend da attacchi DDoS di livello 7 a volumi elevati. Nei seguenti scenari, le richieste non vengono conteggiate in Adaptive Protection:

  • Richieste gestite direttamente da Cloud CDN
  • Richieste rifiutate da un criterio di sicurezza di Google Cloud Armor

Modelli granulari

Per impostazione predefinita, Adaptive Protection rileva un attacco e suggerisce mitigazioni in base al traffico tipico diretto a ciascun servizio di backend. Ciò significa che un backend dietro un servizio di backend può essere sovraccarico, ma Adaptive Protection non intraprende alcuna azione perché il traffico dell'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 modelli granulari, le mitigazioni suggerite di Adaptive Protection filtrano il traffico in base ai prefissi corrispondenti del percorso dell'host o dell'URL, contribuendo a ridurre i falsi positivi. Ciascuno di questi host o percorsi è chiamato unità di traffico granulare.

Le firme di attacco identificate hanno come target solo il traffico dell'attacco in ingresso nell'unità di traffico granulare; tuttavia, il filtro si applica comunque a tutte le richieste corrispondenti alla regola di cui è stato eseguito il deployment, come avverrebbe senza le configurazioni granulari. Ad esempio, se vuoi che una regola di cui è stato eseguito il deployment automatico corrisponda solo a una specifica unità granulare di traffico, valuta la possibilità di utilizzare una condizione di corrispondenza come evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ....

Oltre ai prefissi host e del percorso dell'URL, puoi configurare le soglie di avviso in base ad alcune o a tutte le opzioni seguenti. Puoi applicare queste soglie alle unità di traffico granulari o al servizio di backend nel suo insieme, 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 non è disponibile per backend serverless come Cloud Run, Cloud Functions o backend di origine esterna.
  • Query assolute al secondo (QPS): la quantità massima di traffico, in query al secondo, ricevuta dal servizio di backend o dall'unità di traffico.
  • Rispetto al QPS di riferimento: un multiplo del volume di traffico di riferimento medio a lungo termine. Ad esempio, un valore 2 rappresenta un QPS del doppio del volume di traffico di riferimento.

Per ulteriori informazioni sulla configurazione di modelli granulari, consulta Configurare Google Cloud Armor Adaptive Protection.

Utilizzare e interpretare gli avvisi

Non appena Adaptive Protection rileva un attacco sospetto, genera un evento nella dashboard degli eventi di Adaptive Protection e genera un elemento di log in Cloud Logging. L'avviso si trova nel payload JSON dell'elemento di log. L'elemento di log viene generato nella risorsa Criterio di sicurezza della rete in Cloud Logging. Il messaggio di log identifica il servizio di backend sottoposto a attacco e include un punteggio di confidenza che indica in che misura Adaptive Protection valuta la modifica del pattern di traffico identificato come anomalo. Il messaggio di log include anche una firma dell'attacco che illustra le caratteristiche del traffico dell'attacco, insieme alle regole di Google Cloud Armor suggerite che potresti applicare per mitigare l'attacco.

Informazioni sulle firme di attacco

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

La firma è composta da un insieme di attributi, come l'indirizzo IP di origine, le regioni geografiche, i cookie, gli user agent, i referrer e altre intestazioni delle richieste HTTP, nonché l'insieme di valori per quegli attributi che si ritiene siano associati al potenziale traffico di attacco. L'insieme di attributi non è configurabile dall'utente. I valori degli attributi dipendono dai valori nel traffico in entrata verso il tuo servizio di backend.

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

  • La probabilità di un attacco
  • La proporzione dell'attributo nell'attacco, ovvero la percentuale di traffico potenziale dell'attacco con questo valore al momento in cui è stato rilevato l'attacco
  • La proporzione dell'attributo nel riferimento, ovvero la percentuale di traffico di riferimento che possedeva questo valore dell'attributo nel momento in cui è stato rilevato l'attacco

La specifica delle voci di Cloud Logging contiene dettagli sulle informazioni contenute in ogni avviso.

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

Nome dell'attributo Valore Tipo di corrispondenza Probabile attacco Proporzione di attacco Proporzione in base al valore 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 Regno Unito 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 log eventi di Cloud Logging pertinente contengono quanto segue:

  • Un ID avviso univoco o alertID, utilizzato per fare riferimento a un avviso specifico quando segnala il feedback degli utenti (ulteriori informazioni 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 in che misura il sistema Adaptive Protection valuta l'evento rilevato come attacco dannoso

Riceverai inoltre una serie di firme e regole che caratterizzano l'attacco rilevato. In particolare, il set fornisce un elenco di headerSignatures, ciascuno 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. In particolare, il 60% del traffico proveniente dagli attacchi (proportionInAttack) ha questo valore Referer e solo l'1% del traffico di riferimento in tutto il traffico (proportionInBaseline) ha lo stesso valore Referer. Inoltre, di tutto il traffico che corrisponde a questo valore di Referer, il 95% è costituito da traffico dagli attacchi (attackLikelihood).

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

La proprietà matchType specifica la relazione tra l'attributo nel traffico degli attacchi 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 di Google Cloud Armor suggerita espressa nel linguaggio delle regole personalizzate. Questa regola può essere utilizzata per creare una regola in un criterio di sicurezza di Google Cloud Armor al fine di mitigare l'attacco. Oltre alla firma, l'avviso include una percentuale di traffico di riferimento interessato per aiutarti a valutare l'impatto del deployment della regola. La percentuale di traffico di riferimento interessato è una percentuale prevista di traffico 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 di Google Cloud Armor suggerita che puoi applicare.

Puoi trovare alcune delle firme di avviso e la percentuale di riferimento interessata nel messaggio di log inviato a Cloud Logging. L'esempio seguente è il payload JSON di un avviso di esempio insieme alle etichette delle risorse in base alle quali è possibile 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 eseguire il deployment delle regole suggerite copiando l'espressione CEL dalla firma della regola e incollando l'espressione nella condizione di corrispondenza di una regola appena creata oppure facendo clic sul pulsante Applica nella dashboard di Adaptive Protection nella UI di Google Cloud Armor.

Per eseguire il deployment della regola, devi creare una nuova regola nel criterio di sicurezza di Google Cloud Armor che protegge i servizi di backend scelti come 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 riportato sopra, copi l'espressione evaluateAdaptiveProtection('11275630857957031521') dalla sezione suggestedRule dell'avviso.

Ti consigliamo vivamente di eseguire inizialmente il deployment della regola in modalità di anteprima, in modo da poterne valutare l'impatto sul traffico di produzione. Quando esegui questa operazione, Google Cloud Armor registra l'azione e il traffico associato ogni volta che viene attivata la regola, ma non viene intrapresa alcuna azione sul traffico corrispondente.

Inoltre, se il criterio di sicurezza è associato a più servizi di backend, controlla se gli effetti della nuova regola hanno effetti indesiderati su uno qualsiasi dei servizi di backend. In questo caso, configura nuovi criteri di sicurezza per attenuare gli effetti indesiderati e collegali ai servizi di backend corretti.

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

Esegui automaticamente il deployment delle regole suggerite

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

Se utilizzi un proxy upstream prima del bilanciatore del carico delle applicazioni esterno, ad esempio una rete CDN di terze parti, ti consigliamo di configurare il campo userIpRequestHeaders in modo da inserire nella lista consentita gli indirizzi IP (o gli intervalli di indirizzi IP) del tuo provider. Ciò impedisce ad Adaptive Protection di identificare 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 arrivi al proxy.

Per maggiori informazioni sulla configurazione del deployment automatico delle regole, consulta Eseguire automaticamente il deployment delle regole suggerite di Adaptive Protection.

Stato della regola

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

 ]
ruleStatus: RULE_GENERATED
attackSize: 5000
}

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

Stato della regola Descrizione
RULE_GENERATED Una regola utilizzabile è stata generata normalmente.
BASELINE_TOO_RECENT Tempo insufficiente per accumulare traffico di riferimento affidabile. Per generare le regole è necessaria fino a un'ora.
NO_SIGNIFICANT_VALUE_DETECTED Nessuna intestazione ha valori significativi associati al traffico degli attacchi, pertanto non è stato possibile generare regole.
NO_USABLE_RULE_FOUND Non è stato possibile creare regole utilizzabili.
ERRORE Si è verificato un errore non specificato durante la creazione della regola.

Monitoraggio, feedback e segnalazione di errori relativi agli eventi

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

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

Dopo aver abilitato Adaptive Protection su qualsiasi criterio di sicurezza di Google Cloud Armor, puoi visualizzare la seguente pagina nel riquadro Sicurezza della rete > Google Cloud Armor. Visualizza il volume di traffico nel tempo per il criterio di sicurezza e il servizio di backend selezionati, nonché la durata selezionata. Le istanze di potenziali attacchi segnalati da Adaptive Protection sono annotate nel grafico ed elencate sotto il grafico. Quando fai clic su uno specifico evento di attacco, viene visualizzata una finestra laterale con la firma dell'attacco e la regola suggerita in formato tabulare. Si tratta delle stesse informazioni presenti nelle voci dei log di Cloud Logging descritte nella specifica delle voci di Cloud Logging. Fai clic sul pulsante Applica per aggiungere la regola suggerita allo stesso criterio di sicurezza.

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

Non tutti i risultati di Adaptive Protection sono considerati un attacco, a causa del contesto univoco e dei fattori ambientali del servizio di backend protetto. Se determini che il potenziale attacco descritto nell'avviso è un comportamento normale o accettato, puoi segnalare un errore evento per addestrare i modelli di Adaptive Protection. Accanto a ogni evento di attacco elencato sotto il grafico c'è un pulsante che apre una finestra interattiva per segnalare un errore relativo a un evento con del contesto facoltativo. Segnalare un errore di evento aiuta a ridurre la probabilità di errori simili in futuro. Nel tempo, ciò aumenta la precisione 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. Viene generata una voce di log ogni volta che Adaptive Protection rileva un potenziale attacco e ogni voce contiene un punteggio di confidenza che descrive l'affidabilità dei modelli che il traffico osservato sia anomalo. Per perfezionare gli avvisi, in Cloud Logging è possibile configurare un criterio di avviso in modo che attivi 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 maggiore di 0,5, per evitare di perdere avvisi di potenziali attacchi. La soglia di affidabilità nel criterio di avviso può essere aumentata nel tempo se gli avvisi hanno una percentuale di riferimento di impatto inaccettabile.

La dashboard di Security Command Center contiene anche i risultati di Adaptive Protection. Si trovano nella scheda Google Cloud Armor nella categoria Attacchi DDoS. Ogni risultato include i dettagli del servizio, l'affidabilità dell'attacco, la firma associata all'attacco e un link all'avviso specifico nella dashboard di Adaptive Protection. Il seguente screenshot è un esempio di tentativo di attacco DDoS di un'applicazione:

Ricerca di attacchi DDoS dell'applicazione.
Attacco DDoS ad applicazioni (fai clic per ingrandire).

Specifica della voce Cloud Logging

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

  • Confidenza degli avvisi: con Adaptive Protection la confidenza che l'evento osservato è un attacco.
  • Deployment automatico: valore booleano che indica se è stata attivata una difesa automatica.
  • Firma dell'attacco
    • Nome attributo: il nome dell'attributo che corrisponde al valore Value riportato di seguito, ad esempio il nome di un'intestazione di una determinata richiesta o un'origine geografica.
    • Valore: il valore a cui corrisponde l'attributo in traffico dannoso.
    • Tipo di corrispondenza: la relazione tra Value e l'attributo nel traffico degli attacchi. Il valore è uguale o è una sottostringa di un attributo nel traffico di attacco.
    • Probabilità di attacco: la probabilità che una determinata richiesta sia dannosa, dato che l'attributo pertinente di questa richiesta corrisponde a Value.
    • Proporzione di attacco: la percentuale di potenziale traffico di attacco che corrisponde a Value.
    • Proporzione nel riferimento: la percentuale di traffico normale di riferimento corrispondente a Value.
  • Regola suggerita
    • Condizione di corrispondenza: l'espressione da utilizzare nella condizione di corrispondenza delle regole per identificare il traffico dannoso.
    • Percentuale di riferimento interessata: la percentuale prevista di traffico buono verso il servizio di backend specifico sotto attacco, acquisito dalla regola suggerita.
    • Percentuale di riferimento interessata nel criterio: la percentuale prevista di traffico buono verso tutti i servizi di backend nello stesso criterio di sicurezza acquisito dalla regola suggerita.
    • Percentuale di attacco interessato: la percentuale prevista di traffico di attacco acquisito dalla regola suggerita.
  • Stato regola: dettagli aggiuntivi sulla generazione delle regole.

Panoramica e privacy del machine learning

  • Dati di addestramento e dati di rilevamento
    • Adaptive Protection crea vari modelli per rilevare potenziali attacchi e identificarne le firme. Gli indicatori utilizzati da questi modelli per determinare se un attacco è in corso derivano dai metadati osservati del traffico di richieste in entrata dai tuoi progetti. Tali metadati includono l'indirizzo IP di origine, l'area geografica di origine e i valori di alcune intestazioni delle richieste HTTP.
    • Le funzionalità effettive utilizzate dai modelli sono proprietà statistiche derivate degli indicatori di cui sopra. In altre parole, i dati di addestramento dei modelli non includono i valori effettivi di alcun metadati, come gli indirizzi IP e/o i valori dell'intestazione della richiesta.
    • Un insieme comune di modelli di rilevamento, addestrati solo con dati artificiali, viene condiviso tra tutti i clienti per determinare se un attacco è in corso, quando Adaptive Protection viene abilitato per la prima volta. Una volta segnalato qualsiasi evento di falso attacco e aggiornato i modelli utilizzando indicatori di traffico specifici dei tuoi progetti, questi modelli sono locali per i tuoi progetti e non vengono utilizzati per altri clienti.
  • Dati per la generazione delle firme
    • Dopo che Adaptive Protection ha determinato che è in corso un potenziale attacco, genera una firma di attacco efficace per aiutare l'obiettivo a mitigare rapidamente l'attacco. Per raggiungere questo obiettivo, dopo aver abilitato Adaptive Protection in un criterio di sicurezza, le metriche di traffico e i metadati delle richieste a un servizio di backend (associati al criterio di sicurezza) vengono continuamente registrate per apprendere le caratteristiche di base del traffico.
    • Poiché Adaptive Protection deve apprendere il traffico di riferimento, Adaptive Protection potrebbe richiedere fino a un'ora prima di generare regole per mitigare i potenziali attacchi.

Passaggi successivi