MongoDB nativ installieren und absichern: Ubuntu/Debian ohne Docker (Community Edition 8.0)

Die native Installation von MongoDB bietet gegenüber Docker einen direkten systemd-Lifecycle, Logs per journalctl und Zertifikatszugriff ohne Volume-Mapping. Diese Anleitung zeigt, wie Sie MongoDB Community Edition 8.0 über das offizielle mongodb-org-APT-Repository auf Ubuntu (20.04, 22.04, 24.04) oder Debian 12 einrichten, als systemd-Dienst betreiben und mit drei aufeinander aufbauenden Maßnahmen härten: SCRAM-Authentifizierung, IP-Bindung und TLS.

Voraussetzungen

1. Ubuntu 20.04 LTS (Focal), 22.04 LTS (Jammy) oder 24.04 LTS (Noble), alternativ Debian 12 (Bookworm), jeweils 64-bit (amd64 oder arm64)
2. Prozessor: x86_64 mit AVX-Befehlssatz (Pflicht seit MongoDB 5.0) oder ARM64 ab ARMv8.2-A. Ältere Celeron-, Pentium- und Atom-CPUs ohne AVX scheiden aus; prüfen Sie das mit grep -c avx /proc/cpuinfo (Ergebnis größer als 0)
3. Linux-Kernel unter 6.19 oder Upstream-Kernel ab 7.0.14 beziehungsweise 7.1, prüfen mit uname -r (Details in Schritt 1)
4. Für eine kleine Produktivinstanz 2 CPU-Kerne, 4 GB RAM und 20 GB SSD-Speicher
5. Root- oder sudo-Zugang zum Server
6. Internetverbindung zu repo.mongodb.org und pgp.mongodb.com (für APT-Repo und GPG-Schlüssel)
7. Pakete gnupg, curl und openssl verfügbar (werden ggf. nachinstalliert)
8. Für TLS in Produktion: PEM-Zertifikat von einer vertrauenswürdigen CA (z. B. Let's Encrypt oder interne PKI); für Test/Entwicklung reicht ein selbstsigniertes Zertifikat
9. ca. 30 Minuten Zeit

Schritt 1: Voraussetzungen und Paketquellen vorbereiten

Installieren Sie zuerst gnupg und curl, die für den Import des GPG-Schlüssels nötig sind:

sudo apt-get install -y gnupg curl

Anschließend importieren Sie den offiziellen MongoDB-GPG-Schlüssel. Dieser wird in /usr/share/keyrings/ abgelegt und später in der Sources-Datei explizit referenziert. Das ist der moderne, sichere Weg statt des veralteten apt-key-Kommandos:

curl -fsSL https://pgp.mongodb.com/server-8.0.asc | \
  sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg \
  --dearmor

Wichtig: Verwenden Sie ausschließlich das offizielle Paket mongodb-org aus dem mongodb.com-Repository, nicht das Paket mongodb aus den Standard-Ubuntu/Debian-Quellen. Letzteres ist eine veraltete, inoffizielle Variante.

Kernel prüfen: MongoDB führt unter SERVER-121912 eine bekannte Inkompatibilität von MongoDB 8.0 und neuer mit Linux-Kerneln ab 6.19. Ursache sind laut MongoDB geänderte rseq-Funktionen im Kernel, die den Speicherverwalter TCMalloc betreffen. Die Kompatibilitätstabelle in SERVER-125742 (Stand 24.08.2026) nennt diese Grenzen:

Ubuntu-Kernel tragen in uname -r die Versionsnummer X.Y.0, etwa 7.0.0-38-generic, auch wenn sie auf einem neueren Upstream-Stand beruhen. Die Startprüfung von MongoDB erkennt solche Kernel deshalb bis einschließlich 8.0.34 nicht als korrigiert (SERVER-136848). Die Ausnahme für Ubuntu-Kernel ist laut SERVER-131779 für 8.0.35 vorgesehen. Den Upstream-Stand zeigt unter Ubuntu cat /proc/version_signature.

uname -r
cat /proc/version_signature   # nur Ubuntu

Liegt der Kernel ab 6.19 und lässt er sich nicht auf einen Stand unter 6.19 oder einen erkannten Upstream-Kernel ab 7.0.14 bringen, ist MongoDB 7.0 die belegte Alternative: Laut Tabelle läuft sie auf allen Kerneln, MongoDB unterstützt 7.0 laut Lebenszyklus-Seite bis 31. August 2027. Das APT-Repository bietet 7.0 für Ubuntu 22.04 und Debian 12 an (Unterverzeichnis mongodb-org/7.0, Schlüssel server-7.0.asc), für Ubuntu 24.04 gibt es dort keinen 7.0-Zweig. Ersetzen Sie in diesem Fall in den Schritten 1 und 2 jeweils 8.0 durch 7.0. Legen Sie die Hauptversion vor der Installation fest.

Verifizieren: ls -l /usr/share/keyrings/mongodb-server-8.0.gpg zeigt eine Datei mit einigen KB Größe. uname -r zeigt einen Kernel unter 6.19, oder Sie haben sich anhand der Tabelle für eine passende Version entschieden.

Schritt 2: APT-Repository hinzufügen

Tragen Sie das Repository passend zu Ihrer Distribution ein:

Ubuntu 24.04 (Noble):

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse" | \
  sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list

Ubuntu 22.04 (Jammy):

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/8.0 multiverse" | \
  sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list

Ubuntu 20.04 (Focal):

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/8.0 multiverse" | \
  sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list

Debian 12 (Bookworm):

echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/debian bookworm/mongodb-org/8.0 main" | \
  sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list

Verifizieren: sudo apt-get update listet repo.mongodb.org ohne GPG- oder „NO_PUBKEY“-Fehler.

Schritt 3: MongoDB installieren und Version pinnen

Paketliste aktualisieren und das Metapaket mongodb-org installieren. Es zieht automatisch alle Komponenten nach: mongod, mongos, mongosh sowie die Datenbanktools (mongodump, mongorestore, mongoexport, mongostat usw.):

sudo apt-get update
sudo apt-get install -y mongodb-org

Pinnen Sie die Version direkt nach der Installation. Ohne diesen Schritt kann ein späteres apt upgrade MongoDB auf eine inkompatible Version heben, mit potenziell gravierenden Folgen für laufende Datenbankinstanzen:

echo "mongodb-org hold" | sudo dpkg --set-selections
echo "mongodb-org-database hold" | sudo dpkg --set-selections
echo "mongodb-org-server hold" | sudo dpkg --set-selections
echo "mongodb-mongosh hold" | sudo dpkg --set-selections
echo "mongodb-org-mongos hold" | sudo dpkg --set-selections
echo "mongodb-org-tools hold" | sudo dpkg --set-selections

Verifizieren: dpkg -l mongodb-org sollte die installierte Version anzeigen. Um die Pins zu prüfen: dpkg --get-selections | grep hold: Alle sechs Pakete sollten hold zeigen.

Schritt 4: systemd-Dienst starten und aktivieren

Registrieren Sie den Dienst bei systemd, starten Sie ihn und aktivieren Sie den Autostart:

sudo systemctl daemon-reload
sudo systemctl start mongod
sudo systemctl enable mongod
sudo systemctl status mongod

Verifizieren: systemctl status mongod zeigt active (running). Logs finden Sie unter /var/log/mongodb/mongod.log oder per sudo journalctl -u mongod -n 50 --no-pager. Der Dienst lauscht standardmäßig auf Port 27017, ausschließlich auf dem Loopback-Interface (127.0.0.1). Das ist der sichere Default seit MongoDB 3.6.

Schritt 5: Ersten Admin-User anlegen (localhost exception)

Bevor Sie die Authentifizierung aktivieren, muss mindestens ein Admin-User existieren. MongoDB ermöglicht das über die sogenannte „localhost exception“: Solange noch kein User angelegt ist, erlaubt MongoDB einen passwortfreien Loopback-Zugriff. Diese Exception erlischt automatisch nach dem ersten angelegten User.

Öffnen Sie die MongoDB-Shell:

mongosh --port 27017

Legen Sie in der Shell den Admin-User an. passwordPrompt() fragt das Passwort interaktiv ab. Das ist sicherer, als es im Klartext in den Befehlsverlauf zu schreiben:

use admin
db.createUser({
  user: "adminUser",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" }
  ]
})

