Backup e ripristino nei servizi ICT: quando avete testato per ultimo?
La domanda "avete un backup" non è quella che conta. La domanda che conta è: quando qualcuno ha tentato per ultimo di ripristinare effettivamente un sistema da quel backup, e quanto tempo ha impiegato? Un backup che viene creato ma mai ripristinato è in pratica un'assunzione. Le autorità di vigilanza e i clienti che si basano sulle misure di diligenza della direttiva NIS2 quindi non guardano solo all'esistenza di una politica di backup, ma alla prova che il ripristino funziona davvero.
Per un fornitore di servizi ICT questo non è un dettaglio. Spesso non gestite solo il vostro ambiente, ma anche i sistemi dei clienti, da remoto, talvolta con l'aiuto di un subappaltatore. Se qualcosa va male, non conta chi ha commesso l'errore, ma se il ripristino ha funzionato entro un tempo che il cliente poteva giustificare. Questo rende il test di ripristino una delle poche misure che non potete spuntare con un documento.
Perché un backup non testato non conta
Un backup può essere inutilizzabile per molte ragioni: un file corrotto, una configurazione errata, una password che nessuno ricorda più, o una procedura di ripristino che sulla carta funziona ma in pratica richiede tre giorni invece di tre ore. Nessuno di questi problemi diventa visibile finché qualcuno non usa effettivamente il backup. L'articolo 21 della direttiva NIS2 menziona esplicitamente la politica di backup e ripristino come parte delle misure di gestione dei rischi che un'organizzazione deve considerare nei suoi fornitori. In pratica, questo significa che un cliente che è soggetto all'obbligo di diligenza chiede al suo fornitore di servizi ICT come è organizzato il ripristino e, sempre più spesso, quando è stato testato per ultimo.
Cosa intendono un'autorità di vigilanza o un cliente per "testato" non è stabilito in modo uniforme, ma la domanda centrale ricorre sempre: c'è stato un momento in cui un sistema o un set di dati è stato effettivamente ripristinato, al di fuori dell'ambiente di produzione, e il risultato è stato documentato? Un rapporto di test con una data e un risultato è qualcosa di diverso da una comunicazione interna che "i backup funzionano".
Gestione remota: il cui backup è in realtà
Nella gestione remota, il backup di un sistema cliente spesso non si trova fisicamente presso il cliente, ma presso il fornitore di servizi, o presso un servizio cloud che il fornitore ha configurato per conto del cliente. Questo sposta una domanda che sembra tecnica a prima vista verso una questione di responsabilità: chi testa, chi conserva il risultato del test, e chi può dimostrare che il ripristino funziona quando il cliente lo chiede? Un questionario di sicurezza di un cliente chiede sempre più specificamente di questo, e "lo fa il nostro partner di hosting" non è una risposta per un'autorità di vigilanza o un auditor — è un rinvio che richiede un controllo proprio.
È quindi consigliabile documentare per ogni sistema cliente chi ha accesso al backup, come è protetto tale accesso, e chi è responsabile dell'ultimo test di ripristino. le misure di diligenza per argomento spiegate mostra come il backup e il ripristino si relazionano alle altre misure di diligenza, come il controllo degli accessi e la registrazione degli incidenti.
Subappaltatori: chi testa cosa
Molti fornitori di servizi ICT lavorano con subappaltatori per parti specifiche: un provider di hosting, una parte che gestisce il firewall, un freelancer che implementa le patch. Se uno di loro gestisce anche il backup, il test di ripristino scompare facilmente tra due parti: il fornitore pensa che il subappaltatore testa, il subappaltatore pensa che non sia parte del suo incarico. Per il cliente non fa differenza — chiede la questione alla parte con cui ha un contratto.
È quindi opportuno specificare esplicitamente negli accordi con un subappaltatore chi esegue il test di ripristino, con quale frequenza e chi conserva la documentazione. La documentazione non deve essere una relazione dettagliata; una data, una descrizione di ciò che è stato ripristinato e il risultato di solito sono sufficienti per dimostrare al cliente che il ripristino non è un'ipotesi.
Ciò che documentate e ciò che non documentate
Un test di ripristino è un'operazione manuale: qualcuno ripristina un sistema, misura quanto tempo impiega e verifica se i dati sono corretti. Questo lavoro lo svolgete voi stessi o lo fate svolgere dal vostro partner di gestione; una piattaforma non può farlo per voi, così come non può sostituire un test di penetrazione o un audit. Ciò che aiuta invece è uno spazio dove il risultato di ogni test si trova insieme alle altre misure di due diligence, in modo che alla prossima lista di controllo non abbiate bisogno di cercare quando è stato fatto l'ultima volta.
Se non sapete ancora se la vostra organizzazione ricade personalmente sotto l'obbligo di due diligence o se ne siete toccati solo tramite un cliente con queste domande, la vedrete in cinque domande dove siete fornisce una prima indicazione. Se volete sapere come trattiamo i dati che registrate in un tale dossier, come trattiamo i vostri dati lo spiega. E se dubitaste che la vostra situazione rientri esattamente in questa categoria, controllate risposte a domande che ricorrono più spesso o consultate l'autorità di vigilanza per il vostro settore.
Il controllo NIS2 gratuito e la banca dati su secria.eu mostrano dove il backup e il ripristino si trovano esattamente nella vostra situazione, senza che per questo abbiate bisogno di un account.