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 della rete.

La serie è costituita dai seguenti componenti:

Piattaforme di sicurezza

Quando progetti il livello di sicurezza per la rete cross-cloud, devi considerare 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 utilizza punti di applicazione forzata della sicurezza vicini ai carichi di lavoro nell'architettura. Quando possibile, la rete cross-cloud fornisce la sicurezza dei carichi di lavoro utilizzando il firewall di nuova generazione di Google Cloud.

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

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

La capacità di inserire appliance virtuali di rete (NVA) di terze parti all'interno dell'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 ogni istanza VM. La natura distribuita dei firewall di 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 criteri firewall coerenti 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 a livello di regione) con un'azione goto_next.

Le regole di livello inferiore non possono eseguire l'override di una regola da un livello superiore nella gerarchia delle risorse. che consente agli amministratori a livello di organizzazione di gestire le regole firewall obbligatorie in un unico posto. I casi d'uso comuni per i criteri firewall gerarchici includono l'accesso a bastion host a livello di organizzazione o multiprogetto, l'autorizzazione a sistemi centralizzati di probe o controllo di integrità e l'applicazione di un confine di rete virtuale in un'organizzazione o un gruppo di progetti. Per ulteriori esempi sull'utilizzo di criteri firewall gerarchici, consulta Esempi di criteri firewall gerarchici.

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

Per ottenere controlli più granulari applicati a livello di macchina virtuale (VM), consigliamo di utilizzare tag gestiti da Identity and Access Management (IAM) a livello di organizzazione o di 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 nel peering di rete VPC. Le regole firewall distribuite tramite tag possono fornire una micro-segmentazione all'interno delle subnet con copertura dei criteri che si applica automaticamente ai carichi di lavoro ovunque siano stati 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, il nome di dominio completo e il filtro della geolocalizzazione.

Ti consigliamo di eseguire la migrazione dalle regole firewall VPC ai criteri del 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 multi-cloud, la sicurezza perimetrale è solitamente implementata in ogni rete. Ad esempio, la rete on-premise ha un proprio set di firewall perimetrali, mentre ogni rete cloud implementa firewall perimetrali separati.

Poiché la rete cross-cloud è progettata per essere l'hub per tutte le comunicazioni, puoi unificare e centralizzare i controlli di sicurezza perimetrali ed eseguire il deployment di un singolo set di firewall perimetrali nella tua rete cross-cloud. Per offrirti uno stack di sicurezza perimetrale integrato preferito, Cross-Cloud Network offre opzioni flessibili per inserire gli NVA.

Nei progetti mostrati nei diagrammi, puoi eseguire il deployment di NVA di terze parti nel VPC in transito nel progetto hub.

Il deployment degli NVA può essere eseguito su una singola interfaccia di rete (modalità NIC singola) o su più interfacce di rete su più VPC (modalità multi-NIC). Per la rete Cross-Cloud, consigliamo il deployment con un NIC singolo per le NVA, perché questa opzione ti consente di:

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

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

Per eseguire l'indirizzamento del traffico necessario per il deployment di NVA, questa guida consiglia l'applicazione selettiva delle route basate su criteri e statiche nelle tabelle di routing VPC. Le route basate su criteri sono più flessibili rispetto a quelle standard perché hanno corrispondenze sia per le informazioni di origine sia per 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 reindirizzamento del traffico molto specifico per flussi di connettività molto specifici.

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

Sicurezza perimetrale NVA con NIC singolo

Nel design descritto in Connettività tra VPC per i servizi centralizzati, il VPC in transito funge da hub per i VPC spoke connessi utilizzando il peering di rete VPC e la VPN ad alta disponibilità. Il VPC in transito consente anche la connettività tra le reti esterne e i VPC dello spoke.

Ai fini dell'inserimento dell'NVA con NIC singolo, questo design 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 gli NVA inseriti 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:

  • Un VPC in transito che ospita i collegamenti VLAN di Cloud Interconnect che forniscono connettività ibrida o multi-cloud. Questo VPC contiene anche gli NVA a NIC singolo che monitorano le connessioni ibride.
  • VPC dell'applicazione connessi al VPC in transito tramite peering di rete VPC.
  • Un VPC di servizi centrali connesso al VPC di transito su VPN ad alta disponibilità.

In questo progetto, gli spoke connessi tramite VPN ad alta disponibilità utilizzano il VPC in transito per comunicare con gli spoke connessi tramite peering di rete VPC. La comunicazione viene indirizzata 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à verso il bilanciatore del carico interno, applica route basate su criteri senza tag al VPC di Transit. In queste route basate su criteri, utilizza intervalli CIDR di origine e di destinazione che forniscano 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 Transit. Si tratta di route a livello di regione.
  3. Per fare in modo che il traffico in uscita dall'NVA non venga reindirizzato direttamente all'NVA, imposta tutte le interfacce NVA come destinazione di una route basata su criteri ignorati per saltare altre route basate su criteri. Il traffico segue quindi la tabella di routing VPC dopo essere stato elaborato dagli NVA.
  4. Per indirizzare il traffico verso i bilanciatori del carico interni di NVA nel VPC Transit, applica route statiche ai VPC dell'applicazione. Queste possono essere definite a livello di regione utilizzando i tag di rete.

Sicurezza perimetrale NVA multi-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 su interfaccia, la seguente progettazione multi-NIC consente la connettività esterna richiesta. Questo design assegna interfacce firewall diverse alle reti esterne. Le reti esterne sono indicate dai professionisti della sicurezza come reti non attendibili, mentre le reti interne sono note come reti attendibili. Per il deployment multi-NIC NVA, questo design viene implementato utilizzando VPC attendibili e non attendibili.

Per le comunicazioni interne, è possibile applicare il firewall utilizzando un modello di inserzione a NIC singolo che corrisponde a un modello di zona basato su CIDR.

In questa struttura, puoi inserire gli NVA configurando come segue:

  1. Per indirizzare il traffico VPN ad alta disponibilità verso il 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 forniscano la simmetria del traffico.
  2. Per indirizzare il traffico in entrata verso il bilanciatore del carico di rete passthrough interno, applica route basate su criteri alle connessioni Cloud Interconnect nel VPC non attendibile. Si tratta di route a livello di regione.
  3. Per fare in modo che il traffico in uscita dall'NVA non venga reindirizzato direttamente all'NVA, imposta tutte le interfacce NVA come destinazione di una route basata su criteri ignorati per saltare altre route basate su criteri. Il traffico segue quindi la tabella di routing VPC dopo essere stato elaborato dagli NVA.
  4. Per indirizzare il traffico verso i bilanciatori del carico interni di NVA nel VPC attendibile, applica route statiche ai VPC dell'applicazione. Queste possono essere definite a livello di regione utilizzando i tag di rete.

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

NVA per comunicazione interna

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: