Gestion de la sécurité grâce à l'accès de section

Vous pouvez utiliser l'accès de section dans le script de chargement de données pour gérer la sécurité. Ainsi, un seul fichier peut être utilisé pour conserver les données de plusieurs utilisateurs ou groupes d'utilisateurs. Qlik Sense se sert des informations de l'accès de section pour l'authentification et les autorisations, et réduit les données de façon dynamique afin que chaque utilisateur ne puisse visualiser que ses propres données.

Les groupes d'utilisateurs ne sont pas pris en charge dans Qlik Sense Enterprise on Kubernetes.

Le système de sécurité est intégré au fichier. Ainsi, un fichier téléchargé est également protégé, dans une certaine mesure. Néanmoins, si les exigences de sécurité sont strictes, il est recommandé d'interdire le téléchargement de fichiers et l'utilisation hors ligne. De même, seul le serveur Qlik Sense devrait pouvoir publier les fichiers. Les données étant conservées dans un seul fichier, celui-ci peut devenir extrêmement volumineux.

L'application doit être publiée avant que les contrôles d'accès à la section puissent être appliqués. Le rechargement de l'application n'appliquera aucun script d'accès à la section nouveau ou modifié.

Afin d'éviter d'exposer des données d'accès restreint, supprimez tous les fichiers joints dotés de paramètres d'accès de section avant de publier l'application.

Les fichiers joints sont inclus au moment de la publication de l'application. Si l'application publiée est copiée, les fichiers joints sont inclus dans la copie. Cependant, si des restrictions de l'accès de section ont été appliquées aux fichiers de données joints, les paramètres de l'accès de section ne sont pas conservés dans la copie des fichiers. Par conséquent, les utilisateurs de l'application copiée pourront consulter l'intégralité des données contenues dans les fichiers joints.

Un instantané affiche les données en fonction des droits d'accès de l'utilisateur qui prend l'instantané. L'instantané peut ensuite être partagé dans un récit. Toutefois, lorsque les utilisateurs reviennent à une visualisation à partir d'un récit pour consulter les données réelles dans l'application, ils sont limités par leurs propres droits d'accès.

N'attribuez pas de couleurs aux valeurs des dimensions principales si vous utilisez section access ou manipulez des données sensibles, car les valeurs peuvent être exposées par la configuration de couleur.

Sections dans le script

Le contrôle d'accès est géré au moyen d'une ou de plusieurs tables de sécurité chargées de la même façon que celle habituellement utilisée par Qlik Sense pour charger les données. Cela permet de stocker ces tables dans une base de données normale. Les instructions de script qui gèrent les tables de sécurité sont spécifiées dans la section d'accès lancée par l'instruction Section Access dans le script.

Si une section d'accès est définie dans le script, la partie du script qui charge les données de l'application doit être placée dans une autre section, lancée par l'instruction Section Application.

Example:

Section Access; LOAD * inline [ ACCESS, USERID USER, User_ID ]; Section Application; LOAD... ... from... ...

Champs système de l'accès de section

Les niveaux d'accès sont attribués aux utilisateurs dans une ou plusieurs tables chargées dans l'accès de section. Ces tables peuvent contenir plusieurs champs système propres à l'utilisateur, en général USERID, ainsi que le champ définissant le niveau d'accès, ACCESS. Tous les champs système de l'accès de section seront utilisés pour les authentifications ou les autorisations. Tous les champs système de l'accès de section sont décrits ci-dessous.

ACCESS

Définit le type d'accès de l'utilisateur correspondant.

L'accès aux applications Qlik Sense peut être restreint à certains utilisateurs ou groupes d'utilisateurs. Dans la table de sécurité, les utilisateurs peuvent se voir attribuer les niveaux d'accès ADMIN ou USER. Si aucun niveau d'accès valide ne lui est attribué, l'utilisateur ne peut pas ouvrir l'application.

Une personne bénéficiant des privilèges ADMIN a accès à l'intégralité des données contenues dans l'application, tandis qu'une personne dotée des privilèges USER peut uniquement accéder aux données telles que définies dans la table de sécurité.

Si l'accès de section est utilisé dans un scénario de génération d'application On-demand (ODAG) dans l'application modèle, l'utilisateur INTERNAL\SA_API doit être inclus comme ADMIN dans la table d'accès de section. Par exemple :

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

USERID

Contient une chaîne correspondant à un nom d'utilisateur Qlik Sense. Qlik Sense récupère ensuite les informations de connexion auprès du proxy et les compare à la valeur de ce champ.

GROUP

Contient une chaîne correspondant à un groupe dans Qlik Sense. Qlik Sense résout le nom d'utilisateur fourni par le proxy en le comparant à ce groupe.

Lorsque vous utilisez des groupes pour réduire les données et que vous souhaitez faire appel à Qlik Management Console, l'utilisateur du compte INTERNAL\SA_SCHEDULER est toujours requis.

OMIT

Contient le nom du champ devant être omis pour cet utilisateur précis. Il est possible d'utiliser des caractères génériques et de laisser le champ vide. Un moyen facile de procéder consiste à utiliser une fonction sub field.

Nous vous recommandons de ne pas appliquer OMIT aux champs clés. Les champs clés omis sont visibles dans le visionneur de modèle de données, mais leur contenu n'est pas disponible, ce qui peut dérouter les utilisateurs. De plus, si OMIT est appliqué à des champs utilisés dans une visualisation, les utilisateurs n'ayant pas accès aux champs omis risquent d'obtenir une visualisation incomplète.

