Il caso
In Quando il cloud costa, ma nessuno sa dire perché ho raccontato un account AWS da migrare in cui nessuno sapeva spiegare il costo di S3. Bucket con versioning attivo, cancellazioni gestite dall'applicazione, lifecycle policy incompleta. In quel caso, il 70% dello storage era fatto di versioni precedenti di file che l'applicazione aveva eliminato mesi prima.
Lì l'ho raccontato come un problema di costi. Ma la domanda interessante è un'altra: "Se quell'account fosse stato dentro il perimetro di un sistema di gestione della sicurezza delle informazioni, cosa avrebbe trovato un auditor?"
La richiesta
La ISO/IEC 27001:2022 elenca nell'Annex A il controllo 8.10 (cancellazione delle informazioni): le informazioni conservate in sistemi, dispositivi o supporti di memorizzazione vanno cancellate quando non sono più necessarie.
Come tutti i controlli dell'Annex A, si applica se la valutazione del rischio lo rende necessario. Per chi conserva dati, però, è difficile motivarne l'esclusione.
In pratica: devi sapere quando un dato smette di servirti e avere un meccanismo che, a quel punto, lo elimini per davvero.
Cancellato per chi?
Il punto debole non era il versioning. Attivarlo "per sicurezza" è una scelta sensata: protegge da cancellazioni accidentali e sovrascritture. Il punto debole era che nessuno aveva deciso per quanto tempo una versione precedente dovesse esistere.
Così la cancellazione avveniva a metà. L'applicazione rimuoveva il file dalla propria vista, lo storage aggiungeva un delete marker ma conservava tutto il resto. Per l'utilizzatore del sistema il dato era sparito, per chiunque potesse leggere il bucket era ancora lì, intero.
Se quel bucket fosse rientrato nel perimetro del sistema di gestione, sarebbe stato difficile dimostrare l'effettiva applicazione del controllo 8.10: la cancellazione è dichiarata dall'applicazione, ma non viene completata nello storage. E un dato che non serve più, ma esiste ancora, resta un dato da proteggere.
È lo stesso problema che ritrovo dai clienti: utenti "disattivati" ancora presenti nel database, snapshot di dischi dimenticati, export in CSV su una cartella condivisa "solo per questa volta".
Dichiarato vs dimostrato
| Cosa si dichiara | Cosa si dimostra |
|---|---|
| "I file cancellati vengono eliminati" | La lifecycle policy fa scadere versioni precedenti e delete marker, con indicatori tepmorali |
| "Abbiamo il versioning per sicurezza" | Per quanti giorni una versione precedente serve, e perché proprio quelli |
| "Lo storage è sotto controllo" | Il rapporto tra versioni correnti e precedenti per ogni bucket, con la data dell'ultima verifica |
| "Gli upload falliti si puliscono da soli" | Una regola che rimuove gli upload incompleti |
| "Sappiamo cosa conserviamo" | L'elenco dei bucket con proprietario, scopo e tempo di conservazione |
A sinistra c'è quello che si scrive nelle policy, a destra c'è quello che un auditor ti chiede di mostrargli.
Da dove partirei
- Per ogni bucket, una sola riga: a cosa serve? Di chi è? Per quanto tengo i dati e le loro versioni? Se la risposta è "per sempre, per sicurezza", abbiamo il primo problema da sistemare.
- Una lifecycle policy completa, non solo sulle versioni correnti. Versioni precedenti, delete marker, upload incompleti: ognuno con la sua scadenza.
- Una verifica periodica, documentata. Confronti lo spazio occupato dalle versioni correnti con quello delle precedenti e annoti data ed esito. Se il rapporto cresce, la regola non sta funzionando.
Per correggere questa lacuna non devi partire da una piattaforma di data governance. Parti da una decisione scritta su quanto tenere ogni dato, e da una regola che la applichi.
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)
- Il controllo A.8.10 della ISO 27001 chiede di cancellare le informazioni quando non servono più: non basta che l'applicazione smetta di mostrarle.
- Con il versioning S3 attivo e senza una lifecycle policy completa, un file cancellato dall'applicazione resta nello storage come versione precedente.
- Versioning e cancellazione non sono in conflitto: serve decidere per quanto tempo una versione precedente ha ancora uno scopo.
- Per partire: una regola di scadenza per ogni tipo di oggetto, una verifica periodica di cosa occupa lo storage e qualcuno che ne valuti l'esito.