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 rete e sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro del data center suGoogle Cloud. Queste architetture enfatizzano la connettività avanzata, i principi di sicurezza Zero Trust e la gestibilità in un ambiente ibrido.

Come descritto in un documento di accompagnamento, Architetture per la protezione dei piani di dati cloud, le aziende implementano una 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 zero-trust distribuito. Il documento attuale prende in considerazione diversi approcci alla sicurezza, a seconda dell'architettura scelta da un'azienda. Descrive inoltre come realizzare questi approcci utilizzando i componenti di base forniti da Google Cloud. Devi utilizzare queste indicazioni sulla sicurezza insieme ad altre indicazioni sull'architettura che riguardano affidabilità, disponibilità, scalabilità, prestazioni e governance.

Questo documento è progettato per aiutare gli architetti di sistemi, gli amministratori di rete e gli amministratori della sicurezza che stanno pianificando la migrazione dei carichi di lavoro on-premise al 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 sai cosa fanno e chi sono i loro 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 è costituita dai seguenti documenti:

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

Questo documento menziona le macchine virtuali (VM) come esempi di risorse del workload. 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 architetturali

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

Il percorso verso il cloud ha modificato questo approccio perché i costrutti di rete cloud sono definiti dal software. Nel cloud, i proprietari delle applicazioni hanno un controllo limitato dello stack dell'infrastruttura sottostante. Hanno bisogno di un modello con un perimetro sicuro e che fornisca l'isolamento per i loro carichi di lavoro.

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

Pattern lift and shift

Nel pattern architetturale lift-and-shift, i proprietari delle applicazioni aziendali eseguono la migrazione dei carichi di lavoro al cloud senza il refactoring. Gli ingegneri 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 imitano i dispositivi fisici on-premise e le regole firewall cloud nella rete VPC. I proprietari dei workload eseguono il deployment dei propri servizi nelle reti VPC.

Pattern di servizi ibridi

