La guida essenziale alla sicurezza di MongoDB

David Murphy è il responsabile della pratica per MongoDB presso Percona, un fornitore di soluzioni e servizi MySQL e MongoDB di classe enterprise.

La sicurezza di MongoDB è di nuovo nelle notizie. Una recente ondata di storie rivela come gli hacker abbiano sequestrato i database di MongoDB e riscattato i dati per bitcoin. Decine di migliaia di installazioni MongoDB sono state compromesse, secondo Rapid7.

Ci preoccupiamo tutti della sicurezza. Se esegui applicazioni, reti o database, la sicurezza è sempre un problema di primo piano. Con sempre più aziende che si rivolgono a software open source come MongoDB per archiviare dati aziendali importanti, la sicurezza diventa una questione ancora più grande. A seconda della tua attività, potresti anche avere più standard normativi sulla sicurezza della rete governativi (come l'Health Insurance Portability and Accountability Act o HIPAA) o aziendali (Payment Card Industry Data Security Standard o PCI DSS) a cui devi conformarti.

Il software del database MongoDB è sicuro? Soddisfa questi standard? La risposta breve: Sì lo è, e sì lo fa! È semplicemente questione di sapere come impostare, configurare e lavorare con la tua particolare installazione.

In questo articolo, parlerò della sicurezza di MongoDB. MongoDB è sicuro da usare, se sai cosa cercare e come configurarlo.

Prima di tutto, come si sbagliano le persone con la sicurezza di MongoDB? Ci sono diverse aree chiave che inciampano gli utenti quando si tratta di sicurezza MongoDB:

  • Utilizzando le porte predefinite
  • Non abilitare immediatamente l'autenticazione (il problema più grande!)
  • Quando si utilizza l'autenticazione, si offre a tutti un ampio accesso
  • Non si utilizza LDAP per forzare la rotazione delle password
  • Non forzare l'utilizzo di SSL sul database
  • Non limitare l'accesso al database a dispositivi di rete noti (host dell'applicazione, bilanciatori del carico e così via)
  • Non limita la rete in ascolto (tuttavia ciò non influisce più sulle versioni supportate)

MongoDB ha cinque aree di sicurezza principali:

  • Autenticazione. L'autenticazione LDAP centralizza gli elementi nella directory aziendale.
  • Autorizzazione. L'autorizzazione definisce i controlli di accesso basati sui ruoli forniti dal database.
  • Crittografia. La crittografia può essere suddivisa in At-Rest e In-Transit. La crittografia è fondamentale per proteggere MongoDB.
  • Auditing. Il controllo si riferisce alla capacità di vedere chi ha fatto cosa nel database.
  • Governance. La governance si riferisce alla convalida dei documenti e al controllo dei dati sensibili (come un numero di conto, una password, un numero di previdenza sociale o una data di nascita). Ciò si riferisce sia alla conoscenza della posizione in cui sono archiviati i dati sensibili sia alla prevenzione dell'introduzione di dati sensibili nel sistema.

Autenticazione LDAP

MongoDB ha ruoli utente incorporati e li disattiva per impostazione predefinita. Tuttavia, perde elementi come la complessità della password, la rotazione basata sull'età e la centralizzazione e l'identificazione dei ruoli utente rispetto alle funzioni di servizio. Questi sono essenziali per approvare normative come la conformità PCI DSS. Ad esempio, PCI DSS proibisce l'uso di vecchie password e password facili da violare e richiede modifiche all'accesso dell'utente ogni volta che lo stato cambia (ad esempio, quando l'utente lascia un reparto o l'azienda).

Per fortuna, LDAP può essere utilizzato per colmare molte di queste lacune. Molti connettori consentono l'utilizzo di sistemi Windows Active Directory (AD) per comunicare con LDAP.

Nota: il supporto LDAP è disponibile solo in MongoDB Enterprise. Non è nella versione Community. È disponibile in altre versioni open source di MongoDB come Percona Server per MongoDB. 

