Sicurezza di rete per applicazioni distribuite nella rete Cross-Cloud

Last reviewed 2024-04-05 UTC

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 è costituita dai seguenti componenti:

Piattaforme 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 di dominio

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

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

  • Comunicazioni tra i VPC
  • Comunicazioni tra connessioni ibride con altri cloud provider o data center on-premise
  • Comunicazioni verso Internet

La possibilità di inserire appliance virtuali di rete di terze parti (NVA) 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à firewall stateful scalabili orizzontalmente e applicate a ciascuna istanza VM. La natura distribuita dei firewall Google Cloud consente di implementare criteri di sicurezza per la micro-segmentazione della rete senza influire negativamente sulle prestazioni dei carichi di lavoro.

Utilizza i criteri firewall gerarchici per migliorare la gestibilità e applicare la conformità della postura per i criteri firewall. I criteri firewall gerarchici 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 a criteri di livello inferiore (criteri firewall di rete globali o regionali) con un'azione goto_next.

Le regole di livello inferiore non possono prevalere su una regola di un livello superiore nella gerarchia delle risorse. Questa struttura di regole consente agli amministratori a livello di organizzazione di gestire le regole firewall obbligatorie in un'unica posizione. I casi d'uso comuni per i criteri firewall gerarchici includono l'accesso al bastion host a livello di organizzazione o di più progetti, che consente di effettuare probe centralizzati o sistemi di controllo di integrità e l'applicazione di un confine di rete virtuale in un'organizzazione o un gruppo di progetti. Per ulteriori esempi di utilizzo dei criteri firewall gerarchici, consulta Esempi di criteri firewall gerarchici.

Utilizza i criteri firewall globali e regionali del firewall per definire le regole su una singola rete VPC, per tutte le regioni della rete (globale) o per una singola regione (a livello di regione).

Per ottenere controlli più granulari applicati a livello di macchina virtuale (VM), ti consigliamo di utilizzare tag regolati da Identity and Access Management (IAM) a livello di organizzazione o di progetto. I tag gestiti da IAM consentono di applicare regole firewall basate sull'identità dell'host del carico di lavoro, anziché sull'indirizzo IP dell'host, e funzionano nel peering di rete VPC. Le regole firewall distribuite utilizzando i tag possono fornire micro-segmentazione intra-subnet con copertura dei criteri che si applica automaticamente ai carichi di lavoro indipendentemente dall'architettura di rete.

Oltre alle funzionalità di ispezione stateful e al supporto dei tag, Cloud Next Generation Firewall supporta anche Threat Intelligence, il nome di dominio completo e il filtro 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 perimetrale nel cloud

In un ambiente di rete multi-cloud, la sicurezza perimetrale viene implementata in ogni rete. Ad esempio, la rete on-premise dispone di un proprio set di firewall perimetrali, mentre ogni rete cloud implementa firewall perimetri separati.

Poiché la rete cross-cloud è progettata come hub per tutte le comunicazioni, puoi unificare e centralizzare i controlli di sicurezza perimetrali ed eseguire il deployment di un singolo insieme di firewall perimetrali nella tua rete Cross-Cloud. Cross-Cloud Network offre uno stack di sicurezza perimetrale integrato a sua scelta. Offre opzioni flessibili per l'inserimento di NVA.

Nelle progettazioni mostrate nei diagrammi, puoi eseguire il deployment di VM di terze parti nel VPC di transito nel progetto hub.

Le VM possono essere implementate su una singola interfaccia di rete (modalità con NIC singolo) o su più interfacce di rete su più VPC (modalità con più NIC). Per la rete cross-cloud, consigliamo un deployment con NIC singolo per le VM, perché questa opzione consente di:

  • Inserisci gli NVA con route basate su criteri.
  • Evita di creare topologie rigide.
  • Esegui il deployment in una varietà di topologie tra VPC.
  • Abilita la scalabilità automatica per le VM.
  • Scala per molti VPC nel tempo, senza modifiche necessarie al deployment dell'interfaccia NVIDIA.

Se la progettazione richiede più NIC, i suggerimenti sono descritti in dettaglio in Sicurezza perimetrale NVIDIA NVIDIA.

Per svolgere lo reindirizzamento 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 criteri sono più flessibili rispetto alle route standard, perché le route basate su criteri corrispondono alle informazioni di origine e di destinazione. Queste route basate su criteri vengono applicate anche solo in punti specifici nella topologia di rete cloud. Questa granularità consente di definire comportamenti di reindirizzamento del traffico molto specifici per flussi di connettività molto specifici.

