Best practice per Cloud Armor

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

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 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 una policy Cloud Armor che si applichi automaticamente a tutti i progetti della tua organizzazione e che 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 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 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.

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, 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 è 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).

Quando crei criteri 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

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 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 frammento della parte incriminata della richiesta, utile per la risoluzione dei problemi e la messa a punto 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, 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 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 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.

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 la configurazione e l'implementazione di Cloud Armor. Dopo aver completato la configurazione e l'implementazione di 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

È essenziale avere una visione chiara di ciò che accade nella configurazione di Cloud Armor. Per semplificare questa operazione, puoi utilizzare la dashboard per la sicurezza. Inoltre, puoi esportare i log di Cloud Armor direttamente da Logging alla tua piattaforma.

Gestione generale

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

Configura controllo dell'accesso di Identity and Access Management

In conformità alle best practice Trusted Cloud IAM generali, assicurati che le persone giuste abbiano accesso a Cloud Armor. Per configurare, modificare, aggiornare ed eliminare i criteri di sicurezza di Cloud Armor è necessario il ruolo Amministratore sicurezza di Compute. Inoltre, per collegare un criterio di sicurezza 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

Una policy Cloud Armor può essere riutilizzata 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. Cloud Armor ha un'integrazione completa di Terraform per le funzionalità GA.