MongoDB 3.2 memorizza gli utenti in LDAP, ma non i ruoli (questi sono attualmente archiviati sulle singole macchine). MongoDB 3.4 Enterprise dovrebbe introdurre la possibilità di memorizzare i ruoli in LDAP per l'accesso centralizzato. (Discuteremo i ruoli più tardi.)

Percona

Utilizzando LDAP e AD, puoi collegare gli utenti alla tua directory aziendale. Quando cambiano ruolo o lasciano l'azienda, possono essere rimossi dalle risorse umane dal gruppo di database. Pertanto, si dispone di un sistema automatizzato per garantire che solo coloro a cui si desidera accedere manualmente ai dati possano farlo, senza perdere accidentalmente qualcosa.

LDAP in Mongo è in realtà facile. MongoDB ha un comando speciale per dirgli di controllare il database LDAP esterno: $external.

Alcuni altri avvertimenti per l'utilizzo di LDAP:

  • Crea un utente con .createUsercome faresti normalmente, ma assicurati di utilizzare i tag delle risorse db / collection.
  • Inoltre, l'autenticazione LDAP richiede altri due campi:
    • meccanismo: "PLAIN"
    • digestPassword: false

Ruoli personalizzati

Il controllo degli accessi basato sui ruoli (RBAC) è fondamentale per MongoDB. I ruoli incorporati sono disponibili in MongoDB dalla versione 2.6. Puoi persino crearne uno tuo, fino alle azioni specifiche che un determinato utente potrebbe essere autorizzato a fare. Ciò consente di definire ciò che un determinato utente può fare o vedere con precisione assoluta. Questa è una funzionalità principale di MongoDB disponibile in quasi tutte le versioni del software open source.

I cinque ruoli principali di MongoDB incorporati di cui dovresti essere a conoscenza:

  • read:
    • Accesso di sola lettura, in genere concesso alla maggior parte degli utenti
  • readWrite:
    • readWrite l'accesso consente la modifica dei dati
    • readWrite include leggere
  • dbOwner:
    • Include readWrite, dbAdmin, userAdmin(per il database). userAdminsignifica aggiungere o rimuovere utenti, concedere privilegi agli utenti e creare ruoli. Questi privilegi vengono assegnati solo al server di database specifico.
  • dbAdminAnyDatabase:
    • Crea dbAdminsu tutti i database, ma non consente l'amministrazione degli utenti (per creare o rimuovere utenti, ad esempio). Puoi creare indici, chiamare compazioni e altro ancora. Questo non fornisce l'accesso allo sharding.
  • root:
    • Questo è un superutente, ma con dei limiti
    • Può fare la maggior parte delle cose, ma non tutte:
      • Impossibile modificare la raccolta di sistema
      • Alcuni comandi non sono ancora disponibili per questo ruolo, a seconda della versione. Ad esempio, il ruolo root MongoDB 3.2 non ti consente di modificare le dimensioni dell'oplog o del profiler e il ruolo root MongoDB 3.4 non ti consente di leggere le visualizzazioni correnti.

Database e raccolte con caratteri jolly

Il carattere jolly significa concedere autorizzazioni a grandi gruppi di database o raccolte (o tutti) su un server. Con un valore null, è possibile specificare tutti i database o le raccolte ed evitare il dbAdminAnyDatabaseruolo. Ciò consente a utenti specifici di disporre di tutti i privilegi, comprese le funzioni di amministrazione.

Questo è pericoloso.

Quando usi i caratteri jolly, concedi molti privilegi speciali e dovresti essere consapevole che stai aprendo possibili vie di attacco:

  • readWriteAnyDatabaseè estremamente ampia ed espone i nomi utente e i ruoli a un potenziale attacco tramite l'utente dell'applicazione
  • L'utilizzo di caratteri jolly significa che non limiterai applicazioni specifiche a database specifici
  • I caratteri jolly ti impediscono di utilizzare multi-tenancy con più database
  • Ai nuovi database non viene concesso automaticamente l'accesso

