En QlikView se puede configurar un mecanismo de seguridad de dos maneras distintas: Puede incrustarse en el script del documento QlikView, o puede configurarse mediante el uso de QlikView Publisher.
Autenticación y Autorización
Autenticación es cualquier proceso por el cual se verifica que alguien es quién dice ser. QlikView puede, o bien permitir que el sistema Windows efectúe la autenticación, o pedir un ID de Usuario y Contraseña (distintos del ID de Usuario y Contraseña de Windows) o emplear la clave de licencia de QlikView como método simple de autenticación.
Autorización es averiguar si la persona, una vez identificada, posee permisos de acceso al recurso. QlikView puede dejar que el sistema operativo Windows efectúe la autorización o hacerla por sí mismo. Para este último caso, se ha de crear una tabla de seguridad en el script.
Seguridad empleando QlikView Publisher
Si QlikView Publisher se ha configurado para que gestione temas de seguridad, entonces todo archivo QlikView se dividirá en varios archivos, cada uno con los datos relativos al usuario o grupo de usuarios relevante. Dichos archivos se almacenarán en carpetas con los correspondientes parámetros de seguridad del Sistema Operativo, es decir, QlikView permite al Sistema Operativo manejar la Autenticación y la Autorización.
No hay sin embargo seguridad alguna dentro del archivo en sí mismo, así que no hay protección en un archivo descargado.
Los tamaños de estos archivos serán por lo general pequeños, dado que un solo archivo se divide en múltiples archivos y el usuario sólo abre el archivo que contiene sus propios datos. No obstante, esto también implica que un QlikView Server podría tener que emplear más memoria que si los datos se almacenaran en un único archivo, dado que a veces se cargarán varios archivos conteniendo los mismos datos.
Para más información, le remitimos a la documentación de QlikView Publisher.
Seguridad empleando la Sección de Acceso en el script QlikView
Si la Section Access del script de QlikView se ha configurado para que gestione temas de seguridad, entonces se puede hacer que un solo archivo contenga los datos de un conjunto de usuarios o grupos de usuarios. QlikView usará la información de Section Access para los procesos de Autenticación y Autorización y reducirá los datos de forma dinámica, de forma que el usuario únicamente vea sus propìos datos.
La seguridad se incorpora así al archivo mismo, por lo tanto un archivo descargado estará, hasta cierto punto, protegido. No obstante, si las demandas de seguridad fueran muy altas, las descargas de archivos y el uso fuera de conexión (offline) deberían evitarse o impedirse. Los archivos deberían ser publicados únicamente por QlikView Server.
Dado que todos los datos se almacenan en un solo archivo, el tamaño que puede alcanzar este archivo puede ser considerable.
Los documentos QlikView pueden aparecer como invisibles en modo offline, sin conexión. Para que un documento de usuario quede invisible en modo sin conexión, añada el atributo siguiente en la sección de información del documento de un documento de usuario usando la consola QMC:
- Nombre: Invisible
- Valor: True
Toda la información que hay a continuación hace referencia al método de seguridad empleando Section Access en el script de QlikView.
Secciones en el script
El acceso a nivel de fila se gestiona mediante una o varias tablas de seguridad cargadas de la misma manera que los datos se cargan normalmente. Esto permite almacenar las tablas en una base de datos normal o en una hoja de cálculo. Las sentencias de script que administran las tablas de seguridad se dan dentro de una sección de autorización, que en el script se inicia mediante la sentencia Section Access.
Si se define una sección de autorización en el script, la parte del script que carga los datos de la app deberá colocarse en una sección distinta, iniciada por la sentencia Section Application.
Ejemplo:
Niveles de Acceso en la Sección de Acceso
El acceso a los documentos QlikView puede autorizarse a determinados usuarios o grupos de usuarios específicos. En la tabla de seguridad, a los usuarios se les asignan los niveles de acceso ADMIN (Administrador) o USUARIO. Si no se asignara nivel de acceso alguno, el usuario no podrá abrir el documento QlikView.
Una persona con acceso ADMIN puede modificar cualquier cosa en el documento. Utilizando la página Seguridad de los diálogos Propiedades de Documento y Propiedades de Hoja, una persona con privilegios ADMIN puede limitar las posibilidades de modificación de un documento por parte de otros usuarios. Una persona con privilegios de USUARIO no puede acceder a las páginas de Seguridad.
Campos de sistema en la Sección de Acceso
Los niveles de acceso se asignan a los usuarios a través de una o varias tablas cargadas en la sección de acceso. Dichas tablas pueden contener varios campos de sistema distintos, específicos de usuario, siendo los más habituales USERID (o ID de Usuario) y CONTRASEÑA, así como el campo ACCESS, que define el nivel de acceso. Todos los campos de sistema de la Sección de Acceso se emplearán para autenticación y autorización. A continuación, se describen todos los campos de sistema de la sección de acceso.
En la sección de acceso se podrán cargar todos, ninguno o cualquier combinación de estos campos de seguridad. Por tanto, no es necesario emplear USERID (la autorización se puede conceder con otros tipos de campo, por ejemplo, números de serie únicamente).
| Campo | Descripción |
|---|---|
| ACCESO | Campo que define el acceso que deberá tener un usuario específico. |
| IDUSUARIO | Campo que debe incluir un ID de usuario aceptado. QlikView solicitará un ID de usuario y la contrastará con el valor introducido en este campo. Este ID de usuario no es el mismo que el ID de usuario en Windows. |
| USER.EMAIL | Actualmente no es compatible, QlikView solo coincidirá con comodines. |
| CONTRASEÑA | Campo que contiene una contraseña aceptada. QlikView pedirá una contraseña al usuario y la contrastará con el valor introducido en este campo. Esta contraseña no es la misma que la contraseña de Windows. |
| SERIE | Un campo que debe contener un número correspondiente al número de serie de QlikView o la cadena "QLIKVIEW". Ejemplo: 4900 2394 7113 7304 QlikView comprobará el número de serie del usuario o la cadena "QLIKVIEW" y lo comparará con el valor de este campo. |
| NTNAME | Campo que contiene una cadena que muestra un nombre de usuario o nombre de grupo correspondiente a un Dominio de Windows NT. Si se utiliza un sistema de autenticación diferente, debe contener el nombre de un usuario autenticado. QlikView extraerá la información de acceso al Sistema Operativo y la contrastará con el valor introducido en este campo. |
| NTDOMAINSID | Campo que contiene una cadena correspondiente a un SID de Dominio en Windows NT. Ejemplo: S-1-5-21-125976590-4672381061092489882 QlikView extraerá la información de acceso al Sistema Operativo y la contrastará con el valor introducido en este campo. |
| NTSID | Campo que contiene un SID de Windows NT. Ejemplo: S-15-21-125976590-467238106-1092489882-1378 QlikView extraerá la información de acceso al Sistema Operativo y la contrastará con el valor introducido en este campo. |
| OMIT |
Campo que contiene una lista de campos no autorizados y que por tanto debieran omitirse para este usuario específico. Se puede hacer uso de comodines y el campo puede dejarse vacío. Una forma sencilla de realizar esto es utilizando un subcampo. Nota informativaNo debe aplicar OMIT en campos clave, ya que esto cambiaría la estructura de datos subyacente. Esto podría crear islas lógicas e incoherencias en los cálculos.
|
QlikView comparará el número de serie de QlikView con el campo SERIE, el nombre de usuario o de grupo de Windows NT con NTNAME, el SID de Dominio de Windows NT con NTDOMAINSID y el SID de Windows NT con NTSID. Además, pedirá al usuario un ID de Usuario y una contraseña y los contrastará con los campos IDUSUARIO y CONTRASEÑA.
Si la combinación de ID de usuario, contraseña y propiedades del entorno también se encuentran en la sección de acceso, entonces el documento se abrirá con su correspondiente nivel de acceso. Si no, QlikView denegará el acceso al usuario al documento. Si el ID de Usuario y/o la contraseña no se introducen correctamente en tres intentos, habrá que repetir el procedimiento completo de entrada al sistema.
Como en la sección de acceso se utiliza la misma lógica interna que es el distintivo característico de QlikView, los campos de seguridad se han de colocar en diferentes tablas. (por lo tanto es posible que un administrador de sistemas deje un documento QlikView fuera de las tablas de seguridad. En ese caso se simulan un ID de usuario, un nº de serie, una contraseña, etc, correctos mediante un clic de ratón en el correspondiente valor de campo.)
En el proceso de entrada registrada al sistema, QlikView comprobará primero SERIAL, NTNAME, NTDOMAINSID y NTSID para ver si dicha información es suficiente para conceder al usuario acceso al documento. Si lo es, QlikView abrirá el documento sin pedir ID de Usuario y Contraseña.
Si sólo se cargan algunos de los campos de acceso, se utilizarán los requisitos especificados que sean apropiados.
Todos los campos listados en las sentencias Load o Select de la sección de acceso deben ir en MAYÚSCULAS. Cualquier nombre de campo que contenga minúsculas en la base de datos deberá ser convertido a mayúsculas utilizando la función upper, antes de ser leído por una sentencia Load o Select.
Upper - función de script y de gráfico
Sin embargo, el ID de Usuario y la Contraseña introducidos por el usuario final que trata de abrir los documentos QlikView no son sensibles a mayúsculas.
Un comodín (*) se interpreta como todos los valores (enumerados) de este campo, es decir, un valor enumerado en otra parte de esta tabla. Si se usa en uno de los campos de sistema (USERID, PASSWORD, NTNAME o SERIAL) en una tabla cargada en la sección de acceso del script, su interpretación será de todos los valores posibles (también los no listados) de este campo.
Ejemplo 1:
Sólo se comprueba el número de serie. Un ordenador específico recibe acceso ADMIN. Todos los demás reciben acceso de USUARIO. Observe que se puede emplear una estrella para marcar "cualquier número de serie".
| ACCESO | SERIE |
|---|---|
| ADMIN | 4900 2394 7113 7304 |
| USUARIO | * |
Ejemplo 2:
El administrador y el servidor en el que se ejecuta QlikView como una tarea por lotes reciben acceso ADMIN. Todos los demás en el Dominio reciben acceso USUARIO cuando introducen “USER” como ID de Usuario y contraseña.
| ACCESO | SERIE | NTDOMAINSID | IDUSUARIO | CONTRASEÑA |
|---|---|---|---|---|
| ADMIN | * | S-1-5-21-125976590-467238106-1092489882 | ADMIN | ADMIN |
| ADMIN | 4900 2394 7113 7304 | * | * | * |
| USUARIO | * | S-1-5-21-125976590-467238106-1092489882 | USUARIO | USUARIO |
Entornos mixtos
Si planea usar la misma tabla de autorización tanto en QlikView como en Qlik Sense SaaS, hay un par de cosas que debe tener en cuenta:
• USERID tiene diferentes significados en QlikView y Qlik Sense SaaS, y podría, si se usara, ocasionar problemas de seguridad. Utilice NTNAME en su lugar o combínelo con SERIAL como se describe a continuación.
• GROUP y los campos que comienzan con "USER.", Como "USER.NAME" y "USER.EMAIL", etc. son (o serán) campos de autenticación en Qlik Sense Enterprise SaaS. Si utiliza estos campos en su Section Access, puede que se le deniegue el acceso a Qlik Sense SaaS.
• PASSWORD, NTSID y NTDOMAINSID no se pueden usar en Qlik Sense SaaS. Se denegará el acceso, a menos que se utilice un comodín.
• SERIAL no se puede utilizar para comprobar el número de licencia en Qlik Sense SaaS. Sin embargo, si este campo contiene la cadena "QLIKCLOUD" o "QLIKVIEW", se puede conceder acceso. Esto significa que es posible tener una tabla de autorización como la siguiente, donde la línea 1 otorgará acceso a QlikView (pero no a Qlik Sense SaaS), y la línea 2 otorgará acceso a Qlik Sense SaaS (pero no a QlikView).
| Línea | SERIE | IDUSUARIO | Comentario |
|---|---|---|---|
| 1 | 4600 0123 4567 8901 | * | Otorga acceso al número de licencia correcto en QlikView. |
| 2 | QLIKCLOUD | John Doe | Otorga acceso al usuario correcto en Qlik Sense Enterprise SaaS. |
| Línea | SERIE | IDUSUARIO | Comentario |
|---|---|---|---|
| 1 | QLIKVIEW | * | Otorga acceso a QlikView. |
| 2 | QLIKCLOUD | John Doe | Otorga acceso al usuario correcto en Qlik Sense Enterprise SaaS. |
Restricciones en la funcionalidad de QlikView
Los controles que se encuentran en la página Propiedades de Documento: Seguridad y en la página Propiedades de Hoja: Seguridad permiten deshabilitar el acceso a determinados elementos de menú y prohíben cambios en el diseño. Si se van a utilizar estos parámetros como auténticas medidas de seguridad, es importante que los usuarios del documento accedan como USUARIO. Cualquiera que entre como ADMIN sí puede modificar los parámetros de seguridad en cualquier momento.
Un usuario que haya abierto el documento con derechos de USUARIO no cuenta con las páginas de Seguridad en los diálogos de Propiedades.
Reducción Dinámica de Datos
QlikView y QlikView Server cuentan con una funcionalidad mediante la cual algunos de los datos de un documento pueden ocultarse a la vista de un usuario basándose en el tipo de entrada que ha realizado a la sección de acceso.
En primer lugar, los campos (columnas) pueden ocultarse mediante el uso del campo OMIT.
En segundo lugar, los registros (filas) pueden ocultarse vinculando los datos de la sección de acceso con los datos reales: La selección de valores que se habrán de mostrar o excluir se controla teniendo uno o más campos con nombres comunes en la sección de acceso y la sección de la aplicación. Tras la entrada registrada del usuario, QlikView tratará de copiar las selecciones de campos de la sección de acceso a campos de la sección de la aplicación que tengan exactamente los mismos nombres de campo (los nombres de campo deben ir escritos en MAYÚSCULAS). Una vez hechas las selecciones, QlikView ocultará de forma permanente todos los datos excluidos por estas selecciones al usuario.
Para que este procedimiento se lleve a cabo, deberá estar marcada la opción Reducción Inicial de Datos basada en la Sección de Acceso de la página Propiedades de Documento: Al Abrir. Si se empleara esta funcionalidad en documentos que se vayan a distribuir por otro procedimiento distinto de QlikView Server, deberá marcarse la opción Carga Binaria no permitida, en la misma página de Propiedades de Documento, a fin de mantener la protección de los datos.
Ejemplo:
section access;
LOAD * inline [
ACCESS, USERID, REDUCTION, OMIT
ADMIN, ADMIN,*,
USER, A,1
USER, B, 2, NUM
USER, C, 3, ALPHA
];
section application;
T1:
LOAD *,
NUM AS REDUCTION;
LOAD
Chr( RecNo()+ord('A')-1) AS ALPHA,
RecNo() AS NUM
AUTOGENERATE 3;
El campo REDUCTION (mayúsculas) ahora existe en ambas, la sección de acceso y la sección de aplicación (todos los valores de campo van también en mayúsculas). Normalmente serían dos campos totalmente diferentes y separados, pero si se marca la opción Reducción inicial de datos basada en la Sección de Acceso se vincularán ambos y se reducirá el número de registros mostrados al usuario.
El campo OMIT en la sección de acceso define los campos que deberían ocultarse al usuario.
El resultado será el siguiente:
Usuario A puede ver todos los campos, pero solo aquellos registros conectados a REDUCTION=1.
Usuario B puede ver todos los campos excepto NUM, y solo aquellos registros conectados a REDUCTION=2.
Usuario C puede ver todos los campos excepto ALPHA, y solo aquellos registros conectados a REDUCTION=3.
Restricciones de acceso heredadas
Una carga binaria mediante binary hará que las restricciones de acceso pasen al nuevo documento QlikView. Una persona con derechos de ADMIN para este nuevo documento puede cambiar los derechos de acceso al documento mediante la adición de una nueva sección de acceso. Una persona con los derechos de USUARIO puede ejecutar el script y modificarlo, añadiendo así datos propios al archivo cargado de forma binaria. Una persona con derechos de USUARIO no puede modificar los derechos de acceso. El administrador de la base de datos puede controlar de este modo también el acceso del usuario a los documentos QlikView que han sido cargados con carga binaria.
Cifrado / Encriptado
La comunicación entre un QlikView Server y un cliente QlikView Windows se hace mediante encriptación o cifrado. No obstante, si se utiliza el cliente AJAX, la comunicación no va encriptada.
Además, todos los documentos QlikView van codificados, lo que los convierte en ilegibles para cualquier navegador, depurador, etc.
También puede cifrar datos confidenciales en archivos QVD con pares de claves proporcionadas por el cliente, lo que le permite controlar quién tiene acceso a sus datos. Vea Cifrado de QVD (solo en inglés).
