Sicurezza di rete per le applicazioni distribuite in Cross-Cloud Network

Last reviewed 2024-04-05 UTC

Questo documento fa parte di una serie di guide alla progettazione per Cross-Cloud Network. Questa parte illustra il livello di sicurezza di rete.

La serie è composta dai seguenti componenti:

Superfici di sicurezza

Quando progetti il livello di sicurezza per la rete cross-cloud, devi prendere in considerazione le seguenti piattaforme di sicurezza:

  • Sicurezza dei carichi di lavoro
  • Sicurezza del perimetro del dominio

La sicurezza del carico di lavoro controlla la comunicazione tra i carichi di lavoro all'interno e all'esterno del Virtual Private Cloud (VPC). La sicurezza del carico di lavoro utilizza punti di applicazione della sicurezza vicini ai carichi di lavoro nell'architettura. Ove possibile, Cross-Cloud Network fornisce la sicurezza dei carichi di lavoro utilizzando Cloud Next Generation Firewall di Google Cloud.

La sicurezza del perimetro è obbligatoria in tutti i confini della rete. Poiché il perimetro solitamente interconnette reti gestite da organizzazioni diverse, spesso sono necessari controlli di sicurezza più stringenti. Devi assicurarti che le seguenti comunicazioni tra reti siano protette:

  • Comunicazioni tra VPC
  • Comunicazioni tramite connessioni ibride ad altri provider cloud o data center on-premise
  • Comunicazioni con internet

La possibilità di inserire appliance virtuali di rete (NVA) di terze parti nell'ambiente Google Cloud è fondamentale per soddisfare i requisiti di sicurezza del perimetro 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à di firewall stateful scalabili orizzontalmente e applicate a ogni istanza VM. La natura distribuita dei firewall di Google Cloud ti aiuta a implementare criteri di sicurezza per la microsegmentazione della rete senza influire negativamente sul rendimento dei tuoi carichi di lavoro.

Utilizza i criteri firewall gerarchici per migliorare la gestibilità e applicare la conformità della postura per i tuoi criteri firewall. I criteri firewall gerarchici ti consentono di creare e applicare un criterio firewall coerente in tutta l'organizzazione. Puoi assegnare criteri firewall gerarchici all'organizzazione o a singole cartelle. Inoltre, le regole dei criteri firewall gerarchici possono delegare la valutazione ai 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 di regole consente agli amministratori a livello di organizzazione di gestire in un'unica posizione le regole firewall obbligatorie. I casi d'uso comuni per i criteri firewall gerarchici includono l'accesso agli host bastioni di organizzazioni o progetti multipli, la possibilità di utilizzare sistemi di controllo di integrità o di analisi centralizzati e l'applicazione di un confine di rete virtuale in un'organizzazione o in un gruppo di progetti. Per altri esempi di utilizzo dei criteri firewall gerarchici, consulta Esempi di criteri firewall gerarchici.

Utilizza i criteri firewall di rete e regionali per definire regole su 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), consigliamo di utilizzare i tag regolati 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 carico di lavoro, anziché all'indirizzo IP dell'host, e funzionano in tutti i peering di reti VPC. Le regole del firewall implementate utilizzando i tag possono fornire la micro-segmentazione all'interno della sottorete con una copertura delle norme che si applica automaticamente ai carichi di lavoro ovunque siano implementati, indipendentemente dall'architettura di rete.

Oltre alle funzionalità di ispezione stateful e al supporto dei tag, Cloud Next Generation Firewall supporta anche Threat Intelligence, FQDN e filtri 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 un criterio firewall di rete globale e converte le regole firewall VPC esistenti nel nuovo criterio.

Sicurezza del perimetro nel cloud

In un ambiente di rete multicloud, la sicurezza perimetrale viene solitamente implementata in ogni rete. Ad esempio, la rete on-premise ha il proprio insieme di firewall di perimetro, mentre ogni rete cloud implementa firewall di perimetro 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'unica serie di firewall perimetrali nella tua rete. Per offrire uno stack di sicurezza perimetrale integrato di tua scelta, Cross-Cloud Network offre opzioni flessibili per inserire NVA.

Nei progetti mostrati nei diagrammi, puoi implementare NVA di terze parti nella VPC di transito del progetto hub.

Le NVA possono essere implementate su una singola interfaccia di rete (modalità NIC singola) o su più interfacce di rete in più VPC (modalità NIC multiple). Per la rete cross-cloud, consigliamo un deployment con una sola NIC per le NVA, in quanto questa opzione consente di eseguire le seguenti operazioni:

  • Inserisci le NVA con route basate su criteri.
  • Evita di creare topologie rigide.
  • Esegui il deployment in una serie di topologie inter-VPC.
  • Attiva la scalabilità automatica per le NVA.
  • Esegui il ridimensionamento a molti VPC nel tempo, senza modifiche necessarie al deployment dell'interfaccia NVA.

Se il tuo design richiede più NIC, i consigli sono descritti in dettaglio in Sicurezza perimetrale dell'NVA con più NIC.

