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 è rivolto agli utenti che hanno già dimestichezza con VMware Engine. Se sei un principiante, ti consigliamo di iniziare con le informazioni sui prerequisiti e sulla sicurezza di VMware Engine.
VMware Engine ha un modello di responsabilità condivisa per la sicurezza. La sicurezza attendibile nel cloud si ottiene tramite le responsabilità condivise dei clienti e di Google in qualità di fornitore di servizi. Seguire queste best practice può aiutarti a risparmiare tempo, evitare errori e mitigare gli effetti degli eventuali punti di défaillance.
Networking di VMware Engine
Le sezioni seguenti illustrano le best practice per la rete in un ambiente VMware Engine.
Identificare e comprendere tutti i flussi di traffico del tuo ambiente
VMware Engine utilizza le reti VMware Engine e i peering VPC per collegare una connessione di rete privata da una rete cloud privato VMware Engine alla tua rete VPC. Il traffico in entrata da un VPC nel tuo ambiente Google Cloud o da una rete on-premise attraversa una rete dell'unità di tenancy gestita da Google.
Utilizzare il servizio IP pubblico di VMware Engine per il trasferimento di dati su internet
Il traffico internet può entrare in un cloud privato direttamente 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 indirizzato come qualsiasi altro traffico in entrata. Tieni presente che queste opzioni sono mutuamente esclusive. Se sono necessari controlli personalizzati per il traffico internet, come il filtro degli URL, IPS/IDS o l'ispezione del traffico fornita da un'istanza o un servizio centrali nel tuo ambiente Google Cloud, devi instradare il traffico diretto a internet tramite la rete VPC.
Se questo non è il tuo caso o se hai implementato i controlli nel tuo cloud privato, ti consigliamo di includere il servizio di indirizzo IP esterno in VMware Engine. Inoltre, ti consigliamo di utilizzare regole di accesso esterno per negare i pattern di traffico provenienti da internet che non si applicano alle tue applicazioni.
Regole firewall separate nord-sud ed est-ovest sul gateway e sul 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 virtuali di livello 2. NSX DFW è progettato per gestire il traffico di rete east-west (interno) tra i segmenti e consente regole firewall che consentono e negano il traffico tra singole istanze all'interno di un segmento.
Per il controllo granulare dell'accesso alla rete, assicurati di applicare un criterio predefinito limitato al firewall di dominio per negare per impostazione predefinita il traffico di rete tra le istanze. Utilizza il DFW per consentire specificamente il traffico tra le applicazioni e tra i servizi all'interno della tua applicazione.
Configura il firewall del gateway NSX per controllare il traffico nord-sud che entra e esce dal cloud privato.
Il firewall del gateway NSX è progettato per controllare il traffico nord-sud ed è 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 nord-sud per l'intero cloud privato, configura la firewall del gateway sul router di primo livello. Se devi configurare il traffico nord-sud per ogni singolo segmento NSX-T, configura il firewall del gateway sul router di primo livello.
Oltre ai firewall NSX-T, è consigliabile utilizzare il firewall VPC per consentire e bloccare il traffico est-ovest tra i carichi di lavoro nel cloud privato VMware Engine e i carichi di lavoro nelle VPC. Il trasferimento di dati in entrata alle istanze Compute Engine dai workload VMware Engine deve essere limitato per impostazione predefinita solo al traffico aperto consapevolmente.
Il trasferimento di dati in uscita alle appliance di gestione e all'intervallo CIDR di vSphere/vSAN deve essere bloccato anche dalle VPC utilizzando il firewall VPC. Apri solo il trasferimento di dati in uscita verso le appliance di gestione da host e indirizzi IP attendibili all'interno della tua rete. È importante notare che gli appliance di gestione non si trovano all'interno di un segmento NSX-T e, pertanto, le regole DFW non si applicano per limitare l'accesso.
Applica i principi di sicurezza Zero Trust e la microsegmentazione in NSX-T
Utilizza il firewall NSX-T per implementare controlli del traffico per segmenti di sicurezza granulari come le singole macchine virtuali. Questo principio di protezione del traffico tra singole VM che viene negato per impostazione predefinita è spesso indicato anche come "microsegmentazione", che è un approccio più granulare per i firewall rispetto all'implementazione convenzionale di firewall tra domini di livello 3.
Il DFW è abilitato nel kernel dell'hypervisor su tutti gli host vSphere di VMware Engine nel tuo cloud privato e può controllare il flusso di traffico tra i carichi di lavoro nello stesso segmento NSX o in segmenti 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 del tag o del nome della VM.
La micro-segmentazione ti consente di implementare una rete con un 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 procedure di verifica dell'identità e del dispositivo anziché dall'attendibilità implicita è spesso chiamato anche sicurezza Zero Trust.
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 a 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. L'appliance di terze parti può essere implementata 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'analisi approfondita delle architetture di VMware Engine con appliance centralizzate, che possono essere utilizzate per una serie di casi d'uso avanzati di sicurezza, come IPS/IDS, DDoS, offload SSL e altro ancora, consulta il documento Sicurezza di rete con appliance centralizzate nel Cloud Architecture Center.
Utilizzare Google Cloud Armor per proteggere i servizi web su VMware Engine dagli attacchi DDoS
Se inoltri il traffico in entrata ai carichi di lavoro su VMware Engine tramite la VPC del cliente, ti consigliamo di posizionare i carichi di lavoro di VMware Engine in gruppi di endpoint di rete ibrida dietro Cloud Service Mesh e di utilizzare il bilanciatore del carico HTTP(S) esterno. Entrambe le configurazioni ti consentono di includere Google Cloud Armor per le applicazioni rivolte al pubblico, mitigando gli attacchi DDoS e le vulnerabilità comuni come SQL injection o cross-site scripting.
Se hai bisogno di funzionalità di Service Mesh come la gestione avanzata del traffico tramite il proxy Envoy o l'integrazione di Certificate Authority Service, ti consigliamo Cloud Service Mesh. In tutti gli altri casi, consigliamo il bilanciatore del carico HTTP(S) esterno.
Segui la documentazione su come aggiungere i carichi di lavoro di VMware Engine ai gruppi di elenchi di negazioni ibridi in una delle seguenti configurazioni:
- Bilanciamento del carico HTTP(S) esterno regionale con connettività ibrida
- Bilanciatore del carico HTTP(S) esterno globale con connettività ibrida
Connettiti ai servizi Google Cloud in modo privato senza accesso a internet
I carichi di lavoro del cloud privato VMware Engine possono accedere alle API Google Cloud come l'API Cloud Storage utilizzando l'accesso privato Google. Ti consigliamo di utilizzare accesso privato Google per accedere ai servizi Google senza inviare traffico su internet, in quanto riduce il costo e la latenza del trasferimento dati in uscita. Inoltre, viene eliminata la necessità di un percorso di rete per internet per i workload che richiedono solo accesso alle API Google. Per maggiori dettagli tecnici e passaggi di configurazione, consulta l'approfondimento sull'accesso privato Google.
Analogamente, i carichi di lavoro di VMware Engine che devono accedere alle risorse Google Cloud da una rete di producer di servizi, come le istanze Cloud SQL o Memorystore, devono connettersi in privato utilizzando PSA. Per ulteriori informazioni, consulta la sezione sul PSA per VMware Engine.
Crittografa la comunicazione tra il tuo ambiente on-premise e Google Cloud
I carichi di lavoro su VMware Engine che devono comunicare con i sistemi on-premise devono connettersi tramite un canale criptato. Consigliamo un approccio stratificato per la crittografia in transito tra i 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 o utilizzando IPsec integrato sui collegamenti VLAN dell'interconnessione. Inoltre, la crittografia a livello di applicazione deve essere abilitata tra i componenti dell'applicazione che utilizzano TLS.
Proteggi i dati dall'esfiltrazione utilizzando i Controlli di servizio VPC
Ti consigliamo di mitigare i rischi di esfiltrazione di dati utilizzando i Controlli di servizio VPC collocando le 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 nel perimetro. Nello specifico, il progetto Google Cloud che ospita il cloud privato deve far parte del perimetro di Controlli di servizio VPC per accedere alle risorse protette da Controlli di servizio VPC.
Devi configurare i criteri di trasferimento dei dati in entrata e in uscita nella configurazione di Controlli di servizio VPC per consentire alle API di servizio dei produttori di VMware Engine di accedere al perimetro. Per indicazioni dettagliate sulla configurazione, consulta le nostre pagine di documentazione su Controlli di servizio VPC con VMware Engine.
IAM e autorizzazioni di VMware Engine
Le sezioni seguenti illustrano le best practice per le autorizzazioni utente in un ambiente VMware Engine. È importante occuparsi delle autorizzazioni all'interno dell'ambiente VMware Engine e del progetto Google Cloud in cui viene eseguito il deployment del cloud privato.
Utilizzare ruoli predefiniti o personalizzati per concedere l'accesso
L'approccio di VMware Engine per gestire i ruoli e le autorizzazioni vSphere può essere utilizzato nello stesso modo in cui lo utilizzi in altri ambienti VMware Engine. Tuttavia, attività come il deployment di un cluster richiedono autorizzazioni in Identity and Access Management (IAM). La tabella seguente elenca i gestori dell'accesso pertinenti, le origini dell'identità a cui concedono le autorizzazioni e alcuni esempi di attività 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, il deployment e l'annullamento del cloud privato, il deployment e l'annullamento del cluster. |
| VMware Engine | vCenter | LDAP | Host e cluster, VM e cartelle, datastore nell'interfaccia utente di vCenter | Creazione di VM, creazione di cartelle VM, creazione ed eliminazione di oggetti datastore e così via |
| NSX-T | LDAP | "Utenti e ruoli" nell'interfaccia utente di NSX-T Manager | Creazione di segmenti NSX, configurazione del firewall, configurazione del bilanciatore del carico e così via. | |
| vCenter | Sistema operativo guest della VM | Ad esempio, Active Directory, LDAP, utenti locali | Sistema operativo guest | Accesso SSH o RDP, operazioni sui file e così via |
In Google Cloud IAM sono disponibili due ruoli predefiniti con autorizzazioni per il portale VMware Engine:
- VMware Engine Service Admin: consente l'accesso completo al servizio VMware Engine su Google Cloud.
- VMware Engine Service Viewer: consente l'accesso di sola lettura al servizio VMware Engine su Google Cloud.
Queste autorizzazioni si riferiscono alle azioni nel portale VMware Engine e non alle azioni nell'API o nella CLI. 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 i ruoli predefiniti anziché quelli di base perché forniscono autorizzazioni più granulari.
L'accesso programmatico a VMware Engine tramite account di servizio che utilizzano l'API o la CLI deve essere limitato utilizzando 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, è consigliabile creare un ruolo personalizzato.
Scegli una posizione appropriata per l'assegnazione del ruolo IAM nella gerarchia delle risorse della tua organizzazione. Se esegui tutti i tuoi cloud privati VMware Engine in un unico progetto, i ruoli possono essere assegnati solo a livello di progetto. Se esistono requisiti tecnici o organizzativi che comportano la collocazione dei cloud privati in progetti distinti, definisci i ruoli richiesti in una cartella comune ai progetti utilizzati per i 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 elencati in precedenza. Dovrebbero invece utilizzare le identità LDAP con le autorizzazioni configurate in vCenter e NSX-T. Ti consigliamo di fornire i ruoli VMware Engine Service Admin o VMware Engine Service Viewer solo a un numero molto limitato di utenti, poiché questi ruoli consentono di accedere all'account utente CloudOwner per vCenter e all'account utente amministratore per NSX-T. Questi account dell'utente devono essere utilizzati solo per la configurazione iniziale o le procedure di emergenza.
Limitare e controllare attivamente l'accesso degli amministratori
Il ruolo Amministratore servizio 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 spesso e può avere un impatto elevato sulla fatturazione o sulla disponibilità del cluster. Assegna questo ruolo solo a pochissime persone della tua organizzazione.
Assicurati di controllare regolarmente a chi è stato assegnato il ruolo Amministratore servizio VMware Engine, direttamente nel progetto utilizzato per VMware Engine o in uno dei livelli principali della gerarchia delle risorse. Questo controllo deve includere altri ruoli, come i ruoli di base Editor e Proprietario che includono autorizzazioni critiche relative a VMware Engine. Puoi utilizzare servizi come il motore per suggerimenti dei ruoli IAM per identificare i ruoli eccessivamente privilegiati.
Configurare un'origine identità LDAP o Active Directory
Per attivare l'autenticazione degli utenti per vCenter e NSX Manager, deve essere configurato un provider di identità che supporti l'autenticazione LDAP, ad esempio Active Directory. Si tratta di una best practice per avere 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 Windows integrata non è supportata.
Ruotare le password degli account di servizio integrati
VMware Engine genera le credenziali per accedere alle appliance di gestione nel cloud privato (come vCenter, NSX-T e HCX). Ti consigliamo di stabilire una procedura per ruotare le 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 alternativa, ruota regolarmente le password degli account utente della soluzione che vengono comunemente utilizzati 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 sezioni seguenti illustrano le best practice per la registrazione e il monitoraggio sia dei workload VM sia dell'infrastruttura VMware Engine, che fornisce le risorse consumate dai workload.
Importa i log e le metriche di VMware Engine
Molte organizzazioni vogliono raccogliere e analizzare i log in un "pannello di vetro unico" 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 le metriche come l'utilizzo della CPU e della memoria di ESXi a Cloud Monitoring. Ti consigliamo di creare dashboard in base alle metriche inoltrate da vCenter o di iniziare con alcune dashboard di esempio pubblicate su GitHub.
Per raccogliere i log della piattaforma, i cloud privati VMware Engine possono inoltrare i log syslog a un aggregatore di log centralizzato. Questa operazione può essere eseguita sia per i messaggi Syslog di vCenter sia per quelli di NSX-T. La raccolta, la conservazione e l'analisi dei messaggi Syslog da vCenter hanno importanti casi d'uso per la sicurezza, come gli avvisi in tempo reale basati su gli accessi degli utenti amministrativi (o degli utenti 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 per inoltrare i messaggi a Cloud Logging.
Ti consigliamo di analizzare i log di VMware Engine in una dashboard centralizzata in un singolo progetto. Se il tuo ambiente VMware Engine copre più progetti, dovrai anche aggregarli configurando i canali di log e gli ambiti di monitoraggio.
Utilizzare l'agente Cloud Logging per il logging delle VM del carico di lavoro
Le VM dei carichi di lavoro VMware Engine possono inviare i log direttamente all'API Cloud Logging utilizzando l'agente Logging. L'agente Logging si basa su fluentd e trasmette i log da applicazioni di terze parti e software di sistema comuni a Cloud Logging. Come best practice, allinea l'approccio per la raccolta e l'analisi dei log per le VM di workload su VMware Engine con l'approccio per le istanze 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 funzionalità equivalenti dei criteri Access Transparency e Access Approval
Sebbene VMware Engine non supporti la trasparenza dell'accesso (AxT) e l'approvazione dell'accesso (AxA) in Google Cloud, abbiamo implementato processi con funzionalità equivalenti che possono essere attivati su richiesta.
Per l'equivalenza di Access Transparency devi prendere in considerazione diverse fonti di log, tra cui:
- Log di vCenter: esportabili utilizzando la configurazione del server syslog remoto.
- Log ESXi: possono essere raccolti utilizzando la configurazione syslog remota, tuttavia devi inviare una richiesta di assistenza a Google Cloud per configurare l'inoltro syslog di ESXi.
Se hai requisiti normativi rigidi, implementiamo un criterio per fornire funzionalità equivalenti per l'approvazione dell'accesso. In queste norme, le operazioni di servizio standard richiedono la generazione di un ticket di assistenza con il motivo per cui gli operatori del servizio di accesso richiedono l'accesso.
Si applicano le esclusioni dell'approvazione dell'accesso a Google Cloud.
Crittografia VMware Engine
Le sezioni seguenti illustrano le best practice per la crittografia dello spazio di archiviazione nel cloud privato e i fattori principali da considerare quando scegli un fornitore di chiavi per il tuo cloud privato.
Utilizza un provider di chiavi gestito da Google abilitato per la crittografia at-rest di vSAN
La crittografia dei dati at-rest viene implementata utilizzando la crittografia basata su software vSAN. Per impostazione predefinita, VMware Engine attiva 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 rappresenta una violazione dei termini di servizio di VMware Engine. Molte organizzazioni richiedono la crittografia at-rest nell'ambito delle proprie norme aziendali o sono obbligate dalle 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 viene criptata utilizzando una chiave di crittografia della chiave (KEK) e viene archiviata sul disco solo in forma criptata. Il server vCenter archivia solo l'ID della KEK, ma non la KEK stessa, che è archiviata in un servizio Cloud Key Management Service (KMS). Puoi scegliere la posizione di Cloud KMS in cui viene conservata la tua KEK.
Ti consigliamo di utilizzare il provider di chiavi predefinito gestito da Google. Tuttavia, se devi gestire autonomamente Cloud KMS, puoi utilizzare un Cloud KMS conforme a KMIP 1.1 di terze parti di uno dei fornitori supportati. In entrambi i casi, il fornitore di chiavi può essere utilizzato per criptare i dati at-rest e il traffico vMotion in transito.
La seguente tabella evidenzia le principali differenze tra il provider di chiavi predefinito e le integrazioni Cloud KMS di terze parti:
| Fornitore di chiavi | Vantaggi | Svantaggi |
|---|---|---|
| Provider di chiavi gestite da Google predefinito |
|
|
| Fornitore di chiavi Cloud KMS di terze parti |
|
|
Tieni presente che non è consigliabile attivare la crittografia a livello di VM insieme alla crittografia del datastore vSAN perché l'efficienza della deduplica si avvicina allo zero per le VM criptate.
Automatizza la rotazione delle chiavi di crittografia in base agli standard della tua organizzazione
La rotazione della KEK è a tuo carico se utilizzi VMware Engine vSphere. Questo accade sia con il fornitore di chiavi predefinito sia con un Cloud KMS esterno. La rotazione del KEK può essere avviata da vCenter o utilizzando la relativa API. Valuta la possibilità di automatizzare la rotazione del KEK in base alle esigenze della tua organizzazione. Puoi trovare un esempio di script PowerCLI su GitHub.
Backup e ripristino di emergenza di VMware Engine
È importante proteggere i dati da minacce come ransomware, danneggiamenti e errori umani. Inoltre, le applicazioni business-critical si basano sul fatto che i dati siano disponibili praticamente in qualsiasi momento, lasciandoti poco tempo per recuperarli in caso di interruzioni improvvise. Questa sezione non contiene una copertura completa di tutti gli aspetti di backup e ripristino di emergenza pertinenti per progettare in modo efficace una strategia di backup e RE per mantenere i dati sicuri e disponibili, ma contiene considerazioni chiave per scegliere la strategia giusta per il tuo ambiente VMware Engine.
Esegui il backup dei tuoi carichi di lavoro utilizzando il servizio di backup e RE
Con il servizio di backup e DR, Google Cloud offre una soluzione di backup integrata e gestita centralmente che può essere utilizzata per una serie di casi d'uso, tra cui il backup dei carichi di lavoro su Compute Engine e Google Cloud VMware Engine. Il servizio di backup e RE è la soluzione singola consigliata da Google per i backup dei carichi di lavoro, in quanto offre vantaggi quali un ampio spettro di supporto dei carichi di lavoro, backup incrementali permanenti che consentono di risparmiare spazio e opzioni di archiviazione flessibili.
Google Cloud VMware Engine supporta anche l'utilizzo di soluzioni di backup basate su agenti di terze parti. Potresti preferire queste opzioni se hai già licenze per un prodotto di backup di terze parti. I prerequisiti per questi tipi di strumenti includono quanto segue:
- Forniscono backup a livello di applicazione
- Sono certificati dai fornitori di applicazioni
- Sono certificati da VMware Engine per vSAN
- Supportano lo standard del protocollo API vStorage di VMware Engine per la protezione dei dati (VADP) o eseguono backup a livello di applicazione
Indipendentemente dalla soluzione di backup scelta, consigliamo Cloud Storage come opzione di archiviazione economica per la conservazione a lungo termine dei backup. Cloud Storage è uno spazio di archiviazione di oggetti altamente duraturo e conveniente. I bucket Cloud Storage possono essere configurati per replicare automaticamente gli oggetti di archiviazione su più regioni, il che è ideale per le topologie Cloud multiregionali.
Cloud Storage è ideale anche per l'archiviazione a lungo termine, in quanto fornisce criteri di ciclo di vita per spostare automaticamente gli oggetti di archiviazione in un altro livello di archiviazione una volta che la loro durata supera un valore predefinito. Utilizza questa opzione per una posizione di archiviazione del backup conveniente e per RPO medio-alti, soprattutto se il costo è un fattore determinante.
In alternativa, puoi scegliere lo spazio di archiviazione vSAN per ridurre al minimo il RPO. Utilizza questa opzione di archiviazione se un costo più elevato per l'archiviazione di backup è accettabile e i requisiti RPO non possono essere soddisfatti con Cloud Storage. Evita questa opzione per l'archiviazione a lungo termine, poiché esiste il rischio che le dimensioni del cluster VMware Engine diventino vincolate allo spazio di archiviazione.
Implementare 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 workload di produzione dalle interruzioni di una singola zona all'interno di una regione, è consigliabile implementare e gestire un cloud privato in una zona secondaria all'interno della regione se VMware Engine è disponibile in più di una zona della regione. In caso contrario, ti consigliamo di ripristinare le applicazioni in una regione secondaria.
Oltre a Google Cloud Backup e DR, VMware Engine è compatibile con altre opzioni per la 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 obiettivi RPO inferiori. Se il tuo RPO target è 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 per la 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 VMware Engine | |
| Backup e ripristino di emergenza di VMware Engine |
Passaggi successivi
- Prova Google Cloud VMware Engine. Per ulteriori informazioni, consulta funzionalità, vantaggi e casi d'uso.
- Scopri di più sui concetti di sicurezza di VMware Engine.
- Scopri architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Per ulteriori informazioni, visita il Cloud Architecture Center.