Best practice per Google Cloud Armor

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

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 seguenti sezioni 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 per cui è stata creata ogni regola e sulla sua funzione prevista. La description ha un limite di 64 caratteri, quindi i riferimenti di gestione delle configurazioni o altri repository sono i più efficienti per catturare 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 in un criterio di sicurezza può avere priorità 20 e 30. In questo modo puoi inserire più regole quando ne hai bisogno che li rappresentano. Inoltre, 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.

Abilita Adaptive Protection di Google Cloud Armor

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. Nella Inoltre, ti consigliamo di inserire criterio di avviso in garantire che vengano avvisate le persone giuste su potenziali attacchi informatici. Adaptive Protection è ideale per la protezione volumetrica. Attacchi che non sono 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 abiliti l'analisi JSON, Google Cloud Armor non analizza il contenuto JSON dei corpi POST per regole WAF preconfigurate e i risultati possono essere rumorosi e generare positivi. Per ulteriori informazioni, consulta Analisi di JSON.

Testa la logica

Una regola viene attivata quando la sua condizione di corrispondenza è true; ad esempio la condizione di corrispondenza origin.region_code == 'AU' restituisce true se la regione il codice 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 dal AU regione, tranne il traffico nell'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 che ha origine dall'indirizzo IP intervallo 10.10.10.0/24. Poiché Rule1 è la regola di priorità più alta, il traffico è consentito prima della valutazione rispetto a Rule2, il che significa che Google Cloud Armor non la valuta rispetto a Rule2 (o qualsiasi altro le altre regole).

Quando crei i criteri di 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 per verificare che i risultati siano coerenti con le decisioni relative alla struttura delle regole. Se non hai la certezza del flusso di una richiesta attraverso il sistema, usa 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 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.

Raggruppa e ordina 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, consiglia la seguente struttura di priorità delle regole, dalla massima priorità a priorità minima:

  1. Regole di negazione 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 negazione predefinite

Utilizzare reCAPTCHA per la gestione dei bot

Google Cloud Armor si integra con reCAPTCHA per i bot di Google 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. Questo riduce l'origine ridurre il carico di lavoro, riducendo potenzialmente i costi e avvicinando i controlli di sicurezza e l'utente finale rispetto ai backend. Per saperne di più, consulta la panoramica della gestione dei bot.

Imposta soglie di limitazione di frequenza

La limitazione di frequenza è una funzionalità flessibile e preziosa per prevenire comportamenti illeciti e mitigazione delle minacce a volumi elevati come credential stuffing o attacchi DDoS L7. Quando implementi il limite 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 regolare i parametri di limitazione della frequenza. Inoltre, è importante considerare la priorità che assegni alla regola di limitazione di frequenza. Il traffico potrebbe essere consentito o negato in modo esplicito da una regola con priorità più elevata prima viene valutato in base alla regola di limitazione di frequenza.

Ottimizzazione delle regole

Le applicazioni web potrebbero consentire richieste che sembrano essere attacchi e potrebbero consentono, o addirittura richiedono, che gli utenti inviino richieste corrispondenti alle firme regole WAF preconfigurate. È fondamentale convalidare i tuoi Google Cloud Armor regola in base alla tua applicazione e gestisci eventuali risultati che potrebbero non essere pertinenti per la tua applicazione prima di promuovere la regola tramite la disattivazione della modalità di anteprima su un'applicazione di produzione. Le seguenti sezioni contengono best practice e consigli per l'ottimizzazione del modello WAF preconfigurato le regole del caso.

Scegli il livello di sensibilità delle regole WAF preconfigurato

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à di 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 sono soggetti a misure di sicurezza più rigide, 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. Logging dettagliato fornisce dettagli sulle richieste che attivano regole particolari, tra cui della parte in questione, ovvero utili per la risoluzione dei problemi e l'ottimizzazione di Google Cloud Armor. Poiché il livello di dettaglio il logging può far sì che i contenuti delle richieste degli utenti finali vengano registrati in Cloud Logging, è possibile che tu accumuli PII degli utenti finali nei tuoi 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: stabile e canary. Quando vengono aggiunte nuove regole all'attuale set di regole ModSecurity Core (CRS), le pubblichiamo nelle build delle regole canary prima di pubblicarle automaticamente nelle build di regole stabili. Ti consigliamo di implementare le regole canarie 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 Tuning delle regole WAF di Google Cloud Armor per verificare se la build canary è sincronizzata con la build stabile.

Logging e monitoraggio

Le seguenti sezioni contengono best practice e consigli per 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 tasso 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 logging del bilanciatore del carico delle applicazioni classico dell'infrastruttura. 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 conservare la frequenza di campionamento a 1 quando l'ottimizzazione e l'implementazione Google Cloud Armor. Al termine dell'ottimizzazione e dell'implementazione di Google Cloud Armor, ti consigliamo di mantenere attivato il logging completo delle richieste. ma preferire una riduzione del campionamento a una velocità inferiore. Entrambi i campi Il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni classico non abilita i log per impostazione predefinita, quindi è importante abilitare 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 Avvisi di Adaptive Protection attivati.

Gestione generale

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

Configura il controllo dell'accesso di Identity and Access Management

In conformità con le best practice generali di Google Cloud IAM, garantire che le persone giuste abbiano accesso a Google Cloud Armor. Il ruolo Amministratore della 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 Ingress 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 Google Cloud Armor con GKE, consulta Configurazione delle funzionalità in entrata.