Livelli di insicurezza di MongoDB e come evitarli

La maggior parte dei sistemi di gestione dei database ha diverse tecniche per proteggere i propri dati da un estraneo o da una persona o applicazione non autorizzata. Le tecniche impediscono che i tuoi dati vengano letti o copiati senza il permesso dell'utente.

MongoDB non è diverso in quanto presenta alcuni livelli di insicurezza. In questo post del blog, discuteremo i livelli di insicurezza in MongoDB e come evitarli in modo da poter proteggere la tua installazione di MongoDB.

Per la sicurezza e la protezione del tuo MongoDB, le seguenti sono alcune delle principali misure di sicurezza da considerare rigorosamente:
 

1. Autenticazione delle connessioni degli utenti.

2. Autorizzazione/Controllo dell'accesso basato sul ruolo.

3. Crittografia di rete/Crittografia di trasporto.

4. Crittografia archiviazione/Crittografia a riposo.

5. Auditing.

In questo articolo, esamineremo in dettaglio le misure di sicurezza di cui sopra, con particolare attenzione all'autenticazione e all'autorizzazione.

Autenticazione e autorizzazione

L'autenticazione e l'autorizzazione devono essere attivate all'unisono. Tuttavia, possono essere utilizzati indipendentemente l'uno dall'altro. L'autenticazione impedisce l'accesso a una persona sconosciuta che ha accesso in rete al server del database per copiare o danneggiare i dati del database. L'autenticazione richiede che tutti i client e i server forniscano credenziali valide prima che possano connettersi al sistema. L'autorizzazione, invece, impedisce a un'applicazione oa un utente di leggere, modificare o eliminare dati diversi da quelli previsti.

Per configurare il controllo dell'accesso basato sul ruolo;

1. Crea prima un amministratore utente.

2. Crea utenti aggiuntivi.

3. Quindi crea un utente MongoDB univoco per ogni persona/applicazione che accede al sistema.

4. Seguendo il principio del privilegio minimo, dovresti creare ruoli che definiscano gli esatti diritti di accesso necessari a un insieme di utenti.

5. Quindi assegna agli utenti solo i ruoli che devono svolgere nelle loro operazioni. Un utente può essere un'applicazione client o una persona.

Si noti che un utente può avere privilegi su database diversi o multipli. In tale scenario, invece di creare un utente più volte in database diversi, crea un singolo utente con ruoli che concedono i privilegi del database applicabili.

Il più delle volte, queste due misure di sicurezza potrebbero essere confuse per significare la stessa cosa. In alcuni scenari sono simili tra loro, ma sono anche diversi.

Somiglianze tra autenticazione e autorizzazione

• Entrambi sono in qualche modo una singola unità perché, quando abiliti l'autenticazione, l'autorizzazione viene abilitata automaticamente. L'autorizzazione è abilitata all'unisono con l'autenticazione, quindi le connessioni da utenti sconosciuti non avranno il privilegio di accedere ai dati del database. L'autorizzazione richiede anche che il nome utente sia verificato dall'autenticazione in modo da sapere quali privilegi si applicano alle richieste di connessione. Pertanto, non può nemmeno essere abilitato indipendentemente dall'altro.

• Sono entrambi simili anche nella sfortunata denominazione legacy delle opzioni di configurazione. L'opzione del file di configurazione per l'autenticazione è security.authorization invece dell'autenticazione di sicurezza come ci si aspetterebbe. Quando si utilizza il comando, tuttavia, l'autenticazione è la prima ad essere abilitata e l'autorizzazione è abilitata solo come effetto collaterale. "-auth" è l'argomento della riga di comando per abilitare l'autenticazione che forza automaticamente anche l'autorizzazione ad essere attiva.

Differenze tra autenticazione e autorizzazione

• Questi due sono diversi perché sono due parti del software che hanno funzioni diverse.

Autenticazione ==Identità utente, tramite verifica credenziali.

Autorizzazione ==Assegnazione e applicazione delle autorizzazioni per oggetti DB e comandi DB.

• Durante la configurazione iniziale, l'autenticazione è disabilitata per le connessioni localhost. Questo è breve, tuttavia, poiché hai l'opportunità di creare il primo utente, il privilegio di eccezione (alla regola Autenticazione e autorizzazione insieme) viene eliminato.

Come verificare se l'autenticazione e l'autorizzazione sono abilitate o meno

Le prime versioni di MongoDB avevano "- auth" impostato per impostazione predefinita e questa è ampiamente considerata una mossa sbagliata. Anche nella versione 4.0 era ancora disattivato per impostazione predefinita. La configurazione vuota equivale ancora a un'autorizzazione disattivata nonostante gli avvisi di avvio e varie riduzioni dell'esposizione come localhost che diventa l'unico dispositivo di rete predefinito in MongoDB v3.6.

