Skip to content

Punti di forza

  • Mythos accelererà probabilmente l’individuazione delle vulnerabilità, raggiungendo una portata e una velocità tali da superare i tradizionali flussi di lavoro di correzione basati sull’intervento umano.
  • Gli elementi fondamentali della sicurezza, come l’applicazione delle patch, i backup in ambiente isolato e una gestione rigorosa delle vulnerabilità, rimangono essenziali ma potrebbero non essere più sufficienti da soli.
  • La sfida principale consiste nel passare dalla semplice individuazione alla capacità di intervenire, dato che il volume delle vulnerabilità sta aumentando a ritmi tali da superare gli attuali limiti operativi.
  • La resilienza dell’IA dipende dalla capacità di ripristinare sistemi coerenti – non solo i dati – a livello di modelli, pipeline e autorizzazioni.
  • Le organizzazioni che si adegueranno in modo proattivo in questa fase iniziale avranno probabilmente un vantaggio competitivo molto maggiore rispetto a quelle che rimanderanno l’adozione di misure concrete.

Qualche settimana fa mi trovavo in una stanza con un gruppo di CIO e CISO quando la conversazione si è spostata su Mythos e Project Glasswing. L’entusiasmo è stato immediato: si tratta di persone che hanno vissuto molti cicli di hype, e questa notizia ha catturato la loro attenzione. Le reazioni si sono divise in due schieramenti. Primo: le categorie di minaccia non sono nuove – le organizzazioni con una solida gestione delle vulnerabilità e backup isolati affidabili saranno in una posizione migliore rispetto a quelle che ne sono sprovviste. Due: la velocità è diversa – non solo ciò che Mythos è in grado di individuare, ma anche la rapidità con cui gli autori di attacchi potrebbero sfruttare l’intelligenza artificiale per sferrare attacchi alla velocità delle macchine, e le conseguenze che ciò comporta per i modelli matematici su cui si basano la maggior parte dei programmi di gestione delle vulnerabilità. Avevano ragione entrambi. È proprio questo che ha reso la conversazione degna di essere raccontata.

Cosa cambia con Mythos – e cosa no

Mythos è il modello di intelligenza artificiale sviluppato da Anthropic per l’individuazione autonoma delle vulnerabilità. È in grado di individuare e concatenare exploit critici sui principali sistemi operativi con un tasso di successo che, a quanto pare, non ha precedenti in questo settore.

Il progetto Glasswing – il consorzio di aziende creato per testare e rafforzare i propri sistemi prima che Mythos o funzionalità simili finiscano nelle mani degli avversari – è il segnale che si tratta di una realtà, che è già qui, e che il margine di tempo per anticiparlo è breve. Rimane valida la visione che privilegia i fondamenti: le patch sono importanti, i backup virtualmente isolati (air-gapped) sono importanti, la disciplina nella gestione delle vulnerabilità è importante. Nulla di tutto ciò cambia con Mythos. Ciò che cambia è la velocità di produzione dall’altra parte di quei programmi. Dopo il caso Glasswing, la domanda non è se si disponga di un programma di gestione delle vulnerabilità, bensì se esso sia stato concepito per gestire risultati che arrivano a gocce o come uno tsunami. La maggior parte dei programmi è stata progettata per il flusso a gocce. Valutazioni periodiche, code di prioritizzazione basate sul CVSS, cicli di patch e test misurati in settimane. Quel ritmo aveva senso quando la velocità di individuazione corrispondeva a quella dei processi gestiti dall’uomo. Le funzionalità di classe Mythos ribaltano tale presupposto: il volume dei risultati sfruttabili potrebbe superare ciò che la maggior parte delle organizzazioni è in grado di elaborare attraverso i flussi di lavoro di cui dispone oggi. Il problema non è l’individuazione. È la capacità di agire – e ciò che accade quando il divario tra l’individuazione e la risoluzione si allarga più velocemente di quanto si riesca a colmarlo.

Quando la prevenzione viene messa in secondo piano, la resilienza prende il sopravvento

Quando i tempi dedicati alla prevenzione si riducono, la questione della resilienza passa in primo piano. Se non è possibile garantire che tutte le vulnerabilità vengano corrette prima che qualcuno ne approfitti – e sempre più spesso non è possibile farlo – le domande fondamentali cambiano: con quale rapidità si rileva l’intrusione? Come si contiene? E una volta ripristinata la situazione, a quale stato esatto si ritorna?

Quest’ultima domanda è più complessa di quanto sembri, specialmente per le organizzazioni con interazioni agentiche progressive. Un sistema di IA non è solo dati. È una versione del modello, una pipeline di addestramento, un database vettoriale, un insieme di identità e autorizzazioni degli agenti – tutti elementi che devono riflettere lo stesso stato operativo per costituire qualcosa di cui ci si possa effettivamente fidare. La maggior parte delle organizzazioni è in grado di ripristinare singoli componenti. Pochissime, invece, sono in grado di dimostrare che ciò che hanno ripristinato sia coerente.

Il ripristino di un sistema di intelligenza artificiale non è una questione di recupero dei dati. È una questione di coerenza – ed è proprio nella differenza tra queste due cose che la maggior parte delle aziende si trova attualmente vulnerabile. Questo è il filo conduttore che collega Mythos al più ampio dibattito sulla resilienza dell’intelligenza artificiale. Non è che Mythos introduca un nuovo tipo di rischio che richieda un nuovo quadro di riferimento.

Il fatto è che Mythos comprime la linea temporale in modo tale da far emergere più rapidamente le lacune esistenti, lasciando meno tempo per colmarle prima che si verifichi un problema, aumentando così la probabilità che qualcosa vada storto prima che un’organizzazione riesca a correggere adeguatamente le vulnerabilità.

La finestra è aperta. Ma non resterà così a lungo.

Glasswing è stato progettato per offrire ai difensori un vantaggio iniziale. Le organizzazioni che sfruttano consapevolmente questa opportunità – sottoponendo a stress test i propri programmi di gestione delle vulnerabilità in termini di volume, portando l’infrastruttura di resilienza basata sull’intelligenza artificiale a un livello tale da garantire la difesa e considerando il ripristino come un processo che deve essere dimostrabile prima che si verifichi un incidente, anziché essere messo a punto nel corso dello stesso – si troveranno in una posizione nettamente migliore rispetto a quelle che preferiscono aspettare. I principi fondamentali rimangono validi. È l’urgenza ad essere nuova.

“L’impresa agentica: perché la resilienza dell’IA richiede un sistema di registrazione” – l’ultimo rapporto sulla preparazione di Commvault – esamina le lacune nell’infrastruttura di resilienza dell’IA che determinano la capacità delle organizzazioni di rispondere alle difficili sfide del ripristino quando la rapidità delle minacce lo richiede.

Domande frequenti

D: Che cos’è Mythos e perché è importante?

A: Mythos è un modello di intelligenza artificiale progettato per l’individuazione autonoma delle vulnerabilità, in grado di identificare e concatenare gli exploit tra i vari sistemi a una velocità senza precedenti. La sua importanza risiede nel modo in cui riduce i tempi che intercorrono tra l’individuazione di una vulnerabilità e il suo potenziale sfruttamento, aumentando così la posta in gioco per chi si occupa della difesa.

D: Mythos cambia i principi fondamentali della sicurezza informatica?

A: No, le pratiche fondamentali come l’applicazione delle patch, i backup e la gestione delle vulnerabilità continuano ad essere importanti. Ciò che sta cambiando sono il volume e la velocità delle minacce, il che mette sotto pressione i processi esistenti, progettati per flussi di lavoro più lenti e prevedibili.

D: Perché gli attuali programmi di gestione delle vulnerabilità potrebbero incontrare delle difficoltà?

A: Molti programmi sono stati concepiti per gestire un flusso costante di risultati, non per far fronte all’ondata di scoperte resa possibile dall’intelligenza artificiale. Di conseguenza, le organizzazioni si trovano ad affrontare un divario sempre più ampio tra l’identificazione delle vulnerabilità e la loro effettiva risoluzione.

D: Cosa significa “resilienza” nel contesto dei sistemi di intelligenza artificiale?

A: La resilienza va oltre il ripristino dei dati: implica il ripristino dell’intero sistema di intelligenza artificiale in uno stato coerente e affidabile. Ciò comporta che modelli, pipeline di addestramento, database vettoriali e controlli di accesso siano tutti correttamente allineati.

D: Perché la cura sta diventando più importante della prevenzione?

A: Poiché i tempi di prevenzione si riducono a causa di un’esplorazione sempre più rapida, sta diventando irrealistico applicare tutte le patch in tempo. Ciò sposta l’attenzione sulla rapidità con cui le organizzazioni sono in grado di rilevare, contenere e riprendersi dagli incidenti.

D: In che modo le organizzazioni possono iniziare a prepararsi?

A: Le organizzazioni possono sottoporre a stress test i propri processi di gestione delle vulnerabilità, modernizzare le infrastrutture di resilienza e verificare le capacità di ripristino. Agire in questa fase iniziale offre un vantaggio strategico significativo.

Tim Zonca è vicepresidente responsabile della gestione del portafoglio presso Commvault.

More related posts

Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more

Punti di forza

  • L’IA agentica comporta nuovi rischi per la sicurezza perché pianifica, memorizza e agisce su più sistemi, anziché limitarsi a un singolo ciclo di richiesta-risposta.
  • I dati di addestramento “avvelenati” possono influenzare in modo impercettibile il comportamento del modello su larga scala, anche quando il modello sembra funzionare normalmente nei test standard.
  • I database dei vettori compromessi possono influenzare le decisioni degli agenti alterando il contesto su cui si basa il modello, facendo apparire legittimo un comportamento scorretto.
  • L’identità degli agenti non controllati crea un problema di controllo degli accessi alla velocità delle macchine che i tradizionali sistemi di identità incentrati sull’uomo non sono in grado di gestire.
  • Le decisioni a cascata basate su uno stato errato possono diffondere errori in più agenti e flussi di lavoro, rendendo molto più difficili il rollback e il ripristino.

Gli strumenti, i controlli e le politiche di governance in uso nella maggior parte delle aziende sono stati progettati per sistemi che rispondono a domande: strumenti di recupero, copiloti, assistenti generativi. Sistemi che rispondono a un prompt e poi si fermano. Quando qualcosa andava storto, il guasto era isolato. Bastava correggere il prompt, regolare la configurazione e andare avanti.

L’IA agentica non funziona in questo modo. Questi sistemi pianificano, ricordano ed eseguono operazioni in tutta l’azienda senza istruzioni umane passo dopo passo. Mantengono lo stato. Si coordinano con altri agenti. Agiscono sui sistemi di produzione: scrivono nei database, attivano flussi di lavoro, prendono decisioni alla velocità delle macchine. Questo cambiamento architettonico introduce quattro vettori di minaccia che i sistemi di sicurezza esistenti non sono mai stati progettati per affrontare. Se la vostra strategia di governance dell’IA non ne tiene conto, è probabile che siate esposti a rischi di cui forse non vi rendete conto.

1. Dati di addestramento contaminati

Un sistema di IA è affidabile solo quanto i dati con cui è stato addestrato. Questa affermazione è sempre stata vera. Ciò che è cambiato è la superficie di attacco.

Nelle implementazioni di IA agentica, le pipeline di addestramento sono più ampie, più complesse e spesso assemblate da più fonti: dati interni, feed di terze parti, set di dati forniti dai fornitori. Ogni dipendenza in quella catena è un potenziale punto di iniezione. Un attore malintenzionato in grado di influenzare i dati di addestramento – attraverso la compromissione della catena di approvvigionamento, l’accesso da parte di personale interno o la contaminazione di una fonte di dati condivisa – può plasmare il comportamento del modello su larga scala. Ciò che rende questa situazione particolarmente pericolosa è che i modelli “avvelenati” spesso danno risultati normali nei benchmark standard. La manipolazione può essere “chirurgica”: progettata per produrre risultati specifici in contesti specifici, pur comportandosi correttamente in ogni altro caso.

Quando l’effetto si manifesta in produzione, il modello è già in uso da settimane o mesi, e risalire alla fonte della contaminazione richiede proprio quel tipo di tracciabilità relazionale dei dati di cui la maggior parte delle organizzazioni non dispone. La domanda da porsi è: siete in grado di fornire una documentazione completa e verificabile dei dati utilizzati per l’addestramento dei vostri modelli, in un determinato momento?

2. Banche dati vettoriali compromesse

I database vettoriali costituiscono il livello di memoria dei sistemi agentici. Prima di agire, un agente interroga un archivio vettoriale per recuperare il contesto pertinente – interazioni passate, conoscenze di dominio, dati di riferimento – che determina la sua azione successiva. La maggior parte dei team di sicurezza non considera i database vettoriali alla stregua di altri archivi di dati sensibili. E invece dovrebbero farlo. Un database vettoriale compromesso non si limita a restituire risposte errate. Influenza le decisioni che ne conseguono. Gli embedding iniettati – contenuti malevoli inseriti nell’archivio vettoriale – possono reindirizzare il comportamento dell’agente in modi che dall’esterno appaiono del tutto legittimi.

Un agente a cui viene chiesto di approvare una transazione recupera un contesto che riformula sottilmente i criteri di approvazione. Un agente che gestisce le comunicazioni con i clienti estrae un contesto che orienta le risposte nella direzione preferita dall’autore dell’attacco. L’azione sembra corretta. Il ragionamento sembra valido. Ma il contesto sottostante è stato manipolato.

Questo vettore di attacco è particolarmente difficile da rilevare perché opera al di sotto del livello del modello. Il monitoraggio standard del modello non lo individua. Il modello si comporta esattamente come addestrato: è il contesto su cui basa il proprio ragionamento ad essere stato corrotto. La domanda da porsi è: il vostro database vettoriale viene considerato una risorsa di dati sensibile e soggetta a regole di governance, con controlli di accesso, monitoraggio dell’integrità e registrazione degli audit paragonabili a quelli dei vostri database di produzione più critici?

3. Identità degli agenti non governati

In un’architettura multi-agente, gli agenti non si limitano a interagire con i dati, ma interagiscono anche tra loro. Generano subagenti, delegano compiti, richiedono output e sintetizzano i risultati provenienti da agenti con cui non sono mai stati esplicitamente collegati. Per farlo, effettuano l’autenticazione, presentano le credenziali e instaurano un rapporto di fiducia.

L’identità degli agenti costituisce il livello di controllo degli accessi per l’impresa autonoma – ed è una lacuna che i fornitori di soluzioni per la sicurezza delle identità e i provider di identità (IDP) non riescono a colmare. I loro modelli di governance sono concepiti per l’identità umana.

Le identità degli agenti create secondo quelle stesse regole appaiono del tutto legittime: sono state configurate correttamente e hanno rispettato la politica aziendale. L’IDP non sta fallendo: semplicemente non dispone di uno schema per determinare se un agente stia agendo al di fuori del contesto per cui è stato creato, se i suoi privilegi siano stati silenziosamente ampliati o se stia coordinando attività dove non dovrebbe.

Questa vulnerabilità è qualitativamente diversa dalla tradizionale compromissione delle credenziali. Quando le credenziali di un utente umano vengono rubate, l’autore dell’attacco agisce entro i limiti delle autorizzazioni di quell’utente, alla velocità di un essere umano. Quando l’identità di un agente viene compromessa, l’autore dell’attacco ottiene l’accesso al livello decisionale autonomo: la capacità di avviare flussi di lavoro, approvare azioni, coordinarsi con altri agenti ed esfiltrare dati alla velocità di una macchina, su larga scala, attraverso canali che appaiono del tutto normali.

I fallimenti a livello di identità sono anche tra i più difficili da rilevare a posteriori. Le azioni degli agenti intraprese con un’identità compromessa non appaiono anomale: sembrano comportamenti legittimi degli agenti. E poiché sono generate da un sistema anziché da un essere umano, il volume può diventare enorme prima che qualcuno se ne accorga.

Recovery aggrava il problema. La maggior parte delle procedure di Recovery dell’IA si concentra sul ripristino dei dati: set di addestramento, pesi dei modelli, configurazioni delle pipeline. L’identità è raramente inclusa nell’elenco. Un sistema ripristinato con dati puliti ma con configurazioni di identità disallineate non è in realtà ripristinato. Si tratta di un sistema pulito con un livello di accesso compromesso. La domanda da porsi è: l’identità degli agenti viene gestita con lo stesso rigore dell’identità umana, ovvero con la gestione del ciclo di vita, l’accesso con privilegi minimi e l’inclusione nei piani di ripristino?

4. Decisioni a cascata basate su una situazione errata

I primi tre vettori di attacco sono isolati. Questo invece è sistemico – e per molti versi può rivelarsi il più difficile da contenere. Le architetture multi-agente sono progettate per il coordinamento. Gli agenti condividono il contesto, si scambiano gli output e si basano sul lavoro reciproco. È proprio quel coordinamento a renderli potenti. Ed è anche ciò che fa propagare i guasti.

Un agente che opera su una memoria corrotta non fallisce in modo netto. Produce output – decisioni, azioni, dati – che vengono utilizzati da altri agenti. Questi agenti, a loro volta, producono i propri output. Quando la corruzione originale emerge come qualcosa di osservabile, lo stato errato potrebbe aver già interessato decine di processi a valle, su più agenti, senza un percorso di rollback netto.

È proprio questo che rende il divario contestuale così significativo. In ogni momento, il vostro sistema di IA è costituito da una versione del modello, un insieme di dati di addestramento, un archivio di artefatti, una configurazione della pipeline e un insieme di interazioni attive degli agenti – tutti elementi che devono riflettere lo stesso stato operativo per costituire un sistema affidabile e recuperabile. Quando ciò non avviene, non si tratta semplicemente di un errore. Si ha un sistema che è coerente nelle singole parti ma incoerente nel suo insieme. Ciascuno degli strumenti puntuali può verificare la propria porzione di dati. Nessuno di essi è in grado di confermare che i vari elementi siano correlati tra loro. Non si tratta di un problema di monitoraggio risolvibile semplicemente aggiungendo un altro strumento. È una lacuna strutturale, e l’unico modo per colmarla è un sistema in grado di registrare lo stato dell’IA in modo relazionale: cosa era in esecuzione, su quali dati, con quale configurazione e in quale momento.

La domanda da porsi è questa: se oggi la vostra infrastruttura di intelligenza artificiale venisse compromessa, sareste in grado di identificare con esattezza lo stato in cui si trovava ogni componente prima dell’incidente – e di dimostrarlo?

Cosa significa questo per la vostra strategia di sicurezza

Ciascuno di questi quattro vettori richiede una risposta difensiva diversa. Tuttavia, essi condividono un’implicazione comune: i quadri di governance e resilienza concepiti per la precedente era dell’IA non coprono le modalità di fallimento dell’era degli agenti. Per garantire un’IA agentica è necessario estendere il proprio framework in tre direzioni:

  • Più in profondità, nei livelli dei dati e dell’identità che si trovano al di sotto del modello.
  • Più ampio, in modo da coprire le interazioni tra agenti che il monitoraggio attuale non rileva.
  • Dal punto di vista relazionale, per cogliere non solo lo stato dei singoli componenti, ma anche il modo in cui questi si integrano tra loro in qualsiasi momento.

Quest’ultimo requisito è quello che la maggior parte delle organizzazioni non ha ancora affrontato. Ed è proprio quello che determinerà se, quando qualcosa andrà storto, si avrà a disposizione un sistema recuperabile o una serie di report apparentemente accurati che descrivono qualcosa che non esiste più. Leggi “The Agentic Blind Spot: Why AI Resilience Demands a System of Record” per scoprire perché è necessario un SOR per garantire la coerenza e l’accuratezza dei tuoi dati di IA.

Domande frequenti

D: Perché i sistemi di IA agentica sono più rischiosi rispetto ai tradizionali strumenti di IA generativa?

A: I sistemi agentici non si limitano a rispondere ai prompt. Gestiscono lo stato, si coordinano con altri agenti e intraprendono azioni negli ambienti di produzione, il che amplia la superficie di attacco ben oltre la semplice manipolazione dei prompt.

D: Perché è così difficile individuare i dati di addestramento contaminati?

A: La manipolazione può essere altamente mirata, influenzando solo situazioni specifiche senza alterare i normali valori di riferimento. Ciò significa che un modello può sembrare funzionante fino a quando il comportamento dannoso non si manifesta nell’uso reale.

D: In che modo un database vettoriale può rappresentare un problema di sicurezza?

A: Un database vettoriale definisce il contesto su cui si basa un agente prima di agire. Se tale contesto viene alterato, l’agente potrebbe prendere decisioni che a prima vista sembrano ragionevoli, ma che in realtà sono influenzate da dati dannosi.

D: Perché l’identità di un agente è diversa dall’identità umana?

A: L’identità di un agente è legata alle azioni autonome, alla delega e all’esecuzione alla velocità di una macchina. La governance tradizionale dell’identità è concepita per le persone, quindi spesso non rileva se un agente stia agendo al di fuori del contesto previsto.

D: Perché la propagazione a cascata di stati anomali rappresenta un problema così grave nei sistemi multi-agente?

A: Quando un agente elabora un output corrotto, l’errore può propagarsi agli agenti e ai flussi di lavoro a valle. Il risultato non è solo una decisione errata, ma una catena di errori concatenati.

D: In che modo le organizzazioni possono migliorare la sicurezza dell’IA?

