Cinque Configurazioni di Sicurezza Critiche per MongoDB da Implementare Ora

I problemi di sicurezza di MongoDB di solito iniziano con un semplice errore: un database ascolta dove non dovrebbe, accetta utenti che non dovrebbe o invia traffico senza crittografia. La tua configurazione di MongoDB necessita di autenticazione esplicita, ruoli ristretti, esposizione di rete privata, TLS e registri di audit utili.

Questa guida mostra cinque controlli di produzione che riducono la possibilità di accesso non autorizzato e rendono più facile indagare su attività sospette.

---

1. Abilita il Controllo degli Accessi Obbligatorio e l'Autenticazione Forte

Inizia assicurandoti che l'autorizzazione sia abilitata. Senza di essa, un client che può raggiungere il server potrebbe essere in grado di leggere o modificare i dati a seconda di come è stato avviato e configurato il deployment.

Come Abilitare l'Autenticazione

L'autenticazione è tipicamente abilitata tramite il file di configurazione (mongod.conf) o i flag della riga di comando durante l'avvio.

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

# Estratto da /etc/mongod.conf
security:
  authorization: enabled

Riga di Comando:

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

Creazione dell'Utente Amministratore

Crea il primo utente amministrativo prima di abilitare l'autorizzazione o utilizza l'eccezione localhost di MongoDB durante la configurazione iniziale. Dopo che il primo utente esiste, riavvia con l'autorizzazione abilitata e utilizza account nominativi per tutti gli accessi.

Esempio: Creazione dell'Utente Root tramite mongosh

Prima, connettiti 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: Utilizza sempre password forti memorizzate in un gestore di segreti. Non codificare mai credenziali sensibili in script o file di configurazione.

2. Implementa 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 i permessi minimi necessari per svolgere i propri compiti.

Evita di utilizzare i ruoli root o readWriteAnyDatabase per le connessioni delle applicazioni. Invece, definisci ruoli personalizzati che concedono permessi specifici su database o collezioni specifici.

Passi Pratici per RBAC

1. Definisci Ruoli Personalizzati: Se i ruoli incorporati (read, readWrite) sono insufficienti, crea ruoli con azioni di accesso granulari (ad esempio, solo insert e find su una collezione specifica).
2. Separa gli Utenti dell'Applicazione: Crea utenti dedicati per diversi livelli dell'applicazione (ad esempio, app_rw per il backend, reporting_ro per l'analisi).
3. Limita l'Accesso degli Strumenti Esterni: Assicurati che gli strumenti di amministrazione si connettano utilizzando account privilegiati solo quando assolutamente necessario.

Esempio: Creazione di un Utente di 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. Configura Binding di Rete e Firewall Rigorosi

La configurazione di rete è la difesa perimetrale per il tuo database. Molte installazioni MongoDB preconfezionate si legano a localhost per impostazione predefinita, ma le immagini dei container, le righe di comando personalizzate e i file di configurazione copiati possono esporre 0.0.0.0. Verifica sempre il bindIp effettivo invece di presumere che l'impostazione predefinita sia sicura.

Restringi bindIp

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

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

# Elenco di IP o nomi host a cui associarsi
# Usa 127.0.0.1 per il solo accesso locale
# Usa IP interni per l'accesso solo dai server applicativi
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Implementa Firewall Esterni (Gruppi di Sicurezza)

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

Buona Pratica: Consenti il traffico in entrata solo sulla porta MongoDB (predefinita 27017) dai tuoi server applicativi, bilanciatori di carico e jump box amministrativi.

4. Applica la Crittografia per i Dati in Transito (TLS)

I dati trasmessi tra client, shell, driver e MongoDB dovrebbero essere crittografati con Transport Layer Security (TLS). L'invio di credenziali, query e risultati su connessioni non crittografate espone i dati a intercettazioni e attacchi man-in-the-middle.

MongoDB supporta la configurazione TLS nativa sia per il traffico crittografato che per la convalida opzionale del certificato client.

Abilitazione di TLS

Per abilitare la crittografia, devi generare o ottenere certificati TLS validi e specificare la loro posizione nel file di configurazione.

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

net:
  tls:
    mode: requireTLS
    # Percorso del file combinato certificato e chiave
    certificateKeyFile: /etc/ssl/mongodb.pem
    # Percorso del file dell'Autorità di Certificazione (per la convalida del 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: Usa mode: requireTLS in produzione per garantire che tutte le connessioni siano sicure. La modalità preferTLS è generalmente utilizzata solo durante la migrazione o i test.

5. Abilita l'Audit e Monitora i Log delle Attività

Anche con un forte controllo degli accessi e la crittografia, le minacce alla sicurezza possono derivare da account interni compromessi o escalation dei privilegi. Abilitare un audit completo fornisce una registrazione storica delle azioni, che è cruciale per la conformità, l'analisi forense e il rilevamento di comportamenti sospetti.

La funzionalità di audit di MongoDB può registrare azioni amministrative, tentativi di autenticazione, fallimenti di autorizzazione e operazioni sui dati selezionate. La disponibilità dipende dall'edizione o dalla piattaforma MongoDB; ad esempio, l'audit è disponibile in MongoDB Enterprise e MongoDB Atlas, mentre i deployment Community auto-gestiti necessitano di altri approcci di logging e monitoraggio.

Configurazione per l'Audit

L'audit è configurato tramite la sezione auditLog nel file di configurazione. Puoi 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
  # Concentrati sugli eventi di sicurezza chiave come autenticazione e modifiche amministrative
  filter: '{ atype: { $in: [ "authenticate", "authCheck", "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 riviste.
• Eliminazione di Database o Collezioni: Sono necessari avvisi immediati per operazioni distruttive.

Integra i log di audit di MongoDB con sistemi di gestione dei log centralizzati come Splunk, Elastic Stack o Datadog per avvisi e conservazione.

Conclusione

Rivedi questi cinque controlli durante ogni deployment di MongoDB: l'autorizzazione è abilitata, gli utenti dell'applicazione hanno ruoli ristretti, bindIp e i firewall limitano l'accesso di rete, i client richiedono TLS e gli eventi di sicurezza fluiscono nel tuo sistema di monitoraggio. Questi controlli non sostituiscono backup, patch o rotazione dei segreti, ma chiudono prima le lacune di configurazione più comuni.