MongoDB-Sicherheitshärtung (Autorisierung, TLS, Rollen, Audit)

Szenariobasiertes Runbook, um ein laufendes MongoDB (Einzelserver, Replica Set oder Sharded Cluster) ohne Ausfallzeit zu härten: schreibgeschütztes Sicherheitsaudit, rollierende Aktivierung der Autorisierung mit keyFile + transitionToAuth, Custom Roles und Benutzer nach dem Least-Privilege-Prinzip, SCRAM-SHA-256, bindIp und Firewall, der Übergang allowTLS → preferTLS → requireTLS, x.509-Mitgliedsauthentifizierung, Audit-Log (Enterprise/Percona) und Encryption at Rest; am Ende wird das Audit wiederholt und gezeigt, dass die Risiken behoben sind. Auf Systemen, die mit den Installationsanleitungen dieser Website aufgebaut wurden, sind Autorisierung und Keyfile bereits aktiv: Beginne mit dem Audit und wende nur die Szenarien an, die RISIKO melden. Tagesbetrieb und Backup werden in eigenen MongoDB-Anleitungen behandelt.

Topologie: Einzelserver, Replica Set mit 3+ Mitgliedern oder Sharded Cluster

Szenarien

• Sicherheitsstatus prüfen (schreibgeschützt) — Ändert nichts. Zugriff ohne Authentifizierung, lauschende Adressen, TLS, Authentifizierungsmechanismen, hochprivilegierte Benutzer, Audit und Encryption at Rest werden als OK / WARNUNG / RISIKO gemeldet. Wähle dies, wenn du nicht weißt, wo du anfangen sollst.
• Vollständige Härtung (alles nacheinander) — Audit → interne Authentifizierung + Autorisierung (ohne Ausfallzeit mit transitionToAuth) → Benutzer mit minimalen Rechten → SCRAM-SHA-256 → bindIp/Firewall → TLS (allowTLS → preferTLS → requireTLS) → Audit-Log (Enterprise/Percona) → abschließendes Audit. Im Replica Set rollierend; jeder riskante Schritt fragt nach Bestätigung.
• Autorisierung deaktiviert: Autorisierung aktivieren (keyFile, ohne Ausfallzeit) — Jeder kann sich ohne Benutzername und Passwort verbinden. Im Replica Set und Sharded Cluster wird die Autorisierung mit keyFile + transitionToAuth rollierend und ohne Ausfallzeit aktiviert; ein Einzelserver braucht einen kurzen Neustart.
• Benutzer mit minimalen Rechten und Custom Roles (Anwendung, Backup, Monitoring) — Anwendungen verbinden sich mit root oder einem gemeinsamen Admin-Konto. Es werden eine Custom Role, die der Anwendung nur die in ihrer eigenen Datenbank nötigen Aktionen erlaubt, sowie eigene Benutzer für Backup und Monitoring angelegt; gezeigt wird auch, wie Passwörter auf Cron-/Anwendungsseite sicher abgelegt werden.
• SCRAM-SHA-1 deaktivieren, nur SCRAM-SHA-256 — Die Anmeldedaten älterer Benutzer sind mit SHA-1 gespeichert, oder das Audit hat SCRAM-SHA-1 als aktiv gemeldet. Die Benutzer werden auf SHA-256 migriert, danach wird authenticationMechanisms mit einem rollierenden Neustart eingeschränkt.
• Netzwerkzugriff einschränken (bindIp 0.0.0.0, Firewall) — mongod lauscht auf allen Schnittstellen (0.0.0.0, bindIpAll), oder der Port ist für alle offen. bindIp wird auf localhost + die interne IP des Servers reduziert, die Firewall lässt nur die Mitglieder und das Anwendungsnetz zu. Rollierend, ohne Ausfallzeit.
• Verbindungen verschlüsseln: TLS (allowTLS → preferTLS → requireTLS) — Der Verkehr zwischen Anwendung und Mitgliedern sowie zwischen den Mitgliedern ist unverschlüsselt. Die Zertifikate werden verteilt, die Mitglieder zuerst rollierend auf allowTLS umgestellt, dann im laufenden Betrieb auf preferTLS und, sobald die Anwendungen bereit sind, auf requireTLS. Optional: x.509-Authentifizierung zwischen den Mitgliedern.
• Audit-Log aktivieren (Enterprise / Percona) — Wer sich wann angemeldet hat, Benutzer-/Rollenänderungen und Drop-Operationen müssen protokolliert werden. In MongoDB Enterprise und Percona Server for MongoDB wird das mit auditLog aktiviert; Community hat diese Funktion nicht (eine Alternative wird gezeigt).
• Encryption at Rest (Daten auf der Festplatte verschlüsseln) — Wird eine Festplatte oder ein Backup gestohlen, sollen die Daten nicht lesbar sein. Auf Enterprise/Percona wird die WiredTiger-Verschlüsselung aktiviert, indem die Mitglieder nacheinander per Initial Sync neu aufgebaut werden; auf Community wird die Datenplatte mit LUKS verschlüsselt.

Vor dem Start

