Progettazione di reti per la migrazione di carichi di lavoro aziendali: approcci dell'architettura

Last reviewed 2023-11-13 UTC

Questo documento introduce una serie che descrive il networking e la sicurezza per le aziende che migrano i carichi di lavoro dei data center in Google Cloud. Queste architetture mettono in risalto la connettività avanzata, il modello Zero Trust principi di sicurezza e gestibilità in un ambiente ibrido.

Come descritto in un documento allegato, Architectures for Protecting Cloud Data Planes, le aziende eseguono il deployment di una vasta gamma di architetture che tengono conto delle le esigenze di connettività e sicurezza nel cloud. Classifichiamo queste architetture in tre modelli architetturali distinti: lift and shift, servizi ibridi e la tecnologia Zero Trust distribuita. Il documento attuale considera diverse diversi, a seconda dell'architettura scelta dall'azienda. Inoltre, descrive come realizzare questi approcci utilizzando i componenti di base forniti in Google Cloud. È consigliabile utilizzare queste indicazioni sulla sicurezza in combinazione con altre architetturali che riguardano affidabilità, disponibilità, scalabilità, prestazioni e governance.

Questo documento è progettato per aiutare gli architetti dei sistemi, amministratori di rete e amministratori della sicurezza che intendono eseguire la migrazione dei carichi di lavoro on-premise al cloud. Presuppone quanto segue:

  • Conosci i concetti di rete e sicurezza dei data center.
  • Hai carichi di lavoro esistenti nel tuo data center on-premise di conoscere cosa fanno e chi sono i suoi utenti.
  • Hai almeno alcuni carichi di lavoro di cui prevedi di eseguire la migrazione.
  • In genere conosci i concetti descritti in Architetture per la protezione di piani dati cloud.

La serie è costituita dai seguenti documenti:

Questo documento riassume i tre modelli architetturali principali e introduce i componenti di base delle risorse che puoi utilizzare per creare dell'infrastruttura. Infine, descrive come assemblare i componenti di base in un di architetture di riferimento che corrispondono ai pattern. Puoi utilizzare questi di riferimento per guidare la tua architettura.

In questo documento sono riportate le macchine virtuali (VM) come esempi di risorse dei carichi di lavoro. Le informazioni riguardano altre risorse che utilizzano reti VPC, come istanze Cloud SQL e nodi Google Kubernetes Engine.

Panoramica dei modelli architetturali

In genere, i tecnici di rete si sono concentrati sulla creazione delle reti fisiche dell'infrastruttura e della sicurezza nei data center on-premise.

Il percorso verso il cloud ha cambiato questo approccio perché il networking cloud sono software-defined. Nel cloud, i proprietari delle applicazioni hanno a disposizione e il controllo dello stack dell'infrastruttura sottostante. Hanno bisogno di un modello un perimetro sicuro e fornisce l'isolamento per i carichi di lavoro.

In questa serie, consideriamo tre modelli architetturali comuni. Questi modelli si basano l'uno sull'altro e possono essere visti come uno spettro piuttosto che come scelta rigorosa.

Schema lift and shift

Nel modello architetturale lift and shift, i proprietari di applicazioni aziendali e migrare i carichi di lavoro nel cloud senza doverli eseguire il refactoring. I tecnici di rete e della sicurezza utilizzano i controlli di livello 3 e 4 per fornire mediante una combinazione di appliance virtuali di rete che simulano dispositivi fisici on-premise e regole firewall su cloud nel VPC in ogni rete. I proprietari dei carichi di lavoro eseguono il deployment dei propri servizi nelle reti VPC.

Modello di servizi ibridi

I carichi di lavoro creati utilizzando lift and shift potrebbero richiedere l'accesso al cloud come BigQuery o Cloud SQL. In genere, l'accesso a queste services è disponibile al livello 4 e al livello 7. In questo contesto, l'isolamento e la sicurezza non può essere eseguita esclusivamente per il livello 3. Pertanto, il networking di servizi I Controlli di servizio VPC vengono utilizzati per fornire connettività e sicurezza in base al le identità del servizio a cui si accede e del servizio richiedendo l'accesso. In questo modello, è possibile esprimere criteri.

Pattern distribuito Zero Trust

In un'architettura Zero Trust, le applicazioni aziendali estendono la sicurezza dell'applicazione oltre i controlli perimetrali. All'interno del perimetro, i carichi di lavoro comunicano con altri carichi di lavoro solo se la loro identità IAM è un'autorizzazione specifica, negata per impostazione predefinita. In un sistema distribuito Zero Trust L'architettura e l'attendibilità si basano sull'identità e vengono applicate per ogni applicazione. I carichi di lavoro vengono creati come microservizi con identità emesse centralmente. Questo i servizi possono convalidare i chiamanti e prendere decisioni basate su criteri ogni richiesta per sapere se tale accesso è accettabile. Questa architettura spesso implementati utilizzando proxy distribuiti (un mesh di servizi) anziché utilizzare e gateway centralizzati.

