Questo documento fa parte di una serie di guide alla progettazione per Cross-Cloud Network. Questa parte esplora il livello di sicurezza di rete.
La serie è composta dalle seguenti parti:
- Cross-Cloud Network per applicazioni distribuite
- Segmentazione e connettività di rete per applicazioni distribuite in Cross-Cloud Network
- Service Networking per applicazioni distribuite in Cross-Cloud Network
- Sicurezza di rete per applicazioni distribuite in Cross-Cloud Network (questo documento)
Superfici di sicurezza
Quando progetti il livello di sicurezza per Cross-Cloud Network, devi prendere in considerazione le seguenti superfici di attacco:
- Sicurezza dei carichi di lavoro
- Sicurezza perimetrale del dominio
I controlli di sicurezza del carico di lavoro controllano la comunicazione tra i carichi di lavoro all'interno e all'esterno di Virtual Private Cloud (VPC). La sicurezza del workload utilizza punti di applicazione della sicurezza vicini ai workload nell'architettura. Ove possibile, Cross-Cloud Network fornisce la sicurezza dei carichi di lavoro utilizzando Cloud Next Generation Firewall di Google Cloud.
La sicurezza perimetrale è obbligatoria in tutti i confini di rete. Poiché il perimetro di solito interconnette reti gestite da organizzazioni diverse, spesso sono necessari controlli di sicurezza più rigorosi. Devi assicurarti che le seguenti comunicazioni tra le reti siano protette:
- Comunicazioni tra VPC
- Comunicazioni tra connessioni ibride ad altri cloud provider o data center on-premise
- Comunicazioni a internet
La possibilità di inserire appliance virtuali di rete (NVA) di terze parti all'interno dell'ambienteGoogle Cloud è fondamentale per soddisfare i requisiti di sicurezza perimetrale nelle connessioni ibride.
Sicurezza dei carichi di lavoro nel cloud
Utilizza i criteri firewall in Google Cloud per proteggere i carichi di lavoro e fornire funzionalità firewall stateful scalabili orizzontalmente e applicate a ogni istanza VM. La natura distribuita dei firewall ti aiuta a implementare criteri di sicurezza per la microsegmentazione della rete senza influire negativamente sul rendimento dei tuoi carichi di lavoro. Google Cloud
Utilizza le policy del firewall gerarchiche per
migliorare la gestibilità e applicare la conformità alla postura per le tue policy
del firewall. I criteri firewall gerarchici ti consentono di creare e applicare una policy del firewall coerente in tutta l'organizzazione. Puoi assegnare
le policy del firewall gerarchiche all'organizzazione o a singole cartelle.
Inoltre, le regole dei criteri firewall gerarchici possono delegare la valutazione a criteri di livello inferiore (criteri firewall di rete globali o regionali) con un'azione goto_next
.
Le regole di livello inferiore non possono sostituire una regola di un livello superiore nella gerarchia delle risorse. Questa struttura delle regole consente agli amministratori a livello di organizzazione di gestire le regole firewall obbligatorie in un'unica posizione. I casi d'uso comuni per le policy firewall gerarchiche includono l'accesso all'bastion host dell'organizzazione o di più progetti, l'autorizzazione di sistemi di probing o controllo di integrità centralizzati e l'applicazione di un limite di rete virtuale in un'organizzazione o in un gruppo di progetti. Per altri esempi di utilizzo dei criteri firewall gerarchici, vedi Esempi di criteri firewall gerarchici.
Utilizza i criteri firewall di rete globali e regionali per definire le regole in base a una singola rete VPC, per tutte le regioni della rete (globali) o per una singola regione (regionali).
Per ottenere controlli più granulari applicati a livello di macchina virtuale (VM), ti consigliamo di utilizzare i tag gestiti da Identity and Access Management (IAM) a livello di organizzazione o progetto. I tag gestiti da IAM consentono di applicare regole firewall in base all'identità dell'host del workload, anziché all'indirizzo IP dell'host, e funzionano con il peering di reti VPC. Le regole firewall implementate utilizzando i tag possono fornire la microsegmentazione all'interno della subnet con una copertura delle policy che si applica automaticamente ai carichi di lavoro ovunque vengano implementati, indipendentemente dall'architettura di rete.
Oltre alle funzionalità di ispezione stateful e al supporto dei tag, Cloud Next Generation Firewall supporta anche il filtro Threat Intelligence, FQDN e di geolocalizzazione.
Ti consigliamo di eseguire la migrazione dalle regole firewall VPC ai criteri firewall. Per facilitare la migrazione, utilizza lo strumento di migrazione, che crea una policy firewall di rete globale e converte le regole firewall VPC esistenti nella nuova policy.
Sicurezza perimetrale nel cloud
In un ambiente di rete multicloud, la sicurezza perimetrale viene in genere implementata in ogni rete. Ad esempio, la rete on-premise ha il proprio set di firewall perimetrali, mentre ogni rete cloud implementa firewall perimetrali separati.
Poiché Cross-Cloud Network è progettata per essere l'hub di tutte le comunicazioni, puoi unificare e centralizzare i controlli di sicurezza perimetrale e implementare un unico set di firewall perimetrali nella tua rete Cross-Cloud Network. Per fornire uno stack di sicurezza perimetrale integrato a tua scelta, Cross-Cloud Network offre opzioni flessibili per inserire NVA.
Nei progetti mostrati nei diagrammi, puoi eseguire il deployment di NVA di terze parti nel progetto hub.
Le NVA possono essere implementate su una singola interfaccia di rete (modalità a singola NIC) o su più interfacce di rete in più VPC (modalità multi-NIC). Per Cross-Cloud Network, consigliamo un deployment con una sola NIC per le NVA, perché questa opzione ti consente di:
- Inserisci le NVA con route basate su policy.
- Evita di creare topologie rigide.
- Esegui il deployment in una serie di topologie tra VPC.
- Abilita la scalabilità automatica per le NVA.
- Scalabilità a molte reti VPC nel tempo, senza modifiche richieste al deployment dell'interfaccia NVA.
Se la tua progettazione richiede più NIC, i consigli sono descritti in Sicurezza perimetrale NVA con più NIC.
Per eseguire l'indirizzamento del traffico necessario per il deployment di NVA, questa guida consiglia l'applicazione selettiva di route statiche e basate su criteri nelle tabelle di routing VPC. Le route basate su policy sono più flessibili rispetto alle route standard perché corrispondono alle informazioni di origine e destinazione. Queste route basate su policy vengono applicate solo in posizioni specifiche della topologia di rete cloud. Questa granularità consente di definire un comportamento di gestione del traffico molto specifico per flussi di connettività molto specifici.
Inoltre, questo design consente i meccanismi di resilienza richiesti dalle NVA. Le NVA sono precedute da un bilanciatore del carico TCP/UDP interno per abilitare la ridondanza NVA, lo scalabilità automatica per la capacità elastica e la simmetria del flusso per supportare l'elaborazione del traffico bidirezionale con stato.
Sicurezza perimetrale NVA con una sola NIC
Nella progettazione descritta in Connettività tra VPC per servizi centralizzati, il VPC di transito funge da hub per i VPC spoke connessi tramite il peering di rete VPC e la VPN ad alta disponibilità. Il VPC di transito consente anche la connettività tra le reti esterne e i VPC spoke.
Ai fini dell'inserimento di NVA a singola NIC, questa progettazione combina i seguenti due pattern:
- Inserisci NVA in un hub di peering di rete VPC con connessioni ibride esterne
- Inserisci NVA in un hub VPC VPN ad alta disponibilità con connessioni ibride esterne
Il seguente diagramma mostra le NVA inserite negli hub per il peering di rete VPC e la VPN ad alta disponibilità:
Il diagramma precedente illustra un pattern combinato:
- Un VPC di transito che ospita i collegamenti VLAN Cloud Interconnect che forniscono connettività ibrida o multi-cloud. Questo VPC contiene anche le NVA con una sola NIC che monitorano le connessioni ibride.
- VPC delle applicazioni connesse alla VPC di transito tramite il peering di rete VPC.
- Un VPC dei servizi centrali connesso al VPC di transito tramite VPN ad alta disponibilità.
In questa progettazione, gli spoke connessi tramite VPN ad alta disponibilità utilizzano il VPC di transito per comunicare con gli spoke connessi tramite il peering di rete VPC. La comunicazione viene indirizzata tramite i firewall NVA di terze parti utilizzando la seguente combinazione di bilanciamento del carico pass-through, route statiche e route basate su policy:
- Per indirizzare il traffico VPN ad alta disponibilità al bilanciatore del carico interno, applica route basate su criteri senza tag al VPC di transito. In queste route basate su criteri, utilizza intervalli CIDR di origine e destinazione che prevedono la simmetria del traffico.
- Per indirizzare il traffico in entrata al bilanciatore del carico di rete passthrough interno, applica le route basate su criteri alle connessioni Cloud Interconnect nel VPC di transito. Si tratta di itinerari regionali.
- Affinché il traffico in uscita dalla NVA non venga reindirizzato direttamente alla NVA, imposta tutte le interfacce NVA come destinazione di una route basata su policy di salto per saltare altre route basate su policy. Il traffico segue quindi la tabella di routing VPC una volta elaborato dalle NVA.
- Per indirizzare il traffico ai bilanciatori del carico interni NVA nel VPC di transito, applica route statiche ai VPC delle applicazioni. Questi possono essere limitati a livello regionale utilizzando i tag di rete.
Sicurezza perimetrale NVA con più NIC
In modalità multi-NIC, la topologia è più statica perché le NVA collegano la connettività tra i diversi VPC in cui risiedono le diverse interfacce di rete.
Quando in un firewall sono richieste zone basate sull'interfaccia, la seguente progettazione multi-NIC consente la connettività esterna richiesta. Questo progetto assegna interfacce firewall diverse alle reti esterne. Le reti esterne sono definite dagli esperti di sicurezza come reti non attendibili, mentre le reti interne sono note come reti attendibili. Per il deployment di NVA multi-NIC, questo design viene implementato utilizzando VPC attendibili e non attendibili.
Per le comunicazioni interne, il firewall può essere applicato utilizzando un modello di inserimento con una sola NIC che corrisponde a un modello di zona basato su CIDR.
In questa progettazione, inserisci le NVA configurando quanto segue:
- Per indirizzare il traffico VPN ad alta disponibilità al bilanciatore del carico interno, applica route basate su criteri senza tag al VPC attendibile. In queste route basate su criteri, utilizza intervalli CIDR di origine e destinazione che prevedono la simmetria del traffico.
- Per indirizzare il traffico in entrata al bilanciatore del carico di rete passthrough interno, applica le route basate su criteri alle connessioni Cloud Interconnect nel VPC non attendibile. Si tratta di itinerari regionali.
- Affinché il traffico in uscita dalla NVA non venga reindirizzato direttamente alla NVA, imposta tutte le interfacce NVA come destinazione di una route basata su policy di salto per saltare altre route basate su policy. Il traffico segue quindi la tabella di routing VPC una volta elaborato dalle NVA.
- Per indirizzare il traffico ai bilanciatori del carico interni NVA nel VPC attendibile, applica route statiche ai VPC delle applicazioni. Questi possono essere limitati a livello regionale utilizzando i tag di rete.
Il seguente diagramma mostra le NVA multi-NIC inserite tra le reti VPC non attendibili e attendibili nel progetto hub:
Passaggi successivi
- Scopri di più sui prodotti Google Cloud utilizzati in questa guida alla progettazione:
- Per ulteriori architetture di riferimento, guide alla progettazione e best practice, esplora il Cloud Architecture Center.
Collaboratori
Autori:
- Victor Moreno | Product Manager, Cloud Networking
- Ghaleb Al-habian | Specialista di rete
- Deepak Michael | Networking Specialist Customer Engineer
- Osvaldo Costa | Networking Specialist Customer Engineer
- Jonathan Almaleh | Staff Technical Solutions Consultant
Altri collaboratori:
- Zach Seils | Specialista di networking
- Christopher Abraham | Customer Engineer specializzato in networking
- Emanuele Mazza | Networking Product Specialist
- Aurélien Legrand | Strategic Cloud Engineer
- Eric Yu | Customer Engineer specializzato in networking
- Kumar Dhanagopal | Sviluppatore di soluzioni cross-product
- Mark Schlagenhauf | Technical Writer, Networking
- Marwan Al Shawi | Partner Customer Engineer
- Ammett Williams | Developer Relations Engineer