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

Last reviewed 2023-11-13 UTC

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

Come descritto nel documento Architectures for Protecting Cloud Data Planes, 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 di architettura distinti: lift and shift, servizi ibridi e Zero Trust distribuito. Il documento prende in esame diversi approcci alla sicurezza, a seconda dell'architettura scelta. Descrive inoltre come realizzare questi approcci utilizzando i componenti di base forniti da Google Cloud. È consigliabile utilizzare queste indicazioni sulla sicurezza insieme ad altre indicazioni relative all'architettura che riguardano affidabilità, disponibilità, scalabilità, prestazioni e governance.

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

  • Conosci i concetti di rete e sicurezza dei data center.
  • Hai carichi di lavoro esistenti nel tuo data center on-premise e conosci cosa fanno e chi sono i suoi 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 che corrispondono ai pattern. Puoi usare queste architetture di riferimento come guida per la tua architettura.

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

Panoramica dei modelli architetturali

In genere, i tecnici 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 cambiato questo approccio perché i costrutti di networking cloud sono software-defined. Nel cloud, i proprietari di applicazioni hanno un controllo limitato dello stack dell'infrastruttura sottostante. di un modello che abbia un perimetro sicuro e che fornisca l'isolamento dei carichi di lavoro.

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

Schema lift and shift

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

Modello di servizi ibridi

I carichi di lavoro creati utilizzando lift and shift potrebbero richiedere l'accesso a servizi cloud come BigQuery o Cloud SQL. In genere, l'accesso a questi servizi cloud è al livello 4 e al 7. In questo contesto, l'isolamento e la sicurezza non possono essere eseguiti rigorosamente al livello 3. Pertanto, il networking di servizi 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 avanzati di controllo dell'accesso.

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 ha un'autorizzazione specifica, che è negata per impostazione predefinita. In un'architettura distribuita e Zero Trust, il trust è basato sull'identità e viene applicato a 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 basate su criteri per ogni richiesta e stabilire se tale accesso è accettabile. Questa architettura viene spesso implementata utilizzando proxy distribuiti (un mesh di servizi) anziché utilizzare gateway centralizzati.

Le aziende possono imporre 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.

Combinazione di pattern

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

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 verranno illustrati più avanti in questo documento. La combinazione dei controlli forniti nel piano dati cloud, insieme ai controlli amministrativi per la gestione delle risorse cloud, costituiscono la base di un perimetro di sicurezza end-to-end. Il perimetro creato da questa combinazione ti consente di gestire, eseguire il deployment e gestire i carichi di lavoro nel cloud.

Gerarchia delle risorse e controlli amministrativi

Questa sezione presenta un riepilogo dei controlli amministrativi che Google Cloud fornisce come container di risorse. I controlli includono le risorse, le cartelle e i progetti dell'organizzazione Google Cloud che 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 nella gerarchia ed è 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 figlio. Tutte le altre risorse cloud sono elementi figlio dei progetti.

Puoi utilizzare 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 consentono di gestire le API, abilitare la fatturazione, aggiungere e rimuovere collaboratori e gestire le autorizzazioni.

Utilizzando 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 più in basso nella gerarchia. Questi criteri non possono essere modificati dai proprietari delle risorse che si trovano in un livello inferiore nella gerarchia. In alcuni casi, la gestione di identità e accessi viene fornita a un livello più granulare, ad esempio nell'ambito degli oggetti in uno spazio dei nomi o in un cluster, ad esempio in Google Kubernetes Engine.

Considerazioni sulla progettazione delle reti Google Virtual Private Cloud

Quando si progetta una strategia di migrazione al cloud, è importante sviluppare una strategia per l'utilizzo delle reti VPC da parte dell'azienda. Una rete VPC è come 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. Le reti VPC consentono quindi l'isolamento dei carichi di lavoro formando un confine di sicurezza.

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

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

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

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

Condivisione di una rete mediante VPC condiviso

Un 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 della 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 reteVPC condivisoa.

Le aziende in genere utilizzano le reti VPC condiviso quando hanno bisogno di amministratori di rete e della sicurezza per centralizzare la gestione delle risorse di rete come subnet e route. Allo stesso tempo, le reti VPC condiviso consentono ai team di applicazioni e sviluppo 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'uso di reti VPC per isolare gli ambienti presenta una serie di vantaggi, ma devi considerare anche alcuni svantaggi. Questa sezione risolve questi compromessi e descrive i modelli comuni per l'implementazione dell'isolamento.