Verifizieren: db.getUsers() in der Datenbank admin zeigt adminUser mit beiden Rollen. Beenden Sie die Shell danach mit exit.

Schritt 6: TLS-Zertifikat vorbereiten

MongoDB erwartet eine einzelne PEM-Datei, die Private Key und Zertifikatskette kombiniert enthält.

Für Test und Entwicklung: selbstsigniertes Zertifikat:

sudo mkdir -p /etc/ssl/mongodb

# CA-Schlüssel und -Zertifikat erzeugen
sudo openssl req -x509 -newkey rsa:4096 -keyout /etc/ssl/mongodb/ca.key \
  -out /etc/ssl/mongodb/ca.pem -days 3650 -nodes \
  -subj "/CN=MongoDB-CA"

# Server-Schlüssel und CSR erzeugen
sudo openssl req -newkey rsa:4096 -keyout /etc/ssl/mongodb/server.key \
  -out /etc/ssl/mongodb/server.csr -nodes \
  -subj "/CN=localhost"

# Server-Zertifikat durch CA signieren
sudo openssl x509 -req -in /etc/ssl/mongodb/server.csr \
  -CA /etc/ssl/mongodb/ca.pem -CAkey /etc/ssl/mongodb/ca.key \
  -CAcreateserial -out /etc/ssl/mongodb/server.crt -days 365

