I criteri di sicurezza gerarchici sono una categoria di criteri di sicurezza che estendono la portata del web application firewall (WAF) di Google Cloud Armor e della protezione DDoS oltre i singoli progetti. Sono allegati a livello di organizzazione, cartella o progetto. Queste differiscono dalle norme di sicurezza a livello di servizio, che vengono associate 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 ne 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. Ciò consente l'applicazione centralizzata e coerente della sicurezza nel tuo ambiente Google Cloud .
Questa pagina spiega in che modo le norme di sicurezza gerarchiche differiscono dalle norme di sicurezza a livello di servizio. Prima di procedere, leggi la panoramica delle norme di sicurezza per assicurarti di aver compreso come funzionano le norme di sicurezza. Inoltre, ti consigliamo di acquisire familiarità con la gerarchia delle risorse.
Casi d'uso
Nelle grandi organizzazioni, la gestione dei criteri di sicurezza in numerosi progetti può essere complessa e richiedere molto tempo. Le norme di sicurezza gerarchiche offrono i seguenti vantaggi per aiutarti ad affrontare queste sfide:
- Controllo centralizzato: consente agli amministratori a livello di organizzazione e cartella di definire e applicare policy di sicurezza in più progetti.
- Coerenza: fornisci una postura di sicurezza uniforme in tutta l'organizzazione, riducendo il rischio di errori di configurazione e lacune di sicurezza.
- Efficienza: semplifica l'implementazione di aggiornamenti e mitigazioni della sicurezza, come il blocco di intervalli di indirizzi IP specifici o la risoluzione di vulnerabilità critiche, su un numero elevato di risorse contemporaneamente.
- Delega: delega le responsabilità di sicurezza a team o reparti diversi applicando criteri 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 sulla posizione geografica: puoi limitare il traffico proveniente da regioni geografiche specifiche a livello di organizzazione o 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 criteri di sicurezza coerenti in tutta l'organizzazione.
- Controllo dell'accesso granulare: puoi concedere a intervalli di indirizzi IP specifici o a 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 Google Cloud Armor che puoi utilizzare con i criteri di sicurezza gerarchici e i criteri 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 | ||
| Geografia di origine | ||
| ASN di origine | ||
| Gestione di bot | (solo
EXTERNAL_302 e decorazione delle 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 norme di sicurezza gerarchiche
Quando crei una policy di sicurezza gerarchica, la crei a livello di organizzazione o cartella e questa risorsa ha la proprietà della policy di sicurezza gerarchica. Dopo aver creato una policy di sicurezza gerarchica, le regole della policy di sicurezza non vengono applicate a nessuna delle 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 gerarchica, 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.
Questi criteri 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 un elenco negato di indirizzi IP a più servizi di backend.
Specifica queste risorse utilizzando il flag
--projectdurante l'associazione. - A livello di servizio: utilizza criteri di sicurezza a livello di servizio quando hai bisogno di regole dei criteri di sicurezza uniche che differiscono tra i tuoi servizi. Ogni
policy di sicurezza a livello di servizio applica le proprie regole solo alla policy di backend
a cui è collegata. Specifica queste risorse utilizzando il flag
--project-number.
Puoi utilizzare solo uno di questi flag per criterio di sicurezza gerarchico. Specifichi gli altri flag, come --name o --type, proprio come quando configuri una policy di sicurezza a livello di servizio. Consulta il seguente elenco per ulteriori
informazioni sul funzionamento delle norme di sicurezza gerarchiche:
- Quando un criterio di sicurezza gerarchico è associato a un nodo della gerarchia delle risorse, tutte le risorse protette inferiori a quel nodo nella gerarchia ereditano il criterio.
- Puoi visualizzare i criteri di sicurezza che si applicano a ogni risorsa protetta in un progetto, in tutti i criteri di sicurezza gerarchici e a livello di servizio. Per ulteriori informazioni, vedi Visualizzare tutte le regole Google Cloud Armor effettive per una risorsa protetta.
- Puoi spostare i criteri di sicurezza gerarchici 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 il criterio di sicurezza altrove e poi l'hai spostato sotto il nodo, non viene eliminato.
- 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
Google Cloud Armor valuta i criteri 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 un criterio di sicurezza gerarchico con una priorità bassa che viene valutato prima di un criterio di sicurezza a livello di servizio con una priorità elevata. Valuta attentamente le regole dei criteri di sicurezza esistenti a livello di servizio con priorità elevata e considera cosa succede se Google Cloud Armor non valuta una richiesta consentita o negata da un criterio di sicurezza gerarchico.
L'azione goto_next
Google Cloud Armor ha un'azione di regola esclusiva per
i criteri di sicurezza gerarchici: l'azione goto_next. Quando Google Cloud Armor applica
questa azione, interrompe la valutazione delle regole all'interno dei criteri di sicurezza correnti e
inizia a valutare le regole nei criteri di sicurezza successivi.
Prendi in considerazione un esempio in cui hai 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, crea una regola di 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 in questo criterio di sicurezza gerarchico 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 la condizione di corrispondenza
viene soddisfatta. Questa valutazione gerarchica significa che non vengono valutate ulteriori norme 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 di un'organizzazione o di 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 a 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 ulteriori informazioni su Cloud Armor Enterprise Paygo, vedi Google Cloud Armor Standard e Cloud Armor Enterprise.
- Se aggiorni una policy di sicurezza gerarchica per escludere un progetto dopo che il progetto è stato registrato automaticamente in Cloud Armor Enterprise, il progetto non viene annullato automaticamente. Per annullare manualmente la registrazione del progetto, vedi Rimuovere un progetto da Cloud Armor Enterprise.
- Non puoi rimuovere un progetto da Cloud Armor Enterprise se ha policy di sicurezza gerarchiche ereditate.
La registrazione automatica può richiedere fino a una settimana. Durante questo periodo, le tue norme di sicurezza gerarchiche sono efficaci e non vengono sostenuti costi di Cloud Armor Enterprise. Quando il progetto viene registrato, i log di controllo 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:
- I criteri di sicurezza gerarchici non sono disponibili per i progetti che non fanno parte di un'organizzazione.
- Per i progetti nuovi o ripristinati di recente, la propagazione dei criteri di sicurezza ereditati nel progetto potrebbe richiedere alcune ore.
- Per un progetto in cui è stata abilitata di recente l'API Compute Engine, la propagazione delle policy di sicurezza ereditate potrebbe richiedere alcune ore.
- Puoi ottimizzare le regole WAF preconfigurate nei criteri di sicurezza gerarchici di tua proprietà, ma i proprietari dei servizi che ereditano un criterio di sicurezza gerarchico non possono eseguire l'ottimizzazione delle regole.