Questa guida illustra le best practice e le tipiche architetture aziendali per la progettazione di virtual private cloud (VPC) con Google Cloud. Questa guida è rivolta ai Cloud Network Architect e ai System Architect che hanno già familiarità con i concetti di networking di Google Cloud.
Principi generali e primi passi
Identifica i responsabili delle decisioni, le tempistiche e le attività preliminari.
Valuta la progettazione della rete VPC fin da subito.
Semplicità.
Utilizza convenzioni di denominazione chiare.
Identificare i responsabili delle decisioni, le tempistiche e il lavoro preliminare
Come primo passaggio nella progettazione della tua rete VPC, identifica i responsabili delle decisioni, le tempistiche e le attività preliminari necessarie per assicurarti di soddisfare i requisiti degli stakeholder.
Gli stakeholder possono includere proprietari di applicazioni, architetti della sicurezza, architetti di soluzioni e responsabili delle operazioni. Gli stakeholder stessi potrebbero cambiare a seconda che tu stia pianificando la rete VPC per un progetto, una linea di business o l'intera organizzazione.
Parte del lavoro preliminare prevede che il team acquisisca dimestichezza con i concetti e la terminologia della progettazione delle reti VPC. I documenti utili includono:
- Documentazione di Resource Manager
- Documentazione di Cloud Identity and Access Management
- Documentazione di Virtual Private Cloud
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. Se in un secondo momento dovrai modificare elementi fondamentali come il modo in cui la rete è segmentata o la posizione dei carichi di lavoro, può essere un problema per la tua organizzazione.
Le diverse configurazioni di rete VPC possono avere implicazioni significative per routing, scalabilità e sicurezza. Un'attenta pianificazione e una comprensione approfondita delle tue considerazioni specifiche ti aiuta a creare una solida base architettonica per carichi di lavoro incrementali.
Massima semplicità
Mantenere semplice la progettazione della topologia della tua rete VPC è il modo migliore per garantire un'architettura gestibile, affidabile e ben comprensibile.
Utilizza convenzioni di denominazione chiare
Rendi le convenzioni di denominazione semplici, intuitive e coerenti. Ciò garantisce che gli amministratori e gli utenti finali comprendano lo scopo di ogni risorsa, dove si trova e come si differenzia dalle altre risorse.
Le abbreviazioni comunemente accettate per le parole lunghe sono utili per la brevità. L'utilizzo di una terminologia familiare, ove possibile, favorisce la leggibilità.
Quando definisci le convenzioni di denominazione, considera i componenti illustrati nell'esempio seguente:
- Nome dell'azienda: Acme Azienda:
acmeco - Unità aziendale. Risorse umane:
hr - Codice applicazione: sistema di compensazione:
comp - Codice regione: northamerica-northeast1:
na-ne1, europe-west1:eu-we1 - Codici di ambiente:
dev,test,uat,stage,prod
In questo esempio, l'ambiente di sviluppo per il sistema di compensazione del reparto risorse umane è denominato acmeco-hr-comp-eu-we1-dev.
Per altre risorse di networking comuni, considera modelli come questi:
Rete VPC
sintassi:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
esempio:acmeco-hr-dev-vpc-1Subnet
sintassi:{company-name}-{description(App or BU)-label}-{region/zone-label}
esempio:acmeco-hr-na-ne1-dev-subnetRegola firewall
sintassi:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
esempio:acmeco-hr-internet-internal-tcp-80-allow-ruleRoute IP
sintassi:{priority}-{VPC-label}-{tag}-{next hop}
esempio:1000-acmeco-hr-dev-vpc-1-int-gw
Indirizzi e subnet
Utilizza subnet in modalità personalizzata nelle tue reti VPC aziendali.
Raggruppa le applicazioni in meno subnet con intervalli di indirizzi più ampi.
Usa reti VPC in modalità personalizzata
Quando avvii il tuo primo progetto, inizi con la rete predefinita, che è una rete VPC in modalità automatica denominata default. Le reti in modalità automatica creano automaticamente subnet e route subnet corrispondenti i cui intervalli IP principali sono /20 CIDR in ogni regione di Google Cloud utilizzando un set prevedibile di intervalli di indirizzi RFC 1918. La rete default include automaticamente anche alcune regole firewall precompilate.
Sebbene le reti in modalità automatica possano essere utili per un'esplorazione anticipata, 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 sin 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 connesse alle reti aziendali on-premise.
- Non puoi connettere due reti VPC in modalità automatica utilizzando il peering di rete VPC perché le loro subnet utilizzano intervalli IP principali identici.
- Le subnet in modalità automatica hanno tutte lo stesso nome della rete. Puoi scegliere nomi univoci e descrittivi per le subnet in modalità personalizzata, in modo da rendere le tue reti VPC più comprensibili e gestibili.
- Quando viene introdotta una nuova regione Google Cloud, 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 per motivi di sovranità e di gestione degli indirizzi IP.
Se non dispone di 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 questa rete.
Per ulteriori dettagli sulle differenze tra le reti VPC in modalità automatica e personalizzata, consulta la panoramica delle reti VPC.
Raggruppa le applicazioni in meno subnet con intervalli di indirizzi più ampi
Convenzionalmente, alcune reti aziendali sono separate in molti piccoli intervalli di indirizzi per vari motivi. ad esempio per identificare o isolare un'applicazione o per mantenere un piccolo dominio di trasmissione.
Tuttavia, ti consigliamo di raggruppare le applicazioni dello stesso tipo in un numero inferiore di subnet più gestibili con intervalli di indirizzi più ampi nelle regioni in cui vuoi operare.
A differenza di altri ambienti di networking in cui viene utilizzata una subnet mask, Google Cloud utilizza un approccio di networking software-defined (SDN) per fornire un mesh completo di connettività tra tutte le VM nella rete VPC globale. Il numero di subnet non influisce sul comportamento di routing.
Puoi utilizzare account di servizio o tag di rete per applicare criteri 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, l'accesso privato Google, i log di flusso VPC e gli intervalli IP alias, sono configurate per subnet. Per un controllo più granulare di queste funzionalità, utilizza subnet aggiuntive.
Rete VPC singola e VPC condiviso
Inizia con una singola rete VPC per le risorse che hanno requisiti comuni.
Utilizza il VPC condiviso per l'amministrazione di più gruppi di lavoro.
Concedi il ruolo utente di rete a livello di subnet.
Utilizza un singolo progetto host se le risorse richiedono più interfacce di rete.
Utilizza più progetti host se i requisiti delle risorse superano la quota di un singolo progetto.
Utilizza più progetti host se hai bisogno di criteri di amministrazione separati per ogni VPC.
Inizia con una singola rete VPC per le risorse che hanno requisiti comuni
Per molti casi d'uso semplici, una singola rete VPC fornisce le funzionalità di cui hai bisogno, pur essendo più facile da creare, gestire 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 progetto singolo, rete VPC singola.
I fattori che potrebbero portarti a creare reti VPC aggiuntive includono scalabilità, sicurezza della rete, considerazioni finanziarie, requisiti operativi e gestione di identità e accessi (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 su 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 del team 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, ad esempio subnet, route e firewall, da un progetto host centrale, in modo da applicare criteri di rete coerenti in tutti i progetti.
Per un esempio di questa configurazione, consulta l'architettura di riferimento Progetto host singolo, più progetti di servizio, singolo VPC condiviso.
Concedi il ruolo utente di rete a livello di subnet
L'amministratore del VPC condiviso centralizzato può concedere ai membri IAM il ruolo utente della rete (networkUser) a livello di subnet, per un'autorizzazione granulare del progetto 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 subnet all'utente, all'account di servizio o al gruppo associato.
Poiché le subnet sono a livello di regione, questo controllo granulare consente di specificare le regioni che ogni progetto di servizio può utilizzare per il deployment delle risorse.
Con le architetture di VPC condivisi, hai anche la flessibilità di eseguire il deployment di più progetti host di VPC condiviso all'interno della tua organizzazione. Ogni progetto host del VPC condiviso può quindi ospitare una o più reti VPC condivise. In questa configurazione, ambienti diversi possono applicare facilmente diversi problemi relativi ai criteri.
Per maggiori informazioni, consulta Ruoli IAM per il networking.
Utilizza un singolo progetto host se le risorse richiedono più interfacce di rete
Se hai un progetto di servizio che deve eseguire il deployment delle 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. Il motivo è che un progetto di servizio può essere associato a un solo progetto host.
Utilizza più progetti host se i requisiti delle risorse superano la quota di un singolo progetto
Nei casi in cui i requisiti aggregati delle risorse di tutte le reti VPC non possano essere soddisfatti nella quota di un progetto, utilizza un'architettura con più progetti host con una singola rete VPC condiviso per progetto host, anziché un singolo progetto host con più reti VPC condiviso. È importante valutare i requisiti di scalabilità, perché 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 Più progetti host, più progetti di servizio, più architetture di riferimento per VPC condivisi.
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 del VPC condiviso distinto per ogni rete VPC per scalare le risorse aggregate. In questo modo, ogni rete VPC può disporre di autorizzazioni IAM separate per la gestione del networking e della sicurezza, in quanto 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 di rete VPC ai progetti.
Crea una rete VPC per ogni team autonomo, con servizi condivisi in una rete VPC comune.
Crea reti VPC in progetti diversi per controlli IAM indipendenti.
Isola i dati sensibili nella propria rete 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 di rete. Tutte le risorse hanno una quota predefinita iniziale per proteggerti da un utilizzo imprevisto delle risorse. Tuttavia, molti fattori possono portarti 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 delle risorse VPC predefinite. In questo modo è più semplice mappare gli aumenti della 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 di sistema in forma aggregata. In genere i limiti non possono essere aumentati facilmente, anche se i team di assistenza e vendita di Google Cloud possono collaborare con te per aumentarne alcuni.
Consulta Quote e limiti delle risorse VPC per i valori attuali.
L'Assistenza Google può aumentare alcuni limiti di scalabilità, ma in alcuni casi potrebbe essere necessario creare più reti VPC per soddisfare i requisiti di scalabilità. Se la tua rete VPC ha un requisito di scalabilità oltre i limiti, parla del tuo caso con i team di vendita e assistenza di Google Cloud per individuare l'approccio migliore per i tuoi requisiti.
Crea una rete VPC per ogni team autonomo, con servizi condivisi in una rete VPC comune
Alcuni deployment aziendali di grandi dimensioni prevedono team autonomi che richiedono ciascuno il controllo completo sulle rispettive reti VPC. Puoi soddisfare questo requisito creando una rete VPC per ogni business unit, con servizi condivisi in una rete VPC comune (ad esempio strumenti di analisi, pipeline CI/CD e creazione di macchine, servizi DNS/directory). Per ulteriori informazioni sulla creazione di una rete VPC comune per i servizi condivisi, consulta la sezione Servizi condivisi.
Creazione di reti VPC in progetti diversi per controlli IAM indipendenti
Una rete VPC è una risorsa a livello di progetto con controlli per la gestione di identità e accessi (IAM) granulari, inclusi i seguenti ruoli:
networkAdminsecurityAdminnetworkUsernetworkViewer
Per impostazione predefinita, il deployment dei controlli IAM viene eseguito a livello di progetto e ogni ruolo IAM si applica a tutte le reti VPC all'interno del progetto.
Se sono necessari controlli IAM indipendenti per rete VPC, crea le tue reti VPC in progetti diversi.
Se hai bisogno di ruoli IAM con ambito di 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 altamente regolamentati vincolati da standard di conformità come HIPAA o PCI-DSS, altre misure di sicurezza spesso hanno senso. Un metodo in grado di migliorare la sicurezza e semplificare la verifica della conformità consiste nell'isolare ognuno di questi ambienti nella propria rete VPC.
Connessione di più reti VPC
Scegli il metodo di connessione VPC che soddisfa le tue esigenze di costo, prestazioni e sicurezza.
Utilizza il peering di rete VPC se non supererai i limiti delle risorse.
Utilizza il routing esterno se non hai bisogno di comunicare con un indirizzo IP privato.
Utilizza Cloud VPN per connettere reti VPC che altrimenti supererebbero i limiti aggregati del gruppo di peering.
Utilizza Cloud Interconnect per controllare il traffico tra le reti VPC tramite un dispositivo on-premise.
Utilizza appliance virtuali multi-NIC per controllare il traffico tra reti VPC tramite un dispositivo cloud.
Crea un VPC di servizi condivisi se più reti VPC hanno bisogno di accedere a risorse comuni, ma non tra loro.
Scegli il metodo di connessione VPC che soddisfa le tue esigenze di costo, prestazioni e sicurezza
Il passaggio successivo, dopo aver deciso di implementare più reti VPC, consiste nel connettere queste reti VPC. Le reti VPC sono spazi tenant isolati all'interno dell'SDN Andromeda di Google, ma esistono diversi modi per abilitare la comunicazione tra 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 seguente tabella, mentre le sezioni successive forniscono le best practice per la scelta di un metodo di connessione VPC.
| Vantaggi | Svantaggi | |
|---|---|---|
| Peering di rete VPC |
|
|
| Routing esterno (IP pubblico o gateway NAT) |
|
|
| Cloud VPN |
|
|
| Cloud Interconnect - Dedicato o partner |
|
|
| Interfacce di rete multiple (Multi-NIC) |
|
|
Utilizza il peering di rete VPC se non superi i limiti delle risorse
Ti consigliamo di utilizzare il peering di rete VPC quando devi connettere le reti VPC e non puoi utilizzare un singolo VPC condiviso, a condizione che il totale delle risorse necessarie per tutti i peer connessi direttamente non superi i limiti su istanze VM, il numero di connessioni in peering e le regole di forwarding interno.
Il peering di rete VPC consente a due reti VPC di connettersi tra loro internamente tramite il protocollo 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 dei flussi tra ciascun peer, consentendo le stesse caratteristiche di forwarding come se tutte le VM si trovassero nella stessa rete VPC. Quando le reti VPC sono connesse in peering, tutte le subnet, gli intervalli IP alias e le regole di forwarding interno sono accessibili e ogni rete VPC mantiene 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 si trovassero nella stessa rete VPC.
- Fatturazione: non sono previsti costi aggiuntivi; ti verranno addebitati i costi come se le VM si trovassero nella stessa rete VPC.
Utilizza il routing esterno se non hai bisogno di comunicare con un indirizzo IP privato
Se non hai bisogno della comunicazione tramite indirizzo IP privato, puoi utilizzare il routing esterno con indirizzi IP esterni o un gateway NAT.
Quando viene eseguito il deployment di una rete VPC, viene eseguito il provisioning di una route verso il gateway internet predefinito di Google con una priorità pari a 1000. Se questa route esiste e a una VM viene assegnato un indirizzo IP esterno, le VM possono inviare traffico in uscita (in uscita) attraverso il gateway internet di Google. Puoi anche eseguire il deployment dei servizi che si basano su una delle numerose offerte pubbliche di bilanciamento del carico di Google, che consentono di raggiungere i servizi esternamente.
Le VM con indirizzo esterno comunicano tra loro privatamente sulla spina dorsale di Google, indipendentemente dalla regione e da Network Service Tiers. Utilizza le regole firewall di Google Cloud per controllare il traffico esterno in entrata (in entrata) verso le VM.
Il routing esterno è una buona opzione per la scalabilità, ma è importante capire come il routing pubblico influisce sui costi. Per maggiori dettagli, consulta la documentazione sui prezzi della 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 set di endpoint. Se configuri i tuoi router Cloud con annunci di route personalizzati, puoi abilitare il routing transitivo tra le reti VPC e le topologie hub e 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 reti on-premise, come spiegato nella documentazione di Cloud VPN.
Cloud VPN non supporta MTU di grandi dimensioni. Per i dettagli, consulta le considerazioni sulla MTU.
Utilizza 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 attraverso una connessione a disponibilità elevata e bassa latenza. Puoi utilizzare Dedicated Interconnect per la connessione diretta a Google oppure 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 località on-premise. In questo modo puoi utilizzare l'apparecchiatura di routing on-premise per instradare tra 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 round trip aggiuntivo attraverso il sistema on-premise.
Partner Interconnect offre funzionalità simili, oltre alla possibilità di stabilire un peering diretto con un provider su L3 e di avere la route del provider tra le reti VPC. Ciò consente l'accesso agli indirizzi IP interni nella tua rete on-premise e nelle reti VPC Google Cloud senza un dispositivo NAT o un tunnel VPN.
Poiché molte appliance di sicurezza aziendali possono essere utilizzate su Google Cloud utilizzando VM con più interfacce di rete, l'utilizzo di Cloud Interconnect per instradare il traffico tra reti VPC non è necessario, tranne in pochissimi casi in cui tutto il traffico deve passare attraverso un'appliance on-premise a causa dei criteri aziendali.
Utilizza le appliance virtuali per controllare il traffico tra le reti VPC tramite un dispositivo cloud
Più VM con interfaccia di rete sono comuni nelle reti VPC che richiedono sicurezza o servizi aggiuntivi tra loro, poiché più VM con interfaccia di rete consentono alle istanze VM di collegare le comunicazioni tra 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 quando esegui il deployment di una VM con più NIC:
- Una VM con più NIC può avere un massimo di 8 interfacce.
- Gli intervalli IP di subnet delle interfacce non devono sovrapporsi.
Crea un VPC per i servizi condivisi se più reti VPC richiedono l'accesso a risorse comuni, ma non l'una all'altra
Una rete VPC fornisce una rete mesh completa di connettività globale. Per questo motivo, i servizi condivisi e le pipeline di integrazione continua che risiedono nella stessa rete VPC non richiedono un'attenzione particolare in termini di connettività, sono intrinsecamente raggiungibili. Il VPC condiviso estende questo concetto, consentendo ai servizi condivisi di risiedere in un progetto isolato, fornendo al contempo connettività ad altri servizi o consumer.
Gli approcci ai servizi condivisi includono Private Service Connect, peering di rete VPC e Cloud VPN. Usa Private Service Connect a meno che non sia possibile farlo per qualche motivo. Puoi utilizzare il peering di rete VPC per connetterti a una rete VPC di servizi condivisi, se non supererai 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 dei gruppi di peering.
Private Service Connect consente di rendere disponibile un servizio ospitato in una rete alle VM di un'altra rete creando un endpoint speciale nella rete consumer. Quindi, la configurazione Private Service Connect incanala il traffico di quel servizio tra le due reti.
I consumatori possono utilizzare i propri indirizzi IP interni per accedere ai servizi senza uscire dalle reti VPC o utilizzare indirizzi IP esterni. Il traffico rimane interamente all'interno di Google Cloud. Private Service Connect fornisce un accesso orientato ai servizi tra consumer e producer con un controllo granulare sulla modalità di 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 comune per garantire la connettività. Il peering di rete VPC introduce considerazioni relative alla scalabilità, poiché i limiti di scalabilità si applicano all'utilizzo aggregato delle risorse di tutti i peer.
Il peering di rete VPC può essere utilizzato anche in combinazione con l'accesso privato ai servizi e l'API Service Networking. Utilizzando l'API Service Networking, puoi consentire ai clienti della stessa organizzazione o di un'altra organizzazione di utilizzare un servizio che fornisci, ma lasciare loro di scegliere l'intervallo di indirizzi IP che viene connesso tramite peering di rete VPC.
Cloud VPN è un'alternativa. Poiché Cloud VPN stabilisce la connettività attraverso tunnel IPsec gestiti, non ha i limiti aggregati del peering di rete VPC. Cloud VPN utilizza un gateway VPN per la connettività e non prende in considerazione l'utilizzo aggregato delle risorse del peer IPsec. Gli svantaggi di Cloud VPN includono l'aumento dei costi (tunnel VPN e il traffico in uscita), l'overhead di gestione necessario per gestire i tunnel e l'overhead delle prestazioni di IPsec.
Design ibrido: connessione di un ambiente on-premise
Utilizza il routing dinamico quando possibile.
Utilizza una rete VPC di connettività per scalare un'architettura hub e spoke con più reti VPC.
Dopo aver identificato la necessità di una connettività ibrida e aver scelto una soluzione che soddisfi i tuoi requisiti di larghezza di banda, prestazioni e sicurezza, valuta come integrarla nel design del tuo VPC.
L'utilizzo di un VPC condiviso evita la necessità per ogni progetto di replicare la stessa soluzione. 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 dinamico esterno BGP (eBGP).
Il router Cloud non si trova nel piano dati, ma crea solo route nell'SDN.
Il routing dinamico non utilizza tag e il router Cloud non pubblicizza mai nuovamente i prefissi appresi.
Puoi abilitare una delle due modalità del router Cloud, a livello di regione o globale, su ciascuna rete VPC. Se scegli il routing a livello di regione, il router Cloud pubblicizza solo le subnet che risiedono nella regione in cui è stato eseguito il deployment del router Cloud. Il routing globale, invece, pubblicizza tutte le subnet della rete VPC data, indipendentemente dalla regione, ma penalizza le route annunciate e apprese al di fuori della regione. Ciò mantiene la simmetria all'interno della regione preferendo sempre un'interconnessione locale, ed è calcolata aggiungendo una metrica di penalizzazione (MED) pari a 200 + TTL in millisecondi tra le regioni.
Routing statico
Il routing statico è disponibile solo sulla VPN classica. Il routing statico offre la possibilità di impostare una route di hop successivo che punta a un tunnel Cloud VPN.
Per impostazione predefinita, una route statica viene applicata a tutte le VM nella rete, indipendentemente dalla regione. Il routing statico consente inoltre agli amministratori di rete di impostare in modo selettivo le VM a cui applicare la route utilizzando i tag di istanza, che possono essere specificati quando si crea una route.
Le route statiche si applicano a livello globale all'interno della rete VPC, con la stessa priorità delle route. Di conseguenza, se hai più tunnel in più regioni con lo stesso prefisso e con la stessa priorità, una VM utilizzerà un ECMP basato su hash a 5 tuple in tutti i tunnel. Per ottimizzare questa configurazione, puoi creare una route preferita all'interno della regione facendo riferimento ai tag di istanza per ogni regione e creando di conseguenza le route preferite.
Se non vuoi che il traffico in uscita passi attraverso il gateway internet predefinito di Google, puoi impostare una route statica predefinita preferita per inviare tutto il traffico on-premise attraverso un tunnel.
Utilizza una rete VPC di connettività per scalare un'architettura hub e spoke con più reti VPC
Se hai bisogno di scalare un'architettura hub e spoke con più reti VPC, configura una connettività ibrida centralizzata in una rete VPC dedicata e passa in peering con altri progetti utilizzando route annunciate personalizzate. Ciò consente di esportare le route statiche o ad apprendimento dinamico in reti VPC peer, per fornire una configurazione centralizzata e scalare in base alla progettazione della tua rete VPC.
Ciò è in contrasto con il deployment di connettività ibrida convenzionale, che utilizza tunnel VPN o collegamenti VLAN in ogni singola rete VPC.
Il seguente diagramma illustra la connettività ibrida centralizzata con route personalizzate di peering di rete VPC:
Sicurezza della rete
Identifica obiettivi di sicurezza chiari.
Limita l'accesso esterno.
Definisci i perimetri di servizio per i dati sensibili.
Se possibile, gestisci il traffico con le regole firewall native di Google Cloud.
Se possibile, utilizza un numero minore di serie di regole firewall più ampie.
Se possibile, isolare le VM utilizzando account di servizio.
Utilizza l'automazione per monitorare i criteri di sicurezza quando utilizzi i tag.
Utilizza strumenti aggiuntivi per proteggere e proteggere le tue app.
Google Cloud offre funzionalità di sicurezza affidabili nell'infrastruttura e nei servizi, dalla sicurezza fisica dei data center e dell'hardware di sicurezza personalizzato ai team dedicati di ricercatori. Tuttavia, la protezione delle risorse Google Cloud è una responsabilità condivisa. Devi adottare le misure appropriate per contribuire a garantire che le tue app e i tuoi dati siano protetti.
Identificare obiettivi di sicurezza chiari
Prima di valutare i controlli di sicurezza cloud-native o abilitati per il cloud, inizia con una serie di chiari obiettivi di sicurezza che tutti gli stakeholder concordano come parte fondamentale del prodotto. Questi obiettivi dovrebbero mettere in evidenza la realizzazione, la documentazione e l'iterazione, in modo da potervi fare riferimento e migliorare durante lo sviluppo.
Limita l'accesso esterno
Quando crei una risorsa Google Cloud che utilizza una rete VPC, scegli 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 molte API e servizi Google tramite Private Service Connect o Accesso privato Google. L'accesso privato consente alle risorse di interagire con i servizi chiave di Google e Google Cloud rimanendo isolate dalla rete internet pubblica.
Inoltre, utilizza i criteri dell'organizzazione per limitare ulteriormente le risorse autorizzate a utilizzare gli 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 di dati, ma può anche bloccare il traffico legittimo, incluso il traffico essenziale per gli aggiornamenti del software e le API e i servizi di terze parti. Senza accesso a internet, puoi accedere alle istanze VM solo tramite una rete on-premise connessa 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.
Definisci 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 i perimetri di servizio intorno alle tue risorse VPC e ai servizi gestiti da Google, nonché per controllare lo spostamento dei dati attraverso i confini del perimetro. Con 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 utilizzarli per consentire la comunicazione tra progetti e servizi in perimetri di servizio diversi.
Gestisci il traffico con le regole firewall native di Google Cloud quando possibile
Il VPC di Google Cloud include un firewall stateful L3/L4 scalabile orizzontalmente e applicato a ogni VM in modo distribuito. Questo firewall è configurato utilizzando i criteri firewall gerarchici, i criteri firewall di rete globali e a livello di regione e le regole firewall VPC. Per i dettagli, consulta la panoramica di Cloud Firewall.
Google Cloud Marketplace offre un ampio ecosistema di soluzioni di terze parti, incluse VM che: fornire sicurezza avanzata, come protezione da fughe di informazioni, exploit delle applicazioni ed escalation dei privilegi, rilevare minacce note e sconosciute e applicare filtri agli URL. Ci sono anche vantaggi operativi dall'implementazione dei criteri da parte di un singolo fornitore nei provider di servizi cloud e negli ambienti on-premise.
In genere il traffico viene instradato a queste VM specificando le 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 percorsi multipli alla subnet Dev nel diagramma seguente.
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à è 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ù interfaccia di rete che collega più reti VPC che risiedono nello stesso progetto. Poiché le quote delle risorse VPC sono impostate a livello di progetto, le esigenze di risorse aggregate in tutte le reti VPC possono diventare limitanti.
- Prestazioni: l'introduzione di un singolo chokepoint basato su VM negli attributi di scalabilità completamente orizzontali di una rete VPC viola le metodologie di progettazione del cloud. Per mitigare questo problema, puoi posizionare 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 su larga scala, esegui il push dei controlli di sicurezza agli endpoint. Inizia con la protezione delle VM e l'utilizzo delle regole firewall di Google Cloud. Questa strategia può anche comportare l'introduzione di agenti di ispezione degli endpoint basati su host che non modificano l'architettura di forwarding della rete VPC tramite più VM con interfaccia di rete.
Per un ulteriore esempio di questa configurazione, consulta il firewall Stateful L7 tra reti VPC architettura di riferimento.
Utilizzare un numero minore di serie di regole firewall più ampie quando possibile
Solo un certo numero di regole può essere programmato su qualsiasi VM. Tuttavia, puoi combinare molte regole in un'unica definizione di regole complesse. 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 definisca una porta singola, oppure definire una singola regola che includa tutte le 10 porte. La definizione di una singola regola che includa tutte e 10 le porte è l'opzione più efficiente.
Crea una serie di regole generica applicabile all'intera rete VPC e poi utilizza serie di regole più specifiche per raggruppamenti più piccoli di VM che utilizzano i target. In altre parole, inizia con la definizione di regole ampie e definisci progressivamente le regole in modo più ristretto, a seconda delle esigenze:
- Applica regole firewall comuni a tutte le VM nella rete VPC.
- Applica regole firewall che possono essere raggruppate in più VM, ad esempio un gruppo di istanze di servizio o una subnet.
- Applica le regole firewall a singole VM, ad esempio un gateway NAT o un bastion host.
Isola le VM utilizzando account di servizio quando possibile
Molte organizzazioni dispongono di ambienti che richiedono regole specifiche per un sottoinsieme di VM in una rete VPC. In questi casi puoi adottare due approcci comuni: l'isolamento delle subnet e il filtro della destinazione.
Isolamento subnet
Con l'isolamento della subnet, la subnet definisce il confine di sicurezza su cui vengono applicate le regole firewall di Google Cloud. Questo approccio è comune nei costrutti di networking on-premise e nei casi in cui gli indirizzi IP e il posizionamento sulla rete facciano parte dell'identità della VM.
Puoi identificare le VM in una subnet specifica applicando un tag, un tag di rete o un account di servizio univoci alle istanze. In questo modo puoi creare regole firewall che si applicano solo alle VM in una subnet, ovvero quelle con tag, tag di rete e account di servizio associati. Ad esempio, per creare una regola firewall che consenta tutte le comunicazioni tra VM nella stessa subnet, puoi utilizzare la seguente configurazione di regole nella pagina Regole firewall:
- Target. Tag di destinazione specificati
- Tag di destinazione: subnet-1
- Filtro di origine: Subnet
- Subnet: seleziona una subnet in base al nome (ad esempio subnet-1).
Filtro di destinazione
Con il filtro della destinazione, tutte le VM risiedono nella stessa subnet o fanno parte di un insieme arbitrario di subnet. Con questo approccio, l'appartenenza alla subnet non viene considerata parte dell'identità dell'istanza per le regole firewall. Puoi invece utilizzare tag, tag di rete o account di servizio per limitare l'accesso tra VM nella stessa subnet. A ogni gruppo di VM che utilizza le stesse regole firewall viene applicato lo stesso tag di rete.
Per spiegare meglio, considera un'applicazione a tre livelli (web, app, database) per la quale viene eseguito il deployment di tutte le istanze nella stessa subnet. Il livello web può comunicare con gli utenti finali e il livello di app, mentre il livello di app può comunicare con il livello 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 di app hanno un tag di rete app e le istanze che eseguono il livello di database hanno un tag di rete db.
Le seguenti regole firewall implementano questo approccio:
| Regola 1: consenti utenti finali → livello web | Destinazioni: Tag di destinazione specificati Tag di destinazione: web Filtro di origine: Intervalli IP Intervalli IP di origine: 0.0.0.0/0 |
| Regola 2: consenti livello web → livello app | Target: Tag di destinazione specificati Tag di destinazione: app Filtro di origine: Tag di origine Tag di origine: web |
| Regola 3: autorizzazione livello app → livello database | Target: Tag di destinazione specificati Tag di destinazione: db Filtro di origine: Tag di origine Tag di origine: app |
Tuttavia, anche se in questo modo è possibile utilizzare i tag di rete per il filtro dei target, ti consigliamo di utilizzare i tag o gli account di servizio ove possibile. I tag di destinazione non sono controllati tramite 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 con accesso controllato, vale a dire che un utente specifico deve essere esplicitamente autorizzato a utilizzare un account di servizio.
Può esserci un solo account di servizio per istanza, mentre possono essere
più tag. Inoltre, gli account di servizio assegnati a una VM possono essere modificati solo quando la VM viene arrestata.
Utilizzare l'automazione per monitorare i criteri di sicurezza quando vengono utilizzati i tag
Se utilizzi i tag di rete, ricorda che un amministratore dell'istanza può modificarli. Ciò può aggirare il criterio di sicurezza. Pertanto, se utilizzi i tag di rete in un ambiente di produzione, utilizza un framework di automazione che ti aiuti a superare la mancanza di governance IAM sui tag di rete.
Utilizza strumenti aggiuntivi per proteggere e proteggere le tue app
Oltre alle regole firewall, utilizza questi strumenti aggiuntivi per proteggere le tue app:
- Utilizza un bilanciatore del carico HTTP(S) globale di Google Cloud 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 sul perimetro della rete.
- Controlla l'accesso alle app utilizzando IAP (IAP) per verificare l'identità dell'utente e il contesto della richiesta per determinare se a un utente deve essere concesso l'accesso.
- Fornisci un'unica interfaccia per insight sulla sicurezza, rilevamento di anomalie e rilevamento di vulnerabilità con Security Command Center.
Servizi di rete: NAT e DNS
Utilizza indirizzi IP esterni fissi con Cloud NAT.
Utilizza le zone DNS private per la risoluzione dei nomi.
Utilizza 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 le richieste da specifici indirizzi IP esterni. L'utilizzo di Cloud NAT consente di avere un numero ridotto di indirizzi IP NAT per ogni regione utilizzati per le comunicazioni in uscita.
Cloud NAT consente inoltre alle istanze VM di comunicare su internet senza avere indirizzi IP esterni propri. Le regole firewall di Google Cloud sono stateful. Ciò significa che se una connessione è consentita tra un'origine e una destinazione o tra una destinazione e una destinazione, tutto il traffico successivo in entrambe le direzioni sarà consentito finché la connessione è attiva. In altre parole, le regole firewall consentono la comunicazione bidirezionale dopo la creazione di una sessione.
Usa zone DNS private per la risoluzione dei nomi
Utilizza le zone private su Cloud DNS per consentire la risoluzione dei servizi con DNS all'interno della tua rete VPC utilizzando i relativi indirizzi IP interni senza esporre questa mappatura all'esterno.
Utilizza il DNS diviso per l'orizzonte 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 di rete dalla rete internet pubblica, ma avere il bilanciamento del carico interno che fornisce lo stesso servizio utilizzando lo stesso nome DNS dall'interno della rete VPC.
Accesso API per i servizi gestiti di Google
Se possibile, utilizza il gateway internet predefinito.
Aggiungi route esplicite per le API di Google se devi modificare la route predefinita.
Esegui il deployment delle istanze che utilizzano le API di Google nella stessa subnet.
Se possibile, utilizza il gateway internet predefinito
L'accesso dalle risorse all'interno della rete VPC alle API di Google segue l'hop successivo del gateway internet predefinito. Nonostante il nome del gateway dell'hop successivo, il percorso del traffico dalle istanze alle API di Google rimane all'interno della rete 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 dell'accesso da istanze senza un indirizzo IP esterno, configura gli endpoint Private Service Connect o utilizza la funzionalità di accesso privato Google per ogni subnet. Ciò non rallenta le comunicazioni per le API di Google.
Google Kubernetes Engine (GKE) abilita automaticamente l'accesso privato Google sulle subnet in cui viene eseguito il deployment dei nodi. Tutti i nodi in queste subnet senza un indirizzo IP esterno sono in grado di accedere ai servizi gestiti da Google.
Aggiungi route esplicite per le API di Google se devi modificare la route predefinita
Se devi modificare la route predefinita, aggiungi route esplicite per gli intervalli IP di destinazione dell'API Google.
Negli ambienti in cui la route predefinita (0.0.0.0/0) non utilizza l'hop successivo 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 attraverso un dispositivo on-premise.
Esegui il deployment di istanze che utilizzano le API di Google nella stessa subnet
Esegui il deployment delle istanze che richiedono l'accesso alle API e ai servizi Google sulla 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 Configurazione dell'accesso privato Google per gli host on-premise per accedere ad alcuni servizi Google su intervalli di indirizzi IP privati. Prima di attivare questa funzionalità, controlla quali servizi sono supportati, perché non sarà possibile accedere ad altre API di Google tramite gli indirizzi IP forniti da questo servizio. L'attivazione di questa funzionalità può richiedere una configurazione DNS aggiuntiva, ad esempio la configurazione delle viste 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 i dettagli.
Logging, monitoraggio e visibilità
Personalizza il logging per casi d'uso specifici e segmenti di pubblico previsti.
Aumenta l'intervallo di aggregazione dei log per le reti VPC con connessioni lunghe.
Utilizza il campionamento dei log di flusso VPC per ridurre il volume.
Rimuovi i metadati aggiuntivi quando ti servono solo i dati relativi a IP e porta.
Personalizza il logging per casi d'uso specifici e segmenti di pubblico previsti
Utilizza i log di flusso VPC per monitoraggio della rete, network forensics, analisi della sicurezza in tempo reale e ottimizzazione delle spese. Puoi abilitare o disabilitare i log di flusso VPC a livello di subnet. Se i log di flusso VPC sono abilitati per una subnet, raccolgono i dati da tutte le istanze VM nella subnet.
Questi log registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM. I casi d'uso del logging aiutano a determinare quali subnet ritieni che richiedano il logging e per quanto tempo.
I log di flusso vengono aggregati per connessione a intervalli di 5 secondi dalle VM di Compute Engine e quindi esportati in tempo reale. Puoi visualizzare i log di flusso 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 progetto e ti consente di disabilitare l'importazione di tutti i log o di escludere (scadere) le voci di log che non ti interessano, in modo da ridurre al minimo gli addebiti per i log rispetto all'allocazione mensile.
I log sono una parte fondamentale del successo sia operativo che di sicurezza, ma non sono utili a meno che non li esamini e intervieni. Personalizza i log in base al pubblico previsto, in modo da garantire il successo operativo e della sicurezza delle tue reti VPC.
Per maggiori dettagli, consulta Utilizzo dei log di flusso VPC.
Aumenta 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 consentire analisi più semplici e veloci.
Un flusso di lavoro di esempio per il quale è appropriato aumentare l'intervallo di aggregazione dei log è il monitoraggio della rete, che prevede le seguenti attività:
- Esecuzione diagnostica rete in corso...
- Filtrare i log di flusso per VM e applicazioni per comprendere le variazioni del traffico
- Analisi della 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 devi comunque visualizzare campioni di basso livello e viste aggregate.
Un flusso di lavoro di esempio per il quale l'utilizzo del campionamento per ridurre il volume è appropriato è comprendere l'utilizzo della rete e ottimizzare le spese del traffico di rete. Questo flusso di lavoro prevede le seguenti attività:
- Stima del traffico tra regioni e zone
- Stimare il traffico verso paesi specifici su Internet
- Identificazione dei principali interlocutori
Rimuovi metadati aggiuntivi quando sono necessari solo i dati relativi a IP e porta
Nei casi d'uso della sicurezza in cui ti interessano solo gli indirizzi IP e le porte, rimuovi i metadati aggiuntivi per ridurre il volume di dati consumati in Cloud Logging.
Un flusso di lavoro di esempio per il quale la rimozione dei metadati è appropriata è la network forensics, che prevede le seguenti attività:
- Determinare quali IP hanno parlato con chi e quando
- Identificazione di eventuali indirizzi IP compromessi rilevati analizzando i flussi di rete
Architetture di riferimento
Questa sezione evidenzia alcune architetture che illustrano alcune delle best practice descritte in questo documento.
Singolo progetto, singola rete VPC
Questa architettura di riferimento iniziale include tutti i componenti necessari per il deployment di architetture ad alta disponibilità in più regioni, con isolamento a livello di subnet e uno SLA del 99,99% per la connessione ai data center on-premise.
Singolo progetto host, più progetti di servizio, singolo VPC condiviso
Basato sull'architettura di riferimento iniziale, i progetti host del VPC condiviso e i progetti di servizio multipli 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.
Più progetti host, più progetti di servizio, più VPC condiviso
Il seguente diagramma illustra un'architettura per l'isolamento VPC, che si basa sul nostro design ad alta disponibilità, separando la produzione da altri progetti. Esistono molti motivi per prendere in considerazione l'isolamento VPC, tra cui requisiti di controllo (come PCI), considerazioni sulle quote tra ambienti o solo un altro livello di isolamento logico. Sono necessarie solo due interconnessioni (per la ridondanza) per località, ma da queste puoi aggiungere più collegamenti di interconnessione a più reti VPC o regioni.
L'utilizzo dell'isolamento può inoltre introdurre la necessità di replicare, perché decidi dove posizionare i servizi principali, come proxy, autenticazione e servizi di directory. L'utilizzo di una rete VPC con servizi condivisi può contribuire a evitare questa replica e ti consente di condividere questi servizi con altre reti VPC tramite il peering di rete VPC, centralizzando al contempo l'amministrazione e il deployment.
Firewall L7 stateful tra reti VPC
Questa architettura ha più reti VPC collegate tramite bridge da un'appliance L7 firewall di nuova generazione (NGFW), 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 in questa progettazione, ma il principio chiave è filtrare il traffico attraverso il firewall prima che raggiunga le reti VPC attendibili.
Questa progettazione richiede che ogni rete VPC risieda nel progetto in cui inserisci il NGFW basato su VM. Poiché le quote vengono applicate a livello di progetto, devi considerare l'aggregazione di tutte le risorse VPC.
Passaggi successivi
- Approfondimento e best practice su VPC (video Cloud NEXT'18)
- Topologie di rete ibride e multi-cloud
- Best practice per la progettazione di rete nel framework dell'architettura Google Cloud
- Best practice per la scelta della regione per Compute Engine
- Google Cloud per i professionisti dei data center: networking
- Documentazione di VPC
- Panoramica del networking di GKE
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.