Come utilizzare la crittografia per proteggere i tuoi dati MongoDB

La sicurezza del database è un fattore chiave da considerare per qualsiasi applicazione che coinvolge dati altamente sensibili come rapporti finanziari e sanitari. La protezione dei dati può essere ottenuta attraverso la crittografia a diversi livelli a partire dall'applicazione stessa fino ai file che contengono i dati.

Poiché MongoDB è un database non relazionale, non è necessario definire le colonne prima di inserire i dati; e quindi i documenti della stessa collezione potrebbero avere campi diversi tra loro.

D'altra parte, per SQL DBMS, è necessario definire colonne per i dati, quindi tutte le righe hanno le stesse colonne. Si può decidere di crittografare singole colonne, interi file di database o dati dall'applicazione prima di essere coinvolti nel processo del database.

La crittografia delle singole colonne è preferibile poiché è più economica e vengono crittografati meno dati, migliorando così la latenza. In generale, le prestazioni complessive influiscono a causa della crittografia.

Per NoSQL DBMS, questo approccio tuttavia non sarà il migliore. Considerando che non tutti i documenti potrebbero avere tutti i campi che desideri utilizzare nella crittografia, non è possibile eseguire la crittografia a livello di colonna.

La crittografia dei dati a livello di applicazione è piuttosto costosa e difficile da implementare. Rimaniamo quindi con l'opzione di crittografare i dati a livello di database.

MongoDB fornisce una crittografia nativa che non richiede il pagamento di un costo aggiuntivo per la protezione dei dati sensibili.

Crittografia dei dati in MongoDB

Qualsiasi operazione sul database coinvolge una di queste due forme di dati, dati inattivi o dati in movimento.

I dati in movimento sono un flusso di dati in movimento attraverso qualsiasi tipo di rete, mentre i dati inattivi sono statici, quindi non si spostano da nessuna parte.

Entrambi questi due tipi di dati sono soggetti a interferenze esterne da parte di utenti anonimi, a meno che non sia coinvolta la crittografia. Il processo di crittografia prevede:

• Generazione di una chiave master per l'intero database
• Generazione di chiavi univoche per ogni database
• Crittografare i tuoi dati con le chiavi del database che hai generato
• Crittografia dell'intero database con la chiave master

Crittografia dei dati in transito

I dati vengono trasferiti tra MongoDB e l'applicazione server in due modi, ovvero tramite Transport Layer Security (TLS) e Secure Socket Layer (SSL).

Questi due sono i protocolli di crittografia più utilizzati per proteggere i dati inviati e ricevuti tra due sistemi. Fondamentalmente, il concetto è crittografare le connessioni alle istanze mongod e mongos in modo tale che il traffico di rete sia leggibile solo dal client previsto.

TLS/SSL vengono utilizzati in MongoDB con alcuni certificati come file PEM emessi dall'autorità di certificazione o possono essere un certificato autofirmato. Quest'ultimo ha una limitazione in quanto, tuttavia, il canale di comunicazione è crittografato, non c'è sempre alcuna convalida contro l'identità del server, quindi è vulnerabile ad attacchi esterni a metà strada. È quindi consigliabile utilizzare certificati di autorità attendibili che consentano ai driver MongoDB di verificare anche l'identità del server.

Oltre alla crittografia, TLS/SSL può essere utilizzato nell'autenticazione del client e nelle autorizzazioni interne dei membri dei set di repliche e dei cluster partizionati tramite i certificati.

Configurazione TLS/SSL per client

Esistono varie impostazioni delle opzioni TLS/SSL che possono essere utilizzate nella configurazione di questi protocolli.

Ad esempio, se desideri connetterti a un'istanza Mongod utilizzando la crittografia, devi avviare la tua istanza come,

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl abilita la connessione TLS/SSL.

--sslCAFile specifica il file pem dell'autorità di certificazione (CA) per la verifica del certificato presentato dal mongod o dai mongo. La shell Mongo verificherà quindi il certificato emesso dall'istanza mongod rispetto al file CA specificato e al nome host.

Potresti anche voler connettere l'istanza MongoDB che richiede un certificato client. Usiamo l'esempio di codice qui sotto

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

L'opzione --sslPEMKeyFile specifica il file .pem che contiene il certificato mongo shell e una chiave da presentare all'istanza mongod o mongos. Durante il processo di connessione:

La shell mongo verificherà se il certificato proviene dall'autorità di certificazione specificata che è il (--sslCAFile) e in caso contrario, la shell non riuscirà a connettersi.

In secondo luogo, la shell verificherà anche se il nome host specificato nell'opzione --host corrisponde alla SAN/CN nel certificato presentato dal mongod o dai mongos. Se questo nome host non corrisponde a nessuno dei due, la connessione fallirà.

Se non desideri utilizzare certificati autofirmati, devi assicurarti che la rete di connessione sia affidabile.

Inoltre, è necessario ridurre l'esposizione della chiave privata, in particolare quando sono coinvolti set di repliche/cluster partizionati. Ciò può essere ottenuto utilizzando certificati diversi su server diversi.

Ulteriori opzioni che possono essere utilizzate nelle connessioni sono:

requireSSL:questo limiterà ogni server a utilizzare solo connessioni crittografate TLS/SSL.

--sslAllowConnectionsWithoutCertificates:consente la convalida se solo il client presenta un certificato, altrimenti se non è presente alcun certificato, il client sarà comunque connesso in modalità crittografata. Ad esempio:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols:questa opzione impedisce ai server di accettare connessioni in entrata che utilizzano protocolli specifici. Questo può essere fatto con:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Crittografia dei dati inattivi

