Comment sécuriser les installations Redis : conseils de configuration essentiels

Redis est rapide, simple et souvent utilisé par le code applicatif pour les données de session, les files d'attente, les compteurs et les enregistrements en cache. Cela rend la sécurité de Redis importante : une instance exposée peut permettre à un attaquant de lire des données, de supprimer des clés avec FLUSHALL ou d'abuser des commandes administratives.

Votre objectif est de rendre Redis accessible uniquement depuis les systèmes qui en ont besoin, d'exiger une authentification, de réduire l'accès aux commandes dangereuses et de protéger les fichiers qui contiennent la configuration et les données persistées.

---

1. Configuration réseau : limiter l'exposition

La mesure de sécurité la plus immédiate consiste à contrôler les interfaces réseau sur lesquelles Redis écoute. De nombreuses installations Redis packagées se lient à localhost par défaut, mais les images conteneur, les fichiers de configuration personnalisés et les déploiements plus anciens peuvent différer. Vérifiez toujours votre redis.conf actif au lieu de supposer que la valeur par défaut est sûre.

Liaison à des interfaces spécifiques (bind)

Vous devez configurer Redis pour qu'il écoute uniquement sur les interfaces nécessaires. Dans la plupart des environnements de production, cela signifie se lier uniquement à l'adresse de boucle locale ou à une adresse IP privée spécifique utilisée par les serveurs d'applications.

Accès interne ou local uniquement

Si votre serveur d'applications réside sur le même hôte que Redis, liez-vous exclusivement à l'adresse de boucle locale.

# Extrait de configuration redis.conf
bind 127.0.0.1

Accès privé en réseau

Si vos serveurs d'applications sont sur un segment de réseau privé et ont besoin d'un accès réseau, liez-vous à cette adresse IP privée spécifique. Ne liez pas Redis à une adresse IP publique accessible sur Internet. Si vous avez besoin d'un accès à distance, placez-le sur un réseau privé et restreignez le trafic avec des règles de pare-feu ou des groupes de sécurité.

# Listez les adresses IP internes spécifiques qui doivent accéder à Redis
bind 192.168.1.100 10.0.0.5

Comprendre le mode protégé

Depuis Redis 3.2, le mode protégé est activé par défaut dans les builds Redis standard. Il aide à bloquer l'accès externe lorsque Redis n'est pas explicitement configuré pour les clients distants. Traitez-le comme un filet de sécurité, pas comme votre contrôle principal. Utilisez des restrictions de liaison, une authentification et des règles de pare-feu.

Si vous devez le désactiver pour une configuration spécifique, vous pouvez utiliser :

protected-mode no

Avertissement : Ne désactivez protected-mode que lorsque vous avez correctement configuré bind, l'authentification et le filtrage réseau.

2. Authentification et contrôle d'accès

Une fois l'accès réseau restreint, la couche de défense suivante est l'authentification. Les clients ne devraient pouvoir interagir avec Redis que s'ils fournissent un mot de passe valide ou, de préférence, utilisent le système moderne de liste de contrôle d'accès (ACL).

Implémentation de la protection par mot de passe (requirepass)

Utilisez la directive requirepass dans votre fichier redis.conf pour imposer l'authentification du client. Cela agit comme un secret partagé global pour une sécurité de base.

# Définissez un mot de passe fort et unique
requirepass T4h!S_Est_Tr3s_S3curis3_Mdp

Pour se connecter en utilisant un mot de passe, les clients doivent utiliser la commande AUTH :

# Exemple avec redis-cli
$ redis-cli
127.0.0.1:6379> AUTH T4h!S_Est_Tr3s_S3curis3_Mdp
OK
127.0.0.1:6379> PING
PONG

Sécurité avancée : listes de contrôle d'accès Redis (ACL)

Pour les environnements de production exécutant Redis 6.0 et versions ultérieures, les ACL sont la méthode d'authentification préférée. Les ACL vous permettent de définir plusieurs utilisateurs avec des mots de passe spécifiques et des autorisations granulaires (par exemple, l'utilisateur A peut seulement lire, l'utilisateur B peut écrire dans des espaces de clés spécifiques).

La configuration ACL implique généralement de définir des utilisateurs et leurs règles dans redis.conf ou un fichier ACL séparé :

# Exemple de définitions d'utilisateurs ACL dans redis.conf ou un fichier aclfile
user default off
user app_reader on >app_read_P@ss ~cache:* +get +scan
user app_writer on >app_write_P@ss ~data:* +set +del

