ACL Selectors: granulare Berechtigungen jenseits einfacher Command-Listen

1. Wo klassische ACL-Regeln an ihre Grenzen stoßen

Eine Redis-ACL-Definition ohne Selectors besteht aus genau einem Satz an Regeln pro Nutzer: eine Liste erlaubter oder verbotener Befehle, kombiniert mit einem oder mehreren Key-Patterns, die für alle erlaubten Befehle gleichermaßen gelten. Das funktioniert gut, solange ein Nutzer eine homogene Rolle hat, etwa nur lesen oder nur auf einen bestimmten Schlüsselbereich schreiben darf.

Sobald ein Nutzer aber differenziertere Rechte braucht, etwa lesenden Zugriff auf einen breiten Schlüsselbereich, aber schreibenden Zugriff nur auf einen engen Unterbereich, oder Administrationsbefehle nur für Schlüssel eines bestimmten Teams, reicht ein einziger Regelsatz nicht mehr aus. Vor Redis 7 musste man solche Fälle entweder mit mehreren separaten Nutzern und Anwendungslogik zur Auswahl der richtigen Verbindung lösen, oder man akzeptierte unnötig weitreichende Rechte als Kompromiss.

2. Das Grundprinzip: mehrere unabhängige Regelsätze pro Nutzer

Ein ACL Selector ist ein zusätzlicher, in Klammern gesetzter Regelblock innerhalb einer ACL SETUSER-Definition, der seinen eigenen, unabhängigen Satz an erlaubten Befehlen und Key-Patterns definiert. Ein Nutzer kann beliebig viele Selectors besitzen, zusätzlich zu seinem Root-Regelsatz, der außerhalb der Klammern steht. Bei jedem Befehl prüft Redis, ob entweder der Root-Regelsatz oder mindestens einer der definierten Selectors den Befehl mit den betroffenen Schlüsseln erlaubt.

Wichtig ist, dass ein Selector als vollständig eigenständige Einheit ausgewertet wird: Ein Befehl muss vollständig innerhalb eines einzelnen Selectors erlaubt sein, Rechte aus verschiedenen Selectors werden nicht für denselben Befehlsaufruf kombiniert. Das verhindert, dass sich aus mehreren, für sich genommen engen Selectors versehentlich eine zu weitreichende Kombination ergibt.

# Nutzer mit Root-Regelsatz und einem zusätzlichen Selector anlegen
ACL SETUSER team_checkout on >secretpass \
    ~checkout:* +get +set +del \
    "(~orders:* +get +hget +hgetall)"

# Root-Regelsatz: voller Lese-/Schreibzugriff auf checkout:*
# Selector: nur lesender Zugriff auf orders:*

3. Mehrere Selectors kombinieren: unterschiedliche Rechte je Command-Gruppe

Ein Nutzer kann mehrere Selectors gleichzeitig besitzen, jeweils mit eigenen Befehlen und eigenen Key-Patterns. Das erlaubt es, echte Rollenmodelle abzubilden, bei denen unterschiedliche Befehlsgruppen unterschiedliche Zugriffsbereiche haben: etwa lesender Zugriff auf Bestelldaten für Reporting-Zwecke, schreibender Zugriff auf ein enges Set an Statusfeldern für Statusübergänge und administrativer Zugriff auf Schlüssel zur Job-Steuerung, jeweils mit eigenem Pattern und eigener Befehlsliste.

Praktisch bedeutet das: Statt für jede Kombination aus Rolle und Zugriffsbereich einen eigenen Nutzer mit eigenem Passwort zu pflegen, lässt sich ein einziger, semantisch sinnvoller Nutzer definieren, dessen Selectors die tatsächlich benötigten Zugriffsmuster präzise abbilden. Das reduziert die Anzahl der zu verwaltenden Zugangsdaten erheblich, ohne bei den Rechten Kompromisse einzugehen.

# Nutzer mit drei unabhaengigen Selectors für unterschiedliche Aufgaben
ACL SETUSER order_service on >secretpass \
    "(~orders:*:status +get +set)" \
    "(~orders:* +get +hgetall +mget)" \
    "(~jobs:orders:* +lpush +lpop +llen)"

4. Key-Pattern-Präzision je Selector: warum das den Unterschied macht

