Interventi tecnologici per il raggiungimento dei valori obiettivo di RPO e RTO

Nella disaster recovery, si ha quindi la definizione delle strategie che vanno ad impattare sui valori del recovery point objective e del recovery time objective. A seconda dell’analisi del primo o del secondo parametro, si osserva che la variabile cruciale cambi. Conseguentemente si hanno diverse modalità di intervento a seconda che si voglia ridurre il primo parametro o il secondo. Inoltre, ciascun tipo di intervento va valutato anche in base ad una serie di determinanti che, a primo impatto possono sembrare poco influenti, ma che in realtà possono rendere più utile una modalità rispetto ad un’altra, o anche più dannosa una attività in confronto ad altre. È evidente che le soluzioni migliori siano quelle che permettano di azzerare tali parametri, ma è altrettanto vero che ciò comporta costi elevati, e non tutte le realtà hanno le disponibilità economiche necessarie per tali tipologie di investimento. Inoltre, a seconda della dimensione operativa, geografica, concentrazione della clientela, alcune opzioni che possono risultare migliori di altre risultano sconvenienti.

Se si vuole intervenire sulla riduzione del parametro RTO, le soluzioni disponibili sono:  Back-up su tape-off site (RTO che arriva a più di un giorno);

 Remote DB logging (RTO di alcune ore);

 Remote Disk Copy Asincrono (RTO di alcune ore);  Remote Disk Copy Sincrono (RTO di minuti);

 Remote Disk Copy con server in cluster geografico (RTO in secondi). Se invece si vuole intervenire sulla riduzione del parametro RPO, invece:

 Back-up (RPO di 24 ore);

 Remote DB logging (RPO di ore, ma alcuni casi arriva a durare solo qualche minuto);

 Remote Disk Copy Asincrono (minuti/secondi);  Remote Disk Copy Sincrono (che tende a 0).

Concentrandoci sulle tecnologie a favore della riduzione dell’RPO, si osserva che la variabile cruciale sono i dati: esso infatti viene considerato come l’asset più fragile a disposizione delle banche e tendenzialmente di più elevato rischio di perdita, comportando forti impedimenti

33

all’operatività quotidiana che trovano nei dati il driver informativo che permette di erogare i servizi. Quando il rischio tecnologico si materializza, ciò va a legarsi ai rischi finanziari, di compliance e reputazionali, con implicazioni veramente pericolose. Se le banche perdessero i dati della clientela in un incidente o in uno stato di crisi, gli effetti saranno sicuramente di tipo legale ma anche una forte perdita di clientela, data la perdita di fiducia. Gli investitori allora venderanno le azioni delle banche in caso di attacco cybernetico, producendo un crollo del valore delle azioni della banca stessa e delle società legate ad essa. Non va inoltre trascurato il fatto che i regulators andranno a penalizzare la banca a causa della mancata compliance in termini di tutela dei dati. La forte rischiosità di una situazione del genere ha fatto si che il Comitato di Basilea, già con Basilea 2 abbia indicato come uno delle sette categorie di event types di rischio operativo: “business disruption and systems failure.”

Nel tempo le banche hanno sviluppato notevolmente la gestione e protezione dei dati, soprattutto quelli sensibili. In passato il salvataggio dei dati si basava su un sistema di back-up su nastro. Nonostante il forte sviluppo di tale procedura, si è poi teso al salvataggio dei dati mediante approccio disk-to-disk. Si tratta però di soluzioni che, nonostante nel tempo abbiano visto una forte riduzione del loro costo, non permettono di ridurre sia i parametri di RTO che di RPO.

Ciò allora ha comportato la spinta ad un approccio definito di data replication remoto, il quale permette di replicare i dati in modo continuo e completo, riducendo tantissimo il valore di RPO in quanto si può anche tendenzialmente basare non tanto sulla continua replica di tutti i dati, ma solo delle variazioni.

