Saltar al contenido principal

Administrar la seguridad de los datos con Section Access

Section Access se utiliza para controlar la seguridad de una aplicación. Es básicamente una parte del script de carga de datos donde 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 aplicación se ocultan al usuario en función de su identidad de usuario. Section Access está estrechamente integrado con los datos de la app y se basa en los mismos para controlar el acceso. Esta forma de reducción dinámica de datos puede apuntar a filas, columnas o una combinación de ambas.

Nota informativaInsight Advisor Chat no es compatible con apps que utilicen Section Access.

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 autorización cargadas de la misma manera que los datos se cargan normalmente. Esto hace posible almacenar estas tablas en una base de datos estándar o en una hoja de cálculo. Las instrucciones de script que administran las tablas de autorización se dan dentro de una sección de autorización, cuyo inicio se marca en el script 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.

Example:  

Section Access; Load * INLINE [ ACCESS, USERID, REDUCTION USER, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, 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;

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 Se pueden agregar campos opcionales del sistema según 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 puede 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 ADMIN para realizar recargas. Por ejemplo:

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

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:

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

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.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];
Nota informativa USERID y NTNAME usan ambos 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.

NTNAME

Nota informativaNTNAME es un campo heredado de QlikView y se recomienda usar USERID si QlikView no está usando la misma tabla de autorización.

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

Nota informativaSERIAL es un campo heredado de QlikView y no se usa si solo está usando Qlik Sense.

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.

Nota informativaSi el campo SERIAL contiene un número de licencia la fila de Section Access 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.

Nota informativaLe 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.

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:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, AD_DOMAIN\ADMIN USER, AD_DOMAIN\A USER, AD_DOMAIN\B ]; Section Application;

Un usuario con USERID AD_DOMAIN\C no podría abrir la app en absoluto porque ese ID de usuario no aparece en la tabla de autorización.

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 de 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 Section Access 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. Tras el inicio de sesión del usuario, Qlik Sense hace coincidir las selecciones en los campos de reducción de la sección de acceso a cualquier campo en la sección de aplicación con exactamente los mismos nombres de campo (los nombres de campo deben escribirse 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 autorización.

Nota informativa

El carácter comodín * en la columna de reducción de datos se refiere solo a todos los valores de la tabla de autorización. Si hay valores en la sección Section Application que no están disponibles en la columna de reducción de la tabla de seguridad, se reducirán.

Nota informativaTodos 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.
Nota informativaDe manera predeterminada, si desea habilitar la recarga de script en una tarea de la consola Qlik Management Console, se requiere el usuario de la cuenta INTERNAL\SA_SCHEDULER con acceso a ADMIN. Si no desea utilizar la cuenta INTERNAL\SA_SCHEDULER, vea Usar la suplantación de identidad para recargar datos para un método alternativo.

Example: Reducción de datos a nivel de filas basada en ID de usuario

Section Access; Authorization: LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, * ADMIN, INTERNAL\SA_SCHEDULER, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

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 la 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 del sistema OMIT a la tabla de autorización en el script de Section Access. El ejemplo siguiente se basa en el ejemplo anterior en el que la reducción de datos de filas ya está en su lugar.

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

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT ADMIN, 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 OMIT, en Section Access 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

Section Access 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.

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;

El resultado será:

  • Los usuarios que pertenecen al grupo ADMIN pueden ver todos los datos y todos los campos.
  • Los usuarios que pertenecen al grupo A pueden ver todos los datos asociados con 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 al usuario con UserID y resuelve contrastándolo 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. No obstante, hay una configuración en QMC que utiliza 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 configurar esta opció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 de Section Access sino que en su lugar 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 usuarios a en un entorno multicloud

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 de la tabla de autorización de Section Access es verificado por el servicio del proxy. En SaaS editions of Qlik Sense, un proveedor de identidad asume ese rol de autenticación. En consecuencia, el Section Acess que está configurado 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 SaaS editions of Qlik Sense, se utiliza el subject claim para identificar a los usuarios al iniciar sesión. Con Section Access, 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 subject claim del IdP, agregue /api/v1/diagnose-claims a la URL del espacio empresarial inquilino en el navegador, por ejemplo, su-espacio.empresarial.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, hay una forma alternativa de autenticar a un usuario. Las direcciones de correo electrónico de los usuarios tienden a permanecer iguales en diferentes entornos. Si ese es el caso, puede usar el nombre de cuenta SAM 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:

ACCESS USERID USER.EMAIL Comment COUNTRY
USER ABC\Joe * Acceso local Estados Unidos
USER * joe.smith@example.com Acceso en la nube Estados Unidos
USER ABC\Ursula * Acceso local Alemania
USER * ursula.schultz@example.com Acceso en la nube Alemania
USER ABC\Stefan * Acceso local Suecia
USER * stefan.svensson@example.com Acceso en la nube Suecia

Script de autorización:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\Joe, *, United States USER, *, joe.smith@example.com, United States USER, ABC\Ursula, *, Germany USER, *, ursula.schultz@example.com, Germany USER, ABC\Stefan, *, Sweden USER, *, stefan.svensson@example.com, Sweden ];

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 Section Access

A continuación ofrecemos algunos datos importantes y sugerencias útiles que debe conocer sobre Section Access.

  • 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.

  • No puede usar los nombres de campo de Section Access enunciados como nombres de campo en su modelo de datos.
  • Las apps deben publicarse antes de que se apliquen los controles de Section Access. La recarga de la aplicación no aplica ningún script de Section Access 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, 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.
  • 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.