Nell’ambito della gestione della continuità operativa, RTO (Recovery Time Objective) e RPO (Recovery Point Objective) non hanno una definizione univoca, in quanto varia in funzione dello standard o della metodologia di riferimento.
Inoltre, questi parametri, per quanto possano essere significativi e universalmente riconosciuti, hanno un limite intrinseco estremamente rilevante che è necessario considerare nella predisposizione delle soluzioni di recovery.
Indice degli argomenti
RTO e RPO: il problema delle definizioni
Come anticipato, le definizioni di RTO e RPO variano. Per esempio, la norma 23301:2012 utilizza le seguenti definizioni:
- RPO – Point to which information used by an activity must be restored to enable the activity to operate on resumption
- RTO – Period of time following an incident within which
- product or service must be resumed, or
- activity must be resumed, or
- resources must be recovered
Secondo le Business continuity management guidelines – Monetary Authority of Singapore invece:
RTO – Target duration of time to recover a specific business function. It comprises two components: (1) The duration of time from the point of disruption, to the point of declaring the activation of BCP, and (2) The duration of time from the activation of the BCP to the point when the specific business function is recovered. (Refer to business recovery) It is the acceptable duration of time that can elapse before the non-continuation of the specific business function would result in severe business impact and losses to the institution.
La Circolare 285 di Banca d’Italia non usa specificatamente il termine RTO, ma più genericamente fa riferimento ad un “tempo di ripristino di un processo” definendolo come il “periodo che intercorre fra il momento in cui l’operatore dichiara lo stato crisi e l’istante in cui il processo è ripristinato a un livello di servizio predefinito. Esso è costituito dai tempi di: analisi degli eventi e decisione delle azioni da intraprendere, prima di effettuare gli interventi”;
In sintesi l’RTO definisce il tempo massimo previsto per il ripristino di un servizio/sistema per renderlo nuovamente disponibile all’utente finale, mentre l’RPO indica a quando può risalire l’ultima copia valida dei dati e quindi quanti dati posso perdere. Infatti quando viene effettuata una BIA (Business Impact Analysis) viene definito qual’è il tempo massimo di RTO e di RPO accettabili per il ripristino di un processo/servizio. Tale tempo è legato all’impatto in termini economici, reputazionali, legali…, impatto che cresce in funzione del tempo di fermo del processo/servizio.
Business Impact Analysis (B.I.A.): obiettivi, metodologia operativa e analisi dei risultati
RTO e RPO: i tempi di ripristino dopo un incidente
I processi quindi vengono successivamente classificati in categorie omogenee in funzione dei parametri di RTO ed RPO; ad esempio si possono definire vitali i processi che devono essere ripristinati entro 4 ore, critici quelli da ripristinare entro 8 ore e così via. Tutti i processi aziendali hanno ovviamente un tempo di ripristino massimo, che in alcuni casi può essere anche molto lungo. Ad esempio il processo per il pagamento degli stipendi può non funzionare per giorni senza provocare un danno all’azienda, ma primo o poi deve tornare a funzionare.
Tuttavia l’approccio tradizionale nella definizione di questi parametri presenta delle insidie che è opportuno conoscere; viceversa si corre il rischio che in una reale situazione di emergenza i tempi di ripristino previsti non siano sufficienti e si crei una situazione insostenibile per l’azienda. Bisogna infatti considerare, come già riportato nel precedente articolo Resilienza, contro gli attacchi informatici: linee guida per le aziende che per molti processi l’ RTO desiderato non è fisso, ma è legato al momento della giornata o al giorno dell’anno in cui un evento distruttivo avviene.
Un esempio pratico
Infatti, salvo che si tratti di un processo/servizio attivo 24 ore, qualunque sia l’RTO definito, nel caso in cui l’intervallo di tempo fra il momento in cui avviene l’evento disastroso e la chiusura giornaliera del servizio sia inferiore all’RTO, risulterà impossibile il ripristino del processo interrotto entro la fine della giornata lavorativa. Se infatti l’incidente avviene 2 ore prima della chiusura dell’attività lavorativa e l’RTO è di 4 ore, il ripristino avverrà in ogni caso in tempo utile solo per le attività che verranno svolte il giorno successivo e quindi, da un lato si ha molto più tempo per ripristinare effettivamente il funzionamento del processo, ma dall’altro si deve essere consapevoli che in moltissime situazioni non sarà possibile ripristinare i processi/servizi in tempo utile.
Si consideri ad esempio uno scenario nel quale per sopperire l’indisponibilità di un sito il piano di continuità preveda lo spostamento di centinaia di persone in un altro sito distante 50 km e che tale operazione richieda 2 ore di tempo. Non avrebbe senso attuare questa azione se manca un’ora alla chiusura del servizio, ma nemmeno se ne mancassero 2. Si completerebbe il trasferimento giusto in tempo per sospendere l’attività lavorativa (salvo che si decida di procedere comunque al trasferimento per verificare che tutto funzioni correttamente nell’altro sito).
Sarebbe quindi utile definire non solo i tempi di ripristino, ma anche, per i vari scenari, l’orario limite entro cui ha senso attivare una soluzione “in emergenza” piuttosto che operare con maggiore tranquillità sapendo che in ogni caso il servizio dovrà essere reso operativo per il giorno successivo. Questo non significa che nel frattempo non si farà nulla, in quanto una serie di incaricati dovrà provvedere a predisporre il servizio perché, come nel caso dell’esempio, possa operare da un’altra sede. La stessa cosa vale per qualunque altro scenario/processo. È opportuno che tali considerazioni siano fatte in fase di definizione delle soluzioni previste nel piano e non durante la gestione dell’emergenza, perdendo in questo caso del tempo prezioso per individuare strategie risolutive che dovrebbero essere già disponibili.
RTO, l’importanza del giorno dell’anno
Anche il giorno dell’anno può essere importante; ad esempio un’applicazione per il pagamento dell’F24 può restare inattiva per giorni senza conseguenze, ma diventa sempre più critica all’avvicinarsi del 16 di ogni mese; in particolare il 16 di ogni mese diventa assolutamente critica in quanto l’operazione di pagamento non può essere rinviata. L’RTO di questo processo quindi può essere di diversi giorni nel corso della maggior parte del mese e ridursi a poche ore il 16 di ogni mese.
Non prendere in considerazioni la variabilità dell’RTO in funzione del momento in cui avviene l’evento può quindi vanificare la reale capacità di garantire un’efficace gestione della continuità operativa. È evidente che per tutte le situazioni è opportuno individuare delle soluzioni temporanee; nell’attesa di ripristinare la normale operatività. Queste vanno dall’esecuzione manuale delle operazioni (quando è possibile), a soluzioni di mutuo soccorso con altre aziende.
Ad esempio nel caso del pagamento dell’F24, per garantire un servizio ai propri clienti, è possibile coordinarsi con un’altra banca per garantire un soccorso reciproco. Il tutto deve però avvenire considerando le varie normative impattate, il che spesso non accade. Si pensi ad esempio alla sola normativa privacy; anche nel caso in cui una unità organizzativa subentri ad un’altra si pongono problemi di autorizzazione all’accesso ai dati che devono essere preventivamente formalizzati.
Soluzioni per l’RPO
Anche l’RPO di per sé non è esaustivo; viene infatti considerato il tempo massimo dall’ultima copia valida. Al riguardo valgono le seguenti considerazioni. Tale valore, come per l’RTO, non è uguale per i vari processi e questo fa sì che le copie dei dati relativi a processi diversi siano fra loro disallineate (ovviamente questo vale per le copie dei dati, non delle repliche che avvengono in tempo reale o con un tempo prossimo allo zero). Nel caso la propria soluzione di ripristino sia quindi basata unicamente sulle copie dei dati ad intervalli regolari, ma non analoghi per tutti i processi, si potrebbero avere non pochi problemi nel caso si debba procedere ad un ripristino complessivo dei sistemi.
Per evitare tale situazione, che potrebbe portare a disallineamenti molto difficili da gestire, sarebbe utile definire livelli di RPO differenziati in funzione del tipo di scenario considerato. Infatti, mentre alcuni scenari hanno impatti che riguardano solo alcuni processi contemporaneamente (ad esempio solo quelli presenti in un edificio temporaneamente non disponibile), nel caso di uno scenario che comporti l’attivazione del Disaster Recovery sono impattati contemporaneamente tutti i processi.
Per questo scenario tutti gli RPO dovrebbero essere identici al fine di evitare quei disallineamenti che sono così difficili da recuperare e che sono troppo spesso ignorati. Nel definire l’RPO sarebbe infatti necessario porsi realmente il problema: è effettivamente possibile recuperare in qualche modo i dati dall’ultima copia disponibile al momento del disastro? Altro aspetto che non viene solitamente analizzato con la dovuta attenzione è che non è necessario considerare solo i dati gestiti internamente all’organizzazione. Si pensi al fatto che un processo sia alimentato da un flusso continuo di dati provenienti anche da un soggetto esterno. Siamo effettivamente in grado di recuperare e ricostruire le informazioni che ci sono state inoltrate durante il periodo di interruzione del nostro processo e che sono andate perse?
È evidente che in questo caso la reale perdita per questi dati non è solo quella dall’ultima copia valida al momento del disastro, ma si estende da questa fino al reale ripristino del servizio; solo dal quel momento infatti i dati ricevuti non andranno più persi. Siamo quindi veramente in grado di recuperare i dati di un intervallo di tempo che può essere enormemente superiore all’RPO definito in sede di progettazione delle soluzioni di continuità?
Conclusioni
L’analisi sui processi e la relativa BIA dovrebbe essere molto più complessa di quanto avviene abitualmente, differenziando i tempi di ripristino in funzione del momento in cui avviene l’evento disastroso e i vari scenari da affrontare. In caso contrario, un approccio puramente “scolastico” anche se supportato da eventuali certificazioni, non tutela realmente un’organizzazione contro il rischio di blocchi prolungati e consistente perdita di dati. È inutile quindi investire e gestire costose soluzioni di continuità operativa se non si sono effettivamente considerate tutte le variabili presenti nella normale operatività.
