Redis ACL-Kategorien und Command-Restriktionen praktisch nutzen

1. Warum ein einzelnes Passwort für moderne Setups nicht mehr reicht

Vor Redis 6 kannte der Server im Wesentlichen ein einziges Authentifizierungsgeheimnis über requirepass, das entweder vollständigen Zugriff gewährte oder gar keinen. Für eine einzelne Anwendung mit einer einzigen Verbindungsquelle war das ausreichend, doch moderne Architekturen bestehen selten aus nur einem Dienst: Ein Magento-Shop nutzt Redis parallel für den Full-Page-Cache, für Sessions, für den Objekt-Cache und häufig auch für Warteschlangen oder Indexer-Locks.

Teilen sich all diese Dienste dasselbe Passwort, kann ein kompromittierter Cache-Client theoretisch auch Sessions anderer Nutzer auslesen oder, im schlimmsten Fall, den gesamten Datenbestand mit FLUSHALL löschen. Das Access Control List System aus Redis 6 löst dieses Problem, indem es erlaubt, für jeden Dienst einen eigenen Benutzer mit exakt zugeschnittenen Rechten anzulegen, statt ein einziges Generalschlüssel-Passwort für alles zu verwenden.

2. ACL-Kategorien im Überblick

Statt jeden der mehreren hundert Redis-Befehle einzeln freizugeben, gruppiert Redis Befehle in vordefinierte Kategorien, die sich mit einem einzigen Ausdruck aktivieren oder sperren lassen. Zu den wichtigsten zählen @read für lesende Operationen, @write für schreibende Operationen, @keyspace für Befehle, die den gesamten Schlüsselraum betreffen, @admin für administrative Operationen wie CONFIG oder CLIENT KILL, und @dangerous für Befehle mit besonders weitreichenden Auswirkungen wie FLUSHALL, SHUTDOWN oder DEBUG.

Die vollständige Liste aller Kategorien und der ihnen zugeordneten Befehle lässt sich jederzeit über den Befehl ACL CAT abfragen, während ACL CAT gefolgt von einem Kategorienamen die konkreten Befehle innerhalb dieser Kategorie auflistet. Diese Transparenz ist wichtig, weil sich Kategorien mit neuen Redis-Versionen gelegentlich um neu hinzugekommene Befehle erweitern, sodass eine bestehende Rechtevergabe regelmäßig gegen die aktuelle Kategorienliste geprüft werden sollte.

# Alle verfügbaren Kategorien und ihre Befehle einsehen
redis-cli ACL CAT
redis-cli ACL CAT dangerous

3. Praktisches Least-Privilege-Setup pro Anwendungsdienst

Der Kerngedanke von Least Privilege besteht darin, jedem Dienst nur die Rechte zu geben, die er für seine konkrete Aufgabe tatsächlich benötigt, keinesfalls mehr. Ein Cache-Lesedienst, der Produktdaten nur ausliest und niemals selbst schreibt, sollte ausschließlich @read-Rechte auf sein eigenes Schlüsselpräfix erhalten, während ein separater Cache-Warmer-Prozess zusätzlich @write für genau dasselbe Präfix benötigt, aber weiterhin keinerlei administrative Rechte.

In der Praxis wird ein solcher Benutzer über den Befehl ACL SETUSER angelegt, der Kategorien, einzelne Befehlsausnahmen und Schlüsselmuster in einer einzigen Regel kombiniert. Ein Session-Dienst etwa braucht Lese- und Schreibrechte auf sein Session-Präfix sowie den Befehl EXPIRE zum Setzen von Ablaufzeiten, aber weder Zugriff auf Cache-Schlüssel anderer Dienste noch auf administrative Befehle.

# Cache-Lesedienst: nur lesen, nur eigenes Präfix
redis-cli ACL SETUSER cache-reader on >starkes-passwort \
  ~cache:* +@read

# Cache-Warmer: lesen und schreiben, aber keine Admin-Rechte
redis-cli ACL SETUSER cache-warmer on >anderes-passwort \
  ~cache:* +@read +@write -@admin -@dangerous

4. Umgang mit gefährlichen Commands in Produktionsumgebungen

Befehle wie FLUSHALL, FLUSHDB oder KEYS gehören zur Kategorie @dangerous und sollten in nahezu jeder produktiven Anwendungsverbindung explizit gesperrt sein. FLUSHALL und FLUSHDB löschen sämtliche Daten der Instanz beziehungsweise einer Datenbank unwiderruflich, während KEYS bei einer großen Datenmenge den kompletten Schlüsselraum blockierend durchsucht und dadurch die Instanz für alle anderen Clients spürbar verlangsamt.

Für administrative Werkzeuge und Wartungsskripte, die diese Befehle tatsächlich benötigen, empfiehlt sich ein separater, eng überwachter Administrator-Benutzer, der sich klar von den Anwendungsdiensten unterscheidet und dessen Zugangsdaten nicht in derselben Konfigurationsdatei liegen wie die der regulären Dienste. Für Ad-hoc-Diagnose sollte statt KEYS grundsätzlich der nicht-blockierende Befehl SCAN verwendet werden, der den Schlüsselraum in kleinen Portionen durchläuft, ohne die Instanz für andere Clients zu blockieren.

5. ACL-Datei versus Runtime-Konfiguration und ihre Persistenz

Über ACL SETUSER angelegte Benutzer existieren zunächst nur im Arbeitsspeicher der laufenden Instanz und gehen bei einem Neustart ohne weiteres Zutun verloren. Für einen dauerhaften Bestand gibt es zwei Wege: entweder eine separate aclfile, die beim Serverstart geladen wird und alle Benutzerdefinitionen in Textform enthält, oder den Befehl ACL SAVE, der die aktuell im Speicher aktiven Regeln in genau diese Datei zurückschreibt.