Jeder Selector definiert sein eigenes Set an Key-Patterns über ~pattern für Lese- und Schreibzugriff oder getrennt über %R~pattern für reinen Lesezugriff und %W~pattern für reinen Schreibzugriff auf ein Pattern. Diese Feinheit erlaubt es, innerhalb eines einzigen Selectors sogar zwischen Lese- und Schreibrechten auf unterschiedliche, sich überschneidende oder getrennte Schlüsselbereiche zu unterscheiden, ohne dass dafür ein weiterer Selector nötig wäre.

In der Praxis ist diese Präzision entscheidend für das Prinzip der geringsten Rechte: Ein Reporting-Dienst braucht typischerweise nur %R~orders:*, während ein Order-Service-Prozess, der Status-Übergänge verantwortet, gezielt %W~orders:*:status benötigt, aber keinesfalls Schreibzugriff auf die vollständigen Bestelldatensätze. Ohne diese Trennung müsste man entweder zu weitreichende Schreibrechte vergeben oder unnötig viele Nutzer pflegen.

# Getrennte Lese- und Schreibrechte innerhalb eines Selectors
ACL SETUSER reporting_readonly on >secretpass \
    "(%R~orders:* +get +hgetall +mget)"

# Nur Schreibzugriff auf Statusfelder, kein Lesezugriff auf Volldaten
ACL SETUSER status_writer on >secretpass \
    "(%W~orders:*:status +set +hset)"

5. Praktisches Beispiel: ein Multi-Team-Setup mit drei Diensten

In einem typischen Magento-nahen Setup teilen sich mehrere Dienste dieselbe Redis-Instanz für unterschiedliche Zwecke: ein Checkout-Dienst verwaltet Warenkorb-Zustände, ein Reporting-Dienst liest historische Bestelldaten für Dashboards, und ein Job-Scheduler steuert asynchrone Verarbeitungswarteschlangen. Ohne Selectors bräuchte jeder dieser Dienste entweder einen eigenen, engen Nutzer mit nur einer Aufgabe, oder alle Dienste teilten sich einen zu weitreichend berechtigten gemeinsamen Nutzer.

Mit Selectors lässt sich für jeden Dienst ein einziger Nutzer definieren, dessen Root-Regelsatz und zusätzliche Selectors exakt die Kombination an Zugriffsmustern abbilden, die der jeweilige Dienst tatsächlich benötigt. Das folgende Beispiel zeigt drei Nutzer, die sich dieselbe Redis-Instanz teilen, aber strikt getrennte Zugriffsbereiche haben.

# Checkout-Dienst: voller Zugriff auf Warenkoerbe, nur Lesezugriff auf Preise
ACL SETUSER svc_checkout on >pass1 \
    "(~cart:* +get +set +hset +hgetall +expire)" \
    "(%R~price:* +get +mget)"

# Reporting-Dienst: reiner Lesezugriff auf Bestelldaten und Metriken
ACL SETUSER svc_reporting on >pass2 \
    "(%R~orders:* +get +hgetall +mget +scan)" \
    "(%R~metrics:* +get +mget)"

# Job-Scheduler: volle Kontrolle über Warteschlangen, kein Zugriff auf Kundendaten
ACL SETUSER svc_scheduler on >pass3 \
    "(~jobs:* +lpush +lpop +llen +brpop)"

6. Auswertungsreihenfolge: wie Redis über mehrere Selectors entscheidet

Bei jedem Befehl prüft Redis zunächst, ob der Root-Regelsatz des Nutzers den Befehl mit den betroffenen Schlüsseln erlaubt. Ist das nicht der Fall, werden die definierten Selectors der Reihe nach geprüft, bis entweder ein Selector den Befehl vollständig erlaubt oder alle Selectors erschöpft sind. Findet sich keine passende Erlaubnis, wird der Befehl mit NOPERM abgelehnt, unabhängig davon, wie knapp ein einzelner Selector am Erlauben vorbeigeschrammt ist.

Wichtig dabei: Innerhalb eines Selectors müssen sowohl der Befehl als auch alle betroffenen Schlüssel dessen Key-Pattern entsprechen. Ein Befehl, der mehrere Schlüssel gleichzeitig betrifft, etwa MGET key1 key2, wird nur erlaubt, wenn beide Schlüssel innerhalb desselben Selectors zum Pattern passen. Das verhindert, dass sich Rechte über mehrere Selectors hinweg zu einer unbeabsichtigten Kombination summieren.

