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, puoi valutare di iniziare con l'apprendimento prerequisiti e VMware Engine sicurezza.
VMware Engine ha un condiviso responsabilità un modello di sicurezza. La sicurezza affidabile nel cloud si ottiene attraverso la condivisione delle responsabilità 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 seguenti sezioni introducono le best practice per il networking in un nell'ambiente VMware Engine.
Identifica e comprendi tutti i flussi di traffico del tuo ambiente
VMware Engine sfrutta le reti VMware Engine e peering VPC per connettere connessione di rete privata da un cloud privato 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 dell'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 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 per qualsiasi altro traffico in entrata. Tieni presente che queste opzioni sono mutuamente esclusive. Se sono necessari controlli personalizzati per internet del traffico, come filtri URL, IPS/IDS o controlli del traffico forniti da un centrale o centrale nel tuo ambiente Google Cloud, per instradare il traffico connesso a internet tramite la rete VPC.
Se questo non è applicabile al 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 bloccare i pattern di traffico di internet che non si applicano ai tuoi diverse applicazioni.
Separa le regole firewall nord-sud ed est-ovest su gateway e 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 è progettata per gestire il traffico di rete (interno) est-ovest tra segmenti e permette le regole firewall che consentono e negano il traffico tra singole istanze all'interno di un segmento.
Per un controllo dell'accesso alla rete granulare, assicurati di applicare un valore predefinito limitato sul DFW per negare il traffico di rete tra le istanze per impostazione predefinita. Utilizza la 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 da nord a 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 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 consentire e bloccare il traffico da est a ovest tra i carichi di lavoro Cloud privato e carichi di lavoro di VMware Engine nei VPC. Il trasferimento di dati in entrata alle istanze Compute Engine dai carichi di lavoro 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 il trasferimento dei dati in uscita solo verso da host e indirizzi IP attendibili all'interno della 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 micro-segmentazione 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. La concetto di sicurezza in cui tutti i flussi di rete sono controllati dall'identità e dal dispositivo di verifica, anziché affidabilità implicita, viene spesso chiamata Zero Affidabilità Sicurezza.
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, comprese funzionalità IDS/IPS per traffico in entrata nel cloud privato dal resto della rete o tra segmenti di rete NSX-T, valuta la possibilità di eseguire il deployment di un firewall dell'appliance di ricerca. L'appliance di terze parti può essere distribuita come NIC multiplo tra due VPC nella tua rete Google Cloud o all'interno 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, la mitigazione degli attacchi DDoS e vulnerabilità comuni come cross-site scripting (XSS) o SQL injection.
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, consigliamo Cloud Service Mesh. In tutti gli altri casi, consigliamo il carico HTTP(S) esterno con il bilanciatore del carico di rete passthrough esterno regionale.
Segui la documentazione su come aggiungere i carichi di lavoro VMware Engine a NEG ibrido 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
Connettersi ai servizi Google Cloud in privato senza accesso a internet
I carichi di lavoro del cloud privato di VMware Engine possono accedere a Google Cloud API come l'API Cloud Storage che utilizza 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 dei dati in uscita. Anche questo elimina la necessità di un percorso di rete verso internet per i carichi di lavoro che richiedono solo Accesso alle API di Google. Per saperne di più, segui l'approfondimento sull'accesso privato Google dettagli tecnici e passaggi di configurazione.
Allo stesso modo, i carichi di lavoro VMware Engine che devono accedere delle risorse Google Cloud dalla rete di un producer di servizi, Le istanze Cloud SQL o Memorystore devono connettersi privatamente PSA. Per ulteriori informazioni, consulta la sezione sugli annunci di pubblica utilità per con 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 a più livelli per la crittografia dei dati in transito tra i data center on-premise in Google Cloud. Il collegamento tra i sistemi on-premise e Google Cloud può essere criptato configurando Cloud VPN con un tunnel IPsec usando l'IPsec integrato sui collegamenti VLAN di Interconnect. Inoltre, deve essere abilitata la crittografia a livello di applicazione 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. Carichi di lavoro che devono per accedere ai dati all'interno di un 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 VPC Service Controls per consentire alle API di servizio del produttore VMware Engine di accedere al perimetro. Per indicazioni dettagliate sulla configurazione, consulta le nostre pagine di documentazione su VPC Service Controls con VMware Engine.
IAM e autorizzazioni di VMware Engine
Le seguenti sezioni introducono le best practice per le autorizzazioni utente in un nell'ambiente VMware Engine. È importante prendersi cura delle autorizzazioni nell'ambiente VMware Engine e nel progetto Google Cloud di cui viene eseguito il deployment del cloud privato.
Utilizza ruoli predefiniti o personalizzati per concedere l'accesso
L'approccio di VMware Engine alla gestione di ruoli e autorizzazioni di vSphere possono essere sfruttati allo stesso modo in cui si è abituati a sfruttare da altri Ambienti VMware Engine. Tuttavia, attività come il deployment richiedono le autorizzazioni in Identity and Access Management (IAM). La tabella seguente elenca i gestori degli accessi pertinenti, le origini identità a cui concedono le autorizzazioni ed esempi di attività che abilitano.
| 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 di vCenter | Creazione di VM, creazione di cartelle 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, configurazione del bilanciatore del carico e così via. | |
| vCenter | Sistema operativo guest della VM | Active Directory, LDAP, Utenti locali, ad esempio | Sistema operativo guest | Accesso SSH o RDP, operazioni con i file, ad esempio |
In Google Cloud IAM esistono due ruoli predefiniti le autorizzazioni per il portale VMware Engine:
- VMware Engine Service Admin: consente l'accesso completo al servizio VMware Engine su Google Cloud.
- Visualizzatore servizi VMware Engine - fornisce 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. Anche i ruoli di base includono la possibilità di gestire il servizio VMware Engine (Proprietario, Editor) o per visualizzare i dettagli del servizio (Visualizzatore). In genere, si consiglia di utilizzare i ruoli predefiniti al posto dei ruoli di base perché offrono e autorizzazioni granulari.
Accesso programmatico a VMware Engine tramite account di servizio tramite l'API o l'interfaccia a riga di comando deve essere vincolata utilizzando ruoli predefiniti o personalizzati perché includono autorizzazioni più granulari che si applicano solo con 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 località appropriata per l'assegnazione del ruolo IAM in della 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 IAM di Cloud non sono necessarie per le attività che devono essere eseguite solo in vCenter, NSX-T o HCX. Personale che deve solo operare questi ambienti non richiedono le autorizzazioni IAM ruoli. Dovrebbero invece utilizzare le identità LDAP con le autorizzazioni configurate in vCenter e NSX-T. Ti consigliamo di fornire il servizio VMware Engine Ruoli amministratore o Visualizzatore servizio VMware Engine solo per un numero di utenti poiché questi ruoli concedono l'accesso al potente utente CloudOwner per vCenter e l'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 nella tua organizzazione.
Assicurati di controllare regolarmente a chi è stato assegnato VMware Engine Amministratore servizi direttamente nel progetto utilizzato per VMware Engine o su uno dei livelli padre della risorsa nella gerarchia. Questo controllo deve includere altri ruoli, come Editor di base e Ruoli di proprietario che includono autorizzazioni critiche relative con VMware Engine. Puoi utilizzare servizi come i ruoli IAM per identificare i ruoli con privilegi eccessivi.
Configurare un'origine identità LDAP o Active Directory
Un provider di identità che supporti l'autenticazione LDAP, ad esempio Attivo che deve essere configurata in modo da abilitare l'autenticazione utente per vCenter e NSX Manager. Questa è una pratica consigliata per avere un ciclo di vita centrale dell'identità gestione di gruppi, 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.
Ruota 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). si consiglia di stabilire un processo per ruotare le password del servizio vCenter predefinito l'account CloudOwner@gve.local e l'amministratore dell'account di servizio NSX-T predefinito. Entrambi gli account utente devono essere utilizzati solo per la configurazione iniziale le procedure di emergenza e le relative password vengano ruotate regolarmente (ad esempio, ogni 60 o 90 giorni). In modo equivalente, ruota regolarmente le password degli account utente della soluzione che comunemente utilizzata per l'integrazione di strumenti di terze parti. Più spesso ruotare le password degli account di servizio, meno è probabile che la password ancora valida quando un malintenzionato lo trova.
Logging e monitoraggio di VMware Engine
Le seguenti sezioni introducono le best practice per il logging e il monitoraggio sia per i carichi di lavoro delle VM sia per l'infrastruttura VMware Engine, le risorse consumate dai carichi di lavoro.
Importa log e metriche di VMware Engine
Molte organizzazioni vogliono raccogliere e analizzare i log in un ambiente "pane of Glass". 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 basate sulle metriche che vengono inoltrate vCenter o per iniziare con alcune dashboard di esempio che sono state pubblicate su GitHub.
Per raccogliere i log della piattaforma, i cloud privati di VMware Engine possono inoltrare Log di syslog in un aggregatore di log centralizzato. Questa operazione può essere eseguita sia per vCenter e messaggi Syslog NSX-T. Raccolta, conservazione e analisi dei messaggi Syslog di vCenter dispone di importanti casi d'uso relativi alla sicurezza, come gli avvisi in tempo reale basati sugli accessi amministrativi (o di emergenza), che devono essere eseguiti solo in circostanze eccezionali. Per analizzare i messaggi Syslog, è necessario un file come Fluentd o l'agente standalone deve essere configurato di 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 inoltre aggregarli 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 del carico di lavoro VMware Engine possono inviare i log direttamente all'API Cloud Logging utilizzando l'agente di logging. L'agente di 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 carico di lavoro 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 impiegato per le VM su Compute Engine, in modo che i carichi di lavoro siano inviano i propri log a Cloud Logging.
Applica 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 con capacità equivalenti che possono essere abilitate su richiesta.
Per l'equivalenza di trasparenza degli accessi, devi considerare diverse fonti di log tra cui:
- Log vCenter esportabili utilizzando la configurazione remota del server syslog.
- 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 molto severi, implementiamo una norma per fornire funzionalità equivalenti per l'approvazione dell'accesso. In questo criterio, i servizi standard richiedono la generazione di un ticket di assistenza con la motivazione dell'accesso e gli operatori di servizio richiedono l'accesso.
Si applicano le esclusioni per l'approvazione dell'accesso a Google Cloud.
Crittografia VMware Engine
Le sezioni seguenti introducono le best practice per la crittografia dello spazio di archiviazione il cloud privato e i fattori chiave da considerare nella scelta di un provider chiave per il tuo cloud privato.
Utilizza un provider di chiavi gestito da Google abilitato per la crittografia at-rest 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 all'interno dell'azienda o sono obbligati dalle normative a criptare i dati (ad esempio, NIST, FIPS).
Ogni host ESXi cripta i dati utilizzando la modalità standard AES-256 XTS con chiavi di crittografia dei dati (DEK, Data Encryption Key) generate in modo casuale. La DEK è criptata usando una chiave chiave di crittografia (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 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 provider della chiave può essere utilizzato per criptare i dati at-rest e Traffico vMotion in transito.
La seguente tabella evidenzia le principali differenze tra il provider di chiavi predefinito e integrazioni di Cloud KMS di terze parti:
| Fornitore chiave | Vantaggi | Svantaggi |
|---|---|---|
| Provider di chiavi gestite da Google predefinito |
|
|
| Provider di chiavi Cloud KMS di terze parti |
|
|
Tieni presente che non è consigliabile abilitare la crittografia a livello di VM insieme a vSAN crittografia del datastore poiché 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 delle chiavi KEK mediante VMware Engine vSphere. Questo è il caso sia con la chiave predefinita e con un Cloud KMS esterno. La rotazione della KEK può essere da vCenter o tramite la relativa API. Valuta la possibilità di automatizzare la rotazione del 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, corruzione, e l'errore umano. 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 recupero dei disastri pertinenti per progettare in modo efficace una strategia di backup e RP 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 carichi di lavoro utilizzando il servizio di backup e RE
Con il servizio di backup e RE, Google Cloud offre una soluzione di gestione centralizzata soluzione di backup utilizzabile per diversi casi d'uso, tra cui il backup su Compute Engine e Google Cloud VMware Engine. Il servizio di backup e RE è la soluzione unica consigliata da Google per i carichi di lavoro i backup, perché offre vantaggi come un ampio spettro di carichi di lavoro efficiente in termini di spazio, backup incrementali incrementali e spazio di archiviazione flessibile le opzioni di CPU e memoria disponibili.
Google Cloud VMware Engine supporta anche l'uso di soluzioni di backup basate su agenti. 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 l'API vStorage di VMware Engine per la protezione dei dati standard di protocollo (VADP) o eseguire 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 a elevata durabilità e dai costi contenuti. I bucket Cloud Storage possono essere configurati per replicare automaticamente lo spazio di archiviazione di oggetti in più regioni, ideale per le istanze Cloud multiregionali le topologie.
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. Usa questa l'opzione di archiviazione se è accettabile un costo maggiore per l'archiviazione di backup e l'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
Consigliamo di ripristinare le applicazioni su VMware Engine utilizzando Backup & DR. Per proteggere i carichi di lavoro 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 RP basate sulla replica vSphere.
Riepilogo elenco di controllo
Il seguente elenco di controllo riassume le best practice di sicurezza per l'utilizzo con 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 in prima persona. Per ulteriori informazioni, consulta funzionalità, vantaggi e casi d'uso.
- Scopri di più sulla sicurezza di VMware Engine concetti fondamentali.
- Esplora le architetture di riferimento, i diagrammi, i tutorial e le best practice su Google Cloud. Per ulteriori informazioni, visita il Cloud Architecture Center.