R: Estendere la governance fino ai livelli dei dati e delle identità, monitorare le interazioni tra agenti e tenere traccia dello stato dell’IA in modo relazionale, per consentire loro di ricostruire ciò che è accaduto durante un incidente.

Michael Thelander è direttore senior del marketing di prodotto presso Commvault.

Blog correlati

More related posts

Thumbnail_Blog-Data-Access-Governance-2026

Securing AI with Unified Data Access Governance

Read more
Thumbnail_Blog-Environmental-Footprint-AI-2026

Smarter Data, Greener AI

Read more
Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more
Thumbnail_Blog-AI-Agents-2026

AI Agents Are Everywhere. Do You Know What They’re Doing?

Read more
Thumbnail_Blog-Building-AI-Agents-2026

From Experimentation to Operation: Building AI Agents You Can Actually Trust

Read more

Punti di forza

  • I sistemi di IA agenziale sono sensibili allo stato e operano in modo continuo, rendendo insufficienti i modelli di ripristino tradizionali.
  • Il livello di memoria (database vettoriali e archiviazione del contesto) rappresenta una superficie di attacco critica ma poco monitorata.
  • I flussi di lavoro relativi al processo decisionale in tempo reale possono essere modificati senza attivare i tradizionali avvisi di sicurezza.
  • Le lacune nell’osservabilità delle interazioni tra agenti impediscono alla maggior parte delle organizzazioni di avere una visione completa dei rischi.
  • Una vera e propria ripristinazione richiede una registrazione unificata e sincronizzata nel tempo di tutti i livelli del sistema per ripristinare uno stato affidabile.

La maggior parte delle imprese che stanno entrando nell’era dell’IA agentica gestisce la resilienza con un modello mentale errato – e i dati lo confermano: solo 1 azienda su 5 dispone di un modello maturo per la governance degli agenti IA autonomi. Queste aziende considerano l’IA alla stregua delle applicazioni: entità discrete, senza stato, recuperabili ripristinando dati integri in un ambiente integro.

L’IA agentica non funziona in questo modo. Questi sistemi sono con stato, operano in modo continuo e sono strutturati a livelli in modi che creano modalità di guasto che la maggior parte dei framework di sicurezza e resilienza non è stata progettata per affrontare. Il divario non sta negli strumenti. Sta nella comprensione di ciò che sta effettivamente funzionando – e di cosa debba significare “Recovery” per sistemi costruiti in questo modo.

Ci sono quattro livelli architetturali che definiscono il problema. Ognuno è distinto. Ognuno è insufficientemente protetto. E insieme spiegano perché un sistema di IA agentica possa sembrare recuperabile pur rimanendo fondamentalmente compromesso.

Livello 1: Memoria dell’agente – La superficie di attacco che non stai monitorando

Le applicazioni aziendali tradizionali non conservano alcuna informazione tra una sessione e l’altra. L’Agentic AI invece sì. Il livello di memoria – costituito principalmente da database vettoriali che memorizzano gli embedding, ma anche lo stato della sessione e il contesto recuperato – è ciò che garantisce agli agenti la continuità tra le interazioni. È ciò che permette a un agente di riprendere da dove aveva interrotto, di attingere al contesto precedente e di costruire nel tempo un quadro coerente di un flusso di lavoro complesso.

Si tratta inoltre di una delle superfici di attacco più rilevanti nello stack aziendale moderno – e una delle meno monitorate. Il vettore di attacco è abbastanza sottile da eludere la maggior parte degli strumenti di sicurezza convenzionali. Un avversario in grado di influenzare ciò che viene scritto in un database vettoriale può plasmare ciò che l’agente ritiene vero. Gli embedding iniettati o manipolati non devono necessariamente sembrare dannosi: devono sembrare autorevoli.

Una memoria compromessa può alterare il comportamento dell’agente, sottrarre dati tramite le azioni dell’agente o indurre l’agente a prendere decisioni che sembrano legittime ma che in realtà favoriscono gli obiettivi dell’autore dell’attacco. Tutto ciò avviene senza dover modificare il modello stesso. Il problema del rilevamento è aggravato dal volume e dalla velocità delle scritture nei database vettoriali nelle implementazioni attive degli agenti. Gli strumenti di rilevamento delle anomalie progettati per i dati strutturati non si adattano bene allo spazio degli embedding. Il segnale c’è, ma la maggior parte delle organizzazioni non è in grado di interpretarlo.

Ciò che la resilienza richiede in questo caso è un monitoraggio continuo dell’integrità dei database vettoriali, non solo un backup. Embedding con controllo delle versioni e una catena di custodia dimostrabile. La capacità di identificare, in qualsiasi momento, esattamente ciò che il livello di memoria conteneva e di ripristinare uno stato verificato e pulito, non solo uno recente.

Livello 2: Controllo in fase di esecuzione – Quando il flusso di lavoro rappresenta una minaccia

L’IA agentica non esegue script prestabiliti. Pianifica. Durante l’esecuzione, un agente riceve un obiettivo, determina i passaggi necessari per raggiungerlo, seleziona gli strumenti di cui ha bisogno e agisce, spesso generando sottoagenti per gestire flussi di lavoro paralleli. Il flusso di lavoro è dinamico, costruito sul momento e spesso di lunga durata.

È proprio questo che rende l’IA agentica davvero utile. Ed è anche ciò che la rende davvero difficile da proteggere. In un ambiente di automazione convenzionale, un flusso di lavoro compromesso ha dei limiti. Esegue ciò per cui è stato configurato e poi si interrompe. Un flusso di lavoro agentico compromesso è diverso: si adatta.

Se un aggressore riesce a influenzare il livello di pianificazione – tramite un prompt compromesso, una risposta manipolata dello strumento o un modello di pianificazione danneggiato – l’agente perseguirà l’obiettivo dell’aggressore utilizzando qualsiasi strumento e accesso legittimo a sua disposizione. L’operazione apparirà come normale. I log, nella misura in cui esistono, mostreranno chiamate autorizzate agli strumenti. Si consideri un agente di approvvigionamento incaricato di convalidare le fatture dei fornitori in base ai termini contrattuali. In condizioni di funzionamento normale, controlla gli importi delle fatture, verifica le soglie di approvazione e segnala le eccezioni per la revisione umana. Un malintenzionato in grado di influenzare il livello di pianificazione – tramite una risposta manipolata dello strumento proveniente dal database dei contratti – non ha bisogno di intervenire direttamente sulla logica di approvazione. È sufficiente che fornisca all’agente un record di contratto con soglie modificate. L’agente pianifica correttamente sulla base di input corrotti. Ogni chiamata allo strumento che effettua è legittima. Ogni decisione a cui giunge è errata. Quando l’anomalia emerge durante una riconciliazione finanziaria, il flusso di lavoro ha già elaborato settimane di fatture e la traccia di audit mostra solo azioni autorizzate.

In questi scenari, l’intervallo di tempo tra la compromissione e il rilevamento non si misura in secondi. I flussi di lavoro basati su agenti operano in modo continuo. Quando i risultati anomali vengono alla luce, il flusso di lavoro potrebbe aver interessato decine di sistemi, preso centinaia di decisioni e lasciato modifiche negli ambienti di produzione difficili da enumerare e ancora più difficili da annullare.

Ciò che la resilienza richiede in questo caso: un monitoraggio in tempo reale che osservi ciò che gli agenti stanno decidendo, non solo ciò che stanno facendo. Meccanismi di intervento in grado di arrestare in modo pulito un flusso di lavoro in esecuzione senza causare guasti a cascata. Procedure di Recovery progettate per processi basati su agenti di lunga durata – non solo per transazioni discrete.

Livello 3: Osservabilità agentica – Il divario nella registrazione dei log alla velocità delle macchine

L’infrastruttura di logging aziendale è stata progettata per operazioni su scala umana. Registra le attività dei sistemi con un livello di granularità e una latenza pensati per la revisione umana. L’IA agenziale opera invece a una velocità completamente diversa.

In un’implementazione multi-agente attiva, gli agenti generano subagenti, si scambiano il contesto, effettuano chiamate agli strumenti e sintetizzano i risultati – in modo continuo, in parallelo e a una velocità superiore a quella per cui sono state progettate le pipeline di logging convenzionali. Le interazioni più rilevanti per la sicurezza – comunicazioni tra agenti, passaggi di contesto, richiami di strumenti che superano i confini di fiducia – sono proprio quelle che i sistemi di monitoraggio esistenti trascurano maggiormente.

Oggi, solo il 17% delle aziende monitora costantemente le interazioni tra agenti. L’altro 83% gestisce l’IA agentica basandosi su un quadro parziale, che rileva ciò che fanno i singoli agenti in modo isolato, ma tralascia il livello delle interazioni, dove si verificano gli eventi di sicurezza più rilevanti.

Non si tratta di un divario che possa essere colmato aumentando il volume dei dati di log. Il problema non risiede nella quantità di dati acquisiti, bensì nel fatto che le strutture dei dati e i requisiti di latenza delle interazioni basate su agenti non si adattano bene ai framework di osservabilità progettati per sistemi più lenti e strutturati. Per colmare questo divario sono necessari strumenti di osservabilità specifici per gli agenti oppure un significativo adeguamento dell’infrastruttura esistente.

Ciò che la resilienza richiede in questo caso: visibilità end-to-end sulle interazioni tra agenti, non solo sugli output dei singoli agenti. Architetture di registrazione in grado di operare alla velocità degli agenti senza perdere eventi. La capacità di ricostruire, a posteriori, la sequenza completa delle decisioni e delle interazioni degli agenti per un dato flusso di lavoro.

Livello 4: Coordinamento multi-agente – Dove si nascondono i guasti emergenti

Il rischio più innovativo dal punto di vista architettonico nell’IA agentica non deriva da un singolo agente compromesso, bensì dal modo in cui gli agenti dipendono gli uni dagli altri – e dal modo in cui i malfunzionamenti si propagano attraverso tali dipendenze prima che qualcuno si accorga che qualcosa non va. In un’architettura multi-agente, gli agenti condividono il contesto. Un agente orchestratore trasmette le istruzioni relative a un’attività a un sottoagente; il sottoagente restituisce un risultato che l’orchestratore integra nella sua decisione successiva.

Se l’output del subagente è corrotto – a causa di un livello di memoria compromesso, di una risposta manipolata dello strumento o di un modello di pianificazione compromesso – l’orchestratore non dispone di alcun meccanismo nativo per rilevarlo. Considera l’output come attendibile. Lo integra. Agisce in base ad esso. E trasmette a valle il proprio output, ormai compromesso.

Si tratta della modalità di guasto emergente: una compromissione che ha origine in un livello, si propaga attraverso le interazioni tra agenti e si manifesta come un risultato anomalo in un sistema a diversi livelli di distanza dalla compromissione iniziale. Quando diventa visibile, la catena causale è ormai lunga e il raggio d’azione è significativo.

Si consideri una pipeline di intelligence sulle minacce in cui un agente di raccolta dati acquisisce i feed provenienti da fonti esterne, un agente di classificazione li categorizza e assegna loro un punteggio, e un orchestratore integra le informazioni valutate nelle raccomandazioni relative allo stato di sicurezza che vengono trasmesse ai team a valle. Se il livello di memoria dell’agente di raccolta dati viene compromesso – in modo subdolo, tramite embedding iniettati che lo inducono a classificare determinati attori malevoli come a basso rischio – l’agente di classificazione riceve input che non ha motivo di mettere in discussione. Esso classifica accuratamente in base a ciò che gli viene fornito.

L’orchestratore integra i risultati con fiducia. I team di sicurezza a valle attribuiscono una priorità inferiore alla categoria di minaccia in questione sulla base di quello che sembra un consenso coerente e proveniente da più fonti. Il guasto ha avuto origine nel Livello 1. Si è manifestato nel Livello 4. Nulla nei livelli intermedi ha segnalato un’anomalia perché nulla in essi aveva visibilità sull’intera catena.

I quadri di governance che la maggior parte delle imprese applica all’IA sono stati progettati per gli output dei modelli – ciò che l’IA “dice”. I fallimenti nel coordinamento tra più agenti non sono fallimenti degli output dei modelli. Si tratta di fallimenti di sistema, derivanti dal livello di interazione tra i modelli, e richiedono un diverso tipo di governance: una governance che monitori e controlli non solo il comportamento dei singoli agenti, ma anche le relazioni di fiducia tra gli agenti, l’integrità del contesto man mano che passa da uno all’altro e i diritti di accesso che regolano ciò che un agente può richiedere a un altro.

Ciò che la resilienza richiede in questo caso: una gestione dell’identità degli agenti che consideri la fiducia tra agenti una priorità assoluta in materia di sicurezza. La verifica dell’integrità del contesto mentre si sposta oltre i confini degli agenti. Politiche di governance che coprano il comportamento degli agenti autonomi – non solo i risultati dei singoli modelli.

Il problema relazionale che accomuna tutti e quattro

Questi quattro livelli presentano modalità di malfunzionamento distinte, ma condividono una vulnerabilità comune: nessuno di essi dispone di una documentazione condivisa che illustri le relazioni reciproche in un determinato momento.

Il registro dei modelli sa quale versione è in esecuzione. Il database vettoriale sa cosa c’è in memoria. Il livello di orchestrazione sa quale flusso di lavoro è attivo. Il sistema di identità sa quali agenti dispongono di quali diritti di accesso. Ciascuno può confermare la propria porzione del quadro d’insieme. Nessuno può confermare se tali porzioni siano coerenti tra loro – se riflettano lo stesso stato operativo, lo stesso momento, la stessa configurazione affidabile.

Ecco qual è il divario contestuale. Ed è per questo che il ripristino a seguito di una compromissione da parte di un’IA agente non è un problema di ripristino dei dati. È un problema di coerenza, che richiede una registrazione unificata delle relazioni tra i livelli, non solo dei componenti stessi. Colmate questa lacuna prima che si verifichi un incidente, oppure passate l’intero incidente a cercare di colmarla.

Le sfide architetturali qui trattate rappresentano solo una parte di ciò che i responsabili della sicurezza e della resilienza devono comprendere riguardo al rischio legato all’IA agentica. “L’angolo cieco dell’IA agentica: perché la resilienza dell’IA richiede un sistema di registrazione” va oltre, esaminando a che punto si trovino effettivamente la maggior parte delle aziende in termini di preparazione alla resilienza dell’IA, quali siano le lacune di governance nella pratica e cosa serva per rendere l’affermazione «la nostra IA è affidabile» una dichiarazione dimostrabile, non solo un’asserzione.

Domande frequenti

D: Perché il disaster recovery tradizionale non funziona con l’IA agentica?

A: Il ripristino tradizionale presuppone che i sistemi siano privi di stato e possano essere ripristinati a partire da backup integri. I sistemi di IA basati su agenti conservano la memoria, si evolvono nel tempo e dipendono da interazioni a più livelli, rendendo insufficiente un semplice ripristino per riconquistare la fiducia.

D: Cosa rende vulnerabile il livello di memoria nell’IA agentica?

A: Il livello di memoria memorizza gli embedding e i dati contestuali che influenzano le decisioni dell’agente. Se compromesso, gli aggressori possono manipolare in modo impercettibile ciò che l’agente “crede”, portando ad azioni errate ma apparentemente legittime.

D: In che modo gli hacker possono sfruttare i flussi di lavoro in fase di esecuzione nell’IA basata su agenti?

A: Gli autori degli attacchi possono influenzare i dati di input, i prompt o le risposte degli strumenti, inducendo gli agenti a eseguire azioni dannose tramite processi legittimi. Queste azioni spesso appaiono normali nei log, rendendo difficile il loro rilevamento.

D: Perché l’osservabilità rappresenta una sfida nei sistemi multi-agente?

A: I sistemi basati su agenti operano alla velocità della macchina, con interazioni continue tra gli agenti. I sistemi di registrazione tradizionali non sono progettati per acquisire o elaborare un livello di attività così dinamico e ad alta frequenza.

D: Cosa si intende per “guasti emergenti” negli ambienti multi-agente?

A: I guasti emergenti si verificano quando una piccola vulnerabilità in un agente o in un livello si propaga tra agenti interconnessi, causando problemi su larga scala di cui è difficile risalire alla fonte originaria.

D: Come si presenta un recupero efficace per un’IA agentica?

A: Un ripristino efficace non si limita al semplice recupero dei dati, ma richiede un’istantanea coerente di tutti i livelli del sistema, tra cui memoria, flussi di lavoro, identità e interazioni, allineata a uno stato verificato e affidabile.

Tim Zonca è vicepresidente responsabile della gestione del portafoglio presso Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Far crescere un’azienda basata sui dati è difficile. Farla crescere rispettando i requisiti del GDPR, gestendo migliaia di clienti, supportando i team di analisi e implementando una nuova infrastruttura in meno di due settimane? Questo è un livello di complessità completamente diverso.

In una recente puntata di STRIVE, ho incontrato Asif Dromi di monday.com e Ben Herzberg di Commvault per approfondire cosa serva davvero per rendere operativa la sicurezza dei dati su larga scala – non in teoria, ma nella pratica. Non si tratta di una conversazione astratta sulle best practice, ma di uno sguardo concreto su come le decisioni relative a sicurezza, conformità, automazione e infrastruttura si intrecciano quando il tempo stringe.

Guarda l’episodio completo. Se sei un CISO, un responsabile dei dati, un architetto o un responsabile della conformità, questa puntata ti offre qualcosa di più prezioso della semplice teoria. Ti mostra come:

  • Un’azienda in rapida crescita ha gestito le sfide poste dal GDPR senza frenare l’innovazione.
  • L’approccio “Infrastructure as Code” può semplificare gli audit.
  • L’automazione riduce i rischi anziché aumentare la complessità.
  • La sicurezza e l’agilità aziendale non devono necessariamente essere in contrasto tra loro.

È raro poter ascoltare direttamente gli operatori che hanno affrontato questa sfida in condizioni di reale difficoltà. È proprio questo che rende speciale questa conversazione nell’ambito di STRIVE.

Punti chiave: Rendere operativa la sicurezza dei dati su larga scala

  • Conformità e crescita non devono necessariamente essere in contrasto. Monday.com dimostra come i requisiti del GDPR e una rapida espansione possano coesistere quando la sicurezza è integrata nell’architettura fin dall’inizio.
  • Le autorizzazioni manuali non sono scalabili. L’automazione sì. L’infrastruttura come codice e i controlli di accesso basati su API possono trasformare la governance da un collo di bottiglia a un moltiplicatore di forza.
  • L’accesso basato sui ruoli deve evolversi di pari passo con l’utilizzo dei dati. Man mano che un numero crescente di team fa affidamento sull’analisi dei dati, la visibilità e i controlli granulari assumono un’importanza fondamentale per aiutare a prevenire la proliferazione incontrollata delle autorizzazioni.
  • La sicurezza operativa significa visibilità. Non si tratta solo di definire politiche, ma anche di monitorare, verificare e adattare dinamicamente i controlli man mano che gli ambienti cambiano.
  • La velocità è possibile quando l’architettura è progettata in modo mirato. Un data warehouse conforme alle normative europee è stato realizzato in meno di due settimane perché la governance, l’automazione e gli strumenti erano stati progettati per essere scalabili.
  • La maturità in materia di sicurezza favorisce l’innovazione. Quando le autorizzazioni, l’infrastruttura e la conformità sono programmabili, le organizzazioni possono agire con maggiore rapidità.

La vera sfida: crescita + conformità + velocità

Per monday.com, la sfida non consisteva semplicemente nell’archiviare i dati europei in Europa. Si trattava piuttosto di:

  • Garantire la conformità al GDPR e la residenza dei dati a livello regionale.
  • Garantire che i dipendenti avessero accesso solo ai dati pertinenti.
  • Garantire la visibilità e la verificabilità.
  • A supporto di analisti e sviluppatori che necessitavano di un accesso rapido.
  • Il tutto nel rispetto di scadenze lavorative molto serrate.

Come spiega Asif nella puntata, diventare un’organizzazione basata sui dati comporta una rapida espansione degli accessi interni. Più i team si affidano all’analisi dei dati, più complesse diventano le autorizzazioni. Ed è proprio qui che molte organizzazioni si scontrano con un ostacolo. La sicurezza diventa un’attività manuale, le autorizzazioni diventano fragili e la conformità diventa reattiva. Questa non è sicurezza operativa. È un castello di carte.

Integrare la sicurezza nell’architettura fin dal primo giorno 

Uno degli aspetti più interessanti dell’episodio è il modo in cui monday.com ha affrontato il problema dal punto di vista architettonico. Anziché adeguare il sistema a posteriori per renderlo conforme, ha realizzato:

  • Un data warehouse europeo dedicato.
  • Controlli di accesso chiari basati sui ruoli.
  • Modelli di autorizzazione dettagliati.
  • Livelli di governance automatizzati.

Ben descrive ciò che accade in molte grandi organizzazioni: con il passare del tempo, le autorizzazioni si accumulano a strati, spesso senza una visibilità centrale. Alla fine, nessuno è più sicuro di chi possa accedere a cosa. Rendere operativa la sicurezza significa evitare questa deriva. Significa costruire sistemi in cui la governance si adatta automaticamente man mano che l’utilizzo cresce.

L’automazione è un moltiplicatore di forza

