Administrar la seguridad de los datos mediante la sección de acceso

La sección de acceso se utiliza para controlar la seguridad de una aplicación. Es básicamente una parte del script de carga de datos donde se agrega una tabla de autorización para definir quién puede ver qué. Qlik Sense utiliza esta información para reducir los datos al ámbito adecuado cuando el usuario abre la aplicación, es decir, algunos de los datos de la app se ocultan al usuario en función de su identidad. La sección de acceso está estrechamente integrada con los datos de la app y se basa en ellos para controlar el acceso. Esta forma de reducción dinámica de los datos puede apuntar a filas, columnas o a una combinación de ambas. Para más información, vea Confianza y seguridad en Qlik.

Secciones en el script de carga

El control de acceso a los datos se gestiona a través de una o más tablas de seguridad, cargadas de la misma forma en que se cargan normalmente los datos. Esto hace posible almacenar esas 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, iniciada por la sentencia Section Application.

Ejemplo:  

Tenga en cuenta que después de realizar cambios en el script de carga, siempre debe volver a cargar los datos para que los cambios surtan efecto.

Campos de sistema de la sección de acceso

Los niveles de acceso se asignan a los usuarios en una o más tablas de autorización cargadas dentro de la parte Section Access del script. Estas tablas deben contener, como mínimo, dos campos de sistema: ACCESS, que es el campo que define el nivel de acceso, y USERID o USER.EMAIL. Se pueden agregar otros campos de sistema opcionales, según sea el caso de uso. 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 específicos. En la tabla de autorización, se puede asignar a los usuarios a los niveles de acceso ADMIN o USER. Un usuario con privilegios ADMIN tiene acceso a todos los datos de la app a menos que esté limitado por la tabla de autorización. Un usuario con privilegios de usuario (USER) solo puede acceder a los datos definidos en la tabla de autorización. Si no se asigna un nivel de acceso válido, el usuario no podrá abrir la app.

Si Section Access se utiliza en un escenario de recarga, INTERNAL\SA_SCHEDULER, que es el usuario del servicio del programador, necesita acceso de ADMIN para efectuar cargas. Por ejemplo:

Si no desea utilizar la cuenta INTERNAL\SA_SCHEDULER, vea Usar la suplantación de identidad para recargar datos para un método alternativo.

Si se utiliza Section Access 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 Section Access. Por ejemplo:

USERID

Contiene una cadena correspondiente a un nombre de dominio y 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.

Un carácter comodín de asterisco (*) se interpreta como todos los usuarios, sujeto a condiciones adicionales especificadas en la tabla de autorización. Por ejemplo, en la siguiente tabla de autorización, los usuarios que están en Qlik Sense Tenant Admins pueden ver todos los valores de REDUCCIÓN enumerados.

NTNAME

Un campo que debe contener una cadena correspondiente a un nombre de usuario o grupo de dominio de Windows NT. Si se utilizara un sistema de autenticación diferente, deberá 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.

GROUP

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

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.

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.

Gestionar el acceso de usuarios a una app

Section access, en su forma más simple, sirve para restringir el acceso a determinados usuarios a una app. A los usuarios se les niega el acceso a una app mediante un proceso de exclusión. En otras palabras, si un ID de usuario no aparece en la tabla de autorización, dicho usuario no podrá acceder a la aplicación. La única excepción a esta regla es si se asigna un asterisco (*) al campo USERID en una de las filas de la tabla de autorización. El asterisco, en este caso, significa que todos los usuarios autenticados pueden acceder a la app. A continuación se muestra un ejemplo de una tabla de autorización con un listado de los ID de usuario:

Gestionar el acceso de usuarios a datos específicos de una app

La reducción dinámica de datos limita el acceso a filas y columnas en las tablas de datos dentro de las apps de Qlik Sense después de que un usuario haya sido autorizado para acceder a la app.

Gestionar el acceso a los datos a nivel de fila