# PEM-Datei erstellen (Key + Cert kombiniert, MongoDB-Anforderung!)
sudo cat /etc/ssl/mongodb/server.key /etc/ssl/mongodb/server.crt > /etc/ssl/mongodb/mongod.pem

Für Produktion mit Let's Encrypt oder eigener PKI:

cat /etc/letsencrypt/live/ihre-domain.de/privkey.pem \
    /etc/letsencrypt/live/ihre-domain.de/fullchain.pem \
    > /etc/ssl/mongodb/mongod.pem

Anschließend Berechtigungen setzen. Die Dateien müssen für den Prozess-User mongodb lesbar sein:

sudo chown mongodb:mongodb /etc/ssl/mongodb/mongod.pem /etc/ssl/mongodb/ca.pem
sudo chmod 600 /etc/ssl/mongodb/mongod.pem
sudo chmod 644 /etc/ssl/mongodb/ca.pem

Verifizieren: sudo openssl verify -CAfile /etc/ssl/mongodb/ca.pem /etc/ssl/mongodb/server.crt meldet OK, ls -l /etc/ssl/mongodb/mongod.pem zeigt -rw------- mongodb mongodb.

Schritt 7: mongod.conf: Authentifizierung, bindIp und TLS aktivieren

Alle drei Härtungsmaßnahmen werden in der zentralen Konfigurationsdatei /etc/mongod.conf im YAML-Format konfiguriert. Ersetzen Sie den Inhalt der Datei durch diese gehärtete Konfiguration:

systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true
  logRotate: reopen

storage:
  dbPath: /var/lib/mongodb

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

net:
  port: 27017
  bindIp: 127.0.0.1        # Nur Loopback; für Fernzugriff ergänzen: 127.0.0.1,192.168.1.10
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb/mongod.pem
    CAFile: /etc/ssl/mongodb/ca.pem
    disabledProtocols: TLS1_0,TLS1_1

security:
  authorization: enabled

Was die einzelnen Blöcke bewirken: security.authorization: enabled aktiviert SCRAM-SHA-256 als Standard-Authentifizierungsmechanismus. net.bindIp: 127.0.0.1 schränkt den Lauschbereich auf das Loopback-Interface ein. Für Fernzugriff von einem App-Server tragen Sie dessen interne IP zusätzlich ein, niemals pauschal 0.0.0.0 ohne flankierende Firewallregeln. net.tls.mode: requireTLS erzwingt verschlüsselte Verbindungen; ältere TLS-Versionen 1.0 und 1.1 werden explizit via disabledProtocols ausgeschlossen.

Dienst neu starten, damit die Konfiguration greift:

sudo systemctl restart mongod

Verifizieren: sudo systemctl status mongod muss active (running) zeigen. Schlägt der Start fehl, prüfen Sie die Logs: sudo journalctl -u mongod -n 100 --no-pager. Häufigste Ursachen sind fehlende oder falsch gesetzte Berechtigungen auf der PEM-Datei sowie eine fehlende CAFile-Angabe.

