Cuantas más capas de vistas y más consumidores tiene una plataforma Denodo, más importante es tener claro quién puede ver qué. No es solo una cuestión de «dar acceso o no»: Denodo permite decidir con mucha precisión qué filas, qué columnas y qué operaciones puede ver o ejecutar cada usuario, sin duplicar vistas para cada caso. Así es como está montado el modelo de seguridad por debajo.
Dos niveles de privilegios
Denodo separa el control de acceso en dos niveles, que resuelven preguntas distintas:
Controlan si un usuario o rol puede ejecutar, editar, insertar, actualizar o borrar sobre una vista concreta, y si puede ver sus metadatos. Es la típica pregunta de «¿puede tocar esta vista o no?», a nivel de vista completa.
Una vez que un usuario puede ejecutar una vista, estos privilegios deciden qué datos concretos ve dentro de ella: restricciones por fila, restricciones por columna, o políticas de seguridad personalizadas. Es la diferencia entre «puede consultar esta vista» y «solo ve las filas de su propio departamento».
Roles: colecciones de privilegios, no grupos de usuarios
Denodo sigue el estándar RBAC (Role-Based Access Control) de NIST. La idea clave, y la que más se suele confundir al principio, es que un rol es una colección de privilegios, no un grupo de usuarios. Un usuario no «pertenece» a un rol como quien pertenece a un equipo: un rol simplemente empaqueta un conjunto de permisos, y ese paquete se asigna a los usuarios que lo necesiten.
Los roles pueden ser jerárquicos: un rol puede heredar los privilegios de otro. Y cuando un usuario tiene varios roles asignados, sus permisos son aditivos — se suman los de todos los roles que tenga, nunca se restan.
Por qué solo hay permisos positivos
Denodo modela únicamente permisos positivos («puede hacer X»), no permisos negativos («no puede hacer X»). La razón es puramente práctica: en un modelo con jerarquías de roles, mezclar permisos positivos y negativos genera combinaciones muy difíciles de razonar — ¿qué gana, el permiso heredado de un rol padre o la denegación de un rol hijo? Al quedarse solo con permisos positivos y sumarlos, el resultado de combinar varios roles es siempre predecible: la unión de todo lo que cada rol permite.
Ejemplo con roles de un dominio genérico
Imagina una plataforma con vistas de recursos humanos. Así se vería la combinación de privilegios de grano grueso y fino:
| Rol | Privilegio de grano grueso | Privilegio de grano fino |
|---|---|---|
| rol_empleado | Ejecutar la vista de directorio de plantilla | Solo ve las columnas de contacto, no las de salario |
| rol_manager | Ejecutar la vista de directorio de plantilla | Ve todas las columnas, pero solo las filas de su propio equipo |
| rol_rrhh | Ejecutar, editar e insertar sobre la vista de directorio | Ve todas las filas y columnas, sin restricciones |
Un usuario con rol_manager y rol_empleado a la vez tendría la suma de ambos: al ser permisos aditivos, terminaría viendo lo que le permite el rol más amplio de los dos para cada dato.
Consejos prácticos
- Diseña primero los roles y sus privilegios de grano grueso (qué vistas toca cada rol) antes de entrar en restricciones de fila o columna — añadir grano fino sobre una base desordenada multiplica la complejidad.
- Aprovecha la herencia de roles para modelar jerarquías organizativas (por ejemplo, rol_manager hereda de rol_empleado) en lugar de duplicar privilegios en cada rol.
- En modelos multicapa, define las restricciones de grano fino lo antes posible en la cadena de vistas (cerca de la base view), para que ninguna capa superior pueda saltárselas.
- Documenta qué rol corresponde a qué perfil de negocio — con permisos puramente aditivos, es fácil acabar dando más acceso del previsto si un usuario acumula demasiados roles.
- Revisa periódicamente qué roles tiene cada usuario: al no existir permisos negativos, quitar acceso siempre significa quitar un rol, no añadir una excepción.
¿Quieres ver cómo organizo las vistas antes incluso de aplicar seguridad sobre ellas?
Leer el artículo sobre nomenclatura de capas