Conformità all’articolo 12 del regolamento DORA: una guida al backup e al ripristino per gli enti finanziari

Articolo 12, paragrafo 1, lettera a): Ambito di applicazione del backup e frequenza minima di esecuzione

Ai sensi dell’articolo 12, paragrafo 1, lettera a), gli enti finanziari devono redigere e mantenere una politica di backup che specifichi quali dati vengono sottoposti a backup e con quale frequenza minima deve essere eseguito il backup per ciascuna categoria di dati. L’ambito di applicazione e la frequenza devono essere determinati in base al livello di criticità o riservatezza dei dati.

Poiché i dati presentano livelli di rischio diversi, la norma garantisce che i dati più importanti ricevano la protezione più frequente. Per conformarsi a questa clausola, classificate i vostri dati in base alla loro criticità; ad esempio, contrassegnate i registri dei conti dei clienti come critici, i file delle risorse umane come importanti e i vecchi documenti di progetto come a bassa priorità. Quindi stabilite una frequenza minima per ciascuna classe e riportate le vostre motivazioni nella politica. Un registro dei pagamenti potrebbe richiedere backup ogni ora, mentre un archivio di file di marketing può essere eseguito settimanalmente.

Articolo 12, paragrafo 1, lettera b): Procedure documentate di ripristino e recupero

Oltre alla politica di backup di cui alla lettera a), l’articolo 12, paragrafo 1, lettera b) riguarda l’aspetto del recupero nella protezione dei dati. Esso impone agli enti finanziari di disporre di procedure scritte di ripristino e recupero che indichino al personale quale backup utilizzare, dove effettuare il ripristino e l’ordine in cui i sistemi devono tornare operativi. Poiché il personale non può permettersi di improvvisare durante una crisi, un piano scritto lo aiuta a ripristinare rapidamente i servizi e riduce i tempi di recupero. Assicuratevi che tali documenti siano accessibili anche quando i sistemi principali sono fuori servizio.

Articolo 12, paragrafo 2: Attivazione sicura dei sistemi di backup

Un ripristino effettuato con negligenza può reintrodurre malware nell’ambiente di produzione o lasciare i dati dei clienti su un server non protetto. L’articolo 12, paragrafo 2 previene questo rischio stabilendo due condizioni per i sistemi di backup. In primo luogo, è necessario essere in grado di attivarli secondo quanto descritto nella politica di backup. In secondo luogo, la loro attivazione non deve compromettere la sicurezza della rete né esporre i dati al rischio di perdita, alterazione, falsificazione o divulgazione. Per conformarsi a questo articolo, è necessario crittografare i backup, limitare chi può eseguire i ripristini e dove possono essere salvati i dati ripristinati, nonché eseguire una scansione dei dati ripristinati alla ricerca di malware prima che tornino in produzione.

Articolo 12, paragrafo 2: Test periodici di backup e ripristino

L’articolo 12, paragrafo 2, richiede inoltre di effettuare test periodici delle procedure di backup, ripristino e recupero. I backup non testati spesso falliscono nel momento peggiore possibile, e l’unica prova che il ripristino funzioni consiste nel ripristinare i dati su un sistema di test separato e confermare che l’applicazione si avvii, che i dati siano completi e che il ripristino si concluda entro il tempo di recupero previsto. Utilizzate un software di backup e ripristino cyber-resiliente per ripristinare dati reali in un ambiente di test secondo una pianificazione regolare e verificate che i sistemi funzionino. Non dimenticate di tenere un registro dei risultati e di eventuali problemi risolti, poiché gli standard tecnici DORA richiedono che i risultati dei test siano documentati.

Articolo 12, paragrafo 3: Sistemi di ripristino separati fisicamente e logicamente