Creazione di un ruolo personalizzato

La potenza dei ruoli MongoDB deriva dalla creazione di ruoli personalizzati. In un ruolo personalizzato, è possibile specificare che qualsiasi azione su qualsiasi risorsa può essere specificata per un utente specifico. Con questo livello di granularità, puoi controllare in profondità chi può fare cosa nel tuo ambiente MongoDB.

Quando si tratta di specificare un ruolo personalizzato, esistono quattro tipi distinti di risorse:

  • db. Specifica un database. È possibile utilizzare una stringa per un nome o "" per "qualsiasi" (senza caratteri jolly).
  • collection. Specifica una raccolta di documenti. È possibile utilizzare una stringa per un nome o "" per "qualsiasi" (senza caratteri jolly).
  • cluster. Specifica un cluster partizionato o altre risorse di metadati. È un valore booleano true / false.
  • anyResource. Specifica l'accesso a qualsiasi cosa, ovunque. È un valore booleano true / false.

Qualsiasi ruolo può ereditare le proprietà di un altro ruolo. Esiste un array chiamato "ruoli" ed è possibile rilasciare un nuovo ruolo nell'array. Erediterà le proprietà del ruolo specificato.

Utilizzare createRoleper aggiungere un ruolo all'array.

È possibile aggiungere database nuovi o esistenti a un utente o un ruolo. Ad esempio, è possibile aggiungere l'accesso in lettura e scrittura a un database aggiungendo il database a un ruolo.

Utilizza il grantPrivilegesToRolecomando per aggiungere nuove risorse a un ruolo esistente.

Di seguito è riportato un esempio di creazione di un nuovo ruolo Super utente. Lo scopo di questo ruolo, ancora una volta, è di avere un utente che non sia in alcun modo limitato nell'ambiente MongoDB (per situazioni di emergenza).

db = db.geSiblingDB(“admin”);

db.createRole({     

     role: “superRoot”,     

     privileges:[{          

          resource: {anyResource:true},          

          actions: [‘anyAction’]     

     }]     

     roles:[]

});

db.createUser({     

     user: “comanyDBA”,     

     pwd: “EWqeeFpUt9*8zq”,     

     roles: [“superRoot”]

})

Questi comandi creano un nuovo ruolo sul database geSiblingDBchiamato superRoote assegnano a quel ruolo qualsiasi risorsa e qualsiasi azione. Quindi creiamo un nuovo utente sullo stesso database chiamato companyDBA(con una password) e gli assegniamo il nuovo superRootruolo.

Usare SSL per tutte le cose

SSL aiuta a garantire la sicurezza dei tuoi dati su reti non protette. Se utilizzi un database che interagisce con Internet, dovresti utilizzare SSL.

Ci sono due ottime ragioni per usare SSL per proteggere MongoDB: privacy e autenticazione. Senza SSL, è possibile accedere, copiare e utilizzare i dati per scopi illegali o dannosi. Con l'autenticazione, hai un livello secondario di sicurezza. L'infrastruttura a chiave privata (PKI) di SSL garantisce che solo gli utenti con il certificato CA corretto possano accedere a MongoDB.

MongoDB supporta SSL da molto tempo, ma nelle ultime versioni ha notevolmente migliorato il supporto SSL. In precedenza, se volevi usare SSL, dovevi scaricarlo e compilarlo manualmente con la versione della community di MongoDB. A partire da MongoDB 3.0, SSL viene compilato con il software per impostazione predefinita. 

Anche le versioni precedenti di MongoDB non disponevano di un controllo host valido; la convalida dell'host era semplicemente un flag che era possibile controllare nel file di configurazione che soddisfaceva una richiesta SSL da una connessione.

