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

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 a Google Cloud. Queste architetture sottolineano la connettività avanzata, i principi di sicurezza Zero Trust e la gestibilità in un ambiente ibrido.

Come descritto in un documento allegato, Architetture per la protezione di piani dati cloud, le aziende eseguono il deployment di una vasta gamma 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 distribuiti Zero Trust. Il documento attuale prende in considerazione diversi approcci alla sicurezza, a seconda dell'architettura scelta dall'azienda. Inoltre, descrive come realizzare questi approcci utilizzando i componenti di base forniti da Google Cloud. Dovresti utilizzare queste linee guida sulla sicurezza insieme ad altre linee guida sull'architettura per 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 hanno intenzione di eseguire la migrazione dei carichi di lavoro on-premise nel cloud. Presuppone quanto segue:

  • Hai familiarità con i concetti di rete e sicurezza dei data center.
  • Disponi di carichi di lavoro esistenti nel tuo data center on-premise e conosci il loro funzionamento e chi sono i loro utenti.
  • Hai almeno alcuni carichi di lavoro di cui prevedi di eseguire la migrazione.
  • In genere hai familiarità con i concetti descritti in Architetture per la protezione di piani dati cloud.

La serie è costituita dai seguenti documenti:

Questo documento riassume i tre pattern architetturali principali e introduce i componenti di base delle risorse che puoi utilizzare per creare la tua infrastruttura. Infine, descrive come assemblare i componenti di base in una serie di architetture di riferimento corrispondenti ai pattern. Puoi usare queste architetture di riferimento per guidare la tua architettura.

Questo documento menziona le macchine virtuali (VM) come esempi di risorse dei carichi di lavoro. Le informazioni si applicano ad altre risorse che utilizzano reti VPC, come istanze Cloud SQL e nodi Google Kubernetes Engine.

Panoramica dei pattern architettonici

In genere, gli ingegneri di rete si sono concentrati sulla creazione dell'infrastruttura di networking fisica e della sicurezza nei data center on-premise.

Il percorso verso il cloud ha cambiato questo approccio perché le strutture di networking cloud sono software-defined. Nel cloud, i proprietari delle applicazioni hanno un controllo limitato dello stack dell'infrastruttura sottostante. Ha bisogno di un modello che abbia un perimetro sicuro e che fornisca l'isolamento per i carichi di lavoro.

In questa serie, prenderemo in considerazione tre modelli architettonici comuni. Questi pattern si basano l'uno sull'altro e possono essere visti come uno spettro piuttosto che una scelta rigorosa.

Sequenza lift and shift

Nel modello architetturale lift and shift, i proprietari di applicazioni aziendali migrano i carichi di lavoro nel cloud senza doverli ricorrere al refactoring. I tecnici di rete e della sicurezza utilizzano i controlli di livello 3 e 4 per fornire protezione tramite una combinazione di appliance virtuali di rete che imitano i dispositivi fisici in loco e le regole del firewall cloud nella rete VPC. I proprietari dei carichi di lavoro eseguono il deployment dei propri servizi nelle reti VPC.

Pattern di servizi ibridi

I carichi di lavoro creati utilizzando lift and shift potrebbero richiedere l'accesso a servizi cloud come BigQuery o Cloud SQL. Generalmente, l'accesso a questi servizi cloud avviene al livello 4 e 7. In questo contesto, l'isolamento e la sicurezza non possono essere eseguiti rigorosamente al livello 3. Di conseguenza, il networking dei servizi e i Controlli di servizio VPC vengono utilizzati per fornire connettività e sicurezza in base alle identità del servizio a cui viene eseguito l'accesso e del servizio che richiede l'accesso. In questo modello è possibile definire criteri di controllo dell'accesso avanzati.

Pattern distribuito Zero Trust

In un'architettura Zero Trust, le applicazioni aziendali estendono l'applicazione di sicurezza 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 ha un'autorizzazione specifica, il che viene negata per impostazione predefinita. In un'architettura distribuita Zero Trust, il trust è basato sull'identità e viene applicato per ogni applicazione. I carichi di lavoro sono creati come microservizi con identità emesse centralmente. In questo modo, i servizi possono convalidare i chiamanti e prendere decisioni basate su criteri per ogni richiesta circa l'accettabilità dell'accesso. Questa architettura viene spesso implementata utilizzando proxy distribuiti (un mesh di servizi) invece di gateway centralizzati.