Le aziende possono imporre l'accesso Zero Trust da parte di utenti e dispositivi alle aziende configurando Identity-Aware Proxy (IAP). IAP fornisce controlli basati sull'identità e sul contesto per gli utenti da internet o intranet.

Combinazione di pattern

Le aziende che creano o eseguono la migrazione delle proprie applicazioni aziendali al in genere utilizzano una combinazione di tutti e tre i pattern architetturali.

Google Cloud offre un portafoglio di prodotti e servizi che fungono i componenti di base per implementare il piano dati cloud su cui si basa l'architettura pattern. Questi componenti di base verranno illustrati più avanti in questo documento. La combinazione dei controlli forniti nel piano dati cloud, insieme controlli amministrativi per la gestione delle risorse cloud, che costituiscono la base di il perimetro di sicurezza end-to-end. Il perimetro creato da questa combinazione ti consente di gestire, eseguire il deployment e gestire i carichi di lavoro nel cloud.

Gerarchia delle risorse e controlli amministrativi

Questa sezione presenta un riepilogo dei controlli amministrativi che Google Cloud fornisce come container di risorse. I controlli includono le risorse, le cartelle e i progetti dell'organizzazione Google Cloud per gruppo e organizzare in modo gerarchico delle tue risorse cloud. Questa organizzazione gerarchica fornisce una proprietà strutturale e con punti di ancoraggio per applicare criteri e controlli.

Un account Google organizzazione è il nodo radice della gerarchia e la base per la creazione deployment nel cloud. Una risorsa organizzazione può avere cartelle e progetti da bambini. Una cartella contiene progetti o altre cartelle come figlio. Tutto il resto del cloud sono elementi figlio dei progetti.

Utilizzi cartelle come metodo per raggruppare i progetti. Progetti e costituisce la base per creare, abilitare e utilizzare tutte Google Cloud i servizi di machine learning. I progetti ti consentono di gestire le API, abilitare la fatturazione, aggiungere e rimuovere collaboratori e gestire le autorizzazioni.

Utilizzo di Google Identity and Access Management (IAM). puoi assegnare ruoli e definire i criteri di accesso e le autorizzazioni in livelli gerarchici. I criteri IAM vengono ereditati dalle risorse inferiori nella gerarchia. Questi criteri non possono essere modificati dai proprietari delle risorse che più in basso nella gerarchia. In alcuni casi, la gestione di identità e accessi forniti a un livello più granulare, ad esempio per quanto riguarda l'ambito degli oggetti in o cluster come Google Kubernetes Engine

Considerazioni sulla progettazione delle reti Google Virtual Private Cloud

Quando si progetta una strategia di migrazione al cloud, è importante sviluppare una strategia per l'uso delle reti VPC da parte della tua azienda. Puoi pensare a una rete VPC come a una versione virtuale rete fisica tradizionale. Si tratta di una rete privata completamente isolata della partizione di testo. Per impostazione predefinita, i carichi di lavoro o i servizi di cui viene eseguito il deployment La rete VPC non può comunicare con job in un'altra rete VPC. Le reti VPC pertanto abilitano per l'isolamento dei carichi di lavoro.

Poiché ogni rete VPC nel cloud è una rete ognuno con il proprio spazio di indirizzi IP privato. Puoi quindi utilizzare lo stesso indirizzo IP in più reti VPC senza conflitti. R una tipica distribuzione on-premise potrebbe consumare gran parte del modulo RFC 1918 di indirizzi IP privati. Se invece hai carichi di lavoro sia on-premise che nelle reti VPC, puoi riutilizzare lo stesso indirizzo in reti VPC diverse, purché queste reti non sono connesso o connesso in peering, riducendo così lo spazio di archiviazione degli indirizzi IP.

Le reti VPC sono globali

Le reti VPC in Google Cloud sono globali, il che significa che le risorse di cui è stato eseguito il deployment in un progetto che include una rete VPC comunicare direttamente tra loro utilizzando la rete backbone privata di Google.

Come mostra la figura 1, puoi avere una rete VPC nel progetto che contiene subnet in regioni diverse che coprono più zone. Le VM di qualsiasi regione possano comunicare privatamente tra loro utilizzando delle route VPC.

Implementazione della rete VPC globale di Google Cloud con subnet configurate in regioni diverse.

Figura 1. Rete VPC globale Google Cloud con subnet configurate in regioni diverse.

Condivisione di una rete mediante VPC condiviso

