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 tenere in considerazione le seguenti piattaforme per la 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 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 di rete. Poiché il perimetro di solito interconnette reti gestite da organizzazioni diverse, spesso sono necessari controlli di sicurezza più rigidi. Devi assicurarti che: le comunicazioni tra le reti siano protette:

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

La possibilità di inserire appliance virtuali di rete di terze parti (NVA) all'interno L'ambiente Google Cloud è fondamentale per soddisfare i requisiti la sicurezza perimetrale sulle 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 la sicurezza politiche per la micro-segmentazione della 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 il firewall criteri. 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 criteri firewall di livello inferiore (criteri firewall di rete globali o regionali) con 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 indagine o di controllo di integrità centralizzati e all'applicazione 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.

Usa una rete globale e regionale criteri firewall per definire le regole su una singola rete VPC, per tutte le regioni rete (globale) o una singola regione (regionale).

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 basate sull'identità dell'host dei carichi di lavoro, anziché dell'indirizzo IP dell'host, e funziona peering di rete VPC. Le regole firewall distribuite utilizzando i tag possono fornire micro-segmentazione con copertura di criteri che si applica automaticamente ai carichi di lavoro ovunque venga eseguito il deployment, 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 il strumento, che crea un criterio firewall di rete globale e converte le regole firewall VPC 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 una propria firewall perimetrali, mentre ogni rete cloud implementa firewall perimetrali.

Poiché la rete cross-cloud è progettata per essere l'hub per delle comunicazioni, puoi unificare e centralizzare i controlli di sicurezza perimetrali di un singolo insieme di firewall perimetrali tra cloud. per garantire una sicurezza perimetrale integrata uno stack preferito, Cross-Cloud Network offre per inserire gli NVA.

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

Le VM possono essere implementate su una singola interfaccia di rete (modalità NIC singolo) o su più interfacce di rete in più VPC (multi-NIC ). 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 varietà di topologie tra VPC.
  • Abilita la scalabilità automatica per le VM.
  • Scalabilità su più VPC nel tempo, senza modifiche necessarie alle 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 reindirizzamento del traffico necessario per il deployment di NVA, questo consiglia l'applicazione selettiva di route statiche e basate su criteri nelle tabelle di routing del VPC. Le route basate su criteri sono più Flessibili rispetto a quelle standard perché le route basate su criteri corrispondono sia all'origine sia alla destinazione informazioni. 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 reindirizzamento del traffico specifico per flussi di connettività molto specifici.

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

Sicurezza perimetrale NVA con singolo NIC

Nella progettazione descritta in Connettività tra VPC per centralizzato servizi, il VPC di transito agisce da hub per i VPC spoke connesse tramite peering di rete VPC e 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
  • Inserisci gli NVA in un hub VPC VPN ad alta disponibilità con connessioni ibride esterne

Il seguente diagramma mostra gli VNA inseriti negli hub per Peering di rete VPC e 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 la VLAN Cloud Interconnect che forniscono connettività ibrida o multi-cloud. Questo VPC contiene le VM a NIC singolo che monitorano le connessioni ibride.
  • VPC delle applicazioni connesse al VPC di transito tramite il peering di rete VPC.
  • Un VPC di servizi centrali connesso al trasporto pubblico su una VPN ad alta disponibilità.

In questa progettazione, gli spoke collegati tramite VPN ad alta disponibilità usano il VPC di transito per comunicare con gli spoke connesse tramite 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 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 traffico in un VPC. Si tratta di route regionali.
  3. Per fare in modo che il traffico in uscita dall'NVA non venga reindirizzato direttamente all'NVA, imposta tutte le interfacce NVA come target di uno salvo criterio basato su criteri route per saltare le altre basate su criteri route. 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 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 multi-NIC

In modalità multi-NIC, la topologia è più statica perché gli asset creati automaticamente collegano le reti connettività tra i diversi VPC in cui 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 come dai professionisti della sicurezza alle reti non attendibili, mentre le reti interne note come reti attendibili. Per il deployment di 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 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 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. Per fare in modo che il traffico in uscita dall'NVA non venga reindirizzato direttamente all'NVA, imposta tutte le interfacce NVA come target di uno salvo criterio basato su criteri route per saltare le altre basate su criteri route. 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 nell'ambiente VPC, applica route statiche all'applicazione VPC. 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 unità non attendibili e reti VPC attendibili nel progetto hub:

VNA per la comunicazione interna

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: