Redis es muy rápido, pero una instancia expuesta, sin separación de usuarios o con una estrategia de persistencia incorrecta puede provocar accesos no autorizados y pérdida de datos.

Una configuración base para producción combina:

  • ACL por aplicación y por operador.
  • Acceso limitado a interfaces y redes privadas.
  • Firewall con allowlist.
  • Persistencia acorde con la criticidad de los datos.
  • Backups cifrados y restauraciones probadas.

Esta guía está orientada a Redis Open Source 6 o posterior. Las pruebas con ACL DRYRUN requieren Redis 7 o posterior.

Cuándo conviene aplicarlo

Este enfoque es recomendable cuando Redis se utiliza para:

  • Caché compartida.
  • Sesiones.
  • Rate limiting.
  • Colas o streams.
  • Coordinación entre aplicaciones.
  • Datos temporales con requisitos de recuperación.

No mezcles caché descartable y datos críticos en la misma instancia sin evaluar cuidadosamente la política global de memoria, eviction y persistencia.

Arquitectura recomendada

El flujo seguro es:

Aplicación → Red privada → Firewall → Redis ACL → AOF/RDB → Backup cifrado

La administración debe usar una ruta separada:

Operador → SSH o localhost → Usuario ACL ops → Redis

El usuario de la aplicación solo debe acceder a sus claves y comandos. El usuario administrativo debe emplearse únicamente desde una ruta controlada.

Requisitos previos

Necesitas:

  • Redis 6 o posterior.
  • Acceso mediante sudo.
  • IP privada fija en el servidor Redis.
  • Firewall activo.
  • Conectividad privada desde la aplicación.
  • Consola fuera de banda o acceso alternativo.
  • Backup verificado si ya existen datos.
  • Un gestor de secretos para las credenciales ACL.

En Debian y Ubuntu, las rutas habituales son /etc/redis/redis.conf y el servicio redis-server, pero debes confirmarlas en tu instalación:

systemctl cat redis-server
redis-server --version
redis-cli INFO server

Paso 1: registrar el estado inicial

Antes de modificar la instancia, revisa su configuración efectiva:

redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync
redis-cli CONFIG GET save
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename
redis-cli ACL LIST
redis-cli INFO persistence

Comprueba también dónde escucha Redis:

sudo ss -lntp | grep ':6379'

Crea una copia protegida de la configuración:

sudo cp --preserve=all \
  /etc/redis/redis.conf \
  /etc/redis/redis.conf.pre-hardening

sudo chmod 600 /etc/redis/redis.conf.pre-hardening

Paso 2: crear un backup de los datos

Si utilizas RDB, solicita un snapshot en segundo plano:

redis-cli BGSAVE
redis-cli LASTSAVE
redis-cli INFO persistence

Confirma:

rdb_bgsave_in_progress:0
rdb_last_bgsave_status:ok

Copia el RDB resultante a un almacenamiento cifrado fuera del servidor.

Si AOF está activo, no copies indiscriminadamente sus archivos mientras ocurre una reescritura. Desde Redis 7, AOF utiliza varios archivos y un manifiesto; una copia tomada durante la transición puede quedar inconsistente. Utiliza snapshots consistentes del volumen o el procedimiento oficial de backup de AOF. Persistencia y backups de Redis.

Un archivo de persistencia local no reemplaza un backup externo y probado.

Paso 3: restringir las interfaces

Abre el archivo de configuración:

sudoedit /etc/redis/redis.conf

Localiza bind y protected-mode. Para una aplicación ubicada en otro servidor privado:

bind 127.0.0.1 10.0.0.10
protected-mode yes
port 6379

Sustituye 10.0.0.10 por la IP privada real del servidor Redis.

Si todas las aplicaciones se ejecutan en el mismo host, limita Redis a loopback:

bind 127.0.0.1
protected-mode yes

No utilices:

bind 0.0.0.0
protected-mode no

La documentación de Redis recomienda impedir el acceso externo al puerto y enlazar el servicio únicamente a interfaces controladas. protected-mode es una defensa adicional, no un reemplazo del firewall. Seguridad de Redis.