Motivi per isolare gli ambienti

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

  • Un'azienda vuole stabilire comunicazioni default-deny tra una rete VPC e un'altra, poiché queste reti rappresentano una distinzione significativa a livello organizzativo. Per ulteriori informazioni, consulta Pattern di isolamento della rete VPC comuni più avanti in questo documento.
  • Un'azienda deve avere intervalli di indirizzi IP sovrapposti a causa di ambienti on-premise preesistenti, a causa 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 l'overhead amministrativo associato alla gestione dei servizi su più reti. Questo documento illustra le tecniche che puoi utilizzare per gestire questa complessità.

Pattern di isolamento della rete VPC comuni

Esistono alcuni pattern comuni per isolare le reti VPC:

  • Isolare gli ambienti di sviluppo, gestione temporanea e produzione. Questo modello consente alle aziende di 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 i singoli ambienti. In questo pattern, le reti VPC vengono usate come confini di sicurezza. Gli sviluppatori hanno un elevato grado di accesso alle reti VPC di sviluppo per svolgere il loro lavoro quotidiano. Al termine dello sviluppo, un team di produzione ingegneristico o un team di QA può migrare le modifiche in un ambiente di gestione temporanea, 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 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 quel VPC agli amministratori dell'unità aziendale. L'azienda utilizza le tecniche descritte più avanti in questo documento per esporre i 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 reti VPC in modo da avere il dominio più ampio, in linea con i confini amministrativi e di sicurezza della tua azienda. È possibile ottenere un ulteriore isolamento tra i carichi di lavoro in esecuzione nella stessa rete VPC utilizzando i 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 VPC e Networking nel progetto delle basi aziendali di Google Cloud.

Componenti di base per il networking cloud

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

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

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

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

Connettività di rete

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

Cloud VPN

Cloud VPN 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 quindi decriptato dall'altro gateway VPN, contribuendo così a proteggere i dati mentre attraversano internet.

Cloud VPN ti consente di abilitare la connettività tra il tuo ambiente on-premise e Google Cloud senza l'overhead associato al provisioning delle connessioni incrociate fisiche necessarie per Cloud Interconnect (descritto nella prossima sezione). Puoi eseguire il provisioning di una VPN ad alta disponibilità per soddisfare il requisito dello SLA (accordo sul livello del servizio) con una disponibilità fino al 99,99% se disponi dell'architettura conforme. Valuta Cloud VPN se i tuoi 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 estendere la 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 di VPN o accesso a internet in entrata. Dedicated Interconnect fornisce connettività fisica diretta alla rete Google dai tuoi router. Partner Interconnect fornisce connettività dedicata attraverso 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 reti VPC ad altri cloud provider. Dedicated Interconnect richiede la connessione a una struttura di colocation in cui Google ha una presenza, al contrario di Partner Interconnect. Cross-Cloud Interconnect ti consente di selezionare località che soddisfano i tuoi requisiti per stabilire le connessioni. Cloud Interconnect garantisce che il traffico tra la tua 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 il requisito dello SLA (accordo sul livello del servizio) che prevede una disponibilità fino al 99,99%, se esegui il provisioning dell'architettura appropriata. Puoi prendere in considerazione l'utilizzo di Cloud Interconnect per supportare carichi di lavoro che richiedono bassa latenza, larghezza di banda elevata e prestazioni prevedibili, assicurandoti al contempo che tutto il tuo traffico rimanga privato.

Network Connectivity Center per ambienti ibridi

Network Connectivity Center fornisce connettività site-to-site tra le 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 tua rete overlay SD-WAN esistente a Google Cloud configurando una VM o un fornitore di terze parti l'appliance router 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 vista.

Network Connectivity Center per reti VPC

Network Connectivity Center consente anche di creare un mesh tra molte reti VPC. Puoi connettere questa rete 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, a prescindere dalla loro appartenenza allo stesso progetto o alla stessa risorsa dell'organizzazione. Il traffico rimane all'interno della rete Google e non attraversa la rete internet pubblica.

