MongoDB Security 101: Kernfunktionen, die jede Entwicklerin und jeder Entwickler kennen sollte

MongoDB stellt ein umfassendes Sicherheitsframework bereit, das auf drei Grundprinzipien beruht: Authentifizierung, Autorisierung und Verschlüsselung.

Diese Säulen bilden eine mehrschichtige Verteidigung, sodass ein einzelner Ausfall nicht das gesamte System kompromittiert. Die Autorisierung folgt dem Prinzip der geringsten Rechte (PoLP) und stellt sicher, dass jede Nutzerin, jeder Nutzer oder jede Anwendung nur die minimal nötigen Berechtigungen erhält.

Die Umsetzung dieses ganzheitlichen, mehrschichtigen Ansatzes stärkt deine Sicherheitslage erheblich und reduziert das Risiko durch Fehlkonfigurationen oder Sicherheitsvorfälle.

Das erste Tor öffnen: Authentifizierung

Authentifizierung ist der grundlegende Sicherheitsstep. Sie verifiziert die Identität jedes Principals, der eine Verbindung herstellen will. In MongoDB geschieht dies, indem du Sicherheitsfunktionen aktivierst, die für die lokale Entwicklung standardmäßig deaktiviert sind.

1. Die Standardkonfiguration verstehen

Standardmäßig lauscht deine MongoDB-Installation nur auf localhost und erlaubt nicht authentifizierten Zugriff. Diese Konfiguration ist beabsichtigt und erleichtert das erste Setup und lokale Experimente.

Für jede Produktionsumgebung brauchen zwei Einstellungen besondere Aufmerksamkeit:

• Authentifizierungsstatus: Die Authentifizierung ist standardmäßig deaktiviert. Du kannst die Autorisierung über --auth oder die Einstellung security.authorization aktivieren. Das Aktivieren der internen Authentifizierung aktiviert auch die Client-Autorisierung. Beachte: Sobald die Zugriffskontrolle aktiv ist, müssen sich Nutzerinnen und Nutzer authentifizieren.
• Netzwerk-Bindung (bindIp): Standardmäßig binden die MongoDB-Binaries (mongod und mongos) nur an localhost. Dieser sichere Standard beschränkt Verbindungen auf die gleiche Maschine. In Produktionsumgebungen musst du die Einstellung bindIp explizit so konfigurieren, dass die IP-Adressen deiner autorisierten Anwendungsserver gelistet sind. Falls du IPv6 benötigst, kannst du die Konfigurationsdatei-Einstellung net.ipv6 oder die Kommandozeilenoption --ipv6 setzen; dadurch bindet der Prozess zusätzlich an die localhost-IPv6-Adresse. Beschränke das stets auf autorisierte Netzwerkschnittstellen.

2. So aktivierst du die Authentifizierung

Durch das Aktivieren der Authentifizierung wird MongoDB vom lokalen Spielplatz zum sicheren Datenspeicher. Dazu änderst du die MongoDB-Konfigurationsdatei (typischerweise mongod.conf) und startest den Server neu.

Einstellung in der Konfigurationsdatei: Setze die Autorisierungsoption im Abschnitt security, um die Funktion zu aktivieren:

  authorization: enabled

Der erste User: Sobald die Authentifizierung aktiv ist, kann niemand verbinden, bis du einen administrativen Nutzer anlegst. Dieser erste, kritische User muss in der Datenbank admin erstellt werden und erhält die anfänglichen Rechte, um das System zu verwalten und weitere Nutzer anzulegen.

3. Nutzer- und Passwortverwaltung (createUser)

Nach dem Aktivieren der Autorisierung wird jeder Datenbankzugriff über Nutzer und deren zugeordnete Rollen gesteuert. Du verwendest den Befehl createUser, um diese Identitäten zu definieren.

Syntax und Rollen: Beim Anlegen eines Nutzers gibst du Benutzername, Passwort und ein Array von Rollen an. Rollen definieren die Berechtigungen (z. B. readWrite auf einer bestimmten Datenbank).

db.createUser(
   {
     user: "appUser",
     pwd: passwordPrompt(),  // This function prompts for a password, which 
                                              // avoids storing the plain-text password in 
                                              // shell history and command logs.
     roles: [ { role: "readWrite", db: "inventory" } ]
   }
)

SCRAM-Standard: MongoDB setzt auf den Salted Challenge Response Authentication Mechanism (SCRAM), um Passwörter sicher zu handhaben. SCRAM speichert keine Klartext-Passwörter, sondern nutzt kryptographisch starke Hashing- und Salting-Verfahren und ist damit robust gegen gängige Angriffsvektoren wie Rainbow-Table-Angriffe.