Inoltre, questa progettazione consente i meccanismi di resilienza richiesti dalle VNA. Gli NVA hanno un bilanciatore del carico TCP/UDP interno per abilitare la ridondanza NVA, la scalabilità automatica per la capacità elastica e la simmetria di flusso per supportare l'elaborazione del traffico bidirezionale stateful.

Sicurezza perimetrale NVA con singolo NIC

Nella progettazione descritta in Connettività tra VPC per i servizi centralizzati, il VPC di transito agisce da hub per i VPC spoke che sono connessi tramite peering di rete VPC e VPN ad alta disponibilità. Il VPC di transito consente inoltre la connettività tra le reti esterne e i VPC spoke.

Per l'inserimento dell'NVA con un singolo NIC, questa progettazione combina i due pattern seguenti:

  • Inserisci le VM in un hub di peering di rete VPC con connessioni ibride esterne
  • Inserisci le VM in un hub 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à:

VNA inserite negli hub per peering di rete VPC e VPN ad alta disponibilità

Il diagramma precedente illustra un pattern combinato:

  • Un VPC di transito che ospita collegamenti VLAN di Cloud Interconnect che forniscono connettività ibrida o multi-cloud. Questo VPC contiene anche le VM a NIC singolo che monitorano le connessioni ibride.
  • VPC delle applicazioni connesse al VPC di transito tramite peering di rete VPC.
  • Un VPC di 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 peering di rete VPC. La comunicazione viene gestita attraverso firewall NVA di terze parti utilizzando la seguente combinazione di bilanciamento del carico passthrough, route statiche e route basate su criteri:

  1. 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 di destinazione che forniscono la simmetria del traffico.
  2. Per indirizzare il traffico in entrata al bilanciatore del carico di rete passthrough interno, applica route basate su criteri alle connessioni Cloud Interconnect nel VPC di transito. Si tratta di route regionali.
  3. Per fare in modo che il traffico in uscita dall'NVA non venga instradato direttamente all'NVA, imposta tutte le interfacce NVA come destinazione di una route basata su criteri saltati per saltare altre route basate su criteri. Il traffico segue quindi la tabella di routing VPC dopo essere stato elaborato dalle VM a livello di regione.
  4. Per indirizzare il traffico ai bilanciatori del carico interni NVA nel VPC di transito, applica route statiche ai VPC dell'applicazione. Questi possono essere limitati a livello di regione utilizzando i tag di rete.

Sicurezza perimetrale NVA multi-NIC

In modalità multi-NIC, la topologia è più statica perché gli asset VPN collegano la connettività tra i diversi VPC in cui risiedono le diverse interfacce di rete.

Quando in un firewall sono necessarie zone basate sull'interfaccia, la seguente progettazione con più NIC abilita la connettività esterna richiesta. Questa progettazione assegna interfacce firewall diverse alle reti esterne. Le reti esterne vengono definite dai professionisti della sicurezza come reti non attendibili, mentre le reti interne sono note come reti attendibili. Per il deployment dell'NVA multi-NIC, questa progettazione viene implementata utilizzando VPC attendibili e non attendibili.

Per le comunicazioni interne, il firewall può essere applicato utilizzando un modello di inserimento con NIC singolo che corrisponde a un modello di zona basato su CIDR.

In questa progettazione, devi inserire gli asset creati automaticamente configurando quanto segue:

  1. 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 di destinazione che forniscono la simmetria del traffico.
  2. Per indirizzare il traffico in entrata al bilanciatore del carico di rete passthrough interno, applica route basate su criteri alle connessioni Cloud Interconnect nel VPC non attendibile. Si tratta di route regionali.
  3. Per fare in modo che il traffico in uscita dall'NVA non venga instradato direttamente all'NVA, imposta tutte le interfacce NVA come destinazione di una route basata su criteri saltati per saltare altre route basate su criteri. Il traffico segue quindi la tabella di routing VPC dopo essere stato elaborato dalle VM a livello di regione.
  4. 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 di regione utilizzando i tag di rete.

Il seguente diagramma mostra le VM con più NIC inserite tra le reti VPC non attendibili e attendibili nel progetto hub:

VNA per la comunicazione interna

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: