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

Ejemplo:

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 otros campos de sistema opcionales 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 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:

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 ... ];

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

NTNAME es un campo de QlikView heredado y se recomienda utilizar 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

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

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.

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.

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;

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

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.

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.

De manera predeterminada, si desea habilitar la recarga de script en una tarea de la consola Consola de gestión de Qlik, 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.

Ejemplo: Reducción de datos a nivel de filas basada en la identidad 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 Section Access, 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 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.

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

Algunas visualizaciones tienen requisitos mínimos de datos que deben cumplirse para poder reproducirse. Como resultado, es posible que se muestre "Visualización incompleta" cuando se omita un campo de nivel de columna en la vista de datos de un usuario.

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.

Ejemplo: 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 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 Sense SaaS, 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 Qlik Sense SaaS, se utiliza el subject claim para identificar a los usuarios cuando inician 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 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:

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.

Usar Section Access y Insight Advisor Chat

Para que las apps que utilizan section access estén disponibles en Insight Advisor Chat, debe asegurarse de que los siguientes usuarios del servicio tengan acceso de administrador en el script de section access:

INTERNAL/sa_repository: Esto hace que el script de section access esté disponible con el servicio de repositorio para controlar el acceso de los usuarios.
INTERNAL/sa_scheduler: Esto permite que la app se recargue usanto tareas de QMC.

Si tiene información confidencial en los nombres de las apps, los nombres de los campos o los nombres de los elementos maestros, estos podrían quedar expuestos al hacer que las apps que utilizan Section Access estén disponibles para Insight Advisor Chat. Las sugerencias de consultas de las apps incluyen apps en streams a los que los usuarios tienen acceso. Estos pueden incluir aplicaciones a las que los usuarios no tienen acceso en la sección Section Access de una app. Sin embargo, seleccionar estas aplicaciones no hará nada. Al hacer clic en Dimensiones o Medidas para ver los elementos disponibles desde una app mediante el acceso Section Access, los usuarios pueden ver elementos a los que no tienen acceso. Sin embargo, hacer clic en estos elementos no proporcionará ningún dato a los usuarios.

Por ejemplo:

Section Access; LOAD * inline [ USERID ,ACCESS INTERNAL\sa_repository ,ADMIN INTERNAL\sa_scheduler ,ADMIN DOMAINNAME\user1 ,ADMIN DOMAINNAME\user2 ,USER DOMAINNAME\user3 ,USER ];

Una vez que estos usuarios estén en el script de Section Access, puede hacer que la app esté disponible para Insight Advisor Chat. Una vez que la app se recargue, la app estará disponible en Insight Advisor Chat.

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 usando la función Upper antes de que la sentencia LOAD o SELECT lean el campo.
Para más información, vea Upper - función de script y de gráfico.
No puede utilizar los nombres de campo de Section Access enumerados 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 (*), 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.

¿Esta página le ha sido útil?

No dude en indicarnos en qué podemos mejorar si encuentra algún problema en esta página o su contenido, como, por ejemplo, errores tipográficos, pasos que falta o errores técnicos.

Deje aquí sus comentarios