Panoramica di Google Cloud Armor Adaptive Protection

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

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

Puoi abilitare o disabilitare Adaptive Protection in base ai criteri di sicurezza.

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

Disponibilità di Adaptive Protection

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

Se i tuoi progetti non sono già registrati in Cloud Armor Enterprise, consulta Utilizzo di Cloud Armor Enterprise per informazioni su come registrarsi.

Cloud Logging e Cloud Monitoring

Poiché l'utilizzo efficace di Adaptive Protection richiede la comprensione del funzionamento del logging e degli avvisi in Google Cloud, 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 le tue applicazioni sono già protette dai criteri di sicurezza di Google Cloud Armor. Quando abiliti Adaptive Protection per un determinato criterio di sicurezza, viene applicato a tutti i servizi di backend a cui è associato il criterio di sicurezza.

Dopo aver abilitato Adaptive Protection, segue 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 di ciascun 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 volumi elevati nel traffico diretto a uno qualsiasi dei servizi di backend associati al criterio di sicurezza.

Puoi ottimizzare gli avvisi di Adaptive Protection in base a diverse metriche. Gli avvisi, che vengono inviati a Cloud Logging, includono un livello di confidenza, una firma di attacco, una regola suggerita e una percentuale di riferimento interessata stimata e associata alla regola suggerita.

  • Il livello di confidenza indica il livello di confidenza con cui i modelli Adaptive Protection prevedono che il cambiamento osservato nel pattern di traffico sia anomalo.
  • Le tariffe di riferimento interessate associate alla regola suggerita rappresentano la percentuale di traffico di riferimento esistente che viene rilevata dalla regola. Sono previste due tariffe. La prima è la percentuale relativa al traffico nel servizio di backend attaccato. Il secondo è la percentuale relativa a tutto il traffico che passa attraverso il criterio di sicurezza, comprese tutte le destinazioni servizio di backend configurati (non solo quelli attaccati).

Puoi filtrare gli avvisi in Cloud Logging in base al livello di confidenza, alle percentuali di riferimento interessate o a entrambi. Per ulteriori informazioni sull'ottimizzazione degli avvisi, consulta Gestione dei criteri di avviso.

Adaptive Protection mira a proteggere i servizi di backend dagli attacchi DDoS di livello 7 ad alto volume. 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 indirizzato a ciascun servizio di backend. Ciò significa che un backend dietro un servizio di backend può essere sovraccarico, 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 modelli granulari, le mitigazioni suggerite da Adaptive Protection filtrano il traffico in base ai prefissi host o dei percorsi dell'URL corrispondenti, contribuendo a ridurre i falsi positivi. Ciascuno di questi host o percorsi è chiamato unità di traffico granulare.

Le firme di attacco identificate prendono di mira solo il traffico dell'attacco che arriva all'unità di traffico granulare; tuttavia, il filtro viene comunque applicato a tutte le richieste corrispondenti alla regola di cui è stato eseguito il deployment, come farebbe 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 del traffico, ti consigliamo di utilizzare una condizione di corrispondenza come evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ....

Oltre ai prefissi host e dei percorsi URL, puoi configurare soglie di avviso in base ad alcune o 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 non è disponibile per i backend serverless come Cloud Run, Cloud Functions o i backend di origine esterni.
  • Query assolute al secondo (QPS): la quantità di traffico di picco, in query al secondo, ricevuta dal servizio di backend o dall'unità di traffico.
  • Rispetto al valore QPS di riferimento: un multiplo del volume di traffico di riferimento medio a lungo termine. Ad esempio, un valore 2 rappresenta un QPS pari al doppio del volume di traffico di riferimento.

Per ulteriori informazioni sulla configurazione di modelli granulari, consulta Configurare 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 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 di rete in Cloud Logging. Il messaggio di log identifica il servizio di backend sottoposto a attacco e include un punteggio di confidenza che indica il livello di importanza di Adaptive Protection per classificare la modifica del pattern di traffico identificata come anomala. Il messaggio di log include anche una firma di attacco che illustra le caratteristiche del traffico dell'attacco, insieme alle regole suggerite di Google Cloud Armor che potresti applicare per mitigare l'attacco.

Comprendere le firme degli attacchi

Un avviso di Adaptive Protection include una firma di attacco, ovvero una descrizione degli attributi del traffico del potenziale attacco. Puoi utilizzare la firma per identificare e potenzialmente bloccare l'attacco. La firma assume due forme: come tabella leggibile dall'utente e come regola WAF precostruita di Google Cloud Armor di cui è possibile eseguire il deployment nel criterio di sicurezza pertinente. Se non disponi di un abbonamento a Cloud Armor Enterprise, nell'avviso di base non è inclusa una firma di attacco.