Quando gli enti finanziari ripristinano i backup sui propri sistemi, l’articolo 12, paragrafo 3, li obbliga a utilizzare sistemi separati fisicamente e logicamente dall’ambiente di produzione e protetti da accessi non autorizzati. Questa norma impedisce a un malintenzionato, anche a chi sia già riuscito a penetrare nell’ambiente di produzione, di raggiungere l’ambiente di ripristino. L’EIOPA la interpreta come sistemi sotto il pieno controllo dell’ente che non siano direttamente collegati al sistema principale. Per conformarsi, è necessario realizzare l’ambiente di ripristino su un’infrastruttura separata, dotata di separazione di rete e controlli di accesso propri. Il software di backup deve quindi eseguire il ripristino da copie isolate, e Bacula Enterprise è in grado di ripristinare sistemi critici da nastri offline o da dispositivi di archiviazione scollegati su un’infrastruttura sotto il controllo dell’ente.

Articoli 12, paragrafi 6 e 7: Obiettivi di ripristino e controlli di integrità

L’articolo 12, paragrafo 6 impone l’adozione di obiettivi di tempo di ripristino (RTO) e di punto di ripristino (RPO) per ciascuna funzione, mentre l’articolo 12, paragrafo 7 prevede controlli di integrità e riconciliazioni a seguito del ripristino da un incidente. Queste norme stabiliscono la rapidità con cui è necessario effettuare il ripristino, la quantità di dati che ci si può permettere di perdere e le modalità con cui verificare la correttezza dei dati ripristinati. Per conformarsi agli articoli 12, paragrafi 6 e 7, è necessario definire un RTO e un RPO per ogni funzione critica o importante e pianificare i backup con una frequenza almeno pari a quella consentita da ciascun RPO.

Un RPO di un’ora richiede backup almeno ogni ora, mentre un RPO di 24 ore può basarsi su un backup notturno. Prima di rimettere in funzione il sistema, effettuare la riconciliazione dei dati ripristinati con gli altri sistemi. Il resto dell’articolo 12 prevede capacità ICT ridondanti per tutte le imprese, tranne quelle di dimensioni minime, e norme aggiuntive per i depositari centrali di titoli, le controparti centrali e i fornitori di servizi di segnalazione dei dati.

Articolo 12(1)(a): Processi, insiemi di file e pianificazioni per la politica di backup

L’articolo 12(1)(a) richiede di redigere una politica di backup che elenchi quali dati sottoporre a backup e con quale frequenza, in base alla loro criticità. Bacula consente di inserire queste due decisioni direttamente nel software.

È possibile elencare i server, i database e le cartelle di cui eseguire il backup in un’impostazione denominata Fileset, mentre la frequenza dei backup va impostata in un’impostazione denominata Pianificazione; ad esempio, ogni ora per i registri di pagamento e una volta al giorno per le e-mail. Bacula esegue quindi automaticamente ogni backup secondo tale pianificazione e registra ogni esecuzione in un rapporto di processo, che fornisce una prova scritta del fatto che i backup effettivi seguono la politica definita.

Articolo 12(1)(b): Procedure di ripristino con Catalog, Bootstrap e ripristino bare-metal

L’articolo 12(1)(b) richiede procedure scritte dettagliate per il ripristino dei sistemi e dei dati dopo un’interruzione. Bacula mette a disposizione tre strumenti per eseguire tali procedure: il Catalog, i file bootstrap e il ripristino bare-metal.

• Innanzitutto, il Catalogo è un database che registra cosa è stato sottoposto a backup e dove è archiviata ciascuna copia; Bacula raccomanda di eseguire il backup del Catalogo quotidianamente.
• Il secondo strumento è costituito dai file di avvio (bootstrap), che indicano a Bacula esattamente dove si trova ogni backup e consentono di ricostruire il Catalogo nel caso in cui il server di backup stesso vada perso.
• Infine, è disponibile il ripristino completo (bare-metal recovery) per Linux e Windows, che ricostruisce da zero un server guasto, compresi il sistema operativo, le impostazioni e i dati.

Articolo 12(2): Crittografia e controllo degli accessi per ripristini sicuri