VPC condiviso consente a risorsa dell'organizzazione collegare più progetti a un progetto Rete VPC in modo che possano comunicare tra loro in modo sicuro tramite IP interni indirizzi IP dalla rete condivisa. amministratori di rete per quel tipo di condivisione l'applicazione della rete e il controllo centralizzato sulle risorse di rete.

Quando utilizzi un VPC condiviso, designi un progetto come progetto host, a cui colleghi uno o più progetti di servizio. Le reti VPC il progetto host sono denominate reti VPC condivise. Risorse idonee dai progetti di servizio possono utilizzare subnet della rete VPC condiviso.

Le aziende in genere utilizzano le reti VPC condiviso quando hanno bisogno di reti agli amministratori della sicurezza di centralizzare la gestione delle risorse di rete subnet e route. Allo stesso tempo, le reti VPC condiviso i team dedicati alle applicazioni e allo sviluppo creano ed eliminano le istanze VM ed eseguono in subnet designate con i progetti di servizio.

Isolamento degli ambienti tramite reti VPC

L'uso delle reti VPC per isolare gli ambienti comporta vantaggi, ma occorre considerare anche alcuni svantaggi. Questa sezione risolve questi compromessi e descrive i modelli comuni per l'implementazione e l'isolamento dei dati.

Motivi per isolare gli ambienti

Poiché le reti VPC rappresentano un dominio di isolamento, molte le aziende li utilizzano per mantenere gli ambienti o le unità aziendali in domini separati. I motivi più comuni per creare un isolamento a livello di VPC sono i seguenti:

  • Un'azienda vuole stabilire comunicazioni default-deny tra da una rete VPC e da un'altra, perché queste reti rappresentano una distinzione significativa a livello organizzativo. Per ulteriori informazioni, vedi Pattern di isolamento della rete VPC comuni più avanti in questo documento.
  • Un'azienda deve avere intervalli di indirizzi IP sovrapposti a causa ambienti on-premise preesistenti, a causa di acquisizioni o perché dei deployment in altri ambienti cloud.
  • Un'azienda vuole delegare il controllo amministrativo completo di una rete a una parte dell'azienda.

Svantaggi dell'isolamento degli ambienti

La creazione di ambienti isolati con reti VPC può avere alcuni svantaggi. Avere più reti VPC può aumentare l'overhead amministrativo associato alla gestione dei servizi su più reti. Questo documento illustra le tecniche che puoi utilizzare per gestire questa complessità.

Pattern di isolamento della rete VPC comuni

Esistono alcuni pattern comuni per isolare le reti VPC:

  • Isolare gli ambienti di sviluppo, gestione temporanea e produzione. Questo modello consente alle aziende di isolare completamente di sviluppo, gestione temporanea e produzione l'uno dall'altro. Nella questa struttura mantiene più copie complete delle applicazioni, con un'implementazione progressiva tra i singoli ambienti. In questo schema, Le reti VPC sono utilizzate come confini di sicurezza. Sviluppatori un elevato grado di accesso alle reti VPC di sviluppo svolgono il loro lavoro quotidiano. Al termine dello sviluppo, di produzione o QA possono migrare le modifiche a un progetto in cui le modifiche possono essere testate in modo integrato. Quando le modifiche sono pronte per il deployment, vengono inviate a un ambiente di produzione.
  • Isolare le unità aziendali. Alcune aziende vogliono imporre un livello grado di isolamento tra le unità aziendali, soprattutto nel caso acquisiti o che richiedono un elevato grado di autonomia e l'isolamento dei dati. In questo pattern, le aziende spesso creano un VPC rete per ciascuna unità aziendale e delegane il controllo VPC agli amministratori dell'unità aziendale. L'azienda utilizza le tecniche descritte più avanti in questo documento per esporre che coprono tutta l'azienda o per ospitare applicazioni rivolte agli utenti che comprendono più unità aziendali.

Suggerimento per la creazione di ambienti isolati

Ti consigliamo di progettare le reti VPC in modo da un dominio più ampio che si allinea ai confini amministrativi e di sicurezza della tua azienda. Puoi ottenere un ulteriore isolamento tra i carichi di lavoro eseguiti nella stessa rete VPC, usando controlli di sicurezza come firewall.

Per saperne di più sulla progettazione e la creazione di una strategia di isolamento la tua organizzazione, consulta Best practice e architetture di riferimento per la progettazione di VPC e Networking nel progetto delle basi aziendali di Google Cloud.

Componenti di base per il networking cloud

Questa sezione illustra gli importanti componenti di base per la connettività di rete, sicurezza di rete, networking e sicurezza dei servizi. La figura 2 mostra come questi componenti di base sono correlati tra loro. Puoi utilizzare una o più delle seguenti opzioni prodotti elencati in una determinata riga.

