telodico.io

Cloud

Il cloud non è un backup: la responsabilità dei dati resta vostra

Microsoft 365, Google Workspace e gli altri SaaS non sono automaticamente il vostro backup. Per una PMI il punto non è diffidare del cloud, ma separare servizio, identità e copia dei dati.

8 min

Il cloud non è un backup: la responsabilità dei dati resta vostra

C’è un equivoco molto comodo nel modo in cui molte PMI italiane usano il cloud: se la posta, i file e le chat sono su una grande piattaforma, allora qualcuno starà già facendo il backup. Qualcuno, sì. Ma non necessariamente per voi, non necessariamente con i tempi che vi servono e non necessariamente al di fuori del vostro stesso perimetro, che nel frattempo potrebbe essere compromesso.

Il cloud ha risolto problemi enormi: server di posta fragili, NAS dimenticati in un armadio, aggiornamenti fatti quando capitava, dischi sostituiti in emergenza. Dire che il backup resta una responsabilità aziendale non è nostalgia del ferro in cantina. È il contrario: è prendere sul serio il cloud, trattandolo come infrastruttura critica e non come magia in abbonamento.

La tesi è semplice: un servizio SaaS affidabile non coincide con una strategia di protezione dei dati. Microsoft 365, Google Workspace, CRM, ERP cloud, repository documentali e strumenti AI aziendali vanno protetti con copie indipendenti, prove di ripristino e contratti leggibili. Non perché i grandi vendor siano inaffidabili, ma perché il modello di responsabilità condivisa lascia all’azienda una parte che non si può delegare con un clic.

1. Alta disponibilità non significa recupero dei vostri errori

I grandi servizi cloud sono progettati per restare disponibili anche quando si guasta un componente, un data center o un’intera zona infrastrutturale. È una cosa preziosa. Una PMI che vent’anni fa avrebbe avuto un server Exchange sotto la scrivania oggi compra posta, storage e collaborazione con livelli di affidabilità che difficilmente potrebbe replicare da sola.

Ma l’alta disponibilità del servizio non è la stessa cosa del ripristino del singolo dato aziendale perso, cifrato, cancellato o sovrascritto. Se un utente elimina cartelle importanti, se un amministratore sbaglia una policy di conservazione, se un malware cifra file sincronizzati, se un account compromesso svuota repository condivisi, il problema non è se il SaaS sia online. Il problema è se l’azienda possa tornare a una versione pulita, completa e verificabile dei propri dati.

Cestino, versioning e retention sono utili. Non vanno disprezzati. Ma da soli non sono una strategia di backup indipendente. Sono funzionalità interne allo stesso ambiente, governate spesso dalle stesse identità, dagli stessi amministratori e dalle stesse policy che potrebbero essere parte dell’incidente.

Qui sta il punto che nelle riunioni commerciali tende a sparire: il vendor si impegna a erogare il servizio, ma l’azienda resta responsabile della configurazione, degli accessi, della conservazione coerente con il proprio rischio e della capacità di recupero operativo. Il modello di responsabilità condivisa dei principali cloud provider non è una clausola decorativa. È la descrizione di chi fa cosa quando qualcosa va storto.

Per una PMI non deve diventare un romanzo di compliance, ma una domanda pratica: se domani mattina spariscono le cartelle del commerciale, le email degli ultimi tre mesi o gli allegati del gestionale, chi li ripristina, da dove, in quanto tempo e con quali credenziali?

2. La normativa non chiede eroismi, chiede ripristino

Il GDPR viene spesso ricordato solo per informative, consensi e sanzioni. È una lettura povera, soprattutto per chi gestisce sistemi IT. L’articolo 32 del Regolamento parla di sicurezza del trattamento e cita espressamente la capacità di assicurare riservatezza, integrità, disponibilità e resilienza dei sistemi e dei servizi. Nello stesso articolo compare anche la capacità di ripristinare tempestivamente la disponibilità e l’accesso ai dati in caso di incidente fisico o tecnico.

Non è una formula astratta. Se i dati dei clienti, dei dipendenti, degli ordini o dell’assistenza sono dentro un SaaS, la disponibilità non si dimostra dicendo che il fornitore è famoso. Si dimostra sapendo recuperare i dati quando l’incidente riguarda il proprio tenant, i propri permessi o i propri utenti.

