Progettazione di reti per la migrazione dei carichi di lavoro aziendali: approcci architettonici

Last reviewed 2023-11-13 UTC

Questo documento introduce una serie che descrive le architetture di networking e sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro dei data center su 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 implementano un ampio spettro di architetture che tengono conto delle 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 insieme ad altri architetturali che riguardano affidabilità, disponibilità, scalabilità, prestazioni e governance.

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

  • Hai familiarità con i concetti di networking 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.
  • Hai familiarità con i concetti descritti in Architetture per la protezione dei data plane cloud.

La serie è composta 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 gli elementi di base in una serie 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, gli ingegneri di rete si sono concentrati sulla creazione dell'infrastruttura di rete fisica e dell'infrastruttura di 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 un controllo limitato sull'infrastruttura sottostante. Hanno bisogno di un modello con un perimetro sicuro che fornisca isolamento per i loro carichi di lavoro.

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

Schema lift and shift

Nel pattern di architettura lift-and-shift, i proprietari di applicazioni aziendali migrano i loro carichi di lavoro nel cloud senza eseguirne 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 il lift and shift potrebbero richiedere l'accesso a servizi 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 dei servizi e Controlli di servizio VPC vengono utilizzati per fornire connettività e sicurezza in base alle identità del servizio a cui si accede e del servizio che richiede l'accesso. In questo modello, è possibile esprimere criteri.

Modello 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 possono comunicare con altri carichi di lavoro solo se la loro identità IAM dispone di un'autorizzazione specifica, che è negata per impostazione predefinita. In un'architettura distribuita Zero Trust, l'affidabilità si basa sull'identità ed è applicata 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 il traffico degli utenti da internet o intranet.

Combinare 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 da elementi costitutivi per implementare il piano dati cloud alla base dei pattern di architettura. Questi componenti di base verranno illustrati più avanti in questo documento. La combinazione di controlli forniti nel data plane cloud, insieme ai controlli amministrativi per gestire le risorse cloud, costituisce la base di un 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 ti fornisce una struttura di proprietà e punti di ancoraggio per l'applicazione di criteri e controlli.

Una risorsa organizzazione di Google è il nodo radice della gerarchia e costituisce la base per creare i deployment nel cloud. Una risorsa organizzazione può avere cartelle e progetti da bambini. Una cartella ha progetti o altre cartelle come elementi secondari. Tutte le altre risorse cloud sono elementi figlio dei progetti.

Utilizzi le cartelle come metodo per raggruppare i progetti. I progetti sono la base per creare, abilitare e utilizzare tutti i servizi Google Cloud. I progetti ti consentono di gestire le API, attivare la fatturazione, aggiungere e rimuovere collaboratori e gestire le autorizzazioni.

Con Identity and Access Management (IAM) di Google, puoi assegnare ruoli e definire criteri e autorizzazioni di accesso a tutti i livelli della gerarchia delle risorse. I criteri IAM vengono ereditati dalle risorse inferiori nella gerarchia. Questi criteri non possono essere modificati dai proprietari delle risorse che si trovano 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 progetti una strategia di migrazione al cloud, è importante sviluppare una strategia per l'utilizzo 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 è stato eseguito il deployment in una rete VPC non possono comunicare con i job di 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. Di conseguenza, puoi utilizzare lo stesso indirizzo IP in più reti VPC senza conflitti. Un tipico deployment on-premise potrebbe consumare una grande porzione dello spazio di indirizzi IP privati RFC 1918. D'altra parte, se hai carichi di lavoro sia on-premise che nelle reti VPC, puoi riutilizzare gli stessi intervalli di indirizzi in reti VPC diverse, a condizione che queste reti non siano collegate o in peering, utilizzando così lo spazio degli indirizzi IP meno rapidamente.

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 mostrato nella figura 1, nel tuo progetto puoi avere una rete VPC contenente subnet in regioni diverse che si estendono su più zone. Le VM di qualsiasi regione possano comunicare privatamente tra loro utilizzando delle route VPC.