Für produktive Umgebungen empfiehlt sich die aclfile als Quelle der Wahrheit, idealerweise unter Versionskontrolle verwaltet, sodass jede Rechteänderung nachvollziehbar dokumentiert ist. Runtime-Änderungen über ACL SETUSER eignen sich dann vor allem für Notfallanpassungen, etwa das sofortige Sperren eines kompromittierten Benutzers, gefolgt von einem anschließenden ACL SAVE, um die Änderung dauerhaft in die Datei zu übernehmen.

6. Key-Pattern-Restriktionen kombiniert mit Command-Kategorien

Command-Kategorien allein steuern nur, welche Befehle ein Benutzer ausführen darf, nicht jedoch auf welche Schlüssel. Erst die Kombination mit Key-Pattern-Regeln, eingeleitet durch das Tilde-Zeichen, schränkt den Zugriff zusätzlich auf einen bestimmten Namensraum ein. Ein Benutzer mit +@read und dem Muster ~session:* darf lesen, aber ausschließlich innerhalb von Schlüsseln, die mit session: beginnen, selbst wenn theoretisch auch andere Schlüssel in derselben Datenbank existieren.

Diese Kombination aus Befehls- und Schlüsselraum-Restriktion ist gerade in Multi-Service-Setups entscheidend, weil sie verhindert, dass ein kompromittierter Cache-Dienst auf Session-Daten zugreifen kann, selbst wenn beide Dienste dieselbe Redis-Instanz und dieselbe logische Datenbank teilen. Ohne eine solche Schlüsselraum-Trennung wäre die reine Befehlseinschränkung nur ein halber Schutz.

# Zugriff strikt auf ein Schlüsselpräfix begrenzen
redis-cli ACL SETUSER session-service on >passwort \
  ~session:* +@read +@write +expire -@dangerous

7. ACL-Regeln testen und auditieren

Vor dem produktiven Einsatz eines neuen Benutzers lohnt sich ein gezielter Test der tatsächlichen Rechte über ACL WHOAMI zur Identifikation der aktiven Verbindung sowie ACL GETUSER für einen bestimmten Benutzernamen, der die vollständige, effektive Rechtekonfiguration inklusive aller Kategorien und Schlüsselmuster ausgibt. Gerade bei komplexeren Regeln mit mehreren addierten und subtrahierten Kategorien lohnt sich dieser Blick, weil die Reihenfolge der Regeln das Endergebnis beeinflusst.

Für ein regelmäßiges Audit aller vorhandenen Benutzer eignet sich ACL LIST, das jede aktive Regel im Klartext ausgibt und sich gut in ein automatisiertes Skript integrieren lässt, das Abweichungen von einer erwarteten Soll-Konfiguration meldet. Ein solches Audit deckt zuverlässig auf, wenn versehentlich ein zu breites Recht vergeben wurde, etwa ein +@all statt der eigentlich beabsichtigten engen Kategorie.

8. Migration von requirepass zu ACL ohne Downtime

Eine bestehende Installation, die noch mit dem klassischen requirepass arbeitet, lässt sich schrittweise auf ACL umstellen, ohne den Betrieb zu unterbrechen. Der Standardbenutzer default bleibt dabei zunächst mit seinem bisherigen Passwort aktiv, während parallel neue, eingeschränkte Benutzer für jeden Anwendungsdienst angelegt werden. Erst wenn alle Dienste erfolgreich auf ihren eigenen Benutzer umgestellt sind, wird der default-Benutzer entweder deaktiviert oder auf ein reines Notfallkonto mit stark eingeschränkten Rechten reduziert.

Dieser schrittweise Ansatz erlaubt es, jede Dienst-Umstellung einzeln zu testen und bei Problemen sofort auf das alte Passwort zurückzufallen, statt die gesamte Infrastruktur in einem einzigen riskanten Schnitt umzustellen. Für Magento-Umgebungen bedeutet das konkret, Cache-, Session- und Indexer-Verbindung nacheinander auf jeweils einen eigenen ACL-Benutzer umzustellen und jede Umstellung durch einen produktiven Testlauf zu bestätigen, bevor der nächste Dienst folgt.

9. Praxisbeispiel: Multi-Service-Setup in einem Magento-Shop

Ein realistisches Magento-Setup nutzt Redis typischerweise für mehrere klar getrennte Zwecke gleichzeitig: den Full-Page-Cache, den Objekt-Cache, Sessions und häufig zusätzlich eine Warteschlange für asynchrone Indexer-Läufe. Jeder dieser Zwecke erhält im ACL-Modell einen eigenen Benutzer mit genau den Kategorien und Schlüsselpräfixen, die für die jeweilige Aufgabe nötig sind, und nichts darüber hinaus.

Ein solcher Aufbau begrenzt den Schaden eines kompromittierten Anwendungsservers spürbar: Selbst wenn Angreifer über eine Schwachstelle in der Anwendung Zugriff auf die Cache-Zugangsdaten erlangen, bleiben Session-Daten anderer Nutzer und die Indexer-Warteschlange durch die separaten Benutzer und Schlüsselpräfixe unerreichbar. Diese Isolation lässt sich nachträglich in eine bestehende Installation einziehen, ohne die Anwendung selbst grundlegend umzubauen, solange die Verbindungskonfiguration pro Dienst ohnehin schon getrennt ist.

10. Zusammenfassung

11. FAQ: ACL-Kategorien in Redis: Das Wichtigste auf einen Blick