Anche la NIS2 va nella stessa direzione, per i soggetti che rientrano nel suo perimetro e per molte aziende che ci entrano indirettamente come fornitori. Tra le misure di gestione del rischio la direttiva include la gestione degli incidenti, la continuità operativa, i backup e il disaster recovery. Non chiede a tutte le PMI di costruire un SOC da banca. Dice però una cosa concreta: continuità e backup sono parte della sicurezza, non una voce accessoria del budget IT.

Molte PMI non saranno soggetti NIS2 diretti. Questo non le esonera dal problema. Sempre più clienti strutturati, capifiliera, gruppi industriali e pubbliche amministrazioni chiedono evidenze minime ai fornitori: dove sono i dati, come sono protetti, che tempi di ripristino avete, chi può cancellare cosa. La pressione arriva dal contratto prima ancora che dal regolatore.

La buona notizia è che il salto richiesto non è burocratico. Non serve un documento di quaranta pagine per poi non saper ripristinare una mailbox. Serve scegliere pochi dati critici, proteggerli fuori dal dominio del problema e provare davvero il recupero.

3. Il punto debole è il tenant, non il data center del vendor

Quando si parla di cloud, molte discussioni partono dalla localizzazione dei data center. È un tema importante, ma spesso non è il primo incidente che colpisce una PMI. Il primo rischio è molto più vicino: identità compromesse, amministratori troppo potenti, MFA assente o applicato male, permessi ereditati da anni, sincronizzazioni automatiche che propagano l’errore.

Se un attaccante entra con credenziali valide in un account amministrativo, può fare danni senza bucare l’infrastruttura del provider. Può creare regole di inoltro, cancellare dati, modificare criteri di conservazione, aggiungere applicazioni malevole, alterare configurazioni. In quel caso il servizio cloud può funzionare perfettamente mentre la vostra azienda perde informazioni.

È qui che il backup deve essere separato dal tenant operativo. Separato non vuol dire per forza complicato. Vuol dire che la copia non deve dipendere solo dagli stessi account, dalle stesse policy e dalla stessa console che potrebbero essere compromessi. Vuol dire che chi amministra Microsoft 365 o Google Workspace non deve poter cancellare con leggerezza anche tutte le copie storiche. Vuol dire che il ripristino deve essere possibile anche quando l’ambiente primario è sotto indagine o non ci si fida più delle sue identità.

La stessa logica vale per gli strumenti AI che iniziano a leggere documenti aziendali. Un assistente che indicizza file, email, ticket e knowledge base diventa utile proprio perché attinge a dati vivi. Ma se quei dati non sono protetti, versionati e ripristinabili, l’AI amplifica il disordine. Non crea il rischio dal nulla: lo rende più veloce, più visibile e più difficile da contenere.

Per questo la sovranità tecnologica, in una PMI, non comincia con una bandiera sul sito del provider. Comincia con la possibilità di dire: i dati sono nostri, sappiamo dove sono, abbiamo una copia leggibile, possiamo ripristinarli senza chiedere permesso al sistema che si è appena rotto.

4. Cosa deve avere un backup SaaS serio, senza farne un progetto infinito

La protezione dei dati SaaS non deve diventare una gara a chi compra più licenze. Deve essere proporzionata. Una PMI metalmeccanica, uno studio professionale, un e-commerce B2B e una società di servizi hanno rischi diversi. Ma alcuni criteri sono comuni e permettono di distinguere una soluzione utile da una rassicurazione commerciale.

Un backup SaaS sensato dovrebbe avere almeno questi elementi:

  • copie automatiche di mailbox, calendari, contatti, file condivisi, siti documentali e, dove rilevante, chat e gruppi di lavoro;
  • conservazione configurabile in base alle esigenze dell’azienda, non limitata al cestino o alla retention standard del servizio;
  • credenziali e ruoli separati rispetto agli amministratori ordinari del tenant;
  • ripristino granulare: singolo file, cartella, mailbox, messaggio o intero utente;
  • esportazione dei dati in formati riutilizzabili, senza costringere l’azienda a restare per sempre nello stesso strumento di backup;
  • log delle operazioni di backup e restore, utili quando bisogna capire chi ha fatto cosa;
  • cifratura, controllo degli accessi e collocazione dei dati coerenti con le esigenze contrattuali e regolatorie.

