Best practice per i tag sicuri in Cloud NGFW

Questo documento fornisce le best practice di architettura per progettare, gestire e applicare i tag protetti in Cloud Next Generation Firewall (Cloud NGFW). I tag protetti forniscono un approccio alla sicurezza di rete basato sull'identità, associando la valutazione delle regole firewall alle Workload Identity delle macchine virtuali (VM) anziché agli indirizzi IP dinamici. I tag protetti sono una funzionalità di base inclusa nel livello Cloud Next Generation Firewall Essentials e sono supportati in tutti i livelli Cloud NGFW. Questa guida è destinata ad architetti di rete, amministratori della sicurezza e DevOps engineer che progettano e gestiscono le policy di sicurezza di rete cloud.

Questo documento organizza le best practice in quattro fasi chiave del ciclo di vita dei tag protetti:

  1. Progettare lo schema dei tag: allinea i tag alle identità dei workload configura la microsegmentazione e mantieni i tag a grana grossa per evitare di superare i limiti di quota dei tag protetti.
  2. Configurare il controllo dell'accesso e la governance: stabilisci la separazione dei compiti di Identity and Access Management (IAM), scegli gli ambiti appropriati e applica i tag durante il provisioning delle VM.
  3. Progettare le policy del firewall e la logica delle regole: ottimizza la valutazione delle regole, configura le policy gerarchiche e implementa regole di negazione predefinite sicure.
  4. Proteggere, monitorare e controllare: impedisci l'eliminazione accidentale con i blocchi dei tag, attiva il logging del firewall ed esegui controlli di accesso regolari.

Prima di utilizzare questa guida, assicurati di conoscere la panoramica dei tag protetti per i firewall e la panoramica di Cloud NGFW.

Riepilogo delle best practice

La tabella seguente riassume le best practice principali durante il ciclo di vita dei tag protetti:

Fase del ciclo di vita Consiglio chiave Descrizione
Progettazione dello schema dei tag Allinea i tag con Workload Identity Definisci le chiavi tag in base al ruolo del workload (ad esempio env/prod o tier/database), applica valori reciprocamente esclusivi e mantieni i tag a grana grossa per rispettare i limiti di quota.
Controllo dell'accesso e governance Applica la separazione dei compiti Concedi il ruolo roles/resourcemanager.tagAdmin esclusivamente ai team di sicurezza, limita il ruolo roles/resourcemanager.tagUser alle pipeline di deployment e scegli l'ambito corretto (organization=auto rispetto a network).
Provisioning delle VM Applica i tag al momento della creazione Associa i tag protetti alle interfacce di rete delle VM durante il provisioning e utilizza le policy dell'organizzazione per richiedere i tag su tutte le nuove istanze.
Architettura delle policy Specifica i tag protetti di destinazione Utilizza i tag protetti di destinazione nelle regole firewall per il rendimento della valutazione statica. Configura le regole di negazione predefinite nelle policy gerarchiche per proteggere le risorse senza tag.
Sicurezza tra le reti Proteggi la connettività tra Virtual Private Cloud (VPC) Mantieni i limiti di identità tra le reti VPC in peering e gli spoke di Network Connectivity Center (NCC) senza gestire blocchi CIDR statici.
Protezione e monitoraggio Proteggi e monitora i tag Applica i blocchi dei tag per impedire l'eliminazione accidentale, attiva il logging delle regole firewall per la risoluzione dei problemi e controlla regolarmente le assegnazioni IAM.

Progettare lo schema dei tag

Uno schema dei tag ben strutturato semplifica le regole firewall, ottimizza gli audit di sicurezza e impedisce policy in conflitto.

Allinea i tag a Workload Identity

Progetta le chiavi dei tag protetti in base a ruoli di workload, livelli di applicazione o classificazioni normative distinti:

  • Livello ambiente: env/prod, env/staging, env/dev
  • Livello applicazione: tier/frontend, tier/backend, tier/database
  • Stato di conformità: scope/pci-dss, scope/hipaa

Esempio: microsegmentazione di un'applicazione a tre livelli

Una tipica applicazione web a tre livelli è costituita da un frontend web, un backend dell'applicazione e un database. Per proteggere il database dall'accesso non autorizzato, puoi utilizzare i tag protetti per applicare la microsegmentazione della rete in modo che ogni livello possa comunicare solo con il livello adiacente:

[ Web Tier (tag: tier/frontend) ]
              |
              |  Allow port 8080 (Web can communicate with App)
              v
[ App Tier (tag: tier/backend) ]
              |
              |  Allow port 5432 (App can communicate with DB)
              v
[ Database Tier (tag: tier/database) ]