4. Erweiterte Authentifizierungsoptionen

Für Organisationen mit strengen Compliance-Vorgaben oder komplexer Infrastruktur bietet MongoDB Integrationen mit bestehenden Enterprise-Authentifizierungssystemen:

• x.509-Clientzertifikate: Ermöglichen die Authentifizierung per digitalen Zertifikaten statt Passwörtern und bieten eine robuste Identitätsprüfung, oft genutzt für Machine-to-Machine-Trust.
• LDAP/Kerberos: Integriert MongoDB mit externen Diensten wie Active Directory oder OpenLDAP, sodass Nutzer ihre bestehenden Unternehmens-Credentials für den Datenbankzugriff verwenden können.
• OpenID Connect (OIDC) Authentication – Workforce und Workloads: Für moderne Cloud-native und hybride Umgebungen unterstützt MongoDB Identity Federation sowohl für Workforce (Nutzerzugriff über IdPs wie Azure AD, Okta) als auch Workload (Machine-to-Machine-Authentifizierung per Cloud-Provider-Identität, z. B. AWS IAM oder Google Cloud Service Accounts).

Autorisierung: Rollen mit RBAC definieren

Authentifizierung bestätigt, wer jemand ist; Autorisierung bestimmt, was diese Person tun darf. Das Role-Based Access Control (RBAC) von MongoDB ist der zentrale Mechanismus für die Rechtevergabe, damit Nutzer und Services nur mit den Daten und Befehlen arbeiten, die sie wirklich benötigen.

1. Rollenbasierte Zugriffskontrolle

Im RBAC-Modell von MongoDB werden Berechtigungen in Rollen gebündelt und diese Rollen den Nutzern zugewiesen. Statt hunderte Einzelberechtigungen zu vergeben, weist du eine Rolle zu (z. B. inventoryReader), die bereits den passenden Satz an Rechten enthält (z. B. read auf inventory.products). So wird Berechtigungsmanagement skalierbar und prüfbar.

2. Integrierte Rollen, die jede Entwicklerin und jeder Entwickler braucht

MongoDB stellt einen leistungsfähigen Satz an vordefinierten Rollen bereit, die die häufigsten Zugriffsmuster abdecken. Hier ein paar Beispiele; die vollständige Liste findest du über den Link oben.

• read und readWrite (Datenbankebene): Die gängigsten Rollen für Anwendungsnutzer. Sie gewähren Lese- bzw. Lese-/Schreibzugriff auf alle Nicht-System-Collections innerhalb einer angegebenen Datenbank.
• dbAdmin: Verleiht administrative Rechte für die Verwaltung einer bestimmten Datenbank, etwa zum Erstellen, Löschen und Anpassen von Indizes und Collections. Geeignet für Entwicklerteams oder Wartungsskripte.
• clusterAdmin (operativer Zugriff): Diese hochprivilegierte Rolle ist in der Regel für Operations-(DevOps/Ops)-Personal reserviert. Sie umfasst Berechtigungen zum Verwalten der gesamten MongoDB-Installation, einschließlich Konfiguration von Replica Sets, Sharding und Backups. Anwendungsentwickler brauchen diese Rolle selten.

3. Das Prinzip der geringsten Rechte umsetzen

Das Fundament moderner Datenbanksicherheit ist das Prinzip der geringsten Rechte (PoLP). Jede Person (insbesondere Anwendungskonten) erhält nur die minimal nötigen Berechtigungen für ihre Aufgaben – nicht mehr.

So sieht Best Practice aus: Statt eines globalen readWrite-Nutzers erstellst du anwendungsspezifische Accounts. Wenn dein Inventory-Service nur mit der Datenbank app_data arbeitet, sollte der Anwendungsnutzer nur readWrite-Rechte auf genau diese eine Datenbank bekommen. Diese Segmentierung verhindert, dass ein kompromittierter Service unbefugt auf andere Datenbanken (wie billing oder users) zugreift.

Codebeispiel: Least-Privilege-User anlegen

Dieses Beispiel legt einen Nutzer (inventory_service) mit strikt auf die Datenbank app_data begrenztem Lese-/Schreibzugriff an.

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

4. Eigene Rollen erstellen (wenn die Standardrollen nicht reichen)

So mächtig die integrierten Rollen auch sind, Compliance-Vorgaben oder komplexe Anwendungslogik können sehr feingranulare Kontrolle erfordern. In solchen Fällen kannst du in MongoDB benutzerdefinierte Rollen definieren – per db.createRole().