Qlik Sense compare le nom d'utilisateur transmis par le proxy à l'identifiant d'utilisateur (UserID) et le résout par rapport aux groupes de la table. Si l'utilisateur fait partie d'un groupe dont l'accès est autorisé ou s'il correspond, il aura accès à l'application.

Étant donné que la même logique interne, qui est la caractéristique principale de Qlik Sense, est également utilisée dans la section d'accès, il est possible de placer les champs de sécurité dans des tables différentes. Tous les champs figurant dans les instructions LOAD ou SELECT de l'accès de section doivent être écrits en MAJUSCULES. Convertissez les noms de champ contenant des minuscules dans la base de données en majuscules grâce à la fonction Upper avant de lire le champ au moyen de l'instruction LOAD ou SELECT.

Pour plus d'informations, voir Upper - fonction de script et fonction de graphique.

Un caractère générique * est interprété comme toutes les valeurs (listées) du champ, c'est-à-dire une valeur figurant ailleurs dans la table. S'il est utilisé dans l'un des champs système (USERID, GROUP) d'une table chargée dans la section d'accès du script, il est interprété comme toutes les valeurs possibles (également non listées) du champ.

Lors du chargement de données à partir d'un fichier QVD, l'utilisation de la fonction upper ralentit la vitesse de chargement.

Si vous avez activé l'accès de section, vous ne pouvez pas utiliser les noms des champs système de l'accès de section indiqués ici comme noms de champ dans votre modèle de données.

Example:

Dans cet exemple, seuls les utilisateurs du groupe Finance sont habilités à ouvrir le document.

Accès au document
Accès	Groupe
USER	Finance

Réduction dynamique des données

Qlik Sense prend en charge la réduction dynamique des données qui permet de masquer une partie des données d'une application à un utilisateur, en fonction du type de connexion à l'accès de section dont ce dernier dispose :

Les champs (colonnes) peuvent être masqués au moyen du champ système OMIT.
Il est possible de masquer les enregistrements (lignes) en liant les données de l'accès de section aux données réelles : la sélection des valeurs à afficher/exclure est contrôlée grâce à un ou plusieurs champs ayant des noms communs dans l'accès de section et l'application de section. Une fois l'utilisateur connecté, Qlik Sense tente de faire correspondre les sélections effectuées dans les champs de l'accès de section avec des champs de l'application de section portant les mêmes noms (les noms des champs doivent être spécifiés en MAJUSCULES). Une fois les sélections effectuées, Qlik Sense masque de façon permanente de la vue de l'utilisateur l'ensemble des données exclues par ces sélections.

Les noms et les valeurs des champs utilisés dans l'exemple décrit ci-dessus doivent être en majuscules, car tous les noms et valeurs des champs sont, par défaut, convertis en majuscules dans l'accès de section.

Si vous souhaitez activer le chargement du script dans une tâche Qlik Management Console, l'utilisateur du compte INTERNAL\SA_SCHEDULER doté d'un accès ADMIN est requis.

Example: Réduction des données basée sur l'ID utilisateur

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;

Le champ REDUCTION (en majuscules) existe désormais dans l'accès de section et l'application de section (toutes les valeurs des champs sont également en majuscules). En temps normal, les deux champs seraient totalement différents et distincts mais, grâce à l'accès de section, ils sont liés et réduisent le nombre d'enregistrements visibles par l'utilisateur.

Le champ OMIT figurant dans l'accès de section définit les champs devant être masqués pour l'utilisateur.

Le résultat est le suivant :

Dans cet exemple, lorsque REDUCTION=1, 2 ou 3, l'utilisateur ADMIN peut consulter tous les champs et uniquement les enregistrements visibles par les autres utilisateurs.
L'utilisateur A peut consulter tous les champs, mais uniquement les enregistrements associés à REDUCTION=1.
L'utilisateur B peut consulter tous les champs à l'exception de NUM, et uniquement les enregistrements associés à REDUCTION=2.
L'utilisateur C peut consulter tous les champs à l'exception de ALPHA, et uniquement les enregistrements associés à REDUCTION=3.

Example: Réduction des données basée sur les groupes d'utilisateurs

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;

Le résultat est le suivant :

Les utilisateurs faisant partie du groupe ADMIN sont autorisés à consulter toutes les données et tous les champs.
Les utilisateurs faisant partie du groupe A sont autorisés à consulter les données associées à REDUCTION=1 dans tous les champs.
Les utilisateurs faisant partie du groupe B sont autorisés à consulter les données associées à REDUCTION=2, à l'exception du champ NUM.
Les utilisateurs faisant partie du groupe C sont autorisés à consulter les données associées à REDUCTION=3, à l'exception du champ ALPHA.
Les utilisateurs faisant partie du groupe GROUP1 sont autorisés à consulter les données associées à REDUCTION=3 dans tous les champs.
L'utilisateur INTERNAL\SA_SCHEDULER ne fait partie d'aucun groupe, mais il est autorisé à voir toutes les données figurant dans tous les champs.

Note Informations
Le caractère générique * inséré dans cette ligne fait uniquement référence aux valeurs comprises dans la table d'accès de section. Si des valeurs situées dans l'application de section ne sont pas disponibles dans l'accès de section du champ REDUCTION , elles seront réduites.

Restrictions d'accès héritées

Avec un chargement binaire, les restrictions d'accès sont héritées par la nouvelle application Qlik Sense.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – dites-nous comment nous améliorer !

Envoyer le commentaire