Best practice per Cloud Armor

Questa pagina fornisce le best practice per il perfezionamento e l'ottimizzazione dei deployment di Google Cloud Armor.

Il deployment di Cloud Armor viene eseguito con bilanciatore del carico delle applicazioni esterno globale, bilanciatore del carico delle applicazioni classico o bilanciatore del carico di rete proxy esterno. Quando esegui il deployment di Cloud Armor, colleghi una policy di sicurezza al servizio di backend del bilanciatore del carico che vuoi proteggere. Una policy di sicurezza è costituita da una raccolta di regole preconfigurate e personalizzate determinate da te.

Per configurare una policy di Cloud Armor che si applichi automaticamente a tutti i progetti della tua organizzazione e consenta ai singoli progetti di aggiungere regole specifiche, consulta la guida alla gestione di Cloud Armor utilizzando vincoli personalizzati. Questo approccio fornisce un modo centralizzato per applicare le policy di sicurezza in tutta l'organizzazione, mantenendo al contempo la flessibilità per le esigenze dei singoli progetti.

Creazione di policy e regole di sicurezza

Le sezioni seguenti contengono best practice e consigli per le nuove policy e regole di sicurezza.

Fornisci le descrizioni delle regole

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

Considera la spaziatura per le priorità

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

Usa la modalità di anteprima

Le regole delle policy di sicurezza, incluse le firme OWASP (Open Web Application Security Project), 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 di produzione.

Attiva Google Cloud Armor Adaptive Protection

Attiva Adaptive Protection per una protezione aggiuntiva delle tue applicazioni. Adaptive Protection monitora il traffico e (se necessario) suggerisce nuove regole per le tue policy di sicurezza. Inoltre, ti consigliamo di implementare una policy di avviso per assicurarti che le persone giuste vengano avvisate di potenziali attacchi. Adaptive Protection è più adatto alla protezione volumetrica. Gli attacchi non volumetrici potrebbero non attivare Adaptive Protection.

Attiva l'analisi JSON

Se la tua applicazione invia contenuti JSON nel corpo della richiesta, assicurati di attivare l'analisi JSON. Se non attivi l'analisi JSON, Cloud Armor non analizza i contenuti JSON dei corpi delle richieste per le regole WAF preconfigurate e i risultati possono essere irrilevanti e generare falsi positivi. Per saperne di più, consulta Analisi JSON.

Testa la tua logica

Una regola viene attivata quando la sua condizione di corrispondenza restituisce il valore true. Ad esempio, la condizione di corrispondenza origin.region_code == 'AU' restituisce il valore true se il codice regione della richiesta è AU. Se una regola con priorità più alta restituisce il valore true, l'azione in una regola con priorità più bassa viene ignorata.

Nell'esempio seguente, supponiamo che tu voglia creare una policy 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 le seguenti policy 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 traffico è consentito prima di essere valutato rispetto a Rule2, il che significa che Cloud Armor non lo valuta rispetto a Rule2 (o a qualsiasi altra regola rimanente).

Per ottenere un'eccezione simile all'interno di una singola regola, puoi combinare le condizioni di corrispondenza utilizzando gli operatori logici. È importante notare che questo approccio si differenzia dall'esempio con due regole per il modo in cui vengono valutate le regole successive. Ad esempio, la seguente espressione utilizza una singola regola che nega il traffico da AU a meno che non provenga dall'intervallo IP specifico 10.10.10.0/24:

expr: origin.region_code == 'AU' && !inIpRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1

