Best practice per Google Cloud Armor

Questa pagina fornisce le best practice per ottimizzare e regolare i deployment di Google Cloud Armor.

Google Cloud Armor viene di solito implementato con il bilanciatore del carico delle applicazioni esterno globale, il bilanciatore del carico delle applicazioni classico o il bilanciatore del carico di rete con proxy esterno. Quando esegui il deployment di Google Cloud Armor, colleghi un criterio di sicurezza al servizio di backend del bilanciatore del carico che vuoi proteggere. Un criterio di sicurezza è costituito da una raccolta di regole predefinite e personalizzate che puoi stabilire.

Creazione di criteri e regole di sicurezza

Le sezioni seguenti contengono best practice e consigli per i nuovi criteri e le nuove regole di sicurezza.

Fornisci descrizioni delle regole

Utilizza le descrizioni delle regole per fornire un contesto aggiuntivo sul motivo per cui è stata creata ciascuna regola e sulla sua funzione prevista. Il campo description è limitato a 64 caratteri, pertanto i riferimenti a database di gestione della configurazione o ad altri repository sono il modo più efficiente per acquisire il contesto.

Considerare lo spazio prioritario

Quando configuri inizialmente le regole, lascia un intervallo di almeno 10 tra ciascun valore di priorità della regola. Ad esempio, le prime due regole di un criterio di sicurezza potrebbero avere le priorità 20 e 30. In questo modo puoi inserire altre regole quando ne hai bisogno. Inoltre, ti consigliamo di raggruppare regole simili in blocchi, lasciando intervalli più ampi tra i gruppi.

Utilizzare la modalità di anteprima

Le regole dei criteri di sicurezza, incluse le firme dell'Open Web Application Security Project (OWASP), possono avere effetti imprevedibili sulla tua applicazione. Utilizza la modalità di anteprima per valutare se l'introduzione di una regola avrà un impatto negativo sul traffico in produzione.

Attivare Cloud Armor Adaptive Protection

Attiva Adaptive Protection per una protezione aggiuntiva delle tue applicazioni. La Protezione adattiva monitora il traffico e, se necessario, consiglia nuove regole per i criteri di sicurezza. Inoltre, ti consigliamo di implementare un regolamento per gli avvisi per assicurarti che le persone giuste vengano avvisate di potenziali attacchi. Adaptive Protection è ideale per la protezione volumetrica. Gli attacchi che non sono volumetrici potrebbero non attivare Adaptive Protection.

Abilita analisi JSON

Se la tua applicazione invia contenuti JSON nel corpo delle richieste POST, assicurati di attivare l'analisi JSON. Se non attivi l'analisi JSON, Google Cloud Armor non analizza i contenuti JSON dei campi POST per le regole WAF predefinite e i risultati possono essere poco chiari e generare falsi positivi. Per ulteriori informazioni, consulta Analisi del codice JSON.

Testa la logica

Una regola viene attivata quando la relativa condizione di corrispondenza restituisce true; ad esempio, la condizione di corrispondenza origin.region_code == 'AU' restituisce true se il codice regione della richiesta è AU. Se una regola con priorità più elevata restituisce true, l'azione in una regola con priorità inferiore viene ignorata. Nell'esempio seguente, immagina di voler creare un criterio di sicurezza per bloccare gli utenti della regione AU, ad eccezione del traffico all'interno dell'intervallo di indirizzi IP 10.10.10.0/24. Considera la seguente norma di sicurezza con due regole:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2

In questo esempio, Rule1 consente il traffico proveniente dall'intervallo di indirizzi IP 10.10.10.0/24. Poiché Rule1 è la regola con priorità più alta, questo tipo di traffico viene consentito prima di essere valutato in base a Rule2, il che significa che Google Cloud Armor non lo valuta in base a Rule2 (o a qualsiasi altra regola rimanente).

Quando crei i criteri di Google Cloud Armor, testa la logica delle regole per assicurarti di ottenere il comportamento previsto. A tale scopo, ti consigliamo di generare traffico sintetico per capire quali regole bloccano il traffico e verificare che i risultati siano coerenti con le decisioni di progettazione delle regole. Se non hai la certezza di come una richiesta potrebbe essere gestita dal sistema, utilizza la modalità di anteprima per vedere quale regola corrisponde alla richiesta.

Identifica gli indirizzi IP di origine degli scanner

Gli scanner di sicurezza possono trovarsi all'interno o all'esterno di Google. Se vuoi una valutazione esterna e non filtrata della tua applicazione, puoi consentire esplicitamente il traffico in base all'indirizzo IP (o a un altro token) prima di valutarlo in base ad altre regole.