In sostanza la tecnica di replicazione dati consente di ottenere un database secondario speculare all’originale, in cui i dati son memorizzati in modo permanente solo se i dati son stati inseriti in entrambe i siti. Ciò comporta che, in caso di disastro, le operazioni sul sito di disaster recovery si possano riavviare mantenendo parametri di RTO e RPO veramente ridotti. La data replication vede varie soluzioni a disposizione, le quali possono essere tutte selezionabili, ma per la cui scelta si vanno ad osservare fattori quali la distanza tra sistema centrale e sistema di disaster recovery. Tra queste si possono distinguere quelle che permettono un flusso continuo di dati in salvataggio (mirroring geografico), o che vadano a mettere a salvataggio solo i dati che vengono variati (remote db logging). Relativamente alla modalità di trasmissione dei dati, si può parlare di approccio di replica dei dati sincrono e approccio asincrono.

34

Nel caso di approccio di replica sincrono dei dati si ha un flusso informativo di input dai server alla cache Source, la quale si occupa di trasmettere i dati ricevuti alla cache Target, che si occupa invece di ricevere i dati e ritrasmetterli ai server che verranno utilizzati solo in caso di eventuali situazioni di crisi del sistema principale. Una volta ricevuti i dati dalla Source, trasmetterà alla stessa un messaggio di aknowledgement. In merito alla tecnica di replica sincrona si deve evidenziare il limite dato dalla distanza fisica: al suo aumentare si riduce la capacità di garantire efficienza di propagazione dei dati, provocando un rallentamento tendenzialmente nel caso si vada oltre i 50 km.

Figura 4: Il processo di replica sincrona dei dati.

Fonte: Poste Italiane s.p.a.

Nel caso di approccio di replica asincrono dei dati si ha un flusso informativo che si sviluppa in quattro fasi:

 Capture: in questa fase si ha la raccolta dei dati da parte del Sourche in Cache;

 Transmit: in questa fase, assumendo che si applichi un approccio remote DB logging, si vanno a selezionare le sole informazioni che variano o che risultino nuove rispetto al precedente processo di replica dei dati, in modo da trasmettere al sito secondario solo l’ultimo aggiornamento associalto ad uno specifico blocco di una traccia;

 Receive: i dati trasmessi vengono ricevuti dalla Target;

35

Figura 5: Il processo di replica asincrona dei dati.

Fonte: Poste Italiane s.p.a.

Va tenuto conto anche della scelta della tipologia di sito di Disaster recovery, il quale può presentarsi in varie soluzioni:

 Hot site: in questo caso il sito è completamente attrezzato con propri sistemi, linee TLC, con tutti i servizi necessari per poterlo immediatamente attivare; ciò permette ovviamente di mantenere un livello molto basso di RTO, ma si rendono necessari investimenti molto elevati;

 Warm site: si ha una situazione di attrezzature a disposizione parzialmente completa; ciò ovviamente riduce i costi di implementazione del sito di Disaster recovery, ma implica ovviamente un aumento del parametro RTO;

 Cold site: in questo caso il sito di Disaster recovery dispone solo delle infrastrutture di base, alcuni servizi ma ridotti, comportando una forte riduzione dei costi ma un incremento del parametro RTO, che diventa eccessivamente elevato.

Va inoltre tenuto conto che, per quanto riguarda il processo di disaster recovery, si ha una forte tendenza all’outsourcing ma anche a accordi con organizzazioni di altro tipo, tra i quali anche accordi interaziendali. Questo implica una serie di opzioni contrattuali:

 Timeshare se il sito è destinato a fornire servizi a diverse aziende mediante risorse che saranno approntate al bisogno;

 Accordi interaziendali quando aziende con tipologie di applicazioni e/o architetture simili si impegnano a fornire reciprocamente il sito di DR in caso di necessità;

 Rolling mobile sites, siti cioè realizzati utilizzando mezzi mobili quali TIR o altro specificatamente attrezzati per le necessità di Disaster recovery.

36

L’efficacia di tali soluzioni evidenziate viene a dipendere anche da fattori quali l’installazione di una rete TLC adeguata, ad alta velocità, al fine di rendere più rapida possibile la trasmissione dei dati e l’implemento di servizi a alto valore aggiunto. È necessaria quindi una infrastruttura ad alta affidabilità, cioè capace di garantire la ridondanza del percorso fisico e logico, che permetta l’interconnessione nelle varie modalità che vengono ad essere utilizzate in funzione dei data center.

