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 SaaS 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, USER.EMAIL, REDUCTION USER, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 ADMIN, USER4@example.com, ]; 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.

USERID

Contiene una cadena que corresponde a un nombre de usuario de Qlik Sense SaaS. Qlik Sense SaaS obtendrá la información de inicio de sesión del sujeto de IdP y la comparará con el valor de este campo. Para conocer una forma alternativa de verificar la identidad del usuario mediante la dirección de correo electrónico, vea USER.EMAIL. Para entornos con múltiples nubes, el sujeto de IdP se puede asignar a su identidad interna de Windows. Cuando se usa Qlik Account, el sujeto no se puede asignar a la identidad interna de Windows. El sujeto de la identidad IdP del usuario se puede ver en la sección Usuarios de Consola de gestión.

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 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 la versión NetBIOS de 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 SaaS obtendrá la información de inicio de sesión de la reclamación subject del proveedor de identidad y la comparará con el valor de este campo.

USER.EMAIL

Contiene una cadena que corresponde a la dirección de correo electrónico de un usuario. Qlik Sense SaaS obtendrá esta información del proveedor de identidad y la comparará con el valor de este campo.

GROUP

Contiene una cadena que corresponde a un grupo de Qlik Sense SaaS. Qlik Sense SaaS obtendrá la información de inicio de sesión de la reclamación “groups” del proveedor de identidad y la comparará con el valor de este campo.

Nota informativaLos grupos de usuarios no son compatibles con Qlik Sense Business o cuando se utiliza Proveedor de identidad (IdP) de Qlik

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

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.

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 una dirección de correo electrónico 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 USER EMAIL 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, USER.EMAIL ADMIN, USER1@example.com USER, USER2@example.com USER, USER3@example.com ]; Section Application;

Un usuario con USER.EMAIL USER4@example.com no podría abrir la app en absoluto, porque esa dirección de correo electrónico 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. 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.

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.

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

Section Access; Authorization: LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 USER, USER4@example.com, * ]; 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 USER1@example.com puede ver todos los campos y solo aquellos registros que otros usuarios pueden ver cuando REDUCTION = 1 o REDUCTION =2.
  • El usuario USER2@example.com puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=1.
  • El usuario USER3@example.com puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=2.
  • El usuario USER4@example.com 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, USER.EMAIL, REDUCTION, OMIT ADMIN, USER1@example.com, *, USER, USER2@example.com, 1, USER, USER3@example.com, 2, NUM USER, USER4@example.com, 3, ALPHA ]; 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 USER1@example.com 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 USER2@example.com puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=1.
  • El usuario USER3@example.com puede ver todos los campos excepto NUM y solo aquellos registros asociados a REDUCTION=2.
  • El usuario USER4@example.com puede ver todos los campos excepto ALPHA y solo aquellos registros asociados a REDUCTION=3.
Nota informativaAlgunas 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, AD_DOMAIN\DEV, *, *, ]; 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
  • El usuario AD_DOMAIN\DEV puede ver todos los datos de todos los campos.

Qlik Sense SaaS 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.

Recargar datos en Qlik Sense SaaS

Para recargar una app sin reducción de datos en Qlik Sense SaaS, se recomienda utilizar el campo de sistema USER.EMAIL en la tabla de autorización. El valor del campo USER.EMAIL debe ser la dirección de correo electrónico de los usuarios que pueden editar y cargar la app. Esto se aplica a apps tanto en espacios compartidos como administrados. Por ejemplo:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, test@example.com, * ];

En este ejemplo, el usuario con la dirección de correo electrónico test@example.com es ADMIN y puede recargar la app.

Si está utilizando grupos, el siguiente ejemplo funcionaría igualmente para ambos Qlik Sense y Qlik Sense SaaS:

Section Access; LOAD * inline [ ACCESS, GROUP, REDUCTION ADMIN, Developers, * ];