Per eseguire lo steering del traffico necessario per il deployment dell'NVA, questa guida consiglia l'applicazione selettiva di route basate su criteri e statiche nelle tabelle di routing VPC. Le route basate su criteri sono più flessibili rispetto a quelle standard perché corrispondono sia alle informazioni di origine che a quelle di destinazione. Inoltre, queste route basate su criteri vengono applicate solo in punti specifici della topologia di rete cloud. Questa granularità consente di definire un comportamento di indirizzamento del traffico molto specifico per flussi di connettività molto specifici.

Inoltre, questo design abilita i meccanismi di resilienza richiesti dalle NVA. Le NVA sono precedute da un bilanciatore del carico TCP/UDP interno per abilitare la ridondanza delle NVA, l'autoscaling per la capacità elastica e la simmetria del flusso per supportare l'elaborazione del traffico bidirezionale stateful.

Sicurezza perimetrale dell'NVA con una sola NIC

Nel design descritto in Connettività inter-VPC per i servizi centralizzati, la VPC di transito funge da hub per le VPC spoke connesse tramite il peering di rete VPC e la VPN ad alta disponibilità. La VPC di transito consente inoltre la connettività tra le reti esterne e le VPC spoke.

Ai fini dell'inserimento di un NVA con una sola NIC, questo design combina i seguenti due pattern:

  • Inserisci NVA in un hub di peering di rete VPC con connessioni ibride esterne
  • Inserire NVA in un hub VPC VPN ad alta disponibilità con collegamenti ibridi esterni

Il seguente diagramma mostra le NVA inserite negli hub per il peering di rete VPC e la VPN ad alta disponibilità:

NVA inserite negli hub per il peering di rete VPC e la VPN ad alta disponibilità

Il diagramma precedente illustra un pattern combinato:

  • Una VPC di transito che ospita gli attacchi VLAN Cloud Interconnect che forniscono connettività ibrida o multicloud. Questa VPC contiene anche le NVA con una sola NIC che monitorano le connessioni ibride.
  • Le VPC di applicazione connesse alla VPC di transito tramite il peering di rete VPC.
  • Un VPC di servizi centrali connesso al VPC di transito tramite VPN ad alta disponibilità.

In questo design, gli spoke connessi tramite VPN ad alta disponibilità utilizzano la 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 passthrough, route statici e route basati su criteri:

  1. Per indirizzare il traffico VPN ad alta disponibilità al bilanciatore del carico interno, applica route basate su criteri non taggate alla VPC di transito. In queste route basate su criteri, utilizza intervalli CIDR di origine e destinazione che prevedono la simmetria del traffico.
  2. Per indirizzare il traffico in entrata al bilanciatore del carico di rete passthrough interno, applica le route basate su criteri alle connessioni Cloud Interconnect nella VPC di transito. Si tratta di percorsi regionali.
  3. Affinché il traffico in uscita dall'NVA non venga reindirizzato direttamente all'NVA, imposta tutte le interfacce NVA come target di una route basata su criteri di salto per saltare altre route basate su criteri. Il traffico segue quindi la tabella di routing VPC dopo essere stato elaborato dalle NVA.
  4. Per indirizzare il traffico ai bilanciatori del carico interni NVA nella VPC di transito, applica route statiche alle VPC di applicazione. Questi possono essere definiti a livello di regione utilizzando i tag di rete.

Sicurezza perimetrale NVA con più NIC

In modalità multi-NIC, la topologia è più statica perché le NVA fanno da ponte tra la connettività tra i diversi VPC in cui si trovano le diverse interfacce di rete.

Quando in un firewall sono necessarie zone basate su interfaccia, il seguente design con più NIC consente la connettività esterna richiesta. Questo design assegna diverse interfacce di firewall alle reti esterne. Le reti esterne sono indicate dagli addetti alla sicurezza come reti non attendibili, mentre le reti interne sono note come reti attendibili. Per il deployment dell'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 di una singola NIC che corrisponde a un modello di zona basato su CIDR.

In questo design, inserisci le NVA configurando quanto segue:

  1. Per indirizzare il traffico VPN ad alta disponibilità al bilanciatore del carico interno, applica route basate su criteri non taggate alla VPC attendibile. In queste route basate su criteri, utilizza intervalli CIDR di origine e destinazione che prevedono la simmetria del traffico.
  2. Per indirizzare il traffico in entrata al bilanciatore del carico di rete passthrough interno, applica le route basate su criteri alle connessioni Cloud Interconnect nella VPC non attendibile. Si tratta di percorsi regionali.
  3. Affinché il traffico in uscita dall'NVA non venga reindirizzato direttamente all'NVA, imposta tutte le interfacce NVA come target di una route basata su criteri di salto per saltare altre route basate su criteri. Il traffico segue quindi la tabella di routing VPC dopo essere stato elaborato dalle NVA.
  4. Per indirizzare il traffico ai bilanciatori del carico interni NVA nella VPC attendibile, applica route statiche alle VPC dell'applicazione. Questi possono essere definiti a livello di regione utilizzando i tag di rete.

Il seguente diagramma mostra le NVA multi-NIC inserite tra le reti VPC attendibili e non attendibili nel progetto hub:

NVA per la comunicazione interna

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: