Best practice per Google Cloud Armor

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

Google Cloud Armor viene 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 preconfigurate e personalizzate che determini.

Per configurare un criterio Google 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 norme di sicurezza in tutta l'organizzazione, mantenendo la flessibilità per le esigenze dei singoli progetti.

Creazione di criteri e regole di sicurezza

Le sezioni seguenti contengono best practice e consigli per le nuove norme 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 descrizione è limitato a 64 caratteri, pertanto i riferimenti a database di gestione della configurazione o altri repository sono il modo più efficiente per acquisire il contesto.

Considerare la spaziatura prioritaria

Quando configuri inizialmente le regole, lascia un intervallo di almeno 10 tra ogni valore di priorità della regola. Ad esempio, le prime due regole di un criterio 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.

Utilizzare la modalità di anteprima

Le regole delle norme 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 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) consiglia nuove regole per i tuoi criteri di sicurezza. Inoltre, ti consigliamo di implementare un'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.

Abilita analisi JSON

Se la tua applicazione invia contenuti JSON nel corpo delle richieste POST, assicurati di abilitare l'analisi JSON. Se non abiliti l'analisi JSON, Google Cloud Armor non analizza i contenuti JSON dei corpi POST per le regole WAF preconfigurate e i risultati possono essere rumorosi e generare falsi positivi. Per ulteriori informazioni, vedi 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ù elevata restituisce il valore true, l'azione in una regola con priorità inferiore viene ignorata. Nell'esempio seguente, immagina di voler creare una norma 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 sulla 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 viene consentito prima di essere valutato rispetto a Rule2, il che significa che Google Cloud Armor non lo valuta rispetto a Rule2 (o a qualsiasi altra regola rimanente).

Quando crei criteri Google Cloud Armor, testa la logica delle regole per assicurarti di ottenere il comportamento previsto. A questo 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 sai come potrebbe fluire una richiesta nel sistema, utilizza la modalità di anteprima per vedere quale regola corrisponde alla richiesta.

Identificare 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.

Raggruppare e ordinare le regole nei criteri 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 del criterio per negare questo traffico. Inoltre, vuoi consentire esplicitamente a parte del traffico di accedere all'applicazione senza che venga elaborato dalle norme di sicurezza. Per questo esempio, consigliamo la seguente struttura di priorità delle regole, dalla priorità più elevata a quella più bassa:

1. Regole di negazione esplicite (ASN, regione, intervalli IP)
2. Regole di autorizzazione esplicite attendibili (scanner, sistemi attendibili - da utilizzare 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 negazione predefinite

Utilizzare reCAPTCHA per la gestione dei bot

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

Impostare le soglie di limitazione di frequenza

La limitazione della frequenza è una funzionalità flessibile e preziosa per prevenire abusi e mitigare minacce ad alto volume come il credential stuffing o gli attacchi DDoS a livello 7. Quando esegui il deploymentlimitazione di frequenzaa per la prima volta, è 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 regolalimitazione di frequenzaa. Il traffico potrebbe essere esplicitamente consentito o negato da una regola con priorità più elevata 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 consentire o persino richiedere agli utenti di inviare richieste che corrispondono alle firme nelle regole WAF preconfigurate. È fondamentale convalidare le regole di Google Cloud Armor rispetto all'applicazione e risolvere eventuali problemi 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 la messa a punto delle regole WAF preconfigurate.

Scegliere 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 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ù elevate potrebbero rilevare e prevenire un insieme più ampio di tentativi di exploit, a scapito di un potenziale rumore per alcune applicazioni protette. Tuttavia, i workload soggetti a requisiti di sicurezza più rigorosi potrebbero preferire il livello di sensibilità più alto. Per questi casi d'uso, potrebbe esserci una grande quantità di rumore o risultati irrilevanti, che devi risolvere utilizzando l'ottimizzazione prima che i criteri di sicurezza vengano messi in produzione.

Attiva logging dettagliato

Se hai bisogno di ulteriori informazioni su quali attributi e payload delle richieste attivano una determinata regola WAF, attiva la registrazione dettagliata. La registrazione dettagliata fornisce i dettagli delle richieste che attivano regole specifiche, incluso un snippet della parte incriminata della richiesta, utile per la risoluzione dei problemi e la configurazione di Google 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, non consigliamo di eseguire carichi di lavoro di produzione con la registrazione dettagliata attivata per lunghi periodi di tempo.

Utilizzare regole stabili o canary

Esistono due tipi di regole WAF preconfigurate di Google Cloud Armor: stabili e canary. Quando vengono aggiunte nuove regole al set di regole di base OWASP (CRS) corrente, le pubblichiamo nelle build delle regole canary prima di pubblicarle automaticamente nelle build delle regole stabili. Ti consigliamo di implementare le regole canary in un ambiente di test in modo da 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 di logging e monitoraggio.

Utilizzare Security Command Center

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

• Picco di traffico consentito
• Aumento del rapporto di negazione

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 logging 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 esegui l'ottimizzazione e l'implementazione di Google Cloud Armor. Dopo aver completato la configurazione e l'implementazione di Google Cloud Armor, ti consigliamo di mantenere attivo il logging completo delle richieste; tuttavia, potresti preferire il sottocampionamento 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 che tu li abiliti manualmente.

Utilizzare la dashboard di Cloud Monitoring

Avere una visione chiara di ciò che accade nella configurazione di Google Cloud Armor è essenziale. Per semplificare questa operazione, puoi utilizzare la dashboard per la sicurezza. Inoltre, puoi esportare i log di Google 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 riportate best practice e consigli aggiuntivi per la configurazione di Google Cloud Armor.

Configura 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 sicurezzaa di Compute è necessario per configurare, modificare, aggiornare ed eliminare i criteri di sicurezza di Google Cloud Armor. Inoltre, per collegare una norma di sicurezza Google Cloud Armor a un servizio di backend è necessario il ruolo Amministratore di rete Compute o l'autorizzazione compute.backendServices.setSecurityPolicy.

Ridurre al minimo il numero di policy

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

Utilizza Terraform

Per garantire che le configurazioni possano essere facilmente ripristinate e riprodotte nei vari progetti, ti consigliamo di utilizzare Terraform. Google Cloud Armor offre l'integrazione completa di Terraform per le funzionalità GA.

Configurare Google Cloud Armor con Google Kubernetes Engine

Se utilizzi Google Kubernetes Engine (GKE), devi configurare Google Cloud Armor e altre funzionalità di 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 in modo che funga da punto di ingresso. Per saperne di più sulla configurazione di Google Cloud Armor con GKE, consulta Configurazione delle funzionalità di Ingress.

Dopo aver configurato un criterio di sicurezza Google Cloud Armor, puoi anche utilizzare Kubernetes Gateway per abilitarlo con GKE. Assicurati di creare un criterio di sicurezza di backend di Google Cloud Armor prima di fare riferimento al criterio nella risorsa dei criteri GCPBackendPolicy. Se abiliti un gateway regionale, devi creare un criterio di sicurezza di backend regionale di Google Cloud Armor.