Feingranulare Rechte definieren: Eigene Rollen erlauben dir, exakt festzulegen, welche Privilege-Aktionen (z. B. find, update, insert) auf Ressourcen auf Cluster-, Datenbank- oder Collection-Ebene ausgeführt werden dürfen. Organisationen können Techniken wie Feldbasierte Schwärzung einsetzen, um besonders sensible Datenfelder in sonst öffentlichen Collections zu schützen.

Codebeispiel: eine benutzerdefinierte Rolle erstellen

Dieses Beispiel erstellt eine Custom-Rolle (product_creator), die nur Dokumente in die Collection products innerhalb der Datenbank app_data einfügen darf.

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

Rundumschutz für Daten: Netzwerkisolation und Verschlüsselung

Starke Authentifizierung und Autorisierung steuern den Zugriff, aber vollständige Sicherheit bedeutet, die Daten selbst zu schützen – sowohl auf dem Transportweg (in transit) als auch im Speicher (at rest).

1. Daten auf dem Transportweg mit TLS/SSL schützen

Datenübertragungen – ob intern im Rechenzentrum oder extern in der Cloud – müssen verschlüsselt sein, um Abhören und Man-in-the-Middle-(MITM)-Angriffe zu verhindern. MongoDB nutzt Transport Layer Security/Secure Sockets Layer (TLS/SSL), um sämtliche Kommunikation zwischen Clients (z. B. deiner Anwendung) und dem Server zu verschlüsseln.

Ohne TLS/SSL werden Zugangsdaten, Query-Parameter und sensible Ergebnisse im Klartext übertragen und lassen sich leicht abfangen. Mit TLS/SSL werden die Daten während der Übertragung verschlüsselt und geschützt.

TLS/SSL aktivieren: Dies erfolgt in erster Linie über Konfigurationen, in denen du die Zertifikate für Identitätsprüfung und Schlüsselaustausch angibst:

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

• net.ssl.mode: requireTLS erzwingt TLS/SSL für alle eingehenden Verbindungen und weist unsichere Versuche zurück.
• certificateKeyFile verweist auf dein generiertes TLS/SSL-Zertifikat bzw. die zugehörige Certificate Authority.

2. Firewall und Netzwerksegmentierung

Netzwerksegmentierung bietet eine wichtige Schutzschicht, indem sie die physischen oder virtuellen Schnittstellen beschränkt, die sich mit der Datenbank verbinden dürfen. Selbst wenn ein Angreifer Netzwerkzugriff erlangt, muss er immer noch deine Perimeterverteidigung durchbrechen.

• Zugriff per IP-Whitelist einschränken: Über die Einstellung bindIp oder entsprechende Netzwerk-Firewalls kannst du bestimmte IP-Adressen auf die Positivliste setzen.
• Best Practice: Der MongoDB-Server sollte nur für deine Anwendungsserver, den Load Balancer oder die Proxy-Schicht erreichbar sein. Er sollte niemals direkt aus dem öffentlichen Internet zugänglich sein. Diese Segmentierung schützt die Datenbank hinter dem Sicherheitsperimeter deiner Anwendungsinfrastruktur.

3. Verschlüsselung im Ruhezustand (Storage-Engine-Verschlüsselung)

Der Schutz von Daten im Ruhezustand stellt sicher, dass Dateien unlesbar bleiben, wenn das physische Laufwerk oder die Host-Umgebung kompromittiert wird. MongoDB erreicht dies über die Verschlüsselung der Storage Engine.

• So funktioniert es: Die Storage Engine WiredTiger kann so konfiguriert werden, dass alle Daten-, Konfigurations- und Journaldateien auf dem Datenträger verschlüsselt werden. Daten werden beim Schreiben transparent verschlüsselt und beim Lesen entschlüsselt – mit einem vom System verwalteten Schlüssel.
• Wichtiger Hinweis: Diese zentrale Schutzschicht ist in der Regel ein MongoDB-Enterprise-Feature und nutzt externe Key-Management-Server nach KMIP (Key Management Interoperability Protocol) oder lokale Schlüsseldateien für die Schlüsselverwaltung.

4. Client-Side Field Level Encryption (CSFLE): Der Goldstandard für Entwickler

Während die Verschlüsselung im Ruhezustand die gesamte Datenbank schützt, bietet die Client-Side Field Level Encryption (CSFLE) Entwicklerinnen und Entwicklern punktgenaue Kontrolle über sensible Daten, indem sie ausgewählte Felder verschlüsseln, bevor diese an die Datenbank gesendet werden.