Non stai usando l'Autenticazione o meglio non hai l'Autenticazione abilitata se i file di configurazione di mongod non lo fanno:

1. Avere security.authorization impostato su "abilitato".

2. Includi un security.keyfile.

3. Includi un'impostazione security.clusterAuthMode che forza l'autenticazione.

Per ricontrollare se l'autenticazione e l'autorizzazione sono abilitate o meno, puoi provare questa rapida mongo shell one-liner (senza impostare argomenti per le credenziali utente):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

La risposta che dovresti ricevere è un errore "non autorizzato". Ma, d'altra parte, se ottieni un elenco di nomi di database, significa automaticamente che hai una distribuzione MongoDB nuda.

Autenticazione esterna

Come suggerisce il nome, l'autenticazione esterna consiste nel consentire agli utenti di essere autenticati in un servizio esterno. In via eccezionale, non può essere utilizzato per l'utente interno del sistema mongodb __, ma è perfettamente adatto utilizzarlo per qualsiasi utente umano reale o account del servizio dell'applicazione client.

Semplicemente, il servizio di autenticazione esterno sarà un KDC Kerberos o un server ActiveDirectory o OpenLDAP. Tieni presente che l'utilizzo dell'autenticazione esterna non ti impedisce di avere contemporaneamente account utente MongoDB ordinari.

Autenticazione interna

Al contrario, l'autenticazione interna di MongoDB non significa l'opposto dell'autenticazione esterna. Questo perché un nodo mongod in esecuzione con l'autenticazione abilitata non si fiderà del fatto che un peer TCP sia un altro nodo mongod o mongos solo perché comunica come tale. Piuttosto, richiede che il peer si autentichi tramite la prova del segreto condiviso.

Ci sono due tipi di meccanismi di autenticazione interni in MongoDB:

1. Autenticazione interna del file di chiavi.

2. Autenticazione interna SCRAM o x.509.

Autenticazione interna file di chiavi

Questo è il meccanismo di autenticazione interna predefinito in MongoDB. Il termine "Chiave" indica una chiave di crittografia asimmetrica ma in realtà è solo una password, indipendentemente da come l'hai generata. Il file di chiavi viene salvato in un file identico distribuito a ciascun nodo mongod e mongos nel cluster. Nello scenario in cui la password viene utilizzata correttamente, un nodo mongod consentirà ai comandi provenienti dal peer autenticato di essere eseguiti come superutente “_ _ system”.

Se qualcuno ha una copia del file di chiavi, può semplicemente rimuovere i caratteri di controllo e non stampabili dal file di chiavi per creare la stringa della password che consentirà loro di connettersi come utente "_ _ sistema".

Tuttavia, se ciò accade ed esegui il comando seguente come utente mongod (o root) su uno dei tuoi server MongoDB e hai successo, non dovresti preoccuparti perché non ci saranno perdite accidentali di privilegi di lettura . Questo perché mongod si interromperà all'avvio se il file di chiavi è in una modalità diversa da 400 (o 600) autorizzazioni di file.

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Tuttavia, il salvataggio accidentale del file di chiavi nel controllo del codice sorgente leggibile dal mondo può consentire agli utenti che non sono DBA (o amministratori del server con root) di leggere una copia del file di chiavi. Questo è considerato un errore di sicurezza.

Un rischio estremo aumenta quando il file di chiavi viene distribuito con i nodi mongos di proprietà ed eseguito come uno degli utenti unix del team dell'applicazione anziché "mongod" o un altro utente unix di proprietà del team DBA.

Autenticazione interna SCRAM o x.509

Il meccanismo di autenticazione interna x.509 utilizza effettivamente chiavi private o pubbliche asimmetriche e deve essere utilizzato in unione con TLS/SSL. Questo meccanismo può essere utilizzato per le connessioni client e per l'autenticazione interna.

Il meccanismo x.509 o SCRAM ha un vantaggio rispetto al meccanismo Keyfile perché nel meccanismo x.509 è meno probabile che una delle chiavi distribuite con i nodi mongod e mongos possa essere abusata da un intruso che ne ottiene una copia. Tuttavia, questo dipende da quanto rigorosamente sono impostati i certificati x.509. Per usufruire della massima sicurezza da questo meccanismo, è necessario disporre di un team di sicurezza dedicato che comprenda i concetti e le best practice di x.509. Queste best practice includono il rafforzamento degli host su cui funzionerà e la possibilità di revocare e trasferire i certificati.