La soluzione realizzata per la disaster recovery molto spesso tende a basarsi su una architettura di remotizzazione avanzata costituita sui tre siti, il sito principale definito sito di produzione, sul sito bunker e sul sito remoto. Il primo è quello che permette l’erogazione dei servizi e replica dei dati nelle condizioni di normale funzionamento del processo. Il sito bunker è il sito dislocato a distanza ridotta e destinato alla replica asincrona dei dati di produzione, solitamente per mezzo di reti a fibra ottica a bassissima latenza, che garantisce il perfetto allineamento dei dati col sito di produzione. La funzione del sito bunker è quella di proteggere il sito di produzione e ripartire dal remoto con i servizi applicativi senza perdita di dati, dopo aver eseguito il riallineamento del sito bunker. Il sito remoto è il sito di disaster recovery, preposto al ripristino dei servizi a fronte di eventi disastrosi, dislocato a distanza che in gergo tecnico viene definita geografica. Si collega sia al sito bunker che al sito di produzione e la sua funzione è quella di proteggere il sito di produzione da un disastro, con due possibili casi:

 Se il disastro fosse limitato al solo sito di produzione il sito remoto garantirebbe un RPO nullo;

 Se il disastro fosse geografico, coinvolgendo quindi anche il sito bunker, il sito remoto consentirebbe un RPO nell’ordine di minuti.

L’indisponibilità del sito primario comporta l’applicazione del failover sul sito remoto mediante l’esecuzione di una serie di operazioni che viene attivata a valle della decisione di attuare il disaster recovery plan.

37

Figura 6: Indisponibilità del sito di produzione

Fonte: Poste Italiane s.p.a.

L’indisponibilità del sito bunker non comporta impatti significativi, né sul sito primario, né sul sito remoto.

Figura 7: Indisponibilità del sito bunker

38

Il problema si avrebbe invece se ci fosse indisponibilità del sito di produzione e bunker contemporaneamente, situazione rientrante negli scenari di disastro che la soluzione tecnologica implementata deve essere in grado di gestire. Analogamente al caso di indisponibilità del sito secondario, l’RPO risulta di qualche minuto.

Figura 8: Indisponibilità del sito primario e del sito bunker

Figura 9: indisponibilità di sito primario e sito bunker. Fonte: Poste Italiane s.p.a.

Si vanno quindi a indicare quali siano i processi che scaturiscono dall’utilizzo delle soluzioni tecnologiche indicate e per ciascuno di essi si indicheranno le modalità di allineamento dei dati, di allineamento dei server, di risposta a disastri locali ed estesi:

 Disaster recovery con remote back-up dei dati: in questo caso, per l’allineamento dei dati il software di gestione del back-up crea i duplicati dei nastri oggetto di remote vaulting; i nastri vengono poi spediti nel sito remote con la frequenza necessaria a soddisfare i requisiti richiesti di RPO; l’allineamento dei server può avvenire in una delle modalità hot, warm o cold, a seconda delle scelte in termini di cost-benefit analysis. In questo caso la risposta ai disastri localizzati e estesi è identica e prevede la ripartenza dei sistemi nel sito di Disaster recovery. È una modalità poco onerosa ma molto lenta a causa del processo di back-up, che non permette di ridurre più di tanto il parametro RPO, mentre altre soluzioni tecnologiche permettono la riduzione se non anche la tendenza all’azzeramento dello stesso.

39

Figura 10: Disaster Recovery con remote back-up dei dati

Fonte: Poste Italiane s.p.a.

 Disaster recovery con replica a cascata dei dati: in questo caso l’allineamento dei dati si suddivide in due fasi:

o La prima fase prevede l’allineamento dei dati sincrono tra sito primario e secondario locale;

o La seconda fase prevede l’allineamento dei dati periodico tra il sito secondario locale e il sito di disaster recovery.

