Gestionar la seguridad con sección de acceso

Puede utilizar sección de acceso en el script de carga de datos para administrar el acceso a los datos a nivel de fila. De esta forma, se puede utilizar un solo archivo para almacenar los datos de usuarios o grupos de usuarios. Qlik Senseutiliza la información en la sección de acceso para la autorización a nivel de fila y reduce dinámicamente los datos, de modo que los usuarios solo vean los datos que tienen permiso para ver.

La seguridad se incorpora en el propio archivo, lo que significa que los archivos descargados siempre estarán protegidos, hasta cierto punto. No obstante, si las demandas de seguridad son altas, se debe evitar la descarga de archivos y el uso sin conexión. Los archivos solo deben ser publicados por el servidor de Qlik Sense. Como todos los datos se almacenan en un solo archivo, el tamaño de dicho archivo puede llegar a ser considerable.

La app debe publicarse antes de que se apliquen los controles de acceso a la sección. Recargar la app no aplicará ningún script de acceso a la sección nuevo o modificado.

Para evitar exponer información restringida, elimine todos los archivos adjuntos con la configuración de sección de acceso antes de publicar la app. Los archivos adjuntos se incluyen al publicar la app. Si la app publicada se copia, los archivos adjuntos se incluyen en la copia. Sin embargo, si se han aplicado restricciones de sección de acceso a los archivos de datos adjuntos, la configuración de la sección de acceso no se conserva al copiarse los archivos, por lo que los usuarios de la app copiada podrán ver todos los datos en los archivos adjuntos.

Una captura de imagen muestra los datos conforme a los derechos de acceso que posea el usuario que toma la captura y esta captura puede después compartirse en una historia. No obstante, cuando los usuarios retornan a una visualización desde una historia para ver los datos en vivo en la app, se ven restringidos por sus propios derechos de acceso.

No asigne colores a los valores de las dimensiones maestras si utiliza sección de acceso o trabaja con datos confidenciales, porque los valores podrían quedar expuestos por la configuración del color.

Secciones en el script

El control de acceso a nivel de fila se administra a través de una o varias tablas de seguridad cargadas de la misma manera en que se cargan normalmente los datos. Esto hace posible almacenar estas tablas en una base de datos estándar o en una hoja de cálculo. Las sentencias de script que gestionan las tablas de seguridad se proporcionan 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 debe colocarse en una sección diferente, con la sentencia Section Application al inicio.

Example:

Section Access;

AuthorizationTable:

Load ACCESS, USERID, REGION From ... ;

Section Application;

Load ... From ... ;

Campos de sistema en la sección de acceso

Los niveles de acceso se asignan a los usuarios en una o varias tablas cargadas dentro de la sección de acceso. Estas tablas pueden contener diferentes campos de sistema específicos de usuario, generalmente USERID, y el campo que define el nivel de acceso, ACCESS. 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.

ACCESS

Define el tipo de acceso que debe tener un usuario específico.

El acceso a las apps de Qlik Sense puede autorizarse a determinados usuarios o grupos de usuarios específicos. En la tabla de seguridad, se puede asignar a los usuarios a los niveles de acceso ADMIN o USER. Si no se asigna un nivel de acceso válido, el usuario no podrá abrir la app.

Una persona con privilegios de ADMIN tiene acceso a todos los datos de la app. Una persona con privilegios de USER solo puede acceder a los datos tal como se define en la tabla de seguridad.

Si se utiliza sección de acceso en un escenario de generación de apps (ODAG) bajo demanda en la app de plantilla, el usuario INTERNAL\SA_API debe incluirse como ADMIN en la tabla de la sección de acceso. Por ejemplo:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_API ];

NTNAME

Un campo que debe contener una cadena correspondiente a un nombre de usuario o grupo de dominio de Windows NT. Si se utiliza un sistema de autenticación diferente, debe contener el nombre de un usuario autenticado.

Qlik Sense obtendrá la información de inicio de sesión del sistema operativo y la comparará con el valor de este campo.

USERID

Contiene una cadena que corresponde a un nombre de usuario de Qlik Sense. Qlik Sense recibirá la información de inicio de sesión del proxy y la comparará con el valor introducido en este campo.

USERID y NTNAME ambos usan la misma información de autenticación, por lo que no es necesario marcar ambos en la misma fila en la tabla de autorización. La diferencia entre los dos campos es que NTNAME también verifica grupos.

USER.EMAIL

Actualmente no es compatible, Qlik Sense solo mostrará resultados con comodines.

GROUP

Contiene una cadena que corresponde a un grupo de Qlik Sense. Qlik Sense resolverá el usuario proporcionado por el proxy con este grupo.

Cuando utilice grupos para reducir datos y desee acceder a Qlik Management Console, todavía se requiere el usuario de la cuenta INTERNAL\SA_SCHEDULER.

SERIAL