• CSFLE im Überblick: Die Verschlüsselung erfolgt im Anwendungstreiber bevor die Daten den Anwendungsserver verlassen. Der MongoDB-Server sieht die sensiblen Daten nie im Klartext; er speichert nur Chiffretexte. Die sensiblen Inhalte bleiben auf dem Server – auch im Arbeitsspeicher, in Logs und im Storage – stets verschlüsselt.
• Das stärkste Tool für Entwickler: CSFLE ist der Goldstandard für Compliance (z. B. DSGVO, HIPAA), weil sensible Felder (wie personenbezogene Daten oder Finanzinformationen) selbst bei einem vollständigen Datenbank-Leak verschlüsselt und geschützt bleiben. Entwicklerinnen und Entwickler entscheiden aktiv, was verschlüsselt wird, und integrieren die Logik direkt in den Anwendungscode.

5. Verschlüsselung bei der Nutzung mit Queryable Encryption

Queryable Encryption ist eine Weiterentwicklung von CSFLE und adressiert die Herausforderung, verschlüsselte Felder zu abzufragen. Anwendungen können Gleichheitsabfragen (z. B. Dokumente finden, bei denen ein verschlüsseltes Feld einem bestimmten Wert entspricht) direkt gegen den Chiffretext ausführen. So kombiniert man die Sicherheit von CSFLE mit Datennutzbarkeit – effektiv eine Verschlüsselung „in Use“.

Auditing: Das Post-Mortem-Werkzeug

Sicherheitsmaßnahmen dienen der Prävention, Auditing der Verantwortlichkeit und Erkennung. Das integrierte Audit-Framework von MongoDB protokolliert sicherheitsrelevante Ereignisse und liefert einen unveränderlichen Nachweis – essenziell für Forensik, Compliance und proaktive Bedrohungserkennung.

1. Was ist Auditing und warum ist es wichtig?

Auditing zeichnet jede kritische Aktion gegen die Datenbank auf und schafft so eine detaillierte Historie. Dazu gehören:

• Authentifizierungsereignisse: erfolgreiche und fehlgeschlagene Login-Versuche.
• Autorisierungsänderungen: Anlegen, Ändern oder Löschen von Nutzern und Rollen.
• Konfigurationsänderungen: Anpassungen an systemweiten Parametern mit Sicherheitsrelevanz.

Dieses Protokoll ist für Security-Teams bei der Vorfallsanalyse (das „Post-Mortem“-Tool) und zur Erfüllung regulatorischer Anforderungen unbezahlbar.

2. Konfiguration und Filterung

Auditing aktivieren ist unkompliziert – oft reicht eine einzige Zeile in der Konfigurationsdatei, um das System zu starten und das Ausgabemedium festzulegen (Datei, Syslog oder Konsole).

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

• Filterung: Das Auditsystem erlaubt sehr feingranulare Filter mit einer query-ähnlichen Syntax. Das ist entscheidend, um das Logvolumen zu steuern. Fokussiere den Filter auf kritische, sicherheitsrelevante Ereignisse wie Nutzerverwaltung, Änderungen an Sicherheitskonfigurationen und Authentifizierungsversuche.

Fazit und nächste Schritte

MongoDB bietet ein umfassendes Set an Sicherheitsfunktionen, die – korrekt implementiert – eine starke Defense-in-Depth-Strategie bilden. Deine Hauptaufgabe als Developer ist es, über die Entwicklungs-Defaults hinauszugehen und diese Kernkontrollen umzusetzen.

Bevor eine Anwendung in Produktion geht, denk an diese drei Sicherheitsgebote:

• Daten auf dem Transportweg verschlüsseln: Nutze TLS/SSL für alle Netzwerkverbindungen (net.ssl.mode: requireTLS).
• Daten im Ruhezustand verschlüsseln: Sichere die Datenbankdateien auf dem Datenträger mit Volume- oder Dateisystemverschlüsselung oder der WiredTiger-Storage-Engine-Verschlüsselung von MongoDB (verfügbar in MongoDB Enterprise), um unbefugten Zugriff auf Datenbankdateien zu verhindern.
• Daten während der Nutzung verschlüsseln: Verwende Client-Side Field Level Encryption (CSFLE) und Queryable Encryption für hochsensible Datenfelder, damit die Daten auch im laufenden Betrieb verschlüsselt bleiben.

Sicherheit entwickelt sich ständig weiter. Für tiefergehende Informationen und erweiterte Konfigurationen nutze die offizielle Dokumentation:

• MongoDB Security Center: Finde Leitfäden zum Härtung von Deployments und zu operativen Sicherheitspraktiken.
• Dokumentation zur Verschlüsselung in Nutzung: Lerne, wie du Client-Side Field Level Encryption (CSFLE) und die erweiterte Fähigkeit Queryable Encryption (QE) implementierst, damit sensible Daten vertraulich bleiben und dennoch effizient abgefragt werden können, während sie in Nutzung sind.

Ich empfehle außerdem den Kurs Introduction to Using MongoDB for Data Science in Python.