Questa condizione restituisce il valore true (e attiva un'azione di negazione) solo se la regione è AU e l'indirizzo IP non rientra nell'intervallo 10.10.10.0/24.

Quando crei policy di Cloud Armor, testa la logica delle regole per assicurarti di ottenere il comportamento previsto. Per farlo, 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 possa passare attraverso il 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 a qualsiasi altra regola.

Raggruppa e ordina le regole nella policy di sicurezza

Le tue applicazioni potrebbero servire sottoinsiemi diversi dei tuoi clienti. Nell'esempio seguente, vuoi negare il traffico proveniente da determinate aree geografiche o intervalli IP e pertanto configuri la prima regola nella tua policy per negare quel traffico. Inoltre, vuoi consentire esplicitamente a parte del traffico di accedere all'applicazione senza che venga elaborato dalla policy di sicurezza. Per questo esempio, consigliamo la seguente struttura di priorità delle regole, dalla priorità più alta a quella più bassa:

Regole di negazione esplicita (ASN, regione, intervalli IP)
Regole di autorizzazione esplicita attendibili (scanner, sistemi attendibili, da utilizzare con estrema cautela)
Regole di sicurezza (OWASP, regole personalizzate)
Regole di autorizzazione esplicita (ASN, presenza di un valore dell'intestazione, intervallo IP)
Regole di negazione predefinite

Utilizza reCAPTCHA per la gestione dei bot

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 Cloud Armor, anziché reCAPTCHA, esegue il processo di valutazione dei token. Ciò riduce il carico sull'origine, potenzialmente diminuendo i costi, e avvicina i controlli di sicurezza all'utente finale rispetto ai tuoi backend. Per saperne di più, consulta la panoramica della gestione dei bot.

Imposta le soglie della limitazione di frequenza

La limitazione di frequenza è una funzionalità flessibile e preziosa per prevenire abusi e mitigare minacce con volumi elevati come il credential stuffing o gli attacchi DDoS L7. Quando esegui il deployment iniziale della limitazione di frequenza, è importante scegliere una soglia che abbia senso 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à che assegni alla regola di limitazione di frequenza. Il traffico potrebbe essere esplicitamente consentito o negato 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 attacchi e potrebbero permettere o persino richiedere agli utenti di inviare richieste che corrispondono alle firme nelle regole WAF preconfigurate. È fondamentale convalidare le regole di Cloud Armor rispetto 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à delle regole WAF preconfigurate

Quando implementi una delle regole WAF preconfigurate, puoi scegliere un livello di sensibilità appropriato in base ai tuoi requisiti di sicurezza e alle tue tempistiche. Ti consigliamo di iniziare con un livello di sensibilità 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ù alte potrebbero rilevare e impedire un insieme più ampio di tentativi di exploit, a scapito del potenziale rumore per alcune applicazioni protette. Tuttavia, per i workload soggetti a requisiti di sicurezza più rigorosi può essere preferibile il livello di sensibilità massimo. Per questi casi d'uso, potrebbe esserci una grande quantità di rumore o di risultati irrilevanti, che devi risolvere utilizzando l'ottimizzazione prima che le policy di sicurezza vadano in produzione.

Attiva il logging dettagliato

Se hai bisogno di ulteriori informazioni su quali attributi e payload delle richieste attivano una determinata regola WAF, attiva il logging dettagliato. Il logging dettagliato fornisce i dettagli delle richieste che attivano particolari regole, incluso un snippet della parte incriminata della richiesta, utile per la risoluzione dei problemi e l'ottimizzazione di Cloud Armor. Poiché il logging dettagliato può causare la registrazione dei contenuti delle richieste degli utenti finali in Cloud Logging, esiste la possibilità di accumulare PII degli utenti finali nei log. Di conseguenza, sconsigliamo di eseguire workload di produzione con logging dettagliato attivato per lunghi periodi di tempo.

Utilizza regole stabili o canary

Esistono due tipi di regole WAF preconfigurate di Cloud Armor: stabili e canary. Quando vengono aggiunte nuove regole al core rule set (CRS) OWASP corrente, le pubblichiamo nelle build delle regole canary prima di pubblicarle automaticamente nelle build delle regole stabili. Ti consigliamo di eseguire il deployment delle regole canary in un ambiente di test in modo da poter osservare gli effetti nel tuo ambiente di eventuali modifiche e aggiunte. Puoi controllare i nomi delle regole nella pagina Ottimizza le regole WAF di 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 configurare il logging e il monitoraggio.

Utilizza Security Command Center

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

Picco di traffico consentito
Aumento del rapporto di negazioni

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

Scegli una frequenza di campionamento di Cloud Logging

I log per richiesta di Cloud Armor utilizzano l'infrastruttura di logging del bilanciatore del carico delle applicazioni esterno globale o del bilanciatore del carico delle applicazioni classico. Di conseguenza, la generazione dei log di Cloud Armor è soggetta alla frequenza di campionamento dei log configurata sul bilanciatore del carico. Ti consigliamo di mantenere la frequenza di campionamento a 1 quando esegui attivamente l'ottimizzazione e l'implementazione di Cloud Armor. Dopo aver completato l'ottimizzazione e l'implementazione di Cloud Armor, ti consigliamo di mantenere attivo il logging completo delle richieste. Tuttavia, potresti preferire una riduzione del campionamento a una frequenza inferiore. Sia il bilanciatore del carico delle applicazioni esterno globale che il bilanciatore del carico delle applicazioni classico non abilitano i log per impostazione predefinita, pertanto è importante attivare il logging manualmente.

Nota: i log di Adaptive Protection vengono visualizzati nella console Google Cloud nella risorsa network_security_policy, non nel bilanciatore del carico delle applicazioni esterno globale o nel bilanciatore del carico delle applicazioni classico.

Utilizza la dashboard di Cloud Monitoring

È essenziale avere una visione chiara di ciò che sta accadendo nella configurazione di Cloud Armor. Per ottenerla più facilmente, puoi utilizzare la dashboard per la sicurezza. Inoltre, puoi esportare i log di Cloud Armor direttamente da Logging alla tua piattaforma. Se utilizzi Adaptive Protection, è importante disporre di un percorso di riassegnazione per tutti gli avvisi di Adaptive Protection attivati.

Gestione generale

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

Configura il controllo dell'accesso di Identity and Access Management

In conformità alle best practice IAM generali di Google Cloud , assicurati che le persone giuste abbiano accesso a Cloud Armor. Per configurare, modificare, aggiornare ed eliminare le policy di sicurezza di Cloud Armor è necessario il ruolo Compute Security Admin. Inoltre, per collegare una policy di sicurezza di Cloud Armor a un servizio di backend è necessario avere il ruolo Compute Network Admin o l'autorizzazione compute.backendServices.setSecurityPolicy.

Riduci al minimo il numero di policy

Una policy di Cloud Armor può essere riutilizzata per più servizi di backend. Ti consigliamo di avere un insieme coerente di policy di sicurezza riutilizzabili.

Utilizza Terraform

Per facilitare il rollback delle configurazioni, oltre alla riproduzione tra progetti diversi, ti consigliamo di utilizzare Terraform. Cloud Armor ha un'integrazione completa di Terraform per le funzionalità GA.

Configura Cloud Armor con Google Kubernetes Engine

Se utilizzi Google Kubernetes Engine (GKE), devi configurare Cloud Armor e altre funzionalità Ingress tramite i parametri BackendConfig. Ti consigliamo di evitare di configurare manualmente un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico per fungere da punto di entrata. Per saperne di più sulla configurazione di Cloud Armor con GKE, consulta Configura le funzionalità Ingress.

Dopo aver configurato una policy di sicurezza di Cloud Armor, puoi anche utilizzare Kubernetes Gateway per attivarla con GKE. Assicurati di creare una policy di sicurezza del backend di Cloud Armor prima di fare riferimento alla policy nella risorsa della tua policy GCPBackendPolicy. Se stai attivando un gateway regionale, devi creare una policy di sicurezza del backend Cloud Armor regionale.