Cinque configurazioni critiche di sicurezza MongoDB che devi implementare subito

Cinque Configurazioni Critiche di Sicurezza di MongoDB che Devi Implementare Ora

MongDB è un database NoSQL documentale potente e flessibile utilizzato da milioni di sviluppatori e aziende in tutto il mondo. Tuttavia, la flessibilità e la facilità di implementazione che rendono MongoDB attraente possono anche portare a significative vulnerabilità di sicurezza se le impostazioni predefinite non vengono immediatamente rafforzate. Le prime versioni di MongoDB hanno spesso subito violazioni di dati pubbliche principalmente perché le impostazioni di sicurezza predefinite erano troppo permissive.

Proteggere la tua implementazione di MongoDB non è facoltativo; è fondamentale per mantenere l'integrità dei dati, la riservatezza e la conformità normativa. Questa guida illustra cinque passaggi di sicurezza non negoziabili che devono essere implementati in ogni ambiente MongoDB di produzione e pre-produzione per prevenire accessi non autorizzati e furti di dati. Implementando queste configurazioni, si passa da uno stato predefinito vulnerabile a un cluster di database robusto e protetto.

---

1. Abilitare il Controllo Accessi Obbligatorio e l'Autenticazione Robusta

Uno dei passaggi più critici per mettere in sicurezza MongoDB è garantire che l'autenticazione sia abilitata globalmente. Di default, molte implementazioni di MongoDB consentono connessioni senza credenziali a meno che non sia esplicitamente configurato diversamente. Questa pratica è intrinsecamente pericolosa.

Come Abilitare l'Autenticazione

L'autenticazione viene tipicamente abilitata tramite il file di configurazione (mongod.conf) o flag della riga di comando all'avvio.

File di Configurazione (/etc/mongod.conf):

# Snippet di /etc/mongod.conf
security:
  authorization: enabled

Riga di Comando:

mongod --auth --dbpath /var/lib/mongodb

Creazione dell'Utente Amministratore

Una volta abilitato il controllo degli accessi, è necessario creare un utente amministrativo con il ruolo userAdminAnyDatabase o root. È possibile creare questo utente solo prima che il servizio venga riavviato con --auth abilitato, o disabilitando temporaneamente l'autenticazione per la fase di creazione iniziale se il sistema è già in esecuzione.

Esempio: Creazione dell'Utente Root tramite mongosh

