Il caso
In Quando il cloud costa, ma nessuno sa dire perché ho raccontato di un bucket S3 con versioning attivo e cancellazioni gestite a livello'applicativo senza una lifecycle policy completa. In un caso, il 70% dello storage era popolato di versioni precedenti di file che l'applicazione aveva eliminato mesi prima. Terabyte di dati che, per chi l'utilizzatore finale, non esistevano più.
Se tra quei file ci fossero documenti caricati dagli utenti, allegati o export con dati personali, il problema non si sarebbe limitato alla fattura.
La richiesta
L'articolo 5 del GDPR fissa il principio di limitazione della conservazione: i dati personali sono "conservati in una forma che consenta l'identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati". E il paragrafo 2 aggiunge che il titolare è competente per il rispetto di questi principi "e in grado di comprovarlo".
L'articolo 17 dà all'interessato il diritto di ottenere la cancellazione dei propri dati senza ingiustificato ritardo, per esempio quando non sono più necessari, con eccezioni come gli obblighi di legge.
In pratica: ogni dato personale deve avere un periodo di conservazione deciso, e la cancellazione deve avvenire davvero, non solo nella vista dell'applicazione.
Cancellato per chi?
Il versioning non ha colpe, protegge da cancellazioni accidentali e sovrascritture, tenere copie per un periodo definito è una scelta più che legittima. Il problema è che nessuno aveva definito una lifecycle policy per quel bucket, quindi, le versioni precedenti restavano lì per sempre.
In quel contesto diverse procedure automatiche provvedevano alla cancellazione dei file, quel singolo errore di policy rendeva tutte le versioni precedenti di ogni singolo file cancellato disponibili per chiunque avesse accesso al bucket.
Se un interessato avesse chiesto la cancellazione, la risposta "fatto" sarebbe stata vera per l'applicazione e falsa per lo storage. In caso di data breach? Tra i dati esposti ci sarebbero stati anche quelli che non dovevano più esserci.
C'è anche un effetto sulla migrazione che stavamo valutando: spostare quello storage così com'era significava trasferire a un nuovo fornitore dati personali già dichiarati cancellati.
Dichiarato vs dimostrato
| Cosa si dichiara | Cosa si dimostra |
|---|---|
| "Cancelliamo i dati quando non servono più" | La regola di scadenza per ogni categoria, applicata anche alle versioni precedenti |
| "Abbiamo un periodo di conservazione" | Il documento che lo fissa con la motivazione, e la prova che lo storage lo rispetta |
| "Le richieste di cancellazione vengono evase" | Il registro delle richieste, con data, esito e sistemi in cui il dato è stato eliminato |
| "Il versioning serve per sicurezza" | Per quanto tempo, e perché quel tempo è compatibile con la finalità |
| "Sappiamo dove sono i dati personali" | L'elenco dei bucket che li contengono, con proprietario e finalità |
Il principio di responsabilizzazione sta tutto qui: non basta rispettare la regola, bisogna poterlo mostrare.
Da dove partirei
- Un inventario dei bucket contenenti i dati personali. Quali contengono documenti, allegati o export riferiti a persone, e per quale finalità.
- Scadenze allineate al periodo di conservazione. Le lifecycle policy coprono versioni precedenti, delete marker e upload incompleti, con tempi coerenti con quello che hai deciso e documentato.
- Una cancellazione provata dall'inizio alla fine. Carichi un file di test, lo elimini dall'applicazione, e dopo la scadenza verifichi che non ne esista più nessuna versione. Annoti data ed esito.
Non serve spegnere il versioning, né comprare uno strumento di data discovery. Serve decidere per quanto tenere ogni dato, e assicurarsi che lo storage non ne mantenga una copia fantasma.
Il caso reale da cui nasce, raccontato come appunto di lavoro: il problema, come l'ho affrontato, cosa ho imparato.
Quando il cloud costa, ma nessuno sa dire perché→Questo caso l'ho documentato in modo più strutturato come Architecture Decision Record, con contesto reale, trade-off valutati e risultati osservati.
ADR251104: Costi non attribuibili in AWS S3 dovuti a versioning non governato→
In sintesi (TL;DR)
- L'art. 5 del GDPR chiede di conservare i dati personali per un tempo non superiore a quello necessario alle finalità, e di essere in grado di dimostrarlo.
- Con il versioning S3 senza una lifecycle policy completa, un file cancellato dall'applicazione resta nello storage, intero, come versione precedente.
- Se quei file contengono dati personali, la cancellazione dichiarata all'utente non corrisponde a quella eseguita dallo storage.
- Per partire: sapere quali bucket contengono dati personali, allineare le scadenze al periodo di conservazione e provare una cancellazione dall'inizio alla fine.