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 conoscono già VMware Engine. Se sei alle prime armi, ti consigliamo di iniziare a conoscere i prerequisiti e la sicurezza di VMware Engine.
VMware Engine ha un modello di responsabilità condivisa per la sicurezza. La sicurezza affidabile nel cloud si ottiene attraverso le responsabilità condivise dei clienti e di Google in qualità di fornitore di servizi. Seguire queste best practice può aiutarti a risparmiare tempo, a evitare errori e a mitigare gli effetti dei punti di errore.
Networking VMware Engine
Le sezioni seguenti introducono le best practice per il networking 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 connettere 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 ambienteGoogle 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 su internet
Il traffico internet può accedere direttamente a 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 necessari controlli personalizzati per il traffico internet, come il filtro URL, IPS/IDS o l'ispezione del traffico fornita da un'istanza o un servizio centralizzato nel tuo ambiente Google Cloud , devi instradare il traffico diretto a internet tramite la rete VPC.
Se questo non è applicabile o se i controlli sono implementati nel tuo cloud privato, ti consigliamo di includere il servizio di indirizzi IP esterni in VMware Engine. Inoltre, ti consigliamo di utilizzare regole di accesso esterno per negare i pattern di traffico da internet che non si applicano alle tue applicazioni.
Regole firewall nord-sud ed est-ovest separate sul gateway e sul firewall distribuito in VMware Engine NSX
Configura il firewall distribuito (DFW) in NSX 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 (interno) est-ovest tra i segmenti e consente 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 con limitazioni al DFW per negare il traffico di rete tra le istanze per impostazione predefinita. Utilizza il DFW per consentire specificamente il traffico tra le applicazioni e tra i servizi all'interno dell'applicazione.
Configura il firewall del gateway NSX per controllare il traffico nord-sud che entra ed 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 il traffico nord-sud per l'intero cloud privato in modo coerente, configura il firewall del gateway sul router di livello 0. Se devi configurare il traffico nord-sud per ogni segmento NSX, configura il firewall del gateway sul router di livello 1.
Oltre ai firewall NSX, ti consigliamo di 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 nei VPC. Il trasferimento dei dati in entrata alle istanze Compute Engine dai workload VMware Engine deve essere limitato per impostazione predefinita con solo il traffico aperto consapevolmente.
Il trasferimento dei dati in uscita verso le appliance di gestione e verso l'intervallo CIDR 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 e pertanto le regole DFW non si applicano per limitare l'accesso.
Applica i principi di sicurezza Zero Trust e la microsegmentazione in NSX
Utilizza NSX DFW per implementare controlli del traffico per segmenti di sicurezza granulari come le singole macchine virtuali. Questo principio di protezione del traffico tra singole VM, negato per impostazione predefinita, viene spesso definito anche "microsegmentazione", che è un approccio più granulare per il firewalling rispetto all'implementazione convenzionale dei firewall tra i domini di livello 3.
DFW è abilitato nel kernel dell'hypervisor su tutti gli host VMware Engine vSphere nel tuo cloud privato e può controllare il flusso di traffico tra i carichi di lavoro che si trovano nello stesso segmento NSX 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 policy, che possono avere criteri di appartenenza flessibili come la corrispondenza di tag o nomi delle VM.
La micro-segmentazione consente di implementare una rete con un controllo granulare del traffico in cui un pattern di traffico deve essere esplicitamente consentito. Il concetto di sicurezza in cui tutti i flussi di rete sono controllati da processi di verifica di identità e dispositivo anziché da un'attendibilità implicita viene 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 una 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, 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 tua rete Google Cloud o all'interno del cloud privato con un'integrazione con NSX.
Per un'analisi approfondita delle architetture di VMware Engine con appliance centralizzate, che possono essere utilizzate per una serie di casi d'uso di sicurezza avanzata, come IPS/IDS, DDoS, offload SSL e altro ancora, consulta il documento sulla sicurezza di rete utilizzando appliance centralizzate nel Cloud Architecture Center.
Utilizza Google Cloud Armor per proteggere i servizi web su VMware Engine dagli attacchi DDoS
Se instradi il traffico in entrata ai carichi di lavoro su VMware Engine tramite il VPC del cliente, ti consigliamo di inserire i carichi di lavoro 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 utilizzando 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 VMware Engine ai NEG 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 Google Cloud ad API 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, perché riduce i costi e la latenza del trasferimento dei dati in uscita. In questo modo non è più necessario un percorso di rete a internet per i workload che richiedono solo l'accesso all'API Google. Per ulteriori dettagli tecnici e passaggi di configurazione, consulta l'articolo Approfondimento dell'accesso privato Google.
Allo stesso modo, i carichi di lavoro VMware Engine che devono accedere alle risorseGoogle Cloud di una rete di producer di servizi, come le istanze Cloud SQL o Memorystore, devono connettersi privatamente utilizzando PSA. Per ulteriori informazioni, visita la sezione relativa al PSA per VMware Engine.
Cripta la comunicazione tra l'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. Ti consigliamo un approccio a più livelli per la crittografia 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 o utilizzando IPsec integrato nei collegamenti VLAN di Interconnect. Inoltre, la crittografia a livello dell'applicazione deve essere abilitata tra i componenti dell'applicazione utilizzando TLS.
Proteggere 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 inserendo le risorse sensibili, come i bucket Cloud Storage e i set di dati BigQuery, in un perimetro dei Controlli di servizio VPC. I carichi di lavoro che devono accedere ai dati all'interno di un perimetro devono essere inseriti anche nel 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.
Devi configurare i criteri di trasferimento dei dati in entrata e in uscita nella configurazione di Controlli di servizio VPC per consentire l'accesso delle API del servizio di produzione VMware Engine al perimetro. Per indicazioni dettagliate sulla configurazione, consulta le nostre pagine di documentazione sui Controlli di servizio VPC con VMware Engine.
IAM e autorizzazioni di VMware Engine
Le sezioni seguenti 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 Google Cloud progetto in cui viene eseguito il deployment del cloud privato.
Utilizza ruoli predefiniti o personalizzati per concedere l'accesso
L'approccio di VMware Engine per gestire ruoli e autorizzazioni vSphere può essere sfruttato nello stesso modo in cui viene sfruttato da 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 identità a cui concedono le autorizzazioni e le attività di esempio che consentono.
| Piattaforma | Componente | Origine identità | Dove configurare le autorizzazioni | Attività di esempio |
|---|---|---|---|---|
| Google Cloud | Portale VMware Engine | Cloud Identity | Identity and Access Management | Deployment e annullamento del cloud privato, deployment e annullamento del cluster, ad esempio. |
| VMware Engine | vCenter | LDAP | Host e cluster, VM e cartelle, datastore nell'interfaccia utente vCenter | Creazione di VM, creazione di cartelle VM, creazione ed eliminazione di oggetti datastore, ad esempio |
| NSX | LDAP | "Users and Roles" (Utenti e ruoli) nell'interfaccia utente di NSX Manager | Creazione di segmenti NSX, configurazione del firewall, configurazione del bilanciatore del carico, ad esempio. | |
| vCenter | Sistema operativo guest della VM | Active Directory, LDAP, utenti locali, ad esempio | Sistema operativo guest | Accesso SSH o RDP, operazioni sui file, ad esempio |
In Google Cloud IAM esistono due ruoli predefiniti con autorizzazioni per il portale VMware Engine:
- Amministratore del servizio VMware Engine: concede l'accesso completo al servizio VMware Engine su Google Cloud.
- Visualizzatore del servizio VMware Engine: fornisce 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, ti consigliamo di utilizzare i ruoli predefiniti anziché quelli di base perché forniscono autorizzazioni più granulari.
L'accesso programmatico a VMware Engine tramite service account utilizzando 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, ti consigliamo di 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 posizione dei tuoi cloud privati 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 o HCX. Il personale che deve solo operare in questi ambienti non richiede i ruoli IAM elencati in precedenza. Devono invece utilizzare le identità LDAP con le autorizzazioni configurate in vCenter e NSX. Ti consigliamo di fornire i ruoli Amministratore servizio VMware Engine o Visualizzatore servizio VMware Engine solo a un numero molto limitato di utenti, poiché questi ruoli concedono l'accesso all'account utente CloudOwner per vCenter e all'account utente amministratore per NSX. Questi account utente devono essere utilizzati solo per la configurazione iniziale o le procedure di emergenza.
Limitare e controllare attivamente l'accesso amministratore
Il ruolo Amministratore del 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 di frequente e può avere un impatto elevato sulla fatturazione o sulla disponibilità del cluster. Assegna questo ruolo solo a poche persone della tua organizzazione.
Assicurati di controllare regolarmente a chi è stato assegnato il ruolo Amministratore servizi 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 sui ruoli IAM per identificare i ruoli con privilegi eccessivi.
Configurare 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 degli utenti per vCenter e NSX Manager. Si tratta di una pratica consigliata per la gestione centralizzata del ciclo di vita delle identità, la gestione dei gruppi, la gestione delle password e altro ancora. Tieni presente che l'unione diretta di vCenter e NSX 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 (come vCenter, NSX e HCX). Ti consigliamo di stabilire una procedura per ruotare le password del service account vCenter predefinito CloudOwner@gve.local e dell'amministratore delaccount di serviziot NSX 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 viene trovata da un malintenzionato.
Logging e monitoraggio di VMware Engine
Le sezioni seguenti introducono le best practice per la registrazione e il monitoraggio dei workload VM e dell'infrastruttura VMware Engine, che fornisce le risorse utilizzate dai workload.
Importa log e metriche di VMware Engine
Molte organizzazioni vogliono raccogliere e analizzare i log in un'unica visualizzazione centralizzata. 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 a Cloud Monitoring metriche come l'utilizzo di CPU e memoria ESXi. Ti consigliamo di creare dashboard basate su metriche inoltrate da vCenter o di iniziare a utilizzare 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. La raccolta, la conservazione e l'analisi dei messaggi Syslog di vCenter hanno importanti casi d'uso per la sicurezza, come gli avvisi in tempo reale basati sui login di utenti amministrativi (o 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 centrale in un unico progetto. Se il tuo ambiente VMware Engine si estende su più progetti, devi anche aggregare i progetti configurando sink di log e ambiti di monitoraggio.
Utilizzare l'agente Cloud Logging per il logging delle VM del workload
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 dei workload su VMware Engine con l'approccio per le istanze Compute Engine e il tuo ambiente 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 workload su entrambe le piattaforme inviino i log a Cloud Logging.
Applica funzionalità equivalenti dei criteri Access Transparency e Access Approval
Anche se VMware Engine non supporta 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 di Access Transparency, devi prendere in considerazione diverse origini 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, ma devi presentare una richiesta di assistenza a Google Cloud per configurare l'inoltro di syslog ESXi.
Se hai requisiti normativi rigorosi, implementiamo una norma 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 un motivo per cui gli operatori del servizio di accesso richiedono l'accesso.
Si applicano le esclusioni di Google Cloud Access Approval.
Crittografia VMware Engine
Le sezioni seguenti introducono le best practice per la crittografia dello spazio di archiviazione nel cloud privato e i fattori trainanti da considerare quando scegli un fornitore di chiavi per il tuo cloud privato.
Utilizza un Google-owned and managed key provider abilitato per la crittografia vSAN at-rest
La crittografia dei dati at-rest viene implementata utilizzando la crittografia basata sul 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 cluster ESXi e la disattivazione della crittografia vSAN costituisce una violazione dei termini di servizio per VMware Engine. Molte organizzazioni richiedono crittografia at-rest;ambito delle loro norme aziendali o sono obbligate per legge a criptare i dati (ad esempio NIST, FIPS).
Ogni host ESXi cripta i dati utilizzando la modalità AES-256 XTS standard con chiavi di crittografia dei dati (DEK) diverse generate in modo casuale. La DEK viene criptata utilizzando una chiave di crittografia della chiave (KEK) e viene memorizzata sul disco solo in forma criptata. Il server vCenter memorizza solo l'ID della KEK, ma non la KEK stessa, che viene archiviata in un Cloud Key Management Service (KMS). Puoi scegliere la posizione di Cloud KMS in cui viene conservata la chiave KEK.
Ti consigliamo di utilizzare il fornitore di chiavi predefinito gestito da Google. Se, tuttavia, devi gestire personalmente Cloud KMS, puoi utilizzare un'istanza Cloud KMS di terze parti conforme a KMIP 1.1 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 fornitore di chiavi predefinito e le integrazioni di Cloud KMS di terze parti:
| Fornitore di chiavi | Vantaggi | Svantaggi |
|---|---|---|
| Fornitore Google-owned and managed key predefinito |
|
|
| Fornitore di chiavi Cloud KMS di terze parti |
|
|
Tieni presente che ti sconsigliamo di 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.
Automatizzare la rotazione delle chiavi di crittografia in base agli standard della tua organizzazione
Sei responsabile della rotazione della KEK utilizzando VMware Engine vSphere. Questo vale sia per il fornitore di chiavi predefinito sia per un Cloud KMS esterno. La rotazione della KEK può essere avviata da vCenter o utilizzando la relativa API. Valuta la possibilità di automatizzare la rotazione delle KEK in base ai requisiti 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, danneggiamento ed errori umani. Inoltre, le applicazioni business-critical si basano sulla disponibilità dei dati praticamente in qualsiasi momento, lasciandoti poco tempo per recuperare i dati da interruzioni improvvise. Questa sezione non contiene una copertura completa di tutti gli aspetti di backup e ripristino di emergenzaa pertinenti per progettare in modo efficace una strategia di backup eREDR per mantenere i dati sicuri e disponibili, ma contiene considerazioni chiave quando si sceglie la strategia giusta per l'ambiente VMware Engine.
Esegui il backup dei tuoi carichi di lavoro utilizzando il servizio di backup e DR
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 workload su Compute Engine e Google Cloud VMware Engine. Il servizio di backup e DR è l'unica soluzione 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 per sempre efficienti in termini di spazio e opzioni di archiviazione flessibili.
Google Cloud VMware Engine supporta anche l'utilizzo di soluzioni di backup di terze parti basate su agenti. Potresti preferirle 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 delle applicazioni
- Sono certificati da VMware Engine per vSAN
- Supportano lo standard del protocollo VMware Engine vStorage API for Data Protection (VADP) o eseguono backup a livello di applicazione
Indipendentemente dalla soluzione di backup che scegli, ti consigliamo Cloud Storage come opzione di archiviazione economica per la conservazione a lungo termine dei backup. Cloud Storage è un'archiviazione di oggetti a elevata durabilità e conveniente. I bucket Cloud Storage possono essere configurati per replicare automaticamente gli oggetti di archiviazione in più regioni, il che è 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 una volta che la loro durata supera un valore predefinito. Utilizza questa opzione per una posizione di archiviazione di backup e un supporto convenienti con RPO da medi ad 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 un costo più elevato per l'archiviazione dei 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.
Implementa il ripristino di emergenza con il servizio di backup e DR
Ti consigliamo di ripristinare le applicazioni su VMware Engine utilizzando il servizio di backup e DR. Per proteggere i tuoi workload di produzione dalle interruzioni di una singola zona all'interno di una regione, ti consigliamo di eseguire il deployment e 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 Google Cloud Backup e RE, VMware Engine è compatibile con altre opzioni per RE, come VMware Engine SRM e Zerto. Sia VMware Engine SRM sia Zerto si basano sulla replica vSphere per ilripristino di emergenzay, che in genere supporta target RPO inferiori. Se il tuo RPO target è espresso in minuti anziché in ore, valuta le soluzioni di RE basate sulla replica vSphere.
Elenco di controllo di riepilogo
Il seguente elenco di controllo riassume le best practice per la sicurezza per l'utilizzo di VMware Engine.
| Attività | Argomento |
|---|---|
| Networking 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 saperne di più, visita la pagina Funzionalità, vantaggi e casi d'uso.
- Scopri di più sui concetti di sicurezza di VMware Engine.
- Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Visita il Cloud Architecture Center per maggiori informazioni.