Restrinja el acceso a los datos a nivel de fila agregando una columna de reducción de datos a la tabla de autorización en la sección de acceso del script de carga. Determinados registros (filas) pueden ocultarse enlazando los datos de la sección de acceso con los datos reales: La selección de datos que se mostrarán o excluirán se controla mediante uno o más campos de reducción con nombres comunes en las partes Section Access y Section Application de la secuencia de script. Una vez que el usuario haya 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 realizadas las selecciones, Qlik Sense oculta permanentemente al usuario todos los datos excluidos por estas selecciones. Si se utiliza un carácter comodín (*) como valor de campo en la columna de reducción de datos, se interpreta como que permite al usuario acceder a los registros asociados con todos los campos de reducción seleccionados en la tabla de seguridad.

Cuando Qlik Sense está comparando el campo de reducción en la sección de acceso con los campos del modelo de datos, se esperan los siguientes comportamientos:

• Si un valor de campo en el modelo de datos coincide con el campo de reducción en la sección de acceso, la aplicación se abrirá y mostrará los datos asociados con la coincidencia para el usuario especificado. Otros datos se ocultarán.

• Si el valor del campo de reducción no coincide con ninguno de los valores del modelo de datos, la aplicación no se abrirá para un USUARIO normal; pero sí se abrirá sin reducción para un usuario marcado como ADMIN.

No se recomienda utilizar varios campos reductores en la sección de acceso, ya que permitirá otras combinaciones de acceso distintas a las previstas.

Ejemplo: Reducción de datos a nivel de filas basada en la identidad de usuario

En este ejemplo, 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 sección de acceso, estos campos se vinculan y se reduce el número de registros que se muestran al usuario.

El resultado será:

• El usuario ADMIN puede ver todos los campos y solo aquellos registros que otros usuarios pueden ver cuando REDUCTION = 1 o REDUCTION =2.
• El usuario A puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=1.
• El usuario B puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=2.
• El usuario C puede ver todos los campos y solo aquellos registros que otros usuarios pueden ver cuando REDUCTION = 1 o REDUCTION =2.

Gestionar el acceso a los datos a nivel de columna

Restrinja el acceso a los datos a nivel de columna agregando el campo de sistema OMIT a la tabla de autorización en el script de sección de acceso. El ejemplo siguiente se basa en el ejemplo anterior, en el que la reducción de datos de filas ya está implementada.

Ejemplo: Reducción de datos de columna basada en la identidad del 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.

Gestionar el acceso a grupos de usuarios

La sección de acceso le ofrece la opción de limitar el alcance de los datos visibles para los usuarios mediante la pertenencia a un grupo. Para restringir sus datos utilizando grupos de usuarios, agregue el nombre del campo GROUP a la tabla de autorización en la sección de acceso y defina valores para el campo GROUP.

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

El resultado será:

• Los usuarios que pertenecen al grupo ADMIN tienen permiso para ver todos los campos y solo aquellos registros que otros usuarios pueden ver en este ejemplo cuando REDUCTION sea 1, 2 o 3.
• Los usuarios que pertenecen al grupo A pueden ver los datos asociados a REDUCTION=1 en todos los campos.
• Los usuarios que pertenecen al grupo B pueden ver los datos asociados a REDUCTION=2, pero no en el campo NUM
• Los usuarios que pertenecen al grupo C pueden ver los datos asociados a REDUCTION=3, pero no en el campo ALPHA
• Los usuarios que pertenecen al grupo GROUP1 pueden ver los datos asociados a REDUCTION=3 en todos los campos

Qlik Sense compara el usuario con UserID y resolverá el usuario comparándola con los grupos de 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.

Usar la suplantación de identidad para recargar datos

