Best practice per la sicurezza di VMware Engine
Questo documento descrive le best practice di sicurezza consigliate per la gestione e la configurazione di Google Cloud VMware Engine ed è destinato agli utenti che hanno già familiarità con VMware Engine. Se sei un principiante, puoi iniziare a conoscere i prerequisiti e la sicurezza di VMware Engine.
VMware Engine ha un modello di responsabilità condivisa per la sicurezza. Una sicurezza affidabile nel cloud si raggiunge attraverso le responsabilità condivise dei clienti e di Google come fornitore di servizi. Seguendo queste best practice puoi risparmiare tempo, prevenire gli errori e mitigare gli effetti dei punti di errore.
Networking di VMware Engine
Le seguenti sezioni introducono le best practice per il networking in un ambiente VMware Engine.
Identifica e comprendi tutti i flussi di traffico del tuo ambiente
VMware Engine sfrutta le reti VMware Engine e i peering VPC per connettere una connessione di rete privata da una rete cloud privato di VMware Engine alla rete VPC. Il traffico in entrata da un VPC nel tuo ambiente Google Cloud o da una rete on-premise attraversa una rete di unità di tenancy gestita da Google.
Utilizza il servizio IP pubblico di VMware Engine per il trasferimento di dati internet
Il traffico internet può entrare direttamente in un cloud privato utilizzando il servizio IP pubblico di VMware Engine. In alternativa, il traffico internet può entrare utilizzando un bilanciatore del carico pubblico su Google Cloud. In questo caso, il traffico viene instradato come qualsiasi altro traffico in entrata. Tieni presente che queste opzioni si escludono a vicenda. Se sono richiesti controlli personalizzati per il traffico internet, ad esempio filtri degli URL, IPS/IDS o ispezione del traffico fornita da un'istanza centrale o da un servizio nel tuo ambiente Google Cloud, devi instradare il traffico legato a internet attraverso la rete VPC.
Se questo non è il tuo caso o se hai implementato i controlli all'interno del tuo cloud privato, ti consigliamo di includere il servizio degli indirizzi IP esterni in VMware Engine. Inoltre, ti consigliamo di utilizzare le regole di accesso esterno per negare i pattern di traffico da internet che non si applicano alle tue applicazioni.
Separa le regole firewall nord-sud ed est-ovest sul gateway e il firewall distribuito in VMware Engine NSX-T
Configura il firewall distribuito (DFW) in NSX-T sul router logico di livello 1 per segmentare il traffico interno tra i domini di livello 2 virtuale. Il DFW di NSX è progettato per gestire il traffico di rete (interno) est-ovest tra i segmenti e consente le regole firewall che consentono e negano il traffico tra singole istanze all'interno di un segmento.
Per controllo dell'accesso alla rete granulare, assicurati di applicare un criterio predefinito limitato al file DFW per negare il traffico di rete tra le istanze per impostazione predefinita. Utilizza il file DFW per consentire in modo specifico il traffico tra le applicazioni e tra i servizi all'interno dell'applicazione.
Configura il firewall gateway NSX per controllare il traffico da nord a sud che entra ed esce dal cloud privato.
Il firewall del gateway NSX è progettato per controllare il traffico da nord a sud e consigliato per casi d'uso come il controllo del traffico in un perimetro verso un'altra zona di sicurezza. Se devi configurare in modo coerente il traffico da nord-sud per l'intero cloud privato, configura il firewall del gateway sul router di livello 0. Se devi configurare il traffico da nord-sud per ogni singolo segmento NSX-T, configura il firewall del gateway sul router di livello 1.
Oltre ai firewall NSX-T, è consigliabile utilizzare il firewall VPC per consentire e bloccare il traffico da est-ovest tra i carichi di lavoro nel cloud privato VMware Engine e i carichi di lavoro nei VPC. Il trasferimento di dati in entrata nelle istanze Compute Engine dai carichi di lavoro VMware Engine dovrebbe essere limitato per impostazione predefinita con solo il traffico aperto consapevolmente.
Il trasferimento di dati in uscita verso le appliance di gestione e all'intervallo CIDR vSphere/vSAN deve essere bloccato dai VPC e tramite il firewall VPC. Apri il trasferimento di dati in uscita solo verso appliance di gestione da host e indirizzi IP attendibili all'interno della tua rete. È importante notare che le appliance di gestione non si trovano all'interno di un segmento NSX-T e, di conseguenza, le regole DFW non si applicano per limitare l'accesso.
Applicare i principi di sicurezza Zero Trust e la micro-segmentazione in NSX-T
Utilizza il DFW NSX-T per implementare controlli del traffico per segmenti di sicurezza che sono granulari come singole macchine virtuali. Questo principio di protezione del traffico tra le singole VM negato per impostazione predefinita è spesso indicato anche come "micro-segmentazione", un approccio più granulare per il firewall rispetto all'implementazione convenzionale dei firewall tra i domini di livello 3.
Il file DFW è abilitato nel kernel dell'hypervisor su tutti gli host di VMware Engine vSphere nel tuo cloud privato e può controllare il flusso di traffico tra carichi di lavoro che si trovano nello stesso segmento o in segmenti NSX separati. Le regole firewall per consentire il traffico da e verso le VM possono essere definite organizzando le VM in gruppi di criteri, che possono avere criteri di appartenenza flessibili, come la corrispondenza dei tag o dei nomi delle VM.
La micro-segmentazione consente di implementare una rete con controllo granulare del traffico in cui un modello di traffico deve essere consentito esplicitamente. Il concetto di sicurezza in cui tutti i flussi di rete sono controllati da processi di verifica dell'identità e dei dispositivi anziché da attendibilità implicita è spesso chiamato Zero Trust Security.
Esegui il deployment di un'appliance firewall di terze parti dal portale Cloud Marketplace per le funzionalità IPS/IDS
Se hai bisogno di sicurezza avanzata di livello 7, incluse funzionalità IDS/IPS per il traffico in entrata nel cloud privato dal resto della rete o tra i segmenti di rete NSX-T, valuta la possibilità di implementare un'appliance firewall di terze parti. Il deployment dell'appliance di terze parti può essere eseguito come appliance multi-NIC tra due VPC nella rete Google Cloud o all'interno del cloud privato con un'integrazione con NSX-T.
Per un approfondimento sulle architetture VMware Engine con appliance centralizzate, che possono essere utilizzate per una varietà di casi d'uso di sicurezza avanzati, come IPS/IDS, DDoS, offload SSL e altro, consulta la sezione sulla sicurezza della rete dei documenti utilizzando appliance centralizzate nel Cloud Architecture Center.
Utilizzare Google Cloud Armor per proteggere i servizi web su VMware Engine dagli attacchi DDoS
Se instrada il traffico in entrata ai carichi di lavoro su VMware Engine tramite il VPC del cliente, ti consigliamo di posizionare i carichi di lavoro VMware Engine in gruppi di endpoint di rete ibridi dietro Traffic Director e di sfruttare il bilanciatore del carico HTTP(S) esterno. Entrambe le configurazioni consentono di includere Google Cloud Armor per le applicazioni rivolte al pubblico, con la mitigazione degli attacchi DDoS e delle vulnerabilità comuni come le iniezioni SQL o cross-site scripting (XSS).
Se hai bisogno di funzionalità Mesh di servizi, come la gestione avanzata del traffico tramite il proxy Envoy o l'integrazione di Certificate Authority Service, ti consigliamo Traffic Director. In tutti gli altri casi, consigliamo il bilanciatore del carico HTTP(S) esterno.
Segui la documentazione su come aggiungere i carichi di lavoro VMware Engine ai NEG ibridi in una delle seguenti configurazioni:
- Bilanciamento del carico HTTP(S) esterno a livello di regione con connettività ibrida
- Bilanciatore del carico HTTP(S) esterno globale con connettività ibrida
Connettiti ai servizi Google Cloud in privato senza accesso a internet
I carichi di lavoro del cloud privato di VMware Engine possono accedere alle API Google Cloud come l'API Cloud Storage tramite l'accesso privato Google. Ti consigliamo di utilizzare l'accesso privato Google per accedere ai servizi Google senza inviare traffico su internet, poiché riduce la latenza e i costi del trasferimento dei dati in uscita. Ciò elimina anche la necessità di un percorso di rete a internet per i carichi di lavoro che richiedono solo l'accesso all'API di Google. Segui gli approfondimenti sull'accesso privato Google per ulteriori dettagli tecnici e i passaggi di configurazione.
Allo stesso modo, i carichi di lavoro VMware Engine che devono accedere alle risorse Google Cloud dalla rete di un producer di servizi come le istanze Cloud SQL o Memorystore devono connettersi privatamente tramite PSA. Per ulteriori informazioni, consulta la sezione relativa a PSA per VMware Engine.
Cripta la comunicazione tra il tuo ambiente on-premise e Google Cloud
I carichi di lavoro su VMware Engine che devono comunicare con sistemi on-premise devono connettersi su un canale criptato. Ti consigliamo un approccio a più livelli per la crittografia dei dati in transito tra i tuoi data center on-premise e Google Cloud. Il collegamento tra i sistemi on-premise e Google Cloud può essere criptato configurando Cloud VPN con un tunnel IPsec oppure utilizzando l'IPsec integrato sui collegamenti VLAN di Interconnect. Inoltre, la crittografia a livello di applicazione deve essere abilitata tra i componenti dell'applicazione che utilizzano TLS.
Proteggi i tuoi dati dall'esfiltrazione con i Controlli di servizio VPC
Ti consigliamo di ridurre i rischi di esfiltrazione di dati utilizzando i Controlli di servizio VPC posizionando le tue risorse sensibili come i bucket Cloud Storage e i set di dati BigQuery in un perimetro dei Controlli di servizio VPC. Anche i carichi di lavoro che devono accedere ai dati all'interno di un perimetro devono essere inseriti all'interno del perimetro. In particolare, il progetto Google Cloud che ospita il cloud privato deve far parte del perimetro dei Controlli di servizio VPC per accedere alle risorse protette dai Controlli di servizio VPC.
Per consentire alle API di servizio producer di VMware Engine di entrare nel perimetro, devi configurare i criteri di trasferimento dei dati in entrata e in uscita nella configurazione dei Controlli di servizio VPC. Per indicazioni dettagliate sulla configurazione, consulta le pagine della documentazione sui Controlli di servizio VPC con VMware Engine.
IAM e autorizzazioni di VMware Engine
Le seguenti sezioni introducono le best practice per le autorizzazioni utente in un ambiente VMware Engine. È importante gestire le autorizzazioni all'interno dell'ambiente VMware Engine e del progetto Google Cloud in cui viene eseguito il deployment del cloud privato.
Utilizza ruoli predefiniti o ruoli personalizzati per concedere l'accesso
L'approccio di VMware Engine alla gestione di ruoli e autorizzazioni vSphere può essere utilizzato nello stesso modo in cui si è abituati a sfruttare gli altri ambienti VMware Engine. Tuttavia, attività come il deployment di un cluster richiedono le autorizzazioni in Identity and Access Management (IAM). La seguente tabella elenca i gestori degli accessi pertinenti, le origini identità a cui vengono concesse le autorizzazioni e le attività di esempio che attivano.
| Piattaforma | Componente | Origine identità | Dove configurare le autorizzazioni | Attività di esempio |
|---|---|---|---|---|
| Google Cloud | Portale VMware Engine | Cloud Identity | Identity and Access Management | Ad esempio, deployment e annullamento del cloud privato, deployment e annullamento dei cluster. |
| VMware Engine | vCenter | LDAP | Host e cluster, VM e cartelle, datastore nella UI di vCenter | Creazione di VM, creazione di cartelle di VM, creazione ed eliminazione di oggetti Datastore, ad esempio |
| NSX-T | LDAP | "Utenti e ruoli" nell'interfaccia utente di NSX-T Manager | creazione di segmenti NSX, configurazione del firewall o configurazione del bilanciatore del carico, ad esempio. | |
| vCenter | Sistema operativo guest VM | Active Directory, LDAP, Utenti locali, ad esempio | Sistema operativo ospite | Accesso SSH o RDP, per le operazioni sui file, ad esempio |
In Google Cloud IAM sono disponibili due ruoli predefiniti con autorizzazioni per il portale VMware Engine:
- Amministratore servizi VMware Engine: dà accesso completo al servizio VMware Engine su Google Cloud.
- Visualizzatore servizi VMware Engine: fornisce accesso di sola lettura al servizio VMware Engine su Google Cloud.
Queste autorizzazioni sono relative alle azioni nel portale VMware Engine e non alle azioni nell'API o nell'interfaccia a riga di comando. Tieni presente che anche i ruoli di base includono la possibilità di gestire il servizio VMware Engine (Proprietario, Editor) o di visualizzare i dettagli del servizio (Visualizzatore). In genere, si consiglia di utilizzare ruoli predefiniti anziché ruoli di base, poiché offrono autorizzazioni più granulari.
L'accesso programmatico a VMware Engine tramite account di servizio che utilizzano l'API o l'interfaccia a riga di comando dovrebbe essere limitato tramite ruoli predefiniti o personalizzati perché includono autorizzazioni più granulari che si applicano solo a VMware Engine. Se l'accesso programmatico viene utilizzato solo per un'attività che richiede solo un sottoinsieme specifico delle autorizzazioni dei ruoli predefiniti, consigliamo di creare un ruolo personalizzato.
Scegliere una posizione appropriata per l'assegnazione del ruolo IAM nella gerarchia delle risorse dell'organizzazione. Se esegui tutti i cloud privati di VMware Engine in un solo progetto, è possibile assegnare solo i ruoli a livello di progetto. Se sussistono requisiti tecnici o organizzativi che implicano che i cloud privati si trovano in progetti separati, definisci i ruoli richiesti in una cartella comune ai progetti utilizzati per i tuoi cloud privati.
Le autorizzazioni Cloud IAM non sono necessarie per le attività che devono essere eseguite solo all'interno di vCenter, NSX-T o HCX. Il personale che deve solo utilizzare questi ambienti non richiede i ruoli IAM precedentemente elencati. Devono invece utilizzare identità LDAP con autorizzazioni configurate in vCenter e NSX-T. Consigliamo di assegnare i ruoli Amministratore servizi VMware Engine o Visualizzatore servizio VMware Engine solo a un numero molto limitato di utenti poiché questi ruoli concedono l'accesso al potente account utente CloudOwner per vCenter e all'account utente amministratore per NSX-T. Questi account utente devono essere utilizzati solo per la configurazione iniziale o per le procedure di emergenza.
Limitare e controllare attivamente l'accesso degli amministratori
Il ruolo Amministratore servizi VMware Engine è molto potente e deve essere assegnato solo agli utenti che devono gestire il ciclo di vita del cloud privato VMware Engine e dei relativi cluster. In genere, l'aggiunta o l'eliminazione manuale di cluster e nodi è un'azione che non si verifica di frequente e può avere un impatto elevato sulla fatturazione o sulla disponibilità del cluster. Assegna questo ruolo solo a pochissime persone nella tua organizzazione.
Assicurati di controllare regolarmente a chi è stato assegnato il ruolo Amministratore servizi VMware Engine, direttamente nel progetto utilizzato per VMware Engine o su uno dei livelli padre della gerarchia delle risorse. Questo controllo dovrebbe includere altri ruoli, come i ruoli Editor di base e Proprietario che includono autorizzazioni critiche relative a VMware Engine. Puoi usare servizi come il motore per suggerimenti sui ruoli IAM per identificare i ruoli con privilegi eccessivi.
Configura un'origine identità LDAP o Active Directory
Un provider di identità che supporta l'autenticazione LDAP, come Active Directory, deve essere configurato per abilitare l'autenticazione utente per vCenter e NSX Manager. Si consiglia di disporre di una gestione centralizzata del ciclo di vita delle identità, della gestione dei gruppi, della gestione delle password e altro ancora. Tieni presente che l'unione diretta di vCenter e NSX-T ad Active Directory per l'autenticazione integrata di Windows non è supportata.
Ruotare le password degli account di servizio integrati
VMware Engine genera le credenziali per accedere alle appliance di gestione nel cloud privato (ad esempio vCenter, NSX-T e HCX). È consigliabile stabilire un processo per la rotazione delle password dell'account di servizio vCenter predefinito CloudOwner@gve.local e dell'amministratore dell'account di servizio NSX-T predefinito. Entrambi gli account utente devono essere utilizzati solo per la configurazione iniziale e le procedure di emergenza e le relative password devono essere ruotate regolarmente (ad esempio ogni 60 o 90 giorni). In modo equivalente, ruota regolarmente le password degli account utente della soluzione, comunemente utilizzate per l'integrazione di strumenti di terze parti. Più spesso ruoti le password degli account di servizio, meno è probabile che la password sia ancora valida quando un malintenzionato la trova.
Logging e monitoraggio di VMware Engine
Le seguenti sezioni introducono le best practice per il logging e il monitoraggio dei carichi di lavoro delle VM e dell'infrastruttura VMware Engine, che fornisce le risorse utilizzate dai carichi di lavoro.
Importa log e metriche di VMware Engine
Molte organizzazioni desiderano raccogliere e analizzare i log in un "unico piano di vetro" centralizzato. In Google Cloud, i prodotti Cloud Logging e Cloud Monitoring forniscono servizi che possono essere utilizzati per la gestione centralizzata di log e metriche. VMware Engine può essere integrato con Cloud Monitoring utilizzando un agente autonomo. In questa configurazione, vCenter inoltra metriche come l'utilizzo di CPU e memoria ESXi a Cloud Monitoring. È consigliabile creare dashboard basate sulle metriche inoltrate da vCenter o per iniziare con alcune dashboard di esempio pubblicate su GitHub.
Per raccogliere i log della piattaforma, i cloud privati di VMware Engine possono inoltrare i log Syslog a un aggregatore di log centralizzato. Questa operazione può essere eseguita sia per i messaggi vCenter sia per NSX-T Syslog. La raccolta, la conservazione e l'analisi dei messaggi Syslog da vCenter comprende importanti casi d'uso per la sicurezza, come gli avvisi in tempo reale basati sugli accessi di utenti amministrativi (o di emergenza), che devono essere eseguiti solo in circostanze eccezionali. Per analizzare i messaggi Syslog, è necessario configurare un aggregatore Syslog come Fluentd o l'agente autonomo in modo da reindirizzare i messaggi a Cloud Logging.
È consigliabile analizzare i log di VMware Engine in una dashboard centrale in un singolo progetto. Se il tuo ambiente VMware Engine comprende più progetti, dovrai anche aggregare i progetti configurando i sink di log e gli ambiti di monitoraggio.
Utilizza l'agente Cloud Logging per il logging delle VM dei carichi di lavoro
Le VM dei carichi di lavoro di VMware Engine possono inviare i log direttamente all'API Cloud Logging utilizzando l'agente Logging. L'agente Logging si basa su log scorrevole e trasmette log da applicazioni e software di sistema di terze parti comuni a Cloud Logging. Come best practice, allinea l'approccio per la raccolta e l'analisi dei log per le VM dei carichi di lavoro su VMware Engine all'approccio per le istanze di Compute Engine e la tua proprietà on-premise (se applicabile). L'utilizzo dell'agente Logging su VMware Engine corrisponde all'approccio utilizzato per le VM su Compute Engine in modo che i carichi di lavoro su entrambe le piattaforme inviino i propri log a Cloud Logging.
Applicare le funzionalità equivalenti dei criteri di Access Transparency e Access Approval
Sebbene VMware Engine non supporti Access Transparency (AxT) e Access Approval (AxA) in Google Cloud, abbiamo implementato processi con funzionalità equivalenti che possono essere abilitate su richiesta.
Per l'equivalenza alla trasparenza degli accessi, devi considerare diverse origini dei log, tra cui:
- Log vCenter: esportabili utilizzando la configurazione del server syslog remoto.
- Log ESXi: possono essere raccolti utilizzando la configurazione syslog remota. Tuttavia, per configurare l'inoltro syslog ESXi, devi inviare una richiesta di assistenza a Google Cloud.
Se hai requisiti normativi rigorosi, implementiamo un criterio per fornire capacità equivalenti per l'approvazione dell'accesso. In questo criterio, le operazioni di servizio standard richiedono la generazione di un ticket di assistenza con un motivo per cui gli operatori dei servizi di accesso richiedono l'accesso.
Si applicano le esclusioni di Google Cloud Access Approval.
Crittografia di VMware Engine
Le seguenti sezioni introducono le best practice per la crittografia dello spazio di archiviazione nel cloud privato e i fattori determinanti da considerare nella scelta di un provider di chiavi per il tuo cloud privato.
Utilizza un provider di chiavi gestito da Google abilitato per la crittografia vSAN at-rest
La crittografia dei dati at-rest viene implementata utilizzando la crittografia basata su software vSAN. Per impostazione predefinita, VMware Engine abilita la crittografia vSAN su ogni cluster ESXi e configura un provider di chiavi predefinito in vCenter. Google richiede ai clienti di mantenere abilitata la crittografia vSAN sui propri cluster ESXi e la disattivazione della crittografia vSAN costituisce una violazione dei termini di servizio per VMware Engine. Molte organizzazioni richiedono la crittografia at-rest come parte dei propri criteri aziendali o sono obbligate da normative a criptare i dati (ad esempio, NIST, FIPS).
Ogni host ESXi cripta i dati utilizzando la modalità XTS AES-256 standard con diverse chiavi di crittografia dei dati (DEK) generate in modo casuale. La DEK è criptata con una chiave di crittografia della chiave (KEK) e archiviata sul disco solo in formato criptato. Il server vCenter archivia solo l'ID della KEK ma non la KEK stessa, che è archiviata in un Cloud Key Management Service (KMS). Puoi scegliere la località di Cloud KMS in cui si trova la KEK.
Ti consigliamo di utilizzare il provider di chiavi predefinito gestito da Google. Se, tuttavia, hai l'obbligo di gestire Cloud KMS autonomamente, puoi utilizzare un Cloud KMS di terze parti conforme allo standard KMIP 1.1 e da uno dei fornitori supportati. In entrambi i casi, il provider della chiave può essere utilizzato per criptare i dati at-rest e il traffico vMotion in transito.
La seguente tabella evidenzia le principali differenze tra le integrazioni del provider di chiavi predefinito e di Cloud KMS di terze parti:
| Provider di chiavi | Vantaggi | Svantaggi |
|---|---|---|
| Provider di chiavi gestito da Google predefinito |
|
|
| Provider di chiavi Cloud KMS di terze parti |
|
|
Tieni presente che non è consigliabile abilitare la crittografia a livello di VM insieme alla crittografia del datastore vSAN perché l'efficienza della deduplicazione si avvicina a zero per le VM criptate.
Automatizza la rotazione delle chiavi di crittografia in base agli standard della tua organizzazione
Sei responsabile della rotazione KEK utilizzando vSphere VMware Engine. Questo avviene sia con il provider di chiavi predefinito sia con un provider di chiavi Cloud KMS esterno. La rotazione KEK può essere avviata da vCenter o utilizzando la sua API. Valuta la possibilità di automatizzare la rotazione della KEK in base ai requisiti della tua organizzazione. Puoi trovare uno script PowerCLI di esempio su GitHub.
Backup e ripristino di emergenza di VMware Engine
È importante proteggere i dati da minacce come ransomware, corruzione ed errori umani. Inoltre, le applicazioni business-critical si basano sulla disponibilità dei dati praticamente sempre, lasciando poco tempo per recuperare i dati da improvvise interruzioni. Questa sezione non contiene una copertura completa di tutti gli aspetti di backup e ripristino di emergenza rilevanti per progettare in modo efficace una strategia di backup e RE per mantenere i dati sicuri e disponibili, ma contiene le considerazioni chiave per scegliere la strategia giusta per il tuo ambiente VMware Engine.
Esegui il backup dei carichi di lavoro utilizzando il servizio di backup e RE
Con il servizio di backup e RE, Google Cloud offre una soluzione di backup integrata e gestita centralmente che può essere utilizzata per diversi casi d'uso, incluso il backup dei carichi di lavoro su Compute Engine e Google Cloud VMware Engine. Il servizio di backup e RE è la soluzione unica consigliata da Google per i backup dei carichi di lavoro, in quanto offre vantaggi come un ampio spettro di supporto dei carichi di lavoro, backup efficienti in termini di spazio, backup incrementali senza limiti e opzioni di archiviazione flessibili.
Google Cloud VMware Engine supporta inoltre l'uso di soluzioni di backup basate su agente di terze parti. Se hai già licenze per un prodotto di backup di terze parti, sei in possesso di licenze di backup. I prerequisiti per questo tipo di strumenti includono:
- Forniscono backup a livello di applicazione
- Sono certificati dai fornitori delle applicazioni
- Sono certificati da VMware Engine per vSAN
- Supportano lo standard di protocollo VMware Engine vStorage API for Data Protection (VADP) o eseguono backup a livello di applicazione
Indipendentemente dalla soluzione di backup che scegli, consigliamo Cloud Storage come opzione di archiviazione economica per la conservazione a lungo termine dei backup. Cloud Storage è uno spazio di archiviazione di oggetti a elevata durabilità e dai costi contenuti. I bucket Cloud Storage possono essere configurati per replicare automaticamente gli oggetti di archiviazione in più regioni, ideale per le topologie Cloud multiregionali.
Cloud Storage è ideale anche per l'archiviazione a lungo termine, in quanto fornisce criteri del ciclo di vita per spostare automaticamente gli oggetti di archiviazione in un altro livello di archiviazione quando la loro durata supera un valore predefinito. Utilizza questa opzione per una posizione di archiviazione di backup economica e per RPO medio-alti, soprattutto se il costo è un fattore determinante.
In alternativa, puoi scegliere l'archiviazione vSAN per ridurre al minimo l'RPO. Utilizza questa opzione di archiviazione se è accettabile un costo più elevato per l'archiviazione di backup e se non è possibile soddisfare i requisiti dell'RPO con Cloud Storage. Evita questa opzione per l'archiviazione a lungo termine, poiché esiste il rischio che le dimensioni dei cluster VMware Engine diventino vincolate allo spazio di archiviazione.
Implementa il ripristino di emergenza con il servizio di backup e RE
Ti consigliamo di ripristinare le applicazioni su VMware Engine utilizzando il servizio di backup e RE. Per proteggere i carichi di lavoro di produzione dalle interruzioni di una singola zona all'interno di una regione, ti consigliamo di eseguire il deployment e di gestire un cloud privato in una zona secondaria all'interno della regione se VMware Engine è disponibile in più di una zona di quella regione. In caso contrario, ti consigliamo di ripristinare le applicazioni in una regione secondaria.
Oltre a Backup e RE di Google Cloud, VMware Engine è compatibile con altre opzioni di RE, come VMware Engine SRM e Zerto. Sia VMware Engine SRM che Zerto si basano sulla replica vSphere per il ripristino di emergenza, che in genere supporta target RPO più bassi. Se il target dell'RPO è in minuti anziché in ore, valuta le soluzioni di RE basate sulla replica vSphere.
Riepilogo elenco di controllo
Il seguente elenco di controllo riassume le best practice di sicurezza per l'utilizzo di VMware Engine.
| Attività | Argomento |
|---|---|
| Networking di VMware Engine |
|
| IAM e autorizzazioni di VMware Engine | |
| Logging e monitoraggio di VMware Engine | |
| Crittografia di VMware Engine | |
| Backup e ripristino di emergenza di VMware Engine |
Passaggi successivi
- Prova Google Cloud VMware Engine. Per ulteriori informazioni, visita la pagina relativa a funzionalità, vantaggi e casi d'uso.
- Scopri i concetti di sicurezza di VMware Engine.
- Esplora le architetture di riferimento, i diagrammi, i tutorial e le best practice su Google Cloud. Per ulteriori informazioni, visita il Cloud Architecture Center.