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

Last reviewed 2023-11-13 UTC

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

Come descritto nel documento allegato, 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 architetturali distinti: lift and shift, servizi ibridi e Zero Trust distribuiti. Il documento attuale considera diversi approcci di sicurezza, a seconda dell'architettura scelta dall'azienda. Descrive inoltre come realizzare questi approcci utilizzando i componenti di base forniti da Google Cloud. Dovresti utilizzare queste indicazioni sulla sicurezza insieme ad altre linee guida relative all'architettura che riguardano affidabilità, disponibilità, scalabilità, prestazioni e governance.

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

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

La serie è composta dai seguenti documenti:

Questo documento riassume i tre pattern architetturali principali e introduce i componenti di base delle risorse che puoi utilizzare per creare l'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 per guidare la tua architettura.

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

Panoramica dei pattern architettonici

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

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

In questa serie, consideriamo tre modelli architettonici comuni. Questi pattern sono basati uno sull'altro e possono essere visti come uno spettro piuttosto che come una scelta rigorosa.

Sequenza lift and shift

Nel modello architetturale lift and shift, i proprietari di applicazioni aziendali migrano i propri carichi di lavoro al cloud senza doverli refactoring. Gli ingegneri di 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 cloud nella rete VPC. I proprietari dei carichi di lavoro eseguono il deployment dei propri servizi nelle reti VPC.

Pattern dei servizi ibridi

I carichi di lavoro creati utilizzando la migrazione lift and shift potrebbero richiedere l'accesso a servizi cloud come BigQuery o Cloud SQL. In genere, l'accesso a questi servizi cloud avviene al livello 4 e al 7. In questo contesto, l'isolamento e la sicurezza non possono essere eseguiti rigorosamente a livello 3. Di conseguenza, 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 degli accessi.

Modello 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 Zero Trust, l'attendibilità si basa sull'identità e viene applicata per ogni applicazione. I carichi di lavoro sono creati come microservizi con identità emesse centralmente. In questo modo, i servizi possono convalidare i chiamanti e prendere decisioni basate su norme per ogni richiesta circa se tale accesso è accettabile. Questa architettura viene spesso implementata utilizzando proxy distribuiti (un mesh di servizi) invece di utilizzare gateway centralizzati.

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

Combinare pattern

Le aziende che creano o migrano le proprie applicazioni aziendali al cloud di solito usano 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 vengono illustrati più avanti nel documento. La combinazione dei controlli forniti nel piano dati cloud e dei controlli amministrativi per gestire le risorse cloud formano la base di un perimetro di sicurezza end-to-end. Il perimetro creato da questa combinazione 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 risorse, cartelle e progetti dell'organizzazione Google Cloud che consentono di raggruppare e organizzare in modo gerarchico le risorse cloud. Questa organizzazione gerarchica offre una struttura di proprietà e punti di ancoraggio per l'applicazione di criteri e controlli.

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

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

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

Considerazioni sulla progettazione delle reti Google Virtual Private Cloud

Quando progetti una strategia di migrazione nel cloud, è importante sviluppare una strategia per l'utilizzo delle reti VPC da parte dell'azienda. Puoi considerare una rete VPC come una versione virtuale della tua rete fisica tradizionale. È 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 job in un'altra rete VPC. Le reti VPC consentono quindi l'isolamento del carico di lavoro formando un confine di sicurezza.

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

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

Condivisione di una rete utilizzando un VPC condiviso

VPC condiviso consente a una risorsa dell'organizzazione di connettere più progetti a una rete VPC comune in modo che possano comunicare tra loro in modo sicuro utilizzando indirizzi IP interni dalla rete condivisa. Gli amministratori di rete di quella rete condivisa applicano e applicano il controllo centralizzato sulle risorse di rete.

Quando utilizzi un VPC condiviso, designi un progetto come progetto host a cui colleghi uno o più progetti di servizio. Le reti VPC nel progetto host sono chiamate reti VPC condivise. Le risorse idonee dei progetti di servizio possono utilizzare subnet della rete VPC condiviso.

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

Isolamento degli ambienti tramite l'utilizzo di reti VPC

L'utilizzo di 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 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 ambienti o unità aziendali in domini separati. I motivi 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 ulteriori informazioni, consulta la sezione 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, 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 di isolare gli ambienti

La creazione di ambienti isolati con reti VPC può presentare alcuni svantaggi. La presenza di più reti VPC può aumentare il sovraccarico amministrativo della gestione dei servizi su più reti. Questo documento illustra le tecniche che puoi utilizzare per gestire questa complessità.

