data / redis

Sécurité : ACL et TLS

Leçon 151 exercice

Explication

Ce que vous allez apprendre

Comprendre pourquoi un Redis exposé sans authentification est une faille critique
Créer des utilisateurs ACL avec des permissions précises par motif de clés et par commande
Chiffrer le trafic client-serveur avec TLS, et l'authentifier mutuellement avec mTLS
Configurer un client Python (redis-py) pour se connecter en TLS avec un utilisateur ACL
Appliquer une checklist de sécurité minimale avant toute mise en production

Dans quel contexte ?

En 2026, il reste extrêmement courant que des scans automatisés parcourent Internet à la recherche d'instances Redis exposées sans mot de passe — un Redis mal configuré peut être compromis en quelques minutes, permettant à un attaquant de lire, modifier ou vider entièrement les données, voire d'utiliser certaines commandes pour obtenir une exécution de code sur le serveur hôte. Sécuriser Redis n'est donc pas optionnel dès qu'une instance est accessible au-delà d'un unique poste de développement.

D'abord, l'authentification la plus simple : un mot de passe unique

requirepass dans redis.conf impose un mot de passe unique pour toute connexion, vérifié ensuite avec AUTH. C'est un minimum vital, mais cette approche a une limite évidente : tous les clients partagent le même mot de passe et donc les mêmes droits complets sur toute la base.

Prérequis

Cette leçon suppose une bonne compréhension des commandes Redis courantes et de la notion de motif de clé (produit:*), pour bien comprendre la granularité des ACL.

Une fois cette limite identifiée, les ACL apportent un contrôle bien plus fin

Depuis Redis 6, ACL SETUSER permet de créer des utilisateurs distincts, chacun limité à un sous-ensemble précis de clés (via des motifs comme ~produit:*) et à un sous-ensemble précis de commandes (via +get, -@dangerous). Ce principe du moindre privilège limite fortement les dégâts possibles si les identifiants d'un seul service venaient à fuiter.

Élément de la commande ACL	Rôle
`on` / `off`	Active ou désactive l'utilisateur
`>motdepasse`	Définit le mot de passe (haché en interne)
`~motif:*`	Restreint l'accès à certains motifs de clés uniquement
`+commande` / `-commande`	Autorise ou interdit une commande précise
`-@dangerous`	Interdit toute une catégorie de commandes sensibles

Piège courant

Créer un utilisateur ACL sans restreindre les motifs de clés (~* par défaut) revient presque à ne pas utiliser d'ACL du tout. Prends toujours le temps de définir précisément quelles clés chaque service applicatif a réellement besoin de toucher.

Il reste un problème que les ACL ne résolvent pas seules : le trafic réseau lui-même

Sans TLS, tout le trafic entre client et serveur Redis — y compris les mots de passe échangés lors de l'authentification — circule en clair sur le réseau. TLS chiffre ce trafic, et le mTLS (authentification mutuelle par certificat) va plus loin en exigeant que le client prouve aussi son identité, pas seulement le serveur.

Bonne pratique

Applique systématiquement cette checklist avant toute mise en production : authentification activée, un utilisateur ACL distinct par service avec le strict nécessaire, rename-command FLUSHALL "" pour neutraliser les commandes destructrices, et jamais de Redis exposé directement sur Internet sans protection réseau supplémentaire (VPN, pare-feu, groupe de sécurité cloud).

Maintenant que l'accès à Redis est sécurisé, la prochaine leçon s'attaque à un tout autre défi de production : faire tenir un volume de données qui dépasse la capacité d'une seule machine, grâce au clustering et au sharding.

Commandes & code

Sécurité : ACL et TLS

# --- Mot de passe simple (ancienne méthode, toujours supportée) ---
# redis.conf
requirepass "un_mot_de_passe_tres_solide"

redis-cli -a un_mot_de_passe_tres_solide PING
AUTH un_mot_de_passe_tres_solide           # depuis une session déjà ouverte

# --- ACL (Access Control List), depuis Redis 6 : utilisateurs multiples, permissions fines ---
# Créer un utilisateur en lecture seule sur un sous-ensemble de clés
ACL SETUSER app_readonly on >motdepasse123 ~produit:* ~stock:* +get +mget +exists -@dangerous

# Décomposition de la commande :
# on                  -> active l'utilisateur
# >motdepasse123      -> définit le mot de passe (haché en interne)
# ~produit:* ~stock:* -> autorise UNIQUEMENT les clés matchant ces motifs
# +get +mget +exists  -> autorise uniquement ces commandes
# -@dangerous          -> interdit toute la catégorie de commandes dangereuses (FLUSHALL, CONFIG...)

# Utilisateur applicatif avec droits d'écriture limités
ACL SETUSER app_writer on >motdepasse456 ~session:* +set +get +expire +del -@admin

# Lister les utilisateurs et leurs permissions
ACL LIST
ACL GETUSER app_readonly
ACL CAT                              # liste les catégories de commandes (@read, @write, @admin...)
ACL WHOAMI                            # utilisateur de la session courante

# Supprimer un utilisateur, sauvegarder les ACL dans un fichier
ACL DELUSER app_readonly
ACL SAVE                              # persiste dans aclfile (si configuré)

# --- TLS : chiffrer le trafic entre client et serveur ---
# redis.conf
tls-port 6380
port 0                                # désactive le port non chiffré
tls-cert-file /etc/redis/certs/redis.crt
tls-key-file /etc/redis/certs/redis.key
tls-ca-cert-file /etc/redis/certs/ca.crt
tls-auth-clients yes                  # exige un certificat client (mTLS)

# Connexion cliente en TLS
redis-cli --tls --cert client.crt --key client.key --cacert ca.crt -h redis.example.com -p 6380

import redis

# Client Python avec TLS + ACL
r = redis.Redis(
    host="redis.example.com",
    port=6380,
    username="app_readonly",
    password="motdepasse123",
    ssl=True,
    ssl_ca_certs="ca.crt",
    ssl_certfile="client.crt",
    ssl_keyfile="client.key",
    decode_responses=True,
)

# Checklist sécurité production :
# - JAMAIS de Redis exposé sur Internet sans authentification (scans automatiques massifs)
# - Un utilisateur ACL PAR service, avec le strict nécessaire (~motifs de clés + commandes)
# - `rename-command FLUSHALL ""` désactive/renomme des commandes dangereuses en prod
# - `protected-mode yes` par défaut : refuse les connexions externes sans mot de passe configuré

Résumé

Les ACL (Redis 6+) permettent un contrôle fin par utilisateur : motifs de clés autorisés ET commandes autorisées.
TLS chiffre le trafic ; le mTLS (certificat client) ajoute une authentification forte au niveau transport.
Un Redis en production doit toujours avoir authentification, ACL par service, et ne jamais être exposé sans protection.

Exercices pratiques

1 disponible

Mission : limiter les dégâts après la fuite accidentelle d'un identifiant de service

Objectif : Corriger un utilisateur ACL trop permissif, en créer un correctement restreint, et expliquer pourquoi le chiffrement TLS reste indispensable même avec des ACL bien configurées.

Contexte

Un développeur a poussé accidentellement les identifiants Redis d'un service de logs sur un dépôt GitHub public. L'utilisateur ACL en question a été créé avec un motif de clés bien trop large. Tu dois évaluer les dégâts possibles, corriger le design des permissions pour un nouveau service, puis répondre à une question sur la nécessité du TLS malgré des ACL bien configurées.

Résoudre l’exercice →