Per applicare questo flusso, configura due regole della policy del firewall:

  1. Regola 1 (da web ad app): consenti l'ingresso sulla porta 8080 quando il tag di origine è tier/frontend e il tag di destinazione è tier/backend.
  2. Regola 2 (da app a database): consenti l'ingresso sulla porta 5432 quando il tag di origine è tier/backend e il tag di destinazione è tier/database.

Risultato: il frontend web non può comunicare direttamente con il livello del database perché nessuna regola firewall consente il traffico tra tier/frontend e tier/database. Cloud NGFW applica automaticamente questo limite, anche se le istanze VM condividono la stessa subnet IP.

Migrazione dai tag di rete ai tag protetti

Quando esegui l'upgrade dai tag di rete VPC ai tag protetti del firewall, tieni presente le seguenti differenze di architettura:

Capacità Tag di rete (regole VPC) Tag protetti (policy del firewall)
Specifica della destinazione targetTags = ["web-tier"] targetSecureTags = ["tagValues/1234567890"]
Specifica dell'origine sourceTags = ["db-client"] sourceSecureTags = ["tagValues/0987654321"]
Ambito di applicazione Solo una rete VPC Tra reti VPC in peering, spoke NCC, e policy gerarchiche
Supporto del routing Puoi utilizzare i tag di rete come hop successivi per le route statiche (note anche come tag di route) Non puoi utilizzare i tag protetti per il routing. Utilizzali solo per il filtro del traffico firewall.
Controllo dell'accesso Nessuna autorizzazione IAM per i singoli tag I ruoli Resource Manager e IAM regolano rigorosamente l'accesso e l'associazione dei tag

Applica valori di tag reciprocamente esclusivi

Assicurati che le risorse ricevano esattamente un valore per chiave tag. Ad esempio, a un'istanza VM deve essere assegnato env/prod o env/dev, ma mai entrambi:

  • Esegui: assegna un singolo tag ambiente (env/prod) e consenti l'accesso ai servizi condivisi tramite regole firewall esplicite che fanno riferimento ai tag di destinazione (ad esempio env/shared-logging).

  • Non eseguire: impilare più tag ambiente (env/prod e env/dev) sulla stessa VM. In questo modo, la VM può corrispondere alle regole firewall di sviluppo, esponendo le risorse di produzione al traffico degli sviluppatori.

Mantieni i tag a grana grossa per rispettare le quote

Raggruppa istanze VM simili con valori di tag condivisi anziché creare tag univoci specifici per l'istanza. Il tagging a grana grossa mantiene gestibile la postura di sicurezza e impedisce alla tua organizzazione di superare i limiti di quota dei tag protetti.

Quando pianifichi lo schema dei tag, esamina i seguenti limiti:

Utilizza i tag anziché i service account per le VM multi-NIC

Consigliamo di utilizzare i tag protetti anziché i service account come origini o destinazioni nelle policy del firewall. A differenza dei service account, puoi associare i tag protetti direttamente alle singole interfacce di rete (vNIC) di una VM multi-homed. Questo approccio ti consente di applicare policy di rete diverse a ogni interfaccia di rete.

Configurare il controllo dell'accesso e la governance

IAM gestisce i tag protetti per fornire un controllo dell'accesso rigoroso e una chiara separazione dei compiti.

Separare i compiti con i ruoli IAM

Stabilisci un limite operativo tra gli amministratori che creano i tag e i team che eseguono il provisioning dei workload:

  • Amministratore tag (roles/resourcemanager.tagAdmin): concedi esclusivamente agli amministratori centrali di rete e sicurezza per creare, modificare ed eliminare chiavi e valori dei tag.
  • Utente tag (roles/resourcemanager.tagUser): concedi alle pipeline di deployment CI/CD automatizzate o ai service account di provisioning in ambiti di progetto o risorse specifici per associare i tag alle interfacce di rete delle VM.
  • Visualizzatore tag (roles/resourcemanager.tagViewer): concedi ai team operativi e di audit che hanno bisogno di visibilità in sola lettura nelle configurazioni dei tag.

Impedisci l'auto-tagging e l'escalation dei privilegi

  • Esegui: concedi roles/resourcemanager.tagUser esclusivamente alle pipeline di deployment di Infrastructure as Code (IaC) sottoposte a audit (ad esempio i flussi di lavoro google_tags_tag_binding di Terraform) a livello di progetto o interfaccia di rete.
  • Non eseguire: concedi roles/resourcemanager.tagUser in modo ampio ai gruppi di sviluppatori a livello di organizzazione. In questo modo, gli sviluppatori non possono collegare automaticamente i tag di produzione (ad esempio env/prod) ai workload di sviluppo non autorizzati.

Definisci l'ambito delle chiavi tag in modo appropriato