Crittografia di rete/Crittografia di trasporto

La crittografia di rete impedisce a qualcuno di copiare i dati che vengono trasferiti su un collegamento di rete da qualche parte tra due server. La crittografia di rete richiede poca o nessuna riflessione quando si tratta di decidere se utilizzarla poiché è fondamentale. Ma se, ad esempio, il tuo cluster MongoDB e tutti i suoi client si trovano all'interno di una rete privata virtuale che ritieni non abbia buchi nel suo firewall e nessun rischio di escalation dei privilegi da altre app, allora non hai bisogno della crittografia di rete.

Per la crittografia di rete, dovresti configurare MongoDB per utilizzare TLS/SSL per tutte le connessioni in uscita e in entrata. Crittografa la comunicazione tra i componenti mongod e mongos di una distribuzione MOngoDB, nonché tra tutte le applicazioni e MongoDB utilizzando TLS/SSL.

A partire dalla versione 4.0; MongoDB disabilita il supporto per la crittografia TLS 1.0 sui sistemi in cui è disponibile TLS 1.1+ e utilizza anche le seguenti librerie TLS/SSL native:

1. Windows - Secure Channel (Schannel).

2. Linux/BSD - OpenSSL.

3. macOS - Trasporto sicuro.

Limita l'esposizione alla rete

Dovresti assicurarti che MongoDB venga eseguito in un ambiente di rete affidabile e anche configurare firewall o gruppi di sicurezza per controllare il traffico in entrata e in uscita per le tue istanze MongoDB. Inoltre, configura per consentire solo ai client attendibili di accedere alle interfacce di rete e alle porte su cui sono disponibili le istanze MongoDB. Ad esempio, utilizza la whitelist IP per consentire l'accesso da indirizzi IP affidabili.

Esegui MongoDB con Opzioni di configurazione sicure

MongoDB supporta l'esecuzione del codice JavaScript per le seguenti operazioni lato server:

1. mapReduce.

2. $dove.

3. $accumulatore.

4. $funzione.

Utilizzare l'opzione --noscripting sulla riga di comando per disabilitare lo scripting lato server se non si utilizzano le operazioni precedenti. Mantieni abilitata la convalida dell'input sebbene MongoDB abiliti la convalida dell'input per impostazione predefinita tramite l'impostazione net.wireObjectCheck. Ciò garantisce che tutti i documenti archiviati dall'istanza mongod siano BSON validi.

Crittografia archiviazione MongoDB/Crittografia a riposo

La crittografia dell'archiviazione impedisce a qualcuno di ottenere una copia dei file di database sottostanti. Ciò potrebbe accadere quando qualcuno irrompe nel tuo data center e ruba il disco rigido del tuo server. I dati MongoDB includono file di dati, file di configurazione, log di controllo e file chiave.

A partire da MongoDB Enterprise 3.2, puoi crittografare i dati nel livello di archiviazione con la crittografia a riposo nativa del motore di archiviazione WiredTiger. I dati MongoDB devono essere crittografati su ciascun host utilizzando file system, dispositivo o crittografia fisica quando non si utilizza la crittografia a riposo di WiredTiger. Inoltre, dovresti raccogliere i log in un archivio di log centrale poiché questi log contengono tentativi di autenticazione DB, incluso l'indirizzo IP di origine. Tuttavia, la crittografia dell'archiviazione ha un leggero costo in termini di prestazioni.

Audit

L'auditing aiuta a tenere traccia di un utente del database che sa come nascondere le proprie tracce dopo aver modificato o alterato i dati del database. Fondamentalmente, l'auditing tiene traccia degli accessi e delle modifiche alle configurazioni e ai dati del database. MongoDB Enterprise dispone di una funzione di sistema di controllo in grado di registrare eventi di sistema come operazioni utente ed eventi di connessione su un'istanza MongoDB.

Questi record di controllo aiutano nell'analisi forense e consentono agli amministratori di verificare controlli adeguati. L'auditing è di grande valore per alcuni utenti, ma può esserlo solo quando alcuni altri rischi vengono eliminati. Ad esempio, un utente malintenzionato non può ottenere l'accesso root Unix sui server mentre esegue i nodi mongod live.

Andare avanti

Puoi impostare filtri per registrare eventi specifici come eventi di autenticazione. Ma fai attenzione perché quando i filtri di audit sono troppo ampi, le sue prestazioni si soffocano rapidamente portando a costi di prestazioni elevati. Anche se, se l'auditing viene utilizzato in modo appropriato, non ci saranno molti costi di performance.