Il peering di rete VPC richiede che le reti da gestire in peering non abbiano indirizzi IP sovrapposti.

Sicurezza della rete

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

Regole firewall VPC

Le regole firewall VPC si applicano a una data rete. Le regole firewall VPC consentono o negano 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 dal fatto che le VM siano state completamente avviate.

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 un criterio firewall coerente in tutta l'azienda. Questi criteri contengono regole che possono consentire o negare esplicitamente le connessioni. Puoi assegnare criteri firewall gerarchici alla risorsa dell'organizzazione come un intero o a una singola cartella.

Mirroring pacchetto

Il Mirroring pacchetto 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 sia per il traffico in entrata che per quello 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 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 in VM con più interfacce di rete, ciascuna collegata a una rete VPC diversa, per eseguire una varietà di funzioni virtuali di rete.

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

  • Firewall di nuova generazione (NGFW). I firewall NGFW sono costituiti da un insieme centralizzato di firewall eseguiti come VM che forniscono funzionalità non disponibili nelle regole firewall VPC. Le caratteristiche tipiche dei prodotti NGFW includono l'ispezione approfondita dei pacchetti (DPI) e la protezione del firewall a livello di applicazione. Alcuni NGFW forniscono anche l'ispezione del traffico TLS/SSL e altre funzioni di networking, come descritto più avanti in questo elenco.
  • Sistema di rilevamento delle intrusioni/sistema di prevenzione delle intrusioni (IDS/IPS). Un IDS basato su rete offre visibilità sul traffico potenzialmente dannoso. Per prevenire intrusioni, i dispositivi IPS possono bloccare il traffico dannoso in modo che non raggiunga la destinazione.
  • Gateway web sicuro (SWG). Uno SWG blocca le minacce su internet consentendo alle aziende di applicare criteri aziendali al traffico che viaggia da e verso internet. Ciò avviene mediante filtri degli URL, rilevamento di codice dannoso e controllo dell'accesso.
  • Gateway NAT (Network Address Translation). Un gateway NAT traduce indirizzi IP e 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 diretto verso internet, non per il traffico diretto a 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 funzionalità WAF tramite i criteri di sicurezza di Google Cloud Armor. La funzionalità esatta varia a seconda del fornitore WAF, quindi è importante determinare ciò di cui hai bisogno.

Cloud IDS

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

Cloud NAT

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

Firewall Insights

Firewall Insights ti aiuta a comprendere e ottimizzare le tue regole firewall. Fornisce dati sull'utilizzo delle regole firewall, espone le configurazioni errate e identifica le regole che potrebbero essere rese più rigide. Inoltre, sfrutta il machine learning per prevedere l'utilizzo futuro delle regole firewall, in modo da poter prendere decisioni informate se rimuovere o rafforzare le regole che sembrano eccessivamente permissive.

Log 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 negati) 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 Google Kubernetes Engine (GKE). Questi log possono essere utilizzati per monitoraggio della rete, analisi forense, analisi della sicurezza in tempo reale e ottimizzazione delle spese.

Networking di servizi

I blocchi del networking di servizi sono responsabili della fornitura di servizi di ricerca che indicano ai servizi dove deve essere inviata una richiesta (DNS, Service Directory) e della ricezione delle richieste nella posizione corretta (Private Service Connect, Cloud Load Balancing).

Cloud DNS

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

Cloud Load Balancing

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

Inoltre, i nostri bilanciatori del carico consentono il routing e la scalabilità del 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 trova o in quanti posti è 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 unico posto sicuro in cui pubblicare, individuare e connettere i servizi, tutte le 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. La Service Discovery è possibile sia utilizzando API HTTP e gRPC esplicite sia utilizzando Cloud DNS.

Mesh di servizi: Cloud Service Mesh e Cloud Service Mesh

Sia Cloud Service Mesh che Cloud Service Mesh sono progettati per semplificare l'esecuzione di applicazioni complesse e distribuite, abilitando un ricco insieme di criteri di gestione del traffico e di sicurezza nelle architetture mesh di servizi. Le differenze principali tra questi prodotti stanno negli ambienti supportati, nelle API Istio specifiche e nelle funzionalità di bilanciamento del carico globale.

Cloud Service Mesh è ideale per i deployment regionali e globali basati su Kubernetes, sia su Google Cloud che on-premise, che beneficiano di un prodotto Istio gestito.

