Criptare i dati con MySQL/MariaDB - Parte 4, finale.
Considerazioni finali sull'uso dell'encrypt data on-rest su mysql e mariadb
Nelle puntate precedenti abbiamo visto prima come installare mariadb su debian 12, abbiamo imparato che mariadb di default salva i dati in chiaro sul database, in seguito abbiamo visto come configurare mariadb per criptare i dati “on-rest” sul server, attraverso delle chiavi generate e criptate specificatamente e abbiamo visto le varie modalità di crittazione dei dati disponibi su MariaDB. Oggi faremo delle considerazioni finali molto importati su cosa e quando proteggere con questa modalità. E su cosa venga e cosa non venga protetto tramite l’encrypt di questi dati.
Quando utilizzare l’encryption on rest
Quotando direttamente dalla documentazione ufficiale di MariaDB, vediamo questa introduzione che è molto chiara a riguardo:
Nearly everyone owns data of immense value: customer data, construction plans, recipes, product designs and other information. These data are stored in clear text on your storage media. Everyone with file system access is able to read and modify the data. If this data falls into the wrong hands (criminals or competitors) this may result in serious consequences.
With encryption you protect Data At Rest. That way, the database files are protected against unauthorized access.
In questo senso è palese che dati sensibili di qualunque genere non dovrebbero quindi mai essere salvati in chiaro sullo storage. Tuttavia è importante sottolineare che il solo encrypt dei dati NON salvaguarda da ogni tipo di attacco.
Cosa protegge la data-on-rest encryption
Un attaccante ottiene l'accesso al sistema e copia i file del database evitando il controllo di autorizzazione di MariaDB. In questo senso la data-on-rest encryption è molto utile perchè i file così ottenuti, saranno del tutto inutilizzabili dall’attaccante.
Cosa NON protegge la data-on-rest encryption
Ad esempio un attaccante che dovesse ottenere accesso non consentito ad un’applicazione che si connette alla base dati, tramite autenticazione (es. una interfaccia web utilizzata come frontend/backend del database) avrà accesso alla base dati non criptata, con una penetrazione dipendente dalla clearence che avrà ottenuto dall’abuso dell’applicazione (es. tramite sql-injection).
Come vengono gestite le chiavi di crittazione
MariaDB supporta svariati metodi per la gestione delle chiavi di crittazione (ricordate? sono le chiavi che abbiamo generato nella seconda puntata).
Il metodo utilizzato in questo howto è il più semplice, che non richiede servizi di terze parti. E’ denominato File Key Management Plugin, ha la peculiarità di essere installato e presente di default con ogni installazione di MariaDB e permette la gestione di chiavi crittate estrandole direttamente da un file di testo.
Ha molteplici vantaggi:
Legge le chiavi di crittografia da un file di chiavi in chiaro.
Come ulteriore meccanismo di protezione, il file delle chiavi di testo può essere crittografato.
Supporta più chiavi di crittografia.
Supporta due diversi algoritmi per la crittografia dei dati.
ma ha lo svantaggio di non supportare la rotazione delle chiavi. Se si desidera avere anche la gestione della rotazione ed il versionamento delle chiavi bisogna utilizzare plugin di terze parti su MariaDB. Se vi interessa avere la rotazione delle chiavi su MariaDB encryption on rest fatecelo sapere contattandoci, provvederemo a scrivervi un howto apposito.
Salvataggio delle chiavi di crittazione e backup dei database
Dal momento che se si dovessero perdere le chiavi con cui sono stati criptati i dati in database, i dati stessi si potrebbero considerare persi, è di fondamentale importanza che tali chiavi vengano salvata in un luogo sicuro.
Una buona policy di backup per tali chiavi prevede il salvataggio delle stesse in dispositivi cold storage possibilmente staccati dalla rete. All’interno dei quali salvare le chiavi in una partizione cifrata con una chiave di cifratura dedicata questa partizione. Un esempio può essere un disco locale criptato tramite LUKS.
Allo stesso modo è bene considerare che quando si va ad eseguire un dump del database criptato (pratica questa normale quando si vuole effettuare un backup di un database) il dump risultante sarà non criptato ma in chiaro. Pertanto anche in questo caso è bene considerare una policy di backup similare a quella per le chiavi, quindi ad esempio un disco staccato dalla rete e criptato tramite LUKS con una chiave apposita per questo backup
Conclusioni
Siamo arrivati al termine di questo excursus per quanto concerne l’uso di MySQL/MariaDB data on rest encryption, valutandone i pregi e i difetti a seconda del caso d’uso. Ci auguriamo che possiate averlo trovato utile per voi. Qualora necessitiate di una soluzione professionale configurata già in production-level potete considerare di contattarci senza impegno e vi seguiremo passo a passo nel processo, con una delle nostre soluzioni personalizzabili. Grazie per l’attenzione.