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

Last reviewed 2025-01-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 evidenza la connettività avanzata, i principi di sicurezza Zero Trust e la 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 pattern distinti: lift-and-shift, servizi ibridi e distribuiti zero-trust. Il documento attuale prende in considerazione diversi approcci di sicurezza, a seconda dell'architettura scelta da un'azienda. Inoltre, descrive come realizzare questi approcci utilizzando i componenti di base forniti daGoogle Cloud. Ti consigliamo di utilizzare queste indicazioni sulla sicurezza in combinazione con altre indicazioni sull'architettura 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. Si presume 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 e hai familiarità con le relative funzionalità e con gli utenti.
  • Hai almeno alcuni workload 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 principali pattern di architettura e introduce i componenti di base delle risorse che puoi utilizzare per creare la tua infrastruttura. Infine, descrive come assemblare gli elementi di base in una serie di architetture di riferimento che corrispondono ai pattern. Puoi utilizzare queste architetture di riferimento per creare la tua architettura.

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

Panoramica dei pattern di architettura

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 modificato questo approccio perché i costrutti di reti cloud sono definiti dal software. 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, prendiamo in considerazione tre pattern di architettura comuni. Questi modelli si basano l'uno sull'altro e possono essere considerati come uno spettro piuttosto che una scelta rigida.

Modello di migrazione 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. Gli esperti di rete e sicurezza utilizzano i controlli di Livello 3 e Livello 4 per fornire protezione utilizzando una combinazione di appliance virtuali di rete che simulano i dispositivi fisici on-premise e le regole firewall cloud nella rete VPC. I proprietari di workload eseguono il deployment dei propri servizi nelle reti VPC.

Pattern 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 questi servizi cloud avviene a livello 4 e 7. In questo contesto, l'isolamento e la sicurezza non possono essere eseguiti esclusivamente a 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 di controllo degli accessi avanzati.

Pattern distribuito Zero Trust

In un'architettura Zero Trust, le applicazioni aziendali estendono l'applicazione della sicurezza oltre i controlli di perimetro. 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. In questo modo, i servizi possono convalidare i chiamanti e prendere decisioni in base ai criteri per ogni richiesta in merito all'accettabilità dell'accesso. Questa architettura viene spesso implementata utilizzando proxy distribuiti (un mesh di servizi) anziché gateway centralizzati.

Le aziende possono applicare l'accesso Zero Trust da utenti e dispositivi alle applicazioni aziendali 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 stanno creando o eseguendo la migrazione delle loro applicazioni aziendali sul cloud in genere utilizzano una combinazione di tutti e tre i pattern di architettura.

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 sono descritti 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 consente di governare, 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 forniti daGoogle Cloud come contenitori di risorse. I controlli includono Google Cloud risorse dell'organizzazione, cartelle e progetti che ti consentono di gruppare e organizzare in modo gerarchico le 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 dell'organizzazione può avere cartelle e progetti come elementi figlio. Una cartella ha progetti o altre cartelle come elementi secondari. Tutte le altre risorse cloud sono elementi figlio dei progetti.

Utilizza le cartelle come metodo per raggruppare i progetti. I progetti sono la base per creare, abilitare e utilizzare tutti i Google Cloud servizi. 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 dell'identità e dell'accesso viene fornita a un livello più granulare, ad esempio nell'ambito degli oggetti in un ambito o in un cluster, come in Google Kubernetes Engine.

Considerazioni di progettazione per le 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 considerare una rete VPC come una versione virtuale della tua tradizione rete fisica. Si tratta di una partizione di rete privata completamente isolata. 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 consentono quindi di eseguire l'isolamento dei carichi di lavoro formando un confine di sicurezza.

Poiché ogni rete VPC nel cloud è una rete completamente virtuale, ciascuna ha 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 un progetto che dispone di una rete VPC possono dialogare tra loro direttamente 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 in qualsiasi regione possono comunicare privatamente tra loro utilizzando i route VPC locali.

Implementazione della rete VPC globaleGoogle Cloud con subnet configurate in regioni diverse.

Figura 1. Google Cloud Implementazione di una rete VPC globale con subnet configurate in regioni diverse.

Condividere una rete utilizzando VPC condiviso

La VPC condivisa 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 della 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 e lo colleghi a 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 condivisa.

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 applicazioni e di sviluppo di creare ed eliminare istanze VM e di eseguire il deployment dei carichi di lavoro in subnet designate utilizzando i progetti di servizio.