Componenti di base nell'ambito della sicurezza e della connettività di rete cloud.

Figura 2. Componenti di base nel campo della connettività di rete cloud sicurezza.

Nelle sezioni seguenti sono descritti tutti gli elementi di base e i servizi Google Cloud che puoi utilizzare per ciascuno dei blocchi.

Connettività di rete

Il blocco della connettività di rete si trova in base alla gerarchia. È responsabile della connessione delle risorse Google Cloud ai dati on-premise o altri cloud. In base alle tue esigenze, potrebbe essere necessaria solo una delle o potresti usarli tutti per gestire casi d'uso diversi.

Cloud VPN

Cloud VPN consente di connettere filiali remote o altri cloud provider a Google Reti VPC attraverso una connessione VPN IPsec. Il traffico tra le due reti è criptato da un gateway VPN e poi decriptato dall'altro gateway VPN, contribuendo così a proteggere i dati mentre navigano su internet.

Cloud VPN ti consente di abilitare la connettività tra i tuoi server on-premise dell'ambiente e Google Cloud senza l'overhead associato al provisioning le connessioni incrociate fisiche necessarie per Cloud Interconnect (descritto nella prossima sezione). Puoi eseguire il provisioning VPN ad alta disponibilità a soddisfare il requisito dello SLA (accordo sul livello del servizio) che prevede una disponibilità fino al 99,99% se disponi dei conforme all'architettura. Puoi prendere in considerazione l'utilizzo di Cloud VPN se le tue carichi di lavoro non richiedono bassa latenza o larghezza di banda elevata. Ad esempio: Cloud VPN è una buona scelta per i casi d'uso non mission-critical o per l'estensione della connettività ad altri cloud provider.

Cloud Interconnect

Cloud Interconnect fornisce connettività dedicata di livello enterprise a Google Cloud, una velocità effettiva superiore e prestazioni di rete più affidabili rispetto all'uso di VPN in entrata da internet. Interconnessione dedicata fornisce connettività fisica diretta alla rete Google dai tuoi router. Partner Interconnect offre una connettività dedicata attraverso un'ampia rete di partner, potrebbero offrire una copertura più ampia o altre opzioni di larghezza di banda rispetto Dedicated Interconnect. Cross-Cloud Interconnect fornisce connettività diretta dedicata dalle tue reti VPC ad altri cloud provider. Interconnessione dedicata richiede di connetterti a una struttura di colocation in cui Google è presente, ma Partner Interconnect al contrario. Cross-Cloud Interconnect ti consente di selezionare località che soddisfano i tuoi requisiti per stabilire le connessioni. Cloud Interconnect garantisce che il traffico tra i tuoi on-premise o un'altra rete cloud e la tua rete VPC non attraversa la rete internet pubblica.

Puoi eseguire il provisioning di queste connessioni Cloud Interconnect per soddisfare il requisito dello SLA (accordo sul livello del servizio) fino al 99,99% se si esegue il provisioning dell'architettura appropriata. Puoi valuta di utilizzare Cloud Interconnect per supportare carichi di lavoro che richiedono latenza, larghezza di banda elevata e prestazioni prevedibili, garantendo al contempo che tutte il tuo traffico rimane privato.

Network Connectivity Center per ambienti ibridi

Centro connettività di rete offre connettività site-to-site tra le infrastrutture on-premise e altre reti. A tale scopo, utilizza la rete backbone di Google per offrire e la connettività tra i tuoi siti.

Inoltre, puoi estendere la tua rete overlay SD-WAN esistente in Google Cloud configurando una VM fornitore di terze parti l'appliance router come allegato spoke logico.

Puoi accedere alle risorse all'interno delle reti VPC utilizzando l'appliance router, VPN o Cloud Interconnect come allegati spoke. Puoi utilizzare Network Connectivity Center per consolidare la connettività tra i tuoi siti on-premise, le tue presenze in altri cloud e Google Cloud e gestire tutto da un'unica vista.

Network Connectivity Center per reti VPC

Network Connectivity Center consente anche di creare un mesh tra molti VPC reti. Puoi connettere questa rete mesh a ambienti on-premise o ad altri cloud utilizzando Cloud VPN o Cloud Interconnect.

Peering di rete VPC

Peering di rete VPC di connettere le reti VPC Google in modo che i carichi di lavoro reti VPC diverse possono comunicare internamente, indipendentemente se appartengono allo stesso progetto o alla stessa risorsa dell'organizzazione. Il traffico rimane all'interno della rete Google e non attraversa la rete internet pubblica.

Il peering di rete VPC richiede che le reti da collegare in peering non abbiano che si sovrappongono.

Sicurezza della rete

