Panoramica di Cloud Armor Adaptive Protection

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

1. Rilevare e inviare avvisi in caso di attività anomale
2. Genera una firma che descriva 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 relativi al 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 direttamente o inoltrati a un flusso di lavoro di monitoraggio di log o eventi di sicurezza downstream. Gli avvisi di 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 di attacco o regola suggerita da implementare per gli utenti.

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

Cloud Logging e Cloud Monitoring

Poiché l'utilizzo efficace di Adaptive Protection richiede di comprendere il funzionamento di logging e avvisi in Google Cloud, ti consigliamo di familiarizzare con Cloud Logging, gli avvisi e le relative norme.

• Per informazioni generali sulla registrazione, consulta la documentazione di Cloud Logging.
• Per informazioni sugli avvisi, consulta la documentazione di Cloud Monitoring.
• Per informazioni di logging specifiche di Google Cloud Armor, consulta Utilizzo del logging delle richieste.

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

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

Configurare e ottimizzare 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 una determinata policy di sicurezza, Adaptive Protection è attiva per tutti i servizi di backend a cui è associata la policy di sicurezza.

Dopo l'attivazione di Adaptive Protection, è previsto un periodo di addestramento di almeno un'ora prima che Adaptive Protection sviluppi una baseline 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 baseline per ciascun servizio di backend. Al termine del periodo di addestramento, ricevi avvisi in tempo reale quando Adaptive Protection identifica anomalie di alta frequenza o volume elevato nel traffico indirizzato a uno qualsiasi dei servizi di backend associati a questa policy di sicurezza.

Puoi ottimizzare gli avvisi della protezione adattiva in base a diverse metriche. Gli avvisi, inviati a Cloud Logging, includono un livello di confidenza, una firma di attacco, una regola suggerita e un tasso di base stimato interessato 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 base interessati associati alla regola suggerita rappresentano la percentuale di traffico di base esistente intercettato dalla regola. Vengono fornite due tariffe. 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, incluse tutte le destinazioni del servizio di backend configurate (non solo quella attaccata).

Puoi filtrare gli avvisi in Cloud Logging in base al livello di confidenza, ai tassi di base interessati o a entrambi. Per saperne di più sull'ottimizzazione degli avvisi, consulta la pagina Gestione dei criteri di avviso.

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

• Richieste gestite direttamente da Cloud CDN
• Richieste rifiutate da un criterio di sicurezza Google 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 modelli granulari, i suggerimenti di mitigazione di Adaptive Protection filtrano il traffico in base ai prefissi di host o percorso 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 target 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 di cui è stato eseguito il deployment, come avverrebbe senza le configurazioni granulari. Ad esempio, se vuoi che una regola di 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 di host e percorso 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 di origine esterna.
• Query al secondo (QPS) assoluto: la quantità di traffico di picco, in query al secondo, che riceve il servizio di backend o l'unità di traffico.
• Rispetto alle QPS di riferimento: un multiplo del volume di traffico di riferimento medio a lungo termine. Ad esempio, un valore di 2 rappresenta un QPS doppio rispetto al volume di traffico di base.

Per saperne di più sulla configurazione dei modelli granulari, consulta l'articolo Configurare Google Cloud Armor Adaptive Protection.

Utilizzare e interpretare gli avvisi

Non appena la protezione adattiva rileva un attacco sospetto, genera un evento nel dashboard degli eventi della protezione adattiva 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 di rete in Cloud Logging. Il messaggio di log identifica il servizio di backend sotto attacco e include un punteggio di affidabilità che indica con quale intensità Adaptive Protection valuta la modifica del pattern di traffico identificato come anomala. Il messaggio di log include anche una firma dell'attacco che illustra le caratteristiche del traffico di attacco, insieme alle regole Google Cloud Armor suggerite che potresti applicare per mitigare l'attacco.

Informazioni sulle firme degli attacchi

Un avviso di Protezione adattiva include una firma di 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 Google Cloud Armor predefinita che puoi implementare nei criteri di sicurezza pertinenti. Se non hai un abbonamento a Cloud Armor Enterprise, una firma di 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, referrer 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 al 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 baseline, ovvero la percentuale di traffico di base che possedeva questo valore dell'attributo al momento del rilevamento dell'attacco

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

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

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 (maggiori dettagli di seguito)
• Il servizio di backend sotto attacco o backendService
• Il punteggio di affidabilità, o confidence, che è un numero compreso tra 0 e 1 che indica con quale intensità il sistema di protezione adattiva valuta l'evento rilevato come attacco dannoso

Ricevi anche un insieme di firme e regole che caratterizzano l'attacco rilevato. Nello specifico, il set fornisce un elenco di headerSignatures, ognuno 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) ha questo valore Referer e solo l'1% del traffico di base tra tutto il traffico (proportionInBaseline) ha lo stesso valore Referer. Inoltre, tra tutto il traffico corrispondente a questo valore Referer, il 95% è traffico di attacco (attackLikelihood).

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

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?"
    }
   ]
  }
...

Eseguire il deployment delle regole suggerite

