Un backup conta solo se avete anche testato che potete ripristinare da esso — non solo se il file è presente, ma se il codice sorgente, la pipeline di sviluppo e i segreti associati tornano a funzionare dopo un incidente. Nello sviluppo software non si tratta solo di un repository che potete ripristinare, ma di un'intera catena: controllo versione, server di build, pipeline, ambienti di test e le chiavi e i token che ne fanno parte. Senza una procedura di ripristino testata, scoprirete durante un incidente se funziona, e questo è il momento peggiore per scoprirlo.
L'obbligo di diligenza della NIS2 nomina esplicitamente la continuità e il ripristino come parte delle dieci misure dell'articolo 21. La direttiva non prescrive una frequenza di test fissa né una forma concreta — è definita per organizzazione, e l'implementazione specifica del paese può aggiungere propri accenti. Ciò che tuttavia ricorre sempre, nei questionari di sicurezza dei clienti e in ciò che le autorità di controllo considerano ragionevole, è la distinzione tra avere un backup e avere un backup che avete ripristinato e di cui sapete che il risultato funziona.
Cosa significa esattamente 'testato'
Un test non è la stessa cosa di un segno di spunta verde nel software di backup. Testato significa che qualcuno ha effettivamente ripristinato il backup in un ambiente separato, ha verificato che il codice si compila, che la build ha successo e che l'applicazione funziona come previsto. Solo allora saprete se il momento del ripristino è utilizzabile e quanto tempo richiede. Un backup che viene creato ma non viene mai ripristinato è, in pratica, un'ipotesi sul ripristino, non un ripristino provato.
Cosa ripristinate specificamente nella pipeline di sviluppo
Nello sviluppo software, il codice sorgente è raramente l'unica cosa che potete perdere. Pensate alla configurazione della pipeline CI/CD, agli script di build, alle dipendenze dai pacchetti esterni, alle chiavi di accesso per i registry e gli ambienti cloud, e alla cronologia nel sistema di controllo versione stesso. Un piano di ripristino che copre solo il codice ma non la pipeline o i segreti, lascerà un'organizzazione ancora ferma dopo un incidente. È quindi utile determinare per ciascuno di questi componenti: dove si trova il backup, chi può ripristinarlo, e se questo è mai stato esercitato.
Quanto spesso è ragionevole testare
Non c'è un termine fisso nella direttiva per la frequenza con cui dovete eseguire un test di ripristino. Ciò che nella pratica si considera ragionevole dipende da quanto spesso l'ambiente cambia: una pipeline di sviluppo che cambia configurazione settimanalmente richiede test più frequenti di un ambiente stabile che rimane invariato per mesi. Molte organizzazioni scelgono un momento fisso del calendario — ad esempio ogni trimestre — combinato con un test dopo ogni grande modifica dell'infrastruttura. Più importante della frequenza è che ci sia stato almeno un momento, e che possiate indicare quando.
Cosa registrate come prova
Un cliente che invia un questionario di sicurezza raramente chiede della tecnica dietro il vostro backup. La domanda è solitamente più semplice: quando è stato testato per l'ultima volta, da chi, e qual è stato il risultato. Per quella risposta è sufficiente registrare tre cose: la data dell'ultimo test di ripristino, chi ha condotto il test, e quale componente è stato ripristinato — codice, pipeline, segreti, o tutti e tre. Senza questa registrazione, la risposta al questionario rimane un ricordo invece di una prova, e questa è esattamente la differenza che un valutatore dall'altra parte del tavolo vuole vedere.
Il collegamento con il resto del dossier
Backup e ripristino raramente funzionano da soli. Chi può eseguire la procedura di ripristino dipende dal controllo degli accessi alla pipeline di sviluppo; quello che è andato storto durante un guasto deve essere registrato nella stessa documentazione di incidente utilizzata anche per altre misure. Costituire tale dossier non deve essere un progetto separato: le dieci misure suddivise per situazione mostra esattamente dove backup e ripristino si inseriscono nell'insieme, e quali altre misure vi sono direttamente correlate.
Se backup e ripristino per la vostra organizzazione si qualifichino come misura di due diligence dipende dal fatto che ricadiate voi stessi sotto NIS2 o che riceviate questa richiesta da un contraente che vi ricade. in poche domande vedere dove siete posizionati fornisce un primo indicatore al riguardo, con spiegazione del perché. Come arriviamo a questo indicatore e quali fonti ne sono alla base è illustrato su la pagina sulla nostra metodologia.
Un backup che non è mai stato ripristinato non è una garanzia — è una domanda che rimane in sospeso. Desiderate sapere se e come questa misura è rilevante per la vostra organizzazione, e cosa comporta ulteriormente? Effettuate la scansione rapida gratuita o sfogliate le domande più frequenti su NIS2 per le domande che altri imprenditori hanno già posto.