De forma predeterminada, la cuenta del sistema interno, SA_SCHEDULER, se utiliza para ejecutar tareas de recarga. Esta cuenta tiene privilegios elevados y técnicamente puede utilizar cualquier fuente de datos. Sin embargo, hay una configuración en la consola QMC que usa la suplantación para ejecutar tareas de recarga con los permisos del propietario de la app en lugar de la cuenta del sistema interno. Al establecer esta configuración, se usa el propietario de la app y no SA_SCHEDULER para las recargas, lo que significa que no agrega SA_SCHEDULER en la tabla Section Access, sino que agrega al propietario de la app. Dentro de una cadena de tareas, las aplicaciones pueden tener diferentes propietarios con permisos para las fuentes que dependen de los derechos de acceso de cada propietario. Vea Clúster de servicios (solo en inglés) si desea más información.

Gestionar el acceso de los usuarios en un entorno con varias nubes

Un entorno multicloud de Qlik Sense implica una combinación de mecanismos de autenticación de usuarios. Normalmente con Qlik Sense Enterprise on Windows, el USERID en la tabla de autorización Section Access es verificado por el servicio del proxy. En Qlik Cloud, un proveedor de identidad asume ese rol de autenticación. En consecuencia, la sección de acceso que está configurada para un entorno local como Qlik Sense Enterprise on Windows no funcionará en un entorno en la nube.

Cuando se utiliza un proveedor de identidad OIDC (IdP de Qlik o IdP personalizado) con Qlik Cloud, se utiliza el subject claim para identificar a los usuarios cuando inician sesión. Con la sección de acceso, el valor del campo USERID en la tabla de autorización se compara con el valor de subject claim. Cuando configure su espacio empresarial inquilino, asegúrese de que el nombre de cuenta SAM esté asignado al subject claim de su proveedor de identidad. De modo que, por ejemplo, si su nombre de cuenta SAM es AD_DOMAIN\Dev, establezca el subject claim como AD_DOMAIN\Dev. Si desea ver el valor del subject claim o la IdP, adjunte /api/v1/diagnose-claims a la URL del espacio empresarial inquilino en el navegador, por ejemplo, su-espacioempresarial.es.qlikcloud.com/api/v1/diagnose-claims. En la respuesta JSON , el subject claim se denomina sub.

Si no puede utilizar el nombre de la cuenta SAM, existe una forma alternativa de autenticar a un usuario. Dado que las direcciones de correo electrónico tienden a permanecer igual en diferentes entornos, puede usar el campo USER.EMAIL en lugar de USERID en la tabla de autorización. Aquí tiene un ejemplo del aspecto que podría tener la tabla de autorización:

Script de autorización:

Observe que cada usuario tiene dos registros: Uno para acceso local y otro para acceso en la nube. Los caracteres comodín garantizan que solo se utilicen los campos de autenticación relevantes. En este ejemplo, COUNTRY se utiliza como campo de reducción de datos.

Directrices y consejos para utilizar sección de acceso

A continuación ofrecemos algunos datos importantes y sugerencias útiles que debe conocer sobre la sección de acceso.

• Todos los nombres de campo y valores mostrados 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.

  Upper - función de script y de gráfico

• No puede utilizar los nombres de campo de la sección de acceso mostrados como nombres de campo en su modelo de datos.
• Las apps deben publicarse antes de que se apliquen los controles de la sección de acceso. La recarga de la aplicación no aplica ningún script de sección de acceso nuevo o modificado.
• 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.
• 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.
• Un carácter comodín (*), 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.
• Los campos de seguridad se pueden colocar en diferentes tablas.
• Al cargar datos de un archivo QVD, la función Upper ralentiza la velocidad de carga.
• Si se ha quedado bloqueado y no logra acceder a una app mediante Section Access, puede abrir la app sin sus datos y editar la sección de acceso en el script de carga de datos. Esto requiere tener permisos de edición y recargar el script de carga de datos.

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

• Una carga binaria hará que la nueva app de Qlik Sense herede las restricciones de acceso.