Gli avvisi di Adaptive Protection forniscono anche una regola 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 per mitigare l'attacco. Oltre alla firma, l'avviso include un tasso di traffico di base interessato per aiutarti a valutare l'impatto dell'implementazione della regola. Il tasso di traffico della base di riferimento interessato è una proporzione proiettata 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 Google Cloud Armor suggerita che puoi applicare.

Puoi trovare parte della firma dell'avviso e la frequenza di base 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 su 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 nel dashboard Adaptive Protection nell'interfaccia utente di Google Cloud Armor.

Per implementare la regola, crea una nuova regola 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, copia l'espressione evaluateAdaptiveProtection('11275630857957031521') dalla sezione suggestedRule dell'avviso.

Ti consigliamo vivamente di eseguire il deployment della regola inizialmente in modalità di anteprima in modo da poter valutare l'impatto della regola sul traffico di produzione. Quando lo fai, Google 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, verifica se gli effetti della nuova regola hanno effetti indesiderati in uno dei 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à della nuova regola su un valore superiore a quello di qualsiasi regola con l'azione impostata su Consenti. 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 un criterio di sicurezza di Google 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 concedere un'eccezione per alcuni tipi di traffico o clienti specifici da questa regola, puoi creare una regola "allow" con priorità più elevata, ovvero con un valore numerico inferiore. Per ulteriori informazioni sulla priorità delle regole, vedi Ordine di valutazione delle regole.

Eseguire 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 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 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 maggiori informazioni 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 implementarne una suggerita, puoi utilizzare il campo ruleStatus per determinare 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.

Monitoraggio, feedback e segnalazione degli errori degli eventi

Per visualizzare o interagire con la dashboard Protezione adattiva, devi disporre delle seguenti autorizzazioni.

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

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

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 un errore dell'evento per contribuire all'addestramento dei modelli di protezione adattiva. Accanto a ogni evento di attacco elencato sotto il grafico è presente un pulsante che apre una finestra interattiva per segnalare un errore dell'evento con un contesto facoltativo. La segnalazione di un errore relativo a un evento 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 della protezione adattiva inviato a Cloud Logging è descritto nelle sezioni precedenti di questo documento. Una voce di log viene generata ogni volta che la protezione adattiva rileva un potenziale attacco e ogni voce contiene un punteggio di confidenza che descrive il livello di certezza dei modelli che il traffico osservato sia anomalo. Per perfezionare gli avvisi, è possibile configurare un criterio 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 perdere avvisi di potenziali attacchi. La soglia di confidenza nella criterio di avviso può essere aumentata nel tempo se gli avvisi hanno un tasso di base 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 alle applicazioni. Ogni risultato include i dettagli del servizio, il livello di confidenza dell'attacco, la firma associata all'attacco e un link all'avviso specifico nella dashboard Protezione adattiva. Lo screenshot seguente è un esempio di risultato di un tentativo di attacco DDoS all'applicazione:

Specifica della voce di Cloud Logging

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

• Affidabilità dell'avviso: l'affidabilità di Adaptive Protection che l'evento osservato sia un attacco.
• Automaticamente distribuito: 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 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 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 delle regole per identificare il traffico dannoso.
  • Tasso di base di riferimento interessato: la percentuale prevista di traffico valido per il servizio di backend specifico sotto attacco acquisito dalla regola suggerita.
  • Tasso di base interessato nel criterio: la percentuale stimata di traffico valido verso tutti i servizi di backend nello stesso criterio di sicurezza acquisito dalla regola suggerita.
  • Tasso di attacco interessato: la percentuale prevista di traffico di attacco acquisita dalla regola suggerita.
• Stato regola: ulteriori dettagli sulla generazione delle regole.

Panoramica del machine learning e della privacy

• Dati di addestramento e dati di rilevamento
  • La protezione adattiva crea diversi 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 del traffico di richieste in entrata dai 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 sopra menzionati. ovvero i dati di addestramento per i modelli non includono i valori effettivi di metadati, come indirizzi IP e/o valori di intestazione della richiesta.
  • Un insieme comune di modelli di rilevamento, addestrati solo con dati artificiali, viene condiviso tra tutti i clienti per determinare se è in corso un attacco quando la protezione adattiva viene attivata per la prima volta. Una volta segnalato un evento di attacco falso e aggiornati 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 di generazione della firma
  • Dopo aver stabilito che è in corso un potenziale attacco, la protezione adattiva genera una firma di attacco efficace per aiutare il target a mitigare rapidamente l'attacco. Per ottenere quanto sopra, dopo aver abilitato Adaptive Protection su un criterio di sicurezza, le metriche sul traffico e i metadati delle richieste a un servizio di backend (associato al criterio di sicurezza) vengono registrati continuamente per apprendere le caratteristiche di base del traffico.
  • Poiché Adaptive Protection deve acquisire informazioni sul traffico di base, potrebbe essere necessaria fino a un'ora prima di generare regole per mitigare potenziali attacchi.

Passaggi successivi

• Scopri di più sui casi d'uso comuni di Adaptive Protection
• Scopri le funzionalità dei livelli di Cloud Armor Enterprise
• Scopri come abilitare Cloud Armor Enterprise