Se c’è un tema che ricorre in questo episodio, è l’automazione. Invece di trattare le autorizzazioni come ticket e aggiornamenti manuali, monday.com ha integrato la propria infrastruttura nel codice. Database, ruoli e politiche di accesso potevano essere creati e modificati a livello di programmazione.

Il risultato? Un ambiente conforme e scalabile è stato messo in piedi in meno di due settimane. Non è fortuna. È l’architettura. Ed è un potente promemoria del fatto che la sicurezza non rallenta il lavoro quando è costruita correttamente. Anzi, favorisce la velocità.

Cosa significa davvero rendere operativa la sicurezza dei dati

Il termine “operazionalizzazione” viene usato molto spesso. In questa puntata, viene definito come:

  • Visibilità costante sui dati sensibili.
  • Gestione centralizzata e automatizzata delle autorizzazioni.
  • Monitoraggio degli accessi.
  • Integrazione con gli strumenti di collaborazione.
  • Politiche che si adattano man mano che il numero di utenti e il volume dei dati aumentano.

I controlli statici non sono scalabili. I flussi di lavoro manuali non sono scalabili. La sicurezza deve diventare dinamica, parte integrante del tessuto operativo dell’organizzazione. Ed è proprio in questo cambiamento che molte aziende incontrano difficoltà oggi.

Guarda l’episodio completo di STRIVE

Durante la discussione, potrete approfondire i seguenti argomenti:

  • Come monday.com ha strutturato il proprio data warehouse europeo.
  • Le lezioni più importanti apprese durante l’implementazione rapida.
  • Perché l’automazione era imprescindibile.
  • Ciò che le aziende spesso sottovalutano riguardo alla proliferazione delle autorizzazioni.
  • Come affrontare la questione dell’attuazione della governance prima che le iniziative relative all’intelligenza artificiale prendano piede.

Guardalo subito.

Domande frequenti 

D: In che modo i team di piccole dimensioni possono implementare una sicurezza dei dati scalabile?

A: Inizia con un modello di autorizzazioni ben definito e strumenti di “infrastruttura come codice”. Automatizza fin da subito la gestione delle autorizzazioni per evitare colli di bottiglia dovuti alle operazioni manuali man mano che l’azienda cresce.

D: Che ruolo svolge l’automazione nella conformità?

R: L’automazione contribuisce a garantire la coerenza, a ridurre gli errori e a semplificare le verifiche. Utilizzando API e script, è possibile monitorare e modificare le autorizzazioni in modo dinamico.

D: Quanto tempo occorre in genere per creare un ambiente dati conforme e scalabile?

R: Con una pianificazione adeguata e gli strumenti giusti, aziende come monday.com ci sono riuscite in meno di due settimane. La rapidità dipende dalla portata del progetto e dall’infrastruttura esistente.

D: Quali sono le migliori pratiche per garantire la sicurezza dei dati a livello operativo?

A: Implementare controlli di accesso basati sui ruoli, automatizzare la gestione delle autorizzazioni, monitorare regolarmente i registri di accesso e integrare gli strumenti di sicurezza con le piattaforme di collaborazione per garantire un controllo in tempo reale.

Chris Mierzwa è direttore senior del marketing di portafoglio presso Commvault.

More related posts

Thumbnail_Blog-GoogleWorkspace-2026

Expanding Google Workspace Protection with Commvault eDiscovery

Read more
Thumbnail_Blog-Data-Leakage-Loops-2026

Are You Ready for Data Leakage Loops?

Read more
Thumbnail_Blog-Tornado-2025-Linkedin

The Trust Tightrope: Why New Yorkers Demand More from Businesses Than They Do from Themselves

Read more
Thumbnail_Blog_FinServ-Cybersecurity-2025

Modernizing Financial Cybersecurity: From Reactive to Resilient

Read more

Punti di forza

  • I quadri normativi in materia di conformità codificano gli insegnamenti tratti dai fallimenti verificatisi nella realtà e aiutano le organizzazioni a rafforzare la resilienza, la governance e la stabilità operativa.
  • Le organizzazioni che considerano la conformità come un’iniziativa volta a rafforzare la fiducia possono contribuire a consolidare la fiducia dei clienti, i rapporti con i partner e la credibilità del marchio.
  • L’allineamento normativo e solidi controlli dei rischi possono contribuire a migliorare i risultati nel settore assicurativo, dimostrando un approccio alla sicurezza maturo e resiliente.
  • Mappare i requisiti di conformità a risultati aziendali misurabili consente alle organizzazioni di collegare direttamente gli investimenti nella resilienza alla protezione dei ricavi e alla continuità operativa.
  • Le capacità di resilienza informatica, quali i backup immutabili, il ripristino rapido e i quadri di governance, aiutano le organizzazioni a trasformare la conformità in un vantaggio competitivo.

Nelle sale del consiglio di amministrazione di tutta Europa e non solo, il termine “conformità” è diventato una parola dal significato carico di connotazioni. Evoca immagini di documentazione infinita, pressioni normative sempre più intense e la minaccia incombente di sanzioni.

GDPR. NIS2. DORA. Gli acronimi si susseguono senza sosta e, per molte organizzazioni, può sembrare di essere sommerse dalle normative. Ma se avessimo considerato la conformità da una prospettiva sbagliata? E se la conformità non servisse solo a evitare sanzioni, ma anche a costruire un’azienda migliore, più forte e più resiliente?

L’analogia con le assicurazioni: regole che esistono per un motivo

Esiste un utile parallelo tra la conformità normativa e l’assicurazione. Quando assicuri la tua auto, l’assicuratore stabilisce determinate condizioni. I freni devono funzionare. Gli pneumatici non devono essere lisci. Potrebbe essere richiesto un sistema di allarme. Puoi lamentarti dell’inconveniente o del costo, ma fondamentalmente quelle regole esistono perché aiutano a ridurre il rischio. Contribuiscono a rendere gli incidenti meno probabili. Aiutano a proteggere sia te che gli altri.

Ed ecco il punto fondamentale: tali requisiti sono solitamente una buona idea, indipendentemente dal fatto che si stipuli o meno l’assicurazione. La regolamentazione funziona più o meno allo stesso modo. I governi e le autorità di regolamentazione non creano quadri normativi perché ne traggono piacere. Le normative sono risposte a fallimenti del mondo reale: violazioni dei dati, interruzioni operative, rischio sistemico. Codificano le lezioni apprese a caro prezzo.

Potreste opporvi a questo onere. Potreste trovarlo frustrante. Ma se si esamina attentamente ciò che questi quadri normativi richiedono, è difficile sostenere che i principi fondamentali siano errati.

  • Proteggere i dati dei clienti.
  • Garantire la resilienza operativa.
  • Conosci i rischi della tua catena di approvvigionamento.
  • Essere in grado di riprendersi dagli incidenti informatici.
  • Dimostrare capacità di gestione e responsabilità.

Nessuna di queste è una cattiva idea.

Da come evitare le multe a come instaurare un clima di fiducia

Troppo spesso, la conformità viene presentata in chiave difensiva: «Fai così per non ricevere una multa». «Fai così per non finire in prigione». È un obiettivo modesto. Ed è un’occasione persa. Se cambiamo prospettiva, la conformità assume un significato molto più importante. Diventa un fattore che favorisce la fiducia.

Prendiamo ad esempio il GDPR. In sostanza, si tratta di proteggere i dati personali. Se la vostra organizzazione adotta solide pratiche di protezione dei dati – non solo per spuntare una casella, ma perché i vostri sistemi salvaguardano realmente le informazioni dei clienti – ciò crea fiducia. I clienti si sentono più sicuri nel fare affari con voi. I partner sono più disposti a integrarsi con voi. Le autorità di regolamentazione vi considerano un rischio minore. La fiducia non è un risultato normativo. È un vantaggio commerciale.

Lo stesso vale per il Digital Operational Resilience Act. Non si tratta solo di segnalare gli incidenti, ma di essere in grado di resistere alle interruzioni e riprendersi da esse. In un mondo in cui gli attacchi informatici sono inevitabili, la resilienza non è facoltativa. È fondamentale per la continuità, la reputazione e il valore a lungo termine. Quando la conformità favorisce la resilienza, la resilienza favorisce la stabilità aziendale – e la stabilità favorisce la crescita.

Regolamentazione e assicurazioni: un circolo virtuoso

Esiste inoltre un naturale allineamento tra la regolamentazione e i mercati assicurativi. Quando le autorità di regolamentazione impongono determinati standard, gli assicuratori si adeguano rapidamente. Le organizzazioni che dimostrano conformità e solidi controlli dei rischi risultano più attraenti per gli assicuratori. Possono beneficiare di condizioni migliori, di una copertura più ampia o di premi più vantaggiosi. Questo crea un circolo vizioso:

  • Il regolamento stabilisce gli standard minimi.
  • Le organizzazioni rafforzano i propri controlli.
  • Le compagnie assicurative premiano chi adotta un approccio più prudente nei confronti del rischio.
  • I mercati diventano più stabili e resilienti.

In questo contesto, la conformità diventa un segnale per il mercato: prendiamo sul serio il rischio.

L’anello mancante: collegare la conformità ai risultati aziendali

Una delle opportunità più importanti per le organizzazioni – in particolare per i fornitori di tecnologia – è quella di rendere esplicito il nesso tra conformità e valore aziendale. Ad esempio:

  • Se un prodotto crea backup immutabili, ciò contribuisce a soddisfare i requisiti normativi in materia di integrità dei dati.
  • Se ciò consente un rapido ripristino a seguito di incidenti informatici, contribuisce al rispetto dei requisiti in materia di resilienza operativa.
  • Se garantisce una tracciabilità chiara delle operazioni e una rendicontazione adeguata, ciò contribuisce a soddisfare i requisiti di governance e supervisione.

Ma non ci si dovrebbe fermare qui. Il passo successivo consiste nel definire il vantaggio aziendale:

  • I backup immutabili contribuiscono a ridurre l’impatto del ransomware e a proteggere il fatturato.
  • Un ripristino più rapido contribuisce a ridurre al minimo i tempi di inattività e a mantenere la fiducia dei clienti.
  • Una solida governance contribuisce a ridurre i controlli normativi e rafforza la credibilità del marchio.

Questa mappatura è fondamentale. La conformità non è l’obiettivo finale, ma il meccanismo che consente di ottenere i risultati a cui le aziende tengono: continuità, reputazione, fiducia dei clienti e differenziazione competitiva.

La conformità come innovazione, non come obbligo

Si tende spesso a considerare la conformità come un semplice “adempimento burocratico”. Un centro di costo. Un male necessario. Ma se guardiamo alla storia, molte delle migliori pratiche che oggi sono considerate fondamentali per l’IT e la sicurezza moderne hanno avuto origine da requisiti normativi o assicurativi. Nel corso del tempo, sono diventate parte integrante del modo di operare delle organizzazioni ben gestite. Crittografia. Controlli di accesso. Pianificazione della risposta agli incidenti. Test di continuità operativa. Gestione dei rischi di terze parti. Un tempo, questi aspetti potevano essere considerati un onere normativo. Oggi, invece, sono requisiti imprescindibili per qualsiasi impresa che si rispetti. Le organizzazioni che trattano la conformità come un catalizzatore di innovazione – piuttosto che come un semplice esercizio burocratico – sono spesso quelle che si distinguono. Incorporano la resilienza nella loro architettura. Progettano tenendo conto della governance. Trasformano i requisiti normativi in funzionalità dei prodotti e proposte di valore per i clienti.

Resilienza informatica: dove la conformità e la strategia si incontrano

È proprio qui che cyber resilience un ruolo centrale. Le normative moderne riconoscono sempre più una semplice verità: la prevenzione non basta. Gli incidenti si verificheranno. Ciò che fa la differenza è la capacità di un’organizzazione di reagire e riprendersi.

La resilienza informatica – la capacità di resistere alle interruzioni informatiche, di riprendersi da esse e di adattarsi – non è più solo una questione di sicurezza. È un imperativo strategico. Supporta la conformità normativa, certo. Ma, cosa ancora più importante, è alla base della continuità operativa e della fiducia nel business. Quando le organizzazioni investono in architetture resilienti, dati immutabili, capacità di ripristino rapido e solidi quadri di governance, non si limitano a soddisfare i requisiti delle autorità di regolamentazione. Stanno costruendo imprese durature.

Una prospettiva diversa sulla conformità

Forse è giunto il momento di cambiare prospettiva. Invece di chiederci: «Qual è il minimo che dobbiamo fare per essere in regola?», dovremmo chiederci:

  • In che modo questo regolamento ci rende più forti?
  • Quale buona pratica viene qui codificata?
  • Come possiamo sfruttare questo aspetto per rafforzare la fiducia dei clienti e dei partner?
  • In che modo ciò determina un vantaggio competitivo?

Una corretta conformità non è una questione di paura, ma di lungimiranza. Riflette gli insegnamenti tratti da diversi settori. Integra le migliori pratiche nelle operazioni quotidiane. E quando viene chiaramente collegato alle funzionalità del prodotto e ai risultati aziendali, diventa una potente storia commerciale.

Sì, le normative possono sembrare un peso. Sì, gli acronimi si susseguono senza sosta. Ma al di là delle scartoffie si nasconde qualcosa di molto più prezioso: un quadro di riferimento per gestire al meglio la propria attività. La conformità non significa solo evitare sanzioni. Significa garantire la resilienza. E la resilienza, in definitiva, è ciò che determina il successo sostenibile. Scopri di più su come Commvault garantisce la protezione dei dati per aiutare la tua organizzazione a soddisfare i requisiti di conformità qui.

Domande frequenti

D: Perché le organizzazioni dovrebbero considerare la conformità come qualcosa di più di un semplice obbligo normativo?

A: I quadri normativi in materia di conformità riflettono spesso le migliori pratiche sviluppate in risposta a incidenti informatici reali, malfunzionamenti operativi e sfide di governance. Le organizzazioni che adottano un approccio strategico alla conformità possono contribuire a rafforzare la resilienza, migliorare la fiducia e creare valore aziendale a lungo termine.

D: In che modo la conformità contribuisce a rafforzare la fiducia dei clienti?

A: Adottare solide pratiche di conformità dimostra che un’organizzazione prende sul serio la protezione dei dati, la governance e la continuità operativa. Ciò può contribuire ad accrescere la fiducia dei clienti, a rafforzare i rapporti con i partner e a posizionare l’organizzazione come un’azienda a basso rischio.

D: Qual è il legame tra conformità e cyber resilience?

A: Le normative moderne si concentrano sempre più sulla capacità di un’organizzazione di riprendersi dalle interruzioni piuttosto che limitarsi a prevenirle. Gli investimenti in infrastrutture resilienti, backup immutabili e capacità di ripristino rapido possono aiutare le organizzazioni a garantire la continuità operativa durante gli incidenti informatici.

D: In che modo la conformità può influire positivamente sul settore assicurativo e sulla gestione dei rischi?

R: Le organizzazioni dotate di programmi di conformità consolidati e di solidi controlli di sicurezza sono spesso viste con maggiore favore dagli assicuratori. Ciò può tradursi in migliori opzioni di copertura, condizioni contrattuali più vantaggiose e, potenzialmente, premi più bassi.

D: Perché è importante collegare le iniziative di conformità ai risultati aziendali?

A: Le iniziative di conformità risultano più efficaci quando le organizzazioni dimostrano chiaramente in che modo i controlli contribuiscano al raggiungimento di obiettivi più ampi, quali la tutela dei ricavi, la riduzione dei tempi di inattività e il mantenimento della fiducia dei clienti. Ciò aiuta la dirigenza a considerare la conformità come un investimento strategico piuttosto che come un centro di costo.

Domanda 6: In che modo le organizzazioni possono trasformare la conformità in un vantaggio competitivo?

A: Le aziende che integrano resilienza, governance e sicurezza nei propri prodotti e nelle proprie operazioni possono distinguersi sul mercato. Allineandosi in modo proattivo alle aspettative normative, le organizzazioni possono rafforzare la propria reputazione e infondere maggiore fiducia nei clienti e negli stakeholder.

Darren Thomson è Field CTO presso Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Punti di forza

  • La sovranità operativa verte su chi può accedere ai sistemi e sotto quali giurisdizioni questi operano.
  • L’accesso dei fornitori, i flussi di telemetria e i canali di assistenza possono creare lacune nascoste in materia di sovranità.
  • La sovranità operativa è più difficile da certificare perché richiede visibilità e controlli continui.
  • Le organizzazioni devono essere in grado di dimostrare e documentare ogni percorso di accesso agli ambienti sovrani.

Se si chiede alla maggior parte delle organizzazioni in quale ambito il loro programma di sovranità sia più solido, la risposta è solitamente una variante delle stesse due cose: localizzazione dei dati e crittografia. Sanno dove risiedono i loro dati primari. Hanno implementato accordi del tipo “bring-your-own-key” o “hold-your-own-key”. Possono indicare le certificazioni.

Chiedete loro chi abbia avuto accesso al loro ambiente sovrano negli ultimi novanta giorni, da quali paesi e sotto quali giurisdizioni legali – e la fiducia tenderà a svanire. La sovranità operativa è il pilastro più difficile da sottoporre a verifica, il più soggetto a sottovalutazione e il punto in cui più comunemente una posizione di sovranità che sembra solida sulla carta crolla nella pratica. Il Digital Sovereignty Readiness Report la indica come uno dei quattro pilastri – questo post va oltre. La domanda a cui la maggior parte delle organizzazioni non sa rispondere: «Chi ha avuto accesso al vostro ambiente sovrano negli ultimi 90 giorni, da quali paesi e sotto quali giurisdizioni legali?»

Cosa significa realmente “sovranità operativa”

La sovranità operativa non riguarda il luogo in cui risiedono i dati. Riguarda chi gestisce l’ambiente e chi può accedervi. Comprende tre aspetti che la maggior parte dei programmi di sovranità considera dettagli di implementazione piuttosto che questioni di primaria importanza:

  • Accesso del personale e giurisdizione. Ogni persona in grado di accedere al vostro ambiente sovrano – per attività di assistenza, manutenzione, monitoraggio o risposta agli incidenti – opera nell’ambito di una giurisdizione legale definita. Se un tecnico dell’assistenza in un paese soggetto a una legge straniera sull’accesso ai dati può accedere ai vostri sistemi, la sovranità della vostra infrastruttura è limitata dall’esposizione legale di tale tecnico.

La maggior parte delle organizzazioni, quando effettua questa verifica per la prima volta, individua almeno un percorso di supporto che attraversa un confine giurisdizionale che non era stato mappato.

  • Accesso di terze parti e fornitori. Il confine della vostra sovranità si estende a ogni fornitore, provider di servizi gestiti e platform software platform accesso al vostro ambiente sovrano. Piattaforme ITSM, strumenti di monitoraggio, sistemi SIEM: se questi si trovano al di fuori del confine della vostra sovranità ma hanno accesso a dati o metadati al suo interno, esiste una lacuna che i controlli sulla località dei dati non possono colmare.
  • Traffico di telemetria, fatturazione e piano di controllo. I programmi di sovranità dei dati si concentrano sui dati primari. La sovranità operativa richiede invece di mappare la destinazione di tutto il resto: la telemetria generata dalla vostra infrastruttura, i metadati raccolti dai vostri sistemi di monitoraggio, i dati di fatturazione elaborati dal vostro provider. Questi flussi possono attraversare i confini giurisdizionali anche quando i dati primari non lo fanno – e raramente vengono mappati.

Perché questo pilastro è più difficile da certificare – e perché è importante

La località dei dati è relativamente semplice da documentare. È possibile indicare una regione di archiviazione, un accordo di residenza dei dati, una verifica da parte di terzi. La sovranità operativa non dispone della stessa documentazione cartacea. Non esiste una certificazione che garantisca lo status giurisdizionale di ogni tecnico di supporto che potrebbe accedere al proprio ambiente.

È proprio questo che lo rende sia il pilastro più difficile da verificare sia quello più importante da gestire correttamente. Ciò si ricollega inoltre direttamente alla sfida della “sovranità minima necessaria”: applicare i controlli operativi giusti ai carichi di lavoro giusti richiede di sapere quali siano tali controlli – ed è proprio nell’ambito della sovranità operativa che tale conoscenza è più spesso carente.

La dimensione della catena di approvvigionamento

Il regolamento NIS2, che estende gli obblighi in materia di sicurezza informatica ai settori dell’energia, dei trasporti, della sanità e delle infrastrutture digitali, impone ora alle organizzazioni di valutare le pratiche di sicurezza informatica dei propri fornitori di tecnologia. Per i programmi di sovranità, ciò ha un’implicazione diretta: l’approccio dei fornitori in materia di sovranità non è più un semplice elemento di cortesia negli appalti, ma un requisito verificabile.

Ciò significa porre nuove domande a ogni fornitore all’interno del proprio perimetro di sovranità: Dove si trova il vostro personale di supporto? Sotto quale giurisdizione legale opera? Cosa succede all’accesso di cui dispone al mio ambiente se la vostra azienda venisse acquisita da un’entità non UE?

Come si presenta una buona soluzione

