Ir al contenido 
He puesto ACL de Redis en entornos multiusuario de forma específica, para separar claramente los comandos, los prefijos de clave y los canales Pub/Sub. De este modo, me aseguro de que Seguridad En el lado del servidor, minimiza los accesos erróneos y mantén una gestión clara de los roles.
Puntos centrales
- Separación de comandos, claves y canales por usuario
- Del lado del servidor Control en lugar de lógica en la aplicación
- Espacios de nombres por prefijo de clave para clientes
- Archivo ACL para facilitar el mantenimiento y el control de versiones
- Auditorías con ACL LIST y ACL USERS
Conceptos básicos de ACL en entornos multiusuario
Creo un usuario específico para cada aplicación, cada equipo o cada cliente y defino sus derechos de forma estricta a través de LCA-Reglas. De este modo evito que una única contraseña global abra todas las puertas y que los datos se sobrescriban accidentalmente. Separo los derechos en función de los comandos, los patrones de claves y los canales, de modo que cada cuenta solo pueda hacer lo estrictamente necesario y nada más. Este aislamiento del lado del servidor aligera la carga de la aplicación y aumenta la Transparencia en el modelo de seguridad. Precisamente en las instancias compartidas, esto me permite tener una visión general de quién puede realizar qué operación en cada espacio de nombres.
Modelos de derechos: separar claramente los comandos, las claves y los canales
Asigno derechos de administración de forma detallada, por ejemplo, en categorías como @read y @write, y elimino los grupos de riesgo, como @dangerous, que contienen comandos de configuración o de administración. Para los espacios de claves, utilizo prefijos únicos como app1:*, app2:* o tenant_a:*, de modo que los accesos de lectura y escritura se limiten a un espacio de nombres claro. De esta forma, un trabajo puede, por ejemplo, utilizar SET y GET, pero solo bajo su propio prefijo. Además, restrinjo los canales de Pub/Sub para que los eventos solo se transmitan en los flujos previstos. El resultado es una estructura trazable Separación entre funciones, salas de datos y vías de comunicación.
Limitar de forma segura el modelo Pub/Sub
Para Pub/Sub, solo permito los canales que una aplicación realmente necesita y bloqueo sistemáticamente todo lo demás. LCA-Reglas. De este modo, evito que un servicio reciba eventos ajenos o publique mensajes a suscriptores inesperados. Precisamente en las arquitecturas basadas en eventos, este control reduce el riesgo de fuga de datos o de interferencia en otros servicios. Documento los canales autorizados por usuario para que la incorporación y las auditorías sean claras. De este modo, a medida que crece el entorno del sistema, mantengo la Controlar sobre los flujos de datos.
Gestión de usuarios y reglas en la práctica
Creo nuevos usuarios con el comando ACL SETUSER, les asigno una contraseña segura y activo únicamente los comandos que necesita el servicio, como por ejemplo +@leer y +@write, al tiempo que bloqueo los comandos de mayor riesgo. Defino los espacios de claves permitidos mediante patrones adecuados y regulo los canales de forma análoga. Para tener una visión general, utilizo ACL USERS y, con ACL LIST, obtengo una visión rápida de las reglas activas. Cargué o guardo los cambios con ACL LOAD y ACL SAVE, para que la configuración y el archivo permanezcan sincronizados. Así mantengo la Administración conciso, comprensible y reproducible.
| Comando ACL/Auth | Propósito | Ejemplo |
|---|---|---|
| ACL SETUSER | Crear/modificar usuarios | ACL SETUSER app1 on >contraseñaSegura +@read +@write -@dangerous ~app1:* |
| LISTA DE ACL | Mostrar normas | LISTA DE ACL |
| USUARIOS DE ACL | Mostrar la lista de usuarios | USUARIOS DE ACL |
| ACL CARGAR/GUARDAR | Cargar/guardar un archivo ACL | ACL SAVE; ACL LOAD |
| AUTH | Inicio de sesión en el servidor | AUTH app1 contraseñaSegura |
Configuración: ¿archivo ACL o redis.conf?
Guardo configuraciones sencillas directamente en la redis.conf, aunque, si hay varios usuarios y roles, sigo utilizando un archivo ACL independiente. Este archivo lo versiono en un repositorio seguro, documento los cambios de forma clara y aplico las actualizaciones de forma controlada. De este modo, separo los parámetros de la aplicación de la lógica de seguridad, lo que reduce las fuentes de error. Paralelamente, refuerzo la seguridad de la instancia a nivel de red, por ejemplo, mediante Proteger los puertos abiertos y elimino los puntos vulnerables innecesarios. En conjunto, esto aumenta la Seguridad y simplifica su funcionamiento.
Espacios de nombres y segregación de clientes
Diseño los prefijos de clave de manera que identifiquen claramente los ID de inquilino y los nombres de las aplicaciones, por ejemplo: tenantA:app1:session:{id}. De este modo, creo una barrera bien visible alrededor de los datos de cada parte, que las reglas ACL protegen aún más. Para las rutas de migración utilizo esquemas de nomenclatura coherentes, de modo que las implementaciones mediante Blue-Green o Canary resulten más sencillas. Una estructura clara también resulta útil en las copias de seguridad y las restauraciones, ya que así solo tengo que ocuparme de los conjuntos de datos relevantes. Esta combinación de concepto de nomenclatura y reglas ACL mantiene la Clientes bien separados.
Los microservicios y las funciones del equipo en el día a día
Configuró un usuario por cada servicio, que lee y escribe exclusivamente en sus propias salas de datos, sin tener acceso a prefijos ajenos ni a funciones de administración. Para las cuentas de desarrollador, definió derechos de lectura o escritura restrictivos, mientras que las cuentas de administrador siguen estando estrictamente limitadas y registradas. Los trabajos por lotes solo reciben los comandos que necesitan para ejecutarse, como lectura, escritura y cambios de TTL, pero no comandos de administración. Además, limito las integraciones externas en el tiempo o a entornos de prueba, para que las configuraciones erróneas no Productivo-Datos confidenciales. Así es como distribuyo claramente las responsabilidades sin rebajar la seguridad.
Límites de las ACL y los niveles de aislamiento
Mi valoración de las ACL es correcta: controlan el acceso, pero no lo aíslan. Recursos como la CPU, la RAM o las E/S a nivel de proceso. Por eso, en escenarios de cumplimiento normativo estrictos, me planteo utilizar instancias dedicadas, clústeres separados o nodos propios. La separación lógica mediante ACL reduce los accesos indebidos, pero comparte los mismos recursos del servidor. Para cargas de trabajo sensibles, planifico una delimitación adicional, por ejemplo, mediante segmentos de red, contenedores o límites de máquinas virtuales. De este modo, combino el control de acceso con medidas técnicas blindaje para un mayor nivel de seguridad.
Operaciones: auditorías, rotación y registro
Compruebo los permisos periódicamente con ACL LIST y elaboro un calendario de cambios para poder validar rápidamente qué está activo en caso de auditorías. Roto las contraseñas a intervalos fijos y registro con atención los eventos de inicio de sesión, así como los patrones inusuales. En caso de incidentes, bloqueo inmediatamente a los usuarios afectados, cargo reglas actualizadas y compruebo automáticamente las rutas críticas. En CI/CD integro comprobaciones que detectan comandos prohibidos o la ausencia de prefijos en las configuraciones. Esto Procedimiento ahorra tiempo y reduce al mínimo las interrupciones en el funcionamiento.
Decisiones de arquitectura: compartida o dedicada
Estoy valorando si varios clientes deben utilizar una misma instancia o si es mejor proporcionar servidores independientes, ya que ambas opciones tienen sus propias Riesgos y ventajas. El servidor compartido ahorra costes, pero exige listas de control de acceso (ACL) estrictas, espacios de nombres bien definidos y una supervisión minuciosa. El servidor dedicado reduce las interacciones cruzadas, pero requiere más hardware y mantenimiento. En cuanto a cuestiones de rendimiento y seguridad, prefiero comparaciones como Compartido frente a dedicado lo analizo y realizo pruebas de carga. Al final, tomo una decisión basándome en el acceso a los datos, los requisitos de cumplimiento normativo y Presupuesto.
¿Clúster o modo autónomo? ¿Cuál es la mejor opción para las ACL?
Utilizo las ACL tanto en instancias independientes como en clústeres, pero me aseguro de que las reglas sean coherentes en todos los nodos. En los clústeres, compruebo cómo se distribuyen las claves entre los slots para que los prefijos y los derechos sigan aplicándose de forma adecuada. En entornos de alta disponibilidad, exijo que la conmutación por error no Rotura se genera en la cadena de permisos y el archivo ACL es idéntico en todas partes. Compruebo previamente las rutas de migración para que los cambios de réplica o las actualizaciones no provoquen lagunas. Quien analice la arquitectura puede basarse en comparaciones como Clúster frente a sistema independiente orientarse y, a continuación, implantar la estrategia de ACL de forma adecuada.
Planificación y Bootstrap: un comienzo seguro
Empiezo con un Bootstrap limpio. El usuario „predeterminado“ integrado no tiene derechos amplios: o bien lo desactivo por completo, o bien le retiro por defecto todos los comandos, claves y canales. De este modo, evito que se trabaje accidentalmente sin separación de usuarios. Para las tareas operativas, defino deliberadamente cuentas de administrador independientes con protección multifactorial a nivel de gestión (por ejemplo, host bastión o certificados de cliente TLS) y listas de control de acceso (ACL) estrictas.
# Configuración de inicio seguro en el archivo ACL
user default off
user admin on >ContraseñaAdministradorSólida +@admin -@dangerous allkeys allchannels
Genero contraseñas seguras en el servidor, de modo que nunca aparecen en los registros ni en el historial del shell. Para obtener tokens rápidos y seguros, utilizo un generador en el servidor y los renuevo periódicamente. Para los clientes modernos, prefiero la autenticación mediante HELLO con nombre de usuario y contraseña en un solo paso, lo que define explícitamente la versión del protocolo y evita casos extremos.
Patrones y dificultades con las ACL de clave y de canal
En el caso de los patrones clave, trabajo exclusivamente con listas de permisos. Empiezo con teclas de reinicio y, a continuación, añado patrones ~ específicos, por ejemplo, ~tenantA:* y ~tenantA:app1:* para espacios delimitados con mayor precisión. Los prefijos que se solapan son un punto crítico: si un usuario tiene ~tenantA:* y no debe ver áreas como tenantA:archiv:*, entonces planifico los espacios de nombres de tal forma que los subconjuntos sensibles tengan un prefijo propio (p. ej., tenantA:priv:*), que simplemente no autorizo. Se aplican normas similares a los canales: configuro restablecer canales y concede únicamente &tenantA:* y, en su caso, solo los canales necesarios para las notificaciones de Keyspace.
# Claves y canales estrictos
ACL SETUSER tenantA:app1 on >Pass +@read +@write -@dangerous \
resetkeys ~tenantA:app1:* \
resetchannels &tenantA:app1:*
Tenga en cuenta que comandos como RENAME, MIGRATE o DUMP/RESTORE podrían escribir más allá de los límites de los prefijos. Dichos comandos permanecen bloqueados en las cuentas de servicio en producción. Los campos hash, los elementos de lista o los miembros de conjuntos ordenados no son claves independientes: la ACL se aplica a nivel de clave, no dentro de la estructura de datos. Por lo tanto, basta con un concepto de prefijo de clave bien definido para cubrir también estas estructuras.
Gestionar de forma consciente las categorías de comandos
Solo activo lo que realmente necesito. Para las cargas de trabajo CRUD clásicas, a menudo basta con +@read y +@write. Por norma general, bloqueo las categorías de mayor riesgo: @admin y @dangerous son tabú para los usuarios de las aplicaciones. En configuraciones multitenant, evito en la medida de lo posible el uso de funciones de scripting (EVAL, FUNCTION). En los servicios Pub/Sub, desacoplo los permisos para que no se permitan automáticamente las órdenes de escritura en las claves. En la práctica, empiezo con lo mínimo y, cuando es necesario, permito de forma selectiva comandos concretos (+COMMAND) en lugar de habilitar categorías enteras.
Rotación y cambios sin tiempo de inactividad
Tengo previsto realizar una rotación de contraseñas sin tiempo de inactividad. Redis permite tener varias contraseñas activas por usuario. El procedimiento es sencillo: primero se establece una nueva contraseña adicional, luego se actualizan los clientes y, por último, se elimina la antigua con resetpass Eliminar. Aplico el mismo principio para los cambios graduales en los permisos: en caso de duda, realizo pruebas simuladas y utilizo usuarios de prueba antes de modificar las cuentas productivas.
Proceso de rotación #
ACL SETUSER app1 >NuevaContraseña # establecer además la nueva contraseña
Actualizar los clientes #...
ACL SETUSER app1 resetpass >NuevaContraseña # se elimina la contraseña antigua, se mantiene la nueva
Profundizar en las pruebas, la depuración y las auditorías
Pruebo los cambios antes de que se publiquen. Mediante una simulación, compruebo si un usuario podría ejecutar un comando en una clave o canal concreto, sin llegar a ejecutarlo realmente. Realizo un seguimiento de los accesos indebidos y las infracciones de las normas en un registro ACL específico, donde configuro una conservación y un enrutamiento adecuados hacia mi infraestructura central de registros. Para garantizar la transparencia, también utilizo las listas de categorías para comprender qué comandos se esconden detrás de cada categoría.
# Simular derechos
ACL DRYRUN app1 GET otherprefix:key
# Comprobar la identidad actual del usuario
ACL WHOAMI
# Ver/restablecer los intentos de acceso fallidos
ACL LOG
ACL LOG RESET
# Mostrar comandos por categoría
ACL CAT @write
Para las auditorías, además de la lista de usuarios (ACL LIST/USERS), mantengo instantáneas del archivo ACL en el control de versiones. Cada modificación se asocia a un ticket o solicitud de cambio y a un proceso de fusión que requiere la revisión de un revisor. De este modo, puedo rastrear en cualquier momento quién ha ampliado o restringido qué derechos y cuándo.
Scripts, funciones y ejecución segura
Los scripts de Lua y las funciones del lado del servidor son muy potentes, pero también pueden suponer una vía de escape del aislamiento si se permiten de forma demasiado amplia. En entornos compartidos, desactivo por defecto EVAL/EVALSHA y la gestión de funciones, y solo las permito en contextos de administración claramente delimitados. Si es necesario utilizar scripts, compruebo minuciosamente que estos accedan exclusivamente a prefijos de clave permitidos, ya que las ACL también se aplican a las llamadas realizadas desde scripts. Esto reduce el riesgo de que se acceda indirectamente a áreas ajenas.
Replicación, alta disponibilidad y coherencia de las ACL
En configuraciones replicadas, separo a los usuarios de la aplicación de los usuarios de la replicación. Para la replicación, configuro una cuenta técnica dedicada que solo dispone de los comandos necesarios para SYNC/PSYNC/REPLCONF y similares. Mantengo sincronizado el archivo ACL en todos los nodos: mediante mantenimiento manual a través de la gestión de la configuración, y en clústeres gestionados, mediante los mecanismos previstos para ello. Tras realizar cambios, guardo las reglas de forma centralizada y las cargo de forma controlada en los nuevos nodos, para que la conmutación por error no provoque ninguna violación de permisos.
En los clústeres, compruebo además si los prefijos de clave siguen estando alineados de forma adecuada con los límites de los slots. No se trata tanto de una cuestión relacionada con las ACL como de un aspecto de diseño para lograr una distribución uniforme de la carga y simplificar la gestión de permisos („un prefijo, un espacio de datos, muchos slots“). Durante una conmutación por fallo, me aseguro de que los usuarios de replicación y las cuentas de administrador ya estén disponibles en el nodo de destino, de modo que las conmutaciones se realicen de forma transparente.
Cambios de cliente, migraciones y copias de seguridad
Cuando se renombran prefijos o identificadores de cliente, tengo en cuenta de antemano las repercusiones en la ACL. Si un cliente migra de «tenantA:» a «tenantA2:», permito temporalmente ambos formatos y planifico una fase de transición clara. Me aseguro de que las tareas de migración utilicen un usuario con derechos estrictamente limitados, que solo lea y escriba los prefijos necesarios. En cuanto a las copias de seguridad, tengo en cuenta que el archivo ACL está separado de RDB/AOF, por lo que lo incluyo por separado en la copia de seguridad como parte de la configuración. Para las restauraciones parciales, los prefijos precisos resultan útiles, ya que me permiten extraer de forma selectiva solo los espacios de claves relevantes.
Integración de clientes y protocolos seguros
En el lado del cliente, utilizo sistemáticamente el nombre de usuario y la contraseña, en lugar de dejar activado un „requirepass“ global. Para los clientes modernos, utilizo el protocolo HELLO para negociar la versión del protocolo y la autenticación en un solo paso. En entornos de producción, apuesto por el cifrado TLS para garantizar que los datos de acceso y las rutas de datos permanezcan protegidos. Además, me aseguro de que los clientes no registren el nombre de usuario en los registros en texto claro o de que dichos registros se censuren adecuadamente.
Ejemplo de #: Autenticación en un solo paso
HELLO 3 AUTH app1 contraseñaSegura
Automatización de CI/CD y plantillas de configuración
Modelo las ACL como código. Los roles y los usuarios se crean a partir de plantillas que relleno con variables (prefijo, canales, categorías) según el entorno. En el proceso se realizan validaciones: los linters comprueban que no haya comandos @dangerous/@admin en las cuentas de servicio, las pruebas ejecutan DRYRUNs con claves representativas y un contenedor de pruebas de humo se inicia brevemente contra una instancia aislada de Redis para verificar de extremo a extremo AUTH, GET/SET y Pub/Sub. Los cambios no se implementan hasta que todas las comprobaciones den resultado positivo, y en caso de reversión, el archivo ACL anterior está disponible de inmediato.
Detalles operativos: visibilidad y orden
En el día a día, las pequeñas ayudas tienen un gran impacto. Con ACL WHOAMI compruebo rápidamente con qué cuenta trabaja realmente un cliente, lo cual resulta especialmente útil en cadenas de herramientas complejas. Elimino periódicamente las cuentas „zombi“: los servicios desactivados pierden a sus usuarios („off“), se eliminan las contraseñas („resetpass“) y se borran los derechos de clave y de canal („resetkeys“, „resetchannels“). Sigo las convenciones de nomenclatura para los usuarios (por ejemplo, team_service_env), lo que agiliza las auditorías y la respuesta ante incidentes.
Brevemente resumido
Estoy planeando ACLs Desde el principio, creo un usuario para cada servicio y restrinjo estrictamente sus comandos, prefijos de claves y canales. Para configuraciones que se puedan mantener, utilizo un archivo ACL independiente, aplico los cambios de forma controlada y documento cada paso. Los espacios de nombres con prefijos claros protegen a los clientes, mientras que las auditorías, la rotación y el registro de eventos garantizan un funcionamiento fiable. Para escenarios sensibles, tengo en cuenta además la separación arquitectónica, de modo que el control de acceso y el aislamiento técnico actúen de forma conjunta. De este modo, una instancia compartida de Redis se convierte en una instancia gestionable, seguro Plataforma para numerosos grupos de usuarios.
