Sicherheits-Härtung und Checkliste für den Produktivbetrieb

Produktionsbereitschaft ist kein Feature, sondern eine Checkliste von Maßnahmen, die vor dem ersten echten Zugriff auf Ihr System angewendet werden. Eine Bereitstellung, die alle Funktionstests besteht, aber die Härtung der Sicherheit, das Monitoring und die Überprüfung der Backups auslässt, ist nicht produktionsbereit. Diese abschließende Lektion führt durch die wichtigsten Punkte der Produktionscheckliste für eine MongoDB-Bereitstellung und behandelt Authentifizierung, RBAC, TLS, Verschlüsselung, Monitoring, Backups und Disaster Recovery.

Vergewissern Sie sich, dass die Authentifizierung aktiviert ist und keine nicht authentifizierten Verbindungen möglich sind. Bestätigen Sie bei selbst gehostetem MongoDB, dass security.authorization: enabled in mongod.conf gesetzt ist. In Atlas ist die Authentifizierung obligatorisch und kann nicht deaktiviert werden. Testen Sie dies, indem Sie versuchen, sich ohne Zugangsdaten zu verbinden — die Verbindung muss abgewiesen werden. Stellen Sie sicher, dass kein Benutzer in Produktionskonten von Anwendungen die Rolle root oder __system besitzt.

Überprüfen Sie jeden Datenbankbenutzer. Jeder Anwendungsdienst sollte ausschließlich die Rollen besitzen, die er benötigt, und zwar nur für die Datenbanken, auf die er zugreifen muss. Führen Sie für jede Datenbank db.getUsers() aus und prüfen Sie, dass kein Servicekonto dbAdminAnyDatabase, readWriteAnyDatabase oder root besitzt. Erstellen Sie eine Benutzerzugriffsmatrix, in der dokumentiert ist, welcher Dienst sich mit welchem Benutzer verbindet, welche Rollen dieser besitzt und warum. Diese Matrix ist Ihre zentrale Quelle für Zugriffsüberprüfungen.

Bestätigen Sie, dass net.tls.mode: requireTLS aktiv ist und alle Clientverbindungen verschlüsselt werden. Prüfen Sie das MongoDB-Log auf fehlgeschlagene TLS-Handshakes, die darauf hindeuten, dass Clients noch versuchen, unverschlüsselte Verbindungen herzustellen. In Atlas ist TLS standardmäßig aktiviert und kann nicht deaktiviert werden. Führen Sie bei selbst gehosteten Bereitstellungen db.adminCommand({ sslInfo: 1 }) aus (oder prüfen Sie db.serverStatus().network), um zu verifizieren, dass TLS aktiv ist. Lehnen Sie jede Bereitstellung ab, bei der TLS in der Produktion auf allowTLS gesetzt ist.

MongoDB sollte nicht direkt aus dem öffentlichen Internet erreichbar sein. Vergewissern Sie sich in Atlas, dass die IP Access List nicht 0.0.0.0/0 (alle zulassen) enthält. Verwenden Sie VPC Peering oder Private Link, um den Datenverkehr privat zu leiten. Binden Sie MongoDB bei selbst gehosteten Bereitstellungen ausschließlich an die private Netzwerkschnittstelle (net.bindIp: 127.0.0.1,10.0.0.5) und konfigurieren Sie Firewall-Regeln so, dass am Port 27017 nur IPs von Anwendungsservern zugelassen werden.

Produktionsbereitstellungen müssen über eine verifizierte und getestete Backup-Strategie verfügen. Aktivieren Sie in Atlas Continuous Cloud Backup, das eine Point-in-Time-Recovery zu jeder Sekunde innerhalb des Aufbewahrungszeitraums ermöglicht. Konfigurieren Sie bei selbst gehosteten Bereitstellungen tägliche mongodump-Snapshots in S3 und testen Sie monatlich die Wiederherstellung. Das entscheidende Wort ist getestet — ein Backup, aus dem noch nie eine Wiederherstellung durchgeführt wurde, ist ein Backup, dem Sie nicht vertrauen können. Führen Sie vierteljährlich eine Disaster-Recovery-Übung durch.