Implementazione di una rete VPC globale di Google Cloud con sottoreti 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. Gli amministratori di rete della rete condivisa applicano e impongono 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 nel progetto host sono chiamate reti VPC condivise. Risorse idonee dai progetti di servizio possono utilizzare subnet della rete VPC condiviso.

Le aziende in genere utilizzano le reti VPC condivise quando hanno bisogno che gli amministratori di rete e di sicurezza centralizzino la gestione delle risorse di rete come subnet e route. Allo stesso tempo, le reti VPC condivise consentono ai team di sviluppo e delle applicazioni di creare ed eliminare istanze VM e di eseguire il deployment dei carichi di lavoro in subnet designate utilizzando 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 discute questi compromessi e descrive schemi comuni per l'implementazione dell'isolamento.

Motivi per isolare gli ambienti

Poiché le reti VPC rappresentano un dominio di isolamento, molte imprese le utilizzano per mantenere ambienti o unità aziendali in domini separati. Di seguito sono riportati i motivi più comuni per creare l'isolamento a livello di VPC:

  • 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, consulta Modelli comuni di isolamento della rete VPC più avanti in questo documento.
  • Un'azienda deve avere intervalli di indirizzi IP sovrapposti a causa di ambienti on-premise preesistenti, acquisizioni o implementazioni 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ò comportare 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 pattern consente alle aziende di separare completamente gli ambienti di sviluppo, di gestione temporanea e di produzione. In effetti, questa struttura gestisce più copie complete delle applicazioni, con un'implementazione progressiva tra ciascun ambiente. In questo pattern, le reti VPC vengono 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 modello, le aziende spesso creano una rete VPC per ogni unità aziendale e delegandone il controllo agli amministratori dell'unità. L'azienda utilizza le tecniche descritte più avanti in questo documento per esporre servizi che coprono l'azienda o per ospitare applicazioni rivolte agli utenti che coprono più unità di business.

Consiglio 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 isolamento aggiuntivo tra i carichi di lavoro in esecuzione nella stessa rete VPC utilizzando controlli di sicurezza come i firewall.

Per saperne di più su come progettare e creare una strategia di isolamento per la tua organizzazione, consulta Best practice e architetture di riferimento per la progettazione di VPC e Networking nel blueprint Google Cloud Enterprise Foundations.

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 la relazione tra questi elementi costitutivi. Puoi utilizzare uno o più prodotti elencati in una determinata riga.

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

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

Le sezioni seguenti descrivono ciascuno dei componenti di base e i servizi Google Cloud che puoi utilizzare per ciascuno di essi.

Connettività di rete

Il blocco della connettività di rete si trova in base alla gerarchia. È responsabile della connessione delle risorse Google Cloud ai data center on-premise o ad altri cloud. A seconda delle tue esigenze, potresti aver bisogno di uno solo di questi prodotti o potresti utilizzarli tutti per gestire casi d'uso diversi.

Cloud VPN

Cloud VPN ti consente di connettere le sedi distaccate remote o altri provider cloud alle reti VPC di Google Cloud tramite una connessione VPN IPsec. Il traffico tra le due reti viene criptato da un gateway VPN e decriptato dall'altro gateway VPN, contribuendo così a proteggere i dati durante il transito 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 valutare la possibilità di utilizzare Cloud VPN se i tuoi carichi di lavoro non richiedono latenza ridotta o larghezza di banda elevata. Ad esempio, Cloud VPN è una buona scelta per i casi d'uso non critici o per estendere la 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. Dedicated Interconnect fornisce connettività fisica diretta alla rete di Google dai tuoi router. Partner Interconnect fornisce connettività dedicata tramite una vasta rete di partner, che potrebbero offrire una copertura più ampia o altre opzioni di larghezza di banda rispetto a Dedicated Interconnect. Cross-Cloud Interconnect fornisce connettività diretta dedicata dalle tue reti VPC ad altri cloud provider. Dedicated Interconnect richiede una connessione in una struttura di colocation in cui è presente Google, diversamente da Partner Interconnect. Cross-Cloud Interconnect ti consente di selezionare le 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 un requisito SLA di disponibilità fino al 99,99% se esegui il provisioning dell'architettura appropriata. Puoi valuta di utilizzare Cloud Interconnect per supportare carichi di lavoro che richiedono latenza elevata, larghezza di banda elevata e prestazioni prevedibili, garantendo al contempo che tutte il tuo traffico rimane privato.