Isolare gli ambienti utilizzando le reti VPC

L'utilizzo delle reti VPC per isolare gli ambienti presenta una serie di vantaggi, ma devi 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 con rifiuto predefinito tra una rete VPC e un'altra, perché queste reti rappresentano una distinzione significativa per l'organizzazione. 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ò avere alcuni svantaggi. La presenza di più reti VPC può aumentare il costo amministrativo della gestione dei servizi che si estendono 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:

  • Isola 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 ogni ambiente. In questo pattern, le reti VPC vengono utilizzate come confini di sicurezza. Gli sviluppatori hanno un elevato grado di accesso alle reti VPC di sviluppo per svolgere il proprio lavoro quotidiano. Al termine dello sviluppo, un team di produzione tecnico o un team di QA può eseguire la migrazione delle modifiche a un ambiente di staging, dove possono essere testate in modo integrato. Quando le modifiche sono pronte per essere implementate, vengono inviate a un ambiente di produzione.
  • Isolare le unità aziendali. Alcune aziende vogliono imporre un elevato grado di isolamento tra le unità aziendali, in particolare nel caso di unità acquisite o che richiedono un elevato grado di autonomia e isolamento. In questo modello, le aziende spesso creano una rete VPC per ogni unità aziendale e delegan il controllo della VPC agli amministratori dell'unità aziendale. 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 che abbiano il dominio più ampio in linea con i 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 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 Google Cloud blueprint Enterprise Foundations.

Componenti di base per il networking cloud

Questa sezione illustra gli elementi fondamentali per la connettività di rete, la sicurezza di rete, la rete di servizi e la sicurezza dei servizi. La Figura 2 mostra la relazione tra questi componenti di base. 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à e della sicurezza delle reti cloud.

Le sezioni seguenti illustrano ciascuno dei componenti di base e iGoogle Cloud servizi che puoi utilizzare per ciascuno di essi.

Connettività di rete

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

Cloud VPN

Cloud VPN ti consente di collegare le sedi distaccate remote o altri provider cloud alle reti VPC di Google Cloud tramite connessioni 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 collegare il tuo ambiente on-premise Google Cloud a un costo inferiore, ma con una larghezza di banda inferiore rispetto a Cloud Interconnect (descritto nella sezione successiva). Se disponi di un'architettura conforme, puoi eseguire il provisioning di una VPN ad alta disponibilità per soddisfare un requisito dello SLA fino al 99,99% di disponibilità. Ad esempio, Cloud VPN è una buona scelta per i casi d'uso non mission-critical o per estendere la connettività ad altri cloud provider.

Cloud Interconnect

Cloud Interconnect offre connettività dedicata di livello enterprise a Google Cloud che ha una velocità effettiva superiore e prestazioni di rete più affidabili rispetto all'utilizzo di VPN o ingresso 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. 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 SLA di disponibilità fino al 99,99% se esegui il provisioning dell'architettura appropriata. Puoi prevedere l'utilizzo di Cloud Interconnect per supportare i workload che richiedono bassa latenza, larghezza di banda elevata e prestazioni prevedibili, garantendo al contempo che tutto il tuo traffico rimanga privato.

Network Connectivity Center per ibride

Network Connectivity Center fornisce connettività site-to-site tra le reti on-premise e altre reti cloud. A tale scopo, utilizza la rete di backbone di Google per fornire una connettività affidabile 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, la rete VPN o la rete 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 gestirli tutti con una singola visualizzazione.Google Cloud

Network Connectivity Center per le reti VPC

Network Connectivity Center ti consente anche di creare una topologia a maglia o a stella tra molte reti VPC utilizzando spoke VPC. Puoi connettere l'hub a cloud on-premise o di altri cloud utilizzando spoke ibride di Network Connectivity Center.

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 mettere in peering non abbiano indirizzi IP sovrapposti.

Sicurezza della rete

Il blocco Sicurezza della rete si trova sopra il blocco Connettività di rete. È responsabile dell'autorizzazione o del rifiuto dell'accesso alle risorse in base alle caratteristiche dei pacchetti IP.

Cloud NGFW