Le aziende possono imporre l'accesso Zero Trust da utenti e dispositivi alle applicazioni aziendali configurando Identity-Aware Proxy (IAP). IAP offre controlli basati su identità e contesto per il traffico degli utenti da internet o intranet.

Combinazione di pattern

Le aziende che creano o migrano le proprie applicazioni aziendali al cloud di solito usano una combinazione di tutti e tre i pattern di architettura.

Google Cloud offre un portafoglio di prodotti e servizi che fungono da componenti di base per implementare il piano dati cloud su cui si basano i pattern architetturali. Questi componenti di base vengono trattati più avanti in questo documento. La combinazione di controlli forniti nel piano dati cloud, insieme a controlli amministrativi per gestire le risorse cloud, costituiscono la base di un perimetro di sicurezza end-to-end. Il perimetro creato da questa combinazione consente di gestire, implementare e gestire i carichi di lavoro nel cloud.

Gerarchia delle risorse e controlli amministrativi

Questa sezione presenta un riepilogo dei controlli amministrativi forniti da Google Cloud come container di risorse. I controlli includono risorse dell'organizzazione, cartelle e progetti di Google Cloud che ti consentono di raggruppare e organizzare in modo gerarchico le risorse cloud. Questa organizzazione gerarchica offre una struttura di proprietà e punti di ancoraggio per l'applicazione di criteri e controlli.

Una risorsa dell'organizzazione Google è il nodo radice della gerarchia e la base per la creazione di deployment nel cloud. Una risorsa organizzazione può avere cartelle e progetti come elementi figlio. Una cartella contiene progetti o altre cartelle come elementi figlio. Tutte le altre risorse cloud sono elementi figlio dei progetti.

Puoi utilizzare le cartelle come metodo di raggruppamento dei progetti. I progetti sono la base per la creazione, l'abilitazione e l'utilizzo di tutti i servizi Google Cloud. I progetti consentono di gestire le API, abilitare la fatturazione, aggiungere e rimuovere i collaboratori e gestire le autorizzazioni.

Con Google Identity and Access Management (IAM), puoi assegnare ruoli e definire autorizzazioni e criteri di accesso a tutti i livelli di gerarchia delle risorse. I criteri IAM sono ereditati dalle risorse più in basso nella gerarchia. Questi criteri non possono essere modificati dai proprietari delle risorse di livello inferiore nella gerarchia. In alcuni casi, la gestione di identità e accessi viene fornita a un livello più granulare, ad esempio per l'ambito degli oggetti in uno spazio dei nomi o in un cluster come in Google Kubernetes Engine.

Considerazioni sulla progettazione delle reti Google Virtual Private Cloud

Quando progetti una strategia di migrazione nel cloud, è importante sviluppare una strategia per il modo in cui la tua azienda utilizzerà le reti VPC. Una rete VPC è come una versione virtuale di una rete fisica tradizionale. È una partizione di rete privata e completamente isolata. Per impostazione predefinita, i carichi di lavoro o i servizi di cui viene eseguito il deployment in una rete VPC non possono comunicare con i job in un'altra rete VPC. Le reti VPC consentono quindi l'isolamento del carico di lavoro formando un confine di sicurezza.

Poiché ogni rete VPC nel cloud è completamente virtuale, ognuna ha il proprio spazio di indirizzi IP privati. Pertanto, puoi utilizzare lo stesso indirizzo IP in più reti VPC senza conflitti. Un tipico deployment on-premise potrebbe consumare una grande parte dello spazio di indirizzi IP privati RFC 1918. Se invece hai carichi di lavoro sia on-premise che in reti VPC, puoi riutilizzare gli stessi intervalli di indirizzi in reti VPC diverse, purché queste non siano connesse o in peering, consumando così meno spazio di 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 con una rete VPC possono comunicare tra loro direttamente utilizzando il backbone privato di Google.

Come mostra la figura 1, nel progetto puoi avere una rete VPC contenente subnet in diverse regioni che si estendono su più zone. Le VM in qualsiasi regione possono comunicare privatamente tra loro tramite le route VPC locali.

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