La lista è meno lunga di quanto sembri. In pratica si tratta di evitare tre errori: salvare troppo poco, salvare nello stesso punto fragile, non provare mai a ripristinare. Il terzo è il più diffuso.

Molte aziende scoprono la qualità del backup nel momento peggiore, cioè quando serve. È il modo più costoso per fare un test. Una prova trimestrale o semestrale, anche piccola, cambia completamente la postura: si sceglie una mailbox, una cartella condivisa, un cliente fittizio nel CRM, un progetto archiviato; si ripristina; si misura il tempo; si corregge ciò che non funziona.

Non serve partire da tutto. Anzi, partire da tutto è spesso il modo migliore per non partire mai. Meglio identificare i dieci insiemi di dati senza i quali l’azienda si ferma: posta direzionale, documenti amministrativi, offerte, contratti, distinte, ticket, file di produzione, repository del sito, database del gestionale, knowledge base. Poi si estende.

5. Provider vicino non vuol dire piccolo: vuol dire reperibile quando il ripristino è sporco

Il backup è una di quelle aree in cui la prossimità operativa pesa più della brochure. Quando tutto funziona, una console internazionale e un help center remoto sembrano sufficienti. Quando bisogna ripristinare dati in fretta, capire una cancellazione anomala, coordinarsi con chi gestisce identità, firewall, endpoint e gestionale, avere un interlocutore tecnico raggiungibile diventa un vantaggio concreto.

Questo non significa rifiutare Microsoft 365, Google Workspace, AWS, Azure o altri grandi servizi. Significa non consegnare tutto il ciclo di vita del dato allo stesso perimetro operativo. Un system integrator italiano, un MSP competente o un provider cloud nazionale possono costruire una protezione più aderente alla realtà della PMI: meno slide, più prove; meno architetture monumentali, più responsabilità chiare.

La domanda da fare al fornitore non è solo quanto costa il backup per utente al mese. È troppo poco. Le domande serie sono altre: chi può cancellare le copie, dove sono conservate, come si ripristina se il tenant è compromesso, quanto tempo serve per recuperare cento gigabyte, come si esporta tutto se cambiamo piattaforma, chi risponde il sabato mattina se il ripristino non parte.

C’è poi un aspetto di lock-in che raramente viene discusso: anche il backup può diventare una gabbia. Se le copie sono accessibili solo attraverso una piattaforma proprietaria, se l’esportazione massiva è lenta o costosissima, se il contratto rende difficile uscire, la soluzione nata per liberare l’azienda dal rischio finisce per crearne un altro. Il backup non deve essere un secondo lock-in appoggiato al primo.

Una buona architettura, per una PMI, può essere molto pragmatica: SaaS primario scelto per produttività e collaborazione; backup indipendente gestito da un operatore vicino; copie cifrate in una regione coerente con i contratti; credenziali separate; prove di restore calendarizzate; documentazione breve ma aggiornata. Non è una rivoluzione. È igiene industriale.

6. La prova che conta: ripartire senza chiedere fiducia al disastro

La vera domanda non è se il cloud sia sicuro. Posta così, è una domanda inutile. Il cloud può essere molto sicuro e, allo stesso tempo, l’azienda può restare esposta perché ha configurato male identità, permessi e conservazione. Il problema non è scegliere tra cloud e non cloud. Il problema è non confondere il servizio con il controllo.

Un esercizio concreto, alla portata di molte PMI, è simulare tre scenari in una mattina: recupero di una mailbox cancellata, ripristino di una cartella condivisa sovrascritta, esportazione di un set documentale fuori dalla piattaforma. Se il test riesce, si misurano i tempi e si formalizza la procedura. Se non riesce, si è appena scoperto un rischio senza pagarlo durante un incidente reale.

È anche la differenza tra compliance utile e burocrazia. Un file che dice «abbiamo un backup» non salva nulla. Una procedura provata, con un referente tecnico, credenziali funzionanti e tempi misurati, sì. Ed è esattamente il tipo di evidenza che un cliente serio capisce, senza trasformare la fornitura in un audit permanente.

