Per fornire le migliori esperienze, utilizziamo tecnologie come i cookie per archiviare e/o accedere alle informazioni del dispositivo. Il consenso a queste tecnologie ci consentirà di elaborare dati come il comportamento di navigazione o ID univoci su questo sito. Il mancato consenso o la revoca del consenso può influire negativamente su determinate caratteristiche e funzioni.
La conservazione tecnica o l'accesso è strettamente necessario al fine legittimo di consentire la fruizione di un determinato servizio esplicitamente richiesto dall'abbonato o dall'utente, oppure al solo fine di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente a fini statistici. L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici anonimi. Senza un mandato di comparizione, una conformità volontaria da parte del vostro Fornitore di Servizi Internet, o ulteriori registrazioni da parte di terzi, le informazioni memorizzate o recuperate per questo scopo da sole non possono di solito essere utilizzate per l'identificazione.
L'archiviazione tecnica o l'accesso sono necessari per creare profili utente per inviare pubblicità o per tracciare l'utente su un sito Web o su più siti Web per scopi di marketing simili.
Business Continuity
Continuità operativa e ripristino attività
Indice contenuti:
BUSINESS CONTINUITY
Ogni organizzazione ha caratteristiche uniche, fatte di strumenti, processi, documenti, risorse umane, il tutto contribuisce a consentire all’azienda di erogare prodotti o servizi e produrre fatturato.
La continuità operativa o business continuity è la capacità organizzativa nel mantenere attivi i processi operativi chiave anche in caso di incidenti, guasti o minacce che possono compromettere l’operatività e interrompere la produzione o erogazione dei prodotti o servizi.
È evidente come l’interruzione del processo produttivo si tramuti immediatamente in un danno verso ogni soggetto direttamente o indirettamente coinvolto, come clienti, fornitori e dipendenti.
L’insieme delle procedure per garantire un certo grado di produttività anche in condizione di emergenza, consente all’azienda di mantenere i servizi attivi e di conseguenza, non permettere ad eventi e minacce di impattare negativamente sul fatturato.
In conclusione, per garantire la Business continuity è necessario un complesso processo di analisi e implementazione di procedure che includono molteplici aree, tra cui quella informatica, che come sai, ormai è parte essenziale di quasi tutti i processi produttivi.
Nei prossimi paragrafi ti spiego l’approccio che devi avere per capire dove agire, ma tieni ben presente, che la tua operatività può dipendere da molti altri fattori, come determinati macchinari, piuttosto che specifiche persone chiave
Solo tu puoi sapere quali sono questi fattori e una volta identificati, devi attivarti con tutti i vari player per definire le procedure di ripristino necessarie.
ASSET
Per realizzazione un progetto efficace ed efficiente di business continuity informatica, come prima cosa devi identificare quali sono i tuoi strumenti e processi tecnologici strategici.
In pratica stai definendo gli ASSET sui quali poi farai tutti vari ragionamenti.
Nel fare questa scelta, devi chiederti quanto quell’asset sia strategico per la tua attività, attribuendogli un certo grado di importanza.
Esempio – Tabella asset
ANALISI DEI RISCHI
Ora che sai su cosa concentrarti, devi chiederti quanti e quali sono i rischi a cui questi asset sono esposti.
Questo processo prende il nome di risk assessment.
Come devi fare …
Inizia ad ipotizzare eventuali minacce a quell’asset, come un guasto, un furto, un incendio.
Per ogni asset puoi fare un elenco di eventi o minacce associati alla probabilità che si verifichino realmente.
Si arriva quindi avere una visione d’insieme dei rischi associati agli asset e dovresti iniziare a capire quali sono gli eventi accettabili e quelli inaccettabili perché comprometterebbero troppo la tua operatività.
Esempio:
Il PC della sala riunioni si guasta e tu sai che quel PC serve solo a far girare le slide durante i briefing aziendali.
Quel PC non è di vitale importanza per l’operatività aziendale e non impatta direttamente sul fatturato, di conseguenza si può considerare accettabile il rischio di guasto.
Se invece si guasta il PC dell’ufficio tecnico, le commesse dei clienti non possono essere elaborate.
In questo caso l’evento impatta decisamente sul fatturato e di conseguenza il rischio di guasto su quel PC non è accettabile e deve essere quanto prima mitigato.
DISASTER RECOVERY
Lo so, adesso che hai capito che esistono dei rischi che possono mettere in guai seri la tua azienda ti è scattato qualcosa dentro…ed è normale che sia così.
La parte che vediamo ora serve a mandare via l’ansia!
Scherzi a parte…
E’ arrivato il momento di trovare le misure necessarie per mitigare il rischio nel caso cui questo si verifichi realmente.
Per farlo occorrono due cose:
Abbiamo visto che ci sono vari gradi di probabilità che un determinato rischio si concretizzi, ma ahimè, nessuno di questi rischi ha probabilità 0.
Le procedure di disaster recovery, come dice la parola stessa, consentono di farsi trovare pronti in determinate circostanze di emergenza causata dal verificarsi di uno o più eventi che hanno compromesso l’operatività aziendale.
Tramite una serie di azioni, supportate da un solido piani di backup, potrai tornare operativo nei tempi necessari.
Questa fase è essenziale nel contesto della business continuity, in quanto non ti serve a nulla conoscere i rischi e sperare che questi non accadono;
piuttosto è molto più saggio adottare procedure concrete e ben definite per tornare operativi anche nei casi peggiori.
A questo proposito vanno tenute in considerazione 2 importanti parametri nel definire la strategia di business continuity.
RTO – recovery time objective
Indica il tempo massimo che sei disposto a rimanere senza quel determinato asset.
E’ un valore strettamente legato alle procedure di ripristino che il piano di recovery deve mettere in atto.
Nell’esempio precedente è stato assegnato all’asset PC sala riunione un’importanza bassa; in funzione di questo il rischio di eventi critici è stato considerato accettabile; ne puoi dedurre che se il PC sala riunioni non è disponibile per una settimana non succede nulla grave, per cui l’RTO in questo caso è di 7 giorni.
RPO – recovery point objective
Indica la perdita di dati ammissibile
Questo valore, oltre ad essere connesso alle procedure di ripristino va tenuto assolutamente in considerazione durante la progettazione delle procedure di backup.
L’RPO definisce in caso di ripristino di un determinato asset, quanto posso permettermi di perdere in termini di dati.
Se ad esempio occorre ripristinare il gestionale dal backup, i dati saranno aggiornati al primo backup utile.
Definire questo valore, ovviamente condiziona l’intera strategia di backup.
Le procedure di backup e ripristino dovranno essere implementate nel rispetto dei valori di RTO e RPO definiti.
BACKUP vs DISASTER RECOVERY
E’ importante approfondire la differenza tra una strategia di backup e una di disaster recovery.
Seppure fortemente interconnesse, il concetto che ne sta alla base è decisamente diverso.
Il backup viene chiamato in causa quando si ha una perdita di dati ed è necessario un ripristino dell’informazione persa ad una data specifica.
Le procedure di disaster recovery vengono attivate quando un asset non è più operativo e vi è necessità di rimetterlo “in sesto” al più presto.
Con queste due premesse si possono fare alcune osservazioni interessanti:
Disporre di un backup efficace dei dati non significa poter tornare operativi nei tempi richiesti, infatti questo fa parte del piano di disaster recovery, senza contare che i backup potrebbero anche essere temporaneamente non disponibili a causa dell’incidente informatico avvenuto.
Spesso il piano di ripristino ha necessità di utilizzare uno o più backup per rimettere in piedi l’asset.
Le procedure di ripristino possono essere complesse, soprattutto quando a determinare il successo dell’operazione entrano in gioco più fattori.
L’unico modo per essere sicuri che il piano di disaster recovery funzioni è testarlo.
Testare gli scenari peggiori consente di documentare le procedure, stimare i tempi reali e intercettare eventuali ostacoli, il tutto in situazione controllate non di emergenza reale.
Per quanto siano onerosi in termini di tempo, toccare con mano l’asset ripristinato ci garantisce che la procedura funziona e finalmente, potrai stare tranquillo che anche nel caso peggiore sai già cosa ti aspetta e quanto tempo devi stare fermo.
RIDONDANZA DEI SISTEMI
La ridondanza nei sistemi informatici consente ai dispositivi di poter continuare ad erogare servizi anche in caso di guasti o eventi che ne compromettono il funzionamento.
Il concetto è semplice, se un asset smette di funzionare, deve essere già pronto un altro asset in grado di sostituirlo.
Spesso l’operazione può essere del tutto automatica, rendendo il cambio operativo trasparente all’utente.
Alcuni esempi di ridondanza sono:
Un secondo computer configurato identico al principale, pronto ad essere usato nel caso il primo non sia disponibile;
Una seconda connessione ad Internet disponibile nel caso la principale non funzioni.
Un secondo server di replica pronto a intervenire se il principale smette di funzionare.
Avere sistemi ridondati consente di ridurre al minimo i fermi operativi, ma il prezzo da pagare in termini economici è alto, in quanto occorre come minimo avere un oggetto simile che possa prendere il posto di quello non funzionante.
In pratica devi comprare le cose come minimo due volte.
Inoltre, occorrono software che gestiscono i meccanismi di ridondanza e spesso, soprattutto per i server, le configurazioni sono piuttosto complesse.
BUSINESS CONTINUITY E GDPR
Avrai sicuramente sentito parlare negli ultimi anni di GDPR (regolamento generale sulla protezione dei dati), o della nuova normativa europea sulla privacy.
Oltre a tutte le direttive per essere conformi, una in particolare fa riferimento esplicito a procedure di backup e business continuity: l’articolo 32.
Anche se la continuità operativa non viene citata direttamente, l’articolo 32 del GDPR è abbastanza chiaro: il titolare del trattamento e il responsabile del trattamento devono mettere in atto misure tecniche e organizzative adeguate a garantire un livello di sicurezza adeguato al rischio, che comprendono, tra le altre, se del caso:
a) la pseudonimizzazione e la cifratura dei dati personali;
b) la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento;
c) la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;
d) una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento.
Questi punti presuppongono che ogni organizzazione debba avere implementato una vera strategia di continuità operativa, che sia periodicamente testata in modo da poterne dimostrare l’efficacia.
Per approfondire visita il nostro servizio: backup e business continuity
Categorie
Ultimi Post
Articoli più letti
MANTENERE IL COMPUTER EFFICIENTE NEL TEMPO: 7
Giugno 24, 2024IL TUO PC E I TUOI DATI
Agosto 3, 2023NUOVA MINACCIA PER E-MAIL: SPAVENTA L’UTENTE INSINUANDO
Novembre 3, 2022Tag
Archivi