Figura 1. implementazione della rete VPC globale di Google Cloud con subnet configurate in regioni diverse.

Condivisione di una rete utilizzando un VPC condiviso

VPC condiviso consente a una risorsa dell'organizzazione di connettere più progetti a una rete VPC comune in modo che possano comunicare tra loro in modo sicuro utilizzando indirizzi IP interni dalla rete condivisa. Gli amministratori di rete per quella rete condivisa applicano e applicano 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. Le risorse idonee dei progetti di servizio possono utilizzare subnet della rete VPC condiviso.

In genere le aziende utilizzano le reti VPC condiviso quando hanno bisogno che gli amministratori di rete e della sicurezza centralizzano la gestione delle risorse di rete, come subnet e route. Allo stesso tempo, le reti VPC condiviso consentono ai team di sviluppo e applicazioni di creare ed eliminare istanze VM e di eseguire il deployment di carichi di lavoro in subnet designate utilizzando i progetti di servizio.

Isolamento degli ambienti tramite reti VPC

L'utilizzo di reti VPC per isolare gli ambienti presenta diversi vantaggi, ma è necessario considerare anche alcuni svantaggi. Questa sezione affronta questi compromessi e descrive pattern comuni per l'implementazione dell'isolamento.

Motivi per isolare gli ambienti

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

  • Un'azienda vuole stabilire comunicazioni di negazione predefinita tra una rete VPC e un'altra, perché queste reti rappresentano una distinzione significativa a livello organizzativo. Per ulteriori informazioni, consulta Pattern di isolamento di rete VPC comuni più avanti in questo documento.
  • Un'azienda deve avere intervalli di indirizzi IP sovrapposti a causa di ambienti on-premise preesistenti, di acquisizioni o di 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ò presentare alcuni svantaggi. Avere più reti VPC può aumentare il sovraccarico amministrativo della 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 schema consente alle aziende di separare completamente i propri ambienti di sviluppo, gestione temporanea e produzione. In effetti, questa struttura mantiene più copie complete delle applicazioni, con un'implementazione progressiva tra ogni ambiente. In questo pattern, le reti VPC vengono utilizzate come confini di sicurezza. Gli sviluppatori hanno un accesso elevato alle reti VPC di sviluppo per il loro lavoro quotidiano. Al termine dello sviluppo, un team di produzione tecnico o un team di QA può eseguire la migrazione delle modifiche in un ambiente di gestione temporanea, in cui le modifiche possono essere testate in modo integrato. Quando sono pronte per il deployment, le modifiche vengono inviate a un ambiente di produzione.
  • Isolare le unità aziendali. Alcune aziende vogliono imporre un elevato grado di isolamento tra le unità aziendali, soprattutto nel caso di unità acquisite o che richiedono un elevato grado di autonomia e isolamento. In questo schema, le aziende spesso creano una rete VPC per ogni unità aziendale e delegano il controllo di tale VPC agli amministratori dell'unità aziendale. L'azienda utilizza le tecniche descritte più avanti in questo documento per esporre servizi che coprono l'intera 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 tue reti VPC in modo che abbiano il dominio più ampio in linea con i confini amministrativi e di sicurezza della tua azienda. Puoi ottenere un ulteriore isolamento tra i carichi di lavoro eseguiti nella stessa rete VPC utilizzando controlli di sicurezza come i firewall.

Per ulteriori informazioni sulla progettazione e sulla creazione di una strategia di isolamento per la tua organizzazione, consulta Best practice e architetture di riferimento per la progettazione di VPC e Networking nel progetto di base della piattaforma aziendale di Google Cloud.

Componenti di base per il networking cloud

Questa sezione illustra gli importanti componenti di base per la connettività di rete, la sicurezza della rete, il networking dei servizi e la sicurezza dei servizi. La Figura 2 mostra la correlazione esistente tra questi componenti di base. Puoi utilizzare uno o più prodotti elencati in una determinata riga.

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

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

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

Connettività di rete

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

Cloud VPN

Cloud VPN ti consente di connettere le filiali remote o altri cloud provider alle reti VPC Google tramite una connessione VPN IPsec. Il traffico tra le due reti viene criptato da un gateway VPN e poi decriptato dall'altro gateway VPN, contribuendo così a proteggere i dati durante il trasferimento su internet.