Il blocco di sicurezza di rete si trova in cima al blocco di connettività di rete. È responsabile di consentire o negare l'accesso alle risorse in base caratteristiche dei pacchetti IP.

Regole firewall VPC

VPC regole firewall si applicano a una data rete. Con le regole firewall VPC puoi consentire di negare le connessioni da o verso le tue istanze VM, in base a una configurazione specificare. Le regole firewall abilitate per il VPC vengono applicate sempre, delle istanze a prescindere dalla loro configurazione, o se le VM si sono avviate completamente.

Ogni rete VPC funziona come un firewall distribuito. Sebbene le regole firewall sono definite a livello di rete, le connessioni sono consentite negati a livello di istanza. Puoi pensare al firewall VPC esistenti non solo tra le istanze e le altre reti, ma anche tra singole istanze nella stessa rete.

Criteri firewall gerarchici

Criteri firewall gerarchici consente di creare e applicare un criterio firewall coerente in tutta l'azienda. Questi criteri contengono regole che possono consentire o negare esplicitamente le connessioni. Tu possono assegnare criteri firewall gerarchici alla risorsa dell'organizzazione come all'interno di una cartella o a singole cartelle.

Mirroring pacchetto

Mirroring pacchetto clona il traffico di istanze specifiche nella tua rete VPC e inoltra ai raccoglitori per l'esame. Il mirroring dei pacchetti acquisisce tutto il traffico e i dati dei pacchetti, inclusi payload e intestazioni. Puoi configurare il mirroring sia per il traffico in entrata solo per il traffico in entrata o solo per il traffico in uscita. La il mirroring viene eseguito sulle istanze VM, non sulla rete.

Appliance virtuale di rete

Le appliance virtuali di rete consentono di applicare controlli di sicurezza e conformità alla rete virtuale in modo coerente con i controlli in loco completamente gestito di Google Cloud. Puoi farlo eseguendo il deployment delle immagini VM disponibili da Google Cloud Marketplace alle VM con più interfacce di rete, ciascuna collegata a una rete VPC diversa, per eseguire varie funzioni virtuali.

Di seguito sono riportati i casi d'uso tipici delle appliance virtuali:

  • Firewall di nuova generazione (NGFW). I firewall NGFW sono costituiti da un insieme centralizzato di firewall eseguiti come VM offrono funzionalità che non sono disponibili Regole firewall VPC. Le caratteristiche tipiche dei prodotti NGFW includono Ispezione approfondita dei pacchetti (DPI) e la protezione firewall a livello di applicazione. Alcuni NGFW offrono anche TLS/SSL controllo del traffico e altre funzioni di networking, come descritto più avanti in questo elenco.
  • Sistema di rilevamento delle intrusioni/sistema di prevenzione delle intrusioni (IDS/IPS). Un IDS basato su rete offre visibilità sul traffico potenzialmente dannoso. Per prevenire intrusioni, i dispositivi IPS possono bloccare il traffico dannoso per raggiungere la sua destinazione.
  • Gateway web sicuro (SWG). Un SWG blocca le minacce su internet che consente alle aziende di applicare criteri aziendali al traffico diretto e da internet. Ciò viene fatto utilizzando filtri degli URL, codici dannosi rilevamento e controllo dell'accesso.
  • Gateway NAT (Network Address Translation). Un gateway NAT traduce indirizzi IP e porte. Ad esempio, questo per evitare la sovrapposizione degli indirizzi IP. Google Cloud offre Cloud NAT come servizio gestito, ma questo servizio è disponibile solo per il traffico tramite internet, non per il traffico diretto verso l'ambiente on-premise ad altre reti VPC.
  • Web application firewall (WAF). Una WAF è progettata per bloccare il traffico HTTP(S) dannoso che raggiunge un indirizzo web un'applicazione. Google Cloud offre funzionalità WAF tramite Criteri di sicurezza di Google Cloud Armor. La funzionalità esatta varia a seconda del fornitore WAF, quindi è importante determinare ciò di cui hai bisogno.

Cloud IDS

Cloud IDS è un servizio di rilevamento delle intrusioni che offre il rilevamento delle intrusioni, malware, spyware e attacchi command-and-control sulla tua rete. Cloud IDS funziona creando una rete in peering gestita da Google contenente VM che riceveranno traffico sottoposto a mirroring. Il traffico sottoposto a mirroring viene quindi ispezionato di Palo Alto Networks tecnologie di protezione dalle minacce al fine di fornire un rilevamento avanzato delle minacce.

Cloud IDS offre visibilità completa sul traffico intra-subnet, di monitorare le comunicazioni da VM a VM e rilevare spostamento laterale.

Cloud NAT

Cloud NAT offre un supporto completamente gestito e software-defined (Network Address Translation) per diverse applicazioni. Abilita la Network Address Translation di origine (source NAT o SNAT). per il traffico su internet proveniente da VM che non hanno indirizzi IP esterni.

