Il caso
In Raddoppiare le risorse non è una strategia a lungo termine ho raccontato un'istanza EC2 con molti siti web, ciascuno con il proprio database, che un giorno ha smesso di rispondere. L'intervento d'emergenza è stato raddoppiare CPU e RAM. La causa vera, scoperta settimane dopo, erano gli IOPS di un disco gp2 con i crediti burstable esauriti.
Nessun monitoraggio: il team non si è mai accorto dell'insorgere del problema.
Se quei database contenessero dati personali (account, ordini, richieste di contatto)? Cosa dice il GDPR di un servizio che si ferma?
La richiesta
L'articolo 32 del GDPR chiede al titolare e al responsabile del trattamento misure tecniche e organizzative "per garantire un livello di sicurezza adeguato al rischio", tenendo conto dello stato dell'arte e dei costi. Tra queste: "la capacità di assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza dei sistemi" e "la capacità di ripristinare tempestivamente la disponibilità e l'accesso dei dati personali in caso di incidente fisico o tecnico".
La sicurezza, per il GDPR, non è solo tenere fuori chi non deve entrare. È anche garantire che i dati ci siano quando servono.
In pratica: devi essere in grado di rimettere in piedi l'accesso ai dati in fretta, ed essere in grado di comprendere perché è caduto, così che non possa riaccadere.
Ripristinato, ma non capito
Il ripristino c'è stato, e in tempi brevi: raddoppiare le risorse è una mossa d'emergenza ragionevole. È la parte "su base permanente" che non ha trovato riscontro. Senza nessuna metrica, cosa avesse causato il blocco era un mistero, e per settimane il sistema è rimasto in piedi reggendosi su una spiegazione sbagliata.
C'è poi un aspetto che spesso sfugge: per il GDPR una violazione dei dati personali non è solo la loro divulgazione, la definizione include anche "la distruzione, la perdita". Le linee guida europee sulla notifica trattano come violazione anche un'indisponibilità temporanea, come le cartelle cliniche di un ospedale inaccessibili per trenta ore dopo un attacco.
Ora, non è che ogni blocco vada notificato al Garante, la notifica è necessaria solo se c'è un rischio per i diritti delle persone, ma l'articolo 33 chiede di documentare qualsiasi violazione, con circostanze, conseguenze e rimedi.
Per documentare un incidente bisogna prima accorgersene, un team che scopre i guasti dalle telefonate dei clienti non ha un modo affidabile per sapere quando è iniziato, quanto è durato e che cosa ha coinvolto.
Dichiarato vs dimostrato
| Cosa si dichiara | Cosa si dimostra |
|---|---|
| "I nostri servizi sono affidabili" | Le metriche di disponibilità degli ultimi mesi, e gli allarmi che le sorvegliano |
| "In caso di problemi ripristiniamo in fretta" | I tempi di ripristino degli ultimi incidenti, e l'ultimo test di ripristino |
| "Abbiamo capito cosa è successo" | La causa individuata, il rimedio applicato e la verifica che abbia funzionato |
| "Non ci sono state violazioni" | Il registro degli incidenti, con la valutazione di ciascuno di essi: violazione o no, notifica o no |
| "Ci accorgiamo subito dei guasti" | L'allarme che è scattato prima della prima telefonata |
Se la colonna destra è compilabile solo con i ricordi del team, abbiamo un serio problema.
Da dove partirei
- Un allarme prima del limite. Per ogni risorsa che può finire (CPU, memoria, IOPS, spazio), una soglia che avvisa (molto) prima che il servizio si fermi.
- Un registro degli incidenti. Anche un singolo file: quando, cosa, quali dati coinvolti, quanto è durato, se è una violazione e perché si è deciso di notificarla o no.
- Un ripristino provato. Una volta, a freddo, è indispensabile verificare quanto ci si mette a ripristinare il sito e il suo database annotandone i tempi.
Non serve un centro operativo di sicurezza per una manciata di siti, servono pochi allarmi, un registro e l'abitudine a trascrivere cosa è successo.
Il caso reale da cui nasce, raccontato come appunto di lavoro: il problema, come l'ho affrontato, cosa ho imparato.
Raddoppiare le risorse non è una strategia a lungo termine→
In sintesi (TL;DR)
- L'art. 32 del GDPR include tra le misure di sicurezza la disponibilità e la resilienza dei sistemi, e la capacità di ripristinare tempestivamente l'accesso ai dati dopo un incidente.
- Un server raddoppiato in emergenza ha rimesso in piedi i siti, ma senza monitoraggio nessuno sapeva perché erano caduti né se sarebbe successo di nuovo.
- Anche l'indisponibilità dei dati personali può essere una violazione: va almeno documentata, e notificata se presenta un rischio per le persone.
- Per partire: un allarme prima che le risorse finiscano, un registro degli incidenti e un ripristino provato.