Cloud VPN consente di abilitare la connettività tra il tuo ambiente on-premise e Google Cloud senza l'overhead del provisioning delle connessioni incrociate fisiche necessarie per Cloud Interconnect (descritte nella sezione successiva). Puoi eseguire il provisioning di una VPN ad alta disponibilità per soddisfare un requisito dello SLA (accordo sul livello del servizio) con una disponibilità fino al 99,99% se disponi dell'architettura conforme. Puoi valutare l'uso di Cloud VPN se i 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 a Google Cloud una connettività dedicata di livello enterprise che offre una velocità effettiva superiore e prestazioni di rete più affidabili rispetto all'uso della VPN o del traffico internet in entrata. Dedicated Interconnect fornisce connettività fisica diretta alla rete Google dai tuoi router. Partner Interconnect fornisce connettività dedicata tramite un'ampia 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 la connessione a una struttura di colocation in cui Google è presente, al contrario di 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 la rete on-premise o un'altra rete cloud e la rete VPC non attraversi la rete internet pubblica.

Puoi eseguire il provisioning di queste connessioni Cloud Interconnect per soddisfare un requisito dello SLA (accordo sul livello del servizio) con una disponibilità fino al 99,99% se esegui il provisioning dell'architettura appropriata. Puoi utilizzare Cloud Interconnect per supportare carichi di lavoro che richiedono bassa latenza, larghezza di banda elevata e prestazioni prevedibili, garantendo al contempo che tutto il traffico rimanga privato.

Network Connectivity Center per ambienti ibridi

Network Connectivity Center fornisce connettività site-to-site tra le tue reti on-premise e altre reti cloud. Per farlo, utilizza la rete backbone di Google per offrire una connettività affidabile tra i tuoi siti.

Inoltre, puoi estendere la 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, la VPN o la rete Cloud Interconnect come collegamenti 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 il tutto utilizzando un'unica visualizzazione.

Network Connectivity Center per reti VPC

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

Peering di rete VPC

Il peering di rete VPC consente di connettere le reti VPC 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 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 peering non abbiano indirizzi IP sovrapposti.

Sicurezza della rete

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

Regole firewall VPC

Le regole firewall VPC si applicano a una determinata rete. Con le regole firewall VPC puoi 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'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 firewall VPC come esistenti non solo tra le tue istanze e altre reti, ma anche tra singole istanze nella stessa rete.

Criteri firewall gerarchici

I criteri firewall gerarchici ti consentono di creare e applicare criteri firewall coerenti in tutta la tua azienda. Questi criteri contengono regole che possono negare o consentire esplicitamente le connessioni. Puoi assegnare criteri firewall gerarchici alla risorsa dell'organizzazione come tutto o a singole cartelle.

Mirroring pacchetto

Il Mirroring pacchetto clona il traffico di istanze specifiche nella rete VPC e lo 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 che per il traffico in uscita. Il mirroring avviene sulle istanze VM, non sulla rete.

Appliance virtuali di rete

Le appliance virtuali di rete consentono di applicare alla rete virtuale controlli di sicurezza e conformità coerenti con i controlli nell'ambiente on-premise. Puoi farlo eseguendo il deployment delle immagini VM disponibili in Google Cloud Marketplace su VM che hanno più interfacce di rete, ciascuna collegata a una rete VPC diversa, per eseguire una varietà di funzioni virtuali di rete.

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

  • Firewall di nuova generazione (NGFW). I NGFW sono costituiti da un insieme centralizzato di firewall eseguiti come VM che forniscono funzionalità non disponibili nelle regole firewall VPC. Le caratteristiche tipiche dei prodotti NGFW includono l'ispezione profonda dei pacchetti (DPI) e la protezione del firewall a livello di applicazione. Alcuni NGFW forniscono anche un'ispezione del traffico TLS/SSL e altre funzioni di rete, 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 le intrusioni, i dispositivi IPS possono impedire al traffico dannoso di raggiungere la sua destinazione.
  • Gateway web sicuro (SWG). Un SWG blocca le minacce provenienti da internet consentendo alle aziende di applicare criteri aziendali al traffico in viaggio da e verso internet. Ciò avviene tramite filtri degli URL, rilevamento di codice dannoso e controllo dell'accesso.
  • Gateway NAT (Network Address Translation). Un gateway NAT converte gli indirizzi IP e le porte. Ad esempio, questa traduzione aiuta a evitare la sovrapposizione di indirizzi IP. Google Cloud offre Cloud NAT come servizio gestito, ma questo servizio è disponibile solo per il traffico indirizzato a internet, non per quello diretto a reti on-premise o ad altre reti VPC.
  • Web application firewall (WAF). Un WAF è progettato per bloccare il traffico HTTP(S) dannoso diretto a un'applicazione web. Google Cloud offre la funzionalità WAF tramite i criteri di sicurezza di Google Cloud Armor. La funzionalità esatta varia tra i fornitori WAF, quindi è importante determinare cosa ti serve.