Definisci le chiavi dei tag protetti a livello della gerarchia delle risorse che corrisponde alla tua governance operativa:

  • Tag con ambito organizzazione (purpose-data=organization=auto): definisci le chiavi a livello di organizzazione o cartella per la governance centralizzata della sicurezza su più reti VPC, reti in peering e policy firewall gerarchiche.
  • Tag con ambito rete (purpose-data=network): utilizza solo per l'isolamento a livello di progetto in cui i tag devono essere confinati in modo permanente a una singola rete VPC.

Applica l'assegnazione dei tag durante la creazione della VM

L'associazione dei tag protetti alle interfacce di rete delle VM al momento della creazione garantisce che i workload siano protetti immediatamente al momento del lancio.

Per assicurarti che gli utenti e le pipeline automatizzate non possano eseguire il provisioning delle istanze senza i tag protetti richiesti, configura una policy dell'organizzazione per applicare i tag alla creazione delle risorse. Questa policy blocca la creazione di istanze VM non protette e senza tag.

Progettare le policy del firewall e la logica delle regole

Integra i tag protetti nelle policy del firewall per ottimizzare la valutazione delle regole e mantenere una protezione coerente.

Utilizza le policy del firewall gerarchiche per l'applicazione centralizzata

Definisci le regole firewall che fanno riferimento ai tag protetti all'interno delle policy firewall gerarchiche a livello di organizzazione o cartella. Le policy gerarchiche applicano la governance a livello di organizzazione che i proprietari dei progetti locali non possono sostituire.

Specifica i tag protetti di destinazione per l'efficienza

Quando crei regole della policy del firewall, specifica i tag protetti di destinazione (targetSecureTags) quando possibile. Cloud NGFW valuta i tag di destinazione e i tag di origine in modo diverso:

  • Tag protetti di destinazione (corrispondenza statica): le regole con i tag di destinazione si applicano staticamente solo alle istanze VM che contengono questi tag. In questo modo si riduce il numero di regole valutate su ogni VM e si migliora il rendimento.

  • Tag protetti di origine (corrispondenza dinamica per connessione): le regole che specificano solo i tag di origine (sourceSecureTags) senza tag di destinazione vengono valutate dinamicamente per ogni connessione su tutte le istanze VM della rete, il che aumenta il sovraccarico di elaborazione.

Implementa impostazioni predefinite sicure con la negazione predefinita gerarchica

Poiché le istanze VM non ereditano i tag protetti GCE_FIREWALL dalle cartelle o dalle organizzazioni principali, proteggi le risorse senza tag definendo regole di fallback sicure nelle policy gerarchiche:

  1. Regola di negazione predefinita: crea una regola a bassa priorità (ad esempio, priorità 65000) a livello di organizzazione o cartella che nega tutto il traffico per impostazione predefinita.

  2. Regole di autorizzazione condizionali: crea regole con priorità più alta che consentono il traffico solo tra tag protetti specifici (ad esempio da tier/frontend a tier/backend).

Se un'istanza VM viene creata senza tag o i tag vengono scollegati, la regola di negazione predefinita gerarchica blocca automaticamente il traffico da e verso l'istanza.

Utilizza i tag protetti nelle reti in peering e in NCC

Utilizza i tag protetti per controllare il traffico tra le reti VPC connesse con il peering di rete VPC o gli spoke VPC NCC VPC. I tag protetti mantengono i limiti basati sull'identità tra le reti connesse senza richiedere la gestione dei blocchi CIDR in continua evoluzione.

Proteggere, monitorare e controllare

I controlli operativi continui garantiscono che le configurazioni dei tag protetti rimangano sicure e resilienti.

Proteggi i valori dei tag critici con i blocchi dei tag

Impedisci interruzioni accidentali che si verificano quando elimini i tag in uso:

  • Applica i blocchi dei tag ai valori dei tag protetti critici per impedirne l'eliminazione.
  • Verifica che nessuna regola firewall attiva si basi sul tag protetto prima di scollegarlo dalle interfacce di rete delle VM. Prima di Google Cloud poter eliminare un valore di tag protetto, è necessario rimuovere tutte le associazioni di risorse (e tutti i blocchi dei tag ).

Attiva il logging delle regole firewall

Attiva il logging delle regole della policy firewall su tutte le regole che utilizzano i tag protetti. Questi log acquisiscono i risultati del traffico corrispondente per aiutarti a controllare i pattern di accesso, verificare la segmentazione e risolvere i problemi di connettività.

Controlla regolarmente le assegnazioni dei ruoli IAM

Controlla periodicamente le assegnazioni delle entità per roles/resourcemanager.tagAdmin e roles/resourcemanager.tagUser. Questo controllo garantisce che solo le pipeline autorizzate dispongano delle autorizzazioni di associazione dei tag, il che impedisce l'escalation dei privilegi e preserva l'isolamento dell'ambiente.

Passaggi successivi