Sicurezza MongoDB 101: funzionalità fondamentali che ogni developer dovrebbe conoscere

MongoDB offre un framework di sicurezza completo basato su tre principi fondamentali: autenticazione, autorizzazione e crittografia.

Questi pilastri formano una difesa stratificata, garantendo che un singolo malfunzionamento non comprometta l’intero sistema. Il pilastro dell’autorizzazione è guidato dal principio del privilegio minimo (PoLP), assicurando che ogni utente o applicazione disponga solo dei permessi minimi necessari per svolgere i propri compiti. 

Implementare questo approccio completo e stratificato rafforza la tua postura di sicurezza complessiva e riduce significativamente l’esposizione a configurazioni errate o violazioni. 

Abilitare il primo varco: autenticazione

L’autenticazione è il primo passo fondamentale di sicurezza. Verifica l’identità di ogni entità che tenta di connettersi. In MongoDB, si ottiene abilitando le funzionalità di sicurezza che, per praticità nello sviluppo locale, sono disabilitate per impostazione predefinita.

1. Comprendere la configurazione predefinita

Per impostazione predefinita, il tuo deployment MongoDB ascolta solo su localhost e consente l’accesso senza autenticazione. Questa configurazione è intenzionale e offre la massima semplicità per l’installazione iniziale e gli esperimenti in locale.

Per qualsiasi deployment in produzione, due impostazioni richiedono l’attenzione degli sviluppatori:

• Stato dell’autenticazione: L’autenticazione è disabilitata per impostazione predefinita. Puoi abilitare l’autorizzazione usando l’opzione --auth o l’impostazione security.authorization. Abilitare l’autenticazione interna abilita anche l’autorizzazione client. Nota: una volta abilitato il controllo degli accessi, gli utenti devono autenticarsi.
• Associazione di rete (bindIp): Per impostazione predefinita, i binari di MongoDB (mongod e mongos) si associano solo a localhost. Questo default sicuro limita le connessioni alla stessa macchina. In ambienti di produzione, devi configurare esplicitamente l’impostazione bindIp per elencare gli indirizzi IP dei tuoi application server autorizzati. Se hai bisogno del supporto IPv6, puoi impostare il parametro di configurazione net.ipv6 nel file di configurazione o l’opzione da riga di comando --ipv6, che farà sì che il binario si associ anche all’indirizzo IPv6 di localhost. Restringi sempre questa impostazione alle interfacce di rete autorizzate.

2. Come abilitare l’autenticazione

Abilitare l’autenticazione trasforma MongoDB da un ambiente di prova locale a un archivio dati sicuro. Si fa modificando il file di configurazione di MongoDB (in genere mongod.conf) e riavviando il server.

Impostazione nel file di configurazione: imposta l’opzione di autorizzazione nella sezione security per abilitare la funzionalità:

  authorization: enabled

Il primo utente: una volta abilitata l’autenticazione, nessuno può connettersi finché non crei un utente amministrativo. Questo primo utente, fondamentale, deve essere creato nel database admin, conferendogli i diritti iniziali necessari per gestire il sistema e creare altri utenti.

3. Gestione di utenti e password (createUser)

Dopo aver abilitato l’autorizzazione, tutto l’accesso al database è regolato da utenti e relativi ruoli. Usi il comando createUser per definire queste identità.

Sintassi e ruoli: quando crei un utente, specifichi username, password e un array di ruoli. I ruoli definiscono i permessi (ad es. readWrite su un database specifico).

db.createUser(
   {
     user: "appUser",
     pwd: passwordPrompt(),  // Questo metodo chiede una password e 
                                              // evita di memorizzare la password in chiaro nella 
                                              // cronologia della shell e nei log dei comandi.
     roles: [ { role: "readWrite", db: "inventory" } ]
   }
)

Standard SCRAM: MongoDB si basa sul Salted Challenge Response Authentication Mechanism (SCRAM) per gestire le password in modo sicuro. SCRAM evita di memorizzare password in chiaro e usa hashing e salting crittograficamente robusti, rendendolo resistente a vettori d’attacco comuni come le rainbow table.

4. Opzioni avanzate di autenticazione