Come nel caso del remote back-up non si ha un vincolo per quanto riguarda le modalità di allineamento dei server, lasciando libertà di scelta tra le modalità hot, warm, cold. Per quanto riguarda le risposte ai disastri, in caso di disastro locale si ha un allineamento dei dati tra il sito secondario locale e quello di disaster recovery, con cui vengono poi fatti ripartire i sistemi senza perdita di dati. Nel caso di disastro esteso, occorrerà saltare la fase di allineamento tra sito di disaster recovery e sito secondario locale, comportando quindi una perdita di dati;

40

Figura 11: Disaster Recovery con replica a cascata dei dati

Fonte: Poste Italiane s.p.a.

 Disaster recovery con replica asincrona dei dati: in questo caso manca il sito secondario locale, quindi si ha un allineamento dei dati direttamente tra sito primario e di DR, ma in modalità asincrona. Non ci sono vincoli in termini di modalità di allineamento dei server. La peculiarità di tale modalità è la mancanza di un sito secondario locale: nel caso di disastro esteso è chiaramente ovvia la perdita di dati, perché anche l’esistenza del sito secondario non influirebbe, ma la sua assenza comporta una forte debolezza in merito al disastro locale, in quanto non si ha allineamento dei dati e la ripresa dei sistemi nel sito di DR avviene anche in questo caso con perdita di dati;

Figura 12: Disaster Recovery con replica asincrona dei dati

41

 Disaster recovery con replica Star dei dati: in questo caso l’allineamento dei dati si suddivide nella fase di allineamento asincrono tra sito primario e di Disaster recovery e nella fase di allineamento sincrono tra sito primario e secondario locale con annesso invio di metadati per tracciare lo stato di avanzamento dell’allineamento asincrono tra sito primario e di Disaster recovery. In caso di disastro localizzato si ha un processo di allineamento dei dati mancanti necessari a sincronizzare il sito secondario locale con quello di Disaster recovery e successiva ripartenza dei sistemi sul sito di Disaster recovery senza perdita di dati, mentre in caso di disastro esteso si ha una ripartenza diretta dal sito di Disaster recovery con perdita minimale dei dati. 27

Figura 13: Disaster Recovery con replica star dei dati

Fonte: Poste Italiane s.p.a.

27 _{Poste Italiane s.p.a., Disaster recovery e Business continuity, Seminario sulla architettura e sulle tecnologie adottate}

Conclusioni

Il sistema bancario sta affrontando, soprattutto a partire dagli anni ’70, un forte e continuo processo di rinnovamento tecnologico, che soprattutto negli ultimi dieci anni ha visto una spinta ancora maggiore, anche a causa degli eventi determinati dalla crisi del 2008, la quale ha comportato la necessità di rivisitazione di una serie di aspetti organizzativi e strategici, in ottica di riduzione dei costi, per sopperire alla debolezza della redditività, e dei rischi di incorrere in perdite non solo relative alle attività tipiche delle banche, ma anche relative alle operatività di vario tipo che le banche quotidianamente devono svolgere.

Ora innovazione tecnologica e banca moderna sono ormai dei sinonimi per gli operatori del settore, in quanto l’investimento in information technology è diventato una leva fondamentale nelle metodologie, strategie ed opportunità che consentono innumerevoli vantaggi ma anche delle situazioni di rischio che comporterebbero perdite anche ingenti.

La necessità di adattare l’operatività odierna e l’apparato organizzativo sempre più basato sull’evoluzione tecnologica ha fatto sì che per le banche si creassero nuove prospettive di sviluppo dell’offerta, non solo mediante modifica di prodotti già esistenti con affiancamento di servizi telematici che vanno dagli ATM ai servizi di Home Banking, e-payments e quant’altro, ma anche un netto miglioramento della gestione dei dati, di maggiore velocità ed efficienza nella comunicazione degli stessi sia tra gli organi direttivi e amministrativi, sia verso l’esterno. Tutto questo rende necessaria una attenta valutazione dei rischi operativi poiché, data una tendenza ad un continuo incremento dell’investimento in tecnologie, le banche si trovano di fronte a nuove tipologie di rischi riassumibili nel concetto di rischio informatico, definito come il rischio di incorrere in perdite economiche, di reputazione e quote di mercato in relazione all’utilizzo di tecnologia dell’informazione e della comunicazione; è un rischio che si sviluppa in seguito allo sviluppo tecnologico delle aree operative delle banche e proprio da questa considerazione deriva la sua correlazione col rischio operativo. L’individuazione del rischio operativo si basa sulla definizione di event types, uno tra i quali riguarda appunto l’interruzione di operatività e disfunzione di sistemi. Tenendo conto che

