Redis-Sicherheit für KI-Agenten — FLUSHALL, KEYS * und Admin-Commands blockieren
Redis-Sicherheit für KI-Agenten fängt Wipe-Commands (FLUSHALL, FLUSHDB, SHUTDOWN), administrative Commands (CONFIG SET, MIGRATE, SCRIPT FLUSH) und blockierende Reads (KEYS *, breite LRANGE / ZRANGE) ab. Redis hat kein EXPLAIN-Äquivalent — FutrixData regelt über Command-Semantik und Key-Patterns.
Redis-Risikofläche
Redis-Risiko ist näher an Command-Sicherheit und Key-Range-Sicherheit als an Query-Optimierung. Die gefährlichen Operationen sind Wipe-Commands, breite Scans, die den Single-Threaded-Server blockieren, und administrative Commands, die Cluster-Zustand, ACLs oder Module ändern.
Eingebaute Redis-Regeln
| Command-Klasse | Standardaktion |
|---|---|
FLUSHALL, FLUSHDB, SHUTDOWN | block |
CONFIG SET, CONFIG RESETSTAT, gefährliche CLUSTER-Subcommands | block |
ACL SETUSER, ACL DELUSER, SCRIPT FLUSH, FUNCTION FLUSH, MODULE LOAD, CLIENT KILL, MIGRATE | block |
Writes — SET, DEL, HSET, LPUSH, SADD, ZADD, EXPIRE, RENAME | warn |
Breite Reads — KEYS, SCAN, HGETALL, SMEMBERS, breite ZRANGE / LRANGE | warn |
Skripte — EVAL, EVALSHA | warn |
Key-Pattern-Regeln
Regeln können nach Key-Pattern konfiguriert werden, zum Beispiel:
session:*erlaubt nur Reads — keine Deletes.- Writes auf
prod:*erfordern Approval. - Reads auf
secrets:*sind nicht erlaubt. - Alle administrativen Commands sind Agenten verboten, auch auf Dev-Quellen.
Warum kein EXPLAIN-Äquivalent für Redis
Redis exponiert keine Pre-Execution-Kostenabschätzung. FutrixData nutzt Command-Semantik und Key-Patterns als Kontrollfläche — es gibt keine Probe-Schicht wie auf dem SQL-EXPLAIN-Pfad. Das ist Absicht: Eine Probe, die selbst KEYS involviert, würde genau das Problem erzeugen, das wir verhindern wollen.
Beispiele
// Agent attempts:
FLUSHALL
// FutrixData response:
{ "ok": false, "risk": "block", "rule": "redis.flush_all" }// Agent attempts:
KEYS *
// FutrixData response:
{ "ok": false, "risk": "warn", "rule": "redis.broad_scan",
"reason": "KEYS * blocks the server on large keyspaces; use SCAN with MATCH" }Häufig gestellte Fragen
Wird Redis Cluster unterstützt?
Ja. Cluster-Verbindungen werden automatisch erkannt, und Regeln gelten pro Command. Gefährliche CLUSTER-Subcommands (CLUSTER FAILOVER, CLUSTER RESET) sind standardmäßig blockiert.
Werden blockierende Commands behandelt?
Ja. BLPOP, BRPOP und WAIT werden erkannt; Sie können Timeouts scopen und für unbegrenzte blockierende Aufrufe Approval verlangen.
Kann ich FLUSHDB nur auf Dev-Keys erlauben?
Ja — pro Datenquelle. FLUSHDB auf prod-redis blockieren, auf dev-redis erlauben (oder warnen). Der Trust-Modus ist ein weiterer Hebel: Dev-Quellen auf Trusted, Prod auf Cautious.
Was ist mit Lua-Skripten (EVAL)?
EVAL / EVALSHA landen standardmäßig auf warn. Sie können sie pro Quelle hart blockieren. SCRIPT FLUSH und FUNCTION FLUSH sind sofort blockiert.
Funktioniert das mit Sentinel?
Ja. FutrixData verbindet sich über Sentinel-fähige Redis-Clients; die Regelauswertung ist identisch.
Probieren Sie FutrixData mit Ihrer eigenen Datenbank aus
Kostenlose Desktop-App für macOS, Windows und Linux. Self-hosted Enterprise Edition für produktive Deployments.