No results found
Il Managed Service Provider è parte in una certa misura dell’azienda cui presta assistenza o delle cui infrastrutture IT si occupa, ragion per cui è, suo malgrado, coinvolto nelle implicazioni del GDPR; per questo deve conoscere almeno quella parte di normativa che lo coinvolge e dalla quale non può prescindere se vuole continuare a svolgere bene la propria attività.
In questo tutorial focalizzeremo il problema, fornendo un metodo pratico per il professionista e l’impresa che operano nell’assistenza tecnica IT.
Per inquadrare il problema partiamo da un esempio decontestualizzato per renderlo immune da considerazioni afferenti la privacy, pur trattandosi di un caso reale (esemplificato dall’immagine seguente: abbiamo la società REXA S.p.A. che ha convocato il Dottor Rossi commercialista e titolare dello studio KK International per una verifica della compliance alla Legge sulla Privacy dello studio commercialista stesso, quale responsabile del trattamento dei dati personali.
Il commercialista torna al proprio studio ed espone la richiesta, spiegando che bisogna preparare l’analisi di gestione del rischio dei sistemi informatici dello studio. Il Dottor Rossi ora vuole verificare la propria compliance privacy e per prima cosa vuole preparare un documento di analisi e gestione del rischio dei suoi sistemi informatici; allo scopo ha chiamato Luca della TEXIS Solution che è un tecnico informatico e questo si trova di fronte alla realtà di non sapere come prepararla. A questo punto deve decidere che fare: lasciare l'incarico a un’altra azienda IT o imparare a farla, investendoci sopra
Questo quadro è realistico e attuale, perché spesso chi ha un piccolo studio o una piccola azienda del settore IT pensa di essere fuori da certi obblighi in quanto ha clienti piccoli; il problema è che questi clienti possono, però, trovarsi a lavorare per aziende più grandi che invece hanno obblighi più stringenti, perché possono essere società quotate, conformi ISO 9000 o ISO 27000, quindi se è vero che l’MSP lavora con clienti piccoli che potrebbero non badare a determinati obblighi è anche vero che questi clienti potrebbero trovarsi a dover chiedere documentazione di conformità al GDPR.
L’MSP svolge varie attività di gestione IT con ambiti ben definiti (immagine seguente):
Il Managed Service Provider gestisce sistemi informatici di terzi clienti e che possono essere medici, avvocati, commercialisti, ma anche società di ogni tipo; si trova quindi di fronte a una varietà di documenti che possono essere fascicoli sanitari, atti legali, contratti e via di seguito e comunque a dati sensibili, oltre che a dati comuni.
Quindi il Managed Service Provider, dal momento che gestisce i sistemi informatici dei clienti, in qualche modo entra nella sfera della gestione dei dati, sia perché può avere accesso ad essi, sia perché è sua cura adottare le strategie per contenere situazioni come le Data Breach e la perdita dei dati. Questo coinvolgimento nel GDPR è tanto più concreto se l’MSP gestisce i dati personali per conto dei propri clienti (immagine seguente).
Capire quanto l’MSP sia coinvolto dal GDPR è importante perché quando si tratta di dati di clienti non si intende strettamente dati di proprietà del cliente stesso, ma magari di dati che esso tratta quale titolare del trattamento dei dati personali in conformità al GDPR; nel momento in cui un interessato trasferisce i dati al titolare del trattamento, che è colui che determina le finalità e i mezzi del trattamento, questo implica tutta una serie di obblighi e se questi obblighi non vengono rispettati è prevista tutta una serie di sanzioni, che vanno da quelle amministrative (pecuniarie) anche molto elevate, alle sanzioni Civili (risarcimento del danno, inutilizzabilità processuali) fino alle sanzioni di tipo penale, perché dalla fuga di dati possono derivare reati contro la persona e nello specifico contro l’interessato.
Peraltro il titolare del trattamento deve, se gli viene richiesto dall’interessato e in ogni momento, fornire informazioni riguardanti il trattamento dei propri dati personali e la conformità del trattamento alle regole del GDPR.
Il principio di base del GDPR è tutelare i diritti e le libertà degli interessati in relazione ai loro dati personali e anche di consentire la circolazione sicura dei dati necessari all’espletamento di servizi di vario genere, per realizzare gli interessi delle parti (trattamento ai fini dello svolgimento del servizio). In quest’ottica, il GDPR impone a chi riceve i dati personali di garantire di tutelare i dati in relazione alle finalità per cui sono stati trasmessi.
Il titolare del trattamento può nominare dei responsabili del trattamento che possono trattare i dati per suo conto, allo scopo di realizzare determinati servizi che il titolare trattamento non è in grado di fornire o che per sua natura egli non fornisce; ad esempio uno studio medico può delegare il trattamento ad un terzo e in questo caso il titolare non è l’erogatore del servizio, però quest’ultimo è tenuto a rendere noto al paziente chi tratterà i suoi dati personali. A sua volta il responsabile del trattamento può affidare i dati a un sub-responsabile del trattamento, ma potrebbe anche dare i dati a un altro titolare del trattamento. L’immagine seguente mostra il possibile flusso, dove l’interessato affida i propri dati a chi gli eroga il servizio, questo si affida a un titolare del trattamento esterno ed eventualmente a responsabili che per suo conto devono rispondere della gestione dei dati personali.
A prescindere da quante strade i dati personali percorrano, il GDPR impone che vi siano garanzie nella loro circolazione, perché chi riceve i dati deve garantire e tutelare i dati in relazione alla finalità per cui sono stati permessi, quindi, ad esempio, se un paziente rilascia i dati a uno studio medico è chiaro che quella finalità deve essere garantita e che i dati non siano utilizzati per scopi diversi, salvo che l’interessato non esprima esplicito consenso.
Nel caso del medico, se i dati vengono affidati a un servizio Cloud per consentire di avere un gestionale clienti, il dottore sta rispettando la finalità che è quella di cura, perché senza gestionale dei pazienti il medico non è in grado di curare nessuno perché non riesce a conservare i dati clinici e i referti.
In un caso del genere il provider che fornisce il servizio Cloud per il gestionale si colloca in varie maniere in funzione di quella che è la struttura, la natura del servizio e l’assegnazione dei ruoli, come verrà esposto tra breve.
Prima di entrare nel dettaglio è opportuno richiamare il concetto di dato personale; ebbene, il dato personale è qualsiasi informazione riguardante una persona fisica determinata o determinabile incrociando varie informazioni. Alla definizione del dato personale concorrono:
Il dato personale esiste quando c’è di mezzo una persona fisica, ovvero anche una giuridica quando la sua ragione sociale contenga il nome della persona (Società Nominative).
Ai fini della gestione MSP il provider non deve entrare nel merito di ogni cliente per capire se sta trattando dei dati personali, ma deve sempre operare come se lo facesse; a riguardo è opportuno precisare che il garante ha già definito la risposta a questa problematica ed è che laddove ci sia un dubbio sulla natura dei dati trattati, occorre trattarli com e dati personali e quindi adottare le cautele del caso.
Stabilito che cos’è un dato personale, andiamo a vedere che cosa si intende per trattamento? Ebbene, questo è qualsiasi operazione o insieme di operazioni, compiute con o senza l'ausilio di processi automatizzati applicata a dati personali o a gruppi di dati personali.
Il trattamento è definito, nelle sue fasi, dall’art. 4 §1 punto 2 del GDPR e si articola ne:
Qui si entra nel campo del Managed Service Provider e sicuramente chi lavora in ambito informatico non può escludersi da questo contesto; basti pensare, ad esempio, all’ultima voce dell’elenco, che coinvolge i compiti del provider in fatto di backupn e disaster recovery.
Se il Managed Service Provider va a gestire sistemi informatici di clienti che trattano dati personali, lui stesso è coinvolto nel trattamento dei dati personali: nel momento in cui accede ai sistemi tratta dati personali e quindi deve rispettare il GDPR.
Dunque, l’MSP è un responsabile del trattamento ex articolo 28 del GDPR, il quale recita: “Qualora un trattamento debba essere effettuato per conto del titolare del trattamento, quest'ultimo ricorre unicamente a responsabili del trattamento che presentino garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate in modo tale che il trattamento soddisfi i requisiti del presente regolamento e garantisca la tutela dei diritti dell'interessato”.
Il cliente definisce l’ambito operativo, ossia quali operazioni sui suoi sistemi informatici l’MSP è autorizzato a compiere; quindi l’MSP tratta i dati per conto del cliente secondo quanto pattuito nel contratto di assistenza e fornitura.
Ne deriva che l’MSP deve pretendere che siano chiarite le sue competenze in fase di stipula del contratto e deve quindi accertarsi di poter adempiere ai relativi obblighi.
Ad esempio, uno studio medico che ha un proprio sistema di gestione informatico dei dati contenente anche dati dei pazienti, definirà determinati compiti che affida all’MSP: lo chiamerà ad esempio per effettuare i backup, gestire gli aggiornamenti software e quindi tutta una serie di trattamenti che sono concordati. Chiaramente, seppure implicito nel GDPR, il provider non può prendere i dati dei pazienti e rivenderli per esempio a un informatore scientifico del farmaco...
Potrà esclusivamente fare quelle funzioni che sono cura e aggiornamento dei sistemi informatici al servizio del medico.
Il contratto tra cliente ed MSP deve contenere un Data Process Agreement (DPA) che definisce quali sono le regole di trattamento dei dati personali, perché l'articolo 28 prevede che vi sia un documento scritto firmato (anche in modalità elettronica, con la firma elettronica) contenente le misure adottate.
Il primo paragrafo dell’articolo 28 dice che nel momento in cui il titolare del trattamento affida ad un responsabile del trattamento la gestione dei dati per suo conto, il responsabile del trattamento deve fornire garanzie sufficienti, ossia mettere in atto misure tecniche e organizzative adeguate affinché il trattamento soddisfi i requisiti del GDPR.
Ciò comporta tutta una serie di obblighi che vanno dall’avere istruzioni scritte al garantire la riservatezza del personale coinvolto, al garantire i diritti degli interessati assistendo il titolare del trattamento.
Occorre anche implementare una Gestione del Rischio secondo l’art. 32, l’assistenza in caso di Data Breach (art. da 32 a 36) e l’assistenza sulla DPIA (art. da 32 a 36) che è una particolare forma di ulteriore analisi del rischio specifica per determinati ambiti.
Bisogna inoltre assistere il cliente nella gestione del rischio, concordare degli audit che cliente può fare relativamente alle strutture, controllare i sub-responsabili del trattamento, che esistono nel caso ci si avvalga di terzi per la fornitura di server, servizi Cloud o simili (sub-responsabili del trattamento sono i fornitori di infrastrutture di cui l’MSP si avvale per svolgere la propria opera a favore del titolare del trattamento).
A fronte della complessità del legame tra MSP e cliente nell’ottica del GDPR, bisogna scegliere un approccio idoneo e quindi stabilire da cosa partire nel tracciare la propria strategia; ebbene tre punti da cui partire sono i seguenti:
L’ultimo punto, ossia la formazione sulla privacy, è in realtà il primo aspetto perché prima di redigere contratti di servizi Cloud e contratti MSP bisogna quantomeno avere un’idea di quali sono i problemi legati alla privacy; solo così è possibile stabilire il giusto rapporto con il cliente titolare del trattamento personale. Solo comprendendo le problematiche connesse alla privacy è possibile comprendere concetti come l’analisi e gestione del rischio e come la gestione delle Data Breach.
Quindi per prima cosa, prima di stipulare un contratto con un cliente che tratta dati personali ai sensi del GDPR, l’MSP dele innanzitutto capire in che stato sono i propri sistemi relativamente a ciò che andrà ad offrire al cliente, pertanto dovrà fare un’analisi del rischio, comprendente valutazioni sulla sicurezza in caso di effrazione e attacco informatico, sulle crittografie adottate per i dati sensibili e sulle procedure da adottare.
Ciò che l’MSP deve fare non riguarda solo la sicurezza intrinseca dei sistemi, ma valutare cosa fare per rendere sicura la parte organizzativa: per esempio a implementare una procedura contro gli attacchi di Social Engineering contro i clienti, portati da soggetti che simulano di essere l’MSP per carpire dei dati o accedere ai sistemi.
L’analisi del rischio è un qualcosa dove si mette nero su bianco quali macchine e sistemi si utilizzano per la gestione del dato personale, qual è il loro livello di rischio relativamente ad alcuni aspetti (perdita dei dati, effrazione ecc.) ed altro ancora.
Quanto alla gestione della Data Breach, redigere una procedura è determinante perché oggi molti soggetti, prima di stipulare un contratto un MSP, chiedono per prima cosa se ha l'analisi del rischio e la cosa è ovvia, perché un provider che non sappia dire cosa farà in caso di effrazione dei sistemi e fuga di dati non fornisce garanzie al cliente né lo rassicura in merito agli obblighi che esso ha alla luce del GDPR. La gestione Data Breach è quindi una procedura in cui descrivere come comportarsi in caso di effrazione, quali strumenti disponibili adottare, come identificare il livello di gravità e valutare se avvertire il titolare del trattamento, indirizzare verso l’eventuale segnalazione al Garante ecc.
Prendiamo ad esempio un virus cryptolocker che una volta entrato nel sistema cripta i dati e poi chiede un riscatto per fornire la chiave per decifrarli; ebbene, al verificarsi di un simile evento il problema non è soltanto decifrare i dati, perché se abbiamo un backup sufficientemente recente possiamo recuperarli da lì e considerare risolta la questione. In realtà bisogna porsi il dubbio che i dati non sono stati soltanto cifrati, ma che magari sono stati anche trafugati e letti da un hacker, che quindi ne entra in possesso.
Nel primo caso l’MSP che abbia un efficace sistema di backup real-time è in regola con il GDPR perché garantisce la disponibilità del dato; nel secondo no.
In un caso del genere occorre avere una procedura ragionevole che comprenda l’utilizzo di strumenti riconosciuti a livello internazionale e soluzioni ragionevolmente affidabili, tali che in caso di indagine del Garante ci si possa quantomeno tutelare dimostrando di aver adottato degli accorgimenti e di aver redatto un piano d’intervento, che potrà essere suscettibile di suggerimenti ma difficilmente di sanzioni.
In questo contesto rientra una serie di adempimenti anche formali che se non vengono svolti dall’MSP lo pone nella condizione del dolo, ossia lo fa passare dalla colpa (inadempienza) al dolo (inadempienza cosciente) e quindi lo mette in una condizione tale da assoggettarlop a pesanti sanzioni.
Mentre la Data Breach può essere considerata un problema a valle, provvedere a mettere insieme tutta una serie di elementi e quindi redigere l’analisi del rischio è ciò che va fatto a monte e rappresenta la base di qualunque sistema di gestione privacy, secondo lo schema a piramide proposto dall’immagine seguente.
Bisogna poi capire le nozioni di base di un sistema di gestione del rischio e a riguardo, il GDPR fornisce degli strumenti concettuali che vengono in aiuto. Quel che bisogna cercare di fare è definire un approccio ragionevole alla gestione del rischio che sia conforme al GDPR, basato su un metodo pratico per step definiti; per esempio scindere la gestione rischio per step definiti, partendo dalla mappatura degli asset dell’organizzazione fare le relative analisi dei trattamenti dei dati personali all’interno dell’organizzazione. A questo punto si combinano gli asset con i relativi trattamenti e si definisce un valore e quindi l’importanza degli asset; si va a vedere quali sono le minacce ed il livello di rischio calcolato sulla base delle probabilità che si verifichino le minacce.
Tutte queste valutazioni possono essere contenute in un a cartella di lavoro Excel con fogli collegati fra loro, ognuno relativo ad un aspetto.
A questo punto possiamo definire come gestire il rischio al fine di mitigarlo, definendo quattro step principali:
Riguardo al primo punto, il contesto può essere la collocazione fisica: per esempio il posto dove risiedono i server: se sono in uno scantinato facilmente allagabile il rischio è alto, mentre se si trovano a un piano alto è ridotto; quanto all’organigramma, il numero di addetti e l’eventuale cambiamento periodico influiscono sul livello di rischio. La mappatura degli asset riguarda ad esempio il numero e le caratteristiche delle macchine utilizzate, mentre i valori RID (Riservatezza Integrità Disponibilità) permettono di capire, asset per asset, qual è la sua importanza e quante contromisure adottare per esso. Giusto per dare un’idea, se in un server vengono trattati i dati sanitari di miei pazienti malati di AIDS, il valore RID assegnato sarà altissimo e quel server sovrà essere protetto molto.
Completato il primo step, si passa a fare una mappatura personalizzata dei rischi, utilizzando un metodo che identifichi quali sono le minacce e faccia un calcolo in relazione alla pericolosità che ha per l’organizzazione, tenuto conto del livello di probabilità e di vulnerabilità.
Il passo successivo riguarda il trattamento personalizzato del rischio, ossia definire misure di contrasto del rischio individuato, che devono essere personalizzate per ogni organizzazione perché ogni realtà ha una situazione specifica e configurazioni caratteristiche di server, sedi, asset in generale.
L’ultimo step si concretizza nel definire qual è il rischio accettabile, ossia il margine non annullabile, che comunque implica delle difficoltà: per esempio se si utilizza un algoritmo di crittografia e questo ha una vulnerabilità molto remota, quello è il rischio, ma documentandolo adeguatamente si può far capire quanto sia accettabile. Un ulteriore esempio può essere quello di un MSP che tratta dati di clienti e che eseguendo backup ogni giorno può garantire la disponibilità del dato alla peggio risalente alle 24 ore precedenti; sta poi al cliente valutare se perdere i dati di una giornata è un rischio accettabile, anche alla luce della possibilità di sopperire, magari con un sistema di backup locale istantaneo nella sede del cliente stesso. Ancora, se si utilizza un server protetto da un un firewall ma ha una versione di Apache che ha un bug conosciuto del quale però non c’è ancora un fix, questo va preso come rischio accettabile se non c’è altra soluzione; però è documentato e quindi si sa come comportarsi e dove cercare in caso di Data Breach.
Ecco, documentare condizioni del genere significa fornire un’idea che permetta di stabilire se il rischio è accettabile ed eventualmente di mitigarlo.
Il tutto aiuta l’MSP a valutare se rinunciare per esempio a determinati trattamenti perché il livello di rischio è troppo alto o aumentare le contromisure perché deve contenere il rischio.
Quel che conta è sapere come comportarsi e implementare procedure tali che in caso di Data Breach questa causi un danno limitato e che sia dimostrabile che il provider abbia una strategia di uscita e abbia cercato di evitarla.
Quanto elencato riguarda la propria organizzazione, però nel momento in cui un MSP “mette le mani” nei sistemi del cliente si pone il problema che siccome i dati del cliente devono essere comunque trattati in modo conforme al GDPR, anche il cliente dovrebbe avere l’analisi e gestione del rischio. Questo documento deve esserci perché deve dare delle istruzioni allo stesso MSP riguardanti le modalità di trattamento dei dati e quindi l’ideale sarebbe che l’MSP facesse un’analisi e gestione del rischio dei sistemi informatici definendo anche l’ambito per il cliente e che il cliente stesso lo adottasse, mettendo in atto anche una serie di misure che consistono eventualmente in report che l’MSP fa al cliente ogni 2-3 mesi riportando determinate attività che sono state svolte e allegando una relazione in merito all'attività. Questo, anche al fine del miglioramento dei sistemi.
Eseguire una corretta analisi e gestione del rischio offre alcuni vantaggi, il primo dei quali è il miglioramento del livello di protezione e controllo dei propri sistemi; questo non va fatto solo a mente, perché mettendolo per iscritto è più facile selezionare i vari profili, asset eccetera, tenendo molto più sotto controllo i sistemi, anche nella scelta delle misure di sicurezza da implementare (per esempio avvalersi di determinati i protocolli di sicurezza magari riconosciuti dalla comunità scientifica di riferimento).
Un secondo vantaggio è sicuramente la possibilità di tutelarsi in caso di ispezione della Guardia di Finanza - Nucleo Speciale Privacy presso il cliente, perché una volta andati dal cliente, gli ispettori arrivano all’MSP perché quasi sicuro il cliente nel momento dell’ispezione chiama in causa il suo provider; in questo caso l’MSP che ha provveduto a una corretta analisi e gestione del rischio può esibire un documento con cui presenta tutta la sua analisi del rischio, le misure che ha adottato e via di seguito. Sicuramente la Guardia di Finanza può avere opinioni differenti, però già l’atteggiamento con cui si pone è molto diverso e più disponibile; se invece non si ha nulla da produrre, a verbale va il fatto che il provider non ha adottato alcuna contromisura né valutato il rischio e tale condotta configura una negligenza che molto probabilmente il Garante sanzionerà.
Il terzo vantaggio è sicuramente la possibilità di tutelarsi in caso di contestazione da parte del cliente, che molto probabilmente se viene citato per danni o riceve sanzioni cerca di tirare in mezzo l’MSP e coinvolgerlo cercando di fargli pagare i danni.
In caso di coinvolgimento in una causa legale, avere un documento che dimostri l’impegno e la strategia del provider pone di fronte al Giudice in una condizione di vantaggio.
Infine, fare e saper fare un’analisi e gestione del rischio apre a nuove opportunità, nel senso che permette di allargare la propria schiera di clienti, quindi sebbene sia inizialmente un onere, una volta che l’MSP ha fatto il lavoro per sé, poi diventa uno strumento di lavoro come tanti altri e permette di essere in regola ad ogni richiesta di assistenza da parte di aziende che devono effettuare il trattamento dei dati personali.
Per quanto riguarda il consulente informatico che fa assistenza in determinati ambiti, esso deve avere le conoscenze per poter affrontare questo tipo di problematiche, quindi saper fare l’analisi del rischio e la gestione Data Breach; poi ci sono tutti gli altri adempimenti, ma sono più complicati e sono strettamente legati all’ambito specifico e riguardanti situazioni da verificarsi.