Paso 4: limitar el puerto mediante firewall

Autoriza únicamente al servidor de aplicación. Por ejemplo, con UFW:

sudo ufw allow \
  from 10.0.0.20 \
  to 10.0.0.10 \
  port 6379 \
  proto tcp

Verifica las reglas antes de aplicarlas:

sudo ufw status numbered

No habilites una política restrictiva sin confirmar primero los accesos administrativos y de aplicación necesarios.

Una red privada no cifra automáticamente el tráfico. AUTH y el resto de los comandos se transmiten sin cifrar cuando no se utiliza TLS. Activa TLS si la red es compartida, atraviesa infraestructura no confiable o existe un requisito de cumplimiento. TLS en Redis.

Paso 5: preparar un archivo ACL persistente

Para varias identidades, Redis recomienda un archivo ACL externo. Crea el archivo con permisos limitados:

sudo install \
  -o redis \
  -g redis \
  -m 0640 \
  /dev/null \
  /etc/redis/users.acl

Agrega en redis.conf:

aclfile /etc/redis/users.acl

No combines usuarios declarados directamente mediante líneas user en redis.conf con un archivo externo: ambos métodos son mutuamente excluyentes. Archivos ACL externos.

Reinicia durante una ventana controlada:

sudo systemctl restart redis-server
sudo systemctl status redis-server --no-pager
sudo journalctl -u redis-server -n 50 --no-pager

Confirma que el servicio siga respondiendo localmente:

redis-cli PING

Paso 6: crear credenciales seguras

Crea dos contraseñas distintas:

  • app: usada exclusivamente por la aplicación.
  • ops: usada para administración.

Redis dispone de ACL GENPASS para generar secretos aleatorios:

redis-cli ACL GENPASS

Guarda cada contraseña inmediatamente en el gestor de secretos. No la insertes en scripts, repositorios ni documentación.

Las ACL pueden almacenar hashes SHA-256 mediante reglas que comienzan con #. Calcula el hash sin colocar la contraseña directamente en la línea de comandos:

read -r -s -p "Password ACL: " REDIS_PASSWORD
printf '\n'
printf '%s' "$REDIS_PASSWORD" | sha256sum
unset REDIS_PASSWORD

Conserva los 64 caracteres hexadecimales del resultado.

Paso 7: crear los usuarios app y ops

Crea primero el usuario limitado de la aplicación. Sustituye el hash ficticio:

redis-cli ACL SETUSER app \
  reset \
  on \
  '#HASH_SHA256_APP' \
  '~app:*' \
  resetchannels \
  +PING \
  +@read \
  +@write \
  -@dangerous

Las reglas significan:

  • reset: elimina cualquier permiso anterior.
  • on: habilita el usuario.
  • #HASH_SHA256_APP: agrega una contraseña previamente hasheada.
  • ~app:*: limita el acceso a claves con ese prefijo.
  • resetchannels: impide Pub/Sub mientras no sea necesario.
  • +PING: permite la comprobación de salud.
  • +@read y +@write: permiten categorías de lectura y escritura.
  • -@dangerous: elimina comandos considerados peligrosos.

Las reglas se procesan de izquierda a derecha. Por eso la denegación -@dangerous aparece después de las categorías permitidas. Sintaxis de ACL SETUSER.

Para aplicaciones estrictas, es preferible permitir comandos individuales, por ejemplo +GET, +SET, +DEL y +EXPIRE, en vez de categorías completas. Revisa las categorías después de actualizar Redis porque su composición puede cambiar.

Crea después la identidad administrativa:

redis-cli ACL SETUSER ops \
  reset \
  on \
  '#HASH_SHA256_OPS' \
  '~*' \
  '&*' \
  +@all

ops posee control completo. Su contraseña debe almacenarse por separado y utilizarse únicamente desde localhost, consola o un túnel SSH controlado.

Guarda las ACL:

redis-cli ACL SAVE

ACL SAVE persiste la configuración activa dentro de aclfile. CONFIG REWRITE no guarda automáticamente ese archivo. Persistencia de ACL.

Paso 8: validar los permisos antes de desactivar default