7. Testen und Diagnose: ACL-Regeln vor dem Produktivbetrieb prüfen

Vor dem Einsatz eines neuen Nutzers mit mehreren Selectors lohnt sich ein gezielter Test mit ACL DRYRUN, das simuliert, ob ein bestimmter Befehl mit bestimmten Schlüsseln für einen Nutzer erlaubt wäre, ohne den Befehl tatsächlich auszuführen. Das erlaubt es, komplexe Selector-Kombinationen systematisch gegen die tatsächlich erwarteten Zugriffsmuster einer Anwendung zu verifizieren, bevor der Nutzer produktiv genutzt wird.

Zusätzlich liefert ACL LIST und ACL GETUSER eine vollständige, maschinenlesbare Übersicht aller Regeln und Selectors eines Nutzers, was sich gut für automatisierte Audits eignet, etwa als Teil einer CI-Pipeline, die bei jeder Änderung an den ACL-Definitionen prüft, ob die tatsächlich vergebenen Rechte noch dem dokumentierten Soll-Zustand entsprechen.

# Pruefen, ob svc_reporting einen Schreibbefehl ausführen duerfte
ACL DRYRUN svc_reporting SET orders:4711:status shipped
# -> "This user has no permissions to run the 'set' command"

# Vollstaendige Regeln inklusive aller Selectors ausgeben
ACL GETUSER svc_reporting

8. Migrationspfad: bestehende Nutzer schrittweise auf Selectors umstellen

Bei bestehenden Redis-Installationen mit historisch gewachsenen, zu weitreichenden Nutzerrechten empfiehlt sich eine schrittweise Migration statt eines abrupten Umbaus. Zunächst analysiert man über ACL LOG und Anwendungs-Monitoring, welche Befehle und Key-Patterns ein bestehender Nutzer tatsächlich in der Praxis verwendet, um daraus präzise Selector-Definitionen abzuleiten, statt Rechte pauschal zu raten.

Anschließend legt man den neuen, mit Selectors verfeinerten Nutzer parallel zum alten an, testet ihn mit der Anwendung in einer Staging-Umgebung und schaltet erst danach die Anwendung auf den neuen Nutzer um, während der alte Nutzer als Rückfalloption vorübergehend bestehen bleibt, bevor er endgültig entfernt wird.

9. Häufige Fehler beim Schreiben von Selector-Regeln

Ein verbreiteter Fehler ist das Vergessen der Klammern um einen Selector: Ohne die umschließenden Klammern interpretiert Redis die Regel schlicht als Erweiterung des Root-Regelsatzes statt als eigenständigen, unabhängigen Selector, was die beabsichtigte Trennung der Zugriffsbereiche unbemerkt aufhebt. Ebenso häufig ist eine vergessene Anführungszeichen-Kapselung der gesamten Selector-Zeichenkette in Shell-Skripten, wodurch die Shell die enthaltenen Klammern und Leerzeichen falsch interpretiert und der Befehl fehlschlägt oder, schlimmer, eine unbeabsichtigt andere Regel erzeugt.

Ein weiterer typischer Stolperstein ist die Annahme, ein in einem Selector erlaubtes Muster wie +@read würde automatisch auch neu eingeführte Lesebefehle künftiger Redis-Versionen abdecken, was zwar grundsätzlich zutrifft, aber bei sicherheitskritischen Selectors dennoch regelmäßig gegen die tatsächlich benötigten Befehle geprüft werden sollte, statt sich blind auf Befehlskategorien zu verlassen. Ein regelmäßiger Abgleich mit ACL CAT, das alle Befehle einer Kategorie auflistet, hilft, Überraschungen bei einem Redis-Upgrade zu vermeiden.

# Alle Befehle der Kategorie "read" auflisten, um Selector-Umfang zu pruefen
ACL CAT read

# Häufiger Fehler: fehlende Klammern machen den Selector zum Root-Satz
ACL SETUSER broken_user on >pass ~orders:* +get +hget +hgetall

10. Zusammenfassung

11. FAQ: ACL Selectors: Das Wichtigste auf einen Blick