Firewall Insights

Approfondimenti sul firewall aiuta a comprendere e ottimizzare le regole del firewall. Fornisce dati su come vengono utilizzate le regole firewall, espone gli errori di configurazione identifica le regole che potrebbero essere rese più rigide. Utilizza anche il machine learning prevedere l'uso futuro delle regole firewall in modo da poter prendere decisioni informate le decisioni in merito alla rimozione o all'inasprimento delle regole che sembrano eccessivamente permissiva.

Log di rete

Puoi utilizzare più prodotti Google Cloud per registrare e analizzare la rete per via del traffico.

Logging delle regole firewall consente di controllare, verificare e analizzare gli effetti delle regole firewall. Per Ad esempio, puoi determinare se una regola firewall progettata per negare il traffico funzionando come previsto. Il logging delle regole firewall è utile anche devi determinare quante connessioni sono interessate da una determinata regola firewall.

Puoi abilitare il logging delle regole firewall singolarmente per ogni regola firewall di cui devi registrare le connessioni. Il logging delle regole firewall è un'opzione per qualsiasi regola firewall, indipendentemente dall'azione (consenti/nega) o dalla direzione (in entrata o in uscita) della regola.

Log di flusso VPC registra un campione di flussi di rete inviati e ricevuti istanze VM, incluse le istanze utilizzate Nodi di Google Kubernetes Engine (GKE). Questi log possono essere utilizzati per monitoraggio della rete, analisi forense e sicurezza in tempo reale l'analisi dei dati e l'ottimizzazione delle spese.

Networking di servizi

I blocchi del networking di servizi sono responsabili della fornitura di servizi di ricerca che indicare ai servizi dove deve essere inviata una richiesta (DNS, Service Directory) e ricevere richieste al luogo corretto (Private Service Connect, Cloud Load Balancing).

Cloud DNS

Si accede ai carichi di lavoro utilizzando i nomi di dominio. Cloud DNS offre una traduzione affidabile e a bassa latenza dei nomi di dominio in indirizzi IP si trovano ovunque nel mondo. Cloud DNS offre entrambe le zone pubbliche e zone DNS gestite private. Una zona pubblica è visibile sulla rete internet pubblica mentre una zona privata è visibile solo da uno o più VPC da te specificate.

Cloud Load Balancing

All'interno di Google Cloud, bilanciatori del carico sono un componente fondamentale: instradano il traffico a vari servizi per garantire velocità e per contribuire a garantire la sicurezza a livello globale per per il traffico esterno.

Inoltre, i nostri bilanciatori del carico consentono il routing e la scalabilità del traffico su più cloud o ibridi. Questo rende Cloud Load Balancing il "porta principale" grazie alla quale è possibile scalare qualsiasi applicazione, indipendentemente da dove si trovi e dal numero luoghi in cui è ospitato. Google offre vari tipi di bilanciamento del carico: globale e regionale, esterno e interno e di livello 4 e 7.

Service Directory

Service Directory consente di gestire l'inventario dei servizi, offrendo un'unica posizione sicura in cui servizi di pubblicazione, scoperta e connessione, tutte le operazioni supportate da controllo dell'accesso basato sull'identità. Consente di registrare i servizi denominati e i relativi endpoint. La registrazione può essere manuale o utilizzando integrazioni con Private Service Connect, GKE e Cloud Load Balancing. La Service Discovery è possibile usando API HTTP e gRPC, nonché tramite Cloud DNS.

Mesh di servizi: Cloud Service Mesh e Cloud Service Mesh

Entrambi Cloud Service Mesh e Cloud Service Mesh sono progettate per facilitare l'esecuzione di applicazioni complesse e distribuite tramite abilitare un ricco insieme di criteri di gestione del traffico e di sicurezza nel mesh di servizi diverse architetture. Le differenze principali tra questi prodotti stanno nel fatto che ambienti supportati, nelle API Istio per loro e nei loro di bilanciamento del carico.

Cloud Service Mesh è ideale per le reti globali e regionali basate su Kubernetes di deployment, sia Google Cloud che on-premise, che traggono vantaggio da gestito Istio prodotto.

Cloud Service Mesh è ideale per i casi d'uso di networking che presentano funzionalità di di cui è stato eseguito il deployment a livello globale in Google Cloud. Cloud Service Mesh gestisce i carichi di lavoro utilizzando Envoy proxy che agiscono da file collaterali o gateway oppure utilizzando gRPC senza proxy carichi di lavoro con scale out impegnativi.

La tabella seguente riassume le funzionalità di Cloud Service Meshy e Cloud Service Mesh.