Renommer ou désactiver les commandes dangereuses

Certaines commandes administratives (comme FLUSHALL, CONFIG, KEYS et SHUTDOWN) peuvent provoquer des perturbations opérationnelles ou exposer des détails de configuration sensibles en cas de mauvaise utilisation. Il est de bonne pratique de renommer ces commandes avec des noms obscurs ou de les désactiver complètement.

Pour renommer une commande, utilisez rename-command :

# Renommer la commande CONFIG pour empêcher les modifications non autorisées
rename-command CONFIG CACHE_MON_CONFIG

# Désactiver complètement FLUSHALL
rename-command FLUSHALL ""

3. Bonnes pratiques de sécurité opérationnelle

Au-delà de la configuration interne de Redis, l'application de mesures de sécurité opérationnelles externes robustes est cruciale pour une posture de sécurité complète.

Appliquer des règles de pare-feu strictes

Quelle que soit la configuration de la directive bind, appliquez toujours un filtrage réseau en utilisant des groupes de sécurité cloud, iptables ou des solutions de pare-feu similaires. Le port Redis par défaut (6379) ne doit être ouvert qu'aux adresses IP spécifiques ou aux plages d'adresses IP de vos serveurs d'applications de confiance.

Exemple de règle de pare-feu (Linux/iptables)

Autoriser le trafic entrant sur le port 6379 uniquement depuis une adresse IP de serveur d'applications connue (192.168.1.50) :

# Autoriser un serveur d'applications spécifique
iptables -A INPUT -p tcp -s 192.168.1.50 --dport 6379 -j ACCEPT

# Refuser tout autre trafic Redis entrant
iptables -A INPUT -p tcp --dport 6379 -j DROP

Exécution avec le moindre privilège

N'exécutez jamais le processus serveur Redis en tant qu'utilisateur root. Si un attaquant compromet le processus Redis, l'exécuter en tant que root lui donne un contrôle total sur l'ensemble du système d'exploitation.

Créez un utilisateur système dédié et non privilégié, comme redis, puis configurez votre gestionnaire de services pour exécuter le processus Redis en tant que cet utilisateur. Avec systemd, cela est normalement géré dans le fichier unité avec des directives telles que User=redis et Group=redis, ou par le service packagé fourni par votre distribution.

Sécurisation des fichiers de configuration et de persistance

Le fichier redis.conf contient des informations sensibles comme le mot de passe requirepass et les paramètres réseau. Assurez-vous que ce fichier, ainsi que les fichiers de persistance (instantanés RDB et journaux AOF), soient protégés par des permissions de fichier restrictives, empêchant la lecture ou la modification non autorisée par d'autres utilisateurs du système.

# Exemple de permissions recommandées
# Seuls l'utilisateur 'redis' et root doivent pouvoir lire/écrire
chown redis:redis /etc/redis/redis.conf
chmod 600 /etc/redis/redis.conf

Implémentation du chiffrement SSL/TLS

Pour les environnements où le trafic Redis traverse un segment réseau non fiable (même en interne), implémentez le chiffrement SSL/TLS. Bien que Redis ait historiquement manqué de support TLS natif, les versions modernes (à partir de Redis 6) le supportent pleinement. La configuration de TLS nécessite de générer des certificats et de définir les directives pertinentes dans redis.conf :

# Activer l'écouteur TLS
tls-port 6379
port 0
tls-auth-clients yes
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt

port 0 désactive l'écouteur en texte clair. Ne conservez un port en texte clair que lorsque chaque client qui l'utilise se trouve sur un chemin local de confiance et que vous avez une raison claire.

Résumé des étapes de sécurité essentielles

Sécuriser une installation Redis est un travail en couches. Commencez par l'exposition, puis l'authentification, puis les contrôles opérationnels :

1. Restreindre l'accès réseau : Utilisez bind 127.0.0.1 ou des adresses IP privées spécifiques.
2. Imposer l'authentification : Utilisez requirepass (basique) ou les ACL (avancé).
3. Durcir les commandes : Désactivez ou renommez les commandes administratives dangereuses (FLUSHALL, CONFIG).
4. Utiliser des pare-feu : Autorisez uniquement le trafic sur le port 6379 depuis les serveurs d'applications de confiance.
5. Moindre privilège : Exécutez le processus Redis en tant qu'utilisateur dédié non root.
6. Chiffrer le trafic : Activez SSL/TLS pour les connexions réseau lorsque cela est approprié.