En Redis 7 o posterior, prueba permisos sin ejecutar realmente los comandos:

redis-cli ACL DRYRUN app SET app:health ok
redis-cli ACL DRYRUN app GET app:health
redis-cli ACL DRYRUN app SET otra:health ok
redis-cli ACL DRYRUN app CONFIG GET dir

Los dos primeros deben responder OK. Los otros deben indicar falta de permisos.

ACL DRYRUN simula un comando sin producir sus efectos. Documentación de ACL DRYRUN.

Realiza después una autenticación con el usuario app. Evita colocar la contraseña en una URI porque puede quedar en el historial o en la lista de procesos:

read -r -s -p "Password de app: " REDISCLI_AUTH
printf '\n'
export REDISCLI_AUTH

redis-cli \
  --user app \
  -h 10.0.0.10 \
  SET app:health ok

redis-cli \
  --user app \
  -h 10.0.0.10 \
  GET app:health

redis-cli \
  --user app \
  -h 10.0.0.10 \
  CONFIG GET dir

unset REDISCLI_AUTH

El SET y el GET deben funcionar. CONFIG GET debe ser rechazado.

Redis recomienda REDISCLI_AUTH en lugar de pasar la contraseña mediante -a. Aun así, elimina la variable después de usarla y evita ejecutar estas pruebas en entornos donde otros procesos puedan inspeccionar variables de entorno. Uso de redis-cli.

Prueba también el usuario ops desde una segunda terminal antes de continuar:

read -r -s -p "Password de ops: " REDISCLI_AUTH
printf '\n'
export REDISCLI_AUTH

redis-cli --user ops PING
redis-cli --user ops ACL WHOAMI
redis-cli --user ops ACL LIST

unset REDISCLI_AUTH

No desactives default hasta que esta prueba funcione.

Paso 9: desactivar el usuario default

Autentícate como ops:

read -r -s -p "Password de ops: " REDISCLI_AUTH
printf '\n'
export REDISCLI_AUTH

redis-cli --user ops ACL SETUSER default off
redis-cli --user ops ACL SAVE
redis-cli --user ops ACL LIST

unset REDISCLI_AUTH

Deshabilitar un usuario no termina automáticamente sus conexiones existentes. Si necesitas cerrar conexiones autenticadas previamente como default, inspecciónalas y utiliza CLIENT KILL USER default desde ops:

redis-cli --user ops CLIENT KILL USER default

Ejecuta esta última operación solo después de comprobar que ninguna aplicación legítima continúa usando default.

Paso 10: elegir la persistencia

La estrategia depende del impacto de perder datos:

UsoEstrategia inicial
Caché completamente reconstruibleSin persistencia o RDB opcional
Sesiones o rate limitingAOF everysec, según tolerancia
Colas y datos recuperablesAOF everysec + RDB + backups
Datos con pérdida casi nulaEvaluar always, replicación y alta disponibilidad

appendfsync everysec puede perder aproximadamente el último segundo de escrituras ante un fallo grave. RDB puede perder los cambios ocurridos desde el último snapshot. Opciones de persistencia.

Una configuración combinada puede ser:

appendonly yes
appendfsync everysec

save 900 1
save 300 10

stop-writes-on-bgsave-error yes

Cada línea save es una condición independiente:

  • Snapshot después de 900 segundos si hubo al menos un cambio.
  • Snapshot después de 300 segundos si hubo al menos diez cambios.

Evalúa el impacto de fork(), copy-on-write, latencia y espacio en disco con un volumen de datos representativo.

Paso 11: habilitar AOF sin perder datos existentes

En una instancia nueva o vacía, puedes aplicar la configuración durante el despliegue inicial.

Si el servidor ya utiliza RDB y contiene datos, no te limites a editar redis.conf y reiniciar. Redis advierte que esa secuencia puede causar pérdida de datos.

Habilita primero AOF en ejecución:

redis-cli CONFIG SET appendonly yes
redis-cli INFO persistence

Espera hasta comprobar:

aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

Después actualiza redis.conf para que contenga:

appendonly yes
appendfsync everysec

Así, la configuración persistirá en el siguiente reinicio. Los cambios ejecutados mediante CONFIG SET solo viven en memoria hasta que también se actualiza el archivo o se utiliza CONFIG REWRITE. Configuración dinámica de Redis.

Paso 12: comprobar el resultado

Verifica las interfaces:

sudo ss -lntp | grep ':6379'

Comprueba el servicio y sus logs:

sudo systemctl status redis-server --no-pager
sudo journalctl -u redis-server -n 100 --no-pager

Desde el usuario ops, revisa:

redis-cli --user ops ACL LIST
redis-cli --user ops ACL LOG
redis-cli --user ops INFO persistence
redis-cli --user ops INFO memory

En persistencia, presta atención a:

rdb_last_bgsave_status
aof_enabled
aof_last_write_status
aof_last_bgrewrite_status
aof_rewrite_in_progress
aof_pending_bio_fsync

El comando INFO persistence expone estos indicadores para supervisar RDB y AOF. Referencia de INFO.

Finalmente:

  • Prueba el acceso desde un servidor autorizado.
  • Comprueba que un host no autorizado no llegue al puerto.
  • Reinicia Redis en un entorno de prueba.
  • Verifica que los datos esperados se recuperen.
  • Restaura un backup en una instancia aislada.

Problemas frecuentes

La aplicación no puede autenticarse

Comprueba:

  • Que use AUTH usuario contraseña, no solo una contraseña.
  • Que el usuario esté on.
  • Que la contraseña corresponda al hash configurado.
  • Que la aplicación admita ACL de Redis 6 o posterior.
  • Que no continúe intentando usar default.

Revisa los rechazos:

redis-cli --user ops ACL LOG

La ACL bloquea comandos legítimos

Simula el comando exacto:

redis-cli --user ops ACL DRYRUN app EXPIRE app:session:123 3600

Agrega únicamente el comando o categoría necesaria. Para Pub/Sub también debes conceder comandos +@pubsub y patrones de canal como:

&app:*

Redis no inicia después del cambio

Desde la consola:

sudo systemctl status redis-server --no-pager
sudo journalctl -u redis-server -n 100 --no-pager

Restaura la configuración previa:

sudo cp \
  /etc/redis/redis.conf.pre-hardening \
  /etc/redis/redis.conf

sudo systemctl restart redis-server

No existe en todas las versiones empaquetadas un comando portátil equivalente a --check-config; no lo presupongas. Revisa los logs y prueba primero en staging.

El usuario desaparece después de reiniciar

El cambio se aplicó solo en memoria. Comprueba:

aclfile /etc/redis/users.acl

y guarda las ACL:

redis-cli --user ops ACL SAVE

AOF o RDB informa errores

Revisa:

  • Espacio e inodos disponibles.
  • Permisos del directorio de datos.
  • Errores de disco.
  • Presión de memoria durante fork().
  • Estado de la última reescritura o snapshot.

No ignores stop-writes-on-bgsave-error sin entender por qué fallan los snapshots.

Buenas prácticas para producción

  • No publiques el puerto 6379 en Internet.
  • Mantén protected-mode yes.
  • Usa firewall aunque Redis escuche en una IP privada.
  • Configura TLS cuando la red no sea completamente confiable.
  • Asigna un usuario ACL distinto a cada aplicación.
  • Conserva una identidad administrativa separada.
  • Prefiere comandos explícitos para aplicaciones críticas.
  • Rota contraseñas agregando primero la nueva y eliminando después la anterior.
  • Supervisa ACL LOG, memoria, eviction y persistencia.
  • Configura maxmemory y una política de eviction acorde con el uso.
  • Separa caché y datos durables en instancias diferentes.
  • Cifra los backups y limita el acceso a RDB y AOF.
  • Mantén backups fuera del host y prueba restauraciones.
  • Recuerda que replicación y persistencia no sustituyen un backup.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

  • Performance que te sorprenderá
  • Rápida escalabilidad y sin limitaciones
  • Arquitectura de alta disponibilidad
  • Soporte experto y ejecutivos de cuenta
  • Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting

Panel de Cloud Servers de Donweb mostrando la creación de un servidor con stacks como Django, GitLab, LAMP y NodeJS