Le PMI italiane hanno un vantaggio che spesso sottovalutano: sono veloci. Possono decidere in poche settimane ciò che in un grande gruppo richiede mesi di comitati. Possono scegliere un partner tecnico vicino, fare un inventario essenziale dei dati SaaS, mettere in sicurezza le identità amministrative e provare un restore senza aspettare il prossimo budget annuale.

Il cloud resta una scelta sensata. Anzi, per molte aziende è la più razionale. Ma va trattato per quello che è: un servizio potente, non una rinuncia alla responsabilità sui dati. Chi controlla solo la licenza controlla poco. Chi controlla copia, accessi, ripristino ed esportazione ha una posizione diversa, anche verso i grandi vendor.

La sovranità, qui, non è uno slogan geopolitico. È la capacità di recuperare i propri dati quando il sistema primario non basta più. E per una PMI questa capacità vale molto più di una promessa generica di affidabilità.

Riferimenti

Fonti ufficiali

Le versioni autoritative restano quelle pubblicate dagli enti competenti. Verifica sempre alla fonte prima di prendere decisioni operative.

In sintesi

Domande frequenti

Se uso Microsoft 365 o Google Workspace, non sono già coperto dal backup del vendor?

No. I grandi provider garantiscono alta disponibilità e resilienza dell'infrastruttura, ma non il ripristino di dati che avete cancellato, sovrascritto o fatto cifrare da un malware. Il modello di responsabilità condivisa lascia all'azienda la parte relativa a configurazione, accessi, conservazione e capacità di recupero. Cestino, versioning e retention sono utili ma restano interni allo stesso ambiente potenzialmente compromesso.

Perché il backup dovrebbe essere separato dal tenant se il data center del provider è sicuro?

Perché il primo rischio per una PMI non è il guasto infrastrutturale ma l'identità compromessa. Un account amministrativo violato può cancellare dati, alterare policy di conservazione ed eliminare copie storiche senza mai bucare l'infrastruttura del provider. Una copia con credenziali e ruoli separati permette di ripristinare anche quando non ci si fida più delle identità dell'ambiente primario.

Da dove parto se non voglio trasformare il backup SaaS in un progetto infinito?

Non partite da tutto: è il modo migliore per non partire mai. Identificate i dieci insiemi di dati senza i quali l'azienda si ferma (posta direzionale, contratti, offerte, gestionale, ticket, knowledge base) e proteggeteli con copie indipendenti. Poi calendarizzate una prova di ripristino trimestrale o semestrale, anche piccola, e misurate i tempi.

Cosa devo chiedere davvero a un fornitore di backup, oltre al costo per utente?

Le domande che contano sono: chi può cancellare le copie, dove sono conservate, come si ripristina se il tenant è compromesso, quanto tempo serve per recuperare volumi rilevanti, come si esportano i dati se si cambia piattaforma e chi risponde nel weekend. Verificate anche il rischio di lock-in: se le copie sono accessibili solo tramite una piattaforma proprietaria e l'esportazione è lenta o costosa, avete solo aggiunto una seconda gabbia.

La mia PMI non rientra nel perimetro NIS2: posso ignorare il tema continuità e backup?

No. Anche senza obblighi diretti, il GDPR (art. 32) richiede di assicurare disponibilità dei dati e capacità di ripristino tempestivo in caso di incidente. Inoltre la pressione arriva dal contratto: capifiliera, gruppi industriali e PA chiedono ai fornitori evidenze su dove sono i dati, come sono protetti e quali tempi di ripristino garantite.

Come dimostro a un cliente o a un auditor che il mio backup funziona davvero?

Non con un documento che dichiara «abbiamo un backup», ma con una procedura provata. Simulate tre scenari in una mattina: recupero di una mailbox cancellata, ripristino di una cartella sovrascritta ed esportazione di un set documentale fuori dalla piattaforma. Formalizzate i tempi misurati e indicate un referente tecnico con credenziali funzionanti: è l'evidenza che un cliente serio comprende senza trasformare la fornitura in un audit permanente.

Discussione (0)

Carico…


Per commentare serve un'identità verificata. Inserisci la tua email: riceverai un link per accedere senza password.