Fünf kritische MongoDB-Sicherheitskonfigurationen, die Sie jetzt implementieren müssen

Sichern Sie MongoDB mit Authentifizierung, Rollen mit minimalen Berechtigungen, Netzwerkbindung, TLS und Prüfung der Audit-Logs.

Fünf kritische MongoDB-Sicherheitskonfigurationen, die Sie jetzt umsetzen müssen

MongoDB-Sicherheitsprobleme beginnen meist mit einem einfachen Fehler: Eine Datenbank lauscht dort, wo sie nicht sollte, akzeptiert Benutzer, die sie nicht sollte, oder sendet Datenverkehr ohne Verschlüsselung. Ihre MongoDB-Konfiguration benötigt explizite Authentifizierung, enge Rollen, private Netzwerkexposition, TLS und nützliche Audit-Aufzeichnungen.

Diese Anleitung zeigt fünf Produktionsprüfungen, die die Wahrscheinlichkeit unbefugten Zugriffs verringern und verdächtige Aktivitäten leichter untersuchbar machen.


1. Verbindliche Zugriffskontrolle und starke Authentifizierung aktivieren

Stellen Sie zunächst sicher, dass die Autorisierung aktiviert ist. Ohne sie kann ein Client, der den Server erreicht, möglicherweise Daten lesen oder ändern, je nachdem, wie die Bereitstellung gestartet und konfiguriert wurde.

So aktivieren Sie die Authentifizierung

Die Authentifizierung wird normalerweise über die Konfigurationsdatei (mongod.conf) oder über Befehlszeilenflags beim Start aktiviert.

Konfigurationsdatei (/etc/mongod.conf):

# /etc/mongod.conf Ausschnitt
security:
  authorization: enabled

Befehlszeile:

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

Erstellen des Administrators

Erstellen Sie den ersten administrativen Benutzer, bevor Sie die Autorisierung aktivieren, oder nutzen Sie die Localhost-Ausnahme von MongoDB während der Ersteinrichtung. Nachdem der erste Benutzer existiert, starten Sie mit aktivierter Autorisierung neu und verwenden Sie benannte Konten für den gesamten Zugriff.

Beispiel: Erstellen des Root-Benutzers über mongosh

Stellen Sie zunächst eine Verbindung zur Datenbank her (wenn sie bereits ohne Authentifizierung läuft oder die Localhost-Ausnahme verwendet wird):

use admin
db.createUser(
  {
    user: "mongoAdmin",
    pwd: passwordPrompt(), // Fordert sicher zur Eingabe des Passworts auf
    roles: [ { role: "root", db: "admin" } ]
  }
)

Warnung: Verwenden Sie immer starke Passwörter, die in einem Secrets-Manager gespeichert sind. Hartcodieren Sie niemals sensible Anmeldeinformationen in Skripten oder Konfigurationsdateien.

2. Granulare rollenbasierte Zugriffskontrolle (RBAC) implementieren

Nach der Aktivierung der Authentifizierung besteht der nächste Schritt darin, das Prinzip der geringsten Privilegien (Principle of Least Privilege, PoLP) zu etablieren. Dies bedeutet, dass jeder Benutzer, jede Anwendung und jedes Dienstkonto nur die minimalen Berechtigungen besitzen sollte, die zur Ausführung seiner erforderlichen Aufgaben notwendig sind.

Vermeiden Sie die Verwendung der Rollen root oder readWriteAnyDatabase für Anwendungsverbindungen. Definieren Sie stattdessen benutzerdefinierte Rollen, die spezifische Berechtigungen für bestimmte Datenbanken oder Sammlungen gewähren.

Praktische RBAC-Schritte

  1. Benutzerdefinierte Rollen definieren: Wenn die integrierten Rollen (read, readWrite) nicht ausreichen, erstellen Sie Rollen mit feingranularen Zugriffsaktionen (z. B. nur insert und find für eine bestimmte Sammlung).
  2. Anwendungsbenutzer trennen: Erstellen Sie dedizierte Benutzer für verschiedene Anwendungsebenen (z. B. app_rw für das Backend, reporting_ro für Analysen).
  3. Zugriff externer Tools einschränken: Stellen Sie sicher, dass Verwaltungstools nur dann eine Verbindung mit privilegierten Konten herstellen, wenn dies unbedingt erforderlich ist.

Beispiel: Erstellen eines schreibgeschützten Benutzers für eine bestimmte Datenbank

use users_db
db.createUser(
  {
    user: "reporting_svc",
    pwd: passwordPrompt(),
    roles: [ { role: "read", db: "users_db" } ] // Nur Lesezugriff auf users_db
  }
)

3. Strikte Netzwerkbindung und Firewalls konfigurieren

Die Netzwerkkonfiguration ist die Perimeter-Verteidigung für Ihre Datenbank. Viele paketierte MongoDB-Installationen binden standardmäßig an localhost, aber Container-Images, benutzerdefinierte Befehlszeilen und kopierte Konfigurationsdateien können 0.0.0.0 exponieren. Überprüfen Sie immer die effektive bindIp, anstatt anzunehmen, dass der Standard sicher ist.

bindIp einschränken

Die primäre Sicherheitsmaßnahme ist die Definition der bindIp-Einstellung in Ihrer Konfigurationsdatei. Dies teilt MongoDB explizit mit, welche IP-Adressen oder Hostnamen es abhören soll.