Contiene una cadena correspondiente a la plataforma. Si el campo contiene la cadena ‘QLIKSENSE’ o un carácter comodín ‘*’, se puede conceder acceso, dependiendo de los otros campos de la tabla de autorización.

Si el campo SERIAL contiene un número de licencia, la fila de la Sección de acceso denegará el acceso al documento. Esta configuración solo es válida en QlikView.

OMIT

Contiene el nombre del campo que se debe omitir para este usuario específico. Se puede hacer uso de comodines y el campo puede dejarse vacío. Una forma sencilla de realizar esto consiste en utilizar un subcampo.

Le recomendamos que no aplique OMIT en campos clave. Los campos clave que se omiten están visibles en el visor del modelo de datos, pero el contenido no está disponible, lo que podría ser confuso para el usuario. Además, aplicar OMIT en campos que se utilizan en una visualización puede dar como resultado una visualización incompleta para usuarios que no tengan acceso a los campos omitidos.

Qlik Sense compara al usuario con UserID y resuelve el usuario contrastándolo con los grupos en la tabla. Si el usuario pertenece a un grupo al que se le permite el acceso, o el usuario coincide, puede acceder a la app.

Si se ha quedado bloqueado y no logra acceder a una app mediante la sección de acceso, puede abrir la app sin sus datos y editar la sección de acceso en el script de carga de datos. Esto requiere acceso a edición y carga del script de carga de datos.

Para más información, vea Abrir una app sin datos.

Como en la sección de acceso también se utiliza la misma lógica interna característica de Qlik Sense, los campos de seguridad se pueden colocar en diferentes tablas. Todos los campos enumerados en sentencias LOAD o SELECT en la sección de acceso deben ir escritos en mayúsculas. Convierta cualquier nombre de campo de la base de datos que contenga letras minúsculas a mayúsculas utilizando la función Upper antes de que la sentencia LOAD o SELECT lea el campo.

Para más información, vea Upper - función de script y de gráfico.

Un carácter comodín, por ejemplo el asterisco (*), se interpreta como todos los valores (incluidos en la lista) de este campo, es decir, un valor que aparece en otros lugares de la tabla. Si se usa en uno de los campos de sistema (USERID, GROUP) de una tabla cargada en la sección de acceso del script, se interpretará como todos los valores posibles (también los no enumerados) de este campo.

Al cargar datos de un archivo QVD, la función Upper ralentiza la velocidad de carga.

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:

En este ejemplo, solo los usuarios del grupo financiero pueden abrir el documento.

Acceso al documento
Acceso	Grupo
USUARIO	Finanzas

Reducción dinámica de datos

Qlik Sense admite la funcionalidad de reducción dinámica de datos, mediante la cual algunos de los datos de una app pueden ocultarse a la vista de un usuario conforme al inicio de sesión efectuado en la sección de acceso:

Los campos (columnas) se pueden ocultar utilizando el campo de sistema OMIT.
Los registros (filas) pueden ocultarse enlazando 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 en la sección de la aplicación. Una vez que el usuario ha iniciado sesión, Qlik Sense tratará de contrastar las selecciones de campos de la sección de acceso con los campos de la sección de aplicación que tengan exactamente los mismos nombres de campo (los nombres de los campos deben estar en mayúsculas). Una vez que el usuario ha iniciado la sesión, Qlik Sense ocultará de forma permanente todos los datos excluidos por estas selecciones de la vista del usuario.

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

Si desea habilitar la carga de script en una tarea Qlik Management Console, se requiere el usuario de la cuenta INTERNAL\SA_SCHEDULER con acceso a ADMIN.

Example: Reducción de datos basada en ID de usuario

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT USER, AD_DOMAIN\ADMIN, *, USER, AD_DOMAIN\A, 1, USER, AD_DOMAIN\B, 2, NUM USER, AD_DOMAIN\C, 3, ALPHA ADMIN, INTERNAL\SA_SCHEDULER, *, ]; 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) existe ahora tanto en la sección de acceso como en la sección de aplicación (todos los valores de campos van también en mayúsculas). Por lo general, serían dos campos totalmente diferentes y aparte; pero al utilizar la sección de acceso, estos campos se vinculan y se reduce el número de registros que se muestran al usuario.

El campo OMIT, en la sección de acceso, define los campos que deberían ocultarse del usuario.

El resultado será:

El usuario ADMIN puede ver todos los campos y solo aquellos registros que otros usuarios pueden ver en este ejemplo cuando REDUCTION sea 1, 2 o 3.
El usuario A puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=1.
El usuario B puede ver todos los campos excepto NUM y solo aquellos registros asociados a REDUCTION=2.
El usuario C puede ver todos los campos excepto ALPHA y solo aquellos registros asociados a REDUCTION=3.

Example: Reducción de datos basada en grupos de usuarios

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, INTERNAL\SA_SCHEDULER, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;