Schritt 8: Verbindung mit Authentifizierung und TLS testen

Prüfen Sie, ob die gehärtete Instanz antwortet. Der mongosh-Aufruf gibt TLS, die CA-Datei und als Host den Namen aus dem Zertifikat (hier localhost) an:

mongosh --host localhost --port 27017 \
  --tls \
  --tlsCAFile /etc/ssl/mongodb/ca.pem \
  --authenticationDatabase admin \
  -u adminUser -p

Nach der Passworteingabe sollte der Prompt admin> erscheinen. Eine kurze Funktionsprüfung in der Shell:

db.runCommand({ connectionStatus: 1 })

Verifizieren: Das Ergebnis enthält "ok": 1 sowie unter authInfo.authenticatedUsers Ihren adminUser. Eine Verbindung ohne --tls oder ohne gültige Credentials sollte fehlschlagen.

Schritt 9: Firewall mit UFW konfigurieren

Sichern Sie den Port zusätzlich auf Netzwerkebene ab. Im Standardfall ist MongoDB ist nur lokal erreichbar und Port 27017 bleibt nach außen geschlossen:

sudo ufw deny 27017

Wenn ein App-Server aus dem internen Netz auf MongoDB zugreifen muss:

sudo ufw allow from 192.168.1.100 to any port 27017
sudo ufw reload

Ersetzen Sie 192.168.1.100 durch die IP des App-Servers. Geben Sie Port 27017 nie ohne Quell-IP-Einschränkung ins Internet frei.

Verifizieren: sudo ufw status numbered zeigt die Regel für 27017; ein Verbindungsversuch von einem nicht freigegebenen Rechner läuft in einen Timeout.

Troubleshooting / Typische Fehler

mongod startet nicht nach Aktivierung der Authentifizierung

Wenn Sie security.authorization: enabled gesetzt haben, ohne vorher einen Admin-User anzulegen, ist kein Login mehr möglich. Lösung: Authentifizierung in mongod.conf vorübergehend auf disabled zurücksetzen, Dienst starten, User anlegen, dann wieder aktivieren.

MongoDB beendet sich sofort: „Linux kernel versions 6.19 and newer has a known incompatibility“

Der Kernel liegt ab 6.19 und die installierte Version startet darauf nicht (Tabelle in Schritt 1). sudo journalctl -u mongod -n 50 --no-pager zeigt die Meldung mit Verweis auf SERVER-121912. Lösung: Kernel unter 6.19 booten, einen Upstream-Kernel ab 7.0.14 mit MongoDB ab 8.0.30 nutzen oder auf MongoDB 7.0 ausweichen.

TLS-Startfehler: „certificate file could not be loaded“

Die häufigste Ursache ist eine PEM-Datei, die nur das Zertifikat enthält, aber nicht den Private Key, oder umgekehrt. MongoDB benötigt zwingend beide kombiniert in einer Datei: cat server.key server.crt > mongod.pem. Zusätzlich müssen Besitzer und Berechtigungen stimmen: sudo chown mongodb:mongodb mongod.pem && sudo chmod 600 mongod.pem.

TLS-Startfehler: „CAFile not set“

Bei aktiviertem TLS ist net.tls.CAFile zwingend erforderlich. Alternativ setzen Sie net.tls.tlsUseSystemCA: true, wenn Sie dem System-CA-Store vertrauen. Fehlt beides, verweigert mongod den Start.

Verbindung schlägt fehl, obwohl mongod läuft

Prüfen Sie zuerst, auf welchen Interfaces mongod tatsächlich lauscht: ss -tlnp | grep 27017. Wenn dort nur 127.0.0.1:27017 steht, Sie aber von einer anderen IP verbinden, erweitern Sie net.bindIp in mongod.conf um die Server-IP und starten den Dienst neu.

Meldet mongosh bei TLS einen Fehler zu Hostname oder „altnames“, stimmt der Host im Aufruf nicht mit dem Zertifikat überein: Verbinden Sie mit --host localhost bzw. dem Namen aus dem Zertifikat statt mit 127.0.0.1.

