Redis-/Valkey-Security-Härtung (ACL, TLS, gefährliche Befehle)

Weder Installation noch täglicher Betrieb: ein szenariobasiertes Runbook, um ein laufendes Redis oder Valkey (Einzelserver, Replica + Sentinel oder Cluster) ohne Ausfallzeit zu härten. Schreibgeschütztes Security-Audit, ACL-Benutzer und Deaktivieren des Benutzers default, requirepass/masterauth, bind und protected-mode, Protected Configs gegen Missbrauch von CONFIG/DEBUG/MODULE, Umstellung auf TLS im laufenden Betrieb (Clients, Replikation, Sentinel, Cluster Bus) und Dateirechte; am Ende wird das Audit wiederholt, um zu zeigen, dass die Risiken behoben sind. Mit den DBAtlas-Installationsguides aufgebaute Systeme haben bereits ein Passwort und eine enge Firewall: Beginne mit dem Audit und wende nur die Szenarien an, die RISK oder WARN melden. Backup und täglicher Betrieb stehen in eigenen Redis-Guides.

Topologie: Einzelserver, Master + Replica + Sentinel oder Redis Cluster

Szenarien

• Security-Statusaudit (nur lesend) — Ändert nichts. Zugriff ohne Passwort, der Benutzer default, Listen-Adressen, protected-mode, gefährliche Befehle, TLS, das Sentinel-Passwort und Dateirechte werden als OK / WARN / RISK gemeldet. Wähle dies, wenn du nicht weißt, wo du anfangen sollst.
• Vollständige Härtung (alles der Reihe nach) — Audit → ACL-Benutzer (Admin, Anwendung, Replikation, Sentinel) und Deaktivieren des Benutzers default → bind/protected-mode/Firewall → gefährliche Befehle und Protected Configs → TLS → Dateirechte → abschließendes Audit. Auf Replicas/Sentinel rolling; riskante Schritte verlangen eine Bestätigung.
• ACL-Benutzer und Deaktivieren des Benutzers default (Redis 6+) — Alle verbinden sich mit einem einzigen Passwort (oder ohne) als Benutzer default. Für Administrator, Anwendung (nur eigene Keys, keine gefährlichen Befehle), Replikation und Sentinel werden eigene Benutzer angelegt und in die aclfile geschrieben; sind die Anwendungen umgezogen, wird default deaktiviert.
• Redis ohne Passwort: requirepass / masterauth (Sofortmaßnahme) — Es gibt überhaupt kein Passwort und keine Zeit für die Umstellung auf ACL. Allen Nodes wird im laufenden Betrieb ein gemeinsames Passwort gesetzt (requirepass + masterauth für die Replikation, auth-pass für Sentinel); Anwendungen können sich danach nicht mehr ohne Passwort verbinden.
• Netzwerkzugriff einschränken (bind 0.0.0.0, protected-mode, Firewall) — Redis lauscht auf allen Interfaces oder läuft mit protected-mode no. bind wird auf localhost + die interne IP reduziert, protected-mode aktiviert, und die Firewall lässt nur die Nodes und das Anwendungsnetz zu. Wird im laufenden Betrieb angewendet, bestehende Verbindungen bleiben erhalten; dieser Schritt senkt das Risiko am schnellsten.
• Gefährliche Befehle und CONFIG-Missbrauch (FLUSHALL, CONFIG, DEBUG, MODULE) — Gegen den Missbrauch von CONFIG SET dir/dbfilename, um Dateien auf den Server zu schreiben (SSH-Schlüssel, Cron), und gegen FLUSHALL/DEBUG/MODULE LOAD: enable-protected-configs, enable-debug-command, enable-module-command bleiben deaktiviert, und den Anwendungen wird @dangerous entzogen; bei älteren Versionen rename-command.
• Verbindungen verschlüsseln: TLS (Clients, Replikation, Sentinel, Cluster Bus) — Der Verkehr ist unverschlüsselt. Der TLS-Port wird im laufenden Betrieb neben dem bestehenden Port geöffnet, Replikation und Sentinel wechseln auf TLS, und sobald die Anwendungen umgestellt sind, wird der Klartext-Port geschlossen (port 0).
• Dateirechte und Dienstbenutzer — redis.conf (enthält Passwörter), die ACL-Datei, RDB/AOF und Logdateien sind für andere Benutzer lesbar, oder Redis läuft als root. Die Rechte werden auf 640/750 verschärft und der Besitz auf den Dienstbenutzer gesetzt.

