1. Fuentes de solo lectura
Las fuentes SQL se abren en solo lectura. Una escritura la rechaza el motor, no solo la interfaz; la protección se demuestra con un caso sano, un caso infractor y un sabotaje deliberado.
2. Identidad federada, sin cuentas locales
El inicio de sesión pasa por Idenva (SSO). Un token de otro emisor, o caducado, se rechaza, y se detecta la reactivación de una contraseña local. Dashvia no mantiene una base de usuarios propia.
3. Derechos fila a fila
Los grupos de Idenva determinan qué filas son visibles. El filtro es parametrizado, nunca construido interpolando valores, y se aplica también a los filtros cruzados, al drill-down, a las exportaciones y a los informes programados.
4. Una IA que muestra su consulta
El text-to-SQL responde con una consulta SQL legible. Toda lectura fuera del esquema y toda escritura se rechazan antes de ejecutarse. Sin el hub Kopilvia, Dashvia pasa a un modo degradado explícito: corpus local y negativa a responder fuera de él, en lugar de inventar.
5. Registro de auditoría
Quién ha consultado, exportado o modificado qué informe queda anotado en un registro de solo adición: la base de datos rechaza cualquier modificación o supresión de una fila ya escrita.
6. Base reforzada y fijada
Dashvia se apoya en Apache Superset (Apache-2.0), fijado en la versión 6.1.0. Una clave secreta por defecto o una cuenta admin/admin se rechazan al arrancar, y los avisos de seguridad publicados se comprueban contra la versión fijada.
7. Alojable en su infraestructura
La base se instala en su propia infraestructura. Sus esquemas y sus resultados no tienen por qué salir de ella.