Per organizzazioni con requisiti di compliance stringenti o infrastrutture complesse, MongoDB offre l’integrazione con sistemi di autenticazione enterprise esistenti:

• Certificati client x.509: consentono ai client di autenticarsi con certificati digitali invece che con password, aggiungendo un solido livello di verifica dell’identità, spesso usato per la fiducia machine-to-machine.
• LDAP/Kerberos: integra MongoDB con servizi esterni come Active Directory o OpenLDAP, permettendo agli utenti di usare le credenziali aziendali esistenti per l’accesso al database.
• Autenticazione OpenID Connect (OIDC) - Workforce e Workloads: per ambienti cloud-native e ibridi moderni, MongoDB supporta la federazione delle identità sia per la Workforce (accesso utente tramite IdP come Azure AD, Okta) sia per i Workload (autenticazione machine-to-machine usando l’identità del cloud provider, ad es. AWS IAM o Google Cloud Service Accounts).

Autorizzazione: definire i ruoli con RBAC

L’autenticazione conferma chi è un utente; l’autorizzazione determina cosa quell’utente è autorizzato a fare. Il sistema di Role-Based Access Control (RBAC) di MongoDB è il meccanismo centrale per gestire i permessi, assicurando che utenti e servizi interagiscano solo con i dati e i comandi strettamente necessari.

1. Controllo degli accessi basato sui ruoli

Nel modello RBAC di MongoDB, i permessi sono raggruppati in ruoli e questi ruoli sono assegnati agli utenti. Invece di assegnare centinaia di permessi singoli, assegni un unico ruolo (ad es. inventoryReader), che include automaticamente il set di permessi definiti (ad es. read su inventory.products). Questo rende la gestione dei permessi scalabile e verificabile.

2. Ruoli predefiniti di cui ogni developer ha bisogno

MongoDB fornisce un set solido di ruoli predefiniti che coprono i pattern di accesso più comuni. Di seguito alcuni esempi. Per l’elenco completo, fai riferimento al link sopra.

• read e readWrite (accesso a livello di database): sono i ruoli più comuni per gli utenti applicativi. Concedono rispettivamente l’accesso in sola lettura o lettura/scrittura su tutte le raccolte non di sistema all’interno di un database specifico.
• dbAdmin: concede i diritti amministrativi necessari per gestire un database specifico, come creare, eliminare e modificare indici e raccolte. È adatto per team di sviluppo o script di manutenzione del database.
• clusterAdmin (accesso operativo): è un ruolo ad alto privilegio generalmente riservato al personale operativo (DevOps/Ops). Concede i permessi necessari per gestire l’intero deployment MongoDB, inclusa la configurazione di replica set, sharding ed esecuzione di backup. Gli sviluppatori applicativi raramente hanno bisogno di questo ruolo.

3. Applicare il principio del privilegio minimo

La pietra angolare della sicurezza moderna dei database è il principio del privilegio minimo (PoLP). Stabilisce che ogni utente (specialmente quelli applicativi) debba ottenere solo i permessi minimi necessari per svolgere le attività richieste, e nulla di più.

Ecco un esempio di best practice: invece di usare un utente readWrite globale, crea utenti specifici per l’applicazione. Ad esempio, se il tuo servizio di inventario interagisce solo con il database app_data, l’utente dell’applicazione dovrebbe avere accesso readWrite solo a quel singolo database. Questa compartimentazione impedisce a un servizio compromesso di ottenere accessi non autorizzati ad altri database (come billing o users).

Esempio di codice: creazione di un utente a privilegio minimo

Questo esempio crea un utente (inventory_service) con accesso in lettura/scrittura limitato strettamente al database app_data.

use admin
db.createUser(
   {
     user: "inventory_service",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "app_data" }
     ]
   }
)

4. Creare ruoli personalizzati (quando i predefiniti non bastano)

Sebbene i ruoli predefiniti siano potenti, esigenze di compliance o logiche applicative complesse possono richiedere un controllo molto granulare. In questi casi, MongoDB ti permette di definire ruoli personalizzati usando il comando db.createRole().

Definire permessi granulari: i ruoli personalizzati consentono di specificare esattamente quali azioni privilegiate (ad es. find, update, insert) possono essere eseguite su risorse con ambito di cluster, database o raccolta. Le organizzazioni possono sfruttare tecniche come la redazione a livello di campo per proteggere campi altamente sensibili all’interno di una raccolta altrimenti pubblica.