Cloud IDS

Cloud IDS è un servizio di rilevamento delle intrusioni che offre il rilevamento delle minacce per intrusioni, malware, spyware e attacchi command-and-control sulla tua rete. Cloud IDS crea una rete in peering gestita da Google contenente VM che riceveranno il traffico sottoposto a mirroring. Il traffico sottoposto a mirroring viene quindi ispezionato 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, permettendoti di monitorare la comunicazione da VM a VM e di rilevare i movimenti laterali.

Cloud NAT

Cloud NAT fornisce un supporto per Network Address Translation software-defined completamente gestito per le applicazioni. Consente Network Address Translation di origine (NAT di origine o SNAT) per il traffico rivolto a internet da VM che non hanno indirizzi IP esterni.

Firewall Insights

Firewall Insights ti aiuta a comprendere e ottimizzare le regole firewall. Fornisce dati su come vengono utilizzate le regole firewall, espone configurazioni errate e identifica le regole che potrebbero essere rese più rigide. Utilizza inoltre il machine learning per prevedere l'uso futuro delle regole firewall in modo da poter prendere decisioni informate sulla rimozione o sull'inasprimento di regole che sembrano eccessivamente permissive.

Logging di rete

Puoi utilizzare più prodotti Google Cloud per registrare e analizzare il traffico di rete.

Il logging delle regole firewall consente di controllare, verificare e analizzare gli effetti delle regole firewall. Ad esempio, puoi determinare se una regola firewall progettata per negare il traffico funziona come previsto. Il logging delle regole firewall è utile anche se 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 o negata) o dalla direzione (in entrata o in uscita) della regola.

Log di flusso VPC registra un campione di flussi di rete inviati e ricevuti dalle istanze VM, incluse le istanze utilizzate come nodi di 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 di servizi di networking sono responsabili della fornitura di servizi di ricerca che indicano ai servizi dove deve essere inviata una richiesta (DNS, Service Directory) e che permettono di inviare le richieste alla posizione corretta (Private Service Connect, Cloud Load Balancing).

Cloud DNS

È possibile accedere 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 che si trovano in qualsiasi parte del mondo. Cloud DNS offre sia zone pubbliche e zone DNS private gestite. Una zona pubblica è visibile sulla rete internet pubblica, mentre una zona privata è visibile solo da una o più reti VPC specificate.

Cloud Load Balancing

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

I nostri bilanciatori del carico consentono inoltre di instradare e scalare il traffico su più cloud o ambienti ibridi. Questo fa di Cloud Load Balancing la porta principale attraverso la quale è possibile scalare qualsiasi applicazione indipendentemente da dove si trovi o da quante posizioni è ospitata. Google offre vari tipi di bilanciamento del carico: globale e a livello di regione, esterno e interno e di livello 4 e 7.

Service Directory

Service Directory consente di gestire l'inventario dei servizi, fornendo un'unica posizione sicura in cui pubblicare, individuare e connettere i servizi, tutte operazioni supportate dal 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. Il rilevamento dei servizi è possibile tramite API HTTP e gRPC esplicite, nonché mediante Cloud DNS.

Mesh di servizi: Anthos Service Mesh e Traffic Director

Sia Anthos Service Mesh che Traffic Director sono progettati per semplificare l'esecuzione di applicazioni complesse e distribuite, abilitando un ricco set di criteri di gestione del traffico e di sicurezza nelle architetture di mesh di servizi. Le differenze principali tra questi prodotti sono negli ambienti supportati, nelle API Istio e nelle capacità di bilanciamento del carico globali.