Konfigurationsdatei (/etc/mongod.conf):

# Liste der IPs oder Hostnamen, an die gebunden werden soll
# Verwenden Sie 127.0.0.1 für lokalen Zugriff nur
# Verwenden Sie interne IP(s) für Zugriff nur von Anwendungsservern
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Externe Firewalls implementieren (Sicherheitsgruppen)

Zusätzlich zu bindIp (das den MongoDB-Prozess einschränkt) müssen Sie eine externe Firewall (wie iptables, AWS-Sicherheitsgruppen oder Azure-Netzwerksicherheitsgruppen) verwenden, um Datenverkehr zu filtern, bevor er den Server erreicht.

Best Practice: Erlauben Sie eingehenden Datenverkehr auf dem MongoDB-Port (Standard 27017) nur von Ihren Anwendungsservern, Load-Balancern und administrativen Jump-Hosts.

4. Verschlüsselung für Daten während der Übertragung (TLS) erzwingen

Daten, die zwischen Clients, Shells, Treibern und MongoDB übertragen werden, sollten mit Transport Layer Security (TLS) verschlüsselt werden. Das Senden von Anmeldeinformationen, Abfragen und Ergebnissen über unverschlüsselte Verbindungen setzt Daten Lauschangriffen und Man-in-the-Middle-Angriffen aus.

MongoDB unterstützt native TLS-Konfiguration sowohl für verschlüsselten Datenverkehr als auch für optionale Client-Zertifikatsvalidierung.

TLS aktivieren

Um die Verschlüsselung zu aktivieren, müssen Sie gültige TLS-Zertifikate generieren oder beschaffen und deren Speicherort in der Konfigurationsdatei angeben.

Konfigurationsdatei (/etc/mongod.conf):

net:
  tls:
    mode: requireTLS
    # Pfad zur kombinierten Zertifikats- und Schlüsseldatei
    certificateKeyFile: /etc/ssl/mongodb.pem
    # Pfad zur Zertifizierungsstellendatei (für Client-Validierung)
    CAFile: /etc/ssl/ca.pem

Client-Verbindung mit TLS

Sobald der Server TLS erfordert, müssen alle Clients die entsprechenden sicheren Flags verwenden, um eine Verbindung herzustellen:

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

Tipp: Verwenden Sie in der Produktion mode: requireTLS, um sicherzustellen, dass alle Verbindungen gesichert sind. Der Modus preferTLS wird in der Regel nur während der Migration oder beim Testen verwendet.

5. Auditierung aktivieren und Aktivitätsprotokolle überwachen

Selbst mit starker Zugriffskontrolle und Verschlüsselung können Sicherheitsbedrohungen von kompromittierten internen Konten oder Rechteausweitung ausgehen. Die Aktivierung einer umfassenden Auditierung bietet einen historischen Überblick über Aktionen, der für Compliance, forensische Analysen und die Erkennung verdächtigen Verhaltens entscheidend ist.

Die Audit-Funktion von MongoDB kann administrative Aktionen, Authentifizierungsversuche, Autorisierungsfehler und ausgewählte Datenoperationen protokollieren. Die Verfügbarkeit hängt von Ihrer MongoDB-Edition oder Plattform ab; zum Beispiel ist die Auditierung in MongoDB Enterprise und MongoDB Atlas verfügbar, während selbstverwaltete Community-Bereitstellungen andere Protokollierungs- und Überwachungsansätze benötigen.

Konfiguration für die Auditierung

Die Auditierung wird über den Abschnitt auditLog in der Konfigurationsdatei konfiguriert. Sie können das Ziel (Datei, Syslog, Konsole) und die Filterkriterien angeben.

Konfigurationsdatei (/etc/mongod.conf):

auditLog:
  destination: file
  path: /var/log/mongodb/audit.log
  format: JSON
  # Fokus auf wichtige Sicherheitsereignisse wie Authentifizierung und administrative Änderungen
  filter: '{ atype: { $in: [ "authenticate", "authCheck", "createCollection", "createUser", "dropDatabase" ] } }'

Wesentliche Überwachungsschwerpunkte

  • Fehlgeschlagene Authentifizierungsversuche: Ein plötzlicher Anstieg deutet auf einen möglichen Brute-Force-Angriff hin.
  • Benutzer-/Rollenerstellung/-löschung: Alle Berechtigungsänderungen müssen protokolliert und überprüft werden.
  • Löschen von Datenbanken oder Sammlungen: Für destruktive Operationen sind sofortige Warnungen erforderlich.

Integrieren Sie MongoDB-Audit-Logs in zentrale Log-Management-Systeme wie Splunk, den Elastic Stack oder Datadog für Warnmeldungen und Aufbewahrung.

Fazit

Überprüfen Sie diese fünf Kontrollen bei jeder MongoDB-Bereitstellung: Autorisierung ist aktiviert, Anwendungsbenutzer haben enge Rollen, bindIp und Firewalls schränken den Netzwerkzugriff ein, Clients benötigen TLS, und Sicherheitsereignisse fließen in Ihr Überwachungssystem. Diese Prüfungen ersetzen keine Backups, Patches oder den Geheimniswechsel, aber sie schließen zuerst die häufigsten Konfigurationslücken.