Questa pagina fornisce le best practice per ottimizzare e regolare i deployment di Google Cloud Armor.
Il deployment di Google Cloud Armor viene eseguito con il bilanciatore del carico delle applicazioni esterno globale, con l'Application Load Balancer classico o con il bilanciatore del carico di rete 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 da te stabilite.
Creazione di regole e criteri di sicurezza
Le sezioni seguenti contengono best practice e consigli per nuovi criteri e regole di sicurezza.
Fornisci descrizioni delle regole
Utilizza le descrizioni delle regole per fornire un contesto aggiuntivo sul motivo della creazione di ogni regola e sulla sua funzione prevista. Il campo description è limitato a 64 caratteri, quindi i riferimenti ai database di gestione della configurazione o ad altri repository sono il modo più efficiente per acquisire il contesto.
Considera la spaziatura delle priorità
Quando configuri per la prima volta le regole, lascia un intervallo di almeno 10 tra ogni valore di priorità della regola. Ad esempio, le prime due regole in 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 dei criteri di sicurezza, incluse le firme OWASP (Open Web Application Security Project), possono avere effetti imprevedibili sull'applicazione. Utilizza la modalità di anteprima per valutare se l'introduzione di una regola avrà un impatto negativo sul traffico di produzione.
Abilita Google Cloud Armor Adaptive Protection
Abilita Adaptive Protection per una protezione aggiuntiva delle applicazioni. Adaptive Protection monitora il traffico e, se necessario, consiglia nuove regole per i criteri di sicurezza. Inoltre, ti consigliamo di implementare un criterio di avviso per assicurarti che le persone giuste vengano avvisate dei potenziali attacchi. Adaptive Protection è più adatto per la protezione volumetrica. Gli attacchi non volumetrici potrebbero non attivare Adaptive Protection.
Abilita l'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 corpi POST per le regole WAF preconfigurate e i risultati potrebbero essere "rumorosi" e generare falsi positivi. Per ulteriori informazioni, consulta la pagina relativa all'analisi JSON.
Testare la logica
Una regola viene attivata quando la relativa condizione di corrispondenza ha valore true; ad esempio, la
condizione di corrispondenza origin.region_code == 'AU' restituisce true se il codice
regione della richiesta è AU. Se una regola di priorità più alta restituisce true, l'azione in una regola con priorità inferiore viene ignorata. Nell'esempio seguente, supponiamo di voler creare un criterio di sicurezza per bloccare gli utenti che si trovano nell'area geografica AU, ad eccezione del traffico compreso nell'intervallo di indirizzi IP 10.10.10.0/24. Considera
il seguente criterio 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 che ha origine dall'intervallo di indirizzi IP 10.10.10.0/24. Poiché Rule1 è la regola di priorità più alta, questo tipo di traffico è consentito prima di essere valutato in base a Rule2, il che significa che Google Cloud Armor non lo valuta in base a Rule2 (o qualsiasi altra regola rimanente).
Quando crei criteri di Google Cloud Armor, verifica 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 hai dubbi sul flusso di una richiesta nel sistema, utilizza la modalità di anteprima per vedere quale regola corrisponde alla richiesta.
Identifica gli indirizzi IP di origine dei tuoi scanner
I tuoi scanner di sicurezza possono essere posizionati 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 contro qualsiasi altra regola.
Raggruppa e ordina le regole nel criterio di sicurezza
Le tue applicazioni potrebbero gestire sottoinsiemi diversi di clienti. Nell'esempio seguente, vuoi negare il traffico da determinate aree geografiche o intervalli IP e, di conseguenza, configurerai la prima regola nel criterio per negare questo traffico. Inoltre, vuoi consentire esplicitamente il traffico nell'applicazione senza che il criterio di sicurezza la elabori. Per questo esempio, consigliamo la seguente struttura di priorità delle regole, dalla priorità massima alla minima:
- Regole di negazione esplicite (ASN, regione, intervalli IP)
- Regole di autorizzazione esplicite attendibili (scanner, sistemi attendibili, utilizzare con estrema cautela)
- Regole di sicurezza (OWASP, regole personalizzate)
- Regole di autorizzazione esplicite (ASN, presenza di valore di intestazione, intervallo IP)
- Regole di negazione predefinite
Utilizzare reCAPTCHA Enterprise per la gestione dei bot
Google Cloud Armor si integra con reCAPTCHA Enterprise di Google per il rilevamento di bot a livello WAF. In questa integrazione, reCAPTCHA Enterprise genera i token reCAPTCHA e Google Cloud Armor esegue il processo di valutazione dei token anziché reCAPTCHA Enterprise. Questo riduce il carico di origine, riducendo potenzialmente i costi, e mette i controlli di sicurezza più vicini all'utente finale rispetto ai tuoi backend. Per ulteriori informazioni, consulta la panoramica della gestione dei bot.
Imposta soglie di limitazione di frequenza
La limitazione della frequenza è una funzionalità preziosa e flessibile per prevenire gli abusi e attenuare le minacce a volumi elevati come il credential stuffing o gli attacchi DDoS L7. Quando esegui il deployment della limitazione di frequenza per la prima volta, è importante scegliere una soglia significativa per la tua applicazione. Ti consigliamo di iniziare con l'applicazione forzata in modalità di anteprima. Man mano che analizzi e comprendi il profilo del traffico, puoi regolare i parametri 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 essere attacchi e potrebbero consentire, o persino richiedere, agli utenti di inviare richieste corrispondenti alle firme nelle regole WAF preconfigurate. È fondamentale convalidare le regole di Google Cloud Armor in base alla tua applicazione e risolvere eventuali risultati che potrebbero non essere pertinenti per la tua applicazione prima di promuovere la regola disattivando la modalità di anteprima su un'applicazione di produzione. Le seguenti sezioni contengono best practice e suggerimenti per l'ottimizzazione delle regole WAF preconfigurate.
Scegli il livello di sensibilità delle regole WAF preconfigurate
Quando implementi una qualsiasi delle regole WAF preconfigurate, puoi scegliere un livello di sensibilità appropriato in base ai requisiti e alle tempistiche di sicurezza. 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 rumore potenziale proveniente dalla regola. Le firme associate a sensibilità più elevate potrebbero rilevare e impedire un insieme più ampio di tentativi di exploit, a scapito del potenziale rumore 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 entri in produzione.
Attiva logging dettagliato
Se hai bisogno di ulteriori informazioni su quali attributi della richiesta e payload attivano una determinata regola WAF, abilita il logging dettagliato. Il logging dettagliato fornisce dettagli delle richieste che attivano determinate regole, tra cui uno snippet della parte offensiva della richiesta, utile per la risoluzione dei problemi e l'ottimizzazione di Google Cloud Armor. Poiché il logging dettagliato può causare la registrazione dei contenuti delle richieste dell'utente finale in Cloud Logging, è possibile che tu accumuli PII degli utenti finali nei tuoi log. Di conseguenza, sconsigliamo di eseguire carichi di lavoro di produzione con il logging dettagliato abilitato per lunghi periodi di tempo.
Utilizzare regole stabili o canary
Esistono due tipi di regole WAF preconfigurate di Google Cloud Armor: stabile e canary. Quando vengono aggiunte nuove regole all'attuale set di regole di base ModSecurity (CRS), le pubblichiamo nelle build di regole canary prima di pubblicarle automaticamente nelle build di regole stabili. Ti consigliamo di eseguire il deployment delle 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 suggerimenti 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 i diversi risultati in Security Command Center:
- Picco di traffico consentito
- Aumento del rapporto di negazione
Accertati 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 l'Application Load Balancer esterno globale o l'infrastruttura di logging del bilanciatore del carico delle applicazioni classico. Di conseguenza, la generazione di 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 l'ottimizzazione e l'implementazione di Google Cloud Armor, ti consigliamo di mantenere attivato il logging completo delle richieste; tuttavia, ti consigliamo di eseguire il downgrade a una frequenza inferiore. Sia il bilanciatore del carico delle applicazioni esterno globale sia il bilanciatore del carico delle applicazioni classico non abilitano i log per impostazione predefinita, perciò è importante abilitare il logging manualmente.
Utilizzo della dashboard di Cloud Monitoring
Avere una visione chiara di cosa sta succedendo 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 nella tua piattaforma. Se usi Adaptive Protection, è importante avere un percorso di riassegnazione per tutti gli avvisi di Adaptive Protection attivati.
Gestione generale
Di seguito sono riportati ulteriori best practice e suggerimenti per la configurazione di Google Cloud Armor.
Configurare controllo dell'accesso per 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. Per configurare, modificare, aggiornare ed eliminare i criteri di sicurezza di Google Cloud Armor è necessario il ruolo Amministratore sicurezza Compute. Inoltre, per collegare un criterio di sicurezza di Google Cloud Armor a un servizio di backend è necessario il ruolo Amministratore rete Compute o l'autorizzazione compute.backendServices.setSecurityPolicy.
Riduci al minimo il numero di criteri
Un criterio di Google Cloud Armor può essere riutilizzato in più servizi di backend. Ti consigliamo di adottare un insieme coerente di criteri di sicurezza riutilizzabili.
Utilizza Terraform
Per garantire che il rollback delle configurazioni sia semplice e che possa essere riprodotto in tutti i progetti, consigliamo di utilizzare Terraform. Google Cloud Armor integra l'integrazione Terraform per le funzionalità GA.
Configura Google Cloud Armor con Google Kubernetes Engine
Se utilizzi GKE, devi configurare Google Cloud Armor e altre funzionalità in entrata 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 per fungere da punto in entrata. Per ulteriori informazioni sulla configurazione di Google Cloud Armor con GKE, consulta Configurazione delle funzionalità in entrata.