Durcissement de la sécurité Redis / Valkey (ACL, TLS, commandes dangereuses)

Ni une installation ni un guide d'exploitation courante : runbook par scénarios pour durcir sans interruption un Redis ou un Valkey en service (serveur unique, replica + Sentinel ou Cluster). Audit de sécurité en lecture seule, utilisateurs ACL et désactivation de l'utilisateur default, requirepass/masterauth, bind et protected-mode, protected configs contre l'abus de CONFIG/DEBUG/MODULE, passage à TLS à chaud (clients, réplication, Sentinel, cluster bus) et droits sur les fichiers ; à la fin, l'audit est relancé pour montrer que les risques sont fermés. Les systèmes installés avec les guides DBAtlas disposent déjà d'un mot de passe et d'un firewall restrictif : commencez par l'audit et n'appliquez que les scénarios signalés RISK ou WARN. La sauvegarde et l'exploitation courante font l'objet de guides Redis distincts.

Topologie: Serveur unique, master + replica + Sentinel, ou Redis Cluster

Scénarios

• Audit de l'état de sécurité (lecture seule) — Ne modifie rien. L'accès sans mot de passe, l'utilisateur default, les adresses d'écoute, protected-mode, les commandes dangereuses, TLS, le mot de passe Sentinel et les droits sur les fichiers sont signalés en OK / WARN / RISK. Choisissez ce scénario si vous ne savez pas par où commencer.
• Durcissement complet (tout, dans l'ordre) — Audit → utilisateurs ACL (administrateur, application, réplication, Sentinel) et désactivation de l'utilisateur default → bind/protected-mode/firewall → commandes dangereuses et protected configs → TLS → droits sur les fichiers → audit final. En rolling sur les replicas/Sentinel ; les étapes risquées demandent confirmation.
• Utilisateurs ACL et désactivation de l'utilisateur default (Redis 6+) — Tout le monde se connecte en tant qu'utilisateur default avec un mot de passe unique (ou sans). Des utilisateurs distincts sont créés pour l'administrateur, l'application (ses seules clés, sans commandes dangereuses), la réplication et Sentinel, écrits dans l'aclfile, puis default est désactivé une fois les applications migrées.
• Redis sans mot de passe : requirepass / masterauth (mesure rapide) — Aucun mot de passe n'est défini et le temps manque pour passer aux ACL. Un mot de passe commun est appliqué à chaud sur tous les nœuds (requirepass + masterauth pour la réplication, auth-pass pour Sentinel) ; les applications ne peuvent plus se connecter sans mot de passe.
• Restreindre l'accès réseau (bind 0.0.0.0, protected-mode, firewall) — Redis écoute sur toutes les interfaces ou tourne avec protected-mode no. bind est réduit à localhost + l'IP interne, protected-mode est activé et le firewall n'autorise que les nœuds et le réseau applicatif. Appliqué à chaud, sans couper les connexions existantes ; c'est l'étape qui réduit le risque le plus vite.
• Commandes dangereuses et abus de CONFIG (FLUSHALL, CONFIG, DEBUG, MODULE) — Contre l'abus de CONFIG SET dir/dbfilename pour écrire des fichiers sur le serveur (clé SSH, cron) et contre FLUSHALL/DEBUG/MODULE LOAD : enable-protected-configs, enable-debug-command, enable-module-command restent désactivés et @dangerous est retiré aux applications ; sur les anciennes versions, rename-command.
• Chiffrer les connexions : TLS (clients, réplication, Sentinel, cluster bus) — Le trafic n'est pas chiffré. Le port TLS est ouvert à chaud à côté du port existant, la réplication et Sentinel passent en TLS, puis le port en clair est fermé (port 0) une fois les applications basculées.
• Droits sur les fichiers et utilisateur de service — redis.conf (qui contient des mots de passe), le fichier ACL, les fichiers RDB/AOF et les logs sont lisibles par d'autres utilisateurs, ou Redis tourne en root. Les droits sont ramenés à 640/750 et le propriétaire devient l'utilisateur de service.

Avant de commencer

• root/sudo sur tous les nœuds ; SSH du premier nœud vers les autres (copie du fichier de mots de passe et des certificats).
• Redis 6.2+ ou Valkey 7.2+ (6.0+ pour les ACL, 7.0+ pour les protected configs).
• La réplication… et Sentinel… sont en bonne santé ; aucune opération rolling n'est faite sur une topologie dégradée.
• Liste des applications et versions des bibliothèques clientes : nom d'utilisateur + mot de passe pour les ACL (client Redis 6+), prise en charge de rediss:// pour TLS ; pour les clients qui passent par Sentinel, prise en charge du mot de passe Sentinel et de TLS.
• openssl est installé (génération des mots de passe et des certificats).

Phases du guide

• Préparation : filet de sécurité et outils d'assistance — Sauvegarde de la configuration et des ACL · Écrire les outils d'assistance (dbatlas-rconf, dbatlas-rcli, dbatlas-redis-restart) · Écrire le mot de passe administrateur dans un fichier temporaire
• Audit de l'état (lecture seule) — Rapport de sécurité : … · Rapport Sentinel : … · Faire correspondre les constats aux scénarios
• Mot de passe : requirepass et masterauth (à chaud) — Définir le mot de passe commun : … · masterauth : … · auth-pass Sentinel : … · requirepass : … · Mot de passe pour Sentinel : … · La réplication et Sentinel sont-ils en bonne santé …
• ACL : diagnostic et mots de passe des utilisateurs — Diagnostic : qui est connecté avec quel utilisateur ? · Générer les mots de passe des utilisateurs internes · Copier le fichier de mots de passe sur les autres nœuds
• ACL : désactiver l'utilisateur default — Reste-t-il des clients connectés en default : … · Désactiver l'utilisateur default : … · Vérifier : accès sans authentification, privilèges applicatifs, réplication · Mot de passe pour Sentinel : …
• Accès réseau : firewall — Règles de firewall
• Commandes dangereuses : diagnostic — Protected configs et commandes debug/module : …
• Commandes dangereuses : vérification — CONFIG SET dir et DEBUG sont-ils rejetés : …
• TLS : certificats — Prise en charge de TLS : … · Générer la CA interne et les certificats serveur · Distribuer les certificats · Droits des certificats : …
• TLS · Cluster bus et réplication (fenêtre de maintenance, tous les nœuds ensemble) — Fixer le port bus, écrire tls-cluster et tls-replication dans le fichier : … · Arrêter : … · Démarrer : … · Le cluster et la réplication sont-ils en TLS
• TLS : vérification et fermeture du port en clair — La réplication… et Sentinel… sont-ils en TLS · Fermer le port en clair : … · La connexion non chiffrée est-elle rejetée : …
• Droits sur les fichiers et utilisateur de service — Corriger les droits : …
• Audit final (après durcissement) — Rapport de sécurité : … (état final) · Rapport Sentinel : … (état final)
• Nettoyage et suivi — Supprimer les fichiers de mots de passe temporaires · Suivi : supervision et tâches périodiques