Seguridad

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 Sección de Acceso del script 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 la Sección de Acceso para los procesos de Autenticación y Autorización y reducirá los datos de forma dinámica, de forma que el usuario sólo 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 que utilice la consola QMC:

  • Nombre:  Invisible
  • Valor: True

Toda la información que hay a continuación hace referencia al método de seguridad empleando la Sección de Acceso en el scipt QlikView.

Secciones en el script

El control de acceso se gestiona mediante una o varias tablas de seguridad cargadas de la misma manera que se cargan los datos habitualmente en QlikView. De esta manera es posible almacenar las tablas en una base de datos normal y corriente. Las sentencias de script que gestionan las tablas de seguridad se suministran dentro de la sección de acceso, la cual se inicia desde el script mediante la sentencia section access.

Si se define una sección de acceso en el script, la parte del script que carga los datos "habituales" deberá colocarse en una sección distinta, iniciada por la sentencia section application.

Example:  

Section Access;

Load inline

[ACCESS,USERID,PASSWORD

ADMIN, A,X

USER,U,Y ];

Section Application;

Load... ... from... ...

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.

Nota: Los derechos de ADMIN solo son relevantes para documentos locales. Se accede siempre a los documentos abiertos en un Server con derechos de USUARIO.

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. No es por tanto necesario emplear USERID, se puede dar otro tipo de autorización utilizando otros campos, por ej. números en serie únicamente.

 

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.
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 contiene un número correspondiente al número de serie de QlikView.
Ejemplo: 4900 2394 7113 7304
QlikView comprobará el número de serie del usuario y lo contrastará con el valor introducido en 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.
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: No 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 carácter comodín, como por ejemplo *, se interpreta como todos los valores (listados) de este campo, es decir una lista de valores en cualquier lugar 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.

Nota: Cuando se cargan datos desde un archivo QVD, el uso de la función superior ralentizará la velocidad de carga.
Nota: Para generar tablas de acceso en sentencias inline, utilice el Asistente de Tablas Restricción de Acceso.
Nota: Si ha habilitado la sección de acceso, no podrá utilizar los nombres de campos de sistema de la sección de acceso indicados aquí como nombres de campos en el modelo de datos.

Example 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 *

Example 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

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.

Nota: Todos los nombres de campo empleados en la transferencia descrita y todos los valores de campo de estos campos deberán ir en MAYÚSCULAS, ya que todos los nombres de campo y valores de campo se convierten por defecto a mayúsculas en la sección de acceso.

Example:  

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,

RechNo() 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.