Cloud Next Generation Firewall (Cloud NGFW) è un servizio firewall distribuito che consente di applicare criteri firewall a livello di organizzazione, cartella e rete. Le regole firewall abilitate vengono sempre applicate, proteggendo le istanze a prescindere dalla configurazione o dal sistema operativo o anche dal fatto che le VM siano state avviate completamente. Le regole vengono applicate su base per istanza, il che significa che proteggono le connessioni tra le VM all'interno di una determinata rete, nonché le connessioni all'esterno della rete. L'applicazione delle regole può essere regolata utilizzando i tag gestiti da IAM, che ti consentono di controllare le VM coperte da regole specifiche. Cloud NGFW offre anche la possibilità di eseguire l'ispezione L7 dei pacchetti.

Mirroring pacchetto

Il mirroring dei pacchetti clona il traffico di istanze specifiche nella rete VPC e lo inoltra ai collettori 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 ti consentono di applicare alla rete virtuale controlli di sicurezza e conformità coerenti con quelli dell'ambiente on-premise. Per farlo, puoi implementare le immagini VM disponibili nel marketplace Google Cloud in VM con più interfacce di rete, ciascuna collegata a una rete VPC diversa, per eseguire una serie di funzioni virtuali di rete.

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

  • Firewall di nuova generazione (NGFW). Le NVA NGFW offrono protezione in situazioni non coperte da Cloud NGFW o per garantire la consistenza della gestione con le installazioni NGFW on-premise.
  • Sistema di rilevamento delle intrusioni/sistema di prevenzione delle intrusioni (IDS/IPS). Un IDS basato su rete fornisce visibilità sul traffico potenzialmente dannoso. Per impedire le intrusioni, i dispositivi IPS possono bloccare il traffico dannoso dal raggiungere la destinazione. Google Cloud offre Cloud IDS (Cloud Intrusion Detection System) come servizio gestito.
  • Gateway web sicuro (SWG). Un SWG blocca le minacce provenienti da internet consentendo alle aziende di applicare i criteri aziendali al traffico in entrata e in uscita da internet. Ciò avviene utilizzando il filtro degli URL, il rilevamento di codice dannoso e il controllo dell'accesso. Google Cloud offre Secure Web Proxy come servizio gestito.
  • Gateway Network Address Translation (NAT). 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.
  • Web Application Firewall (WAF). Un WAF è progettato per bloccare il traffico HTTP(S) dannoso in entrata a un'applicazione web. Google Cloud offre la funzionalità WAF tramite i criteri di sicurezza di Google Cloud Armor. La funzionalità esatta varia in base al fornitore di WAF, quindi è importante determinare le tue esigenze.

Cloud IDS

Cloud IDS è un servizio di rilevamento delle intrusioni che offre il rilevamento delle minacce come 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 all'interno della sottorete, consentendoti di monitorare le comunicazioni da VM a VM e di rilevare il movimento laterale.

Cloud NAT

Cloud NAT fornisce supporto per la traduzione degli indirizzi di rete completamente gestito e software-defined per le applicazioni. Consente la Network Address Translation dell'origine (NAT di origine o SNAT) per il traffico in uscita su internet 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 del firewall, espone configurazioni errate e identifica le regole che potrebbero essere più severe. 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ù Google Cloud prodotti per registrare e analizzare il traffico di rete.

Il logging delle regole del firewall consente di controllare, verificare e analizzare gli effetti delle regole del 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.

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 o 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 di Service Networking sono responsabili della fornitura di servizi di ricerca che indicano ai servizi dove deve essere indirizzata una richiesta (DNS, Service Directory) e di inoltrarla al luogo corretto (Private Service Connect, Cloud Load Balancing).

Cloud DNS

Per accedere ai carichi di lavoro vengono utilizzati i nomi di dominio. Cloud DNS offre una traduzione affidabile e a bassa latenza dei nomi di dominio in indirizzi IP situati in qualsiasi parte del mondo. Cloud DNS offre sia zone pubbliche sia zone DNS gestite private. Una zona pubblica è visibile all'internet pubblico, mentre una zona privata è visibile solo da una o più reti VPC specificate.

Cloud Load Balancing

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

I nostri bilanciatori del carico consentono inoltre di instradare e scalare il traffico su più cloud o ambienti ibridi. Questo rende Cloud Load Balancing la "porta d'ingresso" tramite la quale qualsiasi applicazione può essere scalata indipendentemente da dove si trova o da quanti luoghi è ospitata. 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à. Ti consente di registrare servizi denominati e i relativi endpoint. La registrazione può essere manuale o tramite le integrazioni con Private Service Connect, GKE e Cloud Load Balancing. Il discovery dei servizi è possibile utilizzando API HTTP e gRPC esplicite, nonché Cloud DNS.