Pattern comuni di isolamento della rete VPC

Esistono alcuni pattern comuni per isolare le reti VPC:

  • Isolare gli ambienti di sviluppo, gestione temporanea e produzione. Questo pattern consente alle aziende di separare completamente i propri ambienti di sviluppo, gestione temporanea e produzione l'uno dall'altro. In effetti, questa struttura mantiene più copie complete delle applicazioni, con un'implementazione progressiva tra ogni ambiente. In questo modello, le reti VPC vengono utilizzate come limiti di sicurezza. Gli sviluppatori hanno un accesso elevato alle reti VPC di sviluppo per svolgere il loro lavoro quotidiano. Al termine dello sviluppo, il team di produzione o QA può eseguire la migrazione delle modifiche in un ambiente di gestione temporanea, in cui 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à che sono state acquisite o che richiedono un elevato grado di autonomia e isolamento. In questo modello, le aziende creano spesso una rete VPC per ogni business unit e delegano il controllo di quel VPC agli amministratori della business unit. L'azienda utilizza tecniche descritte più avanti in questo documento per esporre servizi che coprono l'intera azienda o per ospitare applicazioni rivolte agli utenti in più unità aziendali.

Suggerimento per la creazione di ambienti isolati

Ti consigliamo di progettare le tue reti VPC in modo che abbiano il dominio più ampio in linea con i confini amministrativi e di sicurezza della tua azienda. Puoi ottenere un ulteriore isolamento tra i carichi di lavoro 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 VPC e Networking nel progetto di base della piattaforma aziendale di Google Cloud.

Componenti di base per il networking cloud

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

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

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

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

Connettività di rete

Il blocco della connettività di rete si trova alla base della gerarchia. È responsabile della connessione delle risorse Google Cloud a 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 consente di connettere le filiali lontane o altri cloud provider alle reti VPC di 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 consente di abilitare la connettività tra il tuo ambiente on-premise e Google Cloud senza l'overhead del provisioning delle connessioni incrociate fisiche richieste per Cloud Interconnect (descritte nella sezione successiva). Puoi eseguire il provisioning di una VPN ad alta disponibilità per soddisfare un requisito dello SLA (accordo sul livello del servizio) con disponibilità fino al 99,99% se disponi dell'architettura conforme. Puoi prendere in considerazione l'utilizzo di Cloud VPN se i carichi di lavoro non richiedono bassa latenza o larghezza di banda elevata. Ad esempio, Cloud VPN è una buona scelta per 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 più elevata e prestazioni di rete più affidabili rispetto all'uso della VPN o del traffico in entrata su internet. Dedicated Interconnect fornisce connettività fisica diretta alla rete Google dai tuoi router. Partner Interconnect fornisce connettività dedicata attraverso 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, 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 tua rete VPC non attraversi la rete internet pubblica.

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

Network Connectivity Center per ambienti ibridi

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

Inoltre, puoi estendere la rete overlay SD-WAN esistente a Google Cloud configurando una VM o un'appliance router di un fornitore di terze parti come collegamento logico dello spoke.

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 inoltre di creare un mesh tra molte reti VPC. Puoi connettere questo mesh a on-premise o ad altri cloud utilizzando Cloud VPN o Cloud Interconnect.

Peering di rete VPC

Il peering di rete VPC consente di connettere le reti VPC Google in modo che i carichi di lavoro in reti VPC diverse possano comunicare internamente indipendentemente dal fatto che appartengano allo stesso progetto o alla stessa risorsa 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 connettere in peering non abbiano indirizzi IP sovrapposti.

Sicurezza della rete

Il blocco di sicurezza della 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.

Regole firewall VPC

A una determinata rete si applicano le regole firewall VPC. Le regole firewall VPC consentono di consentire o negare le connessioni da o verso le istanze VM, in base a una configurazione da te specificata. Le regole firewall abilitate per il VPC vengono applicate sempre, proteggendo le istanze indipendentemente dalla loro configurazione, dal sistema operativo o dal fatto che le VM siano completamente avviate.

Ogni rete VPC funziona come un firewall distribuito. Anche se le regole firewall sono 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 all'interno della stessa rete.

Criteri firewall gerarchici

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

Mirroring pacchetto