Raggruppare e ordinare le regole nel criterio di sicurezza

Le tue applicazioni potrebbero servire sottoinsiemi diversi di clienti. Nel seguente esempio, vuoi negare il traffico da determinate aree geografiche o intervalli IP e, pertanto, configuri la prima regola nel tuo criterio per negare questo traffico. Inoltre, vuoi consentire esplicitamente a un determinato traffico di entrare nell'applicazione senza che venga elaborato dal criterio di sicurezza. Per questo esempio, consigliamo la seguente struttura di priorità delle regole, dalla più alta alla più bassa:

  1. Regole di rifiuto esplicite (ASN, regione, intervalli IP)
  2. Regole di autorizzazione esplicite attendibili (scanner, sistemi attendibili: da usare con estrema cautela)
  3. Regole di sicurezza (OWASP, regole personalizzate)
  4. Regole di autorizzazione esplicite (ASN, presenza di valore dell'intestazione, intervallo IP)
  5. Regole di rifiuto predefinite

Utilizzare reCAPTCHA per la gestione dei bot

Google Cloud Armor si integra con reCAPTCHA di Google per il rilevamento dei bot a livello di WAF. In questa integrazione, reCAPTCHA genera i token reCAPTCHA e Google Cloud Armor esegue la procedura di valutazione dei token anziché reCAPTCHA. In questo modo, riduci il carico sull'origine, potenzialmente i costi e sposti i controlli di sicurezza più vicino all'utente finale rispetto ai backend. Per saperne di più, consulta la panoramica della gestione dei bot.

Impostare le soglie di limitazione di frequenza

Il limite di velocità è una funzionalità flessibile e preziosa per prevenire gli abusi e mitigare le minacce ad alto volume come il credential stuffing o gli attacchi DDoS L7. Quando implementi limitazione di frequenza per la prima volta, è importante scegliere una soglia appropriata per la tua applicazione. Ti consigliamo di iniziare con l'applicazione in modalità di anteprima. Man mano che analizzi e comprendi il profilo del traffico, puoi modificare i parametri di limitazione di frequenza. Inoltre, è importante considerare la priorità assegnata alla regola di limitazione di frequenza. Il traffico potrebbe essere consentito o negato esplicitamente da una regola con priorità più alta prima di essere valutato in base alla regola di limitazione di frequenza.

Ottimizzazione delle regole

Le applicazioni web potrebbero consentire richieste che sembrano essere attacchi e potrebbero consentire o addirittura richiedere agli utenti di inviare richieste corrispondenti alle firme nelle regole WAF predefinite. È fondamentale convalidare le regole di Google Cloud Armor in base all'applicazione e risolvere eventuali risultati che potrebbero non essere pertinenti per l'applicazione prima di promuovere la regola disattivando la modalità di anteprima in un'applicazione di produzione. Le sezioni seguenti contengono best practice e consigli per ottimizzare le regole WAF preconfigurate.

Scegli il livello di sensibilità della regola WAF preconfigurata

Quando implementi una delle regole WAF preconfigurate, puoi scegliere un livello di sensibilità appropriato in base ai tuoi requisiti di sicurezza e alle tempistiche. Ti consigliamo di iniziare con un livello di sensibilità pari a 1 per la maggior parte delle applicazioni che devono soddisfare i requisiti di sicurezza della tua organizzazione. Le regole configurate per la sensibilità 1 utilizzano firme ad alta fedeltà e riducono il potenziale rumore della regola. Le firme associate a sensibilità più elevate potrebbero rilevare e prevenire un insieme più ampio di tentativi di exploit, a spese di potenziali interferenze per alcune applicazioni protette. Tuttavia, i carichi di lavoro soggetti a requisiti di sicurezza più rigorosi potrebbero preferire il livello di sensibilità più elevato. Per questi casi d'uso, potrebbe esserci una grande quantità di rumore o risultati irrilevanti, che devi risolvere utilizzando l'ottimizzazione prima che il criterio di sicurezza venga implementato in produzione.

Attiva il logging dettagliato

Se hai bisogno di ulteriori informazioni sugli attributi e sui payload delle richieste che attivano una determinata regola WAF, attiva la registrazione dettagliata. La registrazione dettagliata fornisce dettagli sulle richieste che attivano regole specifiche, incluso uno snippet della parte in violazione della richiesta, utile per la risoluzione dei problemi e la regolazione di Google Cloud Armor. Poiché il logging dettagliato può causare il logging dei contenuti delle richieste degli utenti finali in Cloud Logging, è possibile che tu accumuli PII degli utenti finali nei log. Di conseguenza, non consigliamo di eseguire carichi di lavoro di produzione con la registrazione dettagliata abilitata per periodi di tempo prolungati.

Utilizzare regole stabili o canarie

Esistono due tipi di regole WAF preconfigurate di Google Cloud Armor: stabili e canary. Quando vengono aggiunte nuove regole all'attuale ModSecurity Core Rule Set (CRS), le pubblichiamo nelle build delle regole canarie prima di pubblicarle automaticamente nelle build delle regole stabili. Ti consigliamo di implementare le regole canary in un ambiente di test per poter vedere gli effetti di eventuali modifiche e aggiunte nel tuo ambiente. Puoi controllare i nomi delle regole nella pagina Ottimizzazione delle regole WAF di Google Cloud Armor per verificare se la build canary è sincronizzata con la build stabile.

Logging e monitoraggio

Le sezioni seguenti contengono best practice e consigli per la configurazione del logging e del monitoraggio.

Utilizzare Security Command Center

Google Cloud Armor si integra automaticamente con Security Command Center. Google Cloud Armor esporta diversi risultati in Security Command Center:

  • Picco di traffico consentito
  • Aumento del rapporto di rifiuto

Assicurati che il personale addetto alla sicurezza web esamini questi risultati.

Scegli una frequenza di campionamento di Cloud Logging

I log per richiesta di Google Cloud Armor utilizzano il bilanciatore del carico delle applicazioni esterno globale o l'infrastruttura di registrazione del bilanciatore del carico delle applicazioni classico. Di conseguenza, la generazione dei log di Google Cloud Armor è soggetta alla frequenza di campionamento dei log configurata sul bilanciatore del carico. Ti consigliamo di mantenere la frequenza di campionamento su 1 quando ottimizzi e implementi attivamente Google Cloud Armor. Al termine della configurazione e dell'implementazione di Google Cloud Armor, consigliamo di mantenere attivo il logging completo delle richieste. Tuttavia, potresti preferire eseguire il downsampling a una frequenza inferiore. Sia il bilanciatore del carico delle applicazioni esterno globale sia il bilanciatore del carico delle applicazioni classico non attivano i log per impostazione predefinita, pertanto è importante attivare il logging manualmente.

Utilizzare la dashboard di Cloud Monitoring

È essenziale avere una visione chiara di cosa sta succedendo nella configurazione di Google Cloud Armor. Per semplificare questa operazione, puoi utilizzare la dashboard per la sicurezza. Inoltre, puoi esportare i log di Google Cloud Armor direttamente da Logging sulla tua piattaforma. Se utilizzi Adaptive Protection, è importante avere un percorso di riassegnazione per tutti gli avvisi di Adaptive Protection attivati.

Gestione generale

Di seguito sono riportate best practice e consigli aggiuntivi per la configurazione di Google Cloud Armor.

Configurare controllo dell'accesso di Identity and Access Management

In conformità con le best practice generali di Google Cloud IAM, assicurati che le persone giuste abbiano accesso a Google Cloud Armor. Il ruolo Amministratore sicurezza Compute è necessario per configurare, modificare, aggiornare ed eliminare i criteri di sicurezza di Google Cloud Armor. Inoltre, è necessario il ruolo Amministratore rete Compute o l'autorizzazione compute.backendServices.setSecurityPolicy per collegare un criterio di sicurezza di Google Cloud Armor a un servizio di backend.

Riduci al minimo il numero di criteri

Un criterio Google Cloud Armor può essere riutilizzato in più servizi di backend. Ti consigliamo di disporre di un insieme coerente di criteri di sicurezza riutilizzabili.

Utilizza Terraform

Per assicurarti che le configurazioni possano essere facilmente annullate e riprodotte tra i progetti, ti consigliamo di utilizzare Terraform. Google Cloud Armor dispone di un'integrazione completa di Terraform per le funzionalità GA.

Configurare Google Cloud Armor con Google Kubernetes Engine

Se utilizzi GKE, devi configurare Google Cloud Armor e altre funzionalità di ingresso tramite i parametri BackendConfig. Ti consigliamo di non configurare manualmente un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico come punto di ingresso. Per ulteriori informazioni sulla configurazione di Google Cloud Armor con GKE, consulta Configurazione delle funzionalità di Ingress.