Vor dem Start

• root/sudo auf allen Nodes; SSH vom ersten Node zu den übrigen (zum Kopieren der Passwortdatei und der Zertifikate).
• Redis 6.2+ oder Valkey 7.2+ (6.0+ für ACL, 7.0+ für Protected Configs).
• Replikation… und Sentinel… sind in Ordnung; Rolling-Vorgänge werden nicht auf einer fehlerhaften Topologie durchgeführt.
• Liste der Anwendungen und Versionen der Client-Bibliotheken: Benutzername + Passwort für ACL (Redis-6+-Client), rediss://-Unterstützung für TLS; bei Clients mit Sentinel Unterstützung für Sentinel-Passwort und TLS.
• openssl ist installiert (Erzeugung von Passwörtern und Zertifikaten).

Phasen der Anleitung

• Vorbereitung: Sicherheitsnetz und Hilfswerkzeuge — Sicherung von Konfiguration und ACL · Hilfswerkzeuge schreiben (dbatlas-rconf, dbatlas-rcli, dbatlas-redis-restart) · Admin-Passwort in eine temporäre Datei schreiben
• Statusaudit (nur lesend) — Security-Bericht: … · Sentinel-Bericht: … · Befunde den Szenarien zuordnen
• Passwort: requirepass und masterauth (im laufenden Betrieb) — Gemeinsames Passwort festlegen: … · masterauth: … · Sentinel auth-pass: … · requirepass: … · Passwort für den Sentinel: … · Sind Replikation und Sentinel in Ordnung? …
• ACL: Diagnose und Benutzerpasswörter — Diagnose: Wer ist mit welchem Benutzer verbunden? · Passwörter der internen Benutzer erzeugen · Passwortdatei auf die anderen Nodes kopieren
• ACL: Benutzer default deaktivieren — Noch Clients als default verbunden: … · Benutzer default deaktivieren: … · Prüfen: Zugriff ohne Authentifizierung, Anwendungsrechte, Replikation · Passwort für den Sentinel: …
• Netzwerkzugriff: Firewall — Firewall-Regeln
• Gefährliche Befehle: Diagnose — Protected Configs und Befehle debug/module: …
• Gefährliche Befehle: Verifizierung — Werden CONFIG SET dir und DEBUG abgewiesen: …
• TLS: Zertifikate — TLS-Unterstützung: … · Interne CA und Server-Zertifikate erzeugen · Zertifikate verteilen · Zertifikatsrechte: …
• TLS · Cluster Bus und Replikation (Wartungsfenster, alle Nodes gemeinsam) — Bus-Port festlegen, tls-cluster und tls-replication in die Datei schreiben: … · Stoppen: … · Starten: … · Laufen Cluster und Replikation über TLS?
• TLS: Verifizierung und Schließen des Klartext-Ports — Laufen Replikation… und Sentinel… über TLS? · Klartext-Port schließen: … · Wird die unverschlüsselte Verbindung abgewiesen: …
• Dateirechte und Dienstbenutzer — Rechte korrigieren: …
• Abschließendes Audit (nach der Härtung) — Security-Bericht: … (Endzustand) · Sentinel-Bericht: … (Endzustand)
• Aufräumen und Nacharbeit — Temporäre Passwortdateien löschen · Nacharbeit: Monitoring und periodische Aufgaben