Innanzitutto, connettersi al database (se è già in esecuzione senza autenticazione, o utilizzando l'eccezione localhost):

use admin
db.createUser(
  {
    user: "mongoAdmin",
    pwd: passwordPrompt(), // Richiede la password in modo sicuro
    roles: [ { role: "root", db: "admin" } ]
  }
)

⚠️ Attenzione: Utilizzare sempre password complesse e robuste memorizzate in modo sicuro tramite un gestore di segreti. Non codificare mai credenziali sensibili in script o file di configurazione.

2. Implementare il Controllo degli Accessi Basato sui Ruoli (RBAC) Granulare

Dopo aver abilitato l'autenticazione, il passo successivo è stabilire il Principio del Minimo Privilegio (PoLP). Ciò significa che ogni utente, applicazione e account di servizio dovrebbe avere solo le autorizzazioni minime necessarie per eseguire le attività richieste.

Evitare di utilizzare i ruoli root o readWriteAnyDatabase per le connessioni applicative. Definire invece ruoli personalizzati che concedano autorizzazioni specifiche su database o raccolte specifiche.

Passaggi Pratici di RBAC

1. Definire Ruoli Personalizzati: Se i ruoli integrati (read, readWrite) sono insufficienti, creare ruoli con azioni di accesso granulari (ad esempio, solo insert e find su una raccolta specifica).
2. Separare gli Utenti Applicativi: Creare utenti dedicati per diversi livelli applicativi (ad esempio, app_rw per il backend, reporting_ro per l'analisi).
3. Limitare l'Accesso agli Strumenti Esterni: Assicurarsi che gli strumenti di amministrazione si connettano utilizzando account privilegiati solo quando assolutamente necessario.

Esempio: Creazione di un Utente Sola Lettura per un Database Specifico

use users_db
db.createUser(
  {
    user: "reporting_svc",
    pwd: passwordPrompt(),
    roles: [ { role: "read", db: "users_db" } ] // Solo accesso in lettura a users_db
  }
)

3. Configurare il Binding di Rete Rigoroso e i Firewall

La configurazione di rete è la difesa perimetrale del tuo database. Di default, MongoDB spesso si collega a tutte le interfacce di rete disponibili (0.0.0.0), rendendolo potenzialmente accessibile all'intera rete o, peggio, a Internet se in esecuzione su un'istanza cloud senza regole firewall adeguate.

Limitare bindIp

La misura di sicurezza principale è definire l'impostazione bindIp nel file di configurazione. Questo dice esplicitamente a MongoDB su quali indirizzi IP o hostname deve ascoltare.

File di Configurazione (/etc/mongod.conf):

# Elenco di IP o hostname a cui collegarsi
# Usare 127.0.0.1 per accesso locale soltanto
# Usare IP interni per accesso solo dai server applicativi
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Implementare Firewall Esterni (Gruppi di Sicurezza)

Oltre a bindIp (che limita il processo MongoDB), è necessario utilizzare un firewall esterno (come iptables, AWS Security Groups o Azure Network Security Groups) per filtrare il traffico prima che raggiunga il server.

Pratica Consigliata: Consentire il traffico in ingresso sulla porta MongoDB (default 27017) solo dai server applicativi, dai bilanciatori di carico e dalle jump box amministrative.

4. Impostare la Crittografia per i Dati in Transito (TLS/SSL)

I dati trasmessi tra i client (applicazioni, shell, driver) e il server MongoDB devono essere crittografati utilizzando Transport Layer Security (TLS) o Secure Sockets Layer (SSL). L'invio di credenziali, query e risultati su connessioni non crittografate espone i dati a potenziali intercettazioni (attacchi man-in-the-middle).

MongDB supporta la configurazione nativa TLS/SSL sia per la crittografia del traffico sia per la validazione opzionale del certificato client.

Abilitazione di TLS/SSL

Per abilitare la crittografia, è necessario generare o ottenere certificati TLS validi e specificarne la posizione nel file di configurazione.

File di Configurazione (/etc/mongod.conf):

net:
  ssl:
    mode: requireTLS
    # Percorso del file combinato di certificato e chiave
    serverCertificateKeyFile: /etc/ssl/mongodb.pem
    # Percorso del file dell'Autorità di Certificazione (per la validazione client)
    CAFile: /etc/ssl/ca.pem

Connessione Client con TLS

Una volta che il server richiede TLS, tutti i client devono connettersi utilizzando i flag sicuri appropriati:

mongosh "mongodb://[email protected]/admin?authSource=admin" --tls --tlsCAFile /path/to/ca.pem

Suggerimento: Utilizzare mode: requireTLS in produzione per garantire che tutte le connessioni siano protette. La modalità preferTLS viene generalmente utilizzata solo durante la migrazione o i test.

5. Abilitare l'Audit e Monitorare i Log di Attività

Anche con un controllo degli accessi rigoroso e la crittografia, le minacce alla sicurezza possono derivare da account interni compromessi o dall'escalation dei privilegi. L'abilitazione di un auditing completo fornisce una registrazione storica delle azioni, fondamentale per la conformità, l'analisi forense e il rilevamento di comportamenti sospetti.

La Funzionalità di Auditing di MongoDB può registrare azioni amministrative, tentativi di autenticazione, tentativi di accesso non autorizzato e potenzialmente letture/scritture di dati.

Configurazione per l'Auditing

L'auditing è configurato tramite la sezione auditLog nel file di configurazione. È possibile specificare la destinazione (file, syslog, console) e i criteri di filtro.

File di Configurazione (/etc/mongod.conf):

auditLog:
  destination: file
  path: /var/log/mongodb/audit.log
  format: JSON
  # Concentrarsi sugli eventi di sicurezza chiave come autenticazione e modifiche amministrative
  filter: '{ atype: { $in: [ "authenticate", "authorize", "createCollection", "createUser", "dropDatabase" ] } }'

Aree di Monitoraggio Essenziali

• Tentativi di Autenticazione Falliti: Un picco improvviso indica un potenziale attacco di forza bruta.
• Creazione/Eliminazione di Utenti/Ruoli: Tutte le modifiche ai privilegi devono essere registrate e revisionate.
• Eliminazione di Database o Raccolte: Sono necessari avvisi immediati per le operazioni distruttive.

Integrare i log di audit di MongoDB con sistemi centralizzati di gestione dei log (ad esempio, Splunk, ELK Stack, DataDog) per avvisi in tempo reale e conservazione a lungo termine.

Conclusione

L'implementazione di queste cinque configurazioni critiche porta la tua implementazione MongoDB da uno stato di vulnerabilità a uno di resilienza. La sicurezza in MongoDB non è un compito da impostare e dimenticare; è un processo continuo. Assicurati che queste configurazioni — autenticazione obbligatoria, RBAC granulare, binding di rete rigoroso, crittografia TLS e auditing completo — siano verificate durante ogni implementazione e riviste regolarmente. Dare priorità a questi passaggi mitigherà significativamente il rischio di accesso non autorizzato e di compromissione dei dati.