La firma consiste in un insieme di attributi, come indirizzo IP di origine, regioni geografiche, cookie, user agent, referer e altre intestazioni di richieste HTTP, e l'insieme di valori per gli 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 servizio di backend.

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

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

La specifica della voce di Cloud Logging contiene dettagli sulle informazioni contenute in ciascun 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 in 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 (scopri di più 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, ognuno dei quali corrisponde a un'intestazione HTTP e contiene un elenco di significantValues per l'intestazione specifica. Ogni valore significativo è un valore di intestazione osservato o una sua sottostringa.

Di seguito è riportato un esempio di firma:

...
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 di attacco (proportionInAttack) ha questo valore Referer e solo l'1% del traffico di riferimento tra tutto il traffico (proportionInBaseline) ha lo stesso valore di Referer. Inoltre, tra tutto il traffico corrispondente a questo valore Referer, il 95% è il traffico di attacco (attackLikelihood).

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

La proprietà matchType specifica la relazione tra l'attributo nel traffico dell'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 di Google Cloud Armor consigliata espressa nel linguaggio delle regole personalizzate. Questa regola può essere utilizzata per creare una regola in un criterio di sicurezza di Google Cloud Armor per 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 del 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.

Alcune delle firme degli avvisi e la percentuale di riferimento interessata sono riportate 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 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 eseguire il deployment delle 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 nella UI di Google Cloud Armor.

Per eseguire il deployment della regola, devi crearne una nuova nel criterio di sicurezza di Google Cloud Armor che protegge i servizi di backend di destinazione 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.

Consigliamo vivamente di eseguire inizialmente il deployment della regola in modalità di anteprima per poter valutare l'impatto della regola 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 è collegato a più servizi di backend, tieni presente se gli effetti della nuova regola hanno effetti indesiderati su tutti i servizi di backend. In questo caso, configura nuovi criteri di sicurezza per mitigare gli effetti indesiderati e collegali ai servizi di backend corretti.

Ti consigliamo di impostare la priorità per la nuova regola su un valore superiore a quello di qualsiasi regola con l'azione impostata in modo da consentire. Questo perché, per avere l'impatto previsto e l'effetto massimo nella mitigazione dell'attacco, la regola deve essere implementata nella posizione di priorità logica più alta per garantire che tutto il traffico corrispondente venga bloccato dalla regola. Le regole in un criterio di sicurezza 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 una parte del traffico o client specifici da questa regola, è possibile creare una regola di "autorizzazione" con una priorità più elevata, ovvero con un valore numerico inferiore. Per ulteriori informazioni sulla priorità delle regole, consulta Ordine di valutazione delle regole.

Esegui automaticamente il deployment delle regole suggerite

Puoi anche configurare Adaptive Protection in modo che esegua automaticamente il deployment delle regole suggerite. Per attivare il deployment automatico delle regole, puoi creare una regola segnaposto con la tua scelta di priorità e azione utilizzando l'espressione evaluateAdaptiveProtectionAutoDeploy() nella condizione di corrispondenza. Questa regola valuta 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 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 in modo da aggiungere l'indirizzo IP (o gli intervalli di indirizzi IP) del tuo provider a una lista consentita. Questo impedisce ad Adaptive Protection di identificare erroneamente l'indirizzo IP di origine del proxy come partecipazione a un attacco. Esamina invece il campo configurato dall'utente per l'indirizzo IP di origine del traffico prima che arrivi al proxy.

Per saperne di più sulla configurazione del deployment automatico delle regole, consulta Eseguire automaticamente il deployment 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 determinare la causa.

 ]
ruleStatus: RULE_GENERATED
attackSize: 5000
}

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

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

Monitoraggio, feedback e segnalazione degli errori relativi agli eventi

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

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

Dopo aver attivato Adaptive Protection in qualsiasi criterio di sicurezza di Google Cloud Armor, puoi visualizzare la pagina seguente nel riquadro Sicurezza della rete > Google Cloud Armor. Viene visualizzato il volume di traffico nel tempo per il criterio di sicurezza e il servizio di backend selezionati, nonché la durata selezionata. Eventuali 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 contenute nelle voci di 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 di Adaptive Protection (fai clic per ingrandire)
Dettagli avvisi di Adaptive Protection
Dashboard di Adaptive Protection (fai clic per ingrandire)