Cloud Service Mesh è ideale per i casi d'uso di networking che presentano servizi di integrità e carico distribuiti a livello globale in Google Cloud. Cloud Service Mesh gestisce i carichi di lavoro utilizzando proxy Envoy che agiscono come file collaterali o gateway oppure mediante carichi di lavoro gRPC senza proxy.

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

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

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

Private Service Connect

Private Service Connect crea astrazioni di servizio rendendo i carichi di lavoro accessibili tra le reti VPC attraverso 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 anziché tra subnet o VPC, consentendo il consumo dei servizi in un modello producer-consumer, che 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 a servizi gestiti in un'altra rete VPC. Private Service Connect consente il consumo dei servizi di livello 4 o 7.

Nel livello 4, Private Service Connect richiede che il producer crei una o più subnet specifiche di Private Service Connect. Queste subnet sono chiamate anche subnet NAT. Private Service Connect esegue la traduzione NAT utilizzando un indirizzo IP selezionato da una delle subnet Private Service Connect per instradare le richieste a un producer di servizi. Questo approccio ti consente di utilizzare 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 i servizi 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 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 tua 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 consentire agli host on-premise di raggiungere la rete del producer di servizi. Per un elenco dei servizi gestiti da Google che sono supportati tramite l'accesso privato ai servizi, vedi Servizi supportati nella documentazione di Virtual Private Cloud.

Accesso VPC serverless

L'accesso VPC serverless 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 il DNS interno e gli indirizzi IP 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 se 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 accesso VPC serverless può avere meno latenza rispetto alla comunicazione su internet.

Sicurezza dei servizi

La sicurezza del servizio blocca l'accesso alle risorse in base all'identità del richiedente o 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 di mitigazione del web application firewall (WAF) e del Distributed Denial-of-Service (DDoS) che consente di difendere le applicazioni e i 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 ispeziona le richieste in entrata sul perimetro globale di Google. Dispone di un set integrato di regole web application firewall da scansionare per individuare gli attacchi web più comuni e di un sistema avanzato di rilevamento degli attacchi basato su ML che crea un modello di traffico di qualità elevata e rileva il traffico non valido. Infine, Google Cloud Armor si integra con Google reCAPTCHA per contribuire a rilevare e bloccare attacchi sofisticati basati su automazione e attività fraudolente, utilizzando sia la telemetria degli endpoint che la telemetria cloud.

Identity-Aware Proxy (IAP)

Identity-Aware Proxy (IAP) fornisce controlli dell'accesso sensibili al contesto ad applicazioni basate su cloud e VM in esecuzione su Google Cloud o collegate a Google Cloud tramite una qualsiasi 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 anche il tunneling TCP per l'accesso SSH/RDP dagli utenti aziendali.

Controlli di servizio VPC

Controlli di servizio VPC consente di ridurre il rischio di esfiltrazione di dati dai servizi Google Cloud come Cloud Storage e BigQuery. L'utilizzo dei Controlli di servizio VPC aiuta a garantire 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 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 distribuzione dei contenuti controllano l'ottimizzazione della distribuzione di applicazioni e contenuti.

Cloud CDN

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

Media CDN

Media CDN è la soluzione di distribuzione dei media di Google ed è creata per carichi di lavoro in uscita ad alta velocità effettiva.

Osservabilità

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

Network Intelligence Center

Network Intelligence Center comprende diversi prodotti che affrontano vari aspetti dell'osservabilità della rete. Ogni prodotto è incentrato su un approccio diverso e fornisce insight dettagliati 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, per internet e ibrido. Queste architetture dei carichi di lavoro sono basate su un piano dati cloud che viene realizzato utilizzando i componenti di base e i pattern architetturali descritti nelle sezioni precedenti di questo documento.

Puoi utilizzare le architetture di riferimento per progettare la migrazione o la creazione di carichi di lavoro nel cloud. I carichi di lavoro sono quindi supportati dal piano dati cloud e usano le architetture. Sebbene questi documenti non forniscano un insieme esaustivo di architetture di riferimento, riguardano gli scenari più comuni.

Come per i pattern dell'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 trattano ogni tipo di carico di lavoro e le considerazioni per ciascuna architettura di sicurezza.

Passaggi successivi