Un ambiente operativamente sovrano presenta quattro caratteristiche che possono essere dimostrate, non solo documentate:

  • Viene mappata ogni via di accesso all’ambiente sovrano: non solo l’accesso principale, ma anche quello dei fornitori, quello del supporto tecnico e quello dei sistemi di monitoraggio.
  • Lo stato giuridico di ogni persona o sistema che dispone di tale accesso viene documentato e sottoposto a verifica a intervalli prestabiliti.
  • I flussi di traffico relativi alla telemetria, ai metadati e al piano di controllo vengono inventariati e, a seconda dei casi, sono contenuti entro i confini della sovranità oppure vengono esplicitamente valutati e accettati come fuori dall’ambito di applicazione.
  • L’organizzazione è in grado di rispondere alla domanda relativa all’accesso entro novanta giorni – in modo preciso, fornendo prove.

Un’ultima cosa: la sovranità operativa non si limita al controllo degli accessi. Se il ripristino richiede l’intervento di personale che opera al di fuori dei confini della vostra sovranità, la strategia fallisce nel momento stesso in cui si verifica un incidente. Questo sarà l’argomento del quarto articolo di questa serie. Il Rapporto sulla preparazione alla sovranità digitale include una domanda di valutazione diretta sulla sovranità operativa.

Domande frequenti

D: Che cos’è la sovranità operativa?

A: La sovranità operativa riguarda chi gestisce e chi ha accesso a un ambiente, compreso il personale, i fornitori e i sistemi di supporto. Va oltre il luogo in cui sono archiviati i dati.

D: Perché la sovranità operativa viene spesso trascurata?

A: Molte organizzazioni si concentrano principalmente sulla localizzazione e sulla crittografia dei dati. Spesso, invece, i percorsi di accesso, il personale di supporto e i flussi di telemetria non vengono sottoposti a un controllo completo.

D: In che modo i fornitori influenzano la posizione in materia di sovranità?

A: I fornitori e i fornitori di servizi gestiti potrebbero avere accesso a sistemi sensibili o a metadati. Le loro giurisdizioni e le loro prassi operative possono influire sulla conformità complessiva in materia di sovranità.

D: Perché la telemetria e i metadati sono importanti?

A: Anche se i dati primari rimangono a livello locale, i dati telemetrici e i metadati possono attraversare i confini giurisdizionali. Se non gestiti, questi flussi possono comportare rischi in termini di conformità.

D: Cosa comprende un modello di forte sovranità operativa?

A: Comprende percorsi di accesso mappati, controlli giurisdizionali documentati, accesso dei fornitori sottoposto a verifica e visibilità su tutti i flussi di telemetria e metadati.

Alex Zinin è vicepresidente e direttore generale della divisione Managed Service Providers presso Commvault.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Punti di forza

  • Le architetture sovrane spesso danno priorità agli audit e ai controlli di accesso rispetto alla prontezza al ripristino.
  • Il personale addetto al ripristino, i sistemi di backup e i modelli di custodia delle chiavi possono creare lacune nella sovranità durante gli incidenti.
  • È fondamentale garantire controlli coerenti sia nell’ambiente primario che in quello di ripristino.
  • Una resilienza a prova di sovranità richiede procedure di ripristino collaudate in condizioni realistiche.

Immaginate la situazione. L’attacco è già avvenuto. Il team di risposta agli incidenti si sta riunendo. Qualcuno deve decidere quali sistemi ripristinare per primi, in quale ordine, utilizzando i punti di Recovery corretti.

E poi qualcuno si rende conto che: il personale che ha accesso al sistema di ripristino ha sede in un altro Paese. Peggio ancora, l’ambiente di ripristino stesso (ospitato in una cloud , in un data center di un partner o in un sito secondario) non è mai stato soggetto agli stessi controlli di sovranità dei dati primari. La pratica non era soggetta agli stessi controlli di sovranità dei dati primari. L’autorità di regolamentazione sta chiedendo informazioni sullo stato della situazione. Il tempo stringe.

Questo è lo scenario per cui la maggior parte delle architetture sovrane non è stata progettata – ed è proprio quello che il Rapporto sulla preparazione alla sovranità digitale evidenzia chiaramente: la maggior parte delle applicazioni sovrane è progettata per l’audit, non per gli incidenti. La maggior parte delle applicazioni di sicurezza è progettata per l’audit, non per gli incidenti. La differenza emerge nel momento peggiore possibile.

Il punto cieco della ripresa nell’architettura sovrana

I programmi di sovranità sono costruiti attorno al controllo degli accessi: chi può accedere ai dati, con quale autorizzazione, attraverso quale percorso. Tale architettura è necessaria. Ma non è sufficiente. E si ricollega direttamente alle lacune operative in materia di sovranità esaminate nel terzo articolo di questa serie: se le persone che gestiscono il vostro ambiente operano al di fuori dei confini della vostra sovranità, quel problema non scompare durante un incidente. Diventa il problema.

Ciò che il controllo degli accessi lascia in sospeso è la domanda più complessa: cosa succede dopo un incidente, quando il ripristino non è solo un’operazione tecnica, ma è soggetto a vincoli legali?

Un attacco ransomware ai danni di un’organizzazione europea soggetta a regolamentazione non comporta semplicemente un problema di ripristino. Comporta un problema di ripristino che deve essere risolto nell’ambito di una giurisdizione specifica, avvalendosi di personale in possesso delle autorizzazioni appropriate e utilizzando punti di ripristino di cui sia possibile dimostrare che siano integri e non compromessi. L’architettura sovrana progettata per proteggere i dati può rendere più difficile il ripristino se la resilienza non è stata integrata nella progettazione originale.

Le modalità specifiche di guasto

I modi in cui le architetture di recupero sovrano falliscono sono prevedibili – e comuni:

  • Personale addetto al Recovery al di fuori dei confini di sovranità. Gli ingegneri che conoscono i sistemi di Recovery potrebbero operare in una giurisdizione diversa. Sotto pressione, ricorrere a loro rappresenta la via più facile. Si tratta inoltre di una violazione della sovranità proprio nel momento in cui è meno opportuno che ciò avvenga.
  • Infrastruttura di backup priva di controlli adeguati. Gli ambienti primari soggetti a requisiti di sovranità sono attentamente controllati. L’infrastruttura di backup – in particolare gli ambienti più datati o secondari – spesso non è soggetta agli stessi requisiti di sovranità. Se i punti di ripristino vengono archiviati o elaborati al di fuori dei confini previsti, non è possibile effettuare un ripristino conforme a partire da un’infrastruttura conforme.
  • Custodia delle chiavi in situazioni di crisi. Le modalità di gestione delle chiavi in cui ciascuno ne detiene una propria sono concepite per le operazioni di routine. In situazioni di crisi – con i sistemi primari compromessi e tempi estremamente ristretti – il modello di custodia delle chiavi che funziona durante una finestra di manutenzione ordinaria può diventare un ostacolo al ripristino. Se non è stato testato, si tratta di un’ipotesi, non di un controllo.
  • Lacune nella governance tra ambienti diversi. Le organizzazioni che operano su più livelli sovrani – ovvero la maggior parte di esse – spesso dispongono di controlli rigorosi negli ambienti primari e di controlli meno rigorosi negli ambienti secondari, che fanno comunque parte del percorso di ripristino. La coerenza nell’intero parco sistemi è ciò che gli auditor verificheranno. Le lacune negli ambienti secondari diventano evidenti proprio quando la coerenza è più importante.

Perché i controlli sulla sovranità possono complicare la ripresa

Gli stessi controlli che rendono un ambiente sovrano difendibile di fronte a un revisore possono rendere più difficile il Recovery. Le restrizioni al movimento dei dati che impediscono l’esfiltrazione non autorizzata limitano anche l’orchestrazione del Recovery. Gli accordi chiave di custodia che garantiscono che nessun fornitore possa accedere ai dati senza autorizzazione aggiungono ulteriore attrito quando è necessario il Recovery rapido.

Ciò non significa affatto che questi controlli siano sbagliati. Significa piuttosto che devono essere progettati fin dall’inizio tenendo conto del ripristino, e non aggiunti a un’architettura in cui il ripristino è stato considerato solo in un secondo momento. Questo è il fulcro del principio della “sovranità minima praticabile”: calibrare i controlli in base alle esigenze effettive significa includere i requisiti di ripristino, non solo quelli relativi al controllo degli accessi.

Cosa richiede una resilienza orientata alla sovranità

  • Convalida del ripristino pulito. Dimostrare che i punti di ripristino siano integri prima di ripristinare l’ambiente di produzione – non solo recenti, ma integri. In uno scenario di ransomware, anche un backup recente potrebbe essere compromesso. La capacità di identificare e ripristinare da un punto di ripristino notoriamente integro, convalidato prima che sia necessario, è un requisito di sovranità, non solo un requisito di disaster recovery.
  • Governance trasversale agli ambienti. Controlli di sovranità e prove di audit coerenti in tutto il parco informatico, non solo nell’implementazione sovrana primaria. Ogni ambiente presente nel percorso di ripristino deve soddisfare gli stessi requisiti dell’ambiente primario.
  • Testati in condizioni realistiche. Esercitazioni periodiche che verificano la capacità di ripristino nelle condizioni che si verificheranno effettivamente durante un incidente: i vincoli normativi applicabili, il personale disponibile, i punti di ripristino funzionanti. Un test annuale di ripristino di emergenza che non tenga conto dei vincoli di sovranità non è un’esercitazione adeguata ai requisiti di sovranità.

La domanda da aggiungere alla tua analisi sulla sovranità

Esiste un modo diretto per verificare se la vostra architettura di ripristino soddisfa gli stessi requisiti di sovranità del vostro ambiente dati primario: ponete la domanda e pretendete una risposta sincera. Siete in grado di recuperare i vostri dati sovrani, in modo accurato, entro i limiti di tolleranza definiti, avvalendovi di personale che opera all’interno dei confini della vostra sovranità, proprio ora – in condizioni reali, non nell’ambito di un’esercitazione controllata?

Per la maggior parte delle organizzazioni, una risposta sincera mette in luce una lacuna. Le organizzazioni che la individuano ora – prima che si verifichi l’incidente – saranno meglio preparate a fornire le prove richieste dall’autorità di regolamentazione. Quelle che non lo faranno dovranno metterle insieme sotto pressione, davanti alle persone che meno vorrebbero deludere. Il Rapporto sulla preparazione alla sovranità digitale include una domanda relativa alla valutazione dell’architettura di ripristino diretto.

Domande frequenti

D: Perché la resilienza è importante per la sovranità digitale?

A: La sovranità è incompleta se le organizzazioni non sono in grado di recuperare i dati all’interno degli stessi confini giuridici e operativi utilizzati per proteggerli.

D: Quali sono i comuni fallimenti nel Recovery sovrano?

A: Tra i guasti più comuni figurano l’intervento del personale addetto al ripristino al di fuori dei confini della sovranità, infrastrutture di backup prive di controlli adeguati e una governance non uniforme tra i vari ambienti.

D: In che modo la custodia delle chiavi può complicare Recovery?

A: I modelli basati sulla gestione autonoma delle chiavi rafforzano la sicurezza durante il normale funzionamento, ma possono rallentare le operazioni di ripristino in caso di incidenti se non vengono testati adeguatamente.

D: Che cos’è la convalida del ripristino pulito?

A: La convalida del ripristino pulito conferma che i punti di ripristino non siano stati compromessi prima del ripristino dei sistemi. Ciò è particolarmente importante in caso di attacchi ransomware.

D: In che modo le organizzazioni dovrebbero verificare la propria resilienza in vista della sovranità?

A: Dovrebbero condurre esercitazioni realistiche che tengano conto dei vincoli legali, della disponibilità operativa e dei punti di ripristino convalidati – non limitarsi a semplici test standard di ripristino di emergenza.

Alex Zinin è vicepresidente e direttore generale della divisione Managed Service Providers presso Commvault.

More related posts

Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Punti di forza

  • La sovranità minima necessaria (MVS) si concentra sull’applicazione del giusto livello di controllo ai carichi di lavoro appropriati.
  • Trattare tutti i carichi di lavoro allo stesso modo può comportare complessità e costi superflui o una protezione insufficiente.
  • Le organizzazioni rientrano in genere in tre profili di sovranità: sovranità totale, impresa regolamentata e multi-cloud ibrido.
  • Una governance coerente in ambienti misti rappresenta una delle maggiori sfide operative.

Esiste una versione del dibattito sulla sovranità digitale che porta le organizzazioni verso una soluzione costosa, gravosa dal punto di vista operativo e – se si è onesti – che va oltre quanto richiesto dai loro effettivi obblighi. La sovranità massima sembra una scelta responsabile. In pratica, spesso si tratta di una valutazione errata.

Esiste una versione altrettanto comune che conduce a una situazione pericolosamente precaria: controlli che soddisfano una checklist ma non supererebbero un audit, un incidente o un’autorità di regolamentazione che ha smesso di accettare l’intenzione documentata come prova di un controllo dimostrato.

Le organizzazioni che gestiscono correttamente la sovranità tendono ad adottare un approccio più rigoroso e più pratico rispetto a entrambi gli estremi: si chiedono cosa devono effettivamente garantire, a chi e per cosa. Quindi si adeguano a tale standard – né più, né meno.

Questa è la disciplina dell’MVS, introdotta nel «Digital Sovereignty Readiness Report» e sviluppata in modo esaustivo in questa sede.

L’MVS non è una scorciatoia. È il riconoscimento che l’obiettivo è il giusto livello di controllo, applicato in modo coerente a ogni carico di lavoro che lo richieda.

Non tutti i carichi di lavoro sono uguali

Il punto di partenza per un approccio MVS è la classificazione dei carichi di lavoro – e la maggior parte delle organizzazioni la salta completamente.

Un sistema di trading che elabora dati finanziari regolamentati comporta obblighi di sovranità fondamentalmente diversi rispetto a uno strumento interno di collaborazione delle risorse umane. Un database che contiene dati personali di cittadini dell’UE è soggetto a un regime giuridico e normativo diverso rispetto a un ambiente di sviluppo che esegue dati di test anonimizzati.

Trattare tutti questi casi in modo identico – sia applicando i massimi controlli di sovranità in modo generalizzato, sia partendo dal presupposto che un unico modello di implementazione copra ogni esigenza – è il modo in cui le organizzazioni finiscono per essere o sovradimensionate o insufficientemente protette.

La domanda giusta da porsi prima di qualsiasi decisione di implementazione è: cosa richiede questo carico di lavoro in ciascuno dei quattro pilastri della sovranità? Il Rapporto di Readiness include un’autovalutazione strutturata proprio attorno a questa domanda.

I tre profili – e ciò di cui hanno effettivamente bisogno

Le imprese soggette a regolamentazione rientrano in tre profili ben definiti, ciascuno con motivazioni principali e priorità di investimento diverse.

  • Il vero sovrano. Agenzie governative, appaltatori della difesa e gestori di infrastrutture nazionali critiche. Per queste organizzazioni, la sovranità non è un requisito di conformità: è un mandato operativo. Il massimo controllo su ogni dimensione dello stack tecnologico è spesso richiesto per legge, e i compromessi in termini di costi sono accettati perché l’alternativa non lo è.
  • L’organizzazione regolamentata. Società di servizi finanziari, organizzazioni sanitarie, aziende energetiche. Queste organizzazioni devono far fronte a requisiti vincolanti previsti da DORA, NIS2, GDPR e quadri normativi specifici di settore. Gli obblighi di conformità possono anche ricadrere sotto schemi di certificazione UE – tra cui EUCS, EUCC, BSI C5 e SecNumCloud – a seconda del settore e del contesto di implementazione.

In alcuni ambiti ciò è imprescindibile – in particolare per quanto riguarda la residenza dei dati, i controlli operativi sugli accessi e Recovery entro i confini giurisdizionali. Ma non tutti i carichi di lavoro comportano lo stesso obbligo.

  • L’organizzazione ibrida multi-cloud. Organizzazioni con investimenti esistenti in hyperscaler che devono affrontare una crescente pressione in materia di sovranità da parte di clienti, autorità di regolamentazione o requisiti di appalto. La loro sfida non è la migrazione totale, ma l’integrazione di controlli di sovranità in un ambiente misto e il mantenimento di una governance coerente in tutto l’ambiente.

Il costo di una calibrazione errata

Un approccio eccessivo alla sovranità crea rischi operativi propri. Le organizzazioni che applicano controlli di sovranità massimi a carichi di lavoro che non li richiedono si accollano costi e complessità che non servono a nessuno scopo normativo o aziendale.

Un approccio insufficiente è la modalità di fallimento più comune, e anche la più pericolosa. In genere non si manifesta fino all’arrivo dell’audit – o, cosa ancora più grave, fino a quando non si verifica un incidente e Recovery diventa un problema soggetto a vincoli legali. (Tale modalità di fallimento è l’argomento del quarto articolo di questa serie.)

Un punto di partenza pratico

Un approccio MVS prevede tre passaggi:

  1. Classificare i carichi di lavoro in base ai loro effettivi requisiti di sovranità in ciascun pilastro – non partire dai modelli di distribuzione.
  2. Mappare ciascuna classe di carico di lavoro al livello di implementazione che soddisfa tali requisiti, nell’intero spettro che va dalle regioni degli hyperscaler pubblici al cloud pubblico sovrano fino agli ambienti gestiti on-premise.
  3. Gestire in modo coerente l’infrastruttura mista risultante: i controlli, le prove di audit e le capacità di Recovery devono essere dimostrabili in tutto l’ambiente, non solo nel livello con la massima sovranità.

È proprio la terza fase quella in cui la maggior parte dei programmi incontra difficoltà. Mantenere controlli di sovranità coerenti in un ambiente misto rappresenta una sfida di governance operativa – e in particolare rientra nell’ambito della sovranità operativa – argomento del terzo articolo di questa serie, il pilastro che la maggior parte delle strategie considera come un aspetto secondario.

Utilizzate l’autovalutazione contenuta nel Rapporto sulla Readiness alla sovranità digitale per individuare la vostra posizione attuale rispetto a tutti e quattro i pilastri.

Domande frequenti

D: Che cos’è la sovranità minima praticabile (MVS)?

R: L’MVS è la pratica di applicare controlli di sovranità basati sulle effettive esigenze aziendali e normative. Ha lo scopo di aiutare a evitare sia un eccesso di ingegnerizzazione che una protezione insufficiente.

D: Perché è importante la classificazione dei carichi di lavoro?

R: Carichi di lavoro diversi comportano obblighi normativi e operativi diversi. La classificazione dei carichi di lavoro aiuta le organizzazioni ad applicare il livello appropriato di controlli di sovranità.

D: Quali sono i tre profili di sovranità più comuni?

R: I tre profili sono: organizzazioni veramente sovrane, organizzazioni regolamentate e organizzazioni ibride multi-cloud. Ciascuna presenta requisiti operativi e di conformità distinti.

D: Quali rischi derivano da un approccio eccessivamente ingegnerizzato alla sovranità?

R: Controlli eccessivi possono aumentare la complessità operativa e i costi senza apportare un valore significativo in termini di conformità o di business.

D: Perché gli ambienti misti creano sfide di governance?

R: Le organizzazioni operano spesso su più modelli di cloud e infrastrutture. È difficile mantenere controlli, prove di audit e standard di Recovery coerenti in tutti gli ambienti.

Ruben Renders è Solutions Director, MSP, presso Commvault.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Punti di forza

  • La residenza dei dati indica il luogo in cui questi sono archiviati, ma la sovranità digitale richiede anche il controllo sull’accesso, sulle operazioni e una corretta comprensione delle implicazioni giurisdizionali.
  • La sovranità operativa è spesso l’aspetto più debole e meno sottoposto a verifica della maggior parte dei programmi di sovranità.
  • Una posizione di sovranità completa si basa su quattro pilastri: la località dei dati, la sovranità tecnologica, la sovranità operativa e la sovranità giurisdizionale.
  • La sovranità non è una questione binaria; le organizzazioni devono definire una strategia in linea con i propri obblighi normativi e operativi.

Ecco una domanda su cui vale la pena riflettere: quando la vostra organizzazione ha preso la decisione sulla propria sovranità, cosa ha deciso esattamente? Per la maggior parte, la risposta è una variante dello stesso concetto. Scegliere una regione. Spostare i carichi di lavoro. Scegliere un fornitore di servizi cloud con data center nel Paese. Spuntare la casella. La questione della localizzazione dei dati ha trovato una risposta e il dibattito sulla sovranità è stato considerato chiuso.

Ma non era finita. Era appena iniziata. La residenza dei dati risponde a una domanda: dove? La sovranità digitale ne pone altre tre: chi, come e a quali condizioni? La confusione tra residenza e sovranità è comprensibile. Gli hyperscaler hanno fatto sì che la scelta della regione sembrasse una decisione in materia di sovranità. Le checklist di conformità chiedono dove sono archiviati i dati. Le linee guida normative, almeno nelle loro prime versioni, si concentravano fortemente sull’aspetto geografico.

La scelta di una cloud sovrana è una questione seria: è importante, ha implicazioni operative ed è un primo passo necessario. Ma è solo un primo passo. E la maggior parte delle organizzazioni si è fermata lì.

A cosa non risponde il programma di residenza

Pensateci in questo modo: scegliere una regione cloud sovrana è come acquistare una cassaforte. Vi dice dove sono conservati i vostri oggetti di valore. Non dice nulla su chi possiede una copia della combinazione, chi ha prodotto la cassaforte, quali leggi nazionali regolano il produttore, né se potete aprirla se costretti a farlo.