Le ultime versioni di SSL in MongoDB includono le seguenti funzionalità chiave:

  • Verifica la presenza di host validi (opzionale)
  • Possibilità di puntare a un file .key di configurazione specifico da utilizzare
  • Autorità di certificazione (CA) personalizzata per certificati autofirmati o firmatari alternativi
  • allowSSL, preferSSL, requireSSLI modi, che consentono di selezionare una granularità per l'uso di SSL (da meno sicuro a più sicuro)

SSL: utilizzo di una CA personalizzata

Le versioni più recenti di SSL in MongoDB consentono di utilizzare una CA personalizzata. Sebbene questo ti dia flessibilità nello specificare come desideri lavorare con SSL, viene fornito con avvertenze. Se stai semplicemente cercando di proteggere la connessione, potresti essere tentato di optare per sslAllowInvalidCertficates. Tuttavia, questa è generalmente una cattiva idea per alcuni motivi:

  • Consente qualsiasi connessione da certificati scaduti a revocati
  • Non stai garantendo restrizioni a un nome host specifico
  • Non sei così sicuro come pensi di essere

Per risolvere questo problema, è sufficiente impostare net.ssl.CAFilee MongoDB utilizzerà sia la chiave che il file CA (è necessario farlo sul client).

L'uso di SSL, tuttavia, ha un noto svantaggio: le prestazioni. Perderai sicuramente alcune prestazioni quando utilizzi SSL.

Crittografia del disco

I dati sono "in transito" o "a riposo". Puoi crittografare uno o entrambi in MongoDB. Abbiamo discusso della crittografia dei dati in transito (SSL). Ora esaminiamo i dati a riposo.

I dati inattivi sono dati archiviati su disco. La crittografia dei dati inattivi si riferisce in genere ai dati salvati in una posizione di archiviazione crittografata. Questo per prevenire il furto con mezzi fisici e creare backup che vengono archiviati in un modo non facilmente leggibile da terze parti. Ci sono limiti pratici a questo. Il più grande è fidarsi degli amministratori di sistema e presumere che un hacker non abbia ottenuto l'accesso amministrativo al sistema.

Questo non è un problema esclusivo di MongoDB. Anche le misure preventive utilizzate in altri sistemi funzionano qui. Potrebbero includere strumenti di crittografia come LUKS e cryptfs o metodi ancora più sicuri come la firma di chiavi di crittografia con LDAP, smart card e token di tipo RSA.

Quando si esegue questo livello di crittografia, è necessario considerare fattori come il montaggio automatico e la decrittografia delle unità. Ma questo non è nuovo per i tuoi amministratori di sistema. Possono gestire questo requisito nello stesso modo in cui lo gestiscono in altre parti della rete. Il vantaggio aggiuntivo è una singola procedura per la crittografia dell'archiviazione, non una per qualsiasi tecnologia utilizzata da una particolare funzione.

La crittografia dei dati inattivi può essere risolta con uno o tutti i seguenti:

  • Crittografa l'intero volume
  • Crittografa solo i file del database
  • Crittografa nell'applicazione

Il primo elemento può essere risolto con la crittografia del disco sul file system. È facile da configurare utilizzando LUKS e dm-crypt. Solo la prima e la seconda opzione sono necessarie per la conformità PCI DSS e altri requisiti di certificazione.

Auditing

Fondamentale per qualsiasi buon progetto di sicurezza è essere in grado di tracciare quale utente ha eseguito quale azione nel database (simile a come dovresti controllare i tuoi server effettivi). Il controllo consente di filtrare l'output di un particolare utente, database, raccolta o posizione di origine. Questo genera un registro per esaminare eventuali incidenti di sicurezza. Ancora più importante, mostra a qualsiasi revisore della sicurezza che hai eseguito i passaggi corretti per proteggere il tuo database da un'intrusione e per comprendere la profondità di qualsiasi intrusione nel caso si verificasse.

L'auditing ti consente di monitorare completamente le azioni di un intruso nel tuo ambiente.

Nota: l'audit è disponibile solo in MongoDB Enterprise. Non è nella versione Community. È disponibile in alcune altre versioni open source di MongoDB come Percona Server per MongoDB.