Best practice per la sicurezza di VMware Engine
Questo documento descrive le best practice di sicurezza consigliate per la gestione e la la configurazione di Google Cloud VMware Engine ed è destinato agli utenti che hanno con VMware Engine. Se sei un principiante, puoi valutare di iniziare con l'apprendimento prerequisiti e VMware Engine sicurezza.
VMware Engine ha uno 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. Stai seguendo le best practice possono aiutarti a risparmiare tempo, prevenire gli errori e mitigare gli effetti o punti di errore.
Identifica e comprendi tutti i flussi di traffico del tuo ambiente
Per proteggere i carichi di lavoro e le interfacce di gestione nel cloud privato, è importante identificare e comprendere tutti i flussi di traffico del tuo ambiente. Rivedi il diagramma di rete per ulteriori informazioni sui flussi di traffico.
VMware Engine sfrutta i servizi privati Accedi (PSA) a esporre una connessione di rete privata da un cloud privato di VMware Engine alla rete VPC. Traffico in entrata da un VPC Google Cloud o da una rete on-premise attraversa una Rete Service Producer gestita da Google.
Utilizza il servizio IP pubblico di VMware Engine per il traffico in entrata da 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 una su Google Cloud. In questo caso, il traffico viene indirizzato come qualsiasi altro traffico in entrata tramite l'accesso privato ai servizi. Tieni presente che questi si escludono a vicenda. 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, routing del traffico associato a internet attraverso il VPC e il producer di servizi condiviso in un VPC.
Se questo non è applicabile al tuo caso o se hai implementato i controlli all'interno il tuo cloud privato, ti consigliamo di includere il servizio di indirizzi IP pubblici in VMware Engine. Inoltre, ti consigliamo di utilizzare la classe stateful firewall regole 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 e e consigliati per casi d'uso come il controllo il traffico in un perimetro verso un altro zona di destinazione. Se è necessario configurare il traffico da nord a sud per l'intero in modo coerente, quindi configura il firewall del gateway sul livello 0 o eseguire il provisioning di un router. Se devi configurare il traffico da nord-sud per ogni persona segmento NSX-T, quindi configura il firewall del gateway sul router di livello 1.
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. In entrata verso Le istanze Compute Engine dei carichi di lavoro VMware Engine devono limitati per impostazione predefinita con solo traffico aperto consapevolmente.
Il traffico in uscita verso le appliance di gestione e verso l'intervallo CIDR vSphere/vSAN dai VPC anche tramite il firewall VPC. Apri il traffico in uscita solo verso da host e indirizzi IP attendibili all'interno della rete. È importante notare che le appliance di gestione non si trovano all'interno di un e quindi le regole DFW non si applicano per limitare l'accesso.
Applica i principi di sicurezza Zero Trust e la micro-segmentazione in NSX-T
Utilizzare NSX-T DFW per implementare i controlli del traffico per i segmenti di sicurezza che sono granulari quanto le singole macchine virtuali. Questo principio di protezione il traffico tra le singole VM, negato per impostazione predefinita, viene spesso indicato "Micro-segmentazione", un approccio più granulare per il firewall di firewall tra i domini di livello 3.
DFW è abilitato nel kernel hypervisor su tutti i VMware Engine vSphere ospita nel tuo cloud privato e può controllare il flusso di traffico tra carichi di lavoro nello stesso numero o in segmenti NSX separati. Firewall per consentire il traffico da e verso le VM possono essere definite organizzando le VM gruppi di criteri, che possono avere criteri di appartenenza flessibili come la corrispondenza di tag o nomi di VM.
La micro-segmentazione consente di implementare una rete con traffico granulare dove ogni modello di traffico desiderato deve essere consentito in modo esplicito. 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 un cloud privato con un'integrazione con NSX-T.
Per un approfondimento sulle architetture di VMware Engine con strumenti utilizzabili per una varietà di casi d'uso di sicurezza avanzata, come IPS/IDS, DDoS, offloading SSL e altro ancora, consultate il documento utilizzando appliance centralizzate nella Cloud Architecture assistenza.
Usa 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, consigliamo di posizionare i carichi di lavoro VMware Engine in gruppi di endpoint di rete ibridi dietro a Traffic Director e sfruttando 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 Traffic Director. 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. I nostri suggerimenti utilizzi l'accesso privato Google per accedere ai servizi Google senza inviare il traffico su internet, poiché riduce i costi e la latenza del traffico 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 su questo argomento, consulta la sezione sugli annunci di pubblica utilità per con VMware Engine.
Cripta la comunicazione tra il tuo ambiente on-premise e Google Cloud
Carichi di lavoro su VMware Engine che devono comunicare con i sistemi la connessione on-prem deve essere connessa su 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 on-prem e Google Cloud può essere è criptato configurando Cloud VPN con un tunnel IPSec o IPSec nativo sui collegamenti VLAN di Interconnect. Inoltre, la crittografia a livello di applicazione deve essere abilitata tra i componenti dell'applicazione utilizzando TLS.
Proteggi i tuoi dati dall'esfiltrazione con Controlli di servizio VPC
Ti consigliamo di mitigare i rischi di esfiltrazione di dati utilizzando Controlli di servizio VPC posizionando le tue risorse sensibili come i bucket Cloud Storage 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. In particolare, il progetto Google Cloud che ospita le esigenze del cloud privato far parte del perimetro Controlli di servizio VPC per accedere alle risorse protette dai Controlli di servizio VPC.
Devi configurare i criteri di traffico in entrata e in uscita nei Controlli di servizio VPC per consentire alle API del servizio producer di VMware Engine di accedere lungo il perimetro. Per indicazioni dettagliate sulla configurazione, consulta le pagine della documentazione dei 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 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 | Ad esempio, creazione di segmenti NSX, configurazione del firewall o del bilanciatore del carico. | |
| vCenter | Sistema operativo guest 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:
- Amministratore servizio VMware Engine - fornisce l'accesso completo 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 riguardano le azioni nel portale VMware Engine e non riguardano le azioni nell'API o nell'interfaccia a riga di comando. 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 usato solo per un'attività che richiede solo un sottoinsieme specifico di autorizzazioni dei ruoli predefiniti, si consiglia di 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 Per i cloud privati di VMware Engine in un progetto possono essere assegnati solo i ruoli assegnate a livello di progetto. In caso di requisiti tecnici o organizzativi che consentono di posizionare i cloud privati in progetti separati, i ruoli richiesti in una cartella comune ai progetti utilizzati e cloud privati.
Le autorizzazioni Cloud IAM non sono necessarie per le attività all'interno di vCenter, NSX-T o HCX. Personale che deve solo operare questi ambienti non richiedono le autorizzazioni IAM ruoli. Dovrebbero invece utilizzare identità LDAP con autorizzazioni configurate 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 utente Deve essere utilizzato solo per la configurazione iniziale o le procedure di deployment di emergenza.
Limitare e controllare attivamente l'accesso degli amministratori
Il ruolo Amministratore servizio VMware Engine è molto potente e dovrebbe solo agli utenti che devono gestire il ciclo di vita il cloud privato VMware Engine e i relativi cluster. In genere, il manuale l'aggiunta o l'eliminazione di cluster e nodi è un'azione che non si verifica di frequente e può avere un impatto elevato sulla fatturazione o sulla disponibilità in un cluster Kubernetes. 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 collegamento di vCenter e NSX-T ad Active Directory per la versione integrata L'autenticazione 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 e il deployment di emergenza e le relative password devono essere ruotate regolarmente (ad es. 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 Monitoring 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 desiderano raccogliere e analizzare i log in un ambiente "pane of Glass". In Google Cloud, lo strumento Cloud Logging e I prodotti Cloud Monitoring forniscono servizi che possono essere utilizzati per centralizzazioni e la gestione di log e metriche. VMware Engine può essere integrato Cloud Monitoring tramite un agente autonomo. In questa configurazione, vCenter inoltra metriche come l'utilizzo della CPU e della memoria 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 di sicurezza, come gli avvisi in tempo reale basati sugli accessi di utenti amministrativi (o "deployment di emergenza") che devono essere eseguiti solo in circostanze eccezionali. Per analizzare i messaggi Syslog, è necessario un file come Fluentd o l'agente autonomo deve essere configurato di inoltrare i messaggi a Cloud Logging.
È consigliabile analizzare i log di VMware Engine in un ambiente una dashboard 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 dei carichi di lavoro di VMware Engine possono inviare i log direttamente API Cloud Logging, utilizzando l'agente Logging. L'agente Logging si basa su fluente e trasmette i flussi di log dalle applicazioni e dai sistemi di terze parti più comuni in Cloud Logging. Come best practice, allinea l'approccio raccogliendo e analizzando i log per le VM dei carichi di lavoro su VMware Engine con per le istanze di Compute Engine e la tua infrastruttura 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 ancora in modo nativo la trasparenza degli accessi, (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 remota syslog, tuttavia, devi inviare una richiesta di assistenza a Google Cloud per e configurare l'inoltro syslog 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.
Approvazione accesso a Google Cloud esclusioni .
Crittografia VMware Engine
Le sezioni seguenti introducono le best practice per la crittografia dello spazio di archiviazione il cloud privato e i fattori determinanti 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 abilita la crittografia vSAN su ogni ESXi cluster e configura un provider di chiavi predefinito in vCenter. Google richiede ai clienti di mantenere abilitata la crittografia vSAN sui propri cluster ESXi La crittografia vSAN è una violazione dei termini di servizio per 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 vCenter archivia solo l'ID della KEK, ma non la KEK stessa, che è archiviata in Cloud Key Management Service (KMS). Puoi scegliere la località del Cloud KMS in cui la tua KEK sia mantenuta.
Ti consigliamo di utilizzare il provider di chiavi predefinito gestito da Google. Se, invece, devi gestire personalmente Cloud KMS, puoi utilizzare di terze parti conforme a KMIP 1.1 da uno dei di Google Cloud. 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 utilizzando la funzionalità fornita da 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 delle chiavi KEK in base ai requisiti della tua organizzazione. Puoi trovare un esempio di 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 disponibile praticamente in ogni momento, lasciandoti poco tempo per recuperare i dati e interruzioni improvvise. Questa sezione non fornisce una copertura completa di tutti i tipi di backup gli aspetti del ripristino di emergenza che siano pertinenti per progettare in modo efficace un backup strategia di RE per mantenere i tuoi dati sicuri e disponibili, ma contenere le chiavi le considerazioni necessarie nella scelta della strategia nell'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 piattaforma nativa 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. Se hai già delle licenze, potresti preferirle per un prodotto di backup di terze parti. I prerequisiti per questi tipi di strumenti includono le seguenti:
- 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 di tua scelta, ti consigliamo Cloud Storage come opzione di archiviazione conveniente 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 un ciclo di vita per spostare automaticamente gli oggetti di archiviazione in un altro livello di archiviazione la durata supera un valore predefinito. Utilizza questa opzione per una posizione di archiviazione di backup e RPO medio-alti, soprattutto se il costo è fattore.
In alternativa, puoi scegliere l'archiviazione vSAN per ridurre al minimo l'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 a lungo termine, poiché c'è il rischio che il cluster diventano associate 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 un singola zona all'interno di una regione, è consigliabile eseguire il deployment e cloud in una zona secondaria all'interno della regione se VMware Engine è disponibile in più di una zona della regione. In caso contrario, verrà ti consigliamo di ripristinare le applicazioni in una regione secondaria.
Oltre a Backup & RE di Google Cloud, VMware Engine è compatibile con altre opzioni per RE, come VMware Engine SRM e Zerto. Sia VMware Engine SRM che Zerto si affida alla replica vSphere per il ripristino di emergenza, che in genere supporta target RPO più bassi. Se il target dell'RPO è di minuti anziché di ore, considera la RE 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 Monitoring di VMware Engine | |
| Crittografia VMware Engine | |
| Backup e ripristino di emergenza di VMware Engine |
Passaggi successivi
- Prova Google Cloud VMware Engine in prima persona. Scopri le funzionalità, i vantaggi e l'utilizzo casi per ulteriori informazioni.
- 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. Visita il Cloud Architecture Center per ulteriori informazioni.