Zero Gravity: Chris Childerhose Talks Tech with the Ootbi VSA | Join us >>
Technical

Non Architetture di Backup Zero Trust

| 8 minuti da leggere

Nel blog #2 di questa serie, abbiamo approfondito i principi centrali del modello di Zero Trust Data Resilience (ZTDR): segmentazione, più zone di resilienza dei dati e backup immutabile storage. Questo modello e architettura, frutto di uno sforzo collaborativo tra Veeam e Numberline Security, estende i principi e il modello di maturità Zero Trust di CISA al caso d'uso del backup e del recupero dei dati aziendali (vedi Figura 1): 

Diagramma che illustra i principi fondamentali di Zero Trust e Zero Trust Data Resilience (ZTDR). La sezione superiore evidenzia i principi di Zero Trust: Assume breach, Verify explicitly e Use least-privilege access. La sezione inferiore estende questi concetti nella Zero Trust Data Resilience per il backup e il recupero dei dati aziendali, concentrandosi sulla Segmentazione del Software di Backup e dello Storage, più zone di resilienza e storage di backup immutabile.

Figura 1: Principi fondamentali di ZTDR 

Ora che abbiamo trattato i principi di ZTDR e come aiuti a proteggere l'infrastruttura di backup, esaminiamo le architetture non Zero Trust e individuiamo alcune insidie di sicurezza che creano.  

Apparecchiatura Monolitica (Integrata) - Non Zero Trust 

È cruciale considerare l'architettura di backup che scegli per le esigenze di resilienza dei dati della tua organizzazione. Un esempio da considerare è l'apparecchiatura monolitica o integrata. Questa architettura non soddisfa i requisiti di Zero Trust Data Resilience perché non c'è separazione tra software di backup e storage di backup (vedi Figura 2). Qualsiasi attaccante avrebbe accesso completo al software di backup e allo storage in caso di violazione. Di conseguenza, la vera immutabilità non può essere raggiunta e l'attaccante può modificare, eliminare o rendere inaccessibili i dati di backup. Il sistema di backup e recupero sarebbe completamente compromesso, creando un significativo raggio d'azione per l'attacco.  

Diagramma che illustra un'architettura di backup con Apparecchiatura Monolitica, che non è conforme ai principi di Zero Trust. Il grafico mostra la combinazione di software di backup e storage di backup sia in scenari on-premises che cloud senza alcuna separazione, evidenziando rischi di sicurezza come la mancanza di vera immutabilità e un raggio d'azione completo in caso di violazione.

 Figura 2: Le apparecchiature monolitiche mancano di segmentazione 

Questo approccio ripone troppa fiducia nell'immutabilità e nella sicurezza del file system proprietario del fornitore con privilegi amministrativi. A causa della loro natura naturalmente non segmentata e costruita attorno al concetto di All-in-One, devono essere fatti sacrifici per far funzionare le parti come un tutto. Un pool di storage può essere etichettato come immutabile, ma l'amministratore della scatola può comunque eseguire ripristini di fabbrica o eliminazioni amministrative (o governate). Supponiamo che una parte del sistema fallisca a causa di un attacco, corruzione o aggiornamento software difettoso. In tal caso, il resto del sistema potrebbe diventare inoperabile. Anche se i dati rimangono immutabili durante un guasto, se sono inaccessibili, non sono dati resilienti. 

Inoltre, è essenziale riconoscere che il dispiegamento di un'apparecchiatura virtuale monolitica in un'istanza cloud non garantisce una vera immutabilità in uno scenario di cloud ibrido. In caso di violazione, in cui le credenziali a livello di OS, istanza o account sono compromesse, l'intera apparecchiatura virtuale diventa suscettibile, espandendo il raggio d'azione. La vulnerabilità di sicurezza deriva dall'esecuzione del backup dei dati nello storage proprietario ospitato all'interno dell'apparecchiatura virtuale basata su cloud. Questa debolezza — causata da un disallineamento architetturale con ZTDR — potrebbe essere risolta eseguendo il backup dei dati direttamente in cloud immutabile storage a oggetti esterno all'istanza. 

Storage Diretto, Vecchia Scuola e Obsoleto 