Network Connectivity Center per ibride

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 a Google Cloud configurando una VM o un'appliance router di un fornitore di terze parti come collegamento spoke logico.

Puoi accedere alle risorse all'interno delle reti VPC utilizzando l'appliance router, VPN o Cloud Interconnect di rete 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 ti consente anche di creare una rete mesh tra molte reti VPC. Puoi connettere questo mesh a cloud on-premise o di altri cloud utilizzando Cloud VPN o Cloud Interconnect.

Peering di rete VPC

Il peering di reti VPC ti consente di connettere le reti VPC di Google in modo che i carichi di lavoro in reti VPC diverse possano comunicare internamente, indipendentemente dal fatto che appartengano allo stesso progetto o alla stessa risorsa dell'organizzazione. Il traffico rimane all'interno della rete di 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 Sicurezza della rete si trova sopra il blocco 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. Le regole firewall VPC ti consentono di consentire o negare le connessioni da o verso le tue istanze VM in base a una configurazione da te specificata. Le regole firewall abilitate per il VPC vengono applicate sempre in modo da proteggere le istanze a prescindere dalla configurazione, dal sistema operativo o dall'avvenuto avvio completo delle VM.

Ogni rete VPC funziona come un firewall distribuito. Sebbene le regole firewall siano definite a livello di rete, le connessioni vengono consentite o negate a livello di istanza. Puoi considerare le regole del firewall VPC come esistenti non solo tra le tue istanze e altre reti, ma anche tra singole istanze all'interno della 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 negare o consentire esplicitamente le connessioni. Puoi assegnare criteri firewall gerarchici alla risorsa dell'organizzazione nel suo insieme 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 i payload e le intestazioni. Puoi configurare il mirroring sia per il traffico in entrata sia per quello in uscita, solo per il traffico in entrata o solo per quello in uscita. Il mirroring avviene 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 per le 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 il filtraggio degli URL, il rilevamento di codice dannoso e il controllo dell'accesso.
  • Gateway NAT (Network Address Translation). Un gateway NAT traduce indirizzi IP e porte. Ad esempio, questa traduzione consente di evitare l'accatastamento 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 il traffico sottoposto a mirroring. Il traffico sottoposto a mirroring viene poi esaminato dalle tecnologie di protezione dalle minacce di Palo Alto Networks per 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, ovvero il supporto per Network Address Translation diverse applicazioni. Consente la Network Address Translation dell'origine (NAT dell'origine o SNAT) per il traffico in entrata da internet proveniente da VM che non dispongono di indirizzi IP esterni.

Firewall Insights

Firewall Insights ti aiuta a comprendere e ottimizzare le tue regole 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 inoltre il machine learning per prevedere l'utilizzo futuro delle regole del firewall, in modo da poter prendere decisioni consapevoli su come rimuovere o rafforzare le regole che sembrano eccessivamente permissive.

Log di rete

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

Il logging delle regole del firewall consente di controllare, verificare e analizzare gli effetti delle regole del 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 se devi determinare quante connessioni sono interessate da una determinata regola firewall.

Devi attivare il logging delle regole firewall singolarmente per ogni regola firewall per le cui connessioni devi generare log. 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.

I log di flusso VPC registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM, incluse quelle utilizzate come nodi Google Kubernetes Engine (GKE). Questi log possono essere utilizzati per monitoraggio della rete, analisi forense, analisi della sicurezza in tempo reale e 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 sia zone pubbliche sia 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, nonché a livello 4 e 7.

Service Directory

Service Directory ti consente di gestire l'inventario dei servizi, fornendo un unico posto sicuro per pubblicare, scoprire e connettere i servizi, tutte operazioni basate sul controllo di 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 principali differenze tra questi prodotti riguardano gli ambienti supportati, le API Istio a loro dedicate e le funzionalità di bilanciamento del carico a livello globale.

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 rete che presentano servizi di cui è stato eseguito il deployment a livello globale in Google Cloud e che sono attenti allo stato e al carico. Cloud Service Mesh gestisce i carichi di lavoro utilizzando proxy Envoy che fungono da sidecar o gateway oppure utilizzando carichi di lavoro gRPC senza proxy.

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

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 Regionali e federate 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 dell'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 se 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. Un modello di rete orientato ai servizi consente agli amministratori di rete di ragionare sui servizi che espongono tra le reti anziché tra le subnet o le VPC, consentendo il consumo dei servizi in un modello produttore-consumatore, sia per i servizi di proprietà sia per quelli di terne 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 di servizi a livello 4 o 7.

A livello 4, Private Service Connect richiede al producer di creare una o più sottoreti specifiche per Private Service Connect. Queste subnet sono chiamate anche subnet NAT. Private Service Connect esegue la NAT di origine utilizzando un indirizzo IP selezionato da una delle subnet di Private Service Connect per instradare le richieste a un producer di servizi. Questo approccio ti consente di utilizzare indirizzi IP sovrapposti tra consumer e producer.

A livello 7, puoi creare un backend Private Service Connect 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 accesso a internet o indirizzi IP esterni per raggiungere i servizi disponibili tramite l'accesso ai servizi privati. 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 dei servizi gestiti da Google supportati tramite l'accesso ai servizi privati, consulta Servizi supportati nella documentazione di 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, le funzioni di App Engine, o Cloud Run. 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 il traffico interno dalla rete VPC all'ambiente serverless solo quando il traffico è una risposta a una richiesta inviata dall'ambiente serverless tramite 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

I blocchi di sicurezza del servizio controllano l'accesso alle risorse in base all'identità del richiedente o in base a una comprensione di livello superiore dei pattern dei pacchetti anziché solo alle 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) e attività fraudolente e attacchi basati sull'automazione.