ormai la tecnologia informativa vada ad influire su ogni aspetto di una banca, ci si rende conto che limitare il concetto di rischio informatico al solo event type definito per il rischio operativo risulta eccessivamente riduttivo. Basti osservare l’incremento di crimini e frodi informatiche, che partono dagli attacchi di cyber criminali organizzati e arrivano ad interventi da parte di soggetti interni alla banca stessa, ma non solo; si può osservare anche il continuo aumento di tentativi di frodi informatiche, di continui attacchi ai dati sensibili sui sistemi di pagamento. A fronte di tutte queste situazioni e tante altre ancora che possono rendere vulnerabile la banca e la sua operatività, a livello internazionale le varie istituzioni interessate si sono rese conto di vivere in un sistema con una normativa eccessivamente frammentata, anche a livello comunitario. Proprio a livello comunitario va osservata l’importanza del lavoro svolto dall’EBA con la collaborazione delle istituzioni finanziarie, services providers e autorità competenti, che hanno portato come risultato più recente la definizione dei Requirements on the Security of Internet Payments, che sono entrati in vigore dal 1 agosto 2015. La finalità dietro la redazione di questo documento è la volontà di definire regole e standards comuni in ottica di armonizzazione seppur tenendo conto delle peculiarità dei vari sistemi. Mediante i Requirements si vanno ad osservare argomenti quali la strong customer authentication, che migliora la verifica dell’identità dell’utente finale nelle procedure di pagamenti online. Il documento non si limita però ad aspetti generali, in quanto lo si può scomporre in tre parti: general control and security environment; specific controls and security measures of internet payments; customer awareness.

Spostandoci a livello nazionale, la normativa di riferimento è data dalla Circolare di Banca d’Italia 285/2013, Capitolo 4 della Parte Prima, Titolo IV. In essa si vanno a definire i casi di incidente di sicurezza informatica distinguendoli dai gravi incidenti, la risorsa umana mediante la definizione dell’utente responsabile, che risulta cruciale in ogni fase della gestione del rischio informatico. La normativa non si ferma solo a questo: va infatti ad indicare quali siano le fasi principali della gestione della sicurezza informatica, a partire dall’analisi del rischio. Questa fase è considerata uno strumento atto a garantire l’efficacia e l’efficienza delle misure di protezione delle risorse ICT che permettono di graduare le misure di mitigazione dei vari ambienti in funzione del profilo di rischio dell’intermediario. L’analisi del rischio è un processo che si scompone in una serie di fasi: valutazione del rischio potenziale; trattamento del rischio; accettazione; valutazione dei risultati ottenuti.

La fase di valutazione dei risultati ottenuti risulta anche il punto di partenza delle successive analisi del rischio, dimostrando quindi la necessità che si tratti di un processo circolare volto

al continuo miglioramento dell’analisi in ottica di continuo miglioramento della capacità di definizione dei presidi. Oltre alla definizione delle fasi dell’analisi del rischio, si vanno a definire ruoli e compiti per la gestione della sicurezza informatica, in modo da accentuarne l’attenzione rispetto a ciò che si avrebbe avuto integrando il capitolo 3 della Circolare come invece fu proposto dagli operatori del settore.

In merito alla gestione dei dati, si indica che la banca debba essere in grado di generare con accuratezza e affidabilità i dati sui rischi incontrati sia in condizioni normali che in condizioni di stress. Si vanno quindi a definire i requisiti dei dati riguardanti i fatti aziendali (completezza,