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 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 del dominio

La sicurezza dei carichi di lavoro controlla la comunicazione tra i carichi di lavoro e all'interno il VPC (Virtual Private Cloud). La sicurezza dei carichi di lavoro utilizza l'applicazione della sicurezza simili ai carichi di lavoro nell'architettura. Se possibile, La rete cross-cloud offre la sicurezza dei carichi di lavoro utilizzando Firewall di nuova generazione 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 i VPC
  • Comunicazioni tramite connessioni ibride ad altri provider cloud o data center on-premise
  • Comunicazioni verso 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 un firewall stateful scalabili orizzontalmente e applicate a ogni istanza VM. La la natura distribuita dei firewall di Google Cloud ti aiuta a implementare politiche per la micro-segmentazione di rete senza influire negativamente sul delle prestazioni 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 consentono di creare e applicare il criterio firewall in tutta l'organizzazione. Puoi assegnare Criteri firewall gerarchici per l'organizzazione o per 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 risorsa nella gerarchia. Questa struttura di regole consente agli amministratori a livello di organizzazione regole firewall obbligatorie in un unico posto. Casi d'uso comuni per I criteri firewall gerarchici includono un bastion host dell'organizzazione o di più progetti l'accesso ai sistemi di sonda e controllo di integrità centralizzati, nonché il confine della rete virtuale in un'organizzazione o un gruppo di progetti. Per ulteriori esempi di utilizzo Criteri firewall gerarchici; consulta Criteri firewall gerarchici esempi.

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 Identity and Access Management (IAM) controllato tag nell'organizzazione o nel progetto livello. 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 VPC Network Peering. Le regole del firewall implementate utilizzando i tag possono fornire una micro-segmentazione intra-subnet 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 il filtro della geolocalizzazione.

Ti consigliamo di eseguire la migrazione dalle regole firewall VPC a 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 è solitamente implementati 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 per tutte le comunicazioni, puoi unificare e centralizzare i controlli di sicurezza perimetrali e implementare un'unica serie di firewall perimetrali nella tua rete. per garantire una sicurezza perimetrale integrata uno stack preferito, Cross-Cloud Network offre per inserire gli 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 singolo NIC per le VM, 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 inter-VPC.
  • Abilita la scalabilità automatica per le VM.
  • Esegui il ridimensionamento a molti VPC nel tempo, senza modifiche necessarie al deployment dell'interfaccia NVA.

Se la progettazione richiede più NIC, i consigli sono descritti in dettaglio nella sezione Più NIC Sicurezza perimetrale NVA.

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 alle route standard perché corrispondono sia alle informazioni di origine che a quelle di destinazione. Queste route basate su criteri vengono applicate anche solo in luoghi specifici nella 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à. Il VPC di transito consente inoltre la connettività tra reti esterne e i VPC spoke.

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

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

VNA inserite negli hub per peering di rete VPC e 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 è guidata attraverso firewall NVA di terze parti utilizzando la seguente combinazione di carico passthrough di bilanciamento del carico, route statiche e 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 destinazione che prevedono la simmetria del traffico.
  2. Per indirizzare il traffico in entrata al bilanciatore del carico di rete passthrough interno, applica route basate su criteri a le connessioni Cloud Interconnect nel traffico in un VPC. Si tratta di route 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 di NVA in transito VPC, applica route statiche all'applicazione VPC. Questi possono essere limitati 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 richieste zone basate sull'interfaccia, i seguenti NIC multipli consente la connettività esterna richiesta. Questo design assegna diversi le interfacce del firewall con le 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 con più NIC, questa progettazione è implementata utilizzando VPC attendibili e non attendibili.

Per le comunicazioni interne, il firewall può essere applicato utilizzando un singolo 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 senza tag al VPC attendibile. In queste basate su criteri, usano intervalli CIDR di origine e di destinazione che forniscono simmetria del traffico.
  2. Per indirizzare il traffico in entrata al bilanciatore del carico di rete passthrough interno, applica route basate su criteri a le connessioni Cloud Interconnect nel nodo non attendibile in un VPC. Si tratta di route 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 una volta che è stata elaborati 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 VM con più NIC inserite tra le unità non attendibili e reti VPC attendibili nel progetto hub:

NVA per la comunicazione interna

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: