Cryptage redis

«Redis est une base de données haute performance largement utilisée qui est capable de stocker une variété de structures de données. Puisqu'il est utilisé par les grandes applications au niveau de l'entreprise pour provisionner la mise en cache, les systèmes de messagerie et les capacités de base de données, les aspects de sécurité et de chiffrement des données sont tout aussi importants que les performances. Au cours de la dernière décennie, il y a eu une tendance croissante dans les attaques malveillantes qui ont été déclenchées contre les bases de données pour révéler des informations sensibles ou pour modifier les données. Ainsi, le risque est le même avec les applications qui utilisent des backends redis.

Redis est fondamentalement conçu pour des connexions autorisées dans des environnements fiables. Par conséquent, il est recommandé de ne pas exposer le port de base de données Redis au grand public ou à Internet et à des réseaux non fiables. Dans la plupart des cas où les applications Web génèrent du contenu en interrogeant le magasin Redis et en poussant des données en fonction des demandes des clients, il est obligatoire de mettre en œuvre une couche intermédiaire pour restreindre ou filtrer les demandes des clients qui proviennent des applications Web. Redis fournit une variété de mesures de chiffrement et de sécurité, telles que les listes de contrôle d'accès (ACL), le support TLS et le chiffrement au repos pour protéger les données."

Autoriser le trafic de confiance avec Redis Authentication & ACL (listes de contrôle d'accès)

Comme mentionné, par conception, Redis n'est pas sûr d'exposer à des réseaux non fiables, à Internet et aux connexions client. Si c'est le cas, Redis fournit un mécanisme d'authentification de base de données où les clients doivent s'authentifier à l'aide d'un nom d'utilisateur et d'un mot de passe. Chaque utilisateur est associé à un ensemble limité de fonctionnalités, de clés Redis et de commandes. Il restreindreait certains clients en n'ayant que les autorisations pour exécuter des commandes de lecture mais pas les commandes d'écriture. De plus, la LCA est utilisée pour restreindre les commandes à haut risque comme Flushall et FlushDB à partir de sources non fiables. De plus, Redis a une variété de commandes de configuration introduites pour gérer l'instance Redis dans les configurations sur site et cloud. Ces commandes de configuration ne sont pas très utiles aux consommateurs. Ainsi, ACL parvient également à masquer ces commandes au public.

Authentification

Habituellement, le fichier Redis Config contient une ligne appelée exigence qui peut être utilisé pour activer l'authentification du mot de passe pour une instance de base de données redis donnée. Avec cette option activée, les clients non authentifiés n'auront pas du tout accès à la base de données. La commande AUTH est utilisée pour authentifier les utilisateurs dans les bases de données redis. Il est étendu à partir de Redis version 6, qui peut être utilisé avec deux paramètres comme suit.

Authentification

Inspecter l'ACL pour une instance redis

Redis ACLS peut être inspecté à l'aide de la commande ACL List, comme indiqué dans ce qui suit. Généralement, il affiche des informations détaillées liées à un utilisateur, comme un nom d'utilisateur, un état de mot de passe (requis ou non), des clés d'accès, des commandes et des canaux pub / sous-canaux.

Liste de la LCA

La sortie ci-dessus peut être interprétée comme suit.

Différentes règles ACL sont disponibles pour créer des utilisateurs corrects avec un minimum de niveaux d'accès à l'instance de base de données Redis. La commande ACL SetUser peut être utilisée pour configurer différents utilisateurs avec différents niveaux d'accès.

Crypter les données transférées à l'aide de redis TLS

De la version 6 de Redis, SSL / TLS a été pris en charge. Il crypte les données envoyées sur tous les canaux de communication redis tels que les connexions client, les connexions en grappe, les sentinelles et les liens de réplication. De plus, le redis SSL / TLS doit être activé au moment de la compilation.

Par défaut, les serveurs Redis s'exécutent en mode normal, qui ne prend pas en charge le cryptage SSL / TLS. Par conséquent, vous devez démarrer explicitement l'instance Redis en mode TLS, comme indiqué dans ce qui suit.

redis-server --TLS-Port 6379 --port 0 --TLS-CERT-FILE ./ reditls / tls / redis.CRT --TLS-Key-File ./ reditls / tls / redis.clé --TLS-CA-CERT-FILE ./ reditls / tls / ca.CRT

Nous supposons que tous les certificats et clés SSL sont disponibles. De même, pour initier une connexion client, nous devons utiliser l'indicateur -TLS avec les clés et certificats SSL nécessaires comme suit.

redis-Cli --tls - cerser ./ reditls / tls / redis.CRT --key ./ reditls / tls / redis.Clé - Cacert ./ reditls / tls / ca.CRT

De plus, l'instance redis doit être configurée avec un x.509 Certificat et clé privée également.

Cryptage SSL / TLS en réplication, sentinelle et communication de cluster

Réplication

Dans redis, lorsque la réplication est activée, l'instance maître utilise le TLS-PORT et TLS-AUTH-CLIENTS Options pour permettre aux clients de connaître le port qui accepte les connexions TLS et si l'authentification des clients est requise ou non. De même, dans les cas de répliques, il est recommandé d'utiliser le cryptage SSL / TLS pour les connexions sortantes vers des instances maîtresses. Dans ce cas, le TLS-Replication L'option doit être définie sur Oui.

Sentinelle

Chaque fois que le Redis Sentinel a été activé pour les besoins de haute disponibilité, le TLS-Replication L'option décide si la connexion TLS ou non TLS doit être utilisée lors de la connexion aux serveurs maîtres. De même, la même directive régit les connexions entrantes des autres sentinelles sont activées ou non SSL / TLS. Si la TLS-Replication La directive se fixe sur oui, le TLS-PORT L'option doit également être attribuée avec le port approprié.

Grappe

Lorsque les clusters sont utilisés dans Redis, il est recommandé de fournir des canaux de communication sécurisés pour les bus de cluster et les liens de cluster en cluster. Redis fournit le tls-cluster Directive pour déterminer la prise en charge du cryptage SSL / TLS parmi les nœuds de cluster. Cette directive devrait être définie sur Oui Lorsque vous avez besoin d'une connexion TLS pour envoyer des données d'un nœud à un autre.

Cryptage au repos

Redis est déployé à la fois dans les environnements sur site et cloud. Dans les déploiements cloud, la communication de repos est toujours cryptée. Les principaux fournisseurs de cloud tels que les déploiements AWS, Azure et GCP Provision redis via des canaux cryptés. De plus, Amazon Cloud propose des fonctionnalités de chiffrement en transit qui sont répertoriées ci-dessous.

• • La communication maître-replice est cryptée dans les instances de redis déployées AWS.
  • Connexions de serveur et client activés SSL
  • Authentications du client et du serveur Prise en charge.

Conclusion

En résumé, Redis n'est pas conçu pour exposer son port TCP aux connexions client non fiables dans des environnements peu fiables. Par conception, il n'a été développé que pour des sources de confiance. Comme mentionné, dans le cas de Redis exposé au public via une application Web, une couche de sécurité supplémentaire doit être implémentée entre les connexions client et l'instance Redis. Selon cet article, Redis prend en charge les listes de contrôle d'accès (ACL), le support TLS et le chiffrement au repos pour atténuer les attaques malveillantes. De plus, nous avons discuté du support SSL / TLS pour la communication Redis Cluster, Replica et Sentinel. Dans l'ensemble, il est recommandé de pratiquer les techniques ci-dessus chaque fois que l'instance Redis est exposée au public.