La scelta della regione risponde a una domanda. Ne rimangono altre tre del tutto aperte – ed è proprio su queste che le autorità di regolamentazione, le commissioni di appalto e i revisori stanno ora ponendosi domande con crescente precisione:

  • Chi può gestire il vostro ambiente e da dove? Il fatto che il personale di assistenza del vostro fornitore di servizi cloud sia soggetto a una giurisdizione straniera è una questione di sovranità che la residenza dei dati non può risolvere. Una finestra di manutenzione ordinaria eseguita da un tecnico dell’assistenza in una giurisdizione diversa è una via di accesso che la vostra politica di residenza non copre. Questo è il dominio della sovranità operativa: il pilastro più difficile da verificare e quello più comunemente trascurato.
  • In base a quale regime giuridico è possibile accedere ai vostri dati? Il fatto che un fornitore di tecnologia straniero gestisca le proprie infrastrutture sul territorio nazionale non esclude automaticamente l’applicazione della legislazione del proprio Paese d’origine. La portata extraterritoriale dei regimi giuridici stranieri rappresenta un rischio che la sola posizione geografica non può eliminare.
  • È possibile recuperare i dati se qualcosa va storto? La maggior parte dei programmi di sovranità è incentrata sul controllo degli accessi. Pochissimi affrontano la questione del Recovery: ovvero se i dati possano essere ripristinati in modo corretto, entro tolleranze definite, da personale che opera all’interno dei confini della vostra sovranità. È proprio in questa lacuna che le strategie di sovranità falliscono più comunemente in condizioni reali.

Il quadro di riferimento che colma il divario

Una strategia completa in materia di sovranità si articola su quattro pilastri interdipendenti. Il «Rapporto sulla preparazione alla sovranità digitale» – disponibile su readiverse.com – ne illustra ciascuno in modo esaustivo. In breve:

  • La località dei dati indica i percorsi effettivi seguiti dai dati e dai metadati.
  • La sovranità tecnologica comprende il controllo sulla crittografia, la custodia delle chiavi e la portabilità dell’architettura.
  • La sovranità operativa riguarda chi gestisce l’ambiente e da dove.
  • La sovranità giurisdizionale definisce il quadro giuridico che disciplina e disciplina tutti gli aspetti sopra citati.

Nessun pilastro è sufficiente da solo. Una solida strategia di località dei dati accompagnata da controlli operativi carenti non equivale a sovranità: si tratta piuttosto di residenza con rischi non valutati.

Ciò che rende utile questo modello non è la sua complessità, bensì le domande che suscita. Quando un’organizzazione analizza per la prima volta la propria situazione attuale alla luce dei quattro pilastri, quasi sempre individua delle lacune di cui ignorava l’esistenza – non perché manchino i controlli, ma perché quelle domande non erano mai state poste.

La sovranità è una scala mobile

Un’altra cosa che vale la pena sottolineare: la sovranità non è uno stato binario. Non esiste una certificazione che la conceda né un unico modello di implementazione che la garantisca. È una posizione – un insieme di decisioni deliberate e verificabili. E il giusto livello di tale posizione varia a seconda dell’organizzazione, del carico di lavoro e di ciò che effettivamente si deve alle autorità di regolamentazione e ai clienti.

È proprio di questo equilibrio che si tratta quando si parla di “sovranità minima sostenibile” – argomento del secondo articolo di questa serie. La fiducia nelle autorità di regolamentazione si costruisce molto prima dell’audit vero e proprio, attraverso requisiti chiaramente definiti e non su presupposti legati alla posizione geografica. Scarica il Rapporto sulla preparazione alla sovranità digitale per conoscere il quadro di riferimento basato sui quattro pilastri e uno strumento pratico di autovalutazione.

Domande frequenti

D: Qual è la differenza tra residenza dei dati e sovranità digitale?

A: La residenza dei dati si concentra sul luogo in cui i dati sono fisicamente archiviati. La sovranità digitale va oltre, occupandosi di chi può accedere ai dati, delle modalità di gestione dei sistemi e dell’esposizione a giurisdizioni che potrebbero comportare rischi legali.

D: Perché la scelta della regione non è sufficiente a garantire la sovranità?

A: La scelta di una cloud riguarda solo l’aspetto geografico. Non risolve le questioni relative all’accesso operativo, all’esposizione ai rischi legali o alle capacità di ripristino.

D: Quali sono i quattro pilastri della sovranità digitale?

A: I quattro pilastri sono la località dei dati, la sovranità tecnologica, la sovranità operativa e la sovranità giurisdizionale. Insieme, creano quello che riteniamo essere un quadro più completo per valutare il grado di preparazione in materia di sovranità.

D: Perché è difficile gestire la sovranità operativa?

A: La sovranità operativa comporta il monitoraggio di chi può accedere ai sistemi, da dove opera e in base a quale regime giuridico. Questi controlli sono più difficili da verificare rispetto ai semplici requisiti relativi all’ubicazione dei dati.

D: La sovranità digitale è una certificazione fissa?

A:No. La sovranità è un approccio continuo basato su decisioni deliberate e verificabili che variano a seconda dell’organizzazione, workload e del contesto normativo.

Ruben Renders è Solutions Director, MSP, presso Commvault.

More related posts

Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more

Punti di forza

  • Gli attacchi di vishing hanno registrato un’impennata, con gruppi organizzati che hanno industrializzato il social engineering per ottenere l’accesso iniziale tramite i servizi di assistenza.
  • Gli aggressori passano rapidamente dagli account umani compromessi a identità macchina persistenti, quali token OAuth e account di servizio.
  • La maggior parte delle organizzazioni non dispone di governance e visibilità sulle identità non umane (NHI), creando un grave punto cieco nella sicurezza.
  • Un’efficace Readiness dipende dalla correlazione dei segnali di identità e dal trattamento delle identità di macchina come risorse ad alto rischio.
  • La vera resilienza richiede la capacità di rilevare e annullare le modifiche non autorizzate ai privilegi prima che gli aggressori riescano a stabilire una presenza persistente.

Il personale del vostro help desk ha appena ricevuto una telefonata. Chi ha chiamato conosceva il nome del dipendente, il suo responsabile e le ultime quattro cifre del numero del badge. Ha chiesto di reimpostare la password. Procedura standard. Il tecnico IT ha acconsentito.

Quella chiamata era una frode. E l’autore dell’attacco è ora all’interno del sistema.

Il phishing vocale – vishing – ha registrato un aumento del 449% nel 2025. I gruppi di malintenzionati hanno trasformato l’ingegneria sociale in un’operazione scalabile: reclutano operatori telefonici, scrivono copioni e pagano da 500 a 1.000 dollari per ogni caso riuscito di impersonazione dell’help desk. Non sono alla ricerca dei vostri dati. Stanno cercando un punto d’appoggio.

Una volta entrati, gli aggressori non si soffermano sull’account umano. Si muovono lateralmente: rubano token OAuth, creano nuovi account di servizio amministrativi, incorporano l’accesso nelle credenziali a livello di macchina che nessuno controlla. A differenza delle password umane, quelle credenziali vengono cambiate raramente. Non attivano avvisi di accesso. Possono sopravvivere a una completa risoluzione del problema relativo all’utente originariamente compromesso.

Nel momento in cui il vostro team di sicurezza chiude il ticket relativo all’incidente dell’help desk, l’aggressore potrebbe essere già presente silenziosamente nel vostro ambiente da settimane. La lacuna nella governance peggiora la situazione.

Meno del 25% delle organizzazioni dispone di politiche formali per la creazione o la disattivazione degli NHI – gli account di servizio, le chiavi API e i token OAuth che ora superano in numero gli utenti umani in un rapporto di 144 a 1. Quasi tutti dispongono di autorizzazioni che vanno ben oltre quanto richiesto dalla loro funzione.

La maggior parte delle organizzazioni non ha quasi alcuna fiducia nella propria capacità di rilevare un attacco mirato a questo livello. Non si tratta di un fallimento nella prevenzione, ma di un fallimento nella pianificazione della Recovery.

Come si presenta la Readiness

La prevenzione a livello di help desk è importante: formazione, verifica tramite richiamata, conferma fuori banda. Ma da sola non è sufficiente. Gli autori degli attacchi si stanno industrializzando più rapidamente di quanto i programmi di sensibilizzazione riescano a stare al passo.

Readiness significa correlare i segnali: un’interazione con l’help desk seguita immediatamente da un reset dell’autenticazione a più fattori (MFA) o dalla creazione di un nuovo token è un indicatore altamente probabile di una compromissione.

Significa trattare le identità delle macchine come risorse di livello 0 – regolandone la creazione, definendone l’ambito delle autorizzazioni e monitorandole per individuare eventuali escalation non autorizzate. E significa avere la capacità di rilevare e annullare rapidamente le modifiche maligne ai privilegi, prima che diventino la nuova normalità.

Scopri come la resilienza delle identità di Commvault supporta il rilevamento rapido, l’annullamento e il Recovery del tuo ambiente di identità.

Domande frequenti

D: Che cos’è un attacco di vishing nel contesto della sicurezza aziendale?

R: Il vishing (voice phishing) utilizza le telefonate per spacciarsi per dipendenti e manipolare i servizi di assistenza IT affinché concedano l’accesso, in genere tramite reimpostazione di password o autenticazione a più fattori (MFA). Si tratta di una pratica sempre più industrializzata, con gruppi organizzati che reclutano operatori e utilizzano script prestabiliti per massimizzare i tassi di successo.

D: Perché gli aggressori si concentrano sulle identità delle macchine dopo essersi introdotti tramite vishing?

R: Gli account umani vengono corretti. Le identità delle macchine (NHI) – token OAuth, account di servizio, chiavi API – sono più persistenti e vengono sostituite raramente, risultando spesso invisibili al monitoraggio tradizionale. La migrazione dell’accesso al livello delle macchine consente agli aggressori di mantenere tale persistenza molto tempo dopo che la violazione originale delle credenziali umane è stata rilevata e risolta.

D: Cosa significa in pratica “resilienza delle identità”?

R: Significa che la vostra organizzazione è in grado di individuare quasi in tempo reale le modifiche non autorizzate ai privilegi e di ripristinare rapidamente l’ambiente delle identità a uno stato affidabile. Il solo rilevamento non è sufficiente: la capacità di annullare le attività dannose e di verificare che le identità delle macchine non siano state manomesse (o, se lo sono state, di riportarle a uno stato precedente integro) è ciò che distingue la Readiness dall’esposizione.

Vidya Shankaran è Field CTO presso Commvault.

More related posts

Thumbnail_Blog-Identity-Resilience-MachineID-2026-Linkedin

The Machine Identity Blind Spot Is Now a Primary Attack Surface

Read more
Thumbnail_Blog-Help-Desk-2026-Linkedin

When the Help Desk Becomes the Front Door to Your Entire Network

Read more
Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

Punti di forza

  • L’ingegneria sociale nei servizi di assistenza è ormai diventata uno dei principali punti di accesso, con gli attacchi di vishing (phishing vocale) in rapido aumento che portano alla compromissione delle credenziali.
  • Le identità non umane, come gli account di servizio e i token, rappresentano un grave punto cieco in termini di sicurezza: spesso non vengono gestite e sono oggetto di gravi abusi finalizzati al movimento laterale.
  • Active Directory (AD) rappresenta un obiettivo di grande valore a causa del suo controllo centralizzato e delle potenziali configurazioni errate.
  • La prevenzione da sola non basta; le organizzazioni hanno bisogno di solide capacità di rilevamento e di ripristino rapido per limitare i danni.
  • Interventi operativi immediati – come la verifica dei conti e la correlazione tra l’attività dell’help desk e le modifiche alle identità – possono ridurre significativamente il rischio.

AD rimane uno degli obiettivi principali degli hacker poiché è il fulcro della gestione delle identità aziendali. Ricerche recenti dimostrano che il 67% degli incidenti comporta ormai una compromissione legata alle identità, con gli hacker che prendono di mira sistemi critici come AD già poche ore dopo aver ottenuto l’accesso iniziale. Una volta compromesso, il ripristino può richiedere giorni o settimane, causando gravi interruzioni dell’attività aziendale.

La domanda che vale la pena porsi non è se l’AD sia un obiettivo. È piuttosto come gli aggressori riescano ad arrivarci – e perché il percorso sia molto più breve di quanto i team di sicurezza potrebbero aspettarsi.

3 passi verso un compromesso completo

Gruppi di malintenzionati come ShinyHunters e Scattered Spider hanno trasformato l’ingegneria sociale in un’operazione su larga scala. Il phishing vocale – noto come “vishing” – ha registrato un aumento del 449% nel 2025. I chiamanti vengono reclutati, istruiti su copioni prestabiliti e pagati fino a 1.000 dollari a seconda del successo e della percentuale di successo.

Ciò significa che è possibile sferrare un attacco con un solo passo: ottenere la reimpostazione di una password o una modifica dell’autenticazione a più fattori (MFA). Tutto qui.

Partendo da quella singola credenziale, l’autore dell’attacco si sposta lateralmente verso ambienti cloud e virtualizzati. Raccoglie token OAuth, crea nuovi account di servizio amministrativi e incorpora l’accesso nelle credenziali a livello di macchina. Queste identità non umane – account di servizio, chiavi API, token – superano ormai gli utenti umani in un rapporto di 144 a 1. La proliferazione e i costi operativi rendono difficili la rotazione e l’audit. Quel movimento laterale ha una destinazione: Active Directory.

La pubblicità è l’obiettivo

AD è il sistema nervoso centrale dell’identità aziendale. Controllandolo, si controlla tutto: account utente, criteri di gruppo e accesso a ogni sistema della rete appartenente al dominio. Il motivo per cui è così attraente per gli aggressori – e così difficile da difendere – è di natura strutturale. Qualsiasi utente autenticato può leggere l’intera directory. Ogni sistema appartenente al dominio ne eredita la fiducia.

Gli oggetti Criteri di gruppo collegati alla radice del dominio possono essere sfruttati per disabilitare completamente i controlli di sicurezza. I protocolli legacy lasciati abilitati per la compatibilità delle applicazioni forniscono un accesso diretto. La stessa documentazione di Microsoft afferma che «la maggior parte degli attacchi alle identità sfrutta comuni errori di configurazione in Active Directory». Quando un malintenzionato raggiunge l’AD, non ha bisogno di forzare l’ingresso. La porta è solitamente aperta.

La prevenzione è necessaria ma non sufficiente

Lo stack di sicurezza standard – MFA, rilevamento degli endpoint, filtraggio delle e-mail – è incentrato sul comportamento umano. Non è stato progettato per gestire il livello delle identità delle macchine né per rilevare quel tipo di escalation dei privilegi graduale e apparentemente legittima che caratterizza i moderni attacchi ad Active Directory. Un aggressore che, nell’arco di 72 ore, passi da un account utente compromesso a un account di servizio e infine a un amministratore di dominio potrebbe non far scattare nemmeno un singolo allarme.

Ecco perché il dibattito deve passare da un approccio incentrato sulla prevenzione a uno incentrato sul recupero. La prevenzione rimane fondamentale. L’accesso con privilegi minimi, il monitoraggio delle modifiche all’AD, il rafforzamento delle configurazioni predefinite e la disattivazione degli account inattivi sono tutte misure che possono contribuire a ridurre la superficie di attacco. Tuttavia, considerando che metà delle organizzazioni ha già subito un attacco all’AD, puntare esclusivamente sulla prevenzione significa andare incontro a un fallimento.

Una vera resilienza delle identità richiede la capacità di rilevare in tempo quasi reale le escalation di privilegi non autorizzate, di annullare le modifiche dannose prima che si propaghino e di ripristinare rapidamente l’ambiente delle identità a uno stato noto e affidabile – non in giorni o settimane, ma con la rapidità necessaria a contenere il raggio d’azione dell’incidente. Ciò significa considerare Active Directory e il livello delle identità non umane come risorse di livello 0, con lo stesso livello di governance e gli stessi investimenti nel ripristino che si applicherebbero a qualsiasi altro sistema mission-critical.

Cosa fare subito per rafforzare la resilienza dell’identità

Il divario tra la situazione attuale della maggior parte delle organizzazioni e quella a cui dovrebbero aspirare in termini di resilienza delle identità è reale. Ma è colmabile. Le priorità immediate sono poco affascinanti e di natura operativa:

  1. Verifica il contenuto del tuo AD.
  2. Individua gli account che non dovrebbero più esistere.
  3. Aggiornare le credenziali che non vengono utilizzate da anni.
  4. Correlare l’attività dell’help desk con gli eventi relativi alla creazione di token e account.

Un’interazione con l’help desk seguita da un ripristino dell’autenticazione a più fattori (MFA) e da la creazione di un nuovo account di servizio costituisce un segnale di attacco altamente attendibile – ed è rilevabile se lo si cerca.

Il lavoro a più lungo termine è di natura architettonica: integrate nel vostro programma di gestione delle identità la capacità di ripristino, in modo che quando un attacco va a buon fine – e di solito si tratta di “quando”, non di “se” – possiate contenerlo, neutralizzarlo e cercare di ripristinare la fiducia più rapidamente di quanto l’autore dell’attacco riesca a consolidare la propria posizione.

Gli aggressori contano sul fatto che il vostro AD non sia governato, che le identità delle vostre macchine siano invisibili e che il vostro piano di Recovery sia puramente teorico. Colmate una di queste lacune in questo trimestre. Colmatele tutte e tre e avrete cambiato radicalmente le carte in tavola. Scopri come Commvault Cloud una protezione completa di Active Directory: dalla valutazione delle vulnerabilità al rollback con un solo clic, fino al ripristino completo della foresta.

Recentemente ho partecipato al podcast STRIVE insieme a Vidya Shankaran per parlare del divario di governance relativo alle identità non umane. Ascolta la nostra puntata qui. E non dimenticare di leggere il blog di Vidya, «Il punto cieco delle identità delle macchine è ora una superficie di attacco primaria».

Domande frequenti

D: Perché i servizi di assistenza stanno diventando un grave rischio per la sicurezza? A: Gli help desk sono spesso incaricati di reimpostare le password e modificare le impostazioni dell’autenticazione a più fattori (MFA), il che li rende obiettivi appetibili per gli attacchi di ingegneria sociale. Gli autori degli attacchi sfruttano questa fiducia per ottenere un accesso iniziale con il minimo ostacolo. D: Che ruolo svolgono le identità non umane negli attacchi?

A: La dispersione e i costi operativi rendono difficili la rotazione e la verifica delle identità non umane, come gli account di servizio e le chiavi API. Gli aggressori le utilizzano per mantenere la persistenza e muoversi inosservati tra i sistemi. D: Perché AD è un bersaglio così critico? A: AD gestisce l’autenticazione e l’accesso all’interno della rete. Assumerne il controllo consente agli aggressori di gestire utenti, criteri e sistemi su larga scala. D: L’autenticazione a più fattori (MFA) e la sicurezza degli endpoint non sono sufficienti a fermare questi attacchi? R: Questi strumenti si concentrano sul comportamento umano e potrebbero non rilevare un’escalation di privilegi graduale e apparentemente legittima. Gli autori degli attacchi possono agire seguendo schemi normali ed evitare di far scattare gli allarmi. D: Cosa significa un approccio alla sicurezza incentrato sul ripristino? R: Significa prepararsi alla realtà che le violazioni si verificheranno e dare priorità alla capacità di rilevarle, contenerle e risolverle rapidamente. Questo approccio contribuisce a ridurre i tempi di inattività e può aiutare a limitare l’impatto complessivo. D: Quali sono le misure più importanti da adottare immediatamente? A: Iniziate effettuando un audit del vostro AD, eliminando gli account non necessari, aggiornando le credenziali obsolete e monitorando eventuali sequenze sospette di attività relative all’help desk e alle identità. Dan Conrad è responsabile tecnico e CTO sul campo presso Commvault.

More related posts

Thumbnail_Blog-Okta-Early-Access-2026

Commvault® Extends Identity Resilience to Okta

Read more
Thumbnail_Blog-Lateral-Access-2026

Staying Resilient Against Lateral Access Exploits

Read more
Thumbnail_3_AD_Blogs_2025

Active Directory Forest Recovery: Why Manual Methods Are No Longer Viable

Read more
Thumbnail_6_AD_Blogs_2025

AD Recovery Testing: How to Know Your Recovery Plan Will Actually Work

Read more

Punti di forza

  • Le identità non umane (NHI) superano ormai di gran lunga il numero degli utenti umani e stanno crescendo a un ritmo molto più rapido, creando una superficie di attacco significativa e poco regolamentata.
  • Gli autori degli attacchi ricorrono sempre più spesso a tecniche di ingegneria sociale, come il phishing vocale (vishing), per aggirare le difese umane e ottenere l’accesso alle credenziali a livello di sistema.
  • La maggior parte delle NHI opera con autorizzazioni eccessive e non dispone di un’adeguata gestione del ciclo di vita, contribuendo così all’accumulo di un “debito identitario”.
  • Gli strumenti di sicurezza tradizionali non riescono a rilevare le minacce a livello di macchina perché gli NHI si comportano in modo diverso dagli utenti umani.
  • Le organizzazioni devono passare da strategie incentrate sulla prevenzione ad approcci incentrati sul ripristino, dando priorità all’individuazione rapida e alla neutralizzazione degli attacchi basati sull’identità.

