Jeder Kunde sollte eine Redis-Instanz mit eigenem Passwort und eigenem Speicherlimit haben. Auf einem gemeinsamen Server können Kunden gegenseitig ihre Daten lesen und leeren, und eine große Website kann den Cache aller anderen verdrängen.
Warum ist ein gemeinsamer Redis-Server ein Problem?
Redis ist laut seiner Sicherheitsdokumentation für vertrauenswürdige Clients in vertrauenswürdigen Umgebungen ausgelegt. Hosting-Kunden betreiben Plugins ihrer eigenen Wahl und erfüllen diese Bedingung deshalb nicht. Ein gemeinsamer Server hat oft ein einziges Passwort für alle.
| Risiko | Gemeinsamer Server | Instanz je Kunde |
|---|---|---|
| Risiko: Zugriff | Gemeinsamer Server: Wer sich verbindet, kann jeden Schlüssel lesen, auch Sitzungen und Optionen anderer Websites | Instanz je Kunde: Ein Passwort öffnet nur die Daten eines Kunden |
| Risiko: Leeren | Gemeinsamer Server: FLUSHDB oder FLUSHALL leert den Cache aller Kunden auf dem Server | Instanz je Kunde: Das Leeren trifft nur einen Kunden |
| Risiko: Speicher | Gemeinsamer Server: maxmemory gilt für den ganzen Server, und ein großer Shop verdrängt die Schlüssel kleiner Websites | Instanz je Kunde: Jede Instanz hat ihr eigenes Limit und ihre eigene Policy |
| Risiko: Voller Speicher unter noeviction | Gemeinsamer Server: Schreibzugriffe aller Kunden schlagen fehl | Instanz je Kunde: Nur die Schreibzugriffe eines Kunden schlagen fehl |
| Risiko: Überwachung | Gemeinsamer Server: Trefferquote, Speicher und Verbindungen lassen sich nicht je Kunde trennen | Instanz je Kunde: Jede Instanz hat eigene Kennzahlen |
| Risiko: Neustarts und Upgrades | Gemeinsamer Server: Sie treffen alle Kunden gleichzeitig | Instanz je Kunde: Sie lassen sich Instanz für Instanz durchführen |
| Risiko: Betrieb | Gemeinsamer Server: Ein einziger Prozess | Instanz je Kunde: Ein Prozess je Kunde, das erfordert Automatisierung |
Nummerierte Datenbanken bringen keine Trennung. SELECT wechselt zwischen ihnen, und die Redis-Dokumentation rät davon ab, sie für voneinander unabhängige Anwendungen zu nutzen.
Reichen ACL-Benutzer aus?
Redis 6 führte ACL-Benutzer ein, und ein Schlüsselmuster wie ~tenant1:* kann einen Benutzer auf ein Präfix beschränken. Schlüsselmuster gelten nur für Befehle, die Schlüssel benennen. FLUSHALL, FLUSHDB und SWAPDB müssen jedem Benutzer ausdrücklich entzogen werden.
ACLs lösen das Zugriffsproblem, Speicher, Eviction und Neustarts bleiben aber gemeinsam. Sie passen zu einem Hoster, der je Benutzer eine vertrauenswürdige Anwendung betreibt. Für Kunden, die eigene Plugins installieren, ist eine eigene Instanz die klarere Grenze.
Was sollte eine Redis-Instanz je Kunde haben?
- Ein eigenes Passwort, generiert, nur dem Kunden angezeigt und jederzeit rotierbar.
- Ein eigenes maxmemory, passend zum Kunden bemessen, mit einer Eviction Policy wie allkeys-lru, damit ein voller Cache weiter Schreibzugriffe annimmt.
- Eine verschlüsselte oder interne Verbindung. Der Redis-Verkehr enthält Optionen, Sitzungen und personenbezogene Daten und gehört in ein internes Netz oder hinter TLS.
- Überwachung von Speicher, Verbindungen, Trefferquote und Uptime je Instanz, sichtbar für Hoster und Kunde.
- Limits je Kunde für die Zahl der Instanzen und den Gesamtspeicher, dazu ein Kapazitätslimit je Server.
- Persistenz nur bei Bedarf. Ein Object Cache lässt sich neu aufbauen, RDB- und AOF-Dateien verursachen deshalb meist nur zusätzliche Schreibzugriffe auf die Festplatte.
Wie verbindet sich eine Website mit ihrer Instanz?
Der Kunde braucht Host, Port, Passwort und die TLS-Einstellung. Die meisten Redis-Plugins für WordPress lesen diese Werte aus Konstanten in der wp-config.php. Ein Panel, das einen fertigen Block zum Kopieren zeigt, erspart deshalb Support-Anfragen.
Mehrere Websites eines Kunden können sich eine Instanz teilen, wenn jede ihr eigenes Schlüsselpräfix hat. Das Leeren muss auf einer solchen Instanz auf dieses Präfix beschränkt bleiben.
Wie kann ein Hoster das umsetzen?
Auf der Redis-Seite reichen Container oder systemd-Units mit einer Konfiguration je Kunde. Die Arbeit liegt in der Bereitstellung, der Passwort-Rotation, den Limits und einer Ansicht für den Kunden.
Für ISPConfig deckt CachePilot Server von CMS ADMINS, derzeit in der Beta, diese Teile ab. Kunden legen Instanzen mit 128, 256 oder 512 MB im Panel an, nach rund 60 Sekunden stehen sie bereit. Je Kunde läuft Standard-Redis, ohne ACL-Benutzer, Unix-Sockets, Backups oder automatische WordPress-Konfiguration. Den vollen Umfang beschreibt die Seite zu CachePilot Server.
Quellen
- Redis-Dokumentation, Sicherheit: vertrauenswürdige Clients, Netzwerkzugriff, TLS.
- Redis-Dokumentation, ACL: Schlüsselmuster und Befehle ohne Schlüsselargumente.
- Redis-Dokumentation, SELECT: nummerierte Datenbanken.
- Redis-Dokumentation, Key Eviction: maxmemory und Policies.
- README.md und CHANGELOG.md der ISPConfig-Extension, Versionen 1.0.0 und 1.1.0.
- redis_instance.tform.php der ISPConfig-Extension: Speichergrößen.
