Sécurité Redis

Durcissement en production pour Redis : authentification, contrôle d'accès basé sur les ACL, et exposition réseau. Couvrir les trois ensemble — chacun seul laisse une faille exploitable.

Quand appliquer

• Déployer ou examiner une instance Redis destinée à la production.
• Configurer des credentials d'application au-delà d'un mot de passe partagé.
• Auditer un déploiement Redis par rapport à une checklist de sécurité.
• Recevoir des findings "Redis exposé à internet" d'un scanner.

1. Toujours authentifier (et utiliser TLS)

Ne jamais exécuter un Redis de production sans mot de passe. Associer l'authentification à TLS pour que les credentials et les données ne soient pas envoyés en clair.

# redis.conf
requirepass your-strong-password
tls-port 6380
tls-cert-file /path/to/redis.crt
tls-key-file  /path/to/redis.key

r = redis.Redis(
    host="localhost",
    port=6380,
    password="your-strong-password",
    ssl=True,
    ssl_cert_reqs="required",
)

Si tu peux utiliser des utilisateurs ACL (section suivante) à la place du requirepass unique, fais-le — requirepass est effectivement le raccourci hérité de l'« utilisateur par défaut ».

Voir references/auth.md.

2. ACLs pour un accès avec moindre privilège

L'utilisateur default avec un mot de passe partagé convient au développement. Pour la production, donner à chaque application un utilisateur ACL dédié avec seulement les commandes et patterns de clés dont elle a réellement besoin.

# Lecteur cache uniquement
ACL SETUSER app_readonly on >password ~cache:* +get +mget +scan

# Writer qui ne peut pas exécuter les opérations dangereuses
ACL SETUSER app_writer   on >password ~*        +@all -@dangerous

# Admin (à utiliser avec parcimonie, jamais pour le trafic d'application)
ACL SETUSER admin        on >strong-password ~* +@all

Catégories de commandes utiles :

Si les credentials de l'app fuient, une ACL stricte limite le rayon d'explosion — l'attaquant ne peut pas FLUSHALL ta DB juste parce qu'il a volé le mot de passe d'un lecteur de cache.

Voir references/acls.md.

3. Restreindre l'accès réseau

La violation Redis la plus courante est un Redis sur l'internet public sans auth. L'éviter avec trois couches :

# redis.conf — bind sur des interfaces spécifiques, keep protected-mode on
bind 127.0.0.1 192.168.1.100
protected-mode yes

# Firewall — autoriser seulement les subnets d'application
iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

Anti-pattern : bind 0.0.0.0 + protected-mode no — expose Redis à tout le réseau sans protection.

Optionnel mais recommandé : renommer ou désactiver les commandes destructrices pour qu'un client compromis ne puisse pas endommager la DB :

rename-command FLUSHALL ""
rename-command DEBUG ""
rename-command CONFIG ""

Voir references/network.md.

Références

• Redis: Security
• Redis: ACL