Negli ultimi dieci anni, gli investimenti nella sicurezza aziendale hanno seguito l’utente umano. Autenticazione migliore. Autenticazione multifattoriale (MFA) più solida. Simulazione di phishing. Architettura incentrata sull’identità. Questi investimenti rappresentavano la risposta adeguata al panorama delle minacce dell’epoca. Il panorama delle minacce è cambiato.

Gli avversari più sofisticati di oggi non cercano di aggirare la vostra MFA. La utilizzano come porta d’accesso. Una telefonata convincente al vostro help desk IT, una reimpostazione dell’MFA e un account umano compromesso: ecco il punto di ingresso. Ciò che in realtà cercano è ciò che si trova dietro: il livello tentacolare e scarsamente regolamentato delle NHI che collega ogni sistema nel vostro ambiente.

La portata del problema è sbalorditiva

Account di servizio, chiavi API, token OAuth, agenti di intelligenza artificiale: le NHI superano ormai gli utenti umani in un rapporto di 144 a 1 e crescono da 4 a 10 volte più velocemente degli account umani. Eppure, meno del 25% delle organizzazioni dispone di politiche formali che ne regolino la creazione o la disattivazione. Quasi tutte dispongono di autorizzazioni eccessive: diritti che superano di gran lunga ciò che la loro funzione richiede.

Non si tratta di un rischio nuovo, apparso all’improvviso. È un debito identitario accumulato nel tempo: anni di implementazione senza governance, automazione senza responsabilità, cloud senza visibilità. E gli avversari se ne sono accorti.

Il vishing è il punto di accesso

Gruppi come ShinyHunters e Scattered Spider – che operano nell’ambito di quello che i ricercatori chiamano il cluster Scattered LAPSUS$ Hunters (SLH) – hanno industrializzato l’ingegneria sociale per sfruttare proprio questa lacuna. Il vishing è aumentato del 449% nel 2025. Non si tratta di chiamate opportunistiche. Sono operazioni coordinate: script appositamente realizzati, operatori reclutati, incentivi finanziari fino a 1.000 dollari per ogni caso di impersonificazione riuscita dell’help desk.

La chiamata non è l’attacco. La chiamata è la reimpostazione delle credenziali che consente all’autore dell’attacco di superare il perimetro umano. L’attacco ha inizio quando l’autore dell’attacco passa al livello dei sistemi: rubando token OAuth, creando account di servizio amministrativi, incorporando l’accesso in credenziali che vengono monitorate raramente e di cui non viene quasi mai effettuata la rotazione. L’account umano viene risolto. L’accesso a livello macchina persiste. L’autore dell’attacco è già passato ad altro.

Tre vulnerabilità che i controlli tradizionali non riescono a individuare

Gli strumenti di sicurezza standard sono progettati in base al comportamento umano. Segnalano accessi anomali, geolocalizzazioni insolite, traffico e-mail sospetto. Gli NHI operano in modo diverso, e proprio questa differenza costituisce il punto cieco.

L’abuso di OAuth, ad esempio, appare come normale traffico API – anche dopo la reimpostazione di una password. Migliaia di account di servizio non documentati operano nelle grandi imprese con privilegi amministrativi, spesso molto tempo dopo la conclusione dei progetti che li hanno creati. Le chiavi API di lunga durata incorporate nelle pipeline DevOps garantiscono un ampio accesso senza contesto del dispositivo e senza avvisi di accesso. L’MFA non li rileva. Il sistema di rilevamento degli endpoint non li individua. Il filtraggio delle e-mail è irrilevante per loro.

Il cambiamento di paradigma: dalla prevenzione al recupero

La risposta logica a una minaccia che spesso sfugge ai sistemi di rilevamento tradizionali è smettere di dare per scontato che sia possibile prevenire ogni intrusione e iniziare a progettare sistemi che consentano un rapido ripristino in caso di intrusioni riuscite. Ciò significa considerare gli NHI come risorse di livello 0, applicando loro gli stessi controlli di governance previsti per gli amministratori di dominio o i piani cloud gestiti con identità umane. Significa sostituire i segreti statici con token a breve durata e rotazione automatica.

Significa anche mettere in correlazione i segnali provenienti da diversi ambiti: un’interazione con l’help desk seguita da un ripristino dell’autenticazione a più fattori (MFA) e poi dalla creazione di un nuovo token costituisce un indicatore di compromissione altamente attendibile, e individuarlo tempestivamente fa la differenza tra il contenimento dell’incidente e una violazione prolungata. Significa inoltre mappare gli NHI alle identità umane ai fini della responsabilità.

Ma soprattutto, significa avere la capacità di rilevare in tempo reale gli aumenti di privilegi non autorizzati e di annullare le modifiche dannose alle identità, riportando l’ambiente a uno stato noto e affidabile prima che il danno si estenda.

La prevenzione rimane fondamentale. Tuttavia, dato il divario di governance che caratterizza molte organizzazioni, la velocità di ripristino sta diventando un indicatore primario di resilienza. Le organizzazioni dovrebbero sviluppare programmi di gestione delle identità pensati per gli attacchi che si stanno già verificando, non per quelli che erano comuni cinque anni fa. Visita Readiverse e dai un’occhiata al nostro eBook *The Non-Human Identity Crisis*, che esplora l’intera portata della superficie di attacco delle macchine e il quadro di riferimento per la resilienza dell’identità.

Domande frequenti

Domanda 1: Cosa sono le identità non umane (NHI)?

A: Gli NHI comprendono account di servizio, chiavi API, token OAuth e agenti di intelligenza artificiale che consentono a sistemi e applicazioni di interagire tra loro. A differenza degli utenti umani, spesso operano in modo automatico e su larga scala, il che li rende più difficili da monitorare e controllare.

Domanda 2: Perché gli NHI sono considerati un rischio per la sicurezza?

A: Gli NHI dispongono spesso di autorizzazioni eccessive e non sono soggetti a un’adeguata governance, il che li rende bersagli appetibili per gli hacker. Poiché vengono raramente monitorati o sottoposti a rotazione, le credenziali compromesse possono rimanere in uso per lunghi periodi senza essere individuate.

Domanda 3: In che modo gli hacker sfruttano gli NHI?

R: Gli autori degli attacchi ottengono solitamente l’accesso iniziale tramite tecniche di ingegneria sociale, come il voice phishing, per poi passare al livello dei sistemi. Rubano i token, creano nuovi account di servizio o incorporano un accesso persistente nelle credenziali che non sono sottoposte a un monitoraggio rigoroso.

Domanda 4: Perché gli strumenti di sicurezza tradizionali non rilevano queste minacce?

A: La maggior parte degli strumenti di sicurezza è progettata per monitorare il comportamento umano, come le anomalie negli accessi o i tentativi di phishing. Gli NHI generano un traffico di sistema che appare normale, il che consente alle attività dannose di mimetizzarsi tra le operazioni legittime.

D5: Cosa si intende per approccio alla sicurezza “recovery-first”?

A: Un approccio incentrato sul ripristino mira a individuare rapidamente le violazioni e a riportare i sistemi a uno stato sicuro, piuttosto che partire dal presupposto che tutti gli attacchi possano essere prevenuti. Ciò comporta l’identificazione delle modifiche non autorizzate e il loro ripristino in tempo reale.

Domanda 6: In che modo le organizzazioni possono migliorare la sicurezza del sistema sanitario nazionale?

A: Le organizzazioni possono considerare gli NHI come risorse critiche, attuare politiche di governance rigorose, sostituire le credenziali statiche con token a breve durata e correlare i segnali tra i vari sistemi. L’assegnazione degli NHI a responsabili umani migliora inoltre la responsabilità e la supervisione.

Vidya Shankaran è Field CTO presso Commvault.

More related posts

Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog-Unified-Resilience-2026

Why AI Is Breaking Your Resilience Strategy (And What to Do About It)

Read more
Thumbnail_Blog-SHIFT-Sanjay-2025-Linkedin

Re-envisioning Resilience for the Age of AI

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

Oggi le organizzazioni sviluppano applicazioni più rapidamente, automatizzano i flussi di lavoro su larga scala e trasformano i dati in informazioni utili, grazie a piattaforme come Microsoft Power Platform. Quello che era nato come un livello di produttività low-code è diventato rapidamente un elemento fondamentale, integrato nei processi che supportano la generazione di ricavi, le operazioni quotidiane e il processo decisionale strategico.

Tuttavia, con l’aumentare della dipendenza da queste risorse di business intelligence, cresce anche il rischio ad esse associato. La stessa platform l’innovazione può anche amplificare l’impatto di errori operativi, configurazioni errate e azioni dolose. Un flusso di lavoro configurato in modo errato, un report cancellato o un’applicazione malfunzionante possono interrompere i processi aziendali, compromettere il processo decisionale e minare la fiducia nei sistemi su cui l’azienda fa affidamento. E quando qualcosa va storto, il ripristino è raramente semplice.

Commvault contribuisce ad affrontare queste sfide offrendo soluzioni di protezione e ripristino dei dati di livello aziendale per Microsoft Power Platform, a partire da Power BI, consentendo alle organizzazioni di proteggere le analisi, i flussi di lavoro e le app che sviluppano e di ripristinarli rapidamente. 

Power BI: Il divario tra analisi e recupero

Al centro di molte Platform Power Platform c’è Microsoft Power BI, che offre funzionalità di analisi e business intelligence, trasformando i dati in report, previsioni e visibilità operativa. Quando le risorse di Power BI vengono perse o compromesse, i team possono perdere rapidamente l’accesso a informazioni affidabili, interrompendo i cicli di reporting e ritardando il processo decisionale aziendale.

In pratica, tuttavia, le strategie di protezione non tengono il passo con l’importanza di queste risorse. Molte organizzazioni si affidano all’esportazione manuale dei file o a funzionalità native limitate che non sono state progettate per un ripristino completo. Quando si verifica un guasto, i team sono spesso costretti a ricostruire manualmente senza la possibilità di ripristinare esattamente ciò che è necessario. Ciò rende il ripristino lento, soggetto a errori e difficile da scalare.

Commvault Cloud Backup & Recovery Microsoft Power Platform

Ora disponibile per tutti, Commvault Cloud Backup & Recovery Microsoft Power Platform le organizzazioni Platform proteggere e ripristinare le risorse fondamentali per l’attività aziendale, come i report, da cancellazioni accidentali, danneggiamenti e attività dolose.

  • Protezione automatizzata basata su criteri: applica backup guidati da criteri a tutte le risorse dell’area di lavoro di Power BI, garantendo una copertura coerente e scalabile senza interventi manuali.
  • Ripristino rapido e dettagliato: ripristina singoli report e cartelle a un momento specifico nel tempo, evitando ricostruzioni manuali e contribuendo a ridurre al minimo i tempi di inattività e le interruzioni.
  • Backup isolati e immutabili: contribuisci a proteggere i dati dal ransomware e dalle modifiche non autorizzate grazie a backup progettati per impedire modifiche o cancellazioni non autorizzate.
  • Conformità semplificata: garantire la conservazione a lungo termine (fino a 10 anni), registri di audit centralizzati e reportistica a supporto dei requisiti normativi e interni.

Platform unificata Platform la resilienza

Commvault Cloud una platform unificata platform proteggere i carichi di lavoro SaaS, cloud e on-premise, tra cui Microsoft 365, Dynamics 365, Salesforce, macchine virtuali, database ed endpoint. Grazie Platform Microsoft Power Platform , i clienti possono ottimizzare la protezione, il ripristino e la resilienza per un numero maggiore di carichi di lavoro, contribuendo a ridurre la proliferazione degli strumenti e a semplificare le operazioni.

Come iniziare

Commvault Cloud Backup and Recovery for Power Platform è fornito come soluzione SaaS, progettata per una rapida implementazione e un overhead operativo minimo. Le organizzazioni possono collegare il proprio ambiente Power BI, applicare una protezione basata su criteri e iniziare a eseguire il backup dei dati critici in pochi passaggi.

Il rilevamento automatico protegge i nuovi report e le nuove cartelle man mano che gli ambienti si evolvono, mentre la gestione centralizzata offre un unico punto da cui monitorare, gestire e ripristinare i dati su larga scala.

Prossimi passi: espansione su Power Platform

Intendiamo ampliare la protezione e la resilienza in tutta Platform Microsoft Power Platform includere Power Apps e Power Automate, estendendo la copertura alle applicazioni e ai flussi di lavoro che sono alla base della vostra attività. I piani, le tempistiche e le funzionalità sono soggetti a modifiche e non devono essere considerati come elementi determinanti nelle decisioni di acquisto.

Proteggi ciò che alimenta la tua attività

Con Platform dell’utilizzo di Microsoft Power Platform , cresce anche la necessità di una protezione resiliente e di livello aziendale. Con Commvault Cloud, è possibile:

  • Proteggi le risorse critiche da cancellazione, danneggiamento e attacchi
  • Recupera rapidamente proprio ciò di cui hai bisogno, senza dover ricostruire tutto da capo
  • Mantenere la fiducia nei dati, nelle decisioni e nell’automazione
Sei pronto a rendere più resiliente il tuo investimento in Microsoft Power BI?

Scopri di più e guarda Commvault Cloud azione su commvault.platform.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Punti di forza

  • La migrazione delle macchine virtuali a Red Hat OpenShift Virtualization è un percorso graduale che richiede una protezione costante in tutti gli ambienti ibridi.
  • Una platform unificata e nativa di Kubernetes per la protezione dei dati platform ridurre la complessità ed elimina la necessità di ricorrere a strumenti o processi separati.
  • Una resilienza affidabile – che includa backup immutabili e il rilevamento delle minacce – è fondamentale durante la migrazione, quando i rischi sono più elevati.
  • Le opzioni di ripristino flessibili consentono alle organizzazioni di adattarsi rapidamente in caso di fallimento delle fasi di migrazione o di variazioni delle tempistiche.
  • Il consolidamento della protezione per le macchine virtuali e i container contribuisce a ridurre la proliferazione degli strumenti e a garantire una governance coerente.

Se oggi ricopri un ruolo dirigenziale nel settore IT, è probabile che la tua strategia di virtualizzazione sia attualmente oggetto di un’attenta revisione. L’aumento dei costi, l’incertezza in materia di licenze e la dipendenza a lungo termine da un unico fornitore stanno spingendo molte organizzazioni a riconsiderare la propria dipendenza dagli hypervisor tradizionali. Allo stesso tempo, Kubernetes è ormai diventato la base operativa per le applicazioni moderne.

Queste due realtà stanno convergendo e, per molte aziende, Red Hat OpenShift Virtualization si sta affermando come la soluzione preferita per l’esecuzione di macchine virtuali all’interno di un modello operativo nativo di Kubernetes. Questa transizione sta accelerando in tutti i settori. Man mano che le organizzazioni modernizzano le proprie infrastrutture secondo le proprie esigenze, Red Hat OpenShift Virtualization viene sempre più considerato come uno strumento per modernizzare la platform dover ricorrere alla rifattorizzazione delle applicazioni. Questo slancio solleva una domanda fondamentale:

Come si fa a migrare le macchine virtuali garantendo al contempo protezione, resilienza e recuperabilità costanti durante l’intero processo? Per rispondere a questa domanda, occorre analizzare come si svolgono effettivamente la maggior parte delle migrazioni aziendali e in quali punti la protezione e la resilienza assumono un’importanza fondamentale.

La migrazione è un percorso, non un evento isolato

I dirigenti esperti nel settore IT sanno bene che le transizioni infrastrutturali raramente avvengono tutte in una volta. Per le aziende che decidono di passare da hypervisor come VMware a Red Hat OpenShift Virtualization, la transizione avviene in genere in più fasi. Durante questo periodo, le organizzazioni si trovano inevitabilmente a operare in una situazione mista:

  • Le macchine virtuali basate su VMware continuano a supportare le operazioni aziendali fondamentali.
  • Macchine virtuali che girano da poco su Red Hat OpenShift Virtualization.
  • Applicazioni in container che condividono gli stessi cluster Red Hat OpenShift.

Questo periodo di coesistenza comporta complessità e rischi. I dati sono in continuo movimento, gli ambienti cambiano e possono emergere lacune nella protezione se gli strumenti e i processi non si evolvono di pari passo con i carichi di lavoro.

È fondamentale garantire una protezione affidabile

Commvault offre da tempo soluzioni di protezione e ripristino dei dati sia per gli ambienti VMware che per i carichi di lavoro Kubernetes in esecuzione su Red Hat OpenShift. Lo stesso modello di protezione nativo per Kubernetes e basato su policy si estende ora alle macchine virtuali in esecuzione su Red Hat OpenShift Virtualization. Ciò che colpisce davvero i clienti è la coerenza:

  • Un’unica platform la protezione e il ripristino.
  • Operazioni basate su criteri applicate in modo uniforme a tutti i carichi di lavoro.
  • Progettato per integrarsi con gli strumenti e i processi già in uso, al passo con l’evoluzione degli ambienti.

Le macchine virtuali in esecuzione su Red Hat OpenShift Virtualization sono protette utilizzando gli stessi flussi di lavoro e gli stessi meccanismi di governance delle applicazioni containerizzate. Questo approccio unificato sta riscuotendo successo tra le organizzazioni che stanno adottando Red Hat OpenShift come standard e che desiderano un modo più semplice e coerente per gestire i dati in tutti gli ambienti.

Questa funzionalità è già disponibile. Commvault Cloud supporta la protezione degli ambienti Red Hat OpenShift Virtualization in linea con la versione 11.40 (Long-Term Support) e la versione 11.42 (Innovation), il che significa che i clienti possono già implementare queste funzionalità in produzione.

Non dovresti dover gestire la protezione in modo diverso

Una volta trasferite su Red Hat OpenShift Virtualization, le macchine virtuali non dovrebbero richiedere alcun trattamento particolare dal punto di vista della protezione. Commvault Cloud e protegge le macchine virtuali (VM) di Red Hat OpenShift Virtualization insieme alle applicazioni containerizzate, contribuendo a garantire ai team una visibilità centralizzata, un’applicazione coerente delle politiche e operazioni di ripristino semplificate. I carichi di lavoro virtualizzati e containerizzati vengono gestiti congiuntamente, senza creare silos operativi.

Per le organizzazioni che gestiscono portafogli applicativi eterogenei, questa gestione delle macchine virtuali all’interno di Kubernetes contribuisce a ridurre gli attriti operativi, garantendo al contempo controlli di livello aziendale.

La resilienza informatica è fondamentale quando la migrazione aumenta i rischi.

I periodi di migrazione rappresentano una fase particolarmente vulnerabile. Il cambiamento genera complessità, e la complessità aumenta l’esposizione alla perdita di dati e al ransomware. Commvault Cloud garantire la resilienza durante questa fase grazie a:

  • Backup isolati fisicamente e immutabili per i carichi di lavoro di Red Hat OpenShift Virtualization.
  • Dati di backup che supportano la ricerca delle minacce e l’analisi forense, aiutando i team a verificare la prontezza al ripristino prima di ripristinare i carichi di lavoro.
  • Funzionalità avanzate di ripristino progettate per aiutare le organizzazioni a ridurre al minimo le interruzioni operative.

Che i carichi di lavoro si trovino in fase di pre-migrazione, nel bel mezzo della transizione o già pienamente operativi su Red Hat OpenShift Virtualization, il livello di resilienza rimane invariato.

La flessibilità nel recupero infonde fiducia

Ogni iniziativa di modernizzazione richiede un margine di adattamento. Commvault supporta sia il ripristino in loco che fuori sede per le macchine virtuali di Red Hat OpenShift Virtualization, compreso l’intero contesto e la configurazione della macchina virtuale. Se una fase della migrazione non procede come previsto – o se è necessario modificare le tempistiche – i team possono ripristinare rapidamente i dati e proseguire senza compromettere la disponibilità o l’integrità dei dati.

Protezione nativa per Kubernetes oltre le macchine virtuali

Per molte aziende, la virtualizzazione rappresenta solo una parte di una strategia più ampia di modernizzazione delle applicazioni. Commvault Cloud offre Cloud una protezione incentrata sulle applicazioni e nativa per Kubernetes per i carichi di lavoro containerizzati, inclusi i volumi persistenti e i metadati delle applicazioni, su tutte le distribuzioni Kubernetes certificate dal CNCF. Ciò garantisce la mobilità e il ripristino delle applicazioni cloud, contribuendo al contempo a mantenere la coerenza operativa tra i diversi ambienti.

Ridurre la proliferazione degli strumenti man mano che l’infrastruttura si evolve

Platform spesso comportano l’introduzione di nuovi strumenti, nuovi processi e una maggiore complessità. Utilizzando Commvault Cloud platform di protezione unificata platform :

  • Macchine virtuali VMware.
  • Macchine virtuali (VM) di Red Hat OpenShift Virtualization.
  • Applicazioni in container.

Le organizzazioni possono contribuire a ridurre la proliferazione degli strumenti, semplificare l’amministrazione e garantire una governance coerente anche man mano che le strategie infrastrutturali si evolvono.

Come tutto si incastra

Durante qualsiasi migrazione, è utile capire come i vari elementi interagiscono tra loro. Il Migration Toolkit for Virtualization di Red Hat si occupa di trasferire le macchine virtuali da VMware a Red Hat OpenShift Virtualization. Commvault Cloud garantire protezione e resilienza che accompagnano i vostri carichi di lavoro durante l’intero processo, in modo che i dati rimangano protetti prima, durante e dopo la migrazione. Ciò contribuisce a evitare che la capacità di ripristino rimanga indietro rispetto allo spostamento dei carichi di lavoro.