Cloud Service Mesh

Entrambi Cloud Service Mesh sono progettati per eseguire applicazioni complesse e distribuite attivando un insieme completo di criteri di gestione del traffico e di sicurezza nelle architetture di mesh di servizi.

Cloud Service Mesh supporta i deployment regionali e globali basati su Kubernetes, sia Google Cloud on-premise sia in cloud, che beneficiano di un prodotto Istio gestito. Supporta inoltre Google Cloud l'utilizzo di proxy su VM o gRPC senza proxy.

Private Service Connect

Private Service Connect crea astrazioni dei servizi rendendo accessibili i carichi di lavoro sulle reti VPC tramite un unico endpoint. In questo modo, due reti possono comunicare in un modello client-server che espone al consumatore solo il servizio 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 anziché tra le subnet o le VPC, consentendo l'utilizzo dei servizi in un modello di produzione e consumo, sia per i servizi di proprietà sia per quelli di terze parti (SaaS).

Con Private Service Connect, una VPC consumer può utilizzare un indirizzo IP privato per connettersi a un'API Google o a un servizio in un'altra 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 di utilizzare i 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 quali servizi sono disponibili utilizzando una mappa URL. Per ulteriori informazioni, consulta Informazioni sui backend di 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 terze parti. Google o le terze parti che offrono servizi sono chiamate 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 collegate 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 mediante 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. L'accesso ai servizi privati può essere anche esteso alla rete on-premise utilizzando Cloud VPN o Cloud Interconnect per consentire agli host on-premise di raggiungere la rete del produttore 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

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 funzioni Cloud Run. La configurazione dell'accesso VPC serverless consente all'ambiente serverless di inviare richieste alla rete VPC utilizzando DNS interni e indirizzi IP interni. Anche le risposte a queste richieste utilizzano 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 a internet.
  • La comunicazione tramite l'accesso VPC serverless può avere una latenza inferiore rispetto alla comunicazione tramite internet.

VPC diretto in uscita

Il traffico VPC diretto in uscita consente al servizio Cloud Run di inviare traffico a una rete VPC senza configurare un connettore di accesso VPC serverless.

Sicurezza del servizio

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 servizio WAF (web application firewall) e di mitigazione degli attacchi DDoS (distributed denial-of-service) che ti aiuta a difendere le tue applicazioni e i tuoi servizi web da diversi tipi di minacce. Queste minacce includono attacchi DDoS, attacchi web come cross-site scripting (XSS) e SQL injection (SQLi), nonché frodi e attacchi basati sull'automazione.

Google Cloud Armor ispeziona le richieste in arrivo sul perimetro globale di Google. Ha 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 di Google per contribuire a rilevare e bloccare sofisticate frodi e attacchi basati sull'automazione utilizzando sia la telemetria dell'endpoint sia la telemetria del cloud.

Identity-Aware Proxy (IAP)

Identity-Aware Proxy (IAP) fornisce controlli di accesso sensibili al contesto per le applicazioni e le VM basate su cloud in esecuzione su Google Cloud o collegate a Google Cloud utilizzando una delle tecnologie di networking ibride. IAP verifica l'identità dell'utente e determina se la richiesta dell'utente proviene da origini 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 ti aiutano a ridurre il rischio di esfiltrazione di dati da Google Cloud servizi come Cloud Storage e BigQuery. L'utilizzo dei Controlli di servizio VPC contribuisce ad assicurare che l'uso dei tuoi Google Cloud servizi avvenga solo da ambienti approvati.

Puoi utilizzare i Controlli di servizio VPC per creare perimetri che proteggono le risorse e i dati dei servizi che specifichi limitando l'accesso a specifici costrutti di identità cloud-native come gli account di servizio e le reti VPC. 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 offre l'accelerazione dei contenuti statici utilizzando la rete perimetrale globale di Google per distribuire i contenuti da un 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 ha un focus diverso e fornisce informazioni dettagliate per 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. Queste architetture dei carichi di lavoro sono basate su un piano dati cloud realizzato utilizzando gli elementi costitutivi e i pattern di architettura descritti 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 tuoi carichi di lavoro sono quindi supportati dal piano dati cloud e utilizzano le architetture. Sebbene questi documenti non forniscano un insieme esaustivo di architetture di riferimento, coprono gli scenari più comuni.

Come per i pattern di architettura di sicurezza descritti in Architectures for Protecting Cloud Data Planes, i servizi reali 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