L’articolo 12(2) richiede che l’attivazione dei backup non metta a rischio i sistemi né esponga, modifichi o danneggi i dati. Per aiutarti a rispettare questa clausola, Bacula crittografa i dati di backup sia in transito che inattivi, rendendoli illeggibili a chiunque non disponga delle tue chiavi di crittografia.

Inoltre, controlla chi può eseguire un ripristino e dove possono essere indirizzati i dati ripristinati, utilizzando gli account esistenti di Active Directory o LDAP, l’autenticazione a due fattori e le autorizzazioni basate sui ruoli. Durante il backup e il ripristino, Bacula può verificare i file confrontandoli con le firme di malware note, contribuendo a impedire che un file infetto torni nell’ambiente di produzione. Detto questo, il backup e la protezione delle chiavi di crittografia rimangono un vostro compito ai sensi dell’articolo 7 del regolamento delegato.

Articolo 12(2): Archiviazione immutabile per le copie di backup

L’articolo 12(2) richiede inoltre che i dati di backup rimangano disponibili e inalterati quando è necessario ripristinarli. Bacula è in grado di scrivere i backup su un’archiviazione immutabile, dove i backup salvati non possono essere modificati o eliminati (fino alla scadenza del periodo di protezione impostato).

Bacula supporta l’archiviazione immutabile su volumi disco Linux, su sistemi NAS quali NetApp SnapLock e Data Domain Retention Lock, su nastri WORM e nel cloud tramite Amazon S3 Object Lock e l’archiviazione immutabile di Azure Blob. L’archiviazione immutabile può comunque connettersi alla rete e non sostituisce i sistemi di ripristino separati richiesti dall’articolo 12, paragrafo 3.

Articoli 12(2) e 11(6): Test di indipendenza del ripristino per i test di ripristino

Gli articoli 12(2) e 11(6) richiedono entrambi test di ripristino reali, e la documentazione di Bacula considera tali test come parte integrante del piano di ripristino. Con il ripristino indipendente, il test di indipendenza del ripristino verifica che i sistemi critici concordati possano essere ripristinati utilizzando esclusivamente la propria infrastruttura, il proprio personale, le proprie credenziali e i backup isolati, senza alcun aiuto da parte di Bacula. Siete voi a definire l’ambito e i criteri di successo. I risultati, i tempi e le correzioni diventano quindi i dati che l’articolo 25 del regolamento delegato richiede di comunicare.

Articolo 12, paragrafo 3: Ripristino indipendente di Bacula per il ripristino segregato

Quando si esegue il ripristino sui propri sistemi, l’articolo 12, paragrafo 3 richiede che tali sistemi siano fisicamente e logicamente separati dall’ambiente di produzione e protetti da accessi non autorizzati. Bacula Independent Recovery ripristina i sistemi critici da copie offline su nastro, supporti rimovibili o dispositivi di archiviazione scollegati. Può funzionare interamente sulla propria infrastruttura senza alcuna connessione a Bacula o a qualsiasi servizio di fornitori terzi, il che è in linea con l’interpretazione della norma da parte dell’EIOPA. Inoltre, si riceve un Recovery Independence Kit sigillato che contiene il software, le impostazioni, le chiavi di crittografia e le istruzioni necessarie per ricostruire il sistema da zero.

Articolo 12(7): Job di verifica per i controlli di integrità

L’articolo 12(7) richiede di verificare che i dati siano completi e corretti dopo il ripristino a seguito di un incidente, compresa la riconciliazione con gli altri sistemi. Un job di verifica di Bacula legge i dati di backup dall’archivio e conferma che siano integri e corrispondano ai registri di Bacula relativi a ciò che è stato salvato.

Può inoltre confrontare i file presenti su un server con un backup precedente e segnalare quelli che sono stati modificati in modo imprevisto; è importante sottolineare che questi report sono utili durante gli audit. Inoltre, si prega di notare che un processo di verifica non conferma il corretto funzionamento di un’applicazione né la corrispondenza dei saldi, e che i vostri team devono comunque eseguire tali controlli autonomamente.