Anthos Service Mesh Traffic Director
Tipo di deployment Kubernetes VM, Kubernetes
Ambienti Google Cloud, on-premise, multi-cloud Google Cloud, on-premise, multi-cloud
Ambito deployment Regionale e federata Globale
Piattaforma API Istio Routing dei servizi (Kubernetes modello gateway)
Connettività di rete Sidecar Envoy Sidecar Envoy, gRPC senza proxy
Distribuzione del carico globale in base all'integrità del backend Sì (in base a Kubernetes) Sì
Distribuzione del carico globale basata sul carico del backend No Sì
Identità gestita per mTLS dei carichi di lavoro (zero-trust) Sì Sì (solo GKE)

Google ha ulteriormente approfondito come creare uno Zero Trust end-to-end l'ambiente di architettura distribuita utilizzando BeyondProd dell'architettura. Oltre all'autenticazione del perimetro di rete e del servizio autorizzazione, BeyondProd descrive in dettaglio come gli ambienti di calcolo sono affidabili, la provenienza del codice e le implementazioni dei deployment svolgono un ruolo un'architettura di servizi Zero Trust distribuita. Devi considerare questi aspetti che vanno oltre il networking quando adotti un approccio Zero Trust.

Private Service Connect

Private Service Connect crea astrazioni di servizi rendendo i carichi di lavoro accessibili tramite un singolo endpoint. Ciò consente a due reti per comunicare in un modello client-server che espone solo il servizio dell'intera rete o del carico di lavoro stesso. R orientato ai servizi consente agli amministratori di rete di che espongono tra reti anziché subnet o VPC, consentendo il consumo effettivo dei servizi in un modello produttore-consumatore, che sia proprietario servizi di terze parti (SaaS).

Con Private Service Connect, un VPC consumer può utilizza un indirizzo IP privato per connetterti a un API di Google oppure un servizio in un altro VPC.

Puoi estendere Private Service Connect alla rete on-premise per accedere agli endpoint che si connettono alle API di Google o ai servizi gestiti in un'altra rete VPC. Private Service Connect consente il consumo dei servizi di livello 4 o 7.

Per il livello 4, Private Service Connect richiede che il producer e la creazione di una o più subnet specifiche di Private Service Connect. Queste subnet sono chiamate anche subnet NAT. Private Service Connect esegue la traduzione NAT utilizzando un indirizzo IP selezionato da una delle subnet Private Service Connect per instradare le richieste a un producer di servizi. Questo approccio ti consente di utilizzare la sovrapposizione di indirizzi IP tra consumatori e produttori.

Nel livello 7, puoi crea un backend Private Service Connect delle applicazioni utilizzando un bilanciatore del carico delle applicazioni interno. Il bilanciatore del carico delle applicazioni interno ti consente di scegliere i servizi sono disponibili utilizzando Mappa URL. Per ulteriori informazioni, vedi Informazioni sui backend Private Service Connect.

Accesso privato ai servizi

Accesso privato ai servizi è una connessione privata tra la tua rete VPC e una rete di proprietà di Google o di terze parti. Google o le terze parti che sono noti come producer di servizi. Utilizzi dell'accesso privato ai servizi il peering di rete VPC per stabilire la connettività e richiede reti VPC consumer e consumer per il peering tra loro. È diverso da Private Service Connect, che ti consente un singolo indirizzo IP privato nella tua subnet.

La connessione privata consente alle istanze VM nella tua rete VPC i servizi a cui accedi comunicano esclusivamente tramite indirizzi IP interni. Le istanze VM non richiedono l'accesso a internet o indirizzi IP esterni per raggiungere disponibili tramite l'accesso privato ai servizi. Servizi privati l'accesso può anche essere estesa alla rete on-premise utilizzando Cloud VPN o Cloud Interconnect per fornire un modo dagli host on-premise per raggiungere la rete del producer di servizi. Per un elenco di Per i servizi gestiti da Google supportati tramite l'accesso privato ai servizi, consulta: Servizi supportati nella documentazione del virtual private cloud.

Accesso VPC serverless

Accesso VPC serverless ti permette di connetterti direttamente alla tua rete VPC da servizi ospitati in ambienti serverless come Cloud Run, in App Engine o Cloud Functions. Configurazione in corso... L'accesso VPC serverless consente all'ambiente serverless di inviare richieste alla tua rete VPC utilizzando il DNS interno e l'IP interno indirizzi IP esterni. Le risposte a queste richieste utilizzano anche la tua rete virtuale.

L'accesso VPC serverless invia traffico interno dalla rete VPC all'ambiente serverless solo quando è una risposta a una richiesta inviata dal tuo ambiente serverless attraverso il connettore di accesso VPC serverless.

