Modelo de seguridad#
Esta página describe las piezas con las que Empowerment Center decide quién entra y qué puede hacer: usuarios, roles, privilegios y universos. Léala antes de diseñar los roles de una instalación.
Usuarios#
Un usuario es una persona que entra en ECenter. Tiene:
| Dato | Qué es |
|---|---|
| Login | El nombre con el que entra. Único en la instalación sin distinguir mayúsculas: «MGarcia» y «mgarcia» son el mismo usuario. Hasta 100 caracteres, sin espacios ni caracteres invisibles. |
| Descripción | Texto libre, normalmente el nombre de la persona y su puesto. Hasta 100 caracteres. |
| Correo | Opcional. Es adonde le llegan los avisos, las suscripciones y las alertas. Único sin distinguir mayúsculas: dos usuarios no pueden tener el mismo. |
| Contraseña | Opcional. Sin contraseña, el usuario solo puede entrar con el proveedor de identidad de la organización (SSO). |
| Estado | Habilitado, Inhabilitado o Bloqueado. Solo un usuario habilitado puede entrar. |
| Roles | Los roles que tiene. De ellos salen sus privilegios. |
Hay dos clases de usuarios:
- Usuario local: lo da de alta y lo mantiene quien administra usuarios en ECenter.
- Usuario gestionado por el proveedor: lo da de alta, lo cambia y lo da de baja el proveedor de identidad de la organización por SCIM. Su login, su descripción, su correo y su habilitación se deciden en el directorio; en ECenter solo se le bloquea y se le dan roles locales. Vea Aprovisionamiento por SCIM.
Estados#
| Estado | Puede entrar | Notas |
|---|---|---|
| Habilitado | Sí | Cuenta para el máximo de usuarios de la licencia. |
| Inhabilitado | No | La baja normal: conserva sus datos y se puede volver a habilitar. |
| Bloqueado | No | El freno de emergencia. En un usuario gestionado, el proveedor de identidad no lo puede levantar: solo lo levanta quien administra en ECenter. |
Inhabilitar o bloquear a un usuario cierra en el acto todas sus sesiones abiertas, y sus credenciales de servicio dejan de valer mientras siga así. Lo que se ejecuta en su nombre (tareas programadas, suscripciones, alertas) tampoco se ejecuta: solo se actúa en nombre de un usuario habilitado.
Nota
ECenter no bloquea una cuenta por intentos fallidos de contraseña. En su lugar, impone un retardo creciente entre intentos (vea Sesiones y entrada). El estado Bloqueado lo pone siempre una persona.
Roles#
Un rol es un conjunto de privilegios con nombre («Comerciales de la zona Norte», «Diseño del metadata»). Los privilegios se dan a los roles y los roles a los usuarios. Un usuario tiene la suma de los privilegios de todos sus roles: un rol nunca quita lo que da otro.
- El nombre de un rol es único sin distinguir mayúsculas.
- El rol Administrador Sistema es del sistema: no se puede eliminar.
- Un rol solo se elimina cuando no lo tiene ningún usuario.
- Un rol puede estar enlazado con un grupo del directorio del proveedor de identidad: quien está en el grupo recibe el rol. Un rol enlazado no se puede eliminar ni puede dar Administración del Sistema.
Privilegios#
Un privilegio es un permiso con nombre. Los privilegios se organizan en un árbol de carpetas, que es el que se ve en la pestaña Roles y privilegios:
| Carpeta | Qué contiene |
|---|---|
| Administración/Acceso | Los privilegios del sistema que abren partes de la aplicación: entrar en la aplicación de análisis o en el portal, administrar el metadata, los usuarios, los libros, el portal o el sistema, suscribirse, vigilar datos y usar la API. |
| Lectura de datos/estructuras | Sin nivel definido y los privilegios de datos que protegen lo que se puede ver: dimensiones, métricas, listas, libros, páginas del portal, datos externos y universos. |
| Edición de datos/estructuras | Los privilegios genéricos de edición (insertar, modificar y eliminar registros desde los formularios, modificar una dimensión) y los privilegios de edición que cree quien diseña el metadata. |
Hay dos clases de privilegios:
- Privilegios del sistema: vienen con ECenter, conservan los códigos de Empowerment Center 7 (EC7) y no se pueden crear, renombrar ni eliminar. La lista completa está en la Referencia de privilegios.
- Privilegios de datos (o de usuario): los crea quien tiene Administración del Metadata, en la pestaña Seguridad del editor del metadata, dentro de las carpetas de lectura y de edición. Son de toda la instalación, no de una conexión. Se usan para proteger elementos concretos («Datos confidenciales», «Libros de Dirección», «Zona Norte»).
Sin nivel definido#
Sin nivel definido (código 0) es el privilegio que tienen por defecto las dimensiones, las métricas y los libros que no se protegen con otro. Por eso casi todos los roles de usuario lo llevan: un usuario sin «Sin nivel definido» no ve las dimensiones ni las métricas que no tienen otro privilegio, y un libro con ese privilegio de lectura tampoco.
Administración del Sistema#
Administración del Sistema (código 100099) es el privilegio de más alto nivel. Quien lo tiene recibe además todos los privilegios del sistema (los de la carpeta Administración/Acceso, Sin nivel definido y los genéricos de edición), aunque su rol no los lleve marcados.
Lo que no recibe son los privilegios de datos. Un administrador del sistema no ve por serlo una métrica protegida con «Datos confidenciales», ni un universo deja de aplicársele: si necesita verla, necesita ese privilegio por uno de sus roles, como cualquier otro usuario.
Qué protege#
Administración del Sistema implica todo lo demás, así que quien solo tiene Administración de Usuarios no puede dársela a nadie, tampoco a sí mismo. Exige tener Administración del Sistema:
- dar a un usuario un rol que la incluye, o quitárselo;
- añadirla a un rol o quitársela (los demás privilegios de ese rol los cambia cualquiera que administre usuarios);
- cambiar la contraseña, el estado, el login o el correo de un usuario que la tiene, o eliminarlo;
- vincular con el proveedor de identidad a un usuario que la tiene, o trasladar su vinculación;
- por SCIM, cambiar el login de un usuario gestionado que la tiene por un rol local, o volver a enlazarlo: lo exige al titular de la credencial SCIM.
Sin ella, la pantalla enseña esos controles desactivados con su motivo («Da Administración del sistema: solo quien la tiene puede darlo o quitarlo.», «Tiene Administración del sistema: solo quien también la tiene puede cambiar su contraseña, su estado o eliminarlo.»), y el servidor responde 403 con el código ADMIN_SYSTEM_REQUIRED («Solo quien tiene Administración del sistema puede…»).
Además:
- Se comprueba con los privilegios de ahora, no con los de la sesión. Si a alguien le acaban de quitar Administración del Sistema, ya no la puede ejercer aunque siga con la sesión abierta.
- Perderla cierra sus sesiones: al quitarle el rol que la daba, al quitársela a su rol (si no la tiene por otro) o al inhabilitarlo.
- Siempre queda un administrador. ECenter no deja que una operación deje la instalación sin ningún usuario local, habilitado y con contraseña que tenga Administración del Sistema; la rechaza con «La operación dejaría el sistema sin ningún usuario habilitado con Administración del Sistema». Es la vía de entrada si falla el proveedor de identidad.
- El proveedor de identidad nunca la da: un rol que la incluye no se puede enlazar con un grupo del directorio.
Universos#
Un universo es una condición sobre una tabla de hechos que se asocia a un privilegio: quien tiene el privilegio solo ve las filas de esa tabla que cumplen la condición. Es la seguridad por filas de ECenter. Los universos son de cada conexión y los define quien tiene Administración del Metadata.
Las reglas que hay que tener en cuenta al diseñarlos:
- Restringen a quien tiene su privilegio. Un usuario que no tiene ninguno de los privilegios con universo de una tabla ve todas sus filas.
- Se suman. Si un usuario tiene dos privilegios con universo sobre la misma tabla («Zona Norte» y «Zona Este»), ve las filas de los dos.
- Se propagan por las relaciones: el universo de una tabla maestra (los clientes) limita también las filas de sus tablas de detalle (las facturas de esos clientes), aunque la consulta no use la maestra.
Vea Seguridad sobre los datos para el detalle y los ejemplos.
Cuándo se aplica un cambio#
| Cambio | Cuándo lo nota el usuario |
|---|---|
| Inhabilitarlo, bloquearlo o eliminarlo | En el acto: se cierran sus sesiones. |
| Cambiar su login | En el acto: se cierran sus sesiones y tiene que entrar con el login nuevo. |
| Cambiar o poner su contraseña desde Usuarios y roles | En el acto: se cierran sus sesiones. |
| Que el usuario cambie su propia contraseña (Cambiar contraseña… en el menú de su cuenta) | En el acto: se cierran sus sesiones en otros navegadores; sigue en la que usa. |
| Quitarle Administración del Sistema | En el acto: se cierran sus sesiones. |
| Que pierda un rol que le daba el proveedor de identidad | En el acto: se cierran sus sesiones. |
| Darle o quitarle otros roles, o cambiar los privilegios de un rol | En su siguiente inicio de sesión. Mientras tanto conserva los privilegios con los que entró. |
| Cualquier cambio, para una credencial de servicio (API, MCP, SCIM) | En la petición siguiente: las credenciales leen los privilegios del titular en cada petición. |
Consejo
Si quiere que un cambio de roles se note ya, pida al usuario que salga y vuelva a entrar, o cierre su sesión desde la consola de operación (vea Operación).