Le policy di sicurezza gerarchiche sono una categoria di policy di sicurezza che estendono la portata del web application firewall (WAF) e della protezione DDoS di Cloud Armor oltre i singoli progetti. Sono collegate a livello di organizzazione, cartella o progetto. Sono diverse dalle policy di sicurezza a livello di servizio, che sono collegate direttamente ai servizi di backend o ai bucket di backend.
Quando configuri una policy di sicurezza gerarchica a livello di organizzazione o di cartella, i progetti ai livelli inferiori della gerarchia ereditano la policy di sicurezza. Questa ereditarietà ti consente di configurare le regole delle policy di sicurezza da applicare a tutti o parte dei progetti all'interno della tua organizzazione. In questo modo puoi ottenere l'applicazione centralizzata e coerente della sicurezza nel tuo intero ambiente Google Cloud .
Questa pagina spiega le differenze tra le policy di sicurezza gerarchiche e le policy di sicurezza a livello di servizio. Prima di procedere, leggi la panoramica delle policy di sicurezza per assicurarti di aver compreso come funzionano le policy di sicurezza. Inoltre, ti consigliamo di acquisire familiarità con la gerarchia delle risorse.
Casi d'uso
Nelle grandi organizzazioni, la gestione delle policy di sicurezza tra numerosi progetti può essere complessa e richiedere molto tempo. Le policy di sicurezza gerarchiche offrono i seguenti vantaggi per aiutarti ad affrontare queste sfide:
- Controllo centralizzato: consentono agli amministratori a livello di organizzazione e cartella di definire e applicare policy di sicurezza in più progetti.
- Coerenza: forniscono una security posture uniforme in tutta l'organizzazione, riducendo il rischio di errori di configurazione e lacune di sicurezza.
- Efficienza: semplificano il deployment di aggiornamenti della sicurezza e mitigazioni, come il blocco di intervalli di indirizzi IP specifici o la risoluzione di vulnerabilità critiche in un numero elevato di risorse contemporaneamente.
- Delega: consentono di delegare le responsabilità di sicurezza a team o reparti diversi applicando policy ai livelli appropriati della gerarchia.
Puoi applicare e combinare questi principi generali in base alle esigenze della tua organizzazione. Considera i seguenti esempi di casi d'uso:
- Blocco degli indirizzi IP a livello di organizzazione: puoi bloccare il traffico proveniente da intervalli di indirizzi IP dannosi noti in tutti i progetti della tua organizzazione.
- Limitazioni basate sull'area geografica: puoi limitare il traffico proveniente da regioni geografiche specifiche a livello di organizzazione o di cartella.
- Mitigazione delle CVE: puoi eseguire rapidamente il deployment delle regole WAF per mitigare le vulnerabilità critiche in più progetti.
- Applicazione della conformità: puoi far rispettare i requisiti normativi applicando policy di sicurezza coerenti in tutta l'organizzazione.
- Controllo dell'accesso granulare: puoi concedere a intervalli di indirizzi IP specifici o a determinate regioni geografiche l'accesso a tutte le risorse all'interno di una cartella specifica.
Funzionalità
Le policy di sicurezza gerarchiche supportano un sottoinsieme delle funzionalità supportate dalle policy di sicurezza a livello di servizio. La tabella seguente confronta le funzionalità di Cloud Armor che puoi utilizzare con le policy di sicurezza gerarchiche e le policy di sicurezza a livello di servizio:
| Tipo di frontend |
|
|
| Punto di collegamento (risorsa protetta) | Servizio di backend | Nodi della gerarchia delle risorse |
| Azioni regola |
|
|
| Indirizzo IP di origine | ||
| Area geografica di origine | ||
| ASN di origine | ||
| Gestione dei bot | (solo EXTERNAL_302 e aggiunta di parametri alle richieste) |
|
| Filtro di livello 7 | ||
| WAF | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| Adaptive Protection | ||
| Gruppi di indirizzi | ||
| Gruppi di indirizzi a livello di organizzazione | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| Logging delle richieste |
Come funzionano le policy di sicurezza gerarchiche
Una policy di sicurezza gerarchica viene creata a livello di un'organizzazione o una cartella, che sarà la risorsa proprietaria della policy. Dopo aver creato una policy di sicurezza gerarchica, le regole della policy di sicurezza non sono ancora applicate alle tue risorse.
A questo punto, associa la policy di sicurezza gerarchica a un'organizzazione, una cartella o un progetto, che può essere la stessa risorsa proprietaria della policy. Dopo aver associato una policy di sicurezza gerarchica a una risorsa, le regole della policy di sicurezza vengono applicate alle risorse protette in corrispondenza e al di sotto di quel nodo nella gerarchia delle risorse. Per aiutarti a decidere a quale risorsa collegare le tue policy di sicurezza gerarchiche, consulta il seguente elenco di casi d'uso di base per ogni risorsa:
- Organizzazione: considera le policy di sicurezza gerarchiche a livello di organizzazione come il tipo predefinito di policy di sicurezza gerarchica.
Queste policy dispongono di ampie autorizzazioni Identity and Access Management (IAM) e si applicano a tutti i nodi dell'organizzazione. Specifica queste risorse utilizzando il flag
--organizationdurante l'associazione. - Cartella: utilizza queste policy di sicurezza gerarchiche quando vuoi applicare le stesse regole delle policy di sicurezza a più progetti, ma non all'intera organizzazione. Specifica queste risorse utilizzando il flag
--folderdurante l'associazione. - Progetto: utilizza questo tipo di policy di sicurezza gerarchica quando devi applicare le stesse regole della policy di sicurezza a tutte le risorse di un progetto, ad esempio applicando una lista bloccata di indirizzi IP a più servizi di backend.
Specifica queste risorse utilizzando il flag
--projectdurante l'associazione. - A livello di servizio: utilizza policy di sicurezza a livello di servizio quando hai bisogno di regole delle policy di sicurezza uniche, diverse per ognuno dei tuoi servizi. Ogni policy di sicurezza a livello di servizio applica le proprie regole solo al servizio di backend a cui è collegata. Specifica queste risorse utilizzando il flag
--project-number.
Per ogni policy di sicurezza gerarchica, puoi utilizzare uno solo di questi flag. Per specificare gli altri flag, come --name o --type, puoi procedere come quando configuri una policy di sicurezza a livello di servizio. Consulta il seguente elenco per saperne di più sul funzionamento delle policy di sicurezza gerarchiche:
- Quando una policy di sicurezza gerarchica è associata a un nodo della gerarchia delle risorse, viene ereditata da tutte le risorse protette al di sotto di quel nodo nella gerarchia.
- Puoi visualizzare le policy di sicurezza che si applicano a ogni risorsa protetta in un progetto, in tutte le policy di sicurezza gerarchiche e a livello di servizio. Per maggiori informazioni, consulta Visualizza tutte le regole Cloud Armor effettive per una risorsa protetta.
- Puoi spostare le policy di sicurezza gerarchiche da un nodo della gerarchia delle risorse a un altro. Potresti farlo quando prevedi di riorganizzare la struttura delle cartelle.
- Quando elimini un nodo della gerarchia delle risorse, ad esempio una cartella o un progetto, la policy di sicurezza gerarchica collegata a quel nodo viene eliminata solo se l'hai creata in quel nodo della gerarchia delle risorse.
- Se hai creato la policy di sicurezza altrove e poi l'hai spostata sotto il nodo, non viene eliminata.
- Per evitare l'eliminazione accidentale delle policy di sicurezza gerarchiche, ti consigliamo di spostare tutte le policy di sicurezza gerarchiche che intendi conservare in un altro nodo della gerarchia delle risorse prima di eliminare il nodo esistente.
Ordine di valutazione delle regole
Cloud Armor valuta le policy di sicurezza nel seguente ordine:
- Policy di sicurezza gerarchiche a livello di organizzazione
- Policy di sicurezza gerarchiche a livello di cartella (a partire dalla cartella principale, per poi procedere con ogni sottocartella)
- Policy di sicurezza gerarchiche a livello di progetto
- Policy di sicurezza a livello di servizio
Questo ordine di valutazione delle regole significa che potresti avere una policy di sicurezza gerarchica con una priorità bassa che viene valutata prima di una policy di sicurezza a livello di servizio con una priorità alta. Valuta attentamente le regole delle policy di sicurezza con priorità elevata esistenti e considera cosa succede se Cloud Armor non valuta una richiesta consentita o negata da una policy di sicurezza gerarchica.
L'azione goto_next
Cloud Armor ha un'azione delle regole esclusiva per le policy di sicurezza gerarchiche, l'azione goto_next. Quando Cloud Armor applica questa azione, interrompe la valutazione delle regole all'interno della policy di sicurezza attuale e inizia a valutare le regole nella policy di sicurezza successiva.
Considera ad esempio di avere una policy di sicurezza gerarchica a livello di organizzazione con molte regole che vuoi utilizzare per limitare le richieste in tutta l'organizzazione. Vuoi consentire alle richieste provenienti da un determinato intervallo di indirizzi IP di saltare la valutazione di queste regole a livello di organizzazione. Pertanto, crei una regola con la priorità massima che corrisponda a questo intervallo di indirizzi IP con l'azione goto_next. Le richieste provenienti da questo intervallo di indirizzi IP vengono valutate prima in base a questa regola e, poiché soddisfano la condizione di corrispondenza, non vengono valutate in base ad altre regole di questa policy di sicurezza gerarchica a livello di organizzazione.
Nello stesso esempio, se hai utilizzato un'azione allow o deny anziché l'azione goto_next, la richiesta viene consentita o negata non appena viene soddisfatta la condizione di corrispondenza. Questa valutazione gerarchica significa che non vengono valutate ulteriori policy di sicurezza in base a questa richiesta.
Comportamento di registrazione e fatturazione di Google Cloud Armor Enterprise
Quando colleghi una policy di sicurezza gerarchica, ogni progetto che eredita la policy di sicurezza gerarchica deve essere registrato in Cloud Armor Enterprise. Sono inclusi tutti i progetti in un'organizzazione o in una cartella con una policy di sicurezza gerarchica che non sono esclusi esplicitamente e tutti i progetti con una policy di sicurezza gerarchica collegata direttamente al progetto.
- I progetti collegati a un account di fatturazione Cloud con un abbonamento a Cloud Armor Enterprise annuale vengono registrati automaticamente in Cloud Armor Enterprise annuale, se non sono già registrati.
- Senza un abbonamento a Cloud Armor Enterprise annuale, i progetti vengono registrati automaticamente in Cloud Armor Enterprise Paygo quando ereditano una policy di sicurezza gerarchica. Se sottoscrivi un abbonamento dell'account di fatturazione a Cloud Armor Enterprise annuale dopo che il tuo progetto è stato registrato automaticamente in Cloud Armor Enterprise Paygo, il progetto non viene registrato automaticamente in Annuale. Per saperne di più su Cloud Armor Enterprise Paygo, consulta Cloud Armor Standard e Cloud Armor Enterprise.
- Se aggiorni una policy di sicurezza gerarchica per escludere un progetto dopo che è stato registrato automaticamente in Cloud Armor Enterprise, la registrazione del progetto non viene annullata automaticamente. Per annullare manualmente la registrazione del progetto, consulta Rimuovi un progetto da Cloud Armor Enterprise.
- Non puoi rimuovere un progetto da Cloud Armor Enterprise se ha policy di sicurezza gerarchiche ereditate.
Il completamento della registrazione automatica può richiedere fino a una settimana. Durante questo periodo, le tue policy di sicurezza gerarchiche sono efficaci e non vengono sostenuti costi per Cloud Armor Enterprise. Quando il progetto viene registrato, gli audit log vengono aggiornati per riflettere lo stato di Cloud Armor Enterprise del progetto e viene visualizzato il nuovo livello del progetto nella console Google Cloud .
Limitazioni
Le policy di sicurezza gerarchiche presentano le seguenti limitazioni:
- Le policy di sicurezza gerarchiche non sono disponibili per i progetti che non si trovano all'interno di un'organizzazione.
- Per i progetti nuovi o ripristinati di recente, la propagazione delle policy di sicurezza ereditate nel progetto potrebbe richiedere alcune ore.
- Per un progetto per cui hai abilitato di recente l'API Compute Engine, potrebbero essere necessarie alcune ore prima che vengano propagate le eventuali policy di sicurezza ereditate.
- Puoi ottimizzare le regole WAF preconfigurate nelle policy di sicurezza gerarchiche di tua proprietà, ma i proprietari dei servizi che ereditano una policy di sicurezza gerarchica non possono eseguire l'ottimizzazione delle regole.