Best practice e architetture di riferimento per la progettazione di VPC

Last reviewed 2024-05-31 UTC

Questa guida illustra le best practice e le architetture aziendali tipiche per la progettazione di virtual private cloud (VPC) con Google Cloud. Questa guida è rivolta agli architetti di reti cloud e agli architetti di sistema che hanno già familiarità con i concetti di Google Cloud networking.

Principi generali e primi passaggi

Identifica i responsabili delle decisioni, le tempistiche e le attività preliminari

Come primo passaggio nella progettazione della rete VPC, identifica i responsabili decisionali, le tempistiche e il lavoro preliminare necessari per assicurarti di poter soddisfare i requisiti degli stakeholder.

Gli stakeholder possono includere proprietari di applicazioni, architetti della sicurezza, architetti delle soluzioni e gestori delle operazioni. Gli stakeholder stessi potrebbero cambiare a seconda che tu stia pianificando la tua rete VPC per un progetto, un'attività commerciale o l'intera organizzazione.

Parte del lavoro preliminare consiste nell'iniziare ad acquisire familiarità con i concetti e la terminologia relativi alla progettazione della rete VPC. I documenti utili includono quanto segue:

Considera in anticipo la progettazione della rete VPC

Rendi la progettazione della rete VPC una prima parte della progettazione della configurazione della tua organizzazione in Google Cloud. Può essere dannoso per la tua organizzazione se in un secondo momento dovrai modificare aspetti fondamentali come la segmentazione della rete o la posizione dei tuoi workload.

Configurazioni diverse della rete VPC possono avere implicazioni significative per il routing, la scalabilità e la sicurezza. Una pianificazione attenta e una conoscenza approfondita delle tue considerazioni specifiche ti aiutano a creare una solida base di architettura per i carichi di lavoro incrementali.

Scegli la semplicità

Mantenere semplice il design della topologia di rete VPC è il modo migliore per garantire un'architettura gestibile, affidabile e ben compresa.

Utilizza convenzioni di denominazione chiare

Rendi le convenzioni di denominazione semplici, intuitive e coerenti. In questo modo, gli amministratori e gli utenti finali comprendono lo scopo di ciascuna risorsa, dove si trova e come si differenzia dalle altre risorse.

Le abbreviazioni comunemente accettate delle parole lunghe contribuiscono alla brevità. Se possibile, utilizza una terminologia familiare per migliorare la leggibilità.

Quando stabilisci le convenzioni di denominazione, prendi in considerazione i componenti illustrati nel seguente esempio:

  • Nome dell'azienda: Acme Company: acmeco
  • Unità aziendale: Risorse umane: hr
  • Codice applicazione: sistema di compensazione: comp
  • Codice regione: northamerica-northeast1: na-ne1, europe-west1: eu-we1
  • Codici ambiente: dev, test, uat, stage, prod

In questo esempio, l'ambiente di sviluppo per il sistema di compensazione del reparto delle risorse umane è denominato acmeco-hr-comp-eu-we1-dev.