Google Cloud Armor ispeziona le richieste in entrata sul perimetro globale di Google. Dispone di un insieme integrato di regole di firewall per applicazioni web per rilevare gli attacchi web comuni e un sistema avanzato di rilevamento degli attacchi basato sull'IA che crea un modello di traffico valido e poi rileva il traffico dannoso. 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 aiutano a ridurre il rischio di esfiltrazione dei dati dai servizi 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 aver creato un perimetro, l'accesso ai servizi Google specificati viene negato, a meno che la richiesta non provenga dall'interno del perimetro.

Distribuzione di contenuti

I blocchi di importazione dei contenuti controllano l'ottimizzazione della distribuzione 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. In questo modo puoi ridurre la latenza per i tuoi siti web e le tue applicazioni.

Media CDN

Media CDN è la soluzione di distribuzione dei contenuti multimediali di Google ed è progettata per i carichi di lavoro in uscita con un'elevata velocità in uscita.

Osservabilità

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

Network Intelligence Center

Network Intelligence Center comprende diversi prodotti che affrontano vari aspetti dell'osservabilità della rete. 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: intra-cloud, rivolti a 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 per eseguire la migrazione o creare carichi di lavoro nel cloud. I tuoi carichi di lavoro sono quindi supportati dal piano dati cloud e utilizzano 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 discusso ogni tipo di carico di lavoro e le considerazioni per ogni architettura di sicurezza.

Passaggi successivi