Questa guida introduce le best practice e le architetture aziendali tipiche per la progettazione virtual private cloud (VPC) con Google Cloud. Questa guida è rivolta ai cloud network architect e architetti di sistema che hanno già familiarità con il networking di Google Cloud concetti.
Principi generali e primi passi
Identifica i responsabili delle decisioni, le tempistiche e le attività preliminari.
Valutare 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 attività preliminari necessarie per rivolgerci alle parti interessate i tuoi requisiti.
Gli stakeholder potrebbero includere proprietari di applicazioni, architetti della sicurezza, soluzioni architetti e responsabili operativi. Gli stakeholder potrebbero cambiare a seconda che tu stia pianificando la tua rete VPC per a un progetto, a una linea di business o all'intera organizzazione.
Parte del lavoro preliminare consiste nel far acquisire al team nozioni e della progettazione di reti VPC. I documenti utili includono seguenti:
- 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 progettazione configurazione organizzativa in Google Cloud. Può essere fonte di disturbo per il tuo organizzazione se in seguito dovessi modificare elementi fondamentali, come il modo in cui la rete è segmentata o dove si trovano i carichi di lavoro.
Configurazioni di rete VPC diverse possono avere implicazioni per il routing, la scalabilità e la sicurezza. Pianificazione attenta e profonda delle tue considerazioni specifiche consente di creare un dell'architettura per 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 gli amministratori e gli utenti finali comprendano lo scopo di ogni risorsa, come si trova e come si differenzia dalle altre risorse.
Le abbreviazioni comunemente accettate di parole lunghe aiutano con la brevità. Utilizzo dell'opzione la terminologia, ove possibile, migliora la leggibilità.
Considera i componenti illustrati nell'esempio seguente quando definisci le convenzioni di denominazione:
- 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 le
il sistema di compensazione del dipartimento si chiama 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, inizi con lo stato predefinito
rete, che è una modalità automatica
Rete VPC denominata default. Automatico
le reti in modalità automatica creano automaticamente le subnet e le subnet corrispondenti
route i cui intervalli IP principali sono /20
CIDR in ogni regione di Google Cloud utilizzando un set prevedibile di conformità RFC 1918
di indirizzi IP esterni. Anche la rete default
include automaticamente alcuni firewall precompilati
Google Cloud.
Sebbene le reti in modalità automatica possano essere utili per l'esplorazione iniziale, la modalità personalizzata Le reti VPC 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 nell'IP esistente schemi di gestione degli indirizzi. Poiché tutte le reti in modalità automatica utilizzano lo stesso insieme di intervalli IP interni, gli intervalli IP in modalità automatica potrebbero sovrapporsi quando i dispositivi sono connessi con le reti aziendali on-premise.
- Non puoi connettere due reti VPC in modalità automatica utilizzando Peering di rete VPC perché le rispettive subnet utilizzano intervalli IP principali identici.
- Tutte le subnet in modalità automatica hanno lo stesso nome della rete. Puoi scegliere nomi descrittivi univoci per le subnet in modalità personalizzata, per rendere le tue reti VPC più comprensibili e gestibili.
- Quando viene introdotta una nuova regione Google Cloud, la modalità automatica Le reti VPC ricevono automaticamente una nuova subnet in quella regione. Le reti VPC in modalità personalizzata ricevono nuove subnet solo se specifichi che li rappresentano. Questo può essere importante sia per la sovranità che per la gestione degli indirizzi IP motivi.
Se non ha risorse, puoi
elimina default
in ogni rete. Non puoi eliminare una rete VPC finché non hai
rimosso tutte le risorse, comprese le istanze di macchine virtuali (VM), che dipendono
li annotino.
Per ulteriori dettagli sulle differenze tra la modalità automatica e quella personalizzata per le reti VPC, consulta Panoramica della rete VPC.
Raggruppa le applicazioni in meno subnet con intervalli di indirizzi più ampi
Convenzionalmente, alcune reti aziendali sono separate in molti indirizzi di piccole per vari motivi. Ad esempio, ciò potrebbe essere stato fatto Identificare o isolare un'applicazione o mantenere un dominio di trasmissione di dimensioni ridotte.
Tuttavia, ti consigliamo di raggruppare le applicazioni dello stesso tipo in meno, più gestibili con intervalli di indirizzi più ampi nelle regioni 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 completa connettività tra tutte le VM nella rete VPC globale. Il numero di subnet non influisce sul comportamento di routing.
Puoi utilizzare gli account di servizio o i tag di rete per applicare criteri di routing specifici o regole firewall. Identity in Google Cloud non si basa unicamente sul l'indirizzo IP della subnet.
Alcune funzionalità VPC, tra cui Cloud NAT Accesso privato Google, Log di flusso VPC, e intervalli IP alias: sono configurate per subnet. Se hai bisogno di un controllo più dettagliato di queste funzionalità, per utilizzare subnet aggiuntive.
Rete VPC singola e VPC condiviso
Inizia con un'unica rete VPC per le risorse con requisiti comuni.
Utilizzare un 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, una singola rete VPC fornisce le funzionalità necessarie, e al contempo è più facile da creare, mantenere e comprendere rispetto alle applicazioni alternative. Raggruppando le risorse con requisiti e caratteristiche comuni in una singola rete VPC, inizi a stabilire bordo della rete VPC come perimetro in caso di potenziali problemi.
Per un esempio di questa configurazione, consulta progetto singolo, rete VPC singola di riferimento.
Fattori che potrebbero portarti a creare reti VPC aggiuntive includono scalabilità, sicurezza di rete, considerazioni finanziarie, 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, VPC condiviso fornisce uno strumento efficace per estendere la semplicità dell'architettura di un singolo in più gruppi di lavoro. L'approccio più semplice prevede l'esecuzione del deployment di un singolo progetto host del VPC condiviso con un singola rete VPC condiviso e quindi collegare i 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 centralizzate e più facili da gestire. I reparti dei progetti di servizio possono configurare e gestire le risorse non di rete, in modo da garantire una chiara separazione responsabilità dei diversi team all'interno dell'organizzazione.
Le risorse in questi progetti possono comunicare tra loro in modo più sicuro in modo efficiente oltre i confini dei progetti usando indirizzi IP interni. Puoi Gestire risorse di rete condivise, come subnet, route e firewall, da un centrale, in modo da poter applicare criteri di rete coerenti su in modo programmatico a gestire i progetti.
Per un esempio di questa configurazione, consulta Singolo progetto host, più progetti di servizio, singolo VPC condiviso di riferimento.
Concedi il ruolo di utente di rete a livello di subnet
L'amministratore centralizzato della VPC condiviso può concedere ai membri IAM l'utente di rete
(networkUser)
a livello di subnet, per un'autorizzazione
dettagliata del progetto di servizio,
o per tutte le subnet a livello di progetto host.
Secondo il principio del privilegio minimo, consigliamo di concedere alla rete a livello di subnet per l'utente, l'account di servizio gruppo.
Poiché le subnet sono a livello di regione, questo controllo granulare ti consente regioni che ogni progetto di servizio può utilizzare per il deployment delle risorse.
Con le architetture VPC condivise, hai anche la flessibilità di eseguire il deployment Progetti host del VPC condiviso all'interno della tua organizzazione. Ogni progetto host del VPC condiviso può quindi ospitare una o più reti VPC condiviso. In questo diversi ambienti possono facilmente applicare criteri diversi i problemi correlati.
Per ulteriori informazioni, vedi 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 reti VPC isolate, ad esempio istanze VM con più interfacce di rete, il progetto host deve contenere tutte le interfacce VPC reti che forniscono i servizi. Il motivo è che un progetto di servizio che 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 non sia 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 singola rete VPC condiviso per progetto host, anziché un singolo progetto host con in più reti VPC condiviso. È importante valutare i requisiti della bilancia, 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 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 host VPC condiviso separato
per ogni rete VPC per scalare le risorse aggregate. Ciò consente a ogni
in modo che la rete VPC abbia autorizzazioni IAM separate per la gestione del networking e della sicurezza,
poiché anche le autorizzazioni IAM
sono implementate 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,
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.
Creare 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.
Ti consigliamo di creare una singola rete VPC per progetto se prevedi di andare oltre quote predefinite delle risorse VPC. In questo modo è più semplice mappare la quota a livello di progetto aumenta in ogni rete VPC anziché a una combinazione di reti VPC nello stesso progetto.
I limiti sono finalizzati a proteggere il sistema le risorse 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 aumentare limiti.
Consulta Quote e limiti delle risorse VPC per i valori correnti.
L'Assistenza Google può aumentare alcuni limiti di scalabilità, ma a volte può succedere che devi creare più reti VPC per soddisfare i tuoi requisiti di scalabilità. Se la tua rete VPC richiede di andare oltre i limiti, discuti il tuo caso ai team di vendita e assistenza di Google Cloud qual è l'approccio migliore per i tuoi requisiti.
Creare una rete VPC per ogni team autonomo, con servizi condivisi in una rete VPC comune
Alcune implementazioni di grandi aziende coinvolgono team autonomi che richiedono il controllo completo delle 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 di creazione, DNS/Directory servizi). Per saperne di più sulla creazione di una rete VPC comune per i servizi condivisi, vedi il servizi condivisi .
Creare reti VPC in progetti diversi per controlli IAM indipendenti
Una rete VPC è una risorsa a livello di progetto con una configurazione granulare a livello di progetto. controlli di gestione di identità e accessi (IAM), inclusi i seguenti ruoli:
networkAdminsecurityAdminnetworkUsernetworkViewer
Per impostazione predefinita, il deployment dei controlli IAM viene eseguito a livello di progetto e di ogni 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 diverse in modo programmatico a gestire i progetti.
Se hai bisogno di ruoli IAM con ambito di risorse Compute Engine specifiche, come Le istanze VM, i dischi e le immagini utilizzano 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 ai dati 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 in una 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 è connetterle reti VPC. Le reti VPC sono spazi tenant isolati all'interno del database Andromeda SDN, ma esistono diversi modi per attivare la comunicazione tra loro. La le sezioni successive forniscono le best practice per scegliere un metodo di connessione VPC.
La vantaggi e svantaggi di ciascuno sono riassunti nella seguente tabella e le sezioni successive forniscono best practice per scegliere una connessione VPC. .
| Vantaggi | Svantaggi | |
|---|---|---|
| Rete VPC Peering |
|
|
| Routing esterno (IP pubblico o un gateway NAT) |
|
|
| Cloud VPN |
|
|
| Cloud Interconnect - Dedicato o partner |
|
|
| Più interfacce di rete (multi-NIC) |
|
|
Utilizza il peering di rete VPC se non superi i limiti di risorse
È consigliabile utilizzare Peering di rete VPC quando devi connettere le reti VPC e non puoi utilizzare un singolo VPC condiviso, purché il totale delle risorse necessarie per tutti i peer direttamente connessi non superano limiti su istanze VM, numero di connessioni in peering e regole di forwarding interno.
Il peering di rete VPC consente a due reti VPC di connettersi internamente tra loro sull'SDN di Google, indipendentemente dal fatto che appartengano o meno allo stesso progetto o nella stessa organizzazione. Il peering di rete VPC unisce il piano di controllo e il flusso la propagazione tra ciascun peer, consentendo lo stesso forwarding caratteristiche come se tutte le VM fossero nella stessa rete VPC. Quando le reti VPC vengono in peering, tutte le subnet, gli intervalli IP alias e le regole di forwarding interno 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 seguenti motivi:
- Nessun collo di bottiglia del gateway: il traffico viene inoltrato tra i peer come se le VM erano nella stessa rete VPC.
- Fatturazione: non sono previsti costi aggiuntivi; ti viene addebitato il costo Le VM si trovavano 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 usare il routing con indirizzi IP esterni o un gateway NAT.
Quando viene eseguito il deployment di una rete VPC, viene eseguita una route al gateway internet predefinito di Google di cui è stato eseguito il provisioning con una priorità pari a 1000. Se questa route esiste e a una VM viene assegnato un indirizzo IP esterno, le VM possono inviare il traffico in uscita un gateway internet standard. Puoi anche eseguire il deployment dei servizi dietro uno dei numerosi delle offerte pubbliche di bilanciamento del carico, che consentono di raggiungere i servizi all'esterno.
Le VM indirizzate esternamente comunicano tra loro privatamente tramite indipendentemente dalla regione e Network Service Tiers. Utilizza le regole firewall di Google Cloud per controllare il traffico esterno in entrata (in entrata) verso per 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 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 tuoi router Cloud Con la modalità pubblicitaria personalizzata, puoi abilitare il routing transitivo tra le reti VPC e hub-and-spoke come descritto più avanti in questo documento. Utilizzando Network Connectivity Center, puoi utilizzare i tunnel VPN ad alta disponibilità 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, vedi Considerazioni sulle 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 attraverso una connessione ad alta disponibilità e a bassa latenza. Puoi utilizzare la modalità Dedicated Interconnect per la connessione diretta a Google o tramite Partner Interconnect per la connessione a Google tramite una fornitore di servizi supportato.
Dedicated Interconnect fornisce un servizio L2 ad alta velocità Google e un fornitore di colocation o una località on-premise. Ciò consente di utilizzare Apparecchiatura di routing on-premise per l'instradamento tra reti VPC e utilizzo di applicazioni on-premise esistenti e i servizi di ispezione e sicurezza 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, Possibilità di connettersi direttamente con un fornitore di livello L3 e di far sì che il fornitore tra le reti VPC. Ciò consente l'accesso agli indirizzi IP interni in rete on-premise e reti VPC di Google Cloud senza dispositivo NAT o VPN tunnel.
Poiché molte appliance di sicurezza aziendale possono essere utilizzate su Google Cloud, utilizzando VM con più interfacce di rete, utilizzando Cloud Interconnect per instradare il traffico tra Le reti VPC non sono necessarie, tranne nei rari casi in cui tutto il traffico deve fluire attraverso un'appliance on-premise grazie ai criteri aziendali.
Utilizzo di appliance virtuali per controllare il traffico tra le reti VPC mediante un dispositivo cloud
VM con più interfacce di rete sono comuni per le reti VPC che richiedono o servizi aggiuntivi tra loro, perché più VM con interfaccia di rete consentono per collegare 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, e le pipeline di integrazione continua che risiedono nella stessa rete VPC richiedono una particolare attenzione in termini di connettività: sono intrinsecamente raggiungibile. VPC condiviso estende questo concetto, consentendo ai servizi condivisi di risiedere in un progetto isolato fornendo al contempo connettività ad altri servizi o consumatori.
Gli approcci ai servizi condivisi includono Private Service Connect, peering di rete VPC e Cloud VPN. Usa Private Service Connect a meno che tu non sia in grado di 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 utilizzare Cloud VPN per connetterti reti VPC di servizi condivisi che altrimenti supererebbero i limiti aggregati del gruppo di peering.
Private Service Connect consente di rendere un servizio ospitato in un'unica rete disponibili per le VM in un'altra rete creando un endpoint speciale sulla rete di consumatori. Quindi la configurazione di Private Service Connect per quel servizio tra le due reti.
I consumer possono utilizzare i propri indirizzi IP interni per accedere ai servizi senza escono dalla loro rete VPC o usano indirizzi IP esterni. Traffico rimanente interamente all'interno di Google Cloud. Private Service Connect fornisce accesso orientato ai servizi tra consumer e producer con controllo granulare le modalità di accesso ai servizi.
Nel modello di peering di rete VPC, ogni rete VPC crea una relazione di peering con rete VPC comune di servizi condivisi per garantire connettività. Peering di rete VPC introduce considerazioni sulla scalabilità, poiché i limiti di scalabilità si applicano agli e l'uso delle risorse di tutti i peer.
Il peering di rete VPC può essere utilizzato anche in combinazione accesso privato ai servizi e ai API Service Networking. Con l'API Service Networking, puoi consentire ai tuoi clienti di organizzazione o in un'altra organizzazione utilizzano un servizio da te fornito, ma lascia che scelgono l'intervallo di indirizzi IP che viene connesso tramite peering di rete VPC.
Cloud VPN è un'altra 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 considera la risorsa aggregata e l'uso del peer IPsec. Gli svantaggi di Cloud VPN includono l'aumento (tunnel VPN e traffico in uscita), l'overhead di gestione richiesto tunneling 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à connettività ibrida e hai scelto una soluzione che soddisfa le tue esigenze in termini di larghezza di banda, prestazioni e sicurezza , considera come integrarlo nella progettazione del tuo VPC.
Utilizzo VPC condiviso riduce la necessità che ogni progetto replica la stessa soluzione. Per Ad esempio, quando integri una soluzione Cloud Interconnect Un VPC condiviso tutte le VM, indipendentemente dalla regione o dal progetto di servizio, possono accedere 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 lo standard un router Cloud come altoparlante BGP (Border Gateway Protocol) per offrire Routing BGP esterno (eBGP).
il router Cloud non si trova nel piano dati; ma crea route solo l'SDN.
Il routing dinamico non utilizza tag e il router Cloud non utilizza mai pubblicizzare di nuovo i prefissi appresi.
Puoi abilitare una delle due modalità del router Cloud: a livello di regione 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 appreso al di fuori dell'area geografica. Questo mantiene la simmetria all'interno della regione preferisce sempre un'interconnessione locale e viene calcolato aggiungendo una penale metrica (MED) pari a 200 + TTL in millisecondi tra le regioni.
Routing statico
Il routing statico è disponibile solo sulla VPN classica. Offerte di routing statico 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. Statica Inoltre, il routing consente agli amministratori di rete di impostare selettivamente le VM si applica utilizzando i tag di istanza, che possono essere specificati quando crei percorso.
Le route statiche vengono applicate a livello globale all'interno della rete VPC, con la stessa priorità delle route tra loro. Pertanto, se hai più tunnel in più regioni al 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 interna preferita facendo riferimento ai tag di istanza per ogni regione e creando route preferite di conseguenza.
Se non vuoi che il traffico in uscita passi attraverso le impostazioni predefinite di Google gateway Internet, puoi impostare una route statica predefinita preferita per inviare tutti il traffico di ritorno 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 e peer-to- altre che utilizzano route annunciate personalizzate. Questo permette di usare in modo statico route apprese da esportare 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 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 minore di set di regole firewall più ampi.
isola le VM utilizzando gli account di servizio, se possibile.
Utilizzare l'automazione per monitorare i criteri di sicurezza quando si utilizzano i tag.
Usa strumenti aggiuntivi per proteggere e proteggere le tue app.
Google Cloud offre solide funzionalità di sicurezza in tutta la sua infrastruttura e servizi, dalla sicurezza fisica dei data center alla sicurezza personalizzata a team di ricercatori dedicati. Tuttavia, la protezione Le risorse Google Cloud sono una responsabilità condivisa. Devi prendere misure appropriate per garantire che le app e i dati siano protetti.
Identificare chiari obiettivi di sicurezza
Prima di valutare i controlli di sicurezza cloud-native o abilitati per il cloud, con una serie di chiari obiettivi di sicurezza che tutte le parti interessate come parte fondamentale del prodotto. Questi obiettivi dovrebbero enfatizzare realizzabilità, documentazione e iterazione, in modo che sia possibile fare riferimento sia migliorato 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. La risorsa è assegnata un indirizzo IP interno da uno degli intervalli IP associati alla subnet. Le risorse in una rete VPC possono comunicare tra loro tramite IP interno se le regole firewall lo consentono.
Limita l'accesso a internet solo alle risorse che ne hanno bisogno. Risorse solo un indirizzo IP interno privato può comunque accedere a molte API di Google e tramite Private Service Connect o Accesso privato Google. L'accesso privato abilita per interagire con i servizi chiave di Google e Google Cloud e rimanere isolati dalla rete internet pubblica.
Inoltre, utilizza criteri dell'organizzazione per limitare ulteriormente le risorse autorizzate a usare indirizzi IP esterni.
Tuttavia, prima di bloccare l'accesso a internet, valuta l'impatto sulla tua VM di Compute Engine. 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 aggiornamenti software e API e servizi di terze parti. Senza accesso a internet, possono accedere alle istanze VM solo tramite una rete on-premise connesso tramite un tunnel Cloud VPN, un gateway Cloud Interconnect o Identity-Aware Proxy. Utilizzando Cloud NAT, le macchine virtuali possono avviare il traffico in uscita connessioni a internet per traffico essenziale specifico senza esporre delle connessioni pubbliche in entrata.
Definisci i perimetri di servizio per i dati sensibili
Per i carichi di lavoro che coinvolgono dati sensibili, utilizza Controlli di servizio VPC per configurare i perimetri di servizio attorno alle tue risorse VPC e e controllare il movimento dei dati attraverso il confine del perimetro. Utilizzo 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 progetti e servizi in diverse perimetri di servizio per 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 in orizzontale scalabili e applicati a ogni VM in modo distribuito. Questo firewall è configurato mediante criteri firewall gerarchici, rete globale e regionale i criteri firewall e le regole firewall VPC. Consulta le Panoramica di Cloud Firewall per maggiori dettagli.
Google Cloud Marketplace offre un ampio ecosistema di soluzioni di terze parti, incluse le VM che: forniscono sicurezza avanzata, ad esempio protezione da fughe di informazioni, exploit delle applicazioni e privilegi; rilevare minacce note e sconosciute; e applicare i filtri degli URL. Esistono vantaggi operativi derivanti dall'implementazione da parte di un unico fornitore dei criteri da provider di servizi cloud e ambienti on-premise.
In genere il traffico viene instradato a queste VM specificando le route, con la stessa priorità (distribuire il traffico utilizzando un hash a 5 tuple) o con priorità diverse (per creare un percorso ridondante), come illustrato nelle 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 con più interfacce di rete, ciascuna deve essere collegata a una rete VPC separata.
La scalabilità è una considerazione importante anche quando si implementano soluzioni di terze parti alla tua rete VPC per i seguenti motivi:
- Limiti: la maggior parte delle appliance basate su VM deve essere inserita nei dati del tuo percorso di apprendimento. Ciò richiede una VM con più interfacce di rete che colleghi più reti VPC che risiedono in lo stesso progetto. Poiché le quote delle risorse VPC sono impostate a livello di progetto, le esigenze aggregate di risorse in tutte le reti VPC possono diventare limitanti.
- Prestazioni: introduzione di un singolo chokepoint basato su VM gli attributi di scalabilità orizzontale di una rete VPC vanno contro la progettazione cloud metodologie. Per mitigare questo problema, puoi posizionare più reti virtuali 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, i controlli di sicurezza agli endpoint. Per iniziare, migliora la protezione delle VM e utilizza Google Cloud le regole del firewall. Questa strategia può comportare anche l'introduzione di endpoint basati su host Agenti di ispezione che non modificano l'architettura di forwarding della rete VPC attraverso più VM con interfaccia di rete.
Per un ulteriore esempio di questa configurazione, consulta Firewall L7 stateful 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 regola complessa definizione di Kubernetes. Ad esempio, se tutte le VM nella rete VPC devono consentire esplicitamente 10 porte TCP in entrata, ci sono due opzioni: scrivere 10 regole separate, ognuna una singola porta o una singola regola che includa tutte e 10 le porte. La definizione di un una singola regola che includa tutte e 10 le porte è l'opzione più efficiente.
Creare una serie di regole generica applicabile all'intera rete VPC, quindi utilizzare altri di regole specifiche per raggruppamenti più piccoli di VM target. In altre parole, inizia definendo regole ampie e definisci progressivamente le regole più restrittivamente 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 gruppo di istanze di servizio o subnet.
- Applica regole firewall a singole VM, ad esempio un gateway NAT o un bastion .
Se possibile, isola le VM utilizzando gli account di servizio
Molte organizzazioni dispongono di ambienti che richiedono regole specifiche per di VM in una rete VPC. Puoi adottare due approcci comuni casi: isolamento di subnet e filtro di destinazione.
Isolamento subnet
Con l'isolamento delle subnet, subnet costituisce 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 a queste istanze. Ciò consente creare regole firewall che si applicano solo alle VM in una subnet, ovvero quelle il tag, il tag di rete e l'account di servizio associati. Ad esempio, per creare un firewall che consenta tutte le comunicazioni tra le VM nella stessa subnet, puoi usare la seguente configurazione delle regole 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 alle subnet è 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 nello stesso una subnet. Ogni gruppo di VM che utilizza le stesse regole firewall ha la stessa rete applicato.
Per illustrare questo aspetto, consideriamo un'applicazione a tre livelli (web, app, database)
di 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, che può comunicare
con il livello di database, ma non sono consentite altre comunicazioni tra i livelli. La
le istanze che eseguono il livello web hanno un tag di rete web, le istanze
che eseguono il livello app hanno un tag di rete app e le istanze che eseguono
il livello di database ha un tag di rete db.
Le seguenti regole firewall implementano questo approccio:
| Regola 1: autorizza gli utenti finali → livello web | Target: 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 | Target: 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 | Target: tag di destinazione specificati Tag di destinazione: db Filtro di origine: Tag di origine Tag di origine: app |
Tuttavia, anche se è possibile utilizzare i tag di rete per il filtro della destinazione
ti consigliamo di utilizzare tag o account di servizio se possibile. Tag di destinazione
non sono soggetti al controllo dell'accesso e possono essere modificati da un utente con l'instanceAdmin
mentre le VM sono in servizio. I tag e gli account di servizio sono controllati dall'accesso, ovvero
che un utente specifico deve essere esplicitamente autorizzato a utilizzare un account di servizio.
Può esserci un solo account di servizio per istanza, mentre
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. Perciò, se utilizzi i tag di rete in una di produzione, usa un framework di automazione per superare dell'assenza 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 proteggi le tue app:
- Utilizza una piattaforma Google Cloud globale Bilanciatore del carico HTTP(S) per supportare l'alta disponibilità e la normalizzazione del protocollo.
- Integra Google Cloud Armor con il bilanciatore del carico HTTP(S) per garantire la protezione dagli attacchi DDoS e la capacità per 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.
- Offre un'unica interfaccia per gli insight sulla sicurezza, il rilevamento di anomalie e il rilevamento delle vulnerabilità Security Command Center.
Servizi di rete: NAT e DNS
Utilizza indirizzi IP esterni fissi con Cloud NAT.
Utilizza 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 che una terza parte consente le richieste da indirizzi IP esterni specifici. Utilizzo Cloud NAT ti consente di avere un numero ridotto di indirizzi IP NAT per ogni regione utilizzata per le comunicazioni in uscita.
Cloud NAT consente inoltre alle istanze VM di comunicare internet senza avere i propri indirizzi IP esterni. Firewall Google Cloud sono stateful, Ciò significa che se è consentita una connessione tra un'origine e un target o un target e una destinazione, quindi tutto il traffico successivo in sarà consentita finché la connessione è attiva. In altre parole, le regole firewall consentono la comunicazione bidirezionale dopo che viene stabilita una sessione.
Usa zone DNS private per la risoluzione dei nomi
Utilizza le funzionalità di zone private su Cloud DNS per consentire la risoluzione dei tuoi servizi con il DNS all'interno della tua rete VPC, utilizzando indirizzi IP interni senza esporre questa mappatura all'esterno.
Utilizza le funzionalità di DNS split Horizon per mappare i servizi a indirizzi IP diversi all'interno della rete VPC dall'esterno. Ad esempio, puoi esporre un servizio tramite rete dalla rete internet pubblica, ma dispongono di bilanciamento del carico interno Fornire lo stesso servizio utilizzando lo stesso nome DNS dall'interno della rete VPC.
Accesso API per i servizi gestiti 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 di istanze che utilizzano le API di Google nella stessa subnet.
Se possibile, utilizza il gateway internet predefinito
L'accesso dalle risorse della rete VPC alle API di Google segue l'impostazione predefinita nell'hop successivo del gateway internet. Nonostante il nome del gateway dell'hop successivo, il percorso 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 API e servizi Google. Se hai bisogno dell'accesso da istanze senza un server per l'indirizzo IP, configurare gli endpoint Private Service Connect o utilizzare Funzionalità di accesso privato Google per ogni subnet. Questo non rallenta le comunicazioni per le API di Google.
Google Kubernetes Engine (GKE) abilita automaticamente Accesso privato Google alle subnet in cui viene eseguito il deployment dei nodi. Tutti i nodi su Queste subnet senza indirizzo IP esterno sono in grado di accedere i servizi di machine learning.
Aggiungi route esplicite per le API di Google se devi modificare la route predefinita
Se devi modificare il percorso predefinito, aggiungi percorsi espliciti per Google Intervalli IP di destinazione API.
In ambienti in cui la route predefinita (0.0.0.0/0) non utilizza la route predefinita
hop successivo del gateway internet, configura route esplicite per
intervalli di indirizzi IP di destinazione
usato dalle API di Google. Imposta l'hop successivo delle route esplicite sul valore predefinito
un gateway internet standard. Un esempio di questo scenario è quando è necessario esaminare tutti
il traffico attraverso un dispositivo on-premise.
Esegui il deployment di istanze che utilizzano le API di Google sulla stessa subnet
Esegui il deployment di istanze che richiedono l'accesso alle API e ai servizi Google sulla stessa subnet e abilita l'accesso privato Google per le istanze senza e gli indirizzi IP esterni. In alternativa, configura gli endpoint Private Service Connect.
Se accedi alle API di Google dal tuo ambiente on-premise utilizzando Accesso privato Google, utilizzo Configurare l'accesso privato Google per gli host on-premise per accedere ad alcuni servizi Google tramite intervalli di indirizzi IP privati. Controlla quale servizi supportati prima di attivare questa funzione in quanto l'accesso ad altre API di Google tramite gli indirizzi IP forniti da questo servizio non saranno raggiungibili. Attivazione in corso può richiedere un'ulteriore configurazione DNS, come la configurazione Visualizzazioni.
Se accedi alle API di Google dal tuo ambiente on-premise utilizzando Endpoint Private Service Connect; consulta Accedere all'endpoint da host on-premise per maggiori 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
Usa Log di flusso VPC per monitoraggio della rete, analisi forense, analisi della sicurezza in tempo reale e e ottimizzazione. 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 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 richiedono il logging e per quanto tempo.
I log di flusso vengono aggregati per connessione a intervalli di 5 secondi VM di Compute Engine ed esportate in tempo reale. Puoi visualizzare i log di flusso Cloud Logging ed esportali in qualsiasi destinazione esportata da Cloud Logging. Google Cloud.
La pagina di importazione dei log in Logging monitora il volume dei log in il tuo progetto e ti consente di disabilitare l'importazione o l'esclusione di log di tutti i log che non ti interessano, in modo da poter ridurre al minimo gli addebiti per i log rispetto all'allocazione mensile.
I log sono una parte fondamentale del successo operativo e della sicurezza, ma non sono utili a meno che tu non li esamini e intervieni. Personalizza i log per pubblico di destinazione, che aiuta a garantire il successo operativo e di sicurezza di alle tue reti VPC.
Per maggiori dettagli, vedi 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 a 15 minuti per ridurre notevolmente il numero di log generati e abilitare un'analisi più rapida e semplice.
Un flusso di lavoro di esempio per cui aumentare l'intervallo di aggregazione dei log più appropriato è il monitoraggio della rete, che prevede le seguenti attività:
- Esecuzione della diagnostica di rete
- Filtrare i log di flusso per VM e applicazioni per comprendere il traffico modifiche
- Analisi della crescita del traffico per prevedere la capacità in corso...
Usa 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, mantenendo possono vedere campioni di basso livello e visualizzazioni 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 legata 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, rimuovere i metadati aggiuntivi per ridurre il volume di dati consumati in in Cloud Logging.
Un flusso di lavoro di esempio per il quale la rimozione dei metadati è appropriata è quella analisi forensi, che comprendono 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 mette in evidenza alcune architetture che illustrano alcune delle migliori pratiche in questo documento.
Progetto singolo, singola rete VPC
Questa architettura di riferimento iniziale include tutti i componenti necessari il deployment di architetture ad alta disponibilità in più regioni, con e uno SLA (accordo sul livello del servizio) 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, sui progetti host del VPC condiviso e più progetti di servizio consentono agli amministratori di delegare le responsabilità, come la creazione e la gestione delle istanze, nei confronti del progetto di servizio Gli amministratori mantengono al contempo il controllo centralizzato sulle risorse di rete, 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 i prodotti da quelli in modo programmatico a gestire i progetti. Ci sono molti motivi per considerare l'isolamento del VPC, compresi i requisiti di audit (come PCI), le considerazioni sulle quote tra ambienti o solo un altro livello all'isolamento logico. Sono necessarie solo due interconnessioni (per la ridondanza) per località, ma è possibile aggiungere più collegamenti di interconnessione a più reti VPC regioni da questi.
L'uso dell'isolamento può anche introdurre la necessità di replica, poiché decidi dove vuoi dei servizi principali come proxy, autenticazione e servizi di directory. L'utilizzo di una rete VPC dei servizi condivisi può aiutarti a evitare la replica e di condividere questi servizi con altre reti VPC tramite peering di rete VPC, mentre centralizzando al contempo l'amministrazione e il deployment.
Firewall L7 stateful tra reti VPC
Questo ha più reti VPC collegate da un'appliance firewall di nuova generazione (NGFW) L7, che funziona come un bridge multi-NIC tra le reti VPC.
Viene introdotta una rete VPC esterna non attendibile per terminare le interconnessioni ibride e le connessioni basate su internet che terminano parte esterna della NGFW L7 per l'ispezione. Esistono molte varianti ma il principio chiave consiste nel filtrare il traffico attraverso il firewall prima il traffico raggiunge reti VPC attendibili.
Questa progettazione richiede che ogni rete VPC risieda nel progetto in cui inserisci basato su VM. Poiché le quote vengono applicate a livello di progetto, considera 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. Dai un'occhiata al nostro Centro architetture cloud.