• Root-/sudo-Zugriff auf alle mongod…- und mongos…-Server; SSH vom ersten Server zu den übrigen (zum Kopieren von Keyfile und Zertifikaten).
• …Das Replica Set ist gesund: alle Mitglieder PRIMARY/SECONDARY, geringer Lag. Auf einem ungesunden Cluster wird kein rollierender Vorgang ausgeführt.…mongod läuft.…
• Liste der Anwendungen und ihrer Verantwortlichen: Die Verbindungszeichenfolge jeder Anwendung wird aktualisiert, bevor Autorisierung/TLS verpflichtend werden. Die Verbindungszeichenfolge muss alle Mitglieder und replicaSet= enthalten (damit die Verbindung beim rollierenden Neustart nicht abreißt).
• Wartungsfenster: Rollierende Vorgänge verursachen keine Ausfallzeit, aber bei jedem Primary-Wechsel warten Schreibvorgänge einige Sekunden. Auf einem Einzelserver erfordert das Aktivieren von Autorisierung/TLS eine kurze Unterbrechung.
• Wenn die Autorisierung im Sharded Cluster bereits aktiv ist: Auf dem Primary jedes Shards muss ein Shard-lokaler Benutzer (root) mit demselben Namen und Passwort wie … auf mongos existieren. Mitgliedsbezogene Schritte (rs.stepDown beim rollierenden Neustart, setParameter, Audit) verbinden sich direkt mit den Shard-Mitgliedern; mongos-Benutzer gelten dort nicht. Prüfung: auf einem Shard-Mitglied mongosh --port <Shard-Port> und db.getSiblingDB("admin").auth("…", passwordPrompt()).
• Ein aktuelles Vollbackup, dessen Wiederherstellung getestet wurde.
• Eine MongoDB-Enterprise-Lizenz oder Percona Server for MongoDB für Audit und Encryption at Rest. Community hat diese Funktionen nicht.
• Die Mitgliedsnamen werden auf jedem Server aufgelöst (DNS oder /etc/hosts); bei TLS laufen die Verbindungen über diese Namen.

Phasen der Anleitung

• Vorbereitung: Sicherheitsnetz und Hilfswerkzeuge — Sicherung von Konfiguration und Zustand · PyYAML installieren · YAML-Bearbeitungswerkzeug schreiben (dbatlas-yaml) · Werkzeug für den rollierenden Neustart schreiben (dbatlas-mongod-restart) · Administratorpasswort in eine temporäre Datei schreiben
• Statusaudit (schreibgeschützt) — Netzwerk, Prozess und Dateirechte: … · Netzwerk und Prozess: … · Autorisierung, TLS und Parameter: … · Autorisierung, TLS und Parameter: … · Benutzer, Rollen und Authentifizierungsmechanismen · Befunde den Szenarien zuordnen
• Autorisierung: Diagnose und Keyfile — Diagnose: Ist die Autorisierung wirklich deaktiviert? · Anwendungsverbindungen inventarisieren · Keyfile erstellen · Keyfile auf die anderen Server kopieren · Rechte des Keyfiles: … · Rechte des Keyfiles: …
• Autorisierung: Administrator — Administrator anlegen (…) · Shard-lokaler Administrator: …
• Benutzer mit minimalen Rechten und Custom Roles — Custom Role für die Anwendung anlegen (…@…) · Anwendungsbenutzer anlegen (…) · Backup- und Monitoring-Benutzer · Minimale Rechte prüfen (…) · Passwörter auf Anwendungs- und Cron-Seite sicher ablegen
• Autorisierung: prüfen, dass keine nicht authentifizierten Verbindungen mehr bestehen — Nicht authentifizierte Client-Verbindungen: …
• Autorisierung erzwingen (Einzelserver) — authorization: enabled · Dienst sicher neu starten (…)
• Autorisierung: Verifizierung — Wird Zugriff ohne Authentifizierung abgelehnt? · Minimale Rechte prüfen (…) · Rollback-Weg (falls nötig)
• SCRAM-SHA-256: Benutzer migrieren — Benutzer mit SHA-1-Anmeldedaten · Benutzer auf ausschließlich SCRAM-SHA-256 reduzieren
• SCRAM-SHA-256: Verifizierung — Wird die Anmeldung mit SHA-1 abgelehnt?
• Netzwerkzugriff: Firewall — Firewall-Regeln
• Netzwerkzugriff: Verifizierung — Lauschende Adressen: …
• TLS: Zertifikate — Aktueller TLS-Status · Interne CA und Serverzertifikate erzeugen · Zertifikate verteilen · Zertifikatsrechte und Prüfung: … · Zertifikatsrechte: …
• TLS: Anwendungen umstellen — Anwendungen auf TLS umstellen und TLS-Verbindungen zählen
• TLS: Verifizierung — Werden Verbindungen ohne TLS abgelehnt: …
• Audit-Log: Vorabprüfung — Unterstützt dieses mongod Auditing: …
• Audit-Log: Verifizierung und Rotation — Werden Audit-Einträge geschrieben: … · Community-Alternative: Authentifizierungslogs überwachen
• Encryption at Rest: Vorabprüfung und Backup — Verschlüsselungsunterstützung und Plattenplatz: … · Wurde ein Vollbackup erstellt?
• Encryption at Rest: Testmarkierung — Klartext-Markierung schreiben
• Encryption at Rest (Community): Datenplatte mit LUKS — LUKS-Platte vorbereiten: … · Daten auf die verschlüsselte Platte verschieben: …
• Abschließendes Audit (nach der Härtung) — Netzwerk, Prozess und Dateirechte: … (Endzustand) · Netzwerk und Prozess: … (Endzustand) · Autorisierung, TLS und Parameter: … (Endzustand) · Autorisierung, TLS und Parameter: … (Endzustand) · Benutzer, Rollen und Authentifizierungsmechanismen (Endzustand)
• Aufräumen und nächste Schritte — Temporäre Passwortdatei löschen · Nächste Schritte: Monitoring und regelmäßige Aufgaben