Perché Zero Trust viene eccessivamente semplificato

Molti fornitori parlano di hardening e Zero Trust come se fossero intercambiabili. Non lo sono. L’hardening è una componente di Zero Trust, focalizzata sul rafforzamento delle difese e sul controllo di chi può accedere. Lo Zero Trust va oltre, imponendo ai team di presupporre la compromissione e di chiedersi cosa succede quando gli attaccanti entrano. 

Gli attacchi moderni aggirano regolarmente i controlli di hardening tramite escalation dei privilegi, furto di credenziali e vulnerabilità non patchate. Quando un attaccante raggiunge privilegi elevati in un sistema, la differenza tra hardening e Zero Trust diventa critica per valutare il rischio e garantire la recuperabilità. 

Il problema non è che l’hardening sia irrilevante o non faccia parte di Zero Trust — ne fa parte. Il problema è che molti fornitori spingono le organizzazioni a fermarsi all’ hardening.  Etichettano l’hardening come Zero Trust, lasciando l’organizzazione con un falso senso di protezione. 

“Gli attaccanti non entrano e si fermano. Si muovono strato dopo strato finché non raggiungono i sistemi con il maggior valore.” 

Hardening: cos’è e dove aiuta 

L’hardening è la riduzione disciplinata del rischio in tutto l’ambiente. Include accesso a privilegi minimi, MFA, segmentazione e monitoraggio—controlli pensati per prevenire la compromissione. Queste misure rallentano l’avanzamento di un attaccante e limitano il raggio d’impatto durante un attacco ransomware. 

Tuttavia, l’hardening si basa su una premessa: che i controlli impediranno la compromissione. I sistemi, i team e l’infrastruttura di tutti i giorni raramente si comportano in modo così lineare. Le finestre di manutenzione introducono eccezioni, le patch arrivano in ritardo e le configurazioni derivano. Inoltre, gli attaccanti non si affidano a un singolo punto di ingresso. Concatenano vulnerabilità, credenziali e configurazioni errate finché non raggiungono un sistema con un’autorità significativa. 

Hypervisor, provider di identità e piattaforme database condividono tutti la stessa limitazione strutturale: per funzionare richiedono controllo privilegiato. Una volta che gli attaccanti violano questi livelli, l’ambiente si comporta esattamente come vuole l’attaccante. Questa limitazione non è esclusiva di una singola categoria di prodotto: è intrinseca ai sistemi progettati per un’ampia autorità operativa. 

Per esempio, un hypervisor deve poter creare, modificare e eliminare workload; un sistema database deve poter alterare schemi, dati e permessi. Questa potenza operativa è necessaria, ma significa anche che, una volta che un attaccante raggiunge il server con privilegi elevati, quell’ infrastruttura può essere accessibile o smantellata. La stessa dinamica si applica a tutti i control plane ad alto privilegio. Questi livelli sono progettati per il controllo operativo, e lo stesso controllo diventa una responsabilità quando compromesso. 

L’hardening molte volte porta a una conclusione errata – che la compromissione non avverrà. La realtà è che le violazioni avverranno e, una volta che un attaccante raggiunge un sistema progettato per esercitare un controllo esteso, può interrompere o modificare le operazioni. 

Zero Trust: cos’è e come funziona 

Zero Trust viene spesso ridotto a una raccolta di tecniche di hardening. Tuttavia, Zero Trust non è una checklist di controlli: è una mentalità basata su Assume Breach. Assume Breach significa accettare che gli attaccanti entreranno nell’ambiente, aumenteranno i privilegi, otterranno credenziali e raggiungeranno sistemi ad alto valore.   La chiave è progettare piani per riprendersi dalla violazione. 

È qui che il settore esita. Molti fornitori evitano la conversazione su Assume Breach perché i loro sistemi non sono in grado di sopravviverle. L’hardening è una comoda affermazione di sicurezza. Assume Breach non lo è. Di conseguenza, mettono in evidenza MFA, segmentazione, e rilevamento, evitando la domanda su cosa accade quando quei controlli falliscono. Il risultato è un’interpretazione ristretta di Zero Trust che si ferma nel punto in cui l’attaccante ha successo. 

Zero Trust in Object First è definito in modo diverso: un sistema di storage con Zero Access per eseguire azioni distruttive, così che nessun amministratore, nessun attaccante e nessun processo possa modificare o eliminare i dati di backup, anche con credenziali complete. 

Questo è applicato tramite immutabilità nativa S3, un’appliance di storage dedicata e controlli Sicuro‑by‑Design che eliminano completamente i percorsi privilegiati. Questo impedisce l’accesso root, l’accesso shell e le azioni amministrative, incluse eliminazione e modifica. 

Zero Trust deve reggere al livello in cui i controlli di hardening hanno fallito. 

I livelli di protezione nello storage dei dati di backup 

La protezione moderna dei dati non si colloca su un unico piano. Si estende su più livelli di controllo, ciascuno con le proprie responsabilità e le proprie modalità di guasto. La stratificazione di sicurezza di Object First è modellata sul Modello di maturità Zero Trust di CISA, che è un modo utile per capire dove l’hardening e Zero Trust definiscono le regole. 

Identità: il primo control plane che gli attaccanti cercano di compromettere 