Bricht mongod sofort mit „Illegal instruction (core dumped)“ ab und das Log bleibt leer, fehlt der CPU der AVX-Befehlssatz. Das betrifft auch virtuelle Server, deren CPU-Typ AVX nicht durchreicht. Lösung: anderer Server bzw. CPU-Typ „host“ in der Virtualisierung.

Version-Pin vergessen: apt upgrade hat MongoDB aktualisiert

Prüfen Sie mit dpkg --get-selections | grep mongodb, ob die Pakete noch auf hold stehen. Wenn nicht, setzen Sie die Pins erneut wie in Schritt 3 beschrieben. Für ein kontrolliertes Upgrade: Pins kurz auf install setzen, upgraden, sofort wieder auf hold zurücksetzen.

LDAP-Authentifizierung nicht mehr nutzen

LDAP ist in MongoDB 8.0 als deprecated markiert und wird in einem zukünftigen Major Release entfernt. Für neue Deployments immer SCRAM (Standard) oder X.509-Zertifikatsauthentifizierung verwenden.

Häufige Fragen

Kann ich MongoDB 8.0 auch auf Ubuntu 18.04 oder Debian 11 installieren?

Nein. MongoDB 8.0 Community Edition unterstützt offiziell nur Ubuntu 20.04/22.04/24.04 und Debian 12 (Bookworm). Für ältere Systeme wäre ein OS-Upgrade oder die Verwendung einer älteren MongoDB-Version (z. B. 7.0 auf Debian 11) nötig.

Muss ich TLS konfigurieren, wenn MongoDB nur lokal erreichbar ist?

Für rein lokale Verbindungen (App und Datenbank auf demselben Host, bindIp: 127.0.0.1) ist TLS optional, da der Traffic das Netzwerk nicht verlässt. Sobald MongoDB über das Netzwerk erreichbar ist, auch nur innerhalb eines internen VLANs, ist TLS in Produktionsumgebungen dringend empfohlen.

Was ist der Unterschied zwischen net.tls und net.ssl in mongod.conf?

net.ssl ist der ältere Namespace und aus Rückwärtskompatibilität erhalten. net.tls ist der aktuelle, bevorzugte Namespace. Beide konfigurieren dieselbe Funktionalität. Für neue Deployments immer net.tls verwenden.

Wie rotiere ich TLS-Zertifikate ohne Downtime?

Ab MongoDB 5.0 ist Online-Zertifikatsrotation ohne Neustart möglich. Neue Zertifikatsdateien unter demselben Pfad ablegen, dann in mongosh als Admin ausführen: db.rotateCertificates().

Wie verhindere ich dauerhaft unbeabsichtigte apt-Upgrades?

Die Pins aus Schritt 3 bleiben persistent. Zum Freigeben für ein gezieltes Upgrade: echo "mongodb-org install" | sudo dpkg --set-selections. Den Befehl für jedes Unterpaket wiederholen. Nach dem Upgrade sofort wieder auf hold setzen.

Fazit

Der entscheidende Unterschied zu einer unsicheren Standardinstallation liegt in der Reihenfolge: erst den Admin-User anlegen, dann Authentifizierung aktivieren. Mit SCRAM-Authentifizierung, einer auf interne IPs beschränkten bindIp-Konfiguration und TLS mit requireTLS schließen Sie die häufigsten Angriffswege. Version-Pinning verhindert ungeplante Upgrades, UFW ergänzt eine Netzwerkschicht. Prüfen Sie vor der Installation die AVX-Unterstützung der CPU.

Weiterführende Anleitungen und Quellen

1. PostgreSQL nativ installieren und absichern (Ubuntu/Debian, ohne Docker)
2. MariaDB / MySQL installieren und absichern
3. VPS absichern und härten: Anleitung mit UFW, SSH-Keys und Fail2Ban
4. Let's Encrypt mit certbot: TLS-Zertifikate ohne Reverse-Proxy
5. Docker und Docker Compose auf Linux installieren
6. Linux-Server absichern mit UFW und Fail2ban
7. MongoDB Docs: Install MongoDB Community Edition on Ubuntu (v8.0)
8. MongoDB Docs: Configure mongod for TLS/SSL (v8.0)
9. MongoDB Docs: Enable SCRAM Client Authentication (v8.0)