Anthos Service Mesh è ideale per i deployment a livello di regione e globale basati su Kubernetes, sia Google Cloud che on-premise, che beneficiano di un prodotto Istio gestito.

Traffic Director è ideale per i casi d'uso del networking che presentano servizi di cui è stato eseguito il deployment a livello globale per l'integrità e il carico su Google Cloud. Traffic Director gestisce i carichi di lavoro utilizzando proxy Envoy che fungono da sidecar o gateway oppure utilizzando carichi di lavoro gRPC senza proxy.

La seguente tabella riassume le funzionalità di Traffic Directory e Anthos 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 Regione regionale e federata Globale
Piattaforma API Istio Routing del servizio (modello gateway Kubernetes)
Connettività di rete Sidecar Envoy Sidecar Envoy, gRPC senza proxy
Distribuzione del carico globale basata sull'integrità del backend Sì (in base a Kubernetes) Sì
Distribuzione del carico globale in base al carico di backend No Sì
Identità gestita per mTLS del carico di lavoro (Zero Trust) Sì Sì (solo GKE)

Google ha ulteriormente approfondito come creare un ambiente con architettura Zero Trust end-to-end utilizzando l'architettura BeyondProd. Oltre all'autenticazione e all'autorizzazione dei servizi e del perimetro di rete, BeyondProd descrive in dettaglio il modo in cui gli ambienti di computing, la provenienza del codice e le implementazioni dei deployment affidabili svolgono un ruolo nel raggiungere un'architettura di servizio Zero Trust sicura e distribuita. Quando adotti un approccio Zero Trust, devi prendere in considerazione questi problemi che vanno oltre il networking.

Private Service Connect

Private Service Connect crea astrazioni di servizi rendendo i carichi di lavoro accessibili nelle reti VPC tramite un singolo endpoint. Ciò consente a due reti di comunicare in un modello client-server che espone solo il servizio al consumer, anziché l'intera rete o il 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 piuttosto che tra subnet o VPC, consentendo il consumo dei servizi in un modello producer-consumer, sia per servizi proprietari o di terze parti (SaaS).

Con Private Service Connect, un VPC consumer può utilizzare un indirizzo IP privato per connettersi a un'API di Google o a un servizio in un altro VPC.

Puoi estendere Private Service Connect alla tua 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 al livello 4 o al 7.

Al livello 4, Private Service Connect richiede al producer di creare una o più subnet specifiche di Private Service Connect. dette anche subnet NAT. Private Service Connect esegue la traduzione 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 consente di utilizzare indirizzi IP sovrapposti tra consumatori e producer.

Al livello 7, puoi creare un backend Private Service Connect utilizzando un bilanciatore del carico delle applicazioni interno. Il bilanciatore del carico delle applicazioni interno consente di scegliere quali servizi sono disponibili utilizzando una mappa URL. Per maggiori informazioni, consulta Informazioni sui backend Private Service Connect.

Accesso privato ai servizi

L'accesso privato ai servizi è una connessione privata tra la tua rete VPC e una rete di proprietà di Google o di una terza parte. Google o le terze parti che offrono servizi sono noti come produttori di servizi. L'accesso privato ai servizi utilizza il peering di rete VPC per stabilire la connettività e richiede che le reti VPC producer e consumer siano connesse in peering tra loro. È diverso da Private Service Connect, che consente di proiettare un singolo indirizzo IP privato nella subnet.

La connessione privata consente alle istanze VM nella rete VPC e ai servizi a cui accedi di comunicare esclusivamente tramite indirizzi IP interni. Le istanze VM non hanno bisogno dell'accesso a internet o di indirizzi IP esterni per raggiungere i servizi disponibili tramite l'accesso privato ai servizi. L'accesso privato ai servizi può anche essere esteso alla rete on-premise utilizzando Cloud VPN o Cloud Interconnect per fornire agli host on-premise di raggiungere la rete del producer di servizi. Per un elenco dei servizi gestiti da Google supportati utilizzando l'accesso privato ai servizi, consulta Servizi supportati nella documentazione di Virtual Private Cloud.

Accesso VPC serverless