Proseguimento del dibattito al Red Hat Summit

Stiamo già collaborando con clienti che stanno trasferendo attivamente le proprie macchine virtuali su OpenShift Virtualization e continueremo a approfondire questi argomenti al Red Hat Summit, che si terrà dall’11 al 14 maggio ad Atlanta. Presso lo stand di Commvault, faremo quanto segue:

  • Un dialogo con i responsabili IT sulle sfide concrete in materia di resilienza.
  • Consigli pratici per affrontare la migrazione con fiducia.
  • Dimostrazione Cloud Commvault Cloud per Red Hat OpenShift Virtualization.

Se garantire la resilienza e la capacità di ripristino nell’ambito della vostra strategia di virtualizzazione è una priorità, saremmo lieti di poter entrare in contatto con voi.

Andare avanti con fiducia

Red Hat OpenShift Virtualization sta diventando una componente fondamentale dell’infrastruttura aziendale moderna. Tuttavia, non è possibile affrettare la migrazione a tutti i costi; è necessario integrare fin dall’inizio nel processo misure di protezione, resilienza e ripristino.

Con Commvault Cloud, la protezione dei carichi di lavoro di Red Hat OpenShift Virtualization non è un obiettivo futuro. È qualcosa che i clienti stanno già facendo, utilizzando una platform unificata platform modernizzarsi in tutta sicurezza, garantendo al contempo resilienza e capacità di ripristino.

“Red Hat OpenShift Virtualization offre alle organizzazioni una base affidabile e coerente per gestire l’intero parco di sistemi virtualizzati”, afferma Steve Gordon, Senior Director, Product Management, Hybrid Cloud , presso Red Hat. “Sfruttando un’integrazione ottimizzata come quella Cloud Commvault Cloud Red Hat OpenShift Virtualization, i nostri clienti possono procedere con maggiore sicurezza, sapendo che i loro carichi di lavoro sono protetti in modo coerente prima, durante e dopo la migrazione.”

Domande frequenti

D: Perché la migrazione delle macchine virtuali è considerata un processo articolato in più fasi?

A: La maggior parte delle aziende non è in grado di migrare tutti i carichi di lavoro contemporaneamente, pertanto opera in un contesto ibrido in cui gli ambienti legacy e quelli nuovi funzionano in parallelo. Questo approccio graduale comporta una certa complessità, rendendo essenziali una protezione e una visibilità costanti durante l’intera transizione.

D: Che ruolo svolge la resilienza durante la migrazione delle macchine virtuali?

A: La resilienza consente alle organizzazioni di garantire la protezione dei dati, di riprendersi rapidamente dai guasti e di difendersi da minacce come il ransomware. Durante la migrazione, quando i sistemi sono in fase di transizione, misure di resilienza efficaci possono aiutare a prevenire la perdita di dati e le interruzioni operative.

D: In che modo Commvault Cloud la protezione in tutti gli ambienti?

A: Commvault Cloud un’unica platform protezione basata su criteri per le macchine virtuali VMware, le macchine virtuali OpenShift Virtualization e le applicazioni containerizzate. Questo approccio unificato consente di garantire operazioni coerenti senza dover introdurre nuovi strumenti o flussi di lavoro.

D: Perché è importante la protezione nativa di Kubernetes?

A: La protezione nativa di Kubernetes si adatta alle modalità di distribuzione e gestione delle applicazioni moderne, coprendo sia i container che le macchine virtuali. Consente una gestione semplificata dei dati, la mobilità e il ripristino all’interno di ambienti cloud.

D: In che modo la flessibilità del ripristino aumenta la fiducia nella migrazione?

A: Le opzioni di ripristino flessibili, come il ripristino in loco e fuori sede, possono aiutare i team a ripristinare rapidamente i carichi di lavoro in caso di problemi. Questa flessibilità contribuisce a ridurre i tempi di inattività e consente alle organizzazioni di adeguare i piani di migrazione senza compromettere l’integrità dei dati.

D: In che modo le organizzazioni possono ridurre la complessità durante le transizioni infrastrutturali?

A: Adottando una platform unificata per la protezione dei dati, le organizzazioni possono gestire tutti i carichi di lavoro – virtualizzati e containerizzati – tramite un’unica interfaccia. Questo approccio contribuisce a ridurre la proliferazione degli strumenti, a semplificare l’amministrazione e a garantire una governance coerente in ambienti in continua evoluzione.

Jason Giza è Senior Manager del reparto Global Content Partner Marketing presso Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Punti di forza

  • La Readiverse Academy ha introdotto un percorso di certificazione strutturato e articolato in livelli, che spazia dalle conoscenze di base alle competenze avanzate cloud .
  • Le certificazioni sono in linea con i ruoli professionali reali e consentono ai partecipanti di sviluppare competenze pertinenti alle loro responsabilità negli Cloud Commvault Cloud .
  • Il programma prevede quattro livelli – Praticante, Specialista, Professionista ed Esperto – ciascuno dei quali presenta un livello crescente di approfondimento e capacità operativa.
  • L’apprendimento si articola attorno a tre pilastri fondamentali: platform , cyber resilience e workload .
  • Le opzioni di formazione flessibili, che comprendono sia corsi autogestiti che tenuti da un docente, consentono ai professionisti di progredire in base ai propri impegni e ai propri obiettivi.

Gli ambienti che proteggete con Commvault Cloud sempre più complessi e le aspettative nei confronti dei vostri team incaricati della loro gestione sono più elevate che mai. Non si tratta più solo di conoscere la platform, ma di essere in grado di gestirla, proteggerla e ripristinarla, spesso sotto pressione.

Se avete già iniziato il vostro percorso di apprendimento alla Readiverse Academy, bentornati. E se siete nuovi qui, siete arrivati proprio al momento giusto. Oggi presentiamo un approccio alla certificazione strutturato e articolato in livelli, che offre agli studenti un percorso chiaro e basato sulle competenze, che va platform di base platform fino alle competenze avanzate cloud.

Creiamo contenuti su misura per te

Cloud Commvault Cloud richiedono competenze che abbracciano diverse aree di responsabilità, spesso all’interno dello stesso ruolo. Amministratori, specialisti della sicurezza, cloud e workload necessitano di conoscenze di diverso livello e portata. E non tutti devono necessariamente apprendere le stesse cose, nello stesso ordine, per essere efficaci.

I nuovi livelli di certificazione della Readiverse Academy riflettono questa realtà. Gli studenti avanzano attraverso livelli chiaramente definiti che si basano l’uno sull’altro, in modo che la certificazione sia in linea con ciò che fai effettivamente e attesti tali competenze ai team con cui collabori.

  • Commvault Cloud – conoscenze di base platform sulla resilienza.
  • Cloud Commvault Cloud – competenze approfondite in ambito operativo e di sicurezza.
  • Commvault Cloud – workload avanzate in materia di ripristino e gestione workload .
  • Commvault Cloud – competenza completa cloud e leadership nella resilienza.

Ogni livello viene conseguito attraverso una combinazione di corsi, attività pratiche di laboratorio e valutazioni certificate. Man mano che gli studenti progrediscono, la portata e la profondità delle competenze operative dimostrate aumentano di conseguenza.

Un percorso chiaro: da principiante a esperto

Il programma di certificazione si articola attorno a tre pilastri fondamentali di competenze che caratterizzano ogni livello:

  • platform di base platform
  • Concetti di resilienza informatica
  • Workload competenze specifiche

Ogni livello prevede requisiti specifici relativi a tali pilastri. Gli studenti possono seguire singoli corsi oppure combinare i requisiti indicati per raggiungere gli obiettivi di certificazione.

Sei già iscritto alla Readiverse Academy? Ecco cosa significa per te.

Con una nuova struttura come questa, la domanda più importante è: cosa significa per i progressi che hai già compiuto? Se hai già completato corsi o ottenuto certificazioni nella Readiverse Academy, congratulazioni! Il tuo investimento è importante e vogliamo essere chiari su ciò che accadrà in seguito.

Queste certificazioni rappresentano il tuo percorso e i risultati raggiunti con Commvault. Il nuovo programma è in linea con il nostro portafoglio ampliato di cyber resilience per Commvault Software, Commvault SaaS e gli ambienti ibridi. Man mano che le tue esigenze cresceranno e richiederanno un maggiore coinvolgimento da parte di Commvault, questi corsi e queste certificazioni ti aiuteranno a configurare, gestire e ottimizzare Commvault per soddisfare le esigenze specifiche della tua organizzazione.

Non esiste un percorso diretto dai precedenti percorsi di certificazione al nuovo programma, ma le tue certificazioni esistenti attestano la tua competenza sulle versioni precedenti del prodotto. Man mano che tali versioni verranno ritirate, anche quelle certificazioni raggiungeranno la fine del ciclo di vita. Gli studenti che hanno già investito nella Readiverse Academy sono in una posizione ideale per progredire rapidamente.

A chi sono rivolti i corsi e le certificazioni della Readiverse Academy

Le certificazioni della Readiverse Academy sono pensate per i professionisti che operano in ambienti Commvault SaaS, Commvault Software e ibridi.

  • Platform che gestiscono le operazioni quotidiane.
  • Specialisti della sicurezza specializzati nella protezione dei dati e nel rafforzamento della sicurezza degli ambienti.
  • Cloud responsabili della configurazione del piano di controllo e della resilienza avanzata.
  • Workload che devono possedere competenze in ambiti specifici relativi ai dati.

Tutti i corsi di formazione sono disponibili per l’apprendimento autonomo, mentre alcuni corsi selezionati sono offerti anche in modalità con docente, in modo che i partecipanti possano progredire secondo le modalità più adatte al proprio ruolo e ai propri impegni.

Come iniziare o proseguire il proprio percorso di apprendimento

Che tu stia iniziando da zero o proseguendo il tuo percorso, il prossimo passo è semplice e pensato per accompagnarti proprio dove ti trovi.

  • Accedi o registrati su commvault.com.
  • Non conosci ancora Commvault? Inizia con il corso “Commvault Cloud ”.
  • Ti occupi del workload ? Dai un’occhiata al nostro catalogo di corsi che coprono praticamente ogni argomento.
  • Cerchi strategie per favorire il ripristino dopo un attacco informatico? Il corso sulla resilienza informatica è il punto di partenza ideale.

Cosa ci aspetta

Il nostro obiettivo è rendere il percorso di crescita professionale prevedibile, trasparente e in linea con i ruoli reali, per aiutare gli studenti a capire quale sarà il prossimo passo e come prepararsi ad affrontarlo. Ci impegniamo a fornire Cloud ogni Cloud di Commvault Cloud le competenze necessarie per gestire, proteggere e ripristinare il proprio ambiente in tutta sicurezza. Perché, quando conta davvero, la certificazione non è solo una questione di credenziali: significa essere resilienti e pronti a ripristinare il sistema.

Domande frequenti

D: Qual è lo scopo del programma di certificazione della Readiverse Academy?

A: Il programma offre un percorso formativo strutturato e incentrato sulle competenze, che aiuta i professionisti a passare dalle platform di base platform a competenze avanzate cloud . Allinea la formazione alle responsabilità del mondo reale per consentire ai partecipanti di applicare efficacemente le proprie conoscenze in contesti complessi.

D: Quali sono i diversi livelli di certificazione disponibili?

A: Esistono quattro livelli: Commvault Cloud , Specialist, Professional ed Expert. Ogni livello si basa su quello precedente, con un progressivo aumento della profondità tecnica, dell’ambito operativo e delle capacità di leadership.

D: Chi dovrebbe iscriversi ai corsi della Readiverse Academy?

R: I corsi sono pensati per platform , specialisti della sicurezza, cloud e workload che operano in ambienti SaaS, software e ibridi. Ciascun ruolo può seguire un percorso formativo su misura in base alle proprie responsabilità.

D: Come si ottengono le certificazioni?

A: Le certificazioni si ottengono attraverso una combinazione di corsi, esercitazioni pratiche e valutazioni convalidate. Man mano che gli studenti progrediscono, dimostrano livelli crescenti di competenza workload platform, della sicurezza e workload .

D: Cosa succede alle certificazioni Readiverse Academy già conseguite?

A: Le certificazioni esistenti rimangono valide come prova delle competenze acquisite in passato, ma sono legate alle versioni precedenti del prodotto. Man mano che tali versioni vengono ritirate dal mercato, le certificazioni giungeranno al termine del loro ciclo di vita, incoraggiando gli studenti a passare al nuovo programma.

D: Come si può iniziare a utilizzare il nuovo programma?

R: I nuovi studenti possono iniziare con il corso “Commvault Cloud Administrator”, mentre gli utenti già registrati possono effettuare l’accesso per proseguire il proprio percorso formativo. Sono disponibili ulteriori corsi in base a obiettivi specifici, quali workload o cyber resilience.

Suzanne Klausner è direttore della strategia di abilitazione dei clienti di Commvault.

More related posts

Thumbnail_Blog-Ready-or-Not-2026

Why Every CIO Needs a ‘Ready. Or Not.’ Mindset

Read more
Thumbnail_Blog_Readiness-Update-2024

Boost Your Cyber Resilience and Readiness

Read more
Social_Readiverse_Blog_LinkedIn-1

The Readiverse: Your Go-To Learning Resource for Cyber Resilience and Readiness

Read more

Punti di forza

  • I flussi di lavoro di ripristino tradizionali possono causare una deriva dell’infrastruttura negli ambienti gestiti da Terraform, poiché prevedono il provisioning di nuove risorse al di fuori dello stato.
  • Clumio Backtrack è progettato per ripristinare i dati direttamente nei bucket S3 e nelle tabelle DynamoDB esistenti, contribuendo a preservare l’identità delle risorse.
  • Il ripristino in loco contribuisce a ridurre la necessità di importazioni manuali di Terraform, di riconfigurazione degli endpoint e di riconciliazione dello stato durante gli incidenti.
  • Allineare i flussi di lavoro di ripristino ai principi dell’Infrastructure as Code (IaC) contribuisce a garantire l’integrità della configurazione e la prevedibilità operativa.
  • La progettazione del ripristino è fondamentale quanto quella del backup per i team che gestiscono ambienti di produzione tramite Terraform.

L’IaC garantisce coerenza, ripetibilità e controllo delle versioni negli cloud . Terraform diventa il punto di riferimento per definire cosa esiste, come è configurato e come dovrebbe comportarsi. Il ripristino introduce una nuova sfida.

Le operazioni di ripristino tradizionali spesso creano nuove risorse: nuovi bucket S3, nuove tabelle DynamoDB, nuovi endpoint. Dal punto di vista di Terraform, tali risorse non sono state definite nel codice. Non esistono nello stato. Ciò crea uno scostamento. Nelle operazioni di routine, lo scostamento è gestibile. Durante un incidente, si aggrava. È qui che la progettazione del ripristino è importante tanto quanto quella del backup.

Il problema della deriva nell’IaC

In un modello di ripristino tipico:

  • Una risorsa protetta viene ripristinata come nuova risorsa.
  • La risorsa originale rimane in uno stato danneggiato, sovrascritto o non funzionante.
  • Lo stato di Terraform non riconosce la nuova risorsa.
  • I team devono importare manualmente le risorse in State.
  • Potrebbe essere necessario aggiornare le configurazioni delle applicazioni.

Per platform gestiscono l’infrastruttura di produzione tramite Terraform, ciò comporta delle difficoltà proprio nel momento meno opportuno. La sfida non riguarda l’affidabilità del backup in sé, ma il modo in cui i flussi di lavoro di ripristino si integrano con le pratiche di “infrastruttura come codice”.

Presentazione del ripristino in loco con Clumio Backtrack

Clumio Backtrack è una funzionalità di ripristino che consente di ripristinare i dati direttamente nelle risorse AWS esistenti, anziché dover configurare un’infrastruttura sostitutiva. Se configurato tramite il provider Clumio Terraform, Backtrack consente di implementare flussi di lavoro di ripristino in linea con l’infrastruttura definita nel codice.

Clumio Backtrack supporta sia Amazon S3 che Amazon DynamoDB. Per un approfondimento tecnico sui flussi di lavoro di ripristino specifici per DynamoDB, consulta il nostro articolo sul blog dedicato a Clumio Backtrack per DynamoDB.

Anziché provvedere alla fornitura di risorse sostitutive, Backtrack aiuta a ripristinare:

  • Oggetti S3 direttamente nel bucket originale.
  • Dati DynamoDB inseriti direttamente nella tabella originale.

Dal punto di vista di Terraform, l’infrastruttura è destinata a rimanere invariata, con le risorse definite che continuano a corrispondere alla configurazione dichiarata. Ciò contribuisce a ridurre la necessità di importazioni manuali delle risorse, tabelle di ripristino temporanee, riconfigurazione degli endpoint e riconciliazione dello stato in situazioni di stress.

Un esempio pratico

Si consideri un ambiente di produzione gestito interamente tramite Terraform. Una tabella DynamoDB tiene traccia dell’inventario; un bucket S3 archivia le risorse dell’applicazione; i ruoli e le politiche di gestione delle identità e degli accessi sono codificati; e le politiche di protezione sono definite tramite Terraform. Se si verifica un danneggiamento prima di un evento di traffico di grande entità, gli approcci tradizionali di ripristino potrebbero creare nuove risorse che dovranno essere reintegrate in Terraform.

Con Backtrack, il ripristino è progettato per avvenire entro i limiti delle risorse esistenti, contribuendo a mantenere intatta l’infrastruttura definita e a preservare l’identità delle risorse. Questo approccio mira a eliminare la necessità di aggiornare Terraform per adattarlo a un bucket o a una tabella appena creati, trattando il ripristino come un’operazione a livello di dati piuttosto che come un’operazione di sostituzione dell’infrastruttura.

Perché questo è importante per Platform

Per i team che adottano l’IaC, i flussi di lavoro di ripristino dovrebbero garantire la conservazione dell’identità delle risorse, l’allineamento dello stato, l’integrità della configurazione e la prevedibilità operativa. Il ripristino in loco contribuisce al raggiungimento di tali obiettivi limitando le modifiche all’infrastruttura durante gli eventi di ripristino.

Ripristino su Cloud

Backtrack è progettato per funzionare su cloud , sia che si tratti di ripristinare un numero limitato di oggetti sia che si tratti di grandi set di dati. Le prestazioni di ripristino variano in base workload e alla configurazione dell’ambiente, ma l’obiettivo architetturale rimane lo stesso: ripristinare i dati senza introdurre nuove discrepanze nell’infrastruttura. Per gli ambienti gestiti tramite Terraform, questa distinzione è importante.

In quali contesti si applica questo approccio

Il ripristino in loco è particolarmente indicato per:

  • Carichi di lavoro DynamoDB ad alta produttività
  • Bucket S3 con un numero elevato di oggetti
  • Sistemi di produzione gestiti interamente tramite Terraform
  • Ambienti complessi in cui è difficile reindirizzare le dipendenze delle applicazioni verso nuove risorse

Quando l’infrastruttura viene definita in modo dichiarativo, i flussi di lavoro di ripristino dovrebbero seguire la stessa logica.

Come iniziare

Per scoprire Clumio Backtrack e la sua integrazione con Terraform:

Definire la protezione come codice è solo una parte del quadro. La progettazione di flussi di lavoro di ripristino che preservino l’integrità dell’infrastruttura completa il modello.

Domande frequenti

D: Quali problemi comportano i ripristini tradizionali negli ambienti gestiti da Terraform?

A: I ripristini tradizionali spesso creano nuove risorse, come bucket S3 sostitutivi o tabelle DynamoDB, che non sono definite nello stato di Terraform. Ciò può causare una deriva dell’infrastruttura e costringere i team a importare manualmente le risorse e a riconciliare le configurazioni durante gli incidenti più critici.

D: In che modo Clumio Backtrack si differenzia dai metodi di ripristino standard?

A: Anziché implementare una nuova infrastruttura, Clumio Backtrack è progettato per ripristinare i dati direttamente nella risorsa AWS esistente. Questo approccio consente di preservare l’identità della risorsa e di mantenere lo stato di Terraform allineato alla configurazione dichiarata.

D: Quali servizi AWS sono supportati da Clumio Backtrack?

R: Clumio Backtrack supporta Amazon S3 e Amazon DynamoDB. È progettato per ripristinare gli oggetti S3 nel bucket originale e i dati DynamoDB nella tabella originale, contribuendo a mantenere la coerenza con l’infrastruttura definita nel codice.

D: Perché il ripristino in loco è importante per platform ?

A: Platform si affidano all’infrastruttura come codice per garantire coerenza e controllo. Il ripristino in loco contribuisce a mantenere l’allineamento dello stato, l’integrità della configurazione e la prevedibilità operativa senza introdurre ulteriori modifiche all’infrastruttura durante gli eventi di ripristino.

D: In quali casi il ripristino in loco risulta particolarmente utile?

A: È particolarmente utile per carichi di lavoro DynamoDB ad alta produttività, bucket S3 con un numero elevato di oggetti e sistemi di produzione gestiti interamente tramite Terraform. Può inoltre rivelarsi vantaggioso in ambienti in cui il reindirizzamento delle dipendenze delle applicazioni verso risorse di nuova creazione risulterebbe complesso o rischioso.

D: Come possono le squadre iniziare a utilizzare l’integrazione tra Clumio Backtrack e Terraform?

