La sicurezza dei dati è fondamentale in tempi di GDPR, PCI DSS o HIPPA. Per ottemperare alle normative, è necessario esercitare la massima cautela su come i dati devono essere archiviati e protetti. I dati, in genere, possono essere inattivi o in transito. I dati in transito sono i dati trasferiti da o verso il database. I risultati delle query inviati al client o all'applicazione oi dati replicati tra i nodi del cluster sono esempi di casi in cui i dati sono in transito. Tendiamo a proteggere i dati in quello stato utilizzando SSL o TLS:connessioni crittografate tra i nodi del database o il database e il client.
Dall'altro lato dello spettro, abbiamo dati a riposo - diremmo che la maggior parte dei dati è, in un dato momento, a riposo. Stiamo parlando di dati archiviati su disco in tablespace, diverse strutture di dati (buffer gcache, redo log) e log (binary e relay log). Diamo un'occhiata alle considerazioni su questo argomento in MariaDB.
Cosa crittografare in MariaDB?
Idealmente, devi crittografare tutto. I database memorizzano i dati in luoghi e modi diversi, come accennato in precedenza. Il più grande set di dati viene archiviato nei tablespace:questa è la posizione "finale" in cui vengono archiviati i dati. Ovviamente, è possibile crittografare i tablespace, altrimenti l'intera funzionalità sarebbe inutile. MariaDB può archiviare i dati in un tablespace condiviso, molti di essi o ogni tabella può essere archiviata in un tablespace separato:tutti questi scenari sono supportati. Gli utenti hanno un certo livello di flessibilità nella scelta di cosa crittografare. Puoi crittografare tutto, singole tabelle o tutto tranne alcune singole tabelle.
Registro di ripristino di MariaDB InnoDB
Un'altra struttura che memorizza i dati è il redo log di InnoDB. Il registro di ripristino di InnoDB è un luogo in cui i dati vengono scritti dopo l'aggiornamento di una determinata riga. I dati del registro di ripristino verranno eventualmente trasferiti al tablespace, ma per un certo periodo il registro di ripristino di InnoDB contiene tutte le modifiche avvenute di recente. Come puoi immaginare, anche questi dati sono fondamentali e dovrebbero essere protetti:MariaDB ti consente di crittografare il registro di ripristino di InnoDB.
Registri binari di MariaDB
I registri binari (così come i registri di inoltro) memorizzano informazioni sulle query eseguite che modificano i dati. Poiché le informazioni incluse ci consentono di ricostruire lo stato corrente di una riga che ha subito modifiche, questa è un'altra forma di dati che dovrebbe essere protetta e crittografata. Sia i log binari che quelli di inoltro possono essere crittografati in MariaDB.
Cache di Galleria
Galera cache (gcache) è un buffer su disco in Galera Cluster che memorizza le informazioni sulle modifiche eseguite. Viene utilizzato in caso di guasto del nodo o problemi di rete temporanei per consentire ai nodi che si uniscono al cluster di recuperare utilizzando solo i dati mancanti, evitando di trasferire l'intero set di dati. Simile ai registri binari o ai registri di ripristino, gcache contiene l'elenco delle modifiche e, in quanto tale, può essere utilizzato per recuperare e mettere insieme parti di dati. Nella versione community di MariaDB Galera Cluster gcache non può essere crittografato. Tale opzione diventa disponibile nella versione Enterprise di MariaDB Galera Cluster.
Cosa non può essere crittografato in MariaDB?
Ci sono ancora alcuni punti in cui potrebbero essere visualizzati pezzi di dati che non possono essere crittografati, almeno per ora, in MariaDB. In primo luogo, i log degli errori possono contenere campioni di query che possono potenzialmente esporre alcuni dati. È impossibile crittografare i log degli errori, ma è possibile reindirizzare il log degli errori al syslog e implementare alcuni meccanismi di protezione al di fuori di MariaDB.
Registri dal plug-in di controllo
Anche il plug-in Audit genera un registro:questo registro può contenere informazioni riservate, comprese le query esatte che sono state eseguite sul database. Non è possibile crittografare questo registro, ma può essere reindirizzato al syslog e crittografato lì.
Registri query
Registri di query generali e lenti:questi registri conterranno query (o almeno esempi di esse) che sono state eseguite da MariaDB. Al momento, non è possibile crittografare quei registri.
Pool buffer InnoDB
Memoria - MariaDB esegue la crittografia solo per le pagine archiviate sul disco. Tutti i dati archiviati nel pool di buffer InnoDB non saranno crittografati. Il pool di buffer InnoDB ha lo scopo di mantenere le righe modificate di recente o a cui si accede dalla query SELECT:quelle righe conterranno ovviamente campioni di dati. Al momento, non è possibile crittografare il pool di buffer InnoDB in MariaDB. Tieni presente che sarebbe necessario l'accesso al sistema per leggere la memoria live. Non è un compito banale, anche se non è nemmeno impossibile da realizzare.
Tieni presente che abbiamo coperto le opzioni di crittografia incluse in MariaDB. C'è sempre la possibilità di utilizzare un altro livello di crittografia. Ad esempio, crittografare l'intero spazio di archiviazione renderà i registri non leggibili per chiunque abbia accesso fisico al disco. D'altra parte, non proteggerà i dati da qualcuno che è in grado di accedere al sistema.
Compatibilità con strumenti esterni
Un'altra cosa da considerare è la compatibilità. Se decidi di crittografare il tuo MariaDB, devi tenere presente che ciò potrebbe influire sul tuo modo di operare. Non è possibile utilizzare strumenti esterni come XtraBackup o mysqlbinlog per elaborare i dati e creare un backup o per gestire i log binari. Dovrai attenerti agli strumenti creati da MariaDB (come Mariabackup), che sono scritti pensando al meccanismo di crittografia. Possono gestire i dati a riposo la crittografia è implementata in MariaDB.
Pianificazione del processo di crittografia
Questa sezione non discuterà il processo in dettaglio, ma esamina ciò che dovresti considerare quando pianifichi la crittografia, come risorse e tempo. L'utilizzo della CPU aumenterà così come l'attività di I/O per la durata del processo. Dal punto di vista dell'utente, tutto si riduce alle impostazioni di configurazione e quindi all'esecuzione dei comandi ALTER per ricostruire e crittografare le tabelle esistenti. Per i database di grandi dimensioni, questo da solo può essere una sfida significativa che richiederebbe una pianificazione. Le modifiche allo schema possono essere un onere serio e si consiglia di utilizzare strumenti come pt-online-schema-change per ridurne l'impatto sui sistemi di produzione e ottenere un migliore controllo sul processo.
Pensieri finali
Come accennato, i dati sono fondamentali per tutte le organizzazioni ed è fondamentale garantire che i dati siano al sicuro e protetti. La crittografia dei dati inattivi è uno degli elementi importanti nell'intero quadro. Ci piacerebbe conoscere la tua esperienza con la crittografia dei dati a riposo in MariaDB. Se desideri condividere i tuoi pensieri, sei invitato a lasciare un commento qui sotto.