L'accesso VPC serverless ti consente di connetterti direttamente alla tua rete VPC da servizi ospitati in ambienti serverless come Cloud Run, App Engine o Cloud Functions. La configurazione dell'accesso VPC serverless consente all'ambiente serverless di inviare richieste alla tua rete VPC utilizzando indirizzi IP interni e DNS interni. 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 questo traffico è una risposta a una richiesta inviata dall'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 a internet.
  • La comunicazione tramite accesso VPC serverless può avere meno latenza 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 a una comprensione più approfondita dei pattern dei pacchetti, invece che solo sulle caratteristiche di un singolo pacchetto.

Google Cloud Armor per DDoS/WAF

Google Cloud Armor è un servizio WAF (web application firewall) e di mitigazione DDoS (Distributed Denial-of-Service) che ti consente di difendere applicazioni e servizi web da diversi tipi di minacce. Queste minacce includono attacchi DDoS, attacchi basati sul web come cross-site scripting (XSS) e SQL injection (SQLi) e attacchi basati su attività fraudolente e automazione.

Google Cloud Armor controlla le richieste in arrivo sul perimetro globale di Google. Dispone di un set integrato di regole web application firewall per la scansione degli attacchi web comuni e di un sistema di rilevamento degli attacchi basato su ML avanzato che crea un modello di traffico efficace, poi rileva il traffico non valido. Infine, Google Cloud Armor si integra con Google reCAPTCHA per aiutare a rilevare e bloccare sofisticate attività fraudolente e attacchi basati su automazione utilizzando la telemetria degli endpoint e la telemetria cloud.

Identity-Aware Proxy (IAP)

Identity-Aware Proxy (IAP) offre controlli dell'accesso sensibili al contesto alle applicazioni basate su cloud e alle VM in esecuzione su Google Cloud o che sono connesse a Google Cloud utilizzando una qualsiasi delle tecnologie di networking ibrido. IAP verifica l'identità dell'utente e determina se la richiesta dell'utente proviene da fonti attendibili, in base a vari attributi contestuali. IAP supporta inoltre il tunneling TCP per l'accesso SSH/RDP da parte degli utenti aziendali.

Controlli di servizio VPC

Controlli di servizio VPC aiuta a ridurre il rischio di esfiltrazione di dati dai servizi Google Cloud come Cloud Storage e BigQuery. L'utilizzo di Controlli di servizio VPC assicura che l'utilizzo dei servizi Google Cloud avvenga solo da ambienti approvati.

Puoi utilizzare Controlli di servizio VPC per creare perimetri che proteggono le risorse e i dati dei servizi da te specificati limitando l'accesso a specifici costrutti di identità cloud-native come gli account di servizio e le reti VPC. Dopo la creazione di 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 un'accelerazione dei contenuti statici utilizzando la rete perimetrale globale di Google per fornire contenuti dal punto più vicino all'utente. Ciò consente di ridurre la latenza dei tuoi siti web e delle tue applicazioni.

Media CDN

Media CDN è la soluzione di pubblicazione di contenuti multimediali di Google ed è progettata per carichi di lavoro in uscita ad alta velocità effettiva.

Osservabilità

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

Network Intelligence Center

Network Intelligence Center è costituito da diversi prodotti che rispondono a vari aspetti dell'osservabilità della rete. Ogni prodotto ha un obiettivo diverso e fornisce insight avanzati per informare amministratori, architetti e professionisti sullo stato e sui problemi della rete.

Architetture di riferimento

I seguenti documenti presentano architetture di riferimento per diversi tipi di carichi di lavoro: intra-cloud, per internet e ibridi. Queste architetture dei carichi di lavoro sono costruite su un piano dati cloud realizzato utilizzando i componenti di base e i pattern architetturali delineati nelle 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 carichi di lavoro sono quindi supportati dal piano dati cloud e utilizzano le architetture. Sebbene questi documenti non forniscano un set completo di architetture di riferimento, coprono gli scenari più comuni.

Come per i pattern di architettura di sicurezza descritti in Architetture per la protezione di piani dati cloud, i servizi reali potrebbero utilizzare una combinazione di questi progetti. Questi documenti esaminano ogni tipo di carico di lavoro e le considerazioni relative a ciascuna architettura di sicurezza.

Passaggi successivi