I carichi di lavoro creati utilizzando il metodo 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 livello 7. In questo contesto, l'isolamento e la sicurezza non possono essere eseguiti rigorosamente a livello 3. Pertanto, il service networking e i 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 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 viene negata per impostazione predefinita. In un'architettura distribuita Zero Trust, l'affidabilità si basa sull'identità ed è applicata a 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 sulle norme per ogni richiesta in merito all'accettabilità dell'accesso. Questa architettura viene spesso implementata utilizzando proxy distribuiti (una 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 su identità e contesto per il traffico degli utenti da internet o intranet.

Combinare pattern

Le aziende che creano o migrano le proprie applicazioni aziendali nel cloud di solito 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 che alimenta i pattern architetturali. Questi componenti di base vengono trattati 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 utilizzare i tuoi carichi di lavoro nel cloud.

Gerarchia delle risorse e controlli amministrativi

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

Una risorsa 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 ha progetti o altre cartelle come elementi figlio. 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.

Utilizzando Google Identity and Access Management (IAM), 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 ai livelli inferiori della gerarchia. Queste norme non possono essere modificate dai proprietari delle risorse che si trovano a un livello inferiore della 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 uno spazio dei nomi o in un cluster come in Google Kubernetes Engine.

Considerazioni sulla progettazione per le reti Virtual Private Cloud di Google

Quando progetti una strategia di migrazione al cloud, è importante sviluppare una strategia per l'utilizzo delle reti VPC da parte della tua azienda. Una rete VPC è una versione virtuale della tua rete fisica tradizionale. 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 in un'altra rete VPC. Pertanto, le reti VPC consentono l'isolamento dei carichi di lavoro formando un confine di sicurezza.

Poiché ogni rete VPC nel cloud è una rete 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'implementazione on-premise tipica potrebbe consumare una parte significativa dello spazio di indirizzi IP privati RFC 1918. D'altra parte, se hai carichi di lavoro sia on-premise sia nelle reti VPC, puoi riutilizzare gli stessi intervalli di indirizzi in reti VPC diverse, a condizione che queste reti non siano connesse o in peering, in modo da utilizzare 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 ha una rete VPC possono comunicare tra loro direttamente utilizzando il backbone privato di Google.

Come mostrato nella figura 1, puoi avere una rete VPC nel tuo progetto che contiene subnet in diverse regioni che si estendono su più zone. Le VM in qualsiasi regione possono comunicare privatamente tra loro utilizzando le route VPC locali.

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

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

Condivisione di una rete utilizzando il VPC condiviso

VPC condiviso consente a una risorsa 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 per quella rete condivisa applicano e impongono il controllo centralizzato sulle risorse di rete.

Quando utilizzi un VPC condiviso, designi un progetto come progetto host e 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.

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

Motivi per isolare gli ambienti

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

  • Un'azienda vuole stabilire comunicazioni di tipo default-deny tra una rete VPC e un'altra, perché queste reti rappresentano una distinzione significativa a livello organizzativo. Per saperne di più, consulta Pattern 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 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. La presenza di più reti VPC può aumentare i costi amministrativi di gestione dei servizi che si estendono su più reti. Questo documento illustra le tecniche che puoi utilizzare per gestire questa complessità.

Pattern comuni di isolamento della rete VPC

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, gestione temporanea e produzione. In effetti, questa struttura mantiene più copie complete delle applicazioni, con un'implementazione progressiva tra un ambiente e l'altro. In questo pattern, le reti VPC vengono utilizzate come confini di sicurezza. Gli sviluppatori hanno un elevato livello di accesso alle reti VPC di sviluppo per svolgere il proprio lavoro quotidiano. Al termine dello sviluppo, un team di produzione di ingegneria o un team di controllo qualità può eseguire la migrazione delle modifiche a un ambiente di staging, 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 elevato grado di isolamento tra le unità aziendali, soprattutto nel caso di unità acquisite o di quelle che richiedono un elevato grado di autonomia e isolamento. In questo pattern, le aziende spesso creano una rete VPC per ogni unità aziendale e delegano il controllo di questo VPC agli amministratori dell'unità aziendale. L'azienda utilizza tecniche descritte più avanti in questo documento per esporre servizi che interessano l'azienda o per ospitare applicazioni rivolte agli utenti che interessano più unità aziendali.

Consiglio 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 limiti amministrativi e di sicurezza della tua azienda. Puoi ottenere un isolamento aggiuntivo tra i carichi di lavoro eseguiti nella stessa rete VPC utilizzando controlli di sicurezza come i firewall.

Per saperne di più sulla progettazione e la 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 per le aziende Google Cloud .

Componenti di base per il networking cloud

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

Elementi costitutivi nel campo della connettività e della sicurezza di rete cloud.

Figura 2. Elementi costitutivi nel campo della connettività di rete cloud e della sicurezza.

Le sezioni seguenti descrivono ciascuno dei blocchi costitutivi e i serviziGoogle Cloud che puoi utilizzare per ciascuno di essi.

Connettività di rete

Il blocco di connettività di rete si trova alla base della 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 oppure potresti utilizzarli tutti per gestire diversi casi d'uso.

Cloud VPN

Cloud VPN ti consente di connettere le tue filiali remote o altri cloud provider alle reti VPC di Google tramite connessioni 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 transito su internet.

Cloud VPN ti consente di connettere il tuo ambiente on-premise e Google Cloud a un costo inferiore, ma con una larghezza di banda inferiore rispetto a Cloud Interconnect (descritto nella sezione successiva). Puoi eseguire il provisioning di una VPN ad alta disponibilità per soddisfare un requisito SLA con disponibilità fino al 99,99% se disponi dell'architettura conforme. 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 fornisce connettività dedicata di livello aziendale a Google Cloud che offre velocità effettiva superiore e prestazioni di rete più affidabili rispetto all'utilizzo di VPN o dell'ingresso a internet. Dedicated Interconnect fornisce connettività fisica diretta alla rete 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 la connessione a una struttura di colocation in cui Google è presente, mentre Partner Interconnect non lo richiede. Cloud Interconnect garantisce che il traffico tra la tua rete on-premise o un'altra rete cloud e la tua rete VPC non attraversi la rete internet pubblica.

Puoi eseguire il provisioning di queste connessioni Cloud Interconnect per soddisfare un requisito SLA con disponibilità fino al 99,99% se esegui il provisioning dell'architettura appropriata. Puoi prendere in considerazione l'utilizzo di Cloud Interconnect per supportare i 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 l'ibrido

Network Connectivity Center fornisce connettività da sito a sito tra le tue reti on-premise e altre reti cloud. A questo scopo, utilizza la rete 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 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 tutto utilizzando una singola visualizzazione.

Network Connectivity Center per le reti VPC

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

Peering di rete VPC

Il peering di rete VPC 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 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 di cui viene eseguito il peering non abbiano indirizzi IP sovrapposti.

Sicurezza della rete

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

Cloud NGFW

Cloud Next Generation Firewall (Cloud NGFW) è un servizio firewall distribuito che ti 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, dal sistema operativo o dal fatto che le VM siano state avviate completamente. Le regole vengono applicate 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 controllata utilizzando i tag gestiti da IAM, che ti consentono di controllare quali VM sono 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 tua 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 per il traffico in entrata e in uscita, solo per il traffico in entrata o solo per il traffico in uscita. Il mirroring viene eseguito sulle istanze VM, non sulla rete.

Appliance virtuale di rete

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

I casi d'uso tipici per le appliance virtuali sono i seguenti:

  • Firewall di nuova generazione (NGFW). Le NVA NGFW offrono protezione in situazioni non coperte da Cloud NGFW o per fornire coerenza di gestione con le installazioni NGFW on-premise.
  • Sistema di rilevamento delle intrusioni/sistema di prevenzione delle intrusioni (IDS/IPS). Un IDS basato sulla rete offre visibilità sul traffico potenzialmente dannoso. Per impedire le intrusioni, i dispositivi IPS possono bloccare il traffico dannoso prima che raggiunga la destinazione. Google Cloud offre Cloud Intrusion Detection System (Cloud IDS) come servizio gestito.
  • Gateway web sicuro (SWG). Un gateway web sicuro blocca le minacce provenienti da internet consentendo alle aziende di applicare criteri aziendali al traffico che viaggia verso e da internet. Ciò avviene tramite il filtraggio 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 aiuta a evitare indirizzi IP sovrapposti. Google Cloud offre Cloud NAT come servizio gestito.
  • Web Application Firewall (WAF). Un WAF è progettato per bloccare il traffico HTTP(S) dannoso diretto a un'applicazione web. Google Cloud offre funzionalità WAF tramite i criteri di sicurezza di Google Cloud Armor. La funzionalità esatta varia a seconda dei fornitori di WAF, quindi è importante determinare ciò di cui hai bisogno.

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 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 all'interno della subnet, consentendoti di monitorare la comunicazione da VM a VM e di rilevare il movimento laterale.

Cloud NAT

Cloud NAT fornisce supporto per Network Address Translation completamente gestito e software-defined per le applicazioni. Consente la Network Address Translation dell'origine (source NAT o SNAT) per il traffico esposto a internet dalle 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 configurazioni errate e identifica le regole che potrebbero essere più severe. Utilizza inoltre il machine learning per prevedere l'utilizzo futuro delle regole firewall, in modo da poter prendere decisioni informate in merito alla rimozione o al rafforzamento delle regole che sembrano eccessivamente permissive.

Registrazione dei log di rete

Puoi utilizzare più Google Cloud prodotti 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.

Attiva il logging delle regole firewall singolarmente per ogni regola firewall le cui connessioni devi registrare. 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 da istanze VM, incluse le istanze 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 andare una richiesta (DNS, Service Directory) e di indirizzare le richieste nella posizione corretta (Private Service Connect, Cloud Load Balancing).

Cloud DNS

Ai carichi di lavoro si accede utilizzando i nomi di dominio. Cloud DNS offre una conversione affidabile e a bassa latenza dei nomi di dominio in indirizzi IP che si trovano in qualsiasi parte del mondo. Cloud DNS offre zone pubbliche e zone DNS gestite private. Una zona pubblica è visibile su internet, mentre una zona privata è visibile solo da una o più reti VPC che specifichi.

Cloud Load Balancing

All'interno di Google Cloud, i bilanciatori del carico sono un componente cruciale: indirizzano il traffico a vari servizi per fornire velocità ed efficienza e per contribuire a migliorare la sicurezza a livello globale per il traffico interno ed esterno.

I nostri bilanciatori del carico consentono anche di instradare e scalare il traffico su più cloud o ambienti ibridi. In questo modo, Cloud Load Balancing diventa la "porta principale" 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, e di livello 4 e livello 7.

Service Directory

Service Directory ti consente di gestire l'inventario dei servizi, fornendo un'unica posizione sicura per pubblicare, individuare e connettere servizi, tutte le operazioni supportate dal controllo dell'accesso dell'accesso basato sull'identità. Consente di registrare servizi denominati e i relativi endpoint. La registrazione può essere manuale o tramite integrazioni con Private Service Connect, GKE e Cloud Load Balancing. Il service discovery è possibile utilizzando API HTTP e gRPC esplicite, nonché Cloud DNS.

Cloud Service Mesh

Cloud Service Mesh è progettato per eseguire applicazioni complesse e distribuite consentendo un ricco insieme di criteri di gestione del traffico e di sicurezza nelle architetture mesh di servizi.

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

Private Service Connect

Private Service Connect crea astrazioni di servizio rendendo i carichi di lavoro accessibili in tutte le reti VPC tramite un unico 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 anziché sulle subnet o sui VPC, consentendo il consumo dei servizi in un modello producer-consumer, che si tratti di 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 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 l'utilizzo dei servizi a livello 4 o 7.

Al livello 4, Private Service Connect richiede al producer di creare una o più subnet 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 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.

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 ti consente di scegliere quali servizi sono disponibili utilizzando una mappa URL. Per ulteriori 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 in peering tra loro. Questo è diverso da Private Service Connect, che ti consente di proiettare un singolo indirizzo IP privato nella tua 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 hanno bisogno dell'accesso a internet o di indirizzi IP esterni per raggiungere i servizi disponibili tramite l'accesso privato ai servizi. L'accesso ai servizi privati può essere esteso alla rete on-premise utilizzando Cloud VPN o Cloud Interconnect per fornire un modo per gli host on-premise di raggiungere la rete producer di servizivizi. Per un elenco dei servizi gestiti da Google supportati tramite l'accesso privato ai servizi, consulta la sezione 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 Run Functions. La configurazione dell'accesso VPC serverless consente all'ambiente serverless di inviare richieste alla 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 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 su 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 più tipi di minacce. Queste minacce includono attacchi DDoS, attacchi basati sul web come cross-site scripting (XSS) e SQL injection (SQLi), nonché attacchi basati su frode e automazione.

Google Cloud Armor ispeziona le richieste in entrata sul perimetro globale di Google. Dispone di un insieme integrato di regole del web application firewall per la scansione di attacchi web comuni e di un sistema di rilevamento degli attacchi basato su ML che crea un modello di traffico valido e poi rileva il traffico dannoso. Infine, Google Cloud Armor si integra con reCAPTCHA per rilevare e bloccare frodi sofisticate e attacchi basati sull'automazione utilizzando la telemetria degli endpoint e del cloud.

Identity-Aware Proxy (IAP)

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

Controlli di servizio VPC

Controlli di servizio VPC ti aiuta 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 a garantire che l'utilizzo dei tuoi servizi Google Cloudavvenga 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à nativi del cloud, come account di servizio e reti VPC. Una volta 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 distribuzione 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. Ciò contribuisce a 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 è pensata per carichi di lavoro con un'uscita a velocità effettiva elevata.

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 riguardano vari aspetti dell'osservabilità della rete. Ogni prodotto ha un focus diverso e fornisce approfondimenti dettagliati per informare amministratori, architetti e professionisti in merito all'integrità e ai problemi della rete.

Architetture di riferimento

I seguenti documenti presentano architetture di riferimento per diversi tipi di carichi di lavoro: intra-cloud, esposti a internet e ibridi. Queste architetture del workload sono basate su un piano dati cloud realizzato utilizzando i blocchi predefiniti e i pattern architetturali 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 Architetture per la protezione dei piani dati cloud, i servizi reali potrebbero utilizzare una combinazione di questi design. Questi documenti descrivono ogni tipo di carico di lavoro e le considerazioni per ogni architettura di sicurezza.

Passaggi successivi