Questa guida introduce 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 rete e ai sistemi cloud 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 in anticipo la progettazione della rete VPC.
Semplicità.
Utilizza convenzioni di denominazione chiare.
Identifica i responsabili delle decisioni, le tempistiche e le attività preliminari
Come primo passo nella progettazione della tua rete VPC, identifica i responsabili delle decisioni, le tempistiche e le attività preliminari necessarie per poter soddisfare i requisiti degli stakeholder.
Gli stakeholder possono includere proprietari di applicazioni, architetti della sicurezza, architetti di soluzioni e responsabili delle operazioni. Gli stakeholder potrebbero cambiare a seconda che tu stia pianificando la tua rete VPC per un progetto, per una linea di business o per l'intera organizzazione.
Parte del lavoro preliminare consiste nel far acquisire al team familiarità con i concetti e la terminologia relativi alla progettazione di reti VPC. Ecco alcuni documenti utili:
- 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 parte iniziale della configurazione della tua organizzazione in Google Cloud. Se in un secondo momento devi modificare elementi fondamentali, ad esempio il modo in cui è segmentata la rete o l'ubicazione dei carichi di lavoro, può essere fastidioso per la tua organizzazione.
Configurazioni di rete VPC diverse possono portare a importanti implicazioni per il routing, la scalabilità e la sicurezza. Un'attenta pianificazione e una comprensione approfondita delle tue considerazioni specifiche consentono di creare una solida base architetturale per i carichi di lavoro incrementali.
Massima semplicità
Mantenere semplice la progettazione della topologia di rete VPC è il modo migliore per garantire un'architettura gestibile, affidabile e ben compresa.
Usa convenzioni di denominazione chiare
Rendi le convenzioni di denominazione semplici, intuitive e coerenti. Ciò garantisce che amministratori e utenti finali comprendano lo scopo di ogni risorsa, la sua posizione e in che modo si differenzia dalle altre risorse.
Le abbreviazioni comunemente accettate di parole lunghe aiutano con la brevità. L'utilizzo di una terminologia familiare, ove possibile, migliora la leggibilità.
Quando definisci le convenzioni di denominazione, considera i componenti illustrati nell'esempio seguente:
- 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 di 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-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, si inizia con la rete predefinita, che è una rete VPC in modalità automatica denominata default. Le reti in modalità automatica creano automaticamente le subnet e le route subnet corrispondenti i cui intervalli IP principali sono /20 CIDR in ogni regione Google Cloud utilizzando un insieme prevedibile di intervalli di indirizzi RFC 1918. La rete default include anche
automaticamente alcune regole firewall
precompilate.
Sebbene le reti in modalità automatica possano essere utili per l'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 dall'inizio per i seguenti motivi:
- Le reti VPC in modalità personalizzata si integrano meglio negli schemi di gestione Poiché tutte le reti in modalità automatica utilizzano lo stesso insieme di intervalli IP interni, gli intervalli IP in modalità automatica potrebbero sovrapporsi quando si connetti alle reti aziendali on-premise.
- Non puoi connettere due reti VPC in modalità automatica usando il peering di rete VPC,
- Tutte le subnet in modalità automatica hanno lo stesso nome della rete. Puoi scegliere nomi descrittivi univoci per le subnet in modalità personalizzata, rendendo 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. Le reti VPC in modalità personalizzata ricevono nuove subnet solo se le specifichi. Questo può essere importante sia per i motivi di sovranità sia per la gestione degli indirizzi IP.
Se non ha risorse, puoi eliminare la rete default. Non puoi eliminare una rete VPC finché non hai rimosso tutte le risorse, comprese le istanze di macchine virtuali (VM), che dipendono da questa.
Per ulteriori dettagli sulle differenze tra le reti VPC in modalità automatica e personalizzata, consulta la panoramica della rete VPC.
Raggruppa le applicazioni in meno subnet con intervalli di indirizzi più ampi
Convenzionalmente, alcune reti aziendali sono separate in molti intervalli di indirizzi ridotti per vari motivi. Ad esempio, ciò potrebbe essere avvenuto per identificare o isolare un'applicazione o mantenere un dominio di trasmissione di piccole dimensioni.
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 una mesh completa 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. Identity in Google Cloud non si basa unicamente 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. Se hai bisogno di un controllo più granulare di queste funzionalità, utilizza subnet aggiuntive.
Rete VPC singola e VPC condiviso
Inizia con un'unica rete VPC per le risorse con requisiti comuni.
Utilizzare il VPC condiviso per l'amministrazione di più gruppi di lavoro.
Concedi il ruolo di 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 ciascun VPC.
Inizia con un'unica 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, pur risultando più facile da creare, gestire e comprendere rispetto alle alternative più complesse. Raggruppando le risorse con caratteristiche e requisiti 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, vedi l'architettura di riferimento per progetto singolo, singola rete VPC.
I fattori che potrebbero portarti a creare altre reti VPC includono scalabilità, sicurezza di rete, considerazioni finanziarie, requisiti operativi e gestione di identità e accessi (IAM).
Uso di un 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, quindi 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, come 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, vedi l'architettura di riferimento Singolo progetto host, più progetti di servizio, singola architettura di VPC condivisa.
Concedi il ruolo di utente di rete a livello di subnet
L'amministratore centralizzato della rete VPC condiviso può concedere ai membri IAM il ruolo utente di rete
(networkUser)
a livello di subnet, per un'autorizzazione granulare dei progetti di servizio
o per tutte le subnet a livello di progetto host.
Secondo il principio del privilegio minimo, 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 ciascun progetto di servizio può utilizzare per eseguire il deployment delle risorse.
Con le architetture VPC condivise, hai anche la flessibilità di eseguire il deployment di più progetti host 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 diverse preoccupazioni relative ai criteri.
Per ulteriori 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 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.
Utilizza più progetti host se i requisiti delle risorse superano la quota di un singolo progetto
Se non è possibile soddisfare i requisiti aggregati delle risorse di tutte le reti VPC all'interno della 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 di VPC condivise.
Utilizza più progetti host se hai bisogno di criteri di amministrazione separati per ciascuna rete VPC
Poiché ogni progetto ha la propria quota, utilizza un progetto host del VPC condiviso
separato per ogni rete VPC al fine di scalare le risorse aggregate. In questo modo ogni rete VPC può avere autorizzazioni IAM separate per il networking e la gestione della sicurezza, dato che 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.
Creare reti VPC in progetti diversi per controlli IAM indipendenti.
Isolare 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 pensata per proteggerti da un utilizzo imprevisto delle risorse. Tuttavia, molti fattori potrebbero indurti a richiedere una quota maggiore. Per la maggior parte delle risorse, puoi richiedere una quota aggiuntiva.
Consigliamo di creare una singola rete VPC per progetto se prevedi di superare le quote predefinite delle risorse VPC. In questo modo è più semplice mappare gli aumenti di quota a livello di progetto su 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 vendita e assistenza di Google Cloud possono collaborare con te per aumentarli.
Consulta Quote e limiti delle risorse VPC per i valori attuali.
L'Assistenza Google può aumentare alcuni limiti di scalabilità, ma in alcuni casi è necessario creare più reti VPC per soddisfare i requisiti di scalabilità. Se la tua rete VPC ha bisogno di scalare oltre i limiti, discuti il tuo caso con i team di vendita e assistenza di Google Cloud per trovare l'approccio migliore per i tuoi requisiti.
Creare una rete VPC per ogni team autonomo, con servizi condivisi in una rete VPC comune
Alcuni deployment aziendali di grandi dimensioni coinvolgono team autonomi che richiedono 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 macchine build, servizi DNS/Directory). Per saperne di più sulla creazione di una rete VPC comune per i servizi condivisi, consulta la sezione sui servizi condivisi.
Creare 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 a livello di progetto, che includono 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 hai bisogno di 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.
Isola 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, ulteriori misure di sicurezza spesso hanno senso. Un metodo che può migliorare la sicurezza e semplificare la dimostrazione della conformità è isolare ciascuno di questi ambienti nella propria rete VPC.
Connessione di più reti VPC
Scegli il metodo di connessione VPC più adatto alle tue esigenze in termini di costi, prestazioni e sicurezza.
Utilizza il peering di rete VPC se non superi i limiti delle risorse.
Utilizza il routing esterno se non hai bisogno di una comunicazione tramite 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 attraverso un dispositivo on-premise.
Utilizza appliance virtuali con più NIC per controllare il traffico tra le reti VPC attraverso un dispositivo cloud.
Crea un VPC di servizi condivisi se più reti VPC devono accedere alle risorse comuni ma non tra loro.
Scegli il metodo di connessione VPC più adatto alle tue esigenze in termini di costi, prestazioni e sicurezza
Il passaggio successivo dopo aver deciso di implementare più reti VPC è la connessione di 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 scegliere un metodo di connessione VPC.
I vantaggi e gli svantaggi di ciascuno sono riepilogati nella tabella seguente e le sezioni successive forniscono le best practice per scegliere 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 di risorse
Ti consigliamo di utilizzare il peering di rete VPC quando devi connettere le reti VPC e non puoi utilizzare un singolo VPC condiviso, purché i totali delle risorse necessarie per tutti i peer connessi direttamente non superino i limiti relativi alle istanze VM, al numero di connessioni in peering e alle regole di forwarding interno.
Il peering di rete VPC consente a due reti VPC di connettersi internamente tra loro tramite 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 forwarding di se tutte le VM si trovassero nella stessa rete VPC. Quando le reti VPC sono 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 addebiti aggiuntivi; ti vengono addebitati i costi come se le VM si trovassero nella stessa rete VPC.
Utilizza il routing esterno se non hai bisogno di una comunicazione tramite indirizzo IP privato
Se non hai bisogno di una comunicazione con un 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 al gateway internet predefinito di Google con priorità 1000. Se questa route esiste e a una VM viene assegnato un indirizzo IP esterno, le VM possono inviare il traffico in uscita attraverso il gateway internet di Google. Puoi anche eseguire il deployment dei servizi dietro a una delle numerose offerte pubbliche di bilanciamento del carico di Google, che consentono di raggiungere i servizi esternamente.
Le VM indirizzate esternamente comunicano tra loro privatamente sul backbone di Google, indipendentemente dalla regione e dai livelli di rete di servizi. Utilizza le regole firewall di Google Cloud per controllare il traffico esterno in entrata (in entrata) verso le tue VM.
Il routing esterno è una buona opzione per la scalabilità, ma è importante capire in che modo il routing pubblico influisce sui costi. Per maggiori dettagli, consulta la documentazione sui prezzi di rete.
Usa 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à pubblicitaria personalizzata, puoi abilitare il routing transitivo tra reti VPC e topologie hub e spoke come descritto di seguito in questo documento. Utilizzando 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 maggiori dettagli, consulta Considerazioni sulla MTU.
Usa Cloud Interconnect per controllare il traffico tra le reti VPC attraverso un dispositivo on-premise
Cloud Interconnect estende la tua rete on-premise alla rete Google attraverso una connessione a bassa latenza e disponibilità elevata. 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 località on-premise. In questo modo puoi utilizzare apparecchiature di routing on-premise per l'instradamento 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 ha una latenza aggiuntiva a causa di un round trip aggiuntivo attraverso il sistema on-premise.
Partner Interconnect offre funzionalità simili, oltre alla possibilità di connettersi direttamente con un provider L3 e di instradare il 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 le reti VPC non è necessario, tranne che in pochissimi casi in cui tutto il traffico deve passare attraverso un'appliance on-premise a causa dei criteri aziendali.
Utilizzo di appliance virtuali per controllare il traffico tra le reti VPC mediante un dispositivo cloud
Le VM con interfaccia di rete multiple sono comuni per le reti VPC che richiedono sicurezza o servizi aggiuntivi tra loro, perché più VM con interfaccia di rete consentono alle istanze VM di collegare le comunicazioni 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 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 di servizi condivisi se più reti VPC devono accedere alle risorse comuni ma non tra loro
Una rete VPC fornisce un mesh completo 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. 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 sono Private Service Connectt, peering di rete VPC e Cloud VPN. Usa Private Service Connect, a meno che tu non possa 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 aggregati delle risorse e non vuoi configurare endpoint per ogni servizio. Puoi anche usare Cloud VPN per connettere le reti VPC di servizi condivisi che altrimenti supererebbero i limiti aggregati del gruppo di peering.
Private Service Connect consente di rendere disponibile alle VM in un'altra rete un servizio ospitato in una rete mediante la creazione di un endpoint speciale nella rete consumer. La configurazione di Private Service Connect incanala quindi il traffico per quel servizio tra le due reti.
I consumer 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 sulle modalità di accesso ai servizi.
Nel modello di peering di rete VPC, ogni rete VPC crea una relazione di peering con una rete VPC comune di servizi condivisi per garantire la connettività. Il peering di rete VPC introduce considerazioni sulla scalabilità, poiché i limiti di scalabilità si applicano all'uso 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. Con l'API Service Networking, puoi consentire ai tuoi clienti nella stessa organizzazione o in un'altra organizzazione di utilizzare un servizio da te fornito, ma consentire loro di scegliere l'intervallo di indirizzi IP che viene connesso tramite 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 considera l'utilizzo aggregato delle risorse del peer IPsec. Gli svantaggi di Cloud VPN includono l'aumento dei costi (tunnel VPN e in uscita del traffico), l'overhead di gestione necessario per la manutenzione dei tunnel e l'overhead delle prestazioni di IPsec.
Progettazione ibrida: connessione di un ambiente on-premise
Utilizza il routing dinamico quando possibile.
Utilizzare una rete VPC di connettività per scalare un'architettura hub e spoke con più reti VPC.
Dopo aver identificato la necessità della connettività ibrida e scelto una soluzione che soddisfi i requisiti di larghezza di banda, prestazioni e sicurezza, valuta come integrarla nella progettazione del VPC.
L'utilizzo di un VPC condiviso riduce la necessità che ogni progetto replica 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 altoparlante BGP (Border Gateway Protocol) per fornire il routing dinamico BGP esterno (eBGP).
Il router Cloud non si trova nel piano dati, ma crea solo route nel SDN.
Il routing dinamico non utilizza tag e il router Cloud non annuncia mai i prefissi appresi.
Puoi abilitare una delle due modalità del router Cloud, regionale o globale, su ogni 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 specificata, indipendentemente dalla regione, ma penalizza le route annunciate e apprese al di fuori della regione. Questo mantiene la simmetria all'interno della regione preferendo sempre un'interconnessione locale e viene calcolata aggiungendo una metrica di penalità (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 hop successivo che punta a un tunnel Cloud VPN.
Per impostazione predefinita, viene applicata una route statica a tutte le VM nella rete, indipendentemente dalla regione. Il routing statico consente inoltre agli amministratori di rete di impostare selettivamente le VM a cui si applica la route utilizzando i tag di istanza, che possono essere specificati durante la creazione di una route.
Le route statiche vengono applicate a livello globale all'interno della rete VPC, con la stessa priorità delle route. Pertanto, se hai più tunnel in più regioni con lo stesso prefisso 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 nella 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.
Usa 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 ed esegui il peering ad altri progetti utilizzando route annunciate personalizzate. Ciò consente di esportare route statiche o apprese dinamicamente 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 della connettività ibrida convenzionale, che utilizza un 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.
Definire i perimetri di servizio per i dati sensibili.
Gestisci il traffico con le regole firewall native di Google Cloud quando possibile.
Se possibile, utilizza un numero inferiore di set di regole firewall più ampi.
Se possibile, isola le VM utilizzando gli 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 solide funzionalità di sicurezza nell'infrastruttura e nei servizi, dalla sicurezza fisica dei data center all'hardware di sicurezza personalizzato a team di ricercatori dedicati. Tuttavia, la protezione delle risorse Google Cloud è una responsabilità condivisa. Devi adottare misure appropriate per contribuire a garantire che le tue app e i tuoi dati siano protetti.
Identificare chiari obiettivi di sicurezza
Prima di valutare i controlli di sicurezza cloud-native o abilitati per il cloud, inizia con una serie di obiettivi di sicurezza chiari che tutti gli stakeholder concordano come parte fondamentale del prodotto. Questi obiettivi dovrebbero enfatizzare la realizzabilità, la documentazione e l'iterazione, in modo da poterli consultare e migliorare nel corso dello sviluppo.
Limita accesso esterno
Quando crei una risorsa Google Cloud che utilizza una rete VPC, scegli una rete e una subnet in cui si trova 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 indirizzi IP esterni.
Tuttavia, prima di bloccare l'accesso a internet, valuta l'impatto sulle tue istanze VM. Il blocco dell'accesso a internet può ridurre il rischio di esfiltrazione di dati, ma può anche bloccare il traffico legittimo, incluso quello essenziale per gli aggiornamenti del software e API e servizi di terze parti. Senza accesso a internet, puoi accedere alle tue istanze VM solo attraverso una rete on-premise connessa tramite un tunnel Cloud VPN, una connessione Cloud Interconnect o Identity-Aware Proxy. Utilizzando Cloud NAT, le macchine virtuali possono avviare connessioni in uscita verso internet per il traffico essenziale specifico senza esporre le connessioni pubbliche in entrata.
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 risorse VPC e ai servizi gestiti da Google, nonché per controllare il movimento dei dati attraverso il confine del perimetro. Con Controlli di servizio VPC, puoi raggruppare i progetti e la rete on-premise in un unico perimetro che impedisce l'accesso ai dati attraverso i servizi gestiti da Google. I perimetri di servizio non possono contenere progetti di organizzazioni diverse, ma puoi utilizzare i bridge perimetrali per consentire a progetti e servizi in perimetri di servizio diversi di comunicare.
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 criteri firewall gerarchici, criteri firewall di rete globali e regionali e regole firewall VPC. Per maggiori dettagli, consulta la panoramica di Cloud Firewall.
Google Cloud Marketplace presenta un ampio ecosistema di soluzioni di terze parti, comprese VM che: offrono sicurezza avanzata, come la protezione da fughe di informazioni, exploit delle applicazioni ed escalation dei privilegi, rilevare minacce note e sconosciute e applicare filtri degli URL. Offre anche vantaggi operativi nell'implementazione da parte di un unico fornitore dei criteri su tutti i provider di servizi cloud e gli ambienti on-premise.
In genere il traffico viene instradato 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 vari percorsi 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, ciascuna interfaccia deve essere collegata a una rete VPC separata.
Anche la scalabilità è una considerazione importante 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 dei dati. Ciò richiede una VM con più interfacce di rete che colleghi più reti VPC che risiedono nello stesso progetto. Poiché le quote delle risorse VPC vengono impostate a livello di progetto, le esigenze aggregate di risorse in tutte le reti VPC possono diventare limitanti.
- Prestazioni: l'introduzione di un singolo chokepoint basato su VM negli attributi di scalabilità completamente orizzontale di una rete VPC va contro le metodologie di progettazione cloud. Per ovviare a 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. Per iniziare, migliora la protezione delle VM e usa le regole firewall di Google Cloud. Questa strategia può comportare anche l'introduzione di agenti di ispezione degli endpoint basati su host che non modificano l'architettura di forwarding della tua rete VPC attraverso più VM con interfacce di rete.
Per un ulteriore esempio di questa configurazione, consulta la pagina sul firewall stateful L7 tra l'architettura di riferimento delle reti VPC.
Se possibile, utilizza un numero minore di set di regole firewall più ampi
È possibile programmare solo un certo numero di regole su qualsiasi VM. Tuttavia, è possibile combinare molte regole in un'unica definizione complessa di regola. Ad esempio, se tutte le VM nella rete VPC devono consentire esplicitamente 10 porte TCP in entrata, hai due opzioni: scrivere 10 regole separate, ognuna che definisce una singola porta, oppure definire una singola regola che includa tutte e 10 le 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, quindi utilizza serie di regole più specifiche per raggruppamenti più piccoli di VM che utilizzano target. In altre parole, inizia a definire regole ampie e definisci progressivamente le regole in modo più restrittivo in base alle necessità:
- Applica regole firewall comuni a tutte le VM nella rete VPC.
- Applica regole firewall che possono essere raggruppate su più VM, ad esempio un gruppo di istanze di servizio o una subnet.
- Applica regole firewall a singole VM, ad esempio un gateway NAT o un bastion host.
Se possibile, isola le VM utilizzando gli account di servizio
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 di destinazione.
Isolamento subnet
Con l'isolamento delle subnet, la subnet forma il confine di sicurezza attraverso il quale 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 di rete fanno parte dell'identità della VM.
Puoi identificare le VM su 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 delle regole nella pagina Regole firewall:
- Target: tag di destinazione specificati
- Tag di destinazione: subnet-1
- Filtro di origine: Subnet
- Subnet: seleziona la subnet in base al nome (esempio: subnet-1).
Filtro dei target
Con il filtro di 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 è 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 le VM nella stessa subnet. A ogni gruppo di VM che utilizza le stesse regole firewall viene applicato lo stesso tag di rete.
Per illustrare questo aspetto, consideriamo un'applicazione a tre livelli (web, app, database) per cui viene eseguito il deployment di tutte le istanze nella stessa subnet. Il livello web può comunicare con gli utenti finali e 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 di 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: autorizza gli 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 dell'app | Destinazioni: tag di destinazione specificati Tag di destinazione: app Filtro di origine: Tag di origine Tag di origine: web |
| Regola 3: consenti livello app → livello di database | Destinazioni: 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 della destinazione, ti consigliamo di utilizzare tag o account di servizio, ove possibile. I tag di destinazione
non sono con controllo dell'accesso e possono essere modificati da qualcuno con il ruolo instanceAdmin
mentre le VM sono in servizio. Tag e account di servizio sono con accesso controllato, il che significa
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 presenti più tag. Inoltre, gli account di servizio assegnati a una VM possono essere modificati solo quando la VM viene arrestata.
Usa l'automazione per monitorare i criteri di sicurezza quando utilizzi i tag
Se utilizzi tag di rete, ricorda che un amministratore di istanza può modificarli. Ciò può aggirare le norme di sicurezza. Pertanto, se utilizzi i tag di rete in un ambiente di produzione, utilizza un framework di automazione per superare la mancanza di governance IAM per i tag di rete.
Usa strumenti aggiuntivi per proteggere e proteggere le tue app
Oltre alle regole firewall, utilizza questi strumenti aggiuntivi per proteggere e 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 dagli attacchi 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 gli insight sulla sicurezza, il rilevamento di anomalie e il rilevamento di vulnerabilità con Security Command Center.
Servizi di rete: NAT e DNS
Utilizza indirizzi IP esterni fissi con Cloud NAT.
Usa zone DNS private per la risoluzione dei nomi.
Usa 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 consente le richieste da indirizzi IP esterni specifici. Utilizzando Cloud NAT, hai a disposizione un numero ridotto di indirizzi IP NAT per ogni regione utilizzati per le comunicazioni in uscita.
Inoltre, Cloud NAT consente alle istanze VM di comunicare su internet senza avere indirizzi IP esterni. Le regole firewall di Google Cloud sono stateful, Ciò significa che se è consentita una connessione 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 aver stabilito 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 il DNS all'interno della rete VPC, utilizzando i relativi indirizzi IP interni, senza esporre questa mappatura all'esterno.
Utilizza il DNS split Horizon per mappare i servizi a indirizzi IP diversi all'interno della rete VPC rispetto a quelli esterni. Ad esempio, puoi fare in modo che un servizio sia esposto tramite il bilanciamento del carico di rete dalla rete internet pubblica, ma che il bilanciamento del carico interno fornisca lo stesso servizio utilizzando lo stesso nome DNS dall'interno della rete VPC.
Accesso API per i servizi gestiti Google
Utilizza il gateway internet predefinito se possibile.
Aggiungi route esplicite per le API di Google se devi modificare la route predefinita.
Esegui il deployment di istanze che utilizzano le API di Google sulla stessa subnet.
Se possibile, utilizza il gateway internet predefinito
L'accesso dalle risorse 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 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 dell'accesso da istanze senza un indirizzo IP esterno, configura gli endpoint di Private Service Connect o utilizza la funzionalità di accesso privato Google per ogni subnet. Questo 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 possono accedere ai servizi gestiti di 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 delle API di 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 sulla 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, utilizza 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à, verifica quali servizi sono supportati, in quanto l'accesso ad altre API di Google tramite gli indirizzi IP forniti dal servizio non sarà raggiungibile. 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 di destinazione.
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 hai bisogno solo di dati IP e delle porte.
Personalizza il logging per casi d'uso specifici e segmenti di pubblico di destinazione
Utilizza i log di flusso VPC per monitoraggio della rete, analisi forense, 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, raccoglie i dati da tutte le istanze VM in quella subnet.
Questi log registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM. I casi d'uso di logging aiutano a determinare quali subnet decidi per la richiesta del logging e per quanto tempo.
I log di flusso vengono aggregati per connessione a intervalli di 5 secondi dalle VM di Compute Engine e poi 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 tutte le voci di log per l'importazione o di escludere (ignorare) i log che non ti interessano, in modo da ridurre al minimo gli addebiti per i log oltre l'allocazione mensile.
I log sono una parte fondamentale del successo operativo e della sicurezza, ma non sono utili a meno che non li esamini e li intervieni. Personalizza i log per il pubblico di destinazione, 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ù a lunga durata, imposta l'intervallo di aggregazione dei log su 15 minuti per ridurre notevolmente il numero di log generati e consentire un'analisi più rapida e semplice.
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 della diagnostica di rete
- Filtrare i log di flusso per VM e applicazioni al fine di comprendere le modifiche al traffico
- Analisi della crescita del traffico per prevedere la capacità in corso...
Usa il campionamento dei log di flusso VPC per ridurre il volume
Utilizzare il campionamento dei log di flusso VPC per ridurre il volume dei log di flusso VPC, ma riuscire comunque a vedere esempi di basso livello e viste aggregate.
Un flusso di lavoro di esempio per il quale è appropriato utilizzare il campionamento per ridurre il volume è comprendere l'utilizzo della rete e ottimizzare la spesa dovuta al traffico di rete. Questo flusso di lavoro prevede le seguenti attività:
- Stima del traffico tra regioni e zone
- Stima del traffico verso paesi specifici su internet
- Identificazione dei principali talker
Rimuovi i metadati aggiuntivi quando hai bisogno solo di dati IP e delle porte
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 utilizzati in Cloud Logging.
Un flusso di lavoro di esempio per il quale la rimozione dei metadati è appropriata è l'analisi forense della rete, che prevede le seguenti attività:
- Determinare quali IP hanno comunicato con chi e quando
- Identificare gli indirizzi IP compromessi, individuati mediante l'analisi dei flussi di rete.
Architetture di riferimento
Questa sezione evidenzia alcune architetture che illustrano alcune delle best practice in questo documento.
Progetto singolo, 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% che si connette ai data center on-premise.
Singolo progetto host, più progetti di servizio, singolo VPC condiviso
Basandosi sull'architettura di riferimento iniziale, i progetti host del VPC condiviso e di più progetti di servizio consentono agli amministratori di delegare le responsabilità amministrative, ad esempio creazione e 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 al contempo la produzione da altri progetti. Esistono molti motivi per prendere in considerazione l'isolamento dei VPC, tra cui requisiti di audit (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'uso dell'isolamento può anche introdurre la necessità di replica, poiché si decide dove posizionare i servizi principali come proxy, autenticazione e servizi di directory. L'utilizzo di una rete VPC di servizi condivisi può aiutarti a evitare questa replica e consentirti di condividere questi servizi con altre reti VPC tramite 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 da un'appliance firewall di nuova generazione (NGFW) L7, che funziona come 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 della NGFW L7 per l'ispezione. Esistono molte varianti di questa struttura, 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 si inserisce l'unità NGFW basata 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 di 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 selezione della regione per Compute Engine
- Google Cloud per i professionisti dei data center: networking
- Documentazione VPC
- Panoramica del networking di GKE
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.