Chaque client devrait disposer d’une instance Redis avec son propre mot de passe et sa propre limite de mémoire. Sur un serveur partagé, les clients peuvent lire et vider les données des autres, et un seul gros site peut chasser le cache de tous les autres.
Pourquoi un serveur Redis partagé pose-t-il problème ?
Redis est conçu pour des clients de confiance dans des environnements de confiance, comme le formule sa documentation sur la sécurité. Les clients d’un hébergeur exécutent les extensions de leur choix et ne remplissent donc pas cette condition. Un serveur partagé n’a souvent qu’un seul mot de passe pour tout le monde.
| Risque | Serveur partagé | Instance par client |
|---|---|---|
| Risque : Accès | Serveur partagé : Toute personne qui se connecte peut lire chaque clé, y compris les sessions et les options des autres sites | Instance par client : Un mot de passe ouvre les données d’un seul client |
| Risque : Vidages | Serveur partagé : FLUSHDB ou FLUSHALL vide le cache de tous les clients présents | Instance par client : Un vidage n’atteint qu’un seul client |
| Risque : Mémoire | Serveur partagé : maxmemory s’applique à tout le serveur, et une grande boutique évince les clés des petits sites | Instance par client : Chaque instance a sa propre limite et sa propre politique |
| Risque : Mémoire pleine avec noeviction | Serveur partagé : Les écritures de tous les clients échouent | Instance par client : Les écritures d’un seul client échouent |
| Risque : Surveillance | Serveur partagé : Le taux de succès, la mémoire et les connexions ne se distinguent pas par client | Instance par client : Chaque instance a ses propres chiffres |
| Risque : Redémarrages et mises à niveau | Serveur partagé : Ils touchent tous les clients en même temps | Instance par client : Ils peuvent se faire instance par instance |
| Risque : Exploitation | Serveur partagé : Un seul processus à exploiter | Instance par client : Un processus par client, ce qui exige de l’automatisation |
Les bases numérotées n’apportent aucune séparation. SELECT permet de passer de l’une à l’autre, et la documentation de Redis déconseille de les utiliser pour des applications sans rapport entre elles.
Les utilisateurs ACL suffisent-ils ?
Redis 6 a ajouté les utilisateurs ACL, et un motif de clé tel que ~tenant1:* peut limiter un utilisateur à un seul préfixe. Les motifs de clé ne couvrent que les commandes qui nomment des clés. FLUSHALL, FLUSHDB et SWAPDB doivent être retirées explicitement de chaque utilisateur.
Les ACL règlent le problème d’accès, alors que la mémoire, l’éviction et les redémarrages restent partagés. Elles conviennent à un hébergeur qui exécute une application de confiance par utilisateur. Pour des clients qui installent leurs propres extensions, une instance séparée constitue la frontière la plus nette.
Que doit comporter une instance Redis par client ?
- Son propre mot de passe, généré, affiché uniquement au client et renouvelable à tout moment.
- Son propre maxmemory, dimensionné pour le client, avec une politique d’éviction telle que allkeys-lru, afin qu’un cache plein continue d’accepter les écritures.
- Une connexion chiffrée ou interne. Le trafic Redis transporte des options, des sessions et des données personnelles, et il doit passer par un réseau interne ou par TLS.
- Une surveillance de la mémoire, des connexions, du taux de succès et de la disponibilité par instance, visible pour l’hébergeur et pour le client.
- Des limites par client pour le nombre d’instances et la mémoire totale, ainsi qu’une limite de capacité par serveur.
- Une persistance uniquement là où elle est nécessaire. Un cache d’objets peut être reconstruit, si bien que les fichiers RDB et AOF ajoutent surtout des écritures sur le disque.
Comment un site se connecte-t-il à son instance ?
Le client a besoin de l’hôte, du port, du mot de passe et du réglage TLS. La plupart des extensions Redis pour WordPress lisent ces valeurs dans des constantes de wp-config.php ; un panneau qui affiche un bloc prêt à copier épargne donc des demandes d’assistance.
Plusieurs sites d’un même client peuvent partager une instance si chacun a son propre préfixe de clé. Un vidage sur une telle instance doit rester limité à ce préfixe.
Comment un hébergeur peut-il mettre cela en place ?
Des conteneurs ou des unités systemd avec une configuration par client suffisent du côté de Redis. Le travail porte sur le provisionnement, le renouvellement des mots de passe, les limites et une vue pour le client.
Pour ISPConfig, CachePilot Server de CMS ADMINS, actuellement en bêta, couvre ces éléments. Les clients créent des instances dans le panneau, prêtes en 60 secondes environ, avec 128, 256 ou 512 Mo. Il exécute un Redis standard par client, et il ne propose ni utilisateurs ACL, ni sockets Unix, ni sauvegardes, ni configuration automatique de WordPress. La page CachePilot Server donne le périmètre complet.
Sources
- Documentation de Redis, sécurité : clients de confiance, accès réseau, TLS.
- Documentation de Redis, ACL : motifs de clé et commandes sans argument de clé.
- Documentation de Redis, SELECT : bases numérotées.
- Documentation de Redis, éviction des clés : maxmemory et politiques.
- README.md et CHANGELOG.md de l’extension ISPConfig, versions 1.0.0 et 1.1.0.
- redis_instance.tform.php de l’extension ISPConfig : tailles de mémoire.
