Passer au contenu 
Je mets ACL Redis dans les environnements multi-utilisateurs de manière ciblée, afin de séparer clairement les commandes, les préfixes de clés et les canaux Pub/Sub. Je veille ainsi à ce que Sécurité Côté serveur, minimise les accès non autorisés et veille à ce que les rôles restent faciles à gérer.
Points centraux
- Séparation de commandes, de clés et de canaux par utilisateur
- Côté serveur Le contrôle prime sur la logique dans l'application
- Espaces de nommage par préfixe de clé pour les mandants
- Fichier ACL pour la maintenabilité et la gestion des versions
- Audits avec ACL LIST et ACL USERS
Principes de base de l'ACL dans les configurations multi-utilisateurs
Je crée un utilisateur distinct pour chaque application, chaque équipe ou chaque client, et je définis ses droits de manière stricte via ACL-règles. Cela m'évite qu'un seul mot de passe global n'ouvre toutes les portes et que des données ne soient écrasées par inadvertance. Je sépare les droits en fonction des commandes, des modèles de clés et des canaux, de sorte que chaque compte ne dispose que des droits nécessaires et rien de plus. Cette isolation côté serveur allège la charge de l’application et augmente la Transparence dans le modèle de sécurité. C'est notamment dans les instances partagées que cela me permet de garder une vue d'ensemble des personnes autorisées à effectuer telle ou telle opération dans tel ou tel espace de noms.
Modèles de droits : séparer clairement les commandes, les clés et les canaux
J'attribue les droits de commande de manière granulaire, par exemple selon des catégories telles que @read et @write, et supprime les groupes à risque tels que @dangerous, qui contiennent des commandes de configuration ou d'administration. Pour les espaces de clés, j’utilise des préfixes uniques tels que app1:*, app2:* ou tenant_a:*, afin que les accès en lecture et en écriture restent limités à un espace de noms bien défini. De cette manière, une tâche peut par exemple utiliser SET et GET, mais uniquement sous son propre préfixe. De plus, je restreins les canaux Pub/Sub afin que les événements ne transitent que par les flux prévus à cet effet. Il en résulte une structure traçable Séparation entre les rôles, les espaces de données et les canaux de communication.
Restriction sécurisée de Pub/Sub
Pour Pub/Sub, je n'autorise que les canaux dont une application a réellement besoin et je bloque systématiquement tout le reste ACL-règles. Cela permet d'empêcher un service de recevoir des événements provenant d'autres sources ou de publier des messages à destination d'abonnés inattendus. Dans les architectures événementielles notamment, ce contrôle réduit le risque de fuite de données ou de perturbation d’autres services. Je documente les canaux autorisés pour chaque utilisateur afin de garantir la clarté de l’intégration et des audits. Ainsi, malgré l’évolution de l’environnement système, je conserve la Contrôle sur les flux de données.
La gestion des utilisateurs et des règles dans la pratique
Je crée de nouveaux utilisateurs à l'aide de la commande ACL SETUSER, j'attribue un mot de passe fort et j'active uniquement les commandes dont le service a besoin, par exemple +@lire et +@write tout en bloquant les commandes à risque. Je définis les espaces de clés autorisés à l'aide de modèles adaptés, et je réglemente les canaux de la même manière. Pour avoir une vue d'ensemble, j'utilise ACL USERS et, grâce à ACL LIST, je peux consulter rapidement les règles actives. Je charge ou enregistre les modifications à l’aide de ACL LOAD et ACL SAVE, afin que la configuration et le fichier restent synchronisés. C’est ainsi que je maintiens la Administration concise, compréhensible et reproductible.
| Commande ACL/Auth | Objectif | Exemple |
|---|---|---|
| ACL SETUSER | Créer/modifier un utilisateur | ACL SETUSER app1 on >motdepassesecurisé +@read +@write -@dangerous ~app1:* |
| LISTE DES ACL | Afficher les règles | LISTE DES ACL |
| UTILISATEURS ACL | Afficher la liste des utilisateurs | UTILISATEURS ACL |
| ACL CHARGER/ENREGISTRER | Charger/sauvegarder un fichier ACL | ACL SAVE ; ACL LOAD |
| AUTH | Connexion au serveur | AUTH app1 mot-de-passe-sécurisé |
Configuration : fichier ACL ou redis.conf ?
J'enregistre des configurations simples directement dans le redis.conf, mais lorsque les utilisateurs et les rôles sont nombreux, je conserve un fichier ACL distinct. Je gère les versions de ce fichier dans un référentiel sécurisé, je documente soigneusement les modifications et je déploie les mises à jour de manière contrôlée. Je sépare ainsi les paramètres de l'application de la logique de sécurité, ce qui réduit les sources d'erreurs. En parallèle, je renforce la sécurité de l’instance au niveau du réseau, par exemple en sécuriser les ports ouverts et élimine les points faibles inutiles. Dans l'ensemble, cela améliore la Sécurité et simplifie son utilisation.
Espaces de noms et séparation des clients
Je conçois les préfixes de clés de manière à ce qu'ils permettent d'identifier clairement les ID de locataires et les noms d'applications, par exemple tenantA :app1:session:{id}. Cela me permet de créer une barrière bien visible autour des données de chaque partie, que les règles ACL renforcent encore davantage. Pour les chemins de migration, j’utilise des schémas de nommage cohérents afin de faciliter les déploiements en mode « blue-green » ou « canary ». Une structure claire est également utile pour les sauvegardes et les restaurations, car elle me permet de ne traiter que les segments de données pertinents. Cette combinaison entre le concept de nommage et les règles ACL garantit la Mandants bien séparés.
Les microservices et les rôles au sein de l'équipe au quotidien
Pour chaque service, je crée un utilisateur qui lit et écrit exclusivement dans ses propres espaces de données, sans avoir accès aux préfixes d’autres utilisateurs ni aux fonctions d’administration. Pour les comptes de développeurs, je définis des droits de lecture ou d’écriture restrictifs, tandis que les comptes d’administrateur restent strictement limités et font l’objet d’une journalisation. Les tâches par lots ne reçoivent que les commandes dont elles ont besoin pour s'exécuter, telles que la lecture, l'écriture et les modifications de TTL, mais aucune commande d'administration. Je limite en outre les intégrations externes dans le temps ou aux environnements de test, afin qu'aucune erreur de configuration ne Productif- les données. C'est ainsi que je répartis clairement les responsabilités sans pour autant compromettre la sécurité.
Limites des listes de contrôle d'accès (ACL) et des niveaux d'isolation
Je considère que les ACL fonctionnent correctement : elles contrôlent les accès, mais ne les isolent pas Ressources telles que le CPU, la mémoire vive (RAM) ou les E/S au niveau des processus. Dans les scénarios de conformité stricte, j’envisage donc des instances dédiées, des clusters séparés ou des nœuds distincts. La séparation logique via des listes de contrôle d’accès (ACL) réduit les accès non autorisés, mais partage les mêmes ressources serveur. Pour les charges de travail sensibles, je prévois une isolation supplémentaire, par exemple via des segments de réseau, des conteneurs ou des machines virtuelles. Je combine ainsi le contrôle d’accès avec des mesures techniques blindage pour un niveau de sécurité accru.
Exploitation : audits, rotation et journalisation
Je vérifie régulièrement les droits à l'aide de la commande ACL LIST et je consigne un calendrier des modifications afin de pouvoir valider rapidement, lors des audits, ce qui est actif. Je renouvelle les mots de passe à intervalles réguliers et je consigne minutieusement les événements de connexion ainsi que les schémas inhabituels. En cas d’incident, je bloque immédiatement les utilisateurs concernés, je charge les règles mises à jour et je teste automatiquement les chemins critiques. Dans le cadre du CI/CD, j’intègre des contrôles qui signalent les commandes interdites ou les préfixes manquants dans les configurations. Ceci Procédure permet de gagner du temps et de réduire au minimum les temps d'arrêt.
Choix architecturaux : mutualisé ou dédié
Je me demande s'il vaut mieux que plusieurs clients partagent une même instance ou si je dois mettre en place des serveurs distincts, car les deux solutions présentent leurs propres Risques et présente des avantages. Le mode « Shared » permet de réduire les coûts, mais exige des listes de contrôle d'accès (ACL) strictes, des espaces de noms bien délimités et une surveillance étroite. Le mode « Dedicated » réduit les interférences, mais nécessite davantage de matériel et d'entretien. En matière de performances et de sécurité, je préfère me baser sur des comparaisons telles que Partagé ou dédié j'étudie la question et je réalise des tests de charge. Au final, je prends ma décision en fonction de l'accès aux données, des exigences de conformité et Budget.
En cluster ou en mode autonome : quelle est la meilleure solution pour les ACL ?
J'utilise les ACL aussi bien dans des instances autonomes que dans des clusters, mais je veille à ce que les règles soient cohérentes sur tous les nœuds. Dans les clusters, je vérifie la répartition des clés entre les slots afin que les préfixes et les droits continuent de s'appliquer de manière pertinente. En cas de haute disponibilité, j'exige que le basculement n'entraîne pas Rupture généré dans la chaîne des droits et dont le fichier ACL est identique partout. Je teste au préalable les chemins de migration afin d'éviter toute faille lors des changements de réplique ou des mises à niveau. Ceux qui évaluent l'architecture peuvent se référer à des comparaisons telles que Cluster ou autonome s'orienter, puis mettre en œuvre la stratégie ACL de manière adaptée.
Planification et Bootstrap : un démarrage en toute sécurité
Je commence par un Bootstrap „ propre “. L'utilisateur « default » intégré ne dispose d'aucun droit étendu : soit je le désactive complètement, soit je lui retire par défaut toutes les commandes, clés et canaux. J'évite ainsi de travailler par inadvertance sans séparation des utilisateurs. Pour les tâches opérationnelles, je définis délibérément des comptes administrateurs distincts, dotés d’une authentification multifactorielle au niveau de la gestion (par exemple, hôte bastion/certificats clients TLS) et de listes de contrôle d’accès (ACL) strictes.
# Démarrage sécurisé dans le fichier ACL
user default off
user admin on >Mot de passe admin fort +@admin -@dangerous allkeys allchannels
Je génère des mots de passe forts côté serveur, afin qu'ils n'apparaissent jamais dans les journaux ni dans l'historique du shell. Pour obtenir des jetons rapides et sécurisés, j'utilise un générateur sur le serveur et je les renouvelle régulièrement. Pour les clients modernes, je privilégie l'authentification via HELLO avec identifiant/mot de passe en une seule étape, ce qui définit explicitement la version du protocole et évite les cas limites.
Exemples et pièges à éviter avec les ACL de clé et de canal
Pour les modèles clés, je travaille exclusivement avec des listes d'autorisations. Je commence par touches de réinitialisation puis j'ajoute de manière ciblée des modèles ~, par exemple ~tenantA:* et ~tenantA:app1:* pour des espaces délimités avec plus de précision. Les préfixes qui se chevauchent posent problème : si un utilisateur dispose de ~tenantA:* et ne doit pas voir des espaces tels que tenantA:archiv:*, je conçois alors les espaces de noms de manière à ce que les sous-ensembles sensibles soient préfixés de manière indépendante (par exemple tenantA:priv:*), que je ne partage tout simplement pas. Des règles similaires s’appliquent aux canaux : je configure réinitialiser les chaînes et n'accorde que &tenantA:* ainsi que les canaux strictement nécessaires aux notifications de l'espace de clés, le cas échéant.
# Clés et canaux stricts
ACL SETUSER tenantA:app1 on >Pass +@read +@write -@dangerous \
resetkeys ~tenantA:app1:* \
resetchannels &tenantA:app1:*
Je note que des commandes telles que RENAME, MIGRATE ou DUMP/RESTORE pourraient écrire au-delà des limites des préfixes. Ces commandes restent bloquées dans les comptes de service en production. Les champs de hachage, les éléments de liste ou les membres d’un ensemble trié ne constituent pas des clés distinctes : la liste de contrôle d’accès (ACL) s’applique au niveau de la clé, et non au sein de la structure de données. C’est pourquoi un concept de préfixe de clé bien défini suffit pour couvrir également ces structures.
Gérer de manière réfléchie les catégories de commandes
Je n'active que ce dont j'ai vraiment besoin. Pour les charges de travail CRUD classiques, les droits +@read et +@write suffisent souvent. Je verrouille systématiquement les catégories présentant un risque accru : @admin et @dangerous sont interdites aux utilisateurs des applications. Dans les configurations multi-locataires, j’évite autant que possible d’utiliser les fonctions de script (EVAL, FUNCTION). Pour les services Pub/Sub, je dissocie les droits de manière à ce que les commandes d’écriture sur les clés ne soient pas automatiquement autorisées. Dans la pratique, je commence par un minimum et, si nécessaire, j’autorise de manière ciblée des commandes individuelles (+COMMAND) plutôt que d’ouvrir des catégories entières.
Rotation et modifications sans interruption de service
Je prévois une rotation des mots de passe sans interruption de service. Redis autorise plusieurs mots de passe actifs par utilisateur. La procédure est simple : commencer par définir un nouveau mot de passe en plus, puis mettre à jour les clients, et enfin supprimer l'ancien avec resetpass Supprimer. J'applique le même principe pour les modifications progressives des droits d'accès : en cas de doute, je procède d'abord à des simulations et utilise des comptes test avant de modifier les comptes de production.
Déroulement de la rotation #
ACL SETUSER app1 >NouveauMotDePasse # : définition d'un nouveau mot de passe supplémentaire
# : mise à jour des clients...
ACL SETUSER app1 resetpass >NouveauMotDePasse # : l'ancien mot de passe est supprimé, le nouveau est conservé
Approfondir les connaissances en matière de tests, de débogage et d'audits
Je teste les modifications avant leur mise en production. À l’aide d’un test simulé, je vérifie si un utilisateur est autorisé à exécuter une commande sur une clé ou un canal donné, sans l’exécuter réellement. Je suis les accès non autorisés et les violations des règles dans un journal ACL dédié, où je configure des règles de conservation et de routage pertinentes vers mon infrastructure centrale de journaux. Pour plus de transparence, j’utilise également les listes de catégories afin de comprendre quelles commandes se cachent derrière chaque catégorie.
# Simuler des droits
ACL DRYRUN app1 GET otherprefix:key
# Vérifier l'identité actuelle de l'utilisateur
ACL WHOAMI
# Afficher/réinitialiser les tentatives d'accès ayant échoué
ACL LOG
ACL LOG RESET
# Afficher les commandes par catégorie
ACL CAT @write
Pour les audits, je mets à disposition, outre la liste ACL LIST/USERS, des instantanés du fichier ACL dans le système de contrôle de version. Chaque modification fait l'objet d'un ticket ou d'une demande de modification et d'un processus de fusion soumis à la validation d'un réviseur. Je peux ainsi retracer à tout moment qui a étendu ou restreint quels droits, et à quel moment.
Scripts, fonctions et exécution sécurisée
Les scripts Lua et les fonctions côté serveur sont puissants, mais ils constituent également une faille potentielle permettant de contourner l'isolation si leur accès est trop largement autorisé. Dans les environnements partagés, je désactive par défaut EVAL/EVALSHA et la gestion des fonctions, et je ne les autorise que dans des contextes d'administration clairement délimités. Si l’utilisation de scripts s’avère nécessaire, je vérifie minutieusement que ceux-ci n’accèdent qu’aux préfixes de clés autorisés, car les listes de contrôle d’accès (ACL) s’appliquent également aux appels effectués à partir de scripts. Cela réduit le risque d’accès indirect à des zones non autorisées.
Réplication, haute disponibilité et cohérence des ACL
Dans les configurations répliquées, je sépare les utilisateurs de l'application des utilisateurs de la réplication. Pour la réplication, je crée un compte technique dédié qui ne dispose que des commandes nécessaires à SYNC/PSYNC/REPLCONF et autres. Je veille à ce que le fichier ACL soit synchronisé sur tous les nœuds : en cas de gestion manuelle, via la gestion de la configuration ; dans les clusters gérés, via les mécanismes prévus à cet effet. Après toute modification, j’enregistre les règles de manière centralisée et je les déploie de manière contrôlée sur les nouveaux nœuds, afin qu’un basculement n’entraîne aucune violation des droits.
Dans les clusters, je vérifie également si les préfixes de clés restent correctement alignés par rapport aux limites des slots. Il s’agit moins d’une question liée aux listes de contrôle d’accès (ACL) que d’un choix de conception visant à assurer une répartition uniforme de la charge et à simplifier la gestion des droits („ un préfixe, un espace de données, plusieurs slots “). Lors d’un basculement, je veille à ce que les utilisateurs de réplication et les comptes administrateurs soient déjà disponibles sur le nœud de destination, afin que les basculements restent transparents.
Changement de client, migrations et sauvegardes
Lors du renommage de préfixes ou d'identifiants de mandants, je tiens compte à l'avance des répercussions sur les listes de contrôle d'accès (ACL). Lorsqu'un mandant migre de « tenantA: » vers « tenantA2: », j'autorise temporairement les deux formats et je prévois une phase de transition claire. Je veille à ce que les tâches de migration utilisent elles-mêmes un utilisateur strictement limité, qui ne lit et n’écrit que les préfixes nécessaires. Pour les sauvegardes, je tiens compte du fait que le fichier ACL est séparé des bases RDB/AOF ; je le sauvegarde donc séparément, dans le cadre de la configuration. Pour les restaurations partielles, des préfixes précis sont utiles, car ils me permettent d’extraire de manière ciblée uniquement les espaces de clés pertinents.
Intégration client et protocoles sécurisés
Côté client, j'utilise systématiquement un identifiant et un mot de passe, plutôt que de m'en tenir à un „ requirepass “ global. Pour les clients modernes, j'utilise la poignée de main HELLO afin de négocier la version du protocole et l'authentification en une seule étape. Dans les environnements de production, je mise sur le chiffrement TLS afin que les identifiants et les chemins d'accès restent protégés. Je m'assure également que les clients n'enregistrent pas le nom d'utilisateur en clair dans les journaux ou que ceux-ci soient masqués en conséquence.
Exemple # : authentification en une seule étape
HELLO 3 AUTH app1 motdepasseSécurisé
Automatisation CI/CD et modèles de configuration
Je modélise les ACL sous forme de code. Les rôles et les utilisateurs sont créés à partir de modèles que je personnalise pour chaque environnement à l’aide de variables (préfixe, canaux, catégories). Des validations sont effectuées en cours de traitement : des linters vérifient qu’aucune commande @dangerous/@ne se retrouvent pas dans les comptes de service, des tests DRYRUN sont effectués sur des clés représentatives, et un conteneur de test de fumée est brièvement lancé contre une instance Redis isolée afin de vérifier de bout en bout les opérations AUTH, GET/SET et Pub/Sub. Les modifications ne sont déployées que lorsque tous les contrôles sont au vert, et en cas de retour en arrière, le fichier ACL précédent est immédiatement disponible.
Subtils détails opérationnels : visibilité et rangement
Au quotidien, les petites astuces ont un grand impact. Grâce à ACL WHOAMI, je vérifie rapidement sous quel compte un client travaille réellement – ce qui s’avère particulièrement utile dans les chaînes d’outils complexes. Je nettoie régulièrement les comptes „ zombies “ : les services désactivés perdent leurs utilisateurs („ off “), les mots de passe sont supprimés („ resetpass “), et les droits relatifs aux clés et aux canaux sont effacés („ resetkeys “, „ resetchannels “). Je respecte les conventions de nommage pour les utilisateurs (par exemple team_service_env), ce qui accélère les audits et les interventions en cas d’incident.
En bref
Je prévois ACLs Dès le départ, je crée un utilisateur par service et je limite strictement ses commandes, ses préfixes de clés et ses canaux. Pour les configurations faciles à maintenir, j'utilise un fichier ACL distinct, j'applique les modifications de manière contrôlée et je documente chaque étape. Les espaces de noms dotés de préfixes clairs protègent les clients, tandis que les audits, la rotation des clés et la journalisation garantissent la fiabilité du fonctionnement. Pour les scénarios sensibles, je prévois en outre une séparation architecturale afin que le contrôle d’accès et l’isolation technique fonctionnent de concert. Ainsi, une instance Redis partagée devient une instance gérable, sécurisé Une plateforme destinée à de nombreux groupes d'utilisateurs.