Non tutti i risultati di Adaptive Protection vengono considerati come attacchi, considerati il contesto specifico e i fattori ambientali del servizio di backend protetto. Se determini che il potenziale attacco descritto dall'avviso è normale o un comportamento accettato, puoi segnalare un errore relativo a un 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 che consente di segnalare un errore evento con un contesto facoltativo. Segnalare un errore evento aiuta a ridurre la probabilità di errori simili in futuro. Nel tempo, la precisione di Adaptive Protection aumenta.

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 voce di log viene generata ogni volta che Adaptive Protection rileva un potenziale attacco e ogni voce contiene un punteggio di confidenza che descrive quanto i modelli siano sicuri che il traffico osservato sia anomalo. Per perfezionare l'avviso, in Cloud Logging può essere configurato un criterio di avviso in modo da 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 confidenza maggiore di 0,5, per evitare di perdere avvisi relativi a potenziali attacchi. La soglia di affidabilità nel criterio di avviso può essere aumentata nel tempo se gli avvisi hanno una percentuale di riferimento interessata 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 alle applicazioni. Ogni risultato include i dettagli del servizio, la confidenza dell'attacco, la firma associata all'attacco e un link all'avviso specifico nella dashboard di Adaptive Protection. Lo screenshot seguente è un esempio di tentativo di rilevamento di un attacco DDoS all'applicazione:

Rilevamento di attacchi DDoS alle applicazioni.
Ricerca di un attacco DDoS a un'applicazione (fai clic per ingrandire).

Specifica delle voci di Cloud Logging

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

  • Confidenza degli avvisi: Adaptive Protection indica che l'evento osservato è un attacco.
  • Deployment automatico: valore booleano che rappresenta se è stata attivata o meno una difesa automatica.
  • Firma dell'attacco
    • Nome dell'attributo: il nome dell'attributo che corrisponde a Value di seguito, ad esempio un determinato nome di intestazione della richiesta 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 o una sottostringa di un attributo nel traffico di attacco.
    • Probabilità di attacco: la probabilità che una determinata richiesta sia dannosa, in quanto l'attributo pertinente di questa richiesta corrisponde a Value.
    • Proporzione all'attacco: la percentuale di traffico potenziale di attacco che corrisponde a Value.
    • Proporzione in 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 delle regole per identificare il traffico dannoso.
    • Percentuale di riferimento interessata: la percentuale prevista di traffico di buona qualità verso il servizio di backend specifico sotto attacco che viene acquisita dalla regola suggerita.
    • Percentuale di riferimento interessata per tutti i criteri: la percentuale prevista di traffico soddisfacente verso tutti i servizi di backend nello stesso criterio di sicurezza acquisita dalla regola suggerita.
    • Tasso di attacchi interessati: la percentuale prevista di traffico di attacchi acquisiti dalla regola suggerita.
  • Stato regola: dettagli aggiuntivi sulla generazione della regola.

Panoramica e privacy del machine learning

  • Dati di addestramento e dati di rilevamento
    • Adaptive Protection crea diversi 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 delle richieste in entrata dai tuoi progetti. Tali metadati includono: indirizzo IP di origine, area geografica di origine e i valori di alcune intestazioni delle richieste HTTP.
    • Le caratteristiche effettive utilizzate dai modelli derivano dalle proprietà statistiche derivate dagli indicatori sopra menzionati. In altre parole, i dati di addestramento dei modelli non includono i valori effettivi dei metadati, come indirizzi IP e/o valori di intestazione delle richieste.
    • Un set comune di modelli di rilevamento, addestrati solo con dati artificiali, viene condiviso tra tutti i clienti per determinare se è in corso un attacco quando Adaptive Protection viene attivato per la prima volta. Se segnali un falso evento di attacco e i modelli vengono aggiornati utilizzando indicatori di traffico specifici dei tuoi progetti, questi sono locali dei tuoi progetti e non vengono utilizzati per altri clienti.
  • Dati per la generazione delle firme
    • Dopo aver determinato che è in corso un potenziale attacco, Adaptive Protection genera una firma di attacco efficace per aiutare l'obiettivo a mitigare rapidamente l'attacco. A questo scopo, dopo aver abilitato Adaptive Protection su un criterio di sicurezza, le metriche del traffico e i metadati delle richieste a un servizio di backend (associati al criterio di sicurezza) vengono registrati continuamente per apprendere le caratteristiche del traffico di base.
    • Poiché Adaptive Protection deve apprendere informazioni sul traffico di riferimento, Adaptive Protection potrebbe richiedere fino a un'ora prima di generare le regole per mitigare i potenziali attacchi.

Passaggi successivi