Dalla versione 3.2, MongoDB ha introdotto un'opzione di crittografia nativa per il motore di archiviazione WiredTiger. L'accesso ai dati in questa memoria da parte di terzi può essere ottenuto solo attraverso una chiave di decrittazione per decodificare i dati in un formato leggibile.

L'algoritmo di crittografia comunemente usato in MongoDB è AES256-GCM. Utilizza la stessa chiave segreta per crittografare e decrittografare i dati. La crittografia può essere attivata utilizzando la modalità FIPS, garantendo così che la crittografia soddisfi gli standard e la conformità più elevati.

L'intero file di database viene crittografato utilizzando la crittografia dei dati trasparenti (TDE) a livello di archiviazione.

Ogni volta che un file viene crittografato, viene generata una chiave di crittografia privata univoca ed è utile capire come queste chiavi vengono gestite e archiviate. Tutte le chiavi del database generate vengono successivamente crittografate con una chiave master.

La differenza tra le chiavi del database e la chiave master è che le chiavi del database possono essere archiviate insieme ai dati crittografati stessi, ma per la chiave master, MongoDB consiglia di archiviarla in un server diverso dai dati crittografati come la chiave aziendale di terze parti soluzioni gestionali.

Con i dati replicati, i criteri di crittografia non vengono condivisi con gli altri nodi poiché i dati non sono crittografati in modo nativo via cavo. È possibile riutilizzare la stessa chiave per i nodi, ma la migliore pratica consiste nell'utilizzare singole chiavi univoche per ogni nodo.

Chiavi di crittografia rotanti

La chiave gestita utilizzata per decrittografare i dati sensibili deve essere ruotata o sostituita almeno una volta all'anno. Ci sono due opzioni in MongoDB per ottenere la rotazione.

Rotazione principale KMIP

In questo caso viene modificata solo la chiave maestra in quanto gestita esternamente. Il processo per ruotare la chiave è come descritto di seguito.

1. La chiave principale per i membri secondari nel set di repliche viene ruotata una alla volta. Cioè

   mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

   Al termine del processo, mongod uscirà e dovrai riavviare il secondario senza il parametro kmipRotateMasterKey

   mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

2. Il primario del set di repliche viene ridotto:
   Utilizzando il metodo rs.stepDown(), il primario viene disattivato, forzando quindi l'elezione di un nuovo primario.

3. Controlla lo stato dei nodi usando il metodo rs.status() e se il primary indica di essere stato abbassato, ruota la sua chiave master. Riavvia il membro dimesso inclusa l'opzione kmipRotateMasterKey.

   mongod --enableEncryption --kmipRotateMasterKey \
     --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Registrazione

MongoDB funziona sempre con un file di registro per registrare alcuni stati o informazioni specifiche a intervalli diversi.

Tuttavia, il file di registro non è crittografato come parte del motore di archiviazione. Ciò comporta il rischio che un'istanza mongod in esecuzione con la registrazione possa restituire dati potenzialmente sensibili ai file di registro proprio come parte della normale registrazione.

Da MongoDB versione 3.4, è presente l'impostazione security.redactClientLogData che impedisce la registrazione di dati potenzialmente sensibili nel registro del processo mongod. Tuttavia, questa opzione può complicare la diagnostica del registro.

Prestazioni di crittografia in MongoDB

La crittografia a un certo punto si traduce in una maggiore latenza, quindi in un peggioramento delle prestazioni di un database. Questo è solitamente il caso quando è coinvolto un grande volume di documenti.

La crittografia e la decrittografia richiedono più risorse, quindi è importante comprendere questa relazione per adeguare di conseguenza la pianificazione della capacità.

Per quanto riguarda i test MongoDB, un motore di archiviazione crittografato sperimenterà una latenza compresa tra il 10% e il 20% al carico massimo. Questo spesso accade quando un utente scrive una grande quantità di dati nel database, con conseguente riduzione delle prestazioni. Per le operazioni di lettura, il degrado delle prestazioni è trascurabile, circa il 5 - 10%.

Per una migliore pratica di crittografia in MongoDB, il motore di archiviazione WiredTiger è preferito per le sue elevate prestazioni, sicurezza e scalabilità. Inoltre, ottimizza la crittografia dei file di database a livello di pagina, il che ha un grande vantaggio in quanto, se un utente legge o scrive dati nel database crittografato, l'operazione di throughput verrà applicata solo alla pagina su cui sono archiviati i dati anziché all'intera banca dati.

Ciò ridurrà la quantità di dati che dovranno essere crittografati e decrittografati per l'elaborazione di un singolo dato.

Riepilogo

La sicurezza dei dati per le informazioni sensibili è un must ed è necessario proteggerli senza degradare le prestazioni del sistema di database.

MongoDB fornisce solide procedure di crittografia nativa che possono aiutarci a proteggere i nostri dati sia inattivi che in movimento. Inoltre, le procedure di crittografia devono essere conformi agli standard stabiliti dalle diverse organizzazioni.

Il motore di archiviazione WiredTiger avanzato offre un'opzione migliore grazie ai vantaggi associati come prestazioni elevate, scalabilità e sicurezza. Quando si crittografano i dati nei set di repliche, è buona norma utilizzare chiavi master diverse per ciascuna, oltre a cambiarle almeno una volta all'anno.

Nonostante la disponibilità di opzioni di crittografia di terze parti, non vi è alcuna garanzia che la tua distribuzione corrisponda a loro in termini di scalabilità. È quindi abbastanza premuroso utilizzare la crittografia a livello di database.