L'accesso VPC serverless offre i seguenti vantaggi:

  • Le richieste inviate alla tua rete VPC non sono mai esposte su internet.
  • La comunicazione tramite l'accesso VPC serverless può avere meno risorse più elevata rispetto alla comunicazione su internet.

Sicurezza dei servizi

Il servizio di sicurezza blocca l'accesso alle risorse in base all'identità richiedente o basato su una comprensione di livello più alto dei pattern dei pacchetti invece che ma solo le caratteristiche di un singolo pacchetto.

Google Cloud Armor per DDoS/WAF

Google Cloud Armor è un web application firewall (WAF) e un Distributed Denial-of-Service (DDoS) di mitigazione che ti aiuta a difendere le applicazioni e i servizi web diversi tipi di minacce. Queste minacce includono attacchi DDoS, attacchi basati sul web come cross-site scripting (XSS) e SQL injection (SQLi), nonché attività fraudolente e attacchi basati sull'automazione.

Google Cloud Armor ispeziona le richieste in entrata sul perimetro globale di Google. Ha un insieme integrato di regole web application firewall attacchi web comuni e un livello avanzato Sistema di rilevamento degli attacchi basato su ML che crea un modello di traffico di qualità e rileva il traffico non valido. Infine, Google Cloud Armor si integra con reCAPTCHA per contribuire a rilevare e bloccare attacchi sofisticati basati su frodi e automazione, utilizzando sia la telemetria degli endpoint che la telemetria del cloud.

Identity-Aware Proxy (IAP)

Identity-Aware Proxy (IAP) fornisce controlli di accesso sensibili al contesto ad applicazioni e VM basate su cloud che sono in esecuzione su Google Cloud o sono connessi a Google Cloud utilizzando una qualsiasi delle tecnologie di networking ibride. IAP verifica l'identità dell'utente e determina se la richiesta dell'utente proviene da un account in base a vari attributi contestuali. Inoltre, IAP supporta il tunneling TCP per l'accesso SSH/RDP dagli utenti aziendali.

Controlli di servizio VPC

Controlli di servizio VPC ti aiuta a mitigare il rischio di esfiltrazione di dati da Google Cloud come Cloud Storage e BigQuery. Utilizzo I Controlli di servizio VPC aiutano a garantire che l'utilizzo dei avvengono solo negli ambienti approvati.

Puoi utilizzare Controlli di servizio VPC per creare perimetri che proteggono le risorse e i dati dei servizi specificati limitando l'accesso a dati specifici costrutti di identità cloud-native come gli account di servizio e VPC reti. Dopo la creazione di un perimetro, l'accesso all'account Google viene negata a meno che la richiesta non provenga dall'interno del perimetro.

Distribuzione di contenuti

I blocchi di importazione dei contenuti controllano l'ottimizzazione della pubblicazione di applicazioni e contenuti.

Cloud CDN

Cloud CDN fornisce l'accelerazione dei contenuti statici utilizzando la rete perimetrale globale di Google pubblicare contenuti dal punto più vicino all'utente. Ciò contribuisce a ridurre la latenza nei tuoi siti web e nelle tue applicazioni.

Media CDN

Media CDN è la soluzione di distribuzione dei media di Google ed è creata per il traffico in uscita a velocità effettiva elevata carichi di lavoro con scale out impegnativi.

Osservabilità

I blocchi di osservabilità ti offrono visibilità sulla rete e forniscono insight che possono essere utilizzati per risolvere, documentare e analizzare i problemi.

Network Intelligence Center

Centro Network Intelligence Center comprende diversi prodotti che affrontano diversi aspetti della rete osservabilità. Ogni prodotto è incentrato su un argomento diverso e fornisce informazioni dettagliate che informare amministratori, architetti e professionisti sull'integrità e sui problemi della rete.

Architetture di riferimento

I seguenti documenti presentano architetture di riferimento per diversi tipi di carichi di lavoro ibridi: intra-cloud, per internet e ibridi. Questi carichi di lavoro le architetture sono basate su un piano dati cloud realizzato utilizzando gli elementi di base e i modelli architettonici delineati sezioni precedenti di questo documento.

Puoi utilizzare le architetture di riferimento per progettare modi eseguire la migrazione o la creazione di carichi di lavoro nel cloud. I tuoi carichi di lavoro sono quindi supportati il piano dati cloud e utilizzare le architetture. Sebbene questi documenti non forniscono un insieme esaustivo di architetture di riferimento, coprono la maggior parte scenari più comuni.

Come per i modelli dell'architettura di sicurezza descritti in Architetture per la protezione di piani dati cloud, potrebbero utilizzare una combinazione di questi design. Questi documenti di ogni tipo di carico di lavoro e le considerazioni relative a ciascun tipo dell'architettura.

Passaggi successivi