Per altre risorse di networking comuni, prendi in considerazione pattern come questi:

  • Rete VPC
    sintassi: {company name}-{description(App or BU)-label}-{environment-label}-{seq#}
    esempio: acmeco-hr-dev-vpc-1

  • Subnet
    sintassi: {company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
    esempio: acmeco-hr-na-ne1-dev-vpc-1-subnet-1
    nota: se la subnet contiene risorse in una sola zona, puoi utilizzare "etichetta-zona" anziché "etichetta-regione".

  • Regola firewall
    sintassi: {company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
    esempio: acmeco-hr-internet-internal-tcp-80-allow-rule

  • Percorso IP
    sintassi: {priority}-{VPC-label}-{tag}-{next hop}
    esempio: 1000-acmeco-hr-dev-vpc-1-int-gw

Indirizzi e subnet

Utilizzare le reti VPC in modalità personalizzata

Quando avvii il tuo primo progetto, viene impostata la rete predefinita, ovvero una rete VPC in modalità automatica denominata default. Le reti in modalità automatica creano automaticamente subnet e route di subnet corrispondenti i cui intervalli IP principali sono CIDR /20in ogni Google Cloud regione utilizzando un insieme prevedibile di intervalli di indirizzi RFC 1918. La rete default include anche alcune regole firewall precompilate.

Sebbene le reti in modalità automatica possano essere utili per le prime esplorazioni, le reti VPC in modalità personalizzata sono più adatte alla maggior parte degli ambienti di produzione.

Consigliamo alle aziende di utilizzare le reti VPC in modalità personalizzata fin dall'inizio per i seguenti motivi:

  • Le reti VPC in modalità personalizzata si integrano meglio negli schemi di gestione degli indirizzi IP esistenti. Poiché tutte le reti in modalità automatica utilizzano lo stesso insieme di intervalli IP interni, gli intervalli IP in modalità automatica potrebbero sovrapporsi quando sono connessi alle reti aziendali on-premise.
  • Non puoi connettere due reti VPC in modalità automatica utilizzando il peering di rete VPC perché le relative subnet utilizzano intervalli IP principali identici.
  • Le subnet in modalità automatica hanno tutte lo stesso nome della rete. Puoi scegliere nomi descrittivi e univoci per le subnet in modalità personalizzata, rendendo le reti VPC più comprensibili e gestibili.
  • Quando viene introdotta una nuova Google Cloud regione, le reti VPC in modalità automatica ricevono automaticamente una nuova subnet in quella regione. Le reti VPC in modalità personalizzata ricevono nuove subnet solo se le specifichi. Questo può essere importante sia per motivi di sovranità sia per la gestione degli indirizzi IP.

Se non contiene risorse, puoi eliminare la rete default. Non puoi eliminare una rete VPC finché non hai rimosso tutte le risorse, incluse le istanze di macchine virtuali (VM), che dipendono da essa.

Per ulteriori dettagli sulle differenze tra le reti VPC in modalità automatica e personalizzata, consulta la panoramica delle reti VPC.

Raggruppa le applicazioni in un numero inferiore di subnet con intervalli di indirizzi più ampi

Per convenzione, alcune reti aziendali sono suddivise in molti piccoli intervalli di indirizzi per una serie di motivi. Ad esempio, questo potrebbe essere stato fatto per identificare o isolare un'applicazione o mantenere un piccolo dominio di trasmissione.

Tuttavia, ti consigliamo di raggruppare le applicazioni dello stesso tipo in meno subnet più gestibili con intervalli di indirizzi più ampi nelle regioni in cui vuoi operare.

A differenza di altri ambienti di rete in cui viene utilizzata una subnet mask,Google Cloud utilizza un approccio di networking software-defined (SDN) per fornire un mesh completo di raggiungibilità tra tutte le VM nella rete VPC globale. Il numero di sottoreti non influisce sul comportamento del routing.

Puoi utilizzare account di servizio o tag di rete per applicare policy di routing o regole firewall specifici. L'identità in Google Cloud non si basa esclusivamente sull'indirizzo IP della subnet.

Alcune funzionalità VPC, tra cui Cloud NAT, Accesso privato Google, Log di flusso VPC e intervalli IP alias, sono configurate per subnet. Se hai bisogno di un controllo più granulare di queste funzionalità, utilizza sottoreti aggiuntive.

Rete VPC singola e VPC condiviso

Inizia con una singola rete VPC per le risorse con requisiti comuni

Per molti casi d'uso semplici, un'unica rete VPC fornisce le funzionalità di cui hai bisogno, ma è più facile da creare, mantenere e comprendere rispetto alle alternative più complesse. Raggruppando le risorse con requisiti e caratteristiche comuni in un'unica rete VPC, inizi a stabilire il confine della rete VPC come perimetro per potenziali problemi.

Per un esempio di questa configurazione, consulta l'architettura di riferimento per un singolo progetto e una singola rete VPC.

I fattori che potrebbero portarti a creare reti VPC aggiuntive includono scalabilità, sicurezza di rete, considerazioni finanziarie, requisiti operativi e gestione dell'identità e dell'accesso (IAM).

Utilizza il VPC condiviso per l'amministrazione di più gruppi di lavoro

Per le organizzazioni con più team, il VPC condiviso fornisce uno strumento efficace per estendere la semplicità dell'architettura di una singola rete VPC a più gruppi di lavoro. L'approccio più semplice prevede l'esecuzione del deployment di un singolo progetto host del VPC condiviso con una singola rete VPC condivisa e poi il collegamento dei progetti di servizio di gruppo alla rete del progetto host.

In questa configurazione, i criteri di rete e il controllo per tutte le risorse di networking sono centralizzati e più facili da gestire. I reparti dei progetti di servizio possono configurare e gestire le risorse non di rete, in modo da avere una chiara separazione delle responsabilità per diversi team dell'organizzazione.

Le risorse in questi progetti possono comunicare tra loro in modo più sicuro ed efficiente oltre i confini dei progetti utilizzando indirizzi IP interni. Puoi gestire risorse di rete condivise come subnet, route e firewall da un progetto host centrale, in modo da applicare criteri di rete coerenti a tutti i progetti.

Per un esempio di questa configurazione, consulta l'architettura di riferimento Singolo progetto host, più progetti di servizio, singola VPC condivisa.

Concedi il ruolo utente di rete a livello di subnet

L'amministratore della VPC condivisa centralizzata può concedere ai membri IAM il ruolo Utente di rete (networkUser) a livello di subnet, per l'autorizzazione granulare dei progetti di servizio, o per tutte le subnet a livello di progetto host.

In base al principio del privilegio minimo, ti consigliamo di concedere il ruolo utente di rete a livello di sottorete all'utente, all'account di servizio o al gruppo associato.

Poiché le subnet sono regionali, questo controllo granulare ti consente di specificare le regioni che ogni progetto di servizio può utilizzare per il deployment delle risorse.

Con le architetture VPC condivise, hai anche la flessibilità di implementare più progetti host VPC condivisi all'interno della tua organizzazione. Ogni progetto host VPC condivisa può quindi ospitare una o più reti VPC condivise. In questa configurazione, ambienti diversi possono applicare facilmente problemi relativi a criteri diversi.

Per saperne di più, consulta Ruoli IAM per la rete.

Utilizza un singolo progetto host se le risorse richiedono più interfacce di rete

Se hai un progetto di servizio che deve eseguire il deployment di risorse in più reti VPC isolate, ad esempio istanze VM con più interfacce di rete, il progetto host deve contenere tutte le reti VPC che forniscono i servizi. Questo perché un progetto di servizio può essere collegato a un solo progetto host.

Progetto di servizio a più VPC

Utilizza più progetti host se i requisiti delle risorse superano la quota di un singolo progetto

Se i requisiti di risorse aggregate di tutte le reti VPC non possono essere soddisfatti all'interno della quota di un progetto, utilizza un'architettura con più progetti host con una singola rete VPC condivisa per progetto host, anziché un singolo progetto host con più reti VPC condivise. È importante valutare i requisiti di scalabilità, poiché l'utilizzo di un singolo progetto host richiede più reti VPC nel progetto host e le quote vengono applicate a livello di progetto.

Per un esempio di questa configurazione, consulta la sezione Architettura di riferimento con più progetti host, più progetti di servizio e più VPC condivise.

Utilizza più progetti host se hai bisogno di criteri di amministrazione separati per ogni rete VPC

Poiché ogni progetto ha una propria quota, utilizza un progetto host VPC condiviso distinto per ogni rete VPC per scalare le risorse aggregate. In questo modo, ogni rete VPC può avere autorizzazioni IAM separate per la gestione della rete e della sicurezza, poiché le autorizzazioni IAM vengono implementate anche a livello di progetto. Ad esempio, se esegui il deployment di due reti VPC (rete VPC A e rete VPC B) nello stesso progetto host, il ruolo di amministratore di rete (networkAdmin) si applica a entrambe le reti VPC.

Decidere se creare più reti VPC

Crea una singola rete VPC per progetto per mappare le quote delle risorse VPC ai progetti

Le quote sono vincoli applicati a livello di progetto o rete. Tutte le risorse hanno una quota predefinita iniziale pensata per proteggerti da un utilizzo imprevisto delle risorse. Tuttavia, molti fattori potrebbero spingerti a richiedere una quota maggiore. Per la maggior parte delle risorse, puoi richiedere una quota aggiuntiva.

Ti consigliamo di creare una singola rete VPC per progetto se prevedi di superare le quote di risorse VPC predefinite. In questo modo è più facile mappare gli aumenti di quota a livello di progetto a ogni rete VPC anziché a una combinazione di reti VPC nello stesso progetto.

I limiti sono progettati per proteggere le risorse del sistema in modo aggregato. In genere i limiti non possono essere aumentati facilmente, anche se Google Cloud i team di assistenza e vendita possono collaborare con te per aumentare alcuni limiti.

Per i valori attuali, consulta Quote e limiti delle risorse VPC.

L'Assistenza Google può aumentare alcuni limiti di scalabilità, ma a volte potrebbe essere necessario creare più reti VPC per soddisfare i requisiti di scalabilità. Se la tua rete VPC deve essere scalata oltre i limiti, parla della tua richiesta con i team di vendita e assistenzaGoogle Cloud sulla strategia migliore per le tue esigenze.

Crea una rete VPC per ogni team autonomo, con servizi condivisi in una rete VPC comune

Alcuni implementazioni di grandi aziende coinvolgono team autonomi che richiedono ciascuno il controllo completo sulle rispettive reti VPC. Puoi soddisfare questo requisito creando una rete VPC per ogni unità aziendale, con servizi condivisi in una rete VPC comune (ad esempio strumenti di analisi, pipeline CI/CD e build machine, servizi DNS/Directory). Per ulteriori informazioni sulla creazione di una rete VPC comune per i servizi condivisi, consulta la sezione relativa ai servizi condivisi.

Crea reti VPC in progetti diversi per controlli IAM indipendenti

Una rete VPC è una risorsa a livello di progetto con controlli IAM (Identity and Access Management) granulari a livello di progetto, inclusi i seguenti ruoli:

  • networkAdmin
  • securityAdmin
  • networkUser
  • networkViewer

Per impostazione predefinita, i controlli IAM vengono implementati a livello di progetto e ogni ruolo IAM si applica a tutte le reti VPC all'interno del progetto.

Se hai bisogno di controlli IAM indipendenti per ogni rete VPC, crea le reti VPC in progetti diversi.

Se hai bisogno di ruoli IAM limitati a risorse Compute Engine specifiche, come istanze VM, dischi e immagini, utilizza i criteri IAM per le risorse Compute Engine.

Isolare i dati sensibili nella propria rete VPC

Per le aziende che si occupano di iniziative di conformità, dati sensibili o dati soggetti a regolamentazioni severe e vincolati da standard di conformità come HIPAA o PCI-DSS, spesso è opportuno adottare ulteriori misure di sicurezza. Un metodo che può migliorare la sicurezza e semplificare la verifica della conformità è isolare ciascuno di questi ambienti nella propria rete VPC.

Connessione di più reti VPC

Scegli il metodo di connessione VPC che soddisfa le tue esigenze in termini di costi, prestazioni e sicurezza

Il passaggio successivo dopo aver deciso di implementare più reti VPC è collegarle. Le reti VPC sono spazi tenant isolati all'interno della SDN di Andromeda di Google, ma esistono diversi modi per abilitare la comunicazione tra di loro. Le sezioni successive forniscono le best practice per la scelta di un metodo di connessione VPC.

I vantaggi e gli svantaggi di ciascuno sono riassunti nella tabella seguente e le sezioni successive forniscono le best practice per la scelta di un metodo di connessione VPC.

Vantaggi Svantaggi
Peering di reti VPC
  • Facile da configurare.
  • Basso overhead per la gestione.
  • Larghezza di banda elevata.
  • Bassi costi di uscita (come per una singola rete VPC).
  • Ogni rete VPC gestisce il proprio firewall distribuito.
  • Ogni rete VPC gestisce i propri account e le proprie autorizzazioni IAM.
  • Non transitivo.
  • I numeri di scalabilità sono associati al gruppo aggregato di reti VPC in peering. Sono inclusi il numero di VM, route e regole di inoltro interno.
  • Richiede uno spazio degli indirizzi non sovrapposto.
  • Le route statiche e dinamiche non vengono propagate.
  • I tag di origine e gli account di servizio di origine della VM di invio non vengono propagati tra il peering di rete VPC.
Routing esterno (IP pubblico o gateway NAT)
  • Nessuna configurazione richiesta.
  • Isolamento completo tra le reti VPC.
  • È possibile che lo spazio degli indirizzi IP si sovrapponga.
  • Larghezza di banda elevata.
  • Gli addebiti per il traffico in uscita per le VM all'interno della stessa zona sono superiori rispetto ad altre opzioni, come il peering di rete VPC.
  • Le VM devono essere esposte utilizzando indirizzi IP esterni.
  • Nessun firewall che utilizza indirizzi IP privati.
  • Le route statiche e dinamiche non vengono propagate.
  • I tag di origine e gli account di servizio di origine della VM di invio non vengono rispettati dalle reti con peering.
Cloud VPN
  • Cloud VPN consente topologie transitive per hub e spoke.
  • Scalabile tramite ECMP.
  • SLA con disponibilità del servizio del 99,99% sulla VPN ad alta disponibilità.
  • Overhead di gestione.
  • Fatturato in base alle tariffe per il traffico in uscita da internet.
  • Latenza leggermente superiore.
  • La velocità in bit è limitata a 3 Gbps per tunnel.
  • MTU inferiore a causa di un'ulteriore incapsulazione del tunnel.
  • I tag di origine e gli account di servizio di origine della VM di invio vengono persi nel tunnel.
Cloud Interconnect - Dedicato o partner
  • SLA supportati in base alla ridondanza nel deployment:
  • Ogni link di un Dedicated Interconnect è una connessione da 10 Gbps o 100 Gbps. È possibile raggruppare più collegamenti di interconnessione per aumentare il throughput, con un massimo di 8 circuiti da 10 Gbps (80 Gbps) o 2 circuiti da 100 Gbps (200 Gbps) per ogni connessione Dedicated Interconnect.
  • È possibile utilizzare ECMP su più interconnessioni per aumentare la velocità in uscita.
  • Costi aggiuntivi e addebiti in uscita per il traffico inviato tra reti VPC tramite una connessione Interconnect.
  • Il traffico non è criptato.
  • Latenza aggiuntiva rispetto alle soluzioni cloud-native.
  • Dispositivi hardware aggiuntivi nel percorso che possono non funzionare.
Più interfacce di rete (Multi-NIC)
  • Scalabile tramite gruppi di istanze gestite e route ECMP tra le istanze.
  • Le singole VM hanno [limiti di larghezza di banda](/compute/docs/network-bandwidth).
  • Limite di 8 interfacce per istanza.
  • Il bilanciatore del carico di rete passthrough interno supporta l'invio di traffico a [qualsiasi interfaccia](/load-balancing/docs/internal#backend-service-multi-nic) della VM. Altri bilanciatori del carico supportano solo l'interfaccia di rete predefinita (nic0) di una VM.

Utilizza il peering di rete VPC se non superi i limiti di risorse

Ti consigliamo di utilizzare il peering di rete VPC quando devi connettere reti VPC e non puoi utilizzare un singolo VPC condiviso, a condizione che i totali delle risorse necessarie per tutti i peer connessi direttamente non superino i limiti relativi a istanze VM, numero di connessioni di peering e regole di inoltro interno.

Il peering di rete VPC consente a due reti VPC di connettersi tra loro internamente tramite la rete SDN di Google, indipendentemente dal fatto che appartengano o meno allo stesso progetto o alla stessa organizzazione. Il peering di rete VPC unisce il piano di controllo e la propagazione del flusso tra ciascun peer, consentendo le stesse caratteristiche di inoltro come se tutte le VM si trovassero nella stessa rete VPC. Quando le reti VPC sono in peering, tutte le subnet, gli intervalli IP degli alias e le regole di inoltro interno sono accessibili e ogni rete VPC gestisce il proprio firewall distribuito. Il peering di rete VPC non è transitivo.

Il peering di rete VPC è il metodo preferito per connettere le reti VPC per i seguenti motivi:

  • Nessun collo di bottiglia del gateway: il traffico viene inoltrato tra i peer come se le VM fossero nella stessa rete VPC.
  • Fatturazione: non vengono addebitati costi aggiuntivi. La fatturazione avviene come se le VM si trovassero nella stessa rete VPC.

Utilizza il routing esterno se non hai bisogno di comunicare con indirizzi IP privati

Se non hai bisogno di comunicare con indirizzi IP privati, puoi utilizzare il routing esterno con indirizzi IP esterni o un gateway NAT.

Quando viene implementata una rete VPC, viene eseguito il provisioning di una route per il gateway internet predefinito di Google con una priorità di 1000. Se questa route esiste e a una VM viene assegnato un indirizzo IP esterno, le VM possono inviare traffico in uscita (di entrata) tramite il gateway internet di Google. Puoi anche implementare i servizi dietro una delle numerose offerte di bilanciamento del carico pubblico di Google, che consente di raggiungerli dall'esterno.

Le VM con indirizzi esterni comunicano tra loro in privato tramite la backbone di Google, indipendentemente dalla regione e dai livelli di servizio di rete. Utilizza Google Cloud le regole firewall per controllare il traffico in entrata (ingress) esterno alle tue VM.

Il routing esterno è una buona opzione per il ridimensionamento, ma è importante comprendere in che modo il routing pubblico influisce sui costi. Per maggiori dettagli, consulta la documentazione sui prezzi di rete.

Utilizza Cloud VPN per connettere reti VPC che altrimenti supererebbero i limiti aggregati del gruppo di peering

La VPN ad alta disponibilità fornisce un servizio gestito per connettere le reti VPC creando tunnel IPsec tra insiemi di endpoint. Se configuri i router Cloud con la modalità di annuncio personalizzata, puoi attivare il routing transitivo tra le reti VPC e le topologie hub and spoke come descritto più avanti in questo documento. Con Network Connectivity Center, puoi utilizzare i tunnel VPN ad alta disponibilità come rete di transito tra le reti on-premise, come spiegato nella documentazione di Cloud VPN.

Cloud VPN non supporta MTU di grandi dimensioni. Per maggiori dettagli, consulta Considerazioni sulla MTU.

Utilizzare Cloud Interconnect per controllare il traffico tra le reti VPC tramite un dispositivo on-premise

Cloud Interconnect estende la tua rete on-premise alla rete di Google tramite una connessione a disponibilità elevata e a bassa latenza. Puoi utilizzare Dedicated Interconnect per connetterti direttamente a Google o utilizzare Partner Interconnect per connetterti a Google tramite un provider di servizi supportato.

Dedicated Interconnect fornisce un servizio L2 ad alta velocità tra Google e un provider di colocation o una sede on-premise. In questo modo, puoi utilizzare l'apparecchiatura di routing on-premise per eseguire il routing tra le reti VPC e utilizzare i servizi di sicurezza e ispezione on-premise esistenti per filtrare tutto il traffico tra le reti VPC. Tutto il traffico tra le due reti VPC presenta una latenza aggiuntiva a causa di un viaggio di andata e ritorno aggiuntivo attraverso il sistema on-premise.

Partner Interconnect offre funzionalità simili, nonché la possibilità di eseguire il peering direttamente con un provider a livello L3 e di far eseguire il routing del provider tra le reti VPC. In questo modo, puoi accedere agli indirizzi IP interni della tua rete on-premise e delle tue reti Google Cloud VPC senza un dispositivo NAT o un tunnel VPN.

Poiché molte appliance di sicurezza aziendale possono essere utilizzate su VM con più interfacce di rete, l'utilizzo di Cloud Interconnect per instradare il traffico tra le reti VPC non è necessario, tranne in pochissimi casi in cui tutto il traffico deve passare attraverso un'appliance on-premise a causa delle norme aziendali. Google Cloud

Utilizza le appliance virtuali per controllare il traffico tra le reti VPC tramite un dispositivo cloud

Più VM con interfaccia di rete sono comuni per le reti VPC che richiedono sicurezza o servizi aggiuntivi tra di loro, perché più VM con interfaccia di rete consentono alle istanze VM di fare da ponte per la comunicazione tra le reti VPC.

Una VM può avere una sola interfaccia per ogni rete VPC a cui si connette. Per eseguire il deployment di una VM in più reti VPC, devi disporre dell'autorizzazione IAM appropriata per ogni rete VPC a cui si connette la VM.

Tieni presente le seguenti caratteristiche durante il deployment di una VM con più NIC:

  • Una VM con più NIC può avere un massimo di 8 interfacce.
  • Gli intervalli IP delle subnet delle interfacce non devono sovrapporsi.

Multi-NIC con VPC condiviso

Crea una VPC di servizi condivisi se più reti VPC devono accedere a risorse comuni, ma non tra di loro

Una rete VPC fornisce un mesh completo di raggiungibilità globale. Per questo motivo, i servizi condivisi e le pipeline di integrazione continua che si trovano nella stessa rete VPC non richiedono particolari considerazioni in termini di connettività, in quanto sono intrinsecamente accessibili. Il VPC condiviso espande questo concetto, consentendo ai servizi condivisi di risiedere in un progetto isolato e al contempo di fornire connettività ad altri servizi o consumer.

Gli approcci ai servizi condivisi includono Private Service Connect, peering di rete VPC e Cloud VPN. Utilizza Private Service Connect se non riesci a farlo per qualche motivo. Puoi utilizzare il peering di rete VPC per connetterti a una rete VPC di servizi condivisi se non superi i limiti di risorse aggregate e non vuoi configurare endpoint per ogni servizio. Puoi anche utilizzare Cloud VPN per connettere reti VPC di servizi condivisi che altrimenti supererebbero i limiti aggregati del gruppo di peering.

Private Service Connect ti consente di rendere disponibile un servizio ospitato in una rete per le VM in un'altra rete creando un endpoint speciale nella rete consumer. La configurazione di Private Service Connect indirizza quindi il traffico per quel servizio tra le due reti.

I consumatori possono utilizzare i propri indirizzi IP interni per accedere ai servizi senza uscire dalle loro reti VPC o utilizzare indirizzi IP esterni. Il traffico rimane interamente all'interno di Google Cloud. Private Service Connect fornisce accesso orientato ai servizi tra consumer e producer con controllo granulare sul modo in cui viene eseguito l'accesso ai servizi.

Nel modello di peering di rete VPC, ogni rete VPC crea una relazione di peering con una rete VPC di servizi condivisi comuni per garantire la raggiungibilità. Il peering di rete VPC introduce considerazioni di scalabilità, poiché i limiti di scalabilità si applicano all'utilizzo aggregato delle risorse di tutti i peer.

servizi con VPC Network Peering

Il peering di reti VPC può essere utilizzato anche in combinazione con l'accesso ai servizi privati e l'API Service Networking. Con l'API Service Networking, puoi consentire ai clienti della stessa organizzazione o di un'altra organizzazione di utilizzare un servizio che fornisci, ma lasciando loro scegliere l'intervallo di indirizzi IP da connettere utilizzando il peering di rete VPC.

Cloud VPN è un'altra alternativa. Poiché Cloud VPN stabilisce la raggiungibilità tramite tunnel IPsec gestiti, non ha i limiti aggregati del peering di rete VPC. Cloud VPN utilizza un gateway VPN per la connettività e non tiene conto dell'utilizzo aggregato delle risorse del peer IPsec. Gli svantaggi di Cloud VPN includono costi elevati (tunnel VPN e traffico in uscita), il sovraccarico di gestione necessario per la manutenzione dei tunnel e il sovraccarico delle prestazioni di IPsec.

servizi condivisi con Cloud VPN

Progettazione ibrida: connessione di un ambiente on-premise

Dopo aver identificato la necessità di una connettività ibrida e aver scelto una soluzione che soddisfi i requisiti di larghezza di banda, prestazioni e sicurezza, valuta come integrarla nel design della VPC.

L'utilizzo della VPC condivisa elimina la necessità di replicare la stessa soluzione in ogni progetto. Ad esempio, quando integri una soluzione Cloud Interconnect in un VPC condiviso, tutte le VM, indipendentemente dalla regione o dal progetto di servizio, possono accedere alla connessione Cloud Interconnect.

Routing dinamico

Il routing dinamico è disponibile su tutte le soluzioni ibride, tra cui VPN ad alta disponibilità, VPN classica, Dedicated Interconnect e Partner Interconnect. Il routing dinamico utilizza il router Cloud di Google come speaker BGP (Border Gateway Protocol) per fornire il routing BGP esterno (eBGP) dinamico.

Il router Cloud non si trova nel piano dati, ma crea route solo nella rete SDN.

Il routing dinamico non utilizza i tag e il router Cloud non annunci mai nuovamente i prefissi appresi.

Puoi attivare una delle due modalità del router Cloud, regionale o globale, su ogni rete VPC. Se scegli il routing regionale, il router Cloud pubblicizza solo le sottoreti che coabitano nella regione in cui è implementato. Il routing globale, invece, annuncia tutte le subnet della rete VPC in questione, indipendentemente dalla regione, ma penalizza le route pubblicizzate e apprese al di fuori della regione. In questo modo viene mantenuta la simmetria all'interno della regione, preferendo sempre un'interconnessione locale e viene calcolata aggiungendo una metrica di penalizzazione (MED) pari a 200 + TTL in millisecondi tra le regioni.

Routing statico

Il routing statico è disponibile solo nella VPN classica. Il routing statico offre la possibilità di impostare una route di hop successivo che rimandi a un tunnel Cloud VPN.

Per impostazione predefinita, una route statica si applica a tutte le VM della rete, indipendentemente dalla regione. Il routing statico consente inoltre agli amministratori di rete di impostare in modo selettivo le VM a cui si applica il percorso utilizzando i tag istanza, che possono essere specificati quando si crea un percorso.

Le route statiche vengono applicate a livello globale all'interno della rete VPC, con la stessa priorità tra loro. Pertanto, se hai più tunnel in più regioni con lo stesso prefisso e la stessa priorità, una VM utilizzerà ECMP basato su hash a 5 tuple su tutti i tunnel. Per ottimizzare questa configurazione, puoi creare un percorso in-regione preferito facendo riferimento ai tag istanza per ogni regione e creando percorsi preferiti di conseguenza.

Se non vuoi che il traffico in uscita (di uscita) passi per il gateway internet predefinito di Google, puoi impostare una route statica predefinita preferita per inviare tutto il traffico di nuovo on-premise tramite un tunnel.

Utilizza una rete VPC di connettività per scalare un'architettura hub-and-spoke con più reti VPC

Se devi scalare un'architettura hub-and-spoke con più reti VPC, configura una connettività ibrida centralizzata in una rete VPC dedicata e esegui il peering con altri progetti utilizzando route pubblicizzate personalizzate. In questo modo, le route statiche o dinamiche acquisite possono essere esportate nelle reti VPC peer per fornire una configurazione centralizzata e scalare la progettazione della rete VPC.

Ciò è in contrasto con il deployment della connettività ibrida convenzionale, che utilizza i tunnel VPN o i collegamenti VLAN in ogni singola rete VPC.

Il seguente diagramma illustra la connettività ibrida centralizzata con route personalizzate del peering di rete VPC:

design ibrido

Sicurezza della rete

Google Cloud fornisce funzionalità di sicurezza efficaci per la sua infrastruttura e i suoi servizi, dalla sicurezza fisica dei data center e dell'hardware di sicurezza personalizzato a team di ricercatori dedicati. Tuttavia, la protezione delle tue Google Cloud risorse è una responsabilità condivisa. Devi adottare misure appropriate per contribuire a garantire la protezione delle tue app e dei tuoi dati.

Identifica obiettivi di sicurezza chiari

Prima di valutare i controlli di sicurezza cloud-native o compatibili con il cloud, inizia con un insieme di obiettivi di sicurezza chiari che tutti gli stakeholder accettano come parte fondamentale del prodotto. Questi obiettivi devono sottolineare la realizzabilità, la documentazione e l'iterazione, in modo che possano essere utilizzati come riferimento e migliorati durante lo sviluppo.

Limita l'accesso esterno

Quando crei una Google Cloud risorsa che utilizza una rete VPC, devi scegliere una rete e una subnet in cui risiede la risorsa. Alla risorsa viene assegnato un indirizzo IP interno da uno degli intervalli IP associati alla subnet. Le risorse in una rete VPC possono comunicare tra loro tramite indirizzi IP interni se le regole firewall lo consentono.

Limita l'accesso a internet solo alle risorse che ne hanno bisogno. Le risorse con solo un indirizzo IP interno privato possono comunque accedere a molti servizi e API di Google tramite Private Service Connect o accesso privato Google. L'accesso privato consente alle risorse di interagire con i principali servizi Google e Google Cloud mantenendosi isolate dalla rete internet pubblica.

Inoltre, utilizza i criteri dell'organizzazione per limitare ulteriormente le risorse che possono utilizzare indirizzi IP esterni.

Tuttavia, prima di bloccare l'accesso a internet, valuta l'impatto sulle istanze VM. Il blocco dell'accesso a internet può ridurre il rischio di esfiltrazione dei dati, ma può anche bloccare il traffico legittimo, incluso quello essenziale per gli aggiornamenti software e le API e i servizi di terze parti. Senza accesso a internet, puoi accedere alle tue istanze VM solo tramite una rete on-premise collegata tramite un tunnel Cloud VPN, una connessione Cloud Interconnect o Identity-Aware Proxy. Con Cloud NAT, le macchine virtuali possono avviare connessioni in uscita verso internet per traffico essenziale specifico senza esporre le connessioni in entrata pubbliche.

Definire i perimetri di servizio per i dati sensibili

Per i carichi di lavoro che coinvolgono dati sensibili, utilizza i Controlli di servizio VPC per configurare perimetri di servizio attorno alle risorse VPC e ai servizi gestiti da Google e per controllare il movimento dei dati attraverso il confine del perimetro. Con i Controlli di servizio VPC, puoi raggruppare i progetti e la tua rete on-premise in un unico perimetro che impedisce l'accesso ai dati tramite i servizi gestiti da Google. I perimetri di servizio non possono contenere progetti di organizzazioni diverse, ma puoi utilizzare i bridge di perimetro per consentire la comunicazione tra progetti e servizi in perimetri di servizio diversi.

Gestisci il traffico con le Google Cloud regole firewall native, se possibile

Google Cloud VPC include un firewall stateful L3/L4 scalabile orizzontalmente e applicato a ogni VM in modo distribuito. Questo firewall viene configurato utilizzando i criteri firewall gerarchici, i criteri firewall di rete globali e regionali e le regole firewall VPC. Per maggiori dettagli, consulta la panoramica di Cloud Firewall.

Google Cloud Marketplace offre un ampio ecosistema di soluzioni di terze parti, tra cui VM che svolgono le seguenti attività: forniscono sicurezza avanzata, ad esempio protezione da fughe di informazioni, exploit di applicazioni e riassegnazione dei privilegi; rilevano minacce note e sconosciute e applicano il filtro degli URL. Esistono anche vantaggi operativi nell'avere un unico fornitore che implementa i criteri per i fornitori di servizi cloud e gli ambienti on-premise.

In genere, il traffico viene indirizzato a queste VM specificando route con la stessa priorità (per distribuire il traffico utilizzando un hash a 5 tuple) o con priorità diverse (per creare un percorso ridondante), come mostrato nei diversi percorsi alla sottorete Dev nel seguente diagramma.

gestione del traffico con regole firewall native

La maggior parte delle soluzioni richiede più VM con interfaccia di rete. Poiché una VM non può avere più di un'interfaccia per rete VPC, quando crei una VM con più interfacce di rete, ogni interfaccia deve essere collegata a una rete VPC separata.

La scalabilità è un aspetto importante anche quando esegui il deployment di soluzioni di terze parti nella tua rete VPC per i seguenti motivi:

  • Limiti: la maggior parte delle appliance basate su VM deve essere inserita nel percorso dati. Ciò richiede una VM con più interfacce di rete che colleghi più reti VPC nello stesso progetto. Poiché le quote delle risorse VPC sono impostate a livello di progetto, le esigenze aggregate delle risorse in tutte le reti VPC possono diventare limitanti.
  • Prestazioni: l'introduzione di un singolo punto di saturazione basato su VM negli attributi di scalabilità completamente orizzontale di una rete VPC è in contrasto con le metodologie di progettazione del cloud. Per mitigare questo problema, puoi inserire più appliance virtuali di rete (NVA) in un gruppo di istanze gestite dietro un bilanciatore del carico di rete passthrough interno.

Per tenere conto di questi fattori nelle architetture dei requisiti di grande scala, applica i controlli di sicurezza ai tuoi endpoint. Inizia con il rafforzare le VM e utilizza Google Cloud le regole firewall. Questa strategia può anche comportare l'introduzione di agenti di ispezione degli endpoint basati su host che non modificano l'architettura di inoltro della rete VPC tramite più VM con interfaccia di rete.

Per un altro esempio di questa configurazione, consulta l'architettura di riferimento del firewall L7 stateful tra reti VPC.

Utilizzare se possibile un numero inferiore di insiemi di regole firewall più ampi

È possibile programmare solo un determinato numero di regole su qualsiasi VM. Tuttavia, puoi combinare molte regole in una singola definizione di regola complessa. Ad esempio, se tutte le VM nella rete VPC devono consentire esplicitamente 10 porte TCP in entrata, hai due opzioni: scrivere 10 regole separate, ciascuna che definisce una singola porta, o definire una singola regola che includa tutte e 10 le porte. Definire una singola regola che includa tutte e 10 le porte è l'opzione più efficiente.

Crea un insieme di regole generico che si applica all'intera rete VPC, quindi utilizza insiemi di regole più specifici per raggruppamenti più piccoli di VM utilizzando i target. In altre parole, inizia definendo regole generali e, se necessario, definisci gradualmente regole più specifiche:

  1. Applica regole firewall comuni a tutte le VM nella rete VPC.
  2. Applica regole firewall che possono essere raggruppate in più VM, ad esempio un gruppo di istanze di servizio o una subnet.
  3. Applica regole firewall a singole VM, ad esempio un gateway NAT o un bastione.

Isolare le VM utilizzando gli account di servizio, se possibile

Molte organizzazioni hanno ambienti che richiedono regole specifiche per un sottoinsieme di VM in una rete VPC. In questi casi, puoi adottare due approcci comuni: isolamento della sottorete e filtro dei target.

Isolamento della subnet

Con l'isolamento della subnet, la subnet forma il confine di sicurezza in cui vengono applicate le Google Cloud regole firewall. Questo approccio è comune nei costrutti di reti on-premise e nei casi in cui gli indirizzi IP e il posizionamento della rete fanno parte dell'identità della VM.

Puoi identificare le VM in una sottorete specifica applicando un tag, un tag di rete o un account di servizio univoco a queste istanze. In questo modo, puoi creare regole firewall che si applicano solo alle VM di una sottorete, ovvero quelle con il tag, il tag di rete e l'account di servizio associati. Ad esempio, per creare una regola firewall che consenta tutte le comunicazioni tra le VM nella stessa subnet, puoi utilizzare la seguente configurazione della regola nella pagina Regole firewall:

  • Target: tag di destinazione specificati
  • Tag di destinazione: subnet-1
  • Filtro di origine: Subnet
  • Subnet: seleziona la subnet per nome (ad es. subnet-1).

Filtro dei target

Con il filtro dei target, tutte le VM si trovano nella stessa subnet o fanno parte di un insieme arbitrario di subnet. Con questo approccio, l'appartenenza alla sottorete non è considerata parte dell'identità dell'istanza per le regole firewall. In alternativa, puoi utilizzare tag, tag di rete o account di servizio per limitare l'accesso tra le VM nella stessa sottorete. A ogni gruppo di VM che utilizza le stesse regole firewall viene applicato lo stesso tag di rete.

Per esemplificare, prendiamo in considerazione un'applicazione a tre livelli (web, app, database) per la quale tutte le istanze sono dipiazzate nella stessa subnet. Il livello web può comunicare con gli utenti finali e con il livello dell'app, mentre il livello dell'app può comunicare con il livello del database, ma non sono consentite altre comunicazioni tra i livelli. Le istanze che eseguono il livello web hanno un tag di rete web, le istanze che eseguono il livello app hanno un tag di rete app e le istanze che eseguono il livello database hanno un tag di rete db.

Le seguenti regole firewall implementano questo approccio:

Regola 1: utenti finali consentiti → livello web Target: Tag target specificati
Tag target: web
Filtro di origine: Intervalli IP
Intervalli IP di origine: 0.0.0.0/0
Regola 2: livello web consentito → livello app Target: Tag di destinazione specificati
Tag di destinazione: app
Filtro sorgente: Tag sorgente
Tag sorgente: web
Regola 3: livello app consentito → livello database Target: Tag di destinazione specificati
Tag di destinazione: db
Filtro origine: Tag origine
Tag origine: app

Tuttavia, anche se è possibile utilizzare i tag di rete per filtrare i target in questo modo, ti consigliamo di utilizzare i tag o gli account di servizio, se possibile. I tag target non sono controllati dall'accesso e possono essere modificati da un utente con il ruolo instanceAdmin mentre le VM sono in servizio. I tag e gli account di servizio sono soggetti a controllo dell'accesso, il che significa che un utente specifico deve essere autorizzato esplicitamente a utilizzare un account di servizio. Può esistere un solo account di servizio per istanza, mentre possono essere presenti più tag. Inoltre, gli account di servizio assegnati a una VM possono essere modificati solo quando la VM è arrestata.

Utilizzare l'automazione per monitorare i criteri di sicurezza quando si utilizzano i tag

Se utilizzi i tag di rete, ricorda che un amministratore dell'istanza può modificarli. In questo modo è possibile aggirare i criteri di sicurezza. Pertanto, se utilizzi i tag di rete in un ambiente di produzione, utilizza un framework di automazione per aiutarti a superare la mancanza di governance IAM sui tag di rete.

Utilizzare strumenti aggiuntivi per proteggere le app

Oltre alle regole firewall, utilizza questi strumenti aggiuntivi per proteggere le tue app:

  • Utilizza un Google Cloud bilanciatore del carico HTTP(S) globale per supportare l'alta disponibilità e la normalizzazione del protocollo.
  • Integra Google Cloud Armor con il bilanciatore del carico HTTP(S) per fornire protezione DDoS e la possibilità di bloccare o consentire gli indirizzi IP all'edge della rete.
  • Controlla l'accesso alle app utilizzando IAP (IAP) per verificare l'identità dell'utente e il contesto della richiesta per determinare se un utente deve essere concesso l'accesso.
  • Fornisci un'unica interfaccia per approfondimenti sulla sicurezza, rilevamento di anomalie e vulnerabilità con Security Command Center.

Servizi di rete: NAT e DNS

Utilizzare indirizzi IP esterni fissi con Cloud NAT

Se hai bisogno di indirizzi IP esterni fissi da un intervallo di VM, utilizza Cloud NAT. Un esempio del motivo per cui potresti aver bisogno di indirizzi IP in uscita fissi è il caso in cui una terza parte consenta richieste da indirizzi IP esterni specifici. L'utilizzo di Cloud NAT ti consente di avere un numero limitato di indirizzi IP NAT per ogni regione che vengono utilizzati per le comunicazioni in uscita.

Cloud NAT consente inoltre alle tue istanze VM di comunicare su internet senza avere indirizzi IP esterni propri. Google Cloud Le regole firewall sono stateful. Ciò significa che se una connessione è consentita tra un'origine e un target o viceversa, sarà consentito tutto il traffico successivo in entrambe le direzioni finché la connessione è attiva. In altre parole, le regole firewall consentono la comunicazione bidirezionale dopo l'instaurazione di una sessione.

Utilizzare zone DNS private per la risoluzione dei nomi

Utilizza le zone private su Cloud DNS per consentire la risoluzione dei tuoi servizi con il DNS all'interno della rete VPC utilizzando i relativi indirizzi IP interni senza esporre questa mappatura all'esterno.

Utilizza DNS orizzonte diviso per mappare i servizi a indirizzi IP diversi dall'interno della rete VPC rispetto all'esterno. Ad esempio, puoi avere un servizio esposto tramite il bilanciamento del carico della rete dall'internet pubblico, ma avere il bilanciamento del carico interno che fornisce lo stesso servizio utilizzando lo stesso nome DNS all'interno della rete VPC.

Accesso API per i servizi gestiti da Google

Se possibile, utilizza il gateway internet predefinito

L'accesso dalle risorse all'interno della rete VPC alle API di Google segue il successivo hop del gateway internet predefinito. Nonostante il nome del gateway di hop successivo, il percorso del traffico dalle istanze alle API Google rimane all'interno della rete di Google.

Per impostazione predefinita, solo le istanze VM con un indirizzo IP esterno possono comunicare con le API e i servizi Google. Se hai bisogno di accedere da istanze senza un indirizzo IP esterno, configura gli endpoint Private Service Connect o utilizza la funzionalità Accesso privato Google per ogni subnet. Ciò non rallenta le comunicazioni per le API di Google.

Google Kubernetes Engine (GKE) abilita automaticamente Accesso privato Google sulle subnet in cui vengono dispiacchiati i nodi. Tutti i nodi di queste subnet senza un indirizzo IP esterno possono accedere ai servizi gestiti da Google.

Aggiungi percorsi espliciti per le API Google se devi modificare il percorso predefinito

Se devi modificare il percorso predefinito, aggiungi percorsi espliciti per gli intervalli di indirizzi IP di destinazione dell'API Google.

Negli ambienti in cui la route predefinita (0.0.0.0/0) non utilizza il successivo hop del gateway internet predefinito, configura route esplicite per gli intervalli di indirizzi IP di destinazione utilizzati dalle API di Google. Imposta l'hop successivo delle route esplicite sul gateway internet predefinito. Un esempio di questo scenario è quando devi ispezionare tutto il traffico tramite un dispositivo on-premise.

Esegui il deployment di istanze che utilizzano le API Google nella stessa subnet

Esegui il deployment di istanze che richiedono l'accesso alle API e ai servizi Google nella stessa subnet e abilita l'accesso privato Google per le istanze senza indirizzi IP esterni. In alternativa, configura gli endpoint Private Service Connect.

Se accedi alle API di Google dal tuo ambiente on-premise utilizzando l'accesso privato Google, consulta la sezione Configurazione dell'accesso privato Google per gli host on-premise per accedere ad alcuni servizi Google tramite intervalli di indirizzi IP privati. Prima di attivare questa funzionalità, controlla quali servizi sono supportati, perché l'accesso ad altre API di Google tramite gli indirizzi IP forniti da questo servizio non sarà raggiungibile. L'attivazione di questa funzionalità può richiedere una configurazione DNS aggiuntiva, ad esempio la configurazione delle visualizzazioni DNS.

Se accedi alle API di Google dal tuo ambiente on-premise utilizzando gli endpoint Private Service Connect, consulta Accedere all'endpoint da host on-premise per maggiori dettagli.

Logging, monitoraggio e visibilità

Personalizzare il logging per casi d'uso e segmenti di pubblico specifici

Utilizza i log di flusso VPC per il monitoraggio della rete, l'analisi forense, l'analisi della sicurezza in tempo reale e l'ottimizzazione delle spese. Puoi attivare o disattivare i log di flusso VPC a livello di subnet. Se i log di flusso VPC sono abilitati per una subnet, vengono raccolti i dati da tutte le istanze VM della subnet.

Questi log registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM. I casi d'uso di registrazione ti aiutano a determinare per quali subnet vuoi attivare la registrazione e per quanto tempo.

I log di flusso vengono aggregati per connessione a intervalli di 5 secondi dalle VM Compute Engine e poi esportati in tempo reale. Puoi visualizzare i log dei flussi in Cloud Logging ed esportarli in qualsiasi destinazione supportata dalle funzionalità di esportazione di Cloud Logging.

La pagina di importazione dei log in Logging monitora il volume dei log nel tuo progetto e ti consente di disattivare l'importazione di tutti i log o di escludere (eliminare) le voci di log che non ti interessano, in modo da ridurre al minimo gli eventuali addebiti per i log rispetto alla tua allocazione mensile.

I log sono un elemento fondamentale per il successo operativo e per la sicurezza, ma non sono utili se non li esamini e non intervieni. Personalizzare i log in base al pubblico di destinazione, il che contribuisce a garantire il successo operativo e la sicurezza delle tue reti VPC.

Per maggiori dettagli, consulta Utilizzo dei log di flusso VPC.

Aumentare l'intervallo di aggregazione dei log per le reti VPC con connessioni lunghe

Per le reti VPC con connessioni per lo più di lunga durata, imposta l'intervallo di aggregazione dei log su 15 minuti per ridurre notevolmente il numero di log generati e abilitare un'analisi più rapida e semplice.

Un esempio di flusso di lavoro per cui è opportuno aumentare l'intervallo di aggregazione dei log è il monitoraggio della rete, che prevede le seguenti attività:

  • Eseguire la diagnostica di rete
  • Filtrare i log di flusso per VM e applicazioni per comprendere le modifiche al traffico
  • Analizzare la crescita del traffico per prevedere la capacità

Utilizzare il campionamento dei log di flusso VPC per ridurre il volume

Utilizza il campionamento dei log di flusso VPC per ridurre il volume dei log di flusso VPC, ma allo stesso tempo essere in grado di visualizzare campioni di basso livello e visualizzazioni aggregate.

Un esempio di flusso di lavoro per il quale è appropriato utilizzare il campionamento per ridurre il volume è comprendere l'utilizzo della rete e ottimizzare la spesa per il traffico di rete. Questo flusso di lavoro prevede le seguenti attività:

  • Stimare il traffico tra regioni e zone
  • Stima del traffico verso paesi specifici su internet
  • Identificazione dei talker principali

Rimuovere metadati aggiuntivi quando sono necessari solo i dati IP e della porta

Nei casi d'uso per la sicurezza in cui ti interessano solo indirizzi IP e porte,rimuovi i metadati aggiuntivi per ridurre il volume di dati consumati in Cloud Logging.

Un esempio di flusso di lavoro per cui è appropriata la rimozione dei metadati è la forensistica di rete, che prevede le seguenti attività:

  • Determinare quali IP hanno comunicato con chi e quando
  • Identificazione di eventuali indirizzi IP compromessi, trovati analizzando i flussi di rete

Architetture di riferimento

Questa sezione mette in evidenza alcune architetture che illustrano alcune delle best practice descritte in questo documento.

Un progetto, una rete VPC

Questa architettura di riferimento iniziale include tutti i componenti necessari per eseguire il deployment di architetture altamente disponibili in più regioni, con isolamento a livello di sottorete e uno SLA (accordo sul livello del servizio) del 99,99% per la connessione ai data center on-premise.

Un progetto, una rete VPC

Un progetto host, più progetti di servizio, un unico VPC condiviso

Basandosi sull'architettura di riferimento iniziale, i progetti host VPC condivisi e più progetti di servizio consentono agli amministratori di delegare le responsabilità amministrative, ad esempio la creazione e la gestione delle istanze, agli amministratori dei progetti di servizio, mantenendo al contempo il controllo centralizzato sulle risorse di rete come subnet, route e firewall.

un progetto host, più progetti di servizio, un'unica VPC condivisa

Più progetti host, più progetti di servizio, più VPC condivise

Il seguente diagramma illustra un'architettura per l'isolamento del VPC, che si basa sul nostro design ad alta disponibilità e separa la produzione dagli altri progetti. Esistono molti motivi per prendere in considerazione l'isolamento della VPC, tra cui requisiti di audit (ad esempio la PCI), considerazioni sulle quote tra gli ambienti o semplicemente un altro livello di isolamento logico. Sono necessarie solo due interconnessioni (per la ridondanza) per località, ma puoi aggiungere più collegamenti di interconnessione a più reti VPC o regioni da queste.

più progetti host, più progetti di servizio, più VPC condivise

L'utilizzo dell'isolamento può anche comportare la necessità di replica, poiché devi decidere dove collocare i servizi di base come proxy, autenticazione e servizi di directory. L'utilizzo di una rete VPC di servizi condivisi può contribuire a evitare questa replica e consentirti di condividere questi servizi con altre reti VPC tramite il peering di rete VPC, centralizzando al contempo l'amministrazione e il deployment.

più progetti host, più progetti di servizio, più VPC condivise

Firewall L7 stateful tra reti VPC

Questa architettura ha più reti VPC collegate da un'appliance NGFW (Next-Generation Firewall) L7, che funziona come un bridge multi-NIC tra le reti VPC.

Viene introdotta una rete VPC esterna non attendibile per terminare le interconnessioni ibride e le connessioni basate su internet che terminano sul tratto esterno del NGFW L7 per l'ispezione. Esistono molte varianti di questo design, ma il principio chiave è filtrare il traffico attraverso il firewall prima che raggiunga le reti VPC attendibili.

Questo design richiede che ogni rete VPC si trovi nel progetto in cui inserisci il NGFW basato su VM. Poiché le quote vengono applicate a livello di progetto, devi considerare l'insieme di tutte le risorse VPC.

Firewall L7 stateful tra VPC

Passaggi successivi