Esempio di codice: creazione di un ruolo personalizzato

Questo esempio crea un ruolo personalizzato (product_creator) che può solo inserire documenti nella raccolta products all’interno del database app_data.

use app_data
db.createRole(
   {
     role: "product_creator",
     privileges: [
       {
         resource: { db: "app_data", collection: "products" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)

Protezione completa dei dati: isolamento di rete e crittografia

Sebbene autenticazione e autorizzazione forti controllino l’accesso al database, una sicurezza completa richiede di proteggere i dati stessi—sia quando viaggiano in rete (in transito) sia quando sono archiviati su disco (a riposo).

1. Proteggere i dati in transito con TLS/SSL

La trasmissione dei dati su qualsiasi rete, sia interna a un data center sia esterna verso il cloud, deve essere crittografata per prevenire intercettazioni e attacchi man-in-the-middle (MITM). MongoDB usa Transport Layer Security/Secure Sockets Layer (TLS/SSL) per crittografare tutte le comunicazioni tra i client (come la tua applicazione) e il server.

Senza TLS/SSL, credenziali utente, parametri di query e risultati sensibili vengono trasmessi in chiaro, rendendone banale l’intercettazione. Abilitare TLS/SSL assicura che i dati siano offuscati e protetti durante la trasmissione.

Abilitare TLS/SSL: si fa principalmente tramite impostazioni di configurazione, dove specifichi i certificati che il server deve usare per la verifica dell’identità e lo scambio delle chiavi di crittografia:

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem

• net.ssl.mode: requireTLS impone che tutte le connessioni in ingresso usino TLS/SSL, rifiutando i tentativi insicuri.
• certificateKeyFile punta rispettivamente al certificato TLS/SSL generato e al file della Certificate Authority.

2. Firewall e segmentazione della rete

La segmentazione della rete fornisce un livello di difesa cruciale limitando le interfacce fisiche o virtuali che possono connettersi al database. Anche se un attaccante ottiene accesso alla rete, dovrà comunque superare il tuo perimetro.

• Limitare l’accesso tramite whitelist di IP: usando l’impostazione bindIp o configurando i firewall di rete, puoi mettere in whitelist indirizzi IP specifici.
• Best practice: il server MongoDB dovrebbe essere esposto solo ai tuoi application server, al load balancer o al livello proxy. Non dovrebbe mai essere direttamente accessibile da internet pubblica. Questa segmentazione assicura che il database sia protetto dietro il perimetro di sicurezza dell’infrastruttura applicativa.

3. Crittografia a riposo (crittografia del motore di archiviazione)

Proteggere i dati a riposo garantisce che, se il disco fisico o l’host vengono compromessi, i file restino illeggibili. MongoDB lo realizza tramite la crittografia del motore di archiviazione.

• Come funziona: il motore di archiviazione WiredTiger può essere configurato per crittografare tutti i file di dati, di configurazione e di journal su disco. I dati vengono crittografati in modo trasparente in scrittura e decrittati in lettura, usando una chiave di cifratura gestita dal sistema.
• Considerazione cruciale: sebbene sia un livello di sicurezza fondamentale, la crittografia nativa a riposo è tipicamente una funzionalità di MongoDB Enterprise e si affida a server KMIP (Key Management Interoperability Protocol) esterni o a file di chiavi locali per la gestione delle chiavi di cifratura.

4. Crittografia lato client a livello di campo (CSFLE): il gold standard per gli sviluppatori

Mentre la crittografia a riposo protegge l’intero database, la Client-Side Field Level Encryption (CSFLE) offre allo sviluppatore un controllo di precisione sui dati sensibili, permettendo di crittografare campi specifici prima che vengano inviati al database.

• Introduzione a CSFLE: con CSFLE, la crittografia avviene all’interno del driver dell’applicazione prima che i dati lascino il server applicativo. Ciò significa che il server MongoDB non vede mai i dati sensibili in chiaro; memorizza solo il ciphertext. I dati sensibili restano sempre crittografati sul server, inclusi memoria, log del server e storage.
• Lo strumento più potente per gli sviluppatori: CSFLE è il gold standard per la compliance (ad es. GDPR, HIPAA), poiché assicura che, anche in caso di violazione totale del database, i campi sensibili (come PII o dati finanziari) restino crittografati e protetti. Gli sviluppatori devono decidere attivamente cosa crittografare, integrando la logica di cifratura direttamente nel codice dell’applicazione.

5. Crittografia in uso con Queryable Encryption

Queryable Encryption è un’evoluzione di CSFLE che affronta la sfida di interrogare campi crittografati. Consente alle applicazioni di eseguire query di uguaglianza (ad es. trovare documenti in cui un campo crittografato è uguale a un certo valore) direttamente sul ciphertext. Offre la sicurezza di CSFLE mantenendo l’utilità dei dati, di fatto crittografandoli durante l’uso.

Audit: lo strumento per il post-mortem

Le misure di sicurezza riguardano la prevenzione, ma l’audit riguarda la responsabilità e il rilevamento. Il framework di auditing integrato di MongoDB offre la capacità cruciale di tracciare e registrare gli eventi rilevanti per la sicurezza, fornendo un registro immutabile essenziale per forense, compliance e rilevamento proattivo delle minacce.

1. Che cos’è l’auditing e perché è importante?

L’audit registra ogni azione critica eseguita sul database, creando uno storico dettagliato. Include:

• Eventi di autenticazione: tentativi di accesso riusciti e falliti.
• Modifiche di autorizzazione: creazione, modifica o eliminazione di utenti e ruoli.
• Modifiche di configurazione: modifiche ai parametri di sistema che influiscono sulla sicurezza.

Questo log è inestimabile per i team di sicurezza che eseguono analisi post-incidente (lo strumento "post-mortem") o per soddisfare i requisiti normativi.

2. Configurazione e filtraggio

Abilitare l’audit è semplice e spesso richiede una sola riga nel file di configurazione per attivare il sistema e specificare la destinazione del log (file, syslog o console).

auditLog:
  destination: file
  format: BSON
  path: /var/log/mongodb/audit.bson
  filter: '{ atype: { $in: [ "authenticate", "createRole", "dropUser" ] } }'

• Filtraggio: il sistema di audit consente un filtraggio altamente granulare usando una sintassi tipo query. Questo è fondamentale per gestire il volume dei log. Gli sviluppatori dovrebbero concentrare il filtro sugli eventi critici e rilevanti per la sicurezza, come le azioni di gestione utenti, le modifiche alla configurazione di sicurezza e i tentativi di autenticazione.

Riepilogo e prossimi passi

MongoDB fornisce una suite completa di funzionalità di sicurezza che, se distribuite correttamente, creano una potente strategia di difesa in profondità. Il tuo compito principale come developer è andare oltre i default di sviluppo e implementare questi controlli di base.

Prima che qualsiasi applicazione vada in produzione, ricordati questi tre mandati di sicurezza fondamentali:

• Cifra i dati in transito: usa TLS/SSL per tutte le connessioni di rete (net.ssl.mode: requireTLS).
• Cifra i dati a riposo: assicurati che i file del database su disco siano protetti usando la crittografia a livello di volume o filesystem, oppure la crittografia del motore di archiviazione WiredTiger di MongoDB (disponibile in MongoDB Enterprise) per proteggere dall’accesso non autorizzato ai file del database.
• Cifra i dati in uso: usa la Client-Side Field Level Encryption (CSFLE) e la Queryable Encryption per i campi altamente sensibili, assicurando che i dati restino crittografati anche mentre il database è in esecuzione.

La sicurezza è una disciplina in evoluzione. Per approfondimenti e configurazioni avanzate, utilizza la documentazione ufficiale:

• MongoDB Security center: esplora le guide per il rafforzamento dei deployment e le pratiche di sicurezza operativa.
• Documentazione sulla crittografia in uso: scopri come implementare la Client-Side Field Level Encryption (CSFLE) e la sua funzionalità avanzata, e la Queryable Encryption (QE), per garantire che i dati sensibili restino confidenziali e possano comunque essere interrogati in modo efficiente mentre sono in uso.

Ti consiglio anche di dare un’occhiata al corso Introduction to Using MongoDB for Data Science in Python.