Tutto inizia dall’identità. Credenziali, token, MFA, servizi di directory—questa è la porta d’ingresso dell’ambiente. Qui l’hardening è pertinente e fa molto bene. Ma l’identità è anche il livello che gli attaccanti prendono di mira con maggiore aggressività. Phishing, furto di token, dirottamento di sessione ed escalation dei privilegi sono all’ordine del giorno. Quando un attaccante impersona un utente legittimo, il resto dell’ambiente inizia ad aprirsi. 

Dispositivi: il livello in cui deriva, eccezioni e operatività creano varchi 

Endpoint, server, hypervisor e appliance rientrano tutti in questa categoria. In teoria, ogni dispositivo è hardenizzato, patchato e monitorato. In pratica, i dispositivi sono dove emerge la realtà operativa: patch in ritardo, regole firewall temporanee, finestre di manutenzione e deriva di configurazione. Queste lacune si accumulano nel tempo e gli attaccanti sanno come trovarle. Un dispositivo compromesso diventa un punto d’appoggio che si confonde con le normali operazioni. 

Reti: la segmentazione rallenta gli attaccanti, ma non li ferma 

Segmentazione, microsegmentazione e controlli del traffico sono progettati per limitare gli attacchi dovuti al movimento laterale una volta ottenuto l’accesso al un sistema. Aiutano, ma non eliminano il problema. Quando un attaccante dispone di credenziali valide o di un token privilegiato, la rete diventa meno una barriera e più un rallentatore. L’assunto che la segmentazione contenga una violazione raramente regge contro un attore malevolo determinato. 

Applicazioni & Workload: dove i privilegi si concentrano 

È qui che l’autorità dell’ambiente inizia a convergere. Hypervisor, sistemi di orchestrazione e server di backup vivono tutti qui. Questi sistemi devono poter creare, modificare ed eliminare workload o job di backup. Questa potenza operativa è necessaria, ma significa anche che, quando un attaccante raggiunge questo livello con privilegi elevati, l’impatto diventa grave. L’hardening riduce il numero di errori banali, ma non può cambiare il fatto che questi sistemi sono intrinsecamente privilegiati. 

Dati Backup: l’unico livello che deve rimanere integro quando tutti gli altri falliscono 

Il livello dei dati è dove Zero Trust deve essere assoluto. Se gli attaccanti compromettono identità, dispositivi, reti e applicazioni, i dati di backup e la relativa catena di custodia devono sopravvivere. Questo richiede un’architettura di storage che non consenta azioni distruttive anche quando l’attaccante dispone di credenziali complete. 

Veeam e Object First sono progettati esattamente per questo scenario. Entrambi presuppongono che una violazione sia già avvenuta e che il ripristino possa dover iniziare anche se Veeam stesso è stato compromesso. Nel peggior caso—ogni segreto esposto, ogni credenziale rubata e ogni control plane violato—i dati di backup in Ootbi rimangono immutabili e non eliminabili, fornendo una base affidabile da cui ripartire per il ripristino. 

Questa capacità di sopravvivenza è ciò che separa Zero Trust dall’hardening. L’hardening sostiene che non si verificheranno violazioni; Zero Trust richiede la valutazione che gli attaccanti violeranno il bersaglio, ma non potranno comunque distruggere i dati necessari per il ripristino. Veeam documenta esplicitamente come ripristinare Veeam stesso in caso di violazione grave, e Object First fornisce il livello archivio immutabile che rende possibile quel ripristino. 

Cosa dovrebbero cercare le organizzazioni 

Nel valutare lo storage di backup, l’indicatore più importante è se il sistema è progettato con una reale mentalità Assume Breach. I sistemi che si basano su accesso privilegiato, rilevamento o immutabilità a livello software restano vulnerabili alle stesse modalità di guasto dei livelli sovrastanti. Usare una soluzione che applica Zero Access garantisce che nessuno—nemmeno un amministratore—possa eseguire azioni distruttive sui dati di backup 

Gli amministratori dei dati Backup devono pianificare lo scenario peggiore: ripristinare da un ambiente compromesso in cui tutte le credenziali sono esposte. Se tutti i segreti sono noti, lo sono anche per gli attaccanti. Il sistema di storage deve essere costruito per resistere a questa realtà. 

Altrettanto importante, le organizzazioni devono poter dimostrare questa capacità di sopravvivenza—non limitarsi a fidarsi dell’affermazione. Una piattaforma credibile consente alle organizzazioni di validare l’immutabilità, testare il ripristino in scenari distruttivi e confermare che i dati rimangono recuperabili anche quando l’ambiente è completamente compromesso. Se un fornitore limita o vieta questo tipo di test, tale limitazione diventa di per sé un segnale di sicurezza. 

Dove si dirige il settore 

Man mano che Zero Trust viene definito in modo più rigoroso, i fornitori dovranno dimostrare, non semplicemente dichiarare, come si comportano i loro sistemi in caso di compromissione completa dei privilegi. Dovranno documentare i percorsi privilegiati, provare l’immutabilità indipendente dal software di backup e mostrare la capacità di sopravvivenza quando ogni credenziale è esposta.  

Lo storage Backup deve funzionare come ultima linea di difesa, non come un altro sistema che crolla quando gli attaccanti ottengono accesso completo.