Questa guida introduce le best practice e le architetture aziendali tipiche per la progettazione virtual private cloud (VPC) con Google Cloud. Questa guida è rivolta agli architetti di reti cloud e agli architetti di sistema che hanno già familiarità con i concetti di networking di Google Cloud.
Principi generali e primi passi
identifica i responsabili decisionali, le tempistiche e le attività preliminari.
Valutare in anticipo la progettazione della rete VPC.
Rendi le cose semplici.
Utilizza convenzioni di denominazione chiare.
Identifica i responsabili delle decisioni, le tempistiche e le attività preliminari
Come primo passaggio nella progettazione della rete VPC, identifica i responsabili decisionali, le tempistiche e il lavoro preliminare necessari per assicurarti di poter soddisfare i requisiti degli stakeholder.
Gli stakeholder possono includere proprietari di applicazioni, architetti della sicurezza, architetti di soluzioni e gestori delle operazioni. Gli stakeholder stessi potrebbero cambiare a seconda che tu stia pianificando la tua rete VPC per un progetto, un'attività commerciale o l'intera organizzazione.
Parte del lavoro preliminare consiste nell'individuare il team con i concetti 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 dannoso per la tua organizzazione se in un secondo momento dovrai modificare aspetti fondamentali come il modo in cui la rete è segmentata o la posizione dei carichi di lavoro.
Configurazioni diverse della rete VPC possono avere implicazioni significative per il routing, la scalabilità e la sicurezza. Una pianificazione attenta e una conoscenza approfondita delle tue considerazioni specifiche ti aiutano a creare una solida base di architettura per i carichi di lavoro incrementali.
Scegli la semplicità
Mantenere semplice il design della topologia di rete VPC è il modo migliore per garantire un'architettura gestibile, affidabile e ben compresa.
Utilizza convenzioni di denominazione chiare
Rendi le convenzioni di denominazione semplici, intuitive e coerenti. 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à. Se possibile, utilizza una terminologia familiare per migliorare 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-label}-{environment-label}-{subnet-label}
esempio:acmeco-hr-na-ne1-dev-vpc-1-subnet-1
Nota: se la subnet contiene risorse in una sola zona, puoi utilizzare "zone-label" anziché "region-label".Regola firewall
sintassi:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
esempio:acmeco-hr-internet-internal-tcp-80-allow-rulePercorso IP
sintassi:{priority}-{VPC-label}-{tag}-{next hop}
esempio:1000-acmeco-hr-dev-vpc-1-int-gw
Indirizzi e subnet
utilizza le subnet in modalità personalizzata nelle 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, viene impostata la rete predefinita, ovvero una rete VPC in modalità automatica 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. La rete default include anche alcune regole firewall precompilate.
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 negli schemi di gestione degli indirizzi IP esistenti. Poiché tutte le reti in modalità automatica utilizzano lo stesso insieme di intervalli IP interni, gli intervalli IP in modalità automatica potrebbero sovrapporsi quando i dispositivi sono connessi con le reti aziendali on-premise.
- Non puoi connettere due reti VPC in modalità automatica utilizzando il peering di rete VPC perché le relative subnet utilizzano intervalli IP principali identici.
- Le subnet in modalità automatica hanno tutte lo stesso nome della rete. Puoi scegliere nomi descrittivi 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, le reti VPC in modalità automatica ricevono automaticamente una nuova subnet in quella regione. Le reti VPC in modalità personalizzata ricevono nuove subnet solo se specifichi che li rappresentano. Questo può essere importante sia per la sovranità sia per la gestione degli indirizzi IP motivi.
Se non contiene risorse, puoi
eliminare la rete default. Non puoi eliminare una rete VPC finché non hai
rimosso tutte le risorse, incluse le istanze di macchine virtuali (VM), che dipendono da essa.
Per ulteriori dettagli sulle differenze tra la modalità automatica e quella personalizzata per le reti VPC, consulta Panoramica della rete VPC.
Raggruppa le applicazioni in un numero inferiore di subnet con intervalli di indirizzi più ampi
Per convenzione, alcune reti aziendali sono suddivise in molti piccoli intervalli di indirizzi per una serie di motivi. Ad esempio, potrebbe essere stato fatto per identificare o isolare un'applicazione o mantenere un piccolo dominio di trasmissione.
Tuttavia, ti consigliamo di raggruppare le applicazioni dello stesso tipo in meno, 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 un mesh completo di raggiungibilità tra tutte le VM nella rete VPC globale. Il numero di subnet non influisce sul comportamento di routing.
Puoi utilizzare account di servizio o tag di rete per applicare criteri di routing o regole firewall specifici. L'identità in Google Cloud non si basa solo sull'indirizzo IP della subnet.
Alcune funzionalità VPC, tra cui Cloud NAT, Accesso privato Google, Log di flusso VPC e intervalli IP alias, sono configurate per subnet. Se hai bisogno di un controllo più granulare di queste funzionalità, utilizza sottoreti aggiuntive.
Rete VPC singola e VPC condiviso
inizia con una singola rete VPC per le risorse con requisiti comuni.
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, un'unica rete VPC fornisce le funzionalità di cui hai bisogno, ma è più facile da creare, gestire e comprendere rispetto alle alternative più complesse. Raggruppando le risorse con requisiti e caratteristiche comuni in un'unica rete VPC, inizi a stabilire il confine della rete VPC come perimetro per potenziali problemi.
Per un esempio di questa configurazione, consulta 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 progetto host centrale, in modo da applicare criteri di rete coerenti a tutti i progetti.
Per un esempio di questa configurazione, consulta Singolo progetto host, più progetti di servizio, singolo VPC condiviso di riferimento.
Concedi il ruolo utente di rete a livello di subnet
L'amministratore della VPC condivisa centralizzata può concedere ai membri IAM il ruolo Utente di rete
(networkUser)
a livello di subnet, per l'autorizzazione granulare dei progetti di servizio,
o per tutte le subnet a livello di progetto host.
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 regionali, questo controllo granulare ti consente di specificare le regioni che ogni progetto di servizio può utilizzare per il deployment delle risorse.
Con le architetture VPC condivise, hai anche la flessibilità di implementare più progetti host VPC condivisi all'interno della tua organizzazione. Ogni progetto host VPC condivisa può quindi ospitare una o più reti VPC condivise. In questo automatica, ambienti diversi possono applicare facilmente criteri diversi le preoccupazioni dei clienti.
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 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. 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 di scalabilità, poiché l'utilizzo di un singolo progetto host richiede più reti VPC nel progetto host e le quote vengono applicate a livello di progetto.
Per un esempio di questa configurazione, consulta la sezione Architettura di riferimento con più progetti host, più progetti di servizio e più VPC condivise.
Utilizza più progetti host se hai bisogno di criteri di amministrazione separati per ogni rete VPC
Poiché ogni progetto ha una propria quota, utilizza un progetto host VPC condiviso distinto per ogni rete VPC per scalare le risorse aggregate. In questo modo, ogni rete VPC può avere autorizzazioni IAM separate per la gestione della rete e della sicurezza, poiché le autorizzazioni IAM vengono implementate anche a livello di progetto. Ad esempio, se esegui il deployment di due reti VPC (rete VPC A e rete VPC B) nello stesso progetto host, il ruolo di amministratore di rete (networkAdmin) si applica a entrambe le reti VPC.
Decidere se creare più reti VPC
crea una singola rete VPC per progetto per mappare le quote di rete VPC ai progetti.
Crea una rete VPC per ogni team autonomo, con servizi condivisi in una rete VPC comune.
Crea reti VPC in progetti diversi per controlli IAM indipendenti.
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 rete. Tutte le risorse hanno una quota predefinita iniziale pensata per proteggerti da un utilizzo imprevisto delle risorse. Tuttavia, molti fattori potrebbero spingerti a richiedere una quota maggiore. Per la maggior parte delle risorse, puoi richiedere una quota aggiuntiva.
Ti consigliamo di creare una singola rete VPC per progetto se prevedi di crescere oltre quote predefinite delle risorse VPC. In questo modo è più facile mappare gli aumenti di quota a livello di progetto a ogni rete VPC anziché a una combinazione di reti VPC nello stesso progetto.
I limiti sono progettati per proteggere il sistema le risorse in forma aggregata. In genere, i limiti non possono essere aumentati facilmente, anche se il team di assistenza e di vendita di Google Cloud può collaborare con te per aumentare alcuni 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ò verificarsi anche 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.
Crea 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 build machine, servizi DNS/Directory). Per ulteriori informazioni sulla creazione di una rete VPC comune per i servizi condivisi, consulta la sezione relativa ai servizi condivisi.
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, i controlli IAM vengono implementati a livello di progetto e ogni ruolo IAM si applica a tutte le reti VPC all'interno del progetto.
Se hai bisogno di controlli IAM indipendenti per rete VPC, crea le tue reti VPC in diverse in modo programmatico a gestire i progetti.
Se hai bisogno di ruoli IAM limitati a risorse Compute Engine specifiche, come istanze VM, dischi e immagini, utilizza i criteri IAM per le risorse Compute Engine.
Isolare i dati sensibili nella propria rete VPC
Per le aziende che si occupano di iniziative di conformità, dati sensibili o dati soggetti a regolamentazioni severe e vincolati da standard di conformità come HIPAA o PCI-DSS, spesso è opportuno adottare ulteriori misure di sicurezza. Un metodo che può migliorare la sicurezza e semplificare la 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 di 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 una VPC di servizi condivisi se più reti VPC devono accedere a risorse comuni, ma non tra di 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 è collegarle. Le reti VPC sono spazi tenant isolati all'interno del database Andromeda SDN, ma esistono diversi modi per attivare la comunicazione tra loro. Le sezioni successive forniscono le best practice per la scelta di 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 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
Ti consigliamo di utilizzare il peering di rete VPC quando devi connettere reti VPC e non puoi utilizzare un singolo VPC condiviso, a condizione che i totali delle risorse necessarie per tutti i peer connessi direttamente non superino i limiti relativi a istanze VM, numero di connessioni di peering e regole di inoltro interno.
Il peering di rete VPC consente a due reti VPC di connettersi tra loro internamente tramite la rete SDN di Google, indipendentemente dal fatto che appartengano o meno allo stesso progetto o alla stessa organizzazione. Il peering di rete VPC unisce il piano di controllo e la propagazione del flusso tra ciascun peer, consentendo le stesse caratteristiche di inoltro come se tutte le VM si trovassero nella stessa rete VPC. Quando le reti VPC 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 i 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 traffico in uscita (di entrata) tramite il gateway internet di Google. 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 con indirizzi esterni comunicano tra loro in privato tramite la backbone di Google, indipendentemente dalla regione e dai livelli di servizio di rete. Utilizza le regole firewall di Google Cloud per controllare il traffico in entrata (ingress) esterno alle 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.
Utilizza Cloud VPN per connettere reti VPC che altrimenti supererebbero i limiti aggregati del gruppo di peering
La VPN ad alta disponibilità fornisce un servizio gestito per connettere le reti VPC creando tunnel IPsec tra insiemi di endpoint. Se configuri i 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. Con Network Connectivity Center, puoi utilizzare i tunnel VPN ad alta disponibilità come rete di transito tra le reti on-premise, come spiegato nella documentazione di Cloud VPN.
Cloud VPN non supporta MTU di grandi dimensioni. Per maggiori dettagli, consulta Considerazioni sulla MTU.
Utilizzare Cloud Interconnect per controllare il traffico tra le reti VPC tramite un dispositivo on-premise
Cloud Interconnect estende la tua rete on-premise alla rete di Google tramite una connessione a disponibilità elevata e a bassa latenza. Puoi utilizzare Dedicated Interconnect per connetterti direttamente a Google o utilizzare Partner Interconnect per connetterti a Google tramite un provider di servizi supportato.
Dedicated Interconnect fornisce un servizio L2 ad alta velocità 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 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, nonché la possibilità di eseguire il peering direttamente con un provider a livello L3 e di far eseguire il routing del provider tra le reti VPC. 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
Più VM con interfaccia di rete sono comuni per le reti VPC che richiedono sicurezza o servizi aggiuntivi tra di loro, perché più VM con interfaccia di rete consentono alle istanze VM di fare da ponte per la comunicazione tra le reti VPC.
Una VM può avere una sola interfaccia per ogni rete VPC a cui si connette. Per eseguire il deployment di una VM in più reti VPC, devi disporre dell'autorizzazione IAM appropriata per ogni rete VPC a cui si connette la VM.
Tieni presente le seguenti caratteristiche durante il deployment di una VM con più NIC:
- Una VM con più NIC può avere un massimo di 8 interfacce.
- Gli intervalli IP 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 raggiungibilità globale. Per questo motivo, i servizi condivisi e le pipeline di integrazione continua che si trovano nella stessa rete VPC non richiedono particolari considerazioni in termini di connettività, in quanto sono intrinsecamente accessibili. 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 connettere reti VPC di servizi condivisi che altrimenti supererebbero i limiti aggregati del gruppo di peering.
Private Service Connect ti consente di rendere disponibile un servizio ospitato in una rete per le VM di un'altra rete creando un endpoint speciale nella rete del consumer. La configurazione di Private Service Connect quindi 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. Il traffico rimane 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 una rete VPC di servizi condivisi comuni per garantire la raggiungibilità. 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 reti 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 clienti della stessa organizzazione o di un'altra organizzazione di utilizzare un servizio che fornisci, ma lasciando loro scegliere l'intervallo di indirizzi IP che viene connesso utilizzando il 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 tiene conto dell'utilizzo aggregato delle risorse del peer IPsec. Gli svantaggi di Cloud VPN includono costi elevati (tunnel VPN e traffico in uscita), il sovraccarico di gestione necessario per la manutenzione dei tunnel e il sovraccarico delle prestazioni di IPsec.
Progettazione ibrida: connessione di un ambiente on-premise
se possibile, utilizza il routing dinamico.
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. Ad esempio, quando integri una soluzione Cloud Interconnect in un VPC condiviso, tutte le VM, indipendentemente dalla regione o dal progetto di servizio, possono accedere alla connessione Cloud Interconnect.
Routing dinamico
Il routing dinamico è disponibile su tutte le soluzioni ibride, tra cui VPN ad alta disponibilità, VPN classica, Dedicated Interconnect e Partner Interconnect. Il routing dinamico utilizza il router Cloud di Google come speaker BGP (Border Gateway Protocol) per fornire il routing BGP esterno (eBGP) dinamico.
Il router Cloud non si trova nel piano dati, ma crea route solo nella rete SDN.
Il routing dinamico non utilizza tag e il router Cloud non utilizza mai pubblicizzare di nuovo i prefissi appresi.
Puoi attivare 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 appreso al di fuori dell'area geografica. In questo modo viene mantenuta la simmetria all'interno della regione, preferendo sempre un'interconnessione locale e viene calcolata aggiungendo una metrica di penalizzazione (MED) pari a 200 + TTL in millisecondi tra le regioni.
Routing statico
Il routing statico è disponibile solo 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, una route statica si applica a tutte le VM della 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 con lo stesso prefisso e la stessa priorità, una VM utilizzerà ECMP basato su hash a 5 tuple su tutti i tunnel. Per ottimizzare questa configurazione, puoi creare 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 del 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 del firewall native di Google Cloud, se possibile.
Utilizza se possibile un numero inferiore di insiemi 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.
Utilizza strumenti aggiuntivi per proteggere e mettere al sicuro 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.
Identifica obiettivi di sicurezza chiari
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 devono sottolineare la realizzabilità, la documentazione e l'iterazione, in modo che possano essere utilizzati come riferimento e migliorati durante lo sviluppo.
Limita l'accesso esterno
Quando crei una risorsa Google Cloud che utilizza una rete VPC, devi scegliere una rete e una sottorete in cui risiede la risorsa. Alla risorsa viene assegnato un indirizzo IP interno da uno degli intervalli IP associati alla subnet. Le risorse in una rete VPC possono comunicare tra loro tramite indirizzi IP interni se le regole firewall lo consentono.
Limita l'accesso a internet solo alle risorse che ne hanno bisogno. 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 consente alle risorse di interagire con i principali servizi Google e Google Cloud rimanendo isolate 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 sulle istanze VM. Il blocco dell'accesso a internet può ridurre il rischio di esfiltrazione di dati, ma può anche bloccare il traffico legittimo, incluso il traffico essenziale per 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 i Controlli di servizio VPC per configurare perimetri di servizio attorno alle risorse VPC e ai servizi gestiti da Google e per controllare il movimento dei dati attraverso il confine del perimetro. 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 di perimetro per consentire la comunicazione tra progetti e servizi in perimetri di servizio diversi.
Gestisci il traffico con le regole firewall native di Google Cloud quando possibile
Google Cloud VPC include un firewall stateful L3/L4 scalabile orizzontalmente e applicato 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, tra cui VM che svolgono le seguenti attività: forniscono sicurezza avanzata, ad esempio protezione da fughe di informazioni, exploit di applicazioni e riassegnazione dei privilegi; rilevano minacce note e sconosciute e applicano il filtro degli URL. Esistono 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 indirizzato a queste VM specificando route con la stessa priorità (per distribuire il traffico utilizzando un hash a 5 tuple) o con priorità diverse (per creare un percorso ridondante), come mostrato nei più percorsi alla sottorete Dev nel seguente diagramma.
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à è un aspetto importante anche quando esegui il deployment di soluzioni di terze parti nella tua rete VPC per i seguenti motivi:
- Limiti: la maggior parte delle appliance basate su VM deve essere inserita nel percorso dati. Ciò richiede una VM con più interfacce di rete che colleghi più reti VPC nello stesso progetto. Poiché le quote delle risorse VPC sono impostate a livello di progetto, le esigenze aggregate 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 attenuare questo problema, puoi inserire più appliance virtuali di rete (NVA) in un gruppo di istanze gestite dietro un bilanciatore del carico di rete passthrough interno.
Per tenere conto di questi fattori nelle architetture dei requisiti su larga scala, esegui il push e i controlli di sicurezza agli endpoint. Inizia con il rafforzamento delle VM e l'utilizzo delle regole del firewall di Google Cloud. 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 altro esempio di questa configurazione, consulta l'architettura di riferimento del firewall L7 stateful tra 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, puoi combinare molte regole in una singola definizione di regola complessa. Ad esempio, se tutte le VM nella rete VPC devono consentire esplicitamente 10 porte TCP in entrata, ci sono due opzioni: scrivere 10 regole separate, ognuna una singola porta o una singola regola che includa tutte e 10 le porte. Definire una singola regola che includa tutte e 10 le porte è l'opzione più efficiente.
Crea un insieme di regole generico che si applica all'intera rete VPC, quindi utilizza insiemi di regole più specifici per raggruppamenti più piccoli di VM utilizzando i target. In altre parole, inizia definendo regole 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 un gruppo di istanze di servizio o subnet.
- Applica regole firewall a singole VM, ad esempio un gateway NAT o un bastion .
Isolare le VM utilizzando gli account di servizio, se possibile
Molte organizzazioni hanno ambienti che richiedono regole specifiche per un sottoinsieme di VM in una rete VPC. In questi casi, puoi adottare due approcci comuni: isolamento della sottorete e filtro dei target.
Isolamento 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 reti on-premise e nei casi in cui gli indirizzi IP e il posizionamento della rete fanno parte dell'identità della VM.
Puoi identificare le VM 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, ossia 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 per nome (ad es. subnet-1).
Filtro dei target
Con il filtro dei target, tutte le VM si trovano nella stessa subnet o fanno parte di un insieme arbitrario di subnet. Con questo approccio, l'appartenenza alla sottorete non è considerata parte dell'identità dell'istanza per le regole firewall. In alternativa, puoi utilizzare tag, tag di rete o account di servizio per limitare l'accesso tra le VM nella stessa sottorete. A ogni gruppo di VM che utilizza le stesse regole firewall viene applicato lo stesso tag di rete.
Per 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 con 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 target specificati Tag target: 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 filtrare i target in questo modo, ti consigliamo di utilizzare i tag o gli account di servizio, se possibile. I tag target
non sono controllati dall'accesso e possono essere modificati da un utente con il ruolo instanceAdmin
mentre le VM sono in servizio. I tag e gli account di servizio sono controllati dall'accesso, ovvero
che un utente specifico deve essere esplicitamente autorizzato a utilizzare un account di servizio.
Può esistere un solo account di servizio per istanza, mentre possono essere presenti più tag. Inoltre, gli account di servizio assegnati a una VM possono essere modificati solo quando
la VM viene arrestata.
Usa l'automazione per monitorare i criteri di sicurezza quando utilizzi i tag
Se utilizzi i tag di rete, ricorda che un amministratore dell'istanza può modificarli. In questo modo è possibile aggirare i criteri di sicurezza. 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.
Utilizzare strumenti aggiuntivi per proteggere le 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 fornire protezione DDoS e la possibilità di bloccare o consentire gli indirizzi IP all'edge della rete.
- Controlla l'accesso alle app utilizzando IAP (IAP) per verificare l'identità dell'utente e il contesto della richiesta per determinare se un utente deve essere concesso l'accesso.
- 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.
Utilizzare indirizzi IP esterni fissi con Cloud NAT
Se hai bisogno di indirizzi IP esterni fissi da un intervallo di VM, utilizza Cloud NAT. Un esempio del motivo per cui potresti aver bisogno di indirizzi IP in uscita fissi è il caso in che una terza parte consente le richieste da indirizzi IP esterni specifici. L'utilizzo di Cloud NAT ti consente di avere un numero limitato di indirizzi IP NAT per ogni regione che vengono utilizzati per le comunicazioni in uscita.
Cloud NAT consente inoltre alle tue istanze VM di comunicare su internet senza avere indirizzi IP esterni propri. Le regole firewall di 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 l'instaurazione di una sessione.
Utilizzare zone DNS private per la risoluzione dei nomi
Utilizza le zone private su Cloud DNS per consentire la risoluzione dei tuoi servizi con il DNS all'interno della rete VPC utilizzando i relativi indirizzi IP interni senza esporre questa mappatura all'esterno.
Utilizza DNS orizzonte diviso per mappare i servizi a indirizzi IP diversi dall'interno della rete VPC rispetto all'esterno. Ad esempio, puoi 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 Google nella stessa sottorete.
Se possibile, utilizza il gateway internet predefinito
L'accesso dalle risorse all'interno della rete VPC alle API di Google segue il successivo hop del gateway internet predefinito. Nonostante il nome del gateway di hop successivo, il percorso del traffico dalle istanze alle API Google rimane all'interno della rete di Google.
Per impostazione predefinita, solo le istanze VM con un indirizzo IP esterno possono comunicare con API e servizi Google. Se hai bisogno di accedere da istanze senza un indirizzo IP esterno, configura gli endpoint Private Service Connect o utilizza la funzionalità Accesso privato Google per ogni subnet. 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 percorsi espliciti per le API Google se devi modificare il percorso predefinito
Se devi modificare il percorso predefinito, aggiungi percorsi espliciti per Google Intervalli IP di destinazione API.
Negli ambienti in cui la route predefinita (0.0.0.0/0) non utilizza il successivo hop del gateway internet predefinito, configura route esplicite per gli intervalli di indirizzi IP di destinazione utilizzati dalle API di Google. Imposta l'hop successivo delle route esplicite sul valore predefinito
un gateway internet standard. Un esempio di questo scenario è quando devi ispezionare tutto il traffico tramite un dispositivo on-premise.
Esegui il deployment di istanze che utilizzano le API 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. Prima di attivare questa funzionalità, controlla quali servizi sono supportati, perché l'accesso ad altre API Google tramite gli indirizzi IP forniti da questo servizio non sarà raggiungibile. L'attivazione di questa funzionalità può richiedere una configurazione DNS aggiuntiva, ad esempio la configurazione delle visualizzazioni DNS.
Se accedi alle API di Google dal tuo ambiente on-premise utilizzando Endpoint Private Service Connect; consulta Accedere all'endpoint da host on-premise per maggiori dettagli.
Logging, monitoraggio e visibilità
personalizza la registrazione per casi d'uso specifici e segmenti di pubblico previsti.
Aumenta l'intervallo di aggregazione dei log per le reti VPC con connessioni lunghe.
Utilizza il campionamento dei log di flusso VPC per ridurre il volume.
Rimuovi i metadati aggiuntivi quando hai bisogno solo di dati IP e di porta.
Personalizza il logging per casi d'uso specifici e segmenti di pubblico di destinazione
Utilizza i log di flusso VPC per il monitoraggio della rete, l'analisi forense, l'analisi della sicurezza in tempo reale e l'ottimizzazione delle spese. Puoi abilitare o disabilitare i log di flusso VPC a livello di subnet. Se i log di flusso VPC sono abilitati per una subnet, vengono raccolti i dati di tutte le istanze VM al suo interno.
Questi log registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM. I casi d'uso di logging ti aiutano a determinare per quali subnet vuoi attivare 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 dei flussi in Cloud Logging ed esportarli in qualsiasi destinazione supportata dalle funzionalità di esportazione di Cloud Logging.
La pagina di importazione dei log in Logging monitora il volume dei log 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.
Aumentare l'intervallo di aggregazione dei log per le reti VPC con connessioni lunghe
Per le reti VPC con connessioni per lo più di lunga durata, imposta l'intervallo di aggregazione dei log su 15 minuti per ridurre notevolmente il numero di log generati e abilitare un'analisi più rapida e semplice.
Un 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à:
- Eseguire la diagnostica di rete
- Filtrare i log di flusso per VM e applicazioni per comprendere le modifiche al traffico
- Analizzare la crescita del traffico per prevedere la capacità
Utilizzare il campionamento dei log di flusso VPC per ridurre il volume
Utilizza il campionamento dei log di flusso VPC per ridurre il volume dei log di flusso VPC, 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à:
- Stimare il traffico tra regioni e zone
- Stima del traffico verso paesi specifici su internet
- Identificazione dei talker principali
Rimuovi i metadati aggiuntivi quando ti servono solo i 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 esempio di flusso di lavoro per cui è appropriata la rimozione dei metadati è la forensistica di rete, che prevede le seguenti attività:
- Determinare quali IP hanno comunicato con chi e quando
- Identificazione di eventuali indirizzi IP compromessi, trovati analizzando i flussi di rete
Architetture di riferimento
Questa sezione evidenzia alcune architetture che illustrano alcune delle migliori pratiche in questo documento.
Un progetto, una 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, i progetti host VPC condivisi e più progetti di servizio consentono agli amministratori di delegare le responsabilità amministrative, ad esempio la creazione e la gestione delle istanze, agli amministratori dei progetti di servizio, mantenendo al contempo il controllo centralizzato sulle risorse di rete come subnet, route e firewall.
Più progetti host, più progetti di servizio, più VPC condivise
Il seguente diagramma illustra un'architettura per l'isolamento della VPC, che si basa sul nostro design ad alta disponibilità e separa la produzione dagli altri progetti. Esistono molti motivi per prendere in considerazione l'isolamento della VPC, tra cui requisiti di audit (ad esempio la PCI), considerazioni sulle quote tra gli ambienti o semplicemente un altro livello di isolamento logico. Sono necessarie solo due interconnessioni (per la ridondanza) per località, ma puoi aggiungere più collegamenti di interconnessione a più reti VPC o regioni da queste.
L'utilizzo dell'isolamento può anche comportare la necessità di replica, poiché devi decidere dove collocare i servizi di base come proxy, autenticazione e servizi di directory. L'utilizzo di una rete VPC di servizi condivisi può contribuire a evitare questa replica e consentirti di condividere questi servizi con altre reti VPC tramite il peering di rete VPC, centralizzando al contempo l'amministrazione e il deployment.
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 sul tratto esterno del 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 su VPC (video di Cloud Next '18)
- Topologie di rete ibride e multi-cloud
- Decidi una gerarchia delle risorse per la zona di destinazione di Google Cloud
- Best practice per la scelta della regione per Compute Engine
- Google Cloud per i professionisti dei data center: networking
- Documentazione VPC
- Panoramica del networking di GKE
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.