R: I team possono consultare la documentazione del provider Clumio Terraform, esaminare il codice sorgente del provider su GitHub e guardare il video dimostrativo “Backtrack” citato nel blog per comprendere i dettagli relativi all’implementazione e al flusso di lavoro.

Lawrence Chang è direttore tecnico di Clumio e Vir Choksi è responsabile principale del marketing di prodotto presso Commvault.

More related posts

Thumbnail_Blog-AWS-Data-Protection-Terraform-Clumio-2026

Automating AWS Data Protection with Terraform and Clumio

Read more
Thumbnail_Blog_Clumio-Tech-2025

Restore only what matters: Clumio Backtrack for DynamoDB

Read more
Thumbnail_Blog-GoogleWorkspace-2026

How the Move to Clumio Delivered 66.7% Savings on AWS Backups

Read more
Thumbnail_Blog_AWS-Marketplace-AI

Commvault Featured in New AI Agent Solutions in AWS Marketplace

Read more
Man-and-woman-working-on-laptops-profile-Crocus-Thumbnail

Protecting Your Amazon S3 Data with Clumio: A Comprehensive Solution

Read more

Clumio

Read more

Punti di forza

  • La maggior parte delle esercitazioni teoriche serve a confermare l’efficacia delle prestazioni anziché mettere in luce le reali lacune nella risposta agli incidenti.
  • Affinché gli esercizi siano efficaci, devono prevedere elementi di attrito, ambiguità e pressione, in modo da rispecchiare le situazioni reali.
  • Limitare l’ambito dell’esercizio a pochi scenari critici e definire il successo come l’individuazione dei problemi piuttosto che come il semplice risultato di fare bella figura può portare a intuizioni più significative e concrete.
  • La partecipazione trasversale, e non solo quella dei team tecnici, è fondamentale per valutare con precisione la risposta dell’organizzazione.
  • La vera resilienza si dimostra attraverso test di ripristino concreti, non solo con scenari teorici.

C’è un momento che la maggior parte dei responsabili della sicurezza riconosce, anche se non lo dice ad alta voce. L’esercitazione teorica è appena terminata. Il team sta uscendo dalla sala. Tutti sembrano ragionevolmente soddisfatti. E da qualche parte, in fondo alla mente, affiora una domanda silenziosa: abbiamo davvero imparato qualcosa?

Se si è onesti, la risposta è spesso no.

Questo non perché le esercitazioni teoriche siano una cattiva idea. Sono uno degli strumenti più preziosi a disposizione di un responsabile della sicurezza. Il problema è il modo in cui la maggior parte delle organizzazioni le conduce – e ciò che effettivamente misurano quando lo fanno.

La trappola delle prestazioni

L’errore più comune nelle esercitazioni teoriche non ha nulla a che vedere con lo scenario. Ha a che fare con l’obiettivo. La maggior parte dei team, consapevolmente o meno, costruisce esercitazioni progettate per dimostrare competenza piuttosto che per individuare lacune.

Lo scenario segue generalmente un arco narrativo lineare. Le informazioni arrivano in sequenza logica. Le persone giuste dicono le cose giuste. Tutti si sentono preparati. E quella sensazione – di sicurezza, di aver provato a fondo, quasi di affiatamento – è proprio il problema. Gli incidenti reali non seguono un andamento lineare. Si presentano con informazioni incomplete, segnali contrastanti, persone irreperibili e un’azienda che esige risposte più rapide di quanto i fatti consentano. Se la vostra simulazione non ricrea questo tipo di attrito, non avete testato la risposta agli incidenti. Avete semplicemente provato una conversazione.

Quando l’esercitazione è progettata per convalidare anziché per mettere alla prova sotto stress, ne deriva un secondo problema: le persone smettono di essere oneste. Nessuno dice: «Non so a chi spetti quella decisione» o «non abbiamo mai effettivamente testato quel percorso di Recovery». Dicono ciò che suona giusto. E le lacune che dovrebbero emergere in un ambiente controllato rimangono nascoste finché non vengono alla luce in uno reale.

Cosa verifica effettivamente un buon esercizio

Prima di elaborare uno scenario, devi rispondere a una domanda più semplice: cosa vuoi davvero imparare? Non venti cose. Tre o quattro.

Il vostro team è in grado di prendere una decisione di spegnimento con sufficiente rapidità e tutti sanno chi ha l’autorità per prenderla? Quando i reparti di sicurezza, IT, legale e comunicazione sono tutti nella stessa stanza con priorità contrastanti, riescono davvero a prendere decisioni insieme? Siete in grado di spiegare l’impatto aziendale di un incidente in modo sufficientemente chiaro da spingere la dirigenza ad agire – e non solo a capire? E se doveste ripristinare un sistema critico nelle prossime quattro ore, sareste davvero in grado di farlo?

Una volta che sapete cosa state testando, costruite uno scenario con attriti reali. Rendete indisponibile una persona chiave a metà dell’esercitazione. Introducete un’escalation da parte di un cliente. Fate in modo che un’autorità di regolamentazione ponga una domanda a cui il team non può rispondere attingendo al runbook.
Fornite alle persone informazioni incomplete e osservate come prendono comunque le decisioni. Il valore non sta nel vedere le persone avere successo sotto pressione. Sta nell’individuare i punti in cui il processo si interrompe mentre la posta in gioco è ancora abbastanza bassa da poterlo correggere.

Dite questo ad alta voce all’inizio: oggi il successo significa individuare i problemi, non fare bella figura. Quella sola frase cambia ciò che le persone sono disposte a dire in quella stanza.

Il problema delle persone

Una simulazione che coinvolga solo i reparti di sicurezza e IT è una discussione tecnica, non un’esercitazione di risposta agli incidenti. Se l’ufficio legale non è presente, se l’ufficio comunicazioni non è presente, se i responsabili di business e la dirigenza sono assenti, non state testando come la vostra organizzazione risponda effettivamente a una crisi. State solo verificando come un gruppo ristretto di persone competenti analizzi un caso ipotetico. Gli incidenti reali vengono gestiti a tutti i livelli dell’azienda. L’esercitazione dovrebbe rispecchiare questa realtà.

Parlarne non basta

È proprio qui che la maggior parte delle organizzazioni si ferma. Un esercizio teorico è importante, ma non basta a infondere fiducia. Discutere uno scenario di Recovery vi fornisce alcune informazioni. Ripristinare effettivamente un sistema vi fornisce informazioni diverse. Siete in grado di riportare le identità a un punto nel tempo in cui erano integre? Potete verificare che ciò che state ripristinando sia affidabile? Siete in grado di ripristinare un’applicazione di primo livello e confermare che torni a funzionare correttamente, senza portare con sé l’infezione?

Non sono domande a cui si può rispondere in una sala riunioni. A un certo punto, il piano deve confrontarsi con la realtà sul campo – e bisogna capire se i due aspetti sono compatibili.

Al termine dell’esercitazione

Il debriefing vi dirà se l’esercitazione è stata significativa. Se il debriefing immediato è silenzioso, vago o pieno di “buoni promemoria”, l’esercitazione non è stata abbastanza impegnativa. Un’esercitazione teorica ben condotta dovrebbe lasciarvi con un breve elenco di risultati concreti, responsabili chiari e scadenze precise. Se non siete in grado di rispondere a quali problemi si sono verificati, chi li sta risolvendo e entro quando, avete organizzato un evento, non un’esercitazione.

L’obiettivo non è mai stato quello di superare l’esercizio. Era quello di imparare qualcosa di importante finché il prezzo da pagare per un errore era solo il tempo. Ascoltate la nostra ultima puntata del podcast STRIVE, in cui mi unisco al mio collega Chris Mierzwa, Senior Director del Portfolio Marketing, per una conversazione approfondita sulle esercitazioni teoriche.

Domande frequenti

D: Perché la maggior parte delle esercitazioni teoriche non riesce a fornire un valore concreto?

A: Molte esercitazioni sono concepite per far apparire le squadre ben preparate, piuttosto che per mettere in luce i loro punti deboli. Ciò porta a discussioni prestabilite che non rispecchiano l’imprevedibilità e la pressione degli incidenti reali.

D: Quale dovrebbe essere l’obiettivo di un’esercitazione teorica?

A: Dovrebbe concentrarsi sulla risposta a un numero limitato di domande fondamentali, quali la rapidità del processo decisionale, la chiarezza delle responsabilità e la capacità di recupero. Questo approccio aiuta i team a individuare lacune significative anziché limitarsi a osservazioni superficiali.

D: In che modo le organizzazioni possono rendere le esercitazioni più realistiche?

A: Introdurre elementi di incertezza, informazioni mancanti e interruzioni impreviste nel corso dello scenario. Questi elementi costringono i team a pensare in modo critico e ad agire sotto pressione, in condizioni più simili a quelle di un incidente reale.

D: Chi dovrebbe partecipare a un’esercitazione teorica?

A: Oltre ai reparti di sicurezza e IT, dovrebbero partecipare anche team come quelli dell’ufficio legale e della comunicazione, i responsabili aziendali e i dirigenti. Ciò consente all’esercitazione di rispecchiare il modo in cui gli incidenti reali vengono gestiti a livello dell’intera organizzazione.

D: Perché non basta parlare del processo di recupero?

A: La discussione può mettere in luce i piani, ma solo dei test concreti dimostrano se i sistemi possano effettivamente essere ripristinati in modo corretto e rapido. È necessaria una verifica pratica per confermare la prontezza al ripristino.

D: Cosa determina il successo di un’esercitazione teorica?

A: Un esercizio efficace porta a risultati chiari, a responsabili ben definiti e a scadenze precise per l’adozione delle misure correttive. Se questi elementi mancano, è probabile che l’esercizio non abbia messo sufficientemente alla prova il team.

Chris Bevil è responsabile del settore Global Cyber Resilience & AI presso Commvault.

More related posts

Thumbnail_Blog-Commvault-Enhancements-Cyber-Recovery-2026

Commvault Enhancements in Cyber Recovery

Read more
Readiverse-Featured-Image-888-x-500

Ready Is Good. Resilient Is Better.

Read more
Thumbnail_5_MV_Blogs_2025

Recovery Testing: The Missing Piece in Most Cyber Resilience Programs

Read more
Urgent-Need-for-Cyber-Resilience

The Urgent Need for Cyber Resilience

Read more
Thumbnail_Blog_Modern-Playbook-2025

Your Modern Playbook for Rapid Response and Clean Recovery

Read more

Punti di forza

  • La governance dell’accesso ai dati di Commvault, basata sulla tecnologia Satori, unifica la visibilità, il controllo degli accessi e la tracciabilità su dati strutturati, file non strutturati, SaaS e carichi di lavoro basati sull’intelligenza artificiale.
  • Una politica di accesso unica e coerente può disciplinare sia gli utenti umani che i modelli di intelligenza artificiale, contribuendo a ridurre i silos e a limitare l’eccessiva esposizione dei dati sensibili.
  • L’individuazione, la classificazione e la valutazione continua dei rischi contribuiscono a fornire informazioni prioritarie su dove si trovano i dati sensibili e dove il rischio di esposizione è più elevato.
  • Il mascheramento e la redazione dinamici basati su criteri consentono di applicare il principio del privilegio minimo, garantendo l’uso autorizzato dei dati e contribuendo al contempo a proteggere i campi sensibili.
  • I registri di audit centralizzati e quasi in tempo reale offrono una visibilità completa sulle query degli utenti, sui prompt dell’IA e sugli eventi relativi agli accessi regolamentati, contribuendo a garantire la conformità e la responsabilità.

Con l’intelligenza artificiale ormai integrata in ogni flusso di lavoro, dai copiloti agli assistenti di chat fino agli strumenti di analisi, tutti questi endpoint hanno sviluppato un forte bisogno di dati da elaborare. Le funzionalità di governance dell’accesso ai dati di Commvault, basate sulla tecnologia Satori, sono progettate per soddisfare al meglio questa “fame” di dati dell’intelligenza artificiale, unificando visibilità, controllo degli accessi e tracciabilità in tutto il vostro panorama dei dati.

Una base unificata per la governance dei dati nell’era dell’intelligenza artificiale

Le funzionalità di governance dell’accesso ai dati di Commvault riuniscono database strutturati, file non strutturati nelle SaaS e carichi di lavoro basati sull’intelligenza artificiale in un unico modello di governance, anziché trattarli come silos separati. Le organizzazioni possono ora applicare un’unica politica di accesso sia agli utenti umani che ai modelli di intelligenza artificiale, in modo che le stesse regole determinino chi o cosa possa accedere alle informazioni sensibili, indipendentemente dalla loro ubicazione.

Grazie all’integrazione di Satori nel Commvault Command Center, queste funzionalità estendono la protezione tradizionale di Commvault ai dati in tempo reale e all’utilizzo dell’intelligenza artificiale, non limitandosi più ai soli backup e snapshot. Ciò consente ai team addetti alla sicurezza e alla protezione dei dati di passare da una risposta reattiva agli incidenti a un controllo proattivo su come i dati vengono individuati, consultati e utilizzati in tempo reale.

Individuazione, classificazione e valutazione del rischio in tempo reale

Uno dei pilastri fondamentali delle nostre capacità di governance dei dati è l’individuazione e la classificazione unificate dei dati su cloud e SaaS. Man mano che le organizzazioni si collegano ad ambienti quali AWS, Azure, Google Cloud, Snowflake, Databricks e altri, Commvault mappa automaticamente gli archivi di dati e li classifica in modo continuo, indipendentemente dal fatto che si tratti di dati strutturati o non strutturati.

A ogni risorsa viene assegnato un punteggio di rischio, che offre ai team una visione gerarchizzata di dove si trovano le informazioni sensibili e dove l’esposizione al rischio è maggiore. Anziché affidarsi a scansioni periodiche, la platform il passo con i movimenti dei dati, i nuovi archivi e le modifiche alla classificazione, aiutando i team a individuare i problemi in anticipo e a concentrarsi innanzitutto sulle aree a più alto rischio.

Accesso con privilegi minimi tramite mascheramento dinamico e oscuramento

La protezione dei dati tradizionale spesso si limita a individuare dove si trovano i dati sensibili; le funzionalità di Commvault puntano invece a controllare le modalità di divulgazione di tali dati. Grazie al mascheramento e alla redazione basati su criteri, le organizzazioni possono applicare il principio del “privilegio minimo”, in modo che utenti, servizi e modelli di IA abbiano accesso solo alle informazioni specifiche per cui sono autorizzati, con i campi sensibili resi anonimi o nascosti secondo necessità.

Poiché le stesse politiche di mascheramento e oscuramento si applicano a tutti gli ambienti collegati, le organizzazioni possono garantire un controllo coerente degli accessi, evitando regole frammentate e applicate applicazione per applicazione. Ciò contribuisce a ridurre il rischio di un’eccessiva esposizione dei dati, ovvero la situazione in cui un numero eccessivo di persone o sistemi ha accesso a più dati di quelli di cui ha legittimamente bisogno.

Sicurezza e gestione sicura e tempestiva

Una funzionalità di spicco è la sicurezza basata sull’intelligenza artificiale e guidata da policy, che opera a livello di prompt e risposta. Prima ancora che i dati vengano inviati a un modello di intelligenza artificiale, Commvault, grazie alla tecnologia Satori, è in grado di intercettare l’interazione, individuare i campi sensibili (come i dati personali soggetti a normative) e applicare il mascheramento o la redazione in linea, in base alle policy di accesso ai dati esistenti.

A differenza delle soluzioni che si limitano a bloccare interi prompt o che si affidano esclusivamente alla prevenzione della perdita di dati a valle (trasferendo così la responsabilità della sicurezza a terzi), questo approccio consente ai dipendenti di continuare a utilizzare gli assistenti IA in modo produttivo, mantenendo al contempo i dati sensibili sotto controllo. Poiché la mascheratura avviene prima che il modello elabori i dati, contribuisce inoltre a impedire che le informazioni sensibili influenzino o contaminino i set di dati utilizzati per l’addestramento dell’IA, proteggendo sia gli utenti che l’ambiente IA in generale.

Le tracce di audit centralizzate favoriscono la conformità

L’ultimo tassello delle nostre funzionalità di governance dell’accesso ai dati è costituito da una registrazione completa e centralizzata dei log di audit. Ogni interazione – che si tratti di una query dell’utente, di un prompt dell’IA o di un evento di accesso regolamentato – viene registrata in tempo quasi reale, con dettagli quali chi ha effettuato l’accesso a cosa, quale politica è stata applicata e quali operazioni di oscuramento sono state effettuate.

Questa visibilità unificata sull’audit abbraccia dati in tempo reale, prompt generati dall’intelligenza artificiale ed eventi relativi alla governance degli accessi, fornendo ai responsabili della sicurezza, dell’IT e della conformità un unico registro autorevole anziché registri disparati provenienti da strumenti puntuali. Per i CISO e i CIO, ciò si traduce in verifiche di conformità più rapide e nella chiara dimostrazione che la governance non è solo documentata sulla carta, ma viene attivamente applicata in tutto l’ambiente.

Aiutare le organizzazioni ad adottare l’intelligenza artificiale in modo sicuro

Nel loro insieme, queste nuove funzionalità offrono alle organizzazioni un approccio coerente per governare i dati in un mondo basato sull’IA: visibilità unificata su cloud, SaaS e IA; un’unica politica per utenti e modelli; mascheramento e oscuramento dinamici per un accesso con privilegi minimi; e protezione dei prompt dell’IA conforme alle politiche, supportata da tracciati di audit completi. Il risultato è il passaggio da controlli reattivi a una governance proattiva dell’accesso ai dati, pronta per l’IA, che aiuta i team ad abbracciare l’innovazione dell’IA mantenendo il controllo sulle informazioni più sensibili.

Domande frequenti

D: In che modo l’approccio di Commvault alla governance dei dati basata sull’intelligenza artificiale si differenzia dalla protezione dei dati tradizionale?

R: La protezione dei dati tradizionale si concentra spesso sui backup e sulla risposta agli incidenti dopo che l’esposizione si è verificata. Commvault estende la governance agli ambienti operativi e alle interazioni con l’IA, consentendo un controllo proattivo su come i dati vengono individuati, consultati e utilizzati in tempo reale. Questo cambiamento aiuta le organizzazioni a gestire il rischio prima che si trasformi in una violazione.

D: In che modo l’individuazione e la classificazione unificate migliorano la sicurezza?

R: L’individuazione e la classificazione continue mappano ed etichettano automaticamente i dati strutturati e non strutturati su cloud e piattaforme SaaS. Assegnando punteggi di rischio a ciascuna risorsa, i team ottengono una visione prioritaria dell’esposizione dei dati sensibili. Ciò consente di identificare più rapidamente le aree ad alto rischio e di concentrare maggiormente gli sforzi di correzione.

D: Che cos’è il mascheramento dinamico e perché è importante per i carichi di lavoro basati sull’intelligenza artificiale?

R: Il mascheramento dinamico e la redazione limitano ciò che gli utenti, i servizi e i modelli di IA possono vedere in base a politiche predefinite. I campi sensibili possono essere resi anonimi o nascosti, pur consentendo l’accesso legittimo ai dati rilevanti. Questo approccio favorisce la produttività contribuendo al contempo a ridurre il rischio di sovraesposizione.

D: Come funziona la protezione dei prompt dell’IA basata sulle politiche?

R: La sicurezza basata su policy per l’IA intercetta le richieste e le risposte prima che i dati raggiungano il modello di IA. Aiuta a rilevare le informazioni sensibili e ad applicare il mascheramento o la redazione in linea secondo le policy esistenti. Ciò consente ai dipendenti di continuare a utilizzare gli strumenti di IA, contribuendo al contempo a mantenere i dati soggetti a regolamentazione sotto controllo e fuori dai set di dati di addestramento.

D: In che modo le tracce di audit centralizzate supportano le attività di conformità?

R: La registrazione completa degli audit rileva dettagli su chi ha avuto accesso a quali dati, quali politiche sono state applicate e quali operazioni di redazione sono state effettuate. Questa visibilità unificata abbraccia i dati in tempo reale e le interazioni con l’IA, contribuendo a fornire ai responsabili della sicurezza e della conformità un registro chiaro e autorevole. Contribuisce a consentire revisioni più rapide e a dimostrare che i controlli di governance vengono attivamente applicati.

D: In che modo queste funzionalità aiutano le organizzazioni ad adottare l’intelligenza artificiale in modo sicuro?

R: Grazie alla combinazione di visibilità unificata, applicazione coerente delle politiche, mascheramento dinamico e tracciabilità completa, le funzionalità di governance dei dati di Commvault offrono alle organizzazioni un quadro coerente per la gestione dei dati nell’era dell’IA. Questi controlli favoriscono l’innovazione, consentendo al contempo di mantenere il controllo sulle informazioni sensibili. Il risultato è un percorso più sicuro e affidabile verso l’adozione dell’IA.

Nico Guerrera è Senior Technical Marketing Manager presso Commvault.

More related posts

Social_Blog_Satori_GigaOm_Leader_2026_Linkedin

Satori Named Leader in GigaOm’s Data Access Governance Radar Report

Read more
Thumbnail_Blog-Conversational-Resilience-2025-Linkedin

Conversational Resilience: The New Way to Manage and Protect Enterprise Data

Read more
Thumbnail_Blog_Satori-Acquisition-2025

Commvault Closes Acquisition of Satori, Strengthening Data and AI Security Platform

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more