Il Mirroring pacchetto clona il traffico di istanze specifiche nella rete VPC e lo inoltra ai raccoglitori per l'esame. Il mirroring dei pacchetti acquisisce tutto il traffico e i dati dei pacchetti, inclusi payload e intestazioni. Puoi configurare il mirroring sia per il traffico in entrata che per quello in uscita. Il mirroring avviene sulle istanze VM, non sulla rete.

Appliance virtuale di rete

Le appliance virtuali di rete consentono di applicare controlli di sicurezza e conformità alla rete virtuale in linea con i controlli nell'ambiente on-premise. Puoi farlo eseguendo il deployment delle immagini VM disponibili in Google Cloud Marketplace su VM con più interfacce di rete, ciascuna collegata a una rete VPC diversa, in modo da 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 NGFW sono costituiti da un set centralizzato di firewall in esecuzione come VM che forniscono funzionalità non disponibili nelle regole firewall di VPC. Le caratteristiche tipiche dei prodotti NGFW includono l'ispezione dei pacchetti profonda (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 fornisce visibilità sul traffico potenzialmente dannoso. Per prevenire le intrusioni, i dispositivi IPS possono impedire al traffico dannoso di raggiungere la destinazione.
  • Gateway web sicuro (SWG). Un SWG blocca le minacce su internet consentendo alle aziende di applicare criteri aziendali al traffico da e verso internet. utilizzando il filtro degli URL, il rilevamento di codice dannoso e controllo dell'accesso.
  • Gateway NAT (Network Address Translation). Un gateway NAT converte gli indirizzi IP e le porte. Ad esempio, questa traduzione consente di evitare la sovrapposizione di indirizzi IP. Google Cloud offre Cloud NAT come servizio gestito, ma questo servizio è disponibile solo per il traffico indirizzato a internet, non per quello diretto a on-premise o ad altre reti VPC.
  • Web Application Firewall (WAF). Un WAF è progettato per bloccare il traffico HTTP(S) dannoso indirizzato a un'applicazione web. Google Cloud offre la 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 alla tua rete. Cloud IDS crea una rete in peering gestita da Google contenente VM che riceveranno traffico con 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 una 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 supporto Network Address Translation software-defined completamente gestito per le applicazioni. Consente Network Address Translation di origine (NAT di origine o SNAT) per il traffico rivolto a internet da VM che non hanno indirizzi IP esterni.

Firewall Insights

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

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 (autorizzazione o negazione) 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 le istanze utilizzate come nodi di Google Kubernetes Engine (GKE). Questi log possono essere utilizzati per monitoraggio della rete, analisi forense, analisi della sicurezza in tempo reale e ottimizzazione delle spese.

Networking di servizi

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

Cloud DNS

È possibile accedere ai carichi di lavoro utilizzando 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 sia zone DNS 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 una componente fondamentale: instradano il traffico a vari servizi per garantire velocità ed efficienza e contribuire a garantire la sicurezza a livello globale per il traffico sia interno che esterno.

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

Service Directory

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

Mesh di servizi: Anthos Service Mesh e Traffic Director

Sia Anthos Service Mesh sia Traffic Director sono progettati per semplificare l'esecuzione di applicazioni complesse e distribuite mediante l'attivazione di una vasta gamma di criteri di sicurezza e gestione del traffico nelle architetture di mesh di servizi. Le differenze principali tra questi prodotti stanno negli ambienti supportati, nelle API Istio per questi prodotti e nelle capacità di bilanciamento del carico globale.

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

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

La tabella seguente riassume le funzionalità di Traffic Directory e Anthos Service Mesh.

Anthos Service Mesh Traffic Director
Tipo di deployment Kubernetes VM, Kubernetes
Ambienti Google Cloud, on-premise, multi-cloud Google Cloud, on-premise, multi-cloud
Ambito deployment A livello di regione 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 basata sull'integrità del backend Sì (in base a Kubernetes) Sì
Distribuzione del carico globale basata sul carico del backend No Sì
Identità gestita per mTLS carico di lavoro (zero trust) Sì Sì (solo GKE)

Google ha ulteriormente approfondito le modalità di creazione di un ambiente end-to-end Zero Trust con architettura distribuita utilizzando l'architettura BeyondProd. Oltre al perimetro della rete e all'autenticazione e all'autorizzazione dei servizi, BeyondProd descrive in dettaglio come gli ambienti di computing affidabili, la provenienza del codice e le implementazioni dei deployment svolgano un ruolo nel raggiungimento di un'architettura di servizio Zero Trust sicura e distribuita. Dovresti prendere in considerazione queste preoccupazioni che vanno oltre il networking quando adotti un approccio Zero Trust.

Private Service Connect

Private Service Connect crea astrazioni di servizi rendendo i carichi di lavoro accessibili nelle reti VPC tramite un singolo endpoint. Ciò consente a due reti di comunicare in un modello client-server che espone solo il servizio al consumer, invece dell'intera rete o del carico di lavoro stesso. Un modello di rete orientato ai servizi consente agli amministratori di rete di ragionare sui servizi che espongono tra reti anziché tra subnet o VPC, consentendo il consumo dei servizi in un modello producer-consumer, sia per servizi proprietari o di terze parti (SaaS).

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

Puoi estendere Private Service Connect alla tua rete on-premise per accedere agli endpoint che si connettono alle API di Google o ai servizi gestiti in un'altra rete VPC. Private Service Connect consente il consumo di servizi al livello 4 o al livello 7.

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

Al livello 7, puoi creare un backend Private Service Connect utilizzando un bilanciatore del carico delle applicazioni interno. L'Application Load Balancer interno consente di scegliere quali servizi sono disponibili utilizzando una mappa URL. Per saperne di più, 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 una terza parte. 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 di producer e consumer siano connesse in peering tra loro. È diverso da Private Service Connect, che consente di proiettare un singolo indirizzo IP privato nella subnet.

La connessione privata consente alle istanze VM nella rete VPC e ai servizi a cui accedi di comunicare esclusivamente 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 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 supportati dall'accesso privato ai servizi, vedi Servizi supportati nella documentazione di Virtual Private Cloud.

Accesso VPC serverless

L'accesso VPC serverless ti consente di connetterti direttamente alla tua rete VPC da servizi ospitati in ambienti serverless come Cloud Run, App Engine o Cloud Functions. La configurazione dell'accesso VPC serverless consente all'ambiente serverless di inviare richieste alla rete VPC utilizzando indirizzi IP interni e DNS interni. Le risposte a queste richieste utilizzano anche la tua rete virtuale.

L'accesso VPC serverless invia il traffico interno dalla rete VPC all'ambiente serverless solo quando questo traffico è una risposta a una richiesta inviata dall'ambiente serverless attraverso il connettore di accesso VPC serverless.

L'accesso VPC serverless offre i seguenti vantaggi:

  • Le richieste inviate alla tua rete VPC non sono mai esposte a internet.
  • La comunicazione tramite accesso VPC serverless può avere una latenza minore rispetto alla comunicazione su internet.

Sicurezza dei servizi

I blocchi di sicurezza del servizio controllano l'accesso alle risorse in base all'identità del richiedente o alla comprensione di livello superiore dei pattern dei pacchetti anziché solo sulle caratteristiche di un singolo pacchetto.

Google Cloud Armor per DDoS/WAF

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

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

Identity Aware Proxy (IAP)

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

Controlli di servizio VPC

Controlli di servizio VPC ti aiuta a ridurre il rischio di esfiltrazione di dati dai servizi di Google Cloud come Cloud Storage e BigQuery. L'utilizzo dei Controlli di servizio VPC contribuisce 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 la creazione di un perimetro, l'accesso ai servizi Google specificati viene negato, a meno che la richiesta non provenga dall'interno del perimetro.

Distribuzione di contenuti

I blocchi dell'importazione dei contenuti controllano l'ottimizzazione della pubblicazione di applicazioni e contenuti.

Cloud CDN

Cloud CDN fornisce un'accelerazione dei contenuti statici utilizzando la rete perimetrale globale di Google per fornire contenuti da un punto più vicino all'utente. Ciò consente di ridurre la latenza di siti web e applicazioni.

Media CDN

Media CDN è la soluzione di Google per la distribuzione di contenuti multimediali ed è progettata 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 i problemi, documentare ed esaminare i problemi.

Network Intelligence Center

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

Architetture di riferimento

I seguenti documenti presentano architetture di riferimento per diversi tipi di carichi di lavoro: intra-cloud, per internet e ibridi. Queste architetture dei carichi di lavoro sono costruite su un piano dati cloud realizzato utilizzando i componenti di base e i pattern architetturali delineati nelle sezioni precedenti di questo documento.

Puoi utilizzare le architetture di riferimento per progettare modi per eseguire la migrazione o creare carichi di lavoro nel cloud. I carichi di lavoro sono quindi supportati dal piano dati cloud e utilizzano le architetture. Anche se questi documenti non forniscono un set completo di architetture di riferimento, coprono gli scenari più comuni.

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

Passaggi successivi