Lo Storage Diretto (DAS) è un'architettura di storage comunemente utilizzata in molte organizzazioni. Tuttavia, presenta un significativo rischio di sicurezza poiché non offre immutabilità. È direttamente collegato al server di backup, senza separazione tra software di backup e storage di backup. Ciò significa che se un attaccante ottiene accesso all'host sfruttando una vulnerabilità del sistema operativo o dell'applicazione, può facilmente accedere a tutti i dati su quel sistema (vedi Figura 3). 

Con DAS, non esiste un meccanismo per prevenire accessi non autorizzati o manomissioni dei dati memorizzati sul server di backup. Questo lo rende vulnerabile a minacce interne ed esterne, inclusi insider malevoli, criminali informatici e hacker. 

Diagramma che mostra lo Storage Diretto (DAS) come un'architettura di backup non Zero Trust. Sottolinea la mancanza di separazione tra software di backup e storage di backup direttamente collegato a un server host, che è suscettibile a violazioni che compromettono le credenziali, con annotazioni che spiegano l'assenza di immutabilità e l'aumento del rischio di accesso non autorizzato.

Figura 3: DAS manca di immutabilità e può essere facilmente compromesso. 

Sebbene lo Storage Diretto possa sembrare una soluzione conveniente ed economica per il backup e il recupero, presenta rischi di sicurezza significativi che non dovrebbero essere ignorati. Implementando un'architettura di storage di backup che fornisca immutabilità e separazione tra software di backup e storage di backup, le organizzazioni possono ridurre significativamente il rischio di violazioni dei dati e garantire l'integrità dei loro dati di backup. 

Altre Opzioni di Storage 

Le stesse considerazioni si applicano ad altri tipi di storage, come apparecchiature deduplication, NAS, o anche un repository Linux indurito Veeam fai-da-te. Sebbene ciascuno abbia i propri punti di forza come obiettivi di storage, come maggiore capacità, gestione indipendente o semplice convenienza, mancano anche della sicurezza necessaria per essere considerati Zero Trust Data Resilient. Quando si considerano questi dispositivi per lo storage di backup, poniti queste domande: 

  • Lo storage è indurito per impostazione predefinita (pronto all'uso)? 
  • Richiede competenze o formazione di sicurezza aggiuntive per configurare e gestire? 
  • I privilegi amministrativi concedono accesso per eliminazioni o ripristini? 
  • Questo minimizzerà la mia superficie di attacco e sarà in grado di operare senza il mio software di backup?  
  • Che tipo di immutabilità viene utilizzata, governance (gli amministratori possono eliminare) o conformità (nessuno può eliminare)? 

Considerazioni Finali 

Le violazioni della sicurezza non sono più una questione di se ma di quando. Le organizzazioni devono proteggere proattivamente i loro sistemi e dati contro potenziali minacce.  

In questa serie di blog, abbiamo trattato i principi di Zero Trust Data Resilience proposti da Veeam e Numberline Security, estendendo Zero Trust ai sistemi di backup aziendali. Abbracciando i principi di Zero Trust Data Resilience, le organizzazioni possono avere un percorso chiaro e concreto per rafforzare la loro postura di sicurezza del sistema di backup e recupero. Questo approccio migliora il tradizionale modello di maturità Zero Trust. Garantisce che l'infrastruttura di backup sia segmentata in modo sicuro in più zone di resilienza dei dati, la superficie di attacco sia minimizzata, l'accesso con privilegi minimi sia applicato per ciascuna zona e sfrutta l'immutabilità per proteggere i dati di backup da modifiche ed eliminazioni indipendentemente dai privilegi amministrativi.  

Inoltre, ZTDR promuove operazioni più efficienti e allineamento tra amministratori di backup, IT e team di sicurezza, portando infine a un recupero più rapido e sicuro in caso di violazione. Implementando queste migliori pratiche, le organizzazioni possono dimostrare il loro impegno per la sicurezza e costruire fiducia con i loro clienti e stakeholder. Per saperne di più, leggi il nostro whitepaper e il documento di ricerca originale scritto da Jason Garbis e Veeam.  

Potresti anche gradire