También puede asignar el USERID en la tabla de autorización al subject claim del proveedor de identidad, como se muestra en el siguiente ejemplo. Esta configuración se sugiere para migrar de Qlik Sense a Qlik Sense SaaS y hacia entornos multicloud. Para más información sobre cómo asignar USERID a subject claim, vea Gestionar el acceso de los usuarios en un entorno con varias nubes

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\DEV, * ];

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.

Campos de autorización de QlikView

Para compatibilidad con versiones anteriores, Qlik Sense SaaS reconoce los campos de autorización de QlikView. Aunque USERID se interpreta de modo diferente en QlikView y Qlik Sense SaaS, en Qlik Sense SaaS se interpretará de la misma manera que en Qlik Sense: Se comparará con el nombre del usuario autenticado.

PASSWORD, NTSID y NTDOMAINSID

Si se usa uno de los campos PASSWORD, NTSID y NTDOMAINSID contiene un valor relevante, se deniega el acceso al documento. Si el campo contiene un comodín (*), se puede otorgar acceso, dependiendo de los otros campos en la tabla de autorización.

SERIAL

Si se usa el campo SERIAL y contiene un número de licencia, la fila de Acceso a la sección /Section Access) denegará el acceso al documento. Si el campo contiene un comodín (*), se podría otorgar acceso, dependiendo de los otros campos en la tabla de autorización.

Además, en Qlik Sense SaaS este campo también se puede utilizar para definir el entorno. Esto significa que si el campo contiene la cadena "QLIKCLOUD’", se podría otorgar acceso dependiendo de los otros campos en la tabla de autorización.

Entornos mixtos

Si planea usar la misma tabla de autorización en ambos, QlikView y Qlik Sense SaaS, tenga en cuenta que:

USERID tiene diferentes significados en QlikView y Qlik Sense SaaS, y podría, si se utiliza, ocasionar problemas de seguridad. Utilice NTNAME en su lugar o combínelo con SERIAL tal como se describe debajo.

GROUP y los campos que comienzan por "USER.", como por ejemplo "USER.NAME" y "USER.EMAIL", son (o serán) campos de autorización en Qlik Sense SaaS. Si usa estos campos en su Sección de acceso, es posible que se le deniegue el acceso a Qlik Sense SaaS.

PASSWORD, NTSID y NTDOMAINSID no se pueden usar en Qlik Sense SaaS. Se denegará el acceso, a menos que se utilice un comodín.

SERIAL no se puede utilizar para comprobar el número de licencia en Qlik Sense SaaS. Sin embargo, si este campo contiene la cadena "QLIKCLOUD", es posible que se otorgue acceso. Esto significa que es posible tener una tabla de autorización como la siguiente, donde la línea 1 otorgará acceso a QlikView (pero no a Qlik Sense SaaS), y la línea 2 otorgará acceso a Qlik Sense SaaS (pero no a QlikView).

Tabla de autorización
Line SERIAL USERID Comentario
1 4600 0123 4567 8901 * Otorga acceso al número de licencia correcto en QlikView.
2 QLIKCLOUD John Doe Otorga acceso al usuario correcto en Qlik Sense SaaS.

Script de autorización:

Section Access; LOAD * INLINE [ ACCESS, USERID, SERIAL USER, *, 4600 0123 4567 8901 USER, John Doe, QLIKCLOUD ];

Usar Section Access y Insight Advisor Chat

Las apps que utilizan acceso a secciones (Section Access en el script) utilizan un usuario de indexación para determinar cuánta información deberá recuperar Insight Advisor Chat de la app. El usuario de indexación deberá ser el usuario con el nivel más alto de acceso a la app en el script con acceso a secciones. No obstante, los datos proporcionados a los usuarios finales seguirán estando controlados por las limitaciones de acceso a secciones que imponga Section Access.

Nota de aviso

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.

De manera predeterminada, el propietario de la app es el usuario de indexación. Puede cambiar el usuario de indexación en Detalles.

  1. En Qlik Cloud, navegue hasta la app.

  2. Haga clic en Más en la app y seleccione Detalles.

  3. Enr Usuario de indexación, seleccione el usuario de indexación.

  4. Haga clic en Atrás.

  5. Haga clic en Más en la app y seleccione Recargar.

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.