Proteggere i dati nel punto in cui vengono usati
Un ecommerce conserva indirizzi, riferimenti agli ordini, note di assistenza e attributi operativi oltre la singola richiesta. Cifrare disco e backup è importante, ma non sostituisce la protezione applicativa dei campi sensibili: quando il database è disponibile, lo sono anche i volumi sottostanti. L’obiettivo è limitare ciò che una copia indebita dell’archivio può rivelare, rendendo i dati leggibili solo ai servizi autorizzati.
Parti da un inventario. Per ogni campo registra finalità, proprietario, lettori, conservazione, ricerca e cancellazione. Elimina ciò che non serve e assegna classi coerenti. Qui trattiamo dati applicativi persistenti, non TLS, password, numeri di carta, tokenizzazione o segreti: problemi che richiedono controlli differenti.
Stabilire il modello di minaccia e il confine
Descrivi gli eventi da contenere: copia non autorizzata del database, backup esposto, privilegio eccessivo di un operatore o compromissione di un servizio. Decidi quali componenti possono richiedere la decifratura e quali devono vedere soltanto dati cifrati. La crittografia non corregge autorizzazioni applicative errate né una compromissione completa del processo che possiede già il permesso di decifrare. Per questo va combinata con identità, autorizzazioni minime, audit e riduzione dei dati.
Separare dati, chiavi dati e chiavi di cifratura
Nell’envelope encryption l’applicazione cifra il contenuto con una chiave di cifratura dei dati, o DEK, generata per un oggetto o un insieme limitato. La DEK in chiaro viene poi cifrata con una chiave di protezione, o KEK, custodita dal KMS. Il dato memorizzato contiene il testo cifrato, la DEK cifrata e i metadati del formato. La KEK non lascia il KMS e la DEK in chiaro vive solo per l’operazione necessaria.
Questa struttura evita di inviare grandi contenuti al KMS e consente di governare centralmente le chiavi di protezione. Non improvvisare primitive o formati: usa una libreria mantenuta che offra cifratura autenticata, generazione casuale corretta e un formato versionato. La cifratura autenticata rileva alterazioni del testo cifrato e dei dati associati prima di restituire il contenuto in chiaro.
Definire una busta versionata
Progetta uno schema esplicito con versione del formato, riferimento logico alla chiave, algoritmo o suite gestita dalla libreria, DEK cifrata, nonce o parametri richiesti, testo cifrato e tag di autenticazione quando separato. Non memorizzare mai la DEK in chiaro. Conserva riferimento alla chiave e metadati di formato o del fornitore sufficienti a interpretare ogni busta: alcuni testi cifrati KMS includono già le informazioni necessarie, quindi non imporre ovunque un campo separato per la versione del materiale.
Legare i dati cifrati al contesto ecommerce
Quando libreria e KMS lo supportano, usa un contesto di cifratura autenticato che leghi la busta al tipo di dato, al soggetto servito e alla finalità. Tecnicamente è un dato associato arbitrario, ma non è segreto: può restare in chiaro e comparire nei registri del KMS. Perciò non inserirvi dati sensibili o personali. Mantieni nomi e valori stabili e verifica che una busta spostata su un dato o soggetto diverso venga rifiutata.
Conserva identificatori tecnici opachi e una versione delle regole, non dettagli operativi sensibili. Il servizio chiamante deve ricostruire lo stesso contesto in modo deterministico. Se una migrazione cambia gli identificatori, prepara una fase di compatibilità o ricifra prima del cambio; non scoprire in produzione che il nuovo codice non può più presentare i parametri usati in origine.
Ridurre i permessi KMS e separare i ruoli
Il percorso di scrittura può avere il permesso di generare o cifrare una DEK senza ottenere privilegi amministrativi sulla KEK. Il percorso di lettura deve poter decifrare solo le buste previste dal proprio contesto. Rotazione, disabilitazione, regole di accesso e pianificazione della cancellazione appartengono a ruoli operativi separati. Evita autorizzazioni globali e verifica con test negativi che un servizio, un ambiente o un soggetto non autorizzato riceva un rifiuto controllato.
Tratta gli eventi di audit KMS come segnali sensibili. Raccogli operazione, identità tecnica, chiave, esito, ambiente e correlazione applicativa senza copiare contenuti in chiaro o DEK. Genera avvisi per volumi inattesi di decifratura, identità nuove, rifiuti di autorizzazione e uso di chiavi prossime alla dismissione. Collega la richiesta al flusso ecommerce senza trasformare i registri in un altro deposito di dati personali.
Progettare la rotazione prima del primo dato
Distingui tre operazioni. La rotazione automatica o su richiesta del materiale può mantenere la stessa identità logica della chiave e conservare il materiale storico per leggere i dati esistenti. Creare una nuova chiave KMS ne cambia invece l’identità. Nessuna delle due operazioni ricifra automaticamente le buste già archiviate: Google Cloud lo dichiara esplicitamente. Ricifrare la DEK protetta con ReEncrypt, senza esporla in chiaro al chiamante, è una migrazione separata da pianificare e autorizzare.
Definisci il periodo d’uso in base a rischio, volume, risposta agli incidenti e obblighi interni. Mantieni accessibile il materiale precedente finché serve a una busta: una cancellazione anticipata rende i dati irrecuperabili. Prima di ogni fase conta i riferimenti e verifica backup, repliche e code.
Scegliere tra migrazione progressiva e per lotti
Una strategia progressiva ricifra la busta quando il dato viene letto o aggiornato: riduce il picco di lavoro, ma prolunga la convivenza tra riferimenti. Una migrazione per lotti accorcia la finestra e richiede limiti di velocità, punti di ripresa, idempotenza e controllo dei costi KMS. Spesso conviene combinarle: nuovi dati sulla chiave corrente, lotti per il nucleo attivo e una coda residua per gli oggetti rari. Ogni percorso deve potersi fermare senza lasciare dati ambigui.
Gestire memoria temporanea, errori e indisponibilità
Memorizzare temporaneamente le DEK in chiaro può ridurre la latenza e le chiamate KMS, ma aumenta la durata dell’esposizione e la quantità di memoria coinvolta. Se la libreria lo consente, limita la durata, il numero di utilizzi e l’ambito; non creare un archivio permanente. Azzera le aree di memoria quando possibile e non registrarle. Misura i riutilizzi, le scadenze e le decifrature, poi confronta il beneficio con il rischio del flusso.
Quando il KMS è indisponibile, non salvare dati in chiaro né ignorare l’autenticazione. Classifica gli errori in transitori, autorizzativi, di formato e di integrità. Esegui un numero limitato di nuovi tentativi soltanto quando è sicuro farlo, accoda i lavori rinviabili e restituisci un errore esplicito per le letture impossibili. La procedura d’intervento deve distinguere indisponibilità, regola errata, chiave disabilitata, busta corrotta e contesto non corrispondente.
Migrare e rilasciare senza una riscrittura rischiosa
Aggiungi una struttura di busta compatibile, poi abilita la doppia lettura: preferisci il formato cifrato e usa il vecchio valore solo durante la migrazione controllata. Avvia le scritture cifrate, completa l’arretrato per piccoli lotti e verifica ogni risultato nel processo autorizzato. Provata la copertura, rimuovi il percorso alternativo e cancella il campo precedente secondo la politica di conservazione. Evita la doppia scrittura indefinita, che crea due fonti di verità.
Prepara il ritorno alla versione precedente di codice e regole senza perdere chiavi. Un rilascio pilota deve coprire cifratura, decifratura, contesto errato, chiave vecchia, nuovi tentativi e ripristino da backup. Mantieni un campione sintetico per provare le procedure, senza dati cliente. Verifica anche esportazioni, lavori asincroni e strumenti di assistenza autorizzati.
Misurare sicurezza, affidabilità e progresso
Costruisci un riferimento iniziale con percentuale di dati nel formato corrente, buste per riferimento alla KEK o metadato equivalente, errori per classe, latenza di cifratura e decifratura, chiamate KMS, riusi delle chiavi dati, arretrato di migrazione e costo osservato. Aggiungi il tempo necessario a revocare un’identità e a completare una rotazione di prova. Non esiste una soglia universale: definisci obiettivi dal traffico e dal rischio reali, poi prova gli allarmi con eventi controllati.
Rivedi inventario, permessi, formati e dipendenze. Il team deve saper ruotare le chiavi, ripristinare i dati e analizzare gli incidenti senza esporre informazioni in chiaro. Per integrare cifratura, architettura e osservabilità, esplora i nostri servizi per sistemi digitali ed ecommerce. La catena deve restare verificabile: dati minimi, buste versionate, chiavi governate e procedure provate.
Domande frequenti
Che differenza c’è tra DEK e KEK nell’envelope encryption?
La DEK cifra il contenuto applicativo; la KEK custodita dal KMS cifra la DEK. Nell’archivio restano testo cifrato, DEK cifrata e metadati, mai la DEK in chiaro.
Ruotare una chiave KMS richiede di ricifrare tutti i dati?
Non sempre. La rotazione automatica o su richiesta può mantenere la stessa identità e il materiale storico; adottare una nuova chiave cambia identità. Ricifrare le DEK protette è una migrazione distinta.
Il contesto di cifratura può contenere dati personali?
Tecnicamente il contesto è un dato associato arbitrario, ma non è segreto e può comparire in chiaro o negli audit KMS. Per questo non dovrebbe contenere dati sensibili o personali.
Come si gestisce un’indisponibilità temporanea del KMS?
Non si salva testo in chiaro. Si classificano gli errori, si limita il numero di nuovi tentativi sicuri, si accodano i lavori rinviabili e si applica una procedura operativa che distingue interruzione del servizio, regola errata, chiavi e buste corrotte.
Articoli correlati
Transazioni database ecommerce: isolamento, deadlock e retry sicuri
Un metodo operativo per scegliere l’isolamento, distinguere deadlock e attese, ripetere l’intera transazione e proteggere gli effetti esterni.
Sessioni ecommerce sicure: cookie, SameSite, rotazione e logout
Una guida operativa per proteggere la sessione dopo il login con cookie ben delimitati, rotazione degli identificatori, timeout server-side e revoca verificabile.
Paginazione delle API ecommerce: cursori, ordine stabile e risultati coerenti
Un metodo operativo per progettare cursori opachi, ordinamenti deterministici e sessioni di lettura che limitano duplicati, salti e costi crescenti.