Eine produktive MongoDB-Bereitstellung benötigt Monitoring für: Hardware (CPU, I/O des Datenträgers, Netzwerk); MongoDB-spezifische Metriken (Verbindungen, Opcounters, Cache-Trefferrate, Replikations-Lag, Lock-Prozentsätze); und auf Anwendungsebene (P99-Abfragelatenz, Fehlerraten). Atlas bietet integriertes Monitoring und Alerting. Selbst gehostete Bereitstellungen sollten in Prometheus (mongodb_exporter) + Grafana oder eine gleichwertige Lösung integriert werden. Richten Sie Alerts ein, bevor Schwellenwerte überschritten werden, nicht erst danach.

Legen Sie vor dem Launch einen Ausgangswert für die Abfrageleistung fest: Aktivieren Sie den Profiler auf Stufe 1, führen Sie eine repräsentative Last aus (mit einem Tool wie MongoDBs Load Generator oder k6) und erfassen Sie die P95- und P99-Latenzen für jeden kritischen Endpunkt. Speichern Sie diese Ausgangswerte. Führen Sie den Lasttest nach jeder Bereitstellung erneut aus und vergleichen Sie die Ergebnisse. Jede Verschlechterung des P99-Werts um mehr als 20 % löst eine Untersuchung aus, bevor die Bereitstellung alle Benutzer erreicht.

Stellen Sie bei Anwendungen, die personenbezogene Daten, Zahlungsdaten oder Gesundheitsinformationen verarbeiten, sicher, dass die Verschlüsselung ruhender Daten aktiviert ist. Aktivieren Sie in Atlas in den Sicherheitseinstellungen die auf dem KMS des Cloud-Anbieters basierende Verschlüsselung. Bestätigen Sie bei selbst gehosteten Enterprise-Bereitstellungen security.enableEncryption: true und stellen Sie sicher, dass ein KMIP-Schlüsselmanager konfiguriert ist. Dokumentieren Sie, welcher Customer Master Key welchen Cluster schützt, und stellen Sie sicher, dass für den CMK selbst Zugriffskontrollen mit mehreren Personen eingerichtet sind, um eine Aussperrung zu verhindern.

Aktivieren Sie Audit-Logging, um jede Authentifizierung, jeden Autorisierungsfehler und jedes Ereignis mit Zugriff auf sensible Daten zu protokollieren. MongoDB Enterprise und Atlas stellen Audit-Log-Streams bereit, die Sie an ein SIEM-System (Security Information and Event Management) weiterleiten können. Konfigurieren Sie Audit-Filter für die Erfassung von: allen authenticate-Aktionen, allen createUser-/dropUser-/updateUser-Aktionen und allen Vorgängen in sensiblen Collections (users, payments). Bewahren Sie Audit-Logs aus Compliance-Gründen mindestens ein Jahr lang auf.

Dokumentieren Sie betriebliche Abläufe in einem Runbook: wie Sie sich im Notfall mit MongoDB verbinden, wie Sie ein ausgefallenes Mitglied eines Replikatsatzes neu starten, wie Sie ein manuelles Failover durchführen, wie Sie aus einem Backup wiederherstellen und wie der Eskalationsweg aussieht. Üben Sie diese Abläufe in einer Staging-Umgebung. Legen Sie ein Recovery Time Objective (RTO) fest — wie lange darf die Datenbank ausfallen — sowie ein Recovery Point Objective (RPO) — wie viel Datenverlust ist akzeptabel. Das kontinuierliche Backup von Atlas ermöglicht ein RPO von wenigen Sekunden.

In der letzten Lektion dieses Abschlussprojekts haben Sie die Checkliste für die Produktionsreife abgeschlossen: Authentifizierung, RBAC mit minimalen Berechtigungen, TLS, Netzwerkisolierung, Sicherung + getestete Wiederherstellung, Überwachung, Referenzwert für die Abfrageleistung, Verschlüsselung ruhender Daten, Audit-Protokollierung und eine schriftliche Betriebsanleitung. Herzlichen Glückwunsch — Sie haben nun den gesamten Track zu MongoDB und NoSQL-Datenbanken abgeschlossen, vom ersten Einfügen eines Dokuments bis zur Bereitstellung eines Sharding-Clusters in der Produktion. Nutzen Sie diese Kenntnisse und bauen Sie etwas Großartiges!