Accéder au contenu principal

Gestion de la sécurité des données grâce à Section Access

Section Access est utilisé pour contrôler la sécurité d'une application. Il fait fondamentalement partie du script de chargement de données auquel vous ajoutez une table de sécurité pour définir qui à accès à quoi. Qlik Sense utilise ces informations pour réduire les données à l'étendue appropriée lorsqu'un utilisateur ouvre l'application. Cela signifie que certaines des données de l'application sont masquées à l'utilisateur en fonction de son identité. Section Access est étroitement intégré aux données de l'application et s'appuie dessus pour contrôler l'accès. Cette forme de réduction dynamique des données peut cibler des lignes et/ou des colonnes de table.

Remarque: Insight Advisor Chat ne prend pas en charge les applications qui utilisent Section Access.

Sections du script de chargement

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

Si une section d'autorisation 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, 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;

Notez qu'après avoir apporté des modifications au script de chargement, vous devez toujours charger les données pour que les modifications soient effectives.

Champs système Section Access

Les niveaux d'accès sont attribués aux utilisateurs dans une ou plusieurs tables de sécurité chargées dans la partie Section Access du script. Ces tables doivent contenir, au minimum, deux champs système : ACCESS, qui est le champ qui définit le niveau d'accès, et USERID ou USER.EMAIL . D'autres champs système facultatifs peuvent être ajoutés suivant le cas d'utilisation. Tous les champs système Section Access 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. Dans la table de sécurité, les utilisateurs peuvent se voir attribuer les niveaux d'accès ADMIN ou USER. Un utilisateur disposant des privilèges ADMIN a accès à l'intégralité des données contenues dans l'application, sauf s'il est limité par la table de sécurité. Un utilisateur bénéficiant des privilèges USER peut uniquement accéder aux données telles que définies dans la table de sécurité. Si aucun niveau d'accès valide ne lui est attribué, l'utilisateur ne peut pas ouvrir l'application.

Si Section access est utilisé dans un scénario de chargement, INTERNAL\SA_SCHEDULER, qui est l'utilisateur du service du planificateur, doit disposer d'un accès ADMIN pour pouvoir effectuer des chargements. Par exemple :

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

Si vous ne souhaitez pas utiliser le compte INTERNAL\SA_SCHEDULER, voir Utilisation de l'emprunt d'identité pour charger des données pour une autre méthode.

Si Section Access 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 Section Access. Par exemple :

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

USERID

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

Un caractère générique (*) est interprété comme tous les utilisateurs, soumis à d'autres conditions spécifiées dans la table de sécurité. Par exemple, dans la table de sécurité suivante, les utilisateurs qui figurent parmi les Administrateurs de clients Qlik Sense peuvent voir l'ensemble des valeurs REDUCTION répertoriées.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];
Remarque: USERID et NTNAME utilisent tous les deux les mêmes informations d'authentification. Il n'est donc pas nécessaire de vérifier les deux sur la même ligne de la table de sécurité. La différence entre les deux champs réside dans le fait que NTNAME vérifie aussi les groupes.

NTNAME

Remarque: NTNAME est un champ QlikView hérité et il est recommandé d'utiliser USERID si QlikView n'utilise pas la même table de sécurité.

Champ devant contenir une chaîne correspondant à un nom de groupe ou à un nom d'utilisateur de domaine Windows NT. Si un autre système d'authentification est utilisé, il doit contenir le nom d'un utilisateur authentifié. Qlik Sense récupère ensuite les informations de connexion auprès du système d'exploitation et les compare à la valeur de ce champ.

GROUP

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

SERIAL

Remarque: SERIAL est un champ QlikView hérité et il n'est pas utilisé si vous utilisez uniquement Qlik Sense.

Contient une chaîne correspondant à la plate-forme. Si le champ contient la chaîne ‘QLIKSENSE’ ou un caractère générique ‘*’, l'accès peut être accordé, suivant les autres champs de la table de sécurité.

Remarque: Si le champ SERIAL contient un numéro de licence, la ligne Section Access refuse l'accès au document. Ce paramètre est valide uniquement dans QlikView.

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.

Remarque: Il est recommandé 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.

Gestion de l'accès des utilisateurs à une application

Section access, sous sa forme la plus simple, peut être utilisé pour empêcher certains utilisateurs d'accéder à une application. L'accès à une application est refusé aux utilisateurs via une exclusion. En d'autres termes, si un ID utilisateur spécifique ne figure pas dans la table de sécurité, il ne pourra pas accéder à l'application. La seule exception à cette règle se produit si un caractère générique (*) est assigné au champ USERID sur l'une des lignes de la table de sécurité. Dans ce cas, un caractère générique signifie que tous les utilisateurs authentifiés peuvent accéder à l'application. Voici un exemple d'une table de sécurité avec une liste d'ID utilisateur :

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

Gestion de l'accès des utilisateurs à des données spécifiques d'une application

La réduction dynamique des données limite l'accès aux lignes et colonnes des tables de données des applications Qlik Sense après qu'un utilisateur a été autorisé à accéder à l'application elle-même.

Gestion de l'accès aux données au niveau des lignes

Limitez l'accès aux données au niveau des lignes en ajoutant une colonne de réduction des données à la table de sécurité dans la section Section Access du script de chargement. il est possible de masquer des enregistrements (lignes) spécifiques à des utilisateurs en liant les données Section Access aux données réelles. La sélection des données à afficher/exclure est contrôlée grâce à un ou plusieurs champs de réduction ayant des noms communs dans les parties Section Access et Section Application du script. Une fois l'utilisateur connecté, Qlik Sense met en correspondance les sélections effectuées dans les champs de réduction de la section d'accès avec tous les champs de la section d'application portant exactement 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. Si un caractère générique (*) est utilisé comme valeur de champ dans la colonne de réduction des données, il est interprété comme autorisant l'utilisateur à accéder aux enregistrements associés à tous les champs de réduction sélectionnés de la table de sécurité.

Remarque:

Le caractère générique * de la colonne de réduction des données fait référence uniquement à l'ensemble des valeurs de la table de sécurité. Si des valeurs situées dans Section Application ne sont pas disponibles dans la colonne de réduction de la table de sécurité, elles seront réduites.

Remarque: Tous les noms et 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 Section Access.
Remarque: Par défaut, 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. Si vous ne souhaitez pas utiliser le compte INTERNAL\SA_SCHEDULER, voir Utilisation de l'emprunt d'identité pour charger des données pour une autre méthode.

Example: Réduction des données au niveau des lignes basée sur l'identité de l'utilisateur

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;

Dans cet exemple, le champ REDUCTION (en majuscules) existe désormais dans Section Access et dans Section Application (toutes les valeurs des champs sont également en majuscules). En temps normal, les deux champs seraient différents et distincts mais, grâce à Section access, ils sont liés et réduisent le nombre d'enregistrements visibles par l'utilisateur.

Le résultat est le suivant :

  • L'utilisateur ADMIN peut voir tous les champs et uniquement les enregistrements visibles par les autres utilisateurs quand REDUCTION = 1 ou REDUCTION =2.
  • L'utilisateur A peut voir tous les champs, mais uniquement les enregistrements associés à REDUCTION=1.
  • L'utilisateur B peut voir tous les champs, mais uniquement les enregistrements associés à REDUCTION=2.
  • L'utilisateur C peut voir tous les champs et uniquement les enregistrements visibles par les autres utilisateurs quand REDUCTION = 1 ou REDUCTION =2.

Gestion de l'accès aux données au niveau des colonnes

Limitez l'accès aux données au niveau des colonnes en ajoutant un champ système OMIT à la table de sécurité dans le script Section access. L'exemple suivant se base sur l'exemple précédent dans lequel la réduction des données au niveau des lignes est déjà en place.

Example: Réduction des données au niveau des colonnes basée sur l'identité de l'utilisateur

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;

Le champ OMIT figurant dans Section Access définit les champs devant être masqués à l'utilisateur.

Le résultat est le suivant :

  • Dans cet exemple, lorsque REDUCTION=1, 2 ou 3, l'utilisateur ADMIN peut voir tous les champs et uniquement les enregistrements visibles par les autres utilisateurs.
  • L'utilisateur A peut voir tous les champs, mais uniquement les enregistrements associés à REDUCTION=1.
  • L'utilisateur B peut voir tous les champs à l'exception de NUM, et uniquement les enregistrements associés à REDUCTION=2.
  • L'utilisateur C peut voir tous les champs à l'exception de ALPHA, et uniquement les enregistrements associés à REDUCTION=3.
Remarque: Certaines visualisations présentent des conditions de données minimales à remplir pour pouvoir s'afficher. En conséquence, il se peut que le message "Visualisation incomplète" apparaisse lorsqu'un champ au niveau des colonnes est omis de la vue des données de l'utilisateur.

Gestion de l'accès aux groupes d'utilisateurs

Section Access vous permet de limiter l'étendue des données visibles par les utilisateurs via l'appartenance à un groupe. Pour restreindre vos données à l'aide de groupes d'utilisateurs, ajoutez le nom de champ GROUP à la table de sécurité de Section Access et définissez les valeurs du champ GROUP.

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 appartenant au 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 dans tous les champs, à l'exception de NUM.
  • Les utilisateurs faisant partie du groupe C sont autorisés à consulter les données associées à REDUCTION=3 dans tous les champs à l'exception d'ALPHA.
  • Les utilisateurs faisant partie du groupe GROUP1 sont autorisés à consulter les données associées à REDUCTION=3 dans tous les champs.

Qlik Sense compare l'utilisateur à la valeur 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 peut accéder à l'application.

Utilisation de l'emprunt d'identité pour charger des données

Par défaut, le compte système interne, SA_SCHEDULER, est utilisé pour exécuter les tâches de chargement. Ce compte dispose de privilèges élevés et, techniquement, peut utiliser n'importe quelle source de données. Cependant, dans QMC, il existe un paramètre qui utilise l'emprunt d'identité pour exécuter des tâches de chargement avec les autorisations du propriétaire de l'application au lieu de celles du compte système interne. Si vous configurez ce paramètre, le propriétaire de l'application et non SA_SCHEDULER est utilisé pour les chargements. Cela signifie que vous n'avez pas à ajouter SA_SCHEDULER à la table Section access. À la place, vous y ajoutez le propriétaire de l'application. Dans une chaîne de tâches, les applications peuvent avoir des propriétaires différents avec des autorisations auprès de ressources dépendant des droits d'accès de chaque propriétaire. Voir Service cluster (uniquement en anglais) pour plus d'informations.

Gestion de l'accès utilisateur dans un environnement multi-cloud

Un environnement multi-cloud Qlik Sense implique une combinaison de mécanismes d'authentification des utilisateurs. Généralement, avec Qlik Sense Enterprise on Windows, la valeur USERID de la table de sécurité Section Access est vérifiée par le service de proxy. Dans SaaS editions of Qlik Sense, un fournisseur d'identité assume ce rôle d'authentification. C'est pourquoi Section Access, qui est configuré pour un environnement On-Premise tel que Qlik Sense Enterprise on Windows, ne fonctionne pas dans un environnement cloud.

Lors de l'utilisation d'un fournisseur d'identité OIDC (IdP Qlik ou IdP personnalisé) avec SaaS editions of Qlik Sense, subject claim est utilisé pour identifier les utilisateurs lorsqu'ils se connectent. Avec Section Access, la valeur du champ USERID de la table de sécurité est comparée à la valeur de subject claim. Lorsque vous configurez votre client, assurez-vous que le nom de compte SAM est mappé vers le champ subject claim de votre fournisseur d'identité. Par exemple, si le nom de compte SAM est AD_DOMAIN\Dev, définissez le champ subject claim sur AD_DOMAIN\Dev. Si vous souhaitez voir la valeur de subject claim de l'IdP, ajoutez /api/v1/diagnose-claims à l'URL du client dans le navigateur, par exemple, your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. Dans la réponse JSON, le champ subject claim est appelé sub.

Si vous ne pouvez pas utiliser le nom de compte SAM, il existe une autre méthode pour authentifier un utilisateur. Étant donné que les adresses e-mail ont tendance à rester les mêmes dans des environnements différents, vous pouvez utiliser le champ USER.EMAIL au lieu de USERID dans la table de sécurité. Voici un exemple de ce à quoi peut ressembler la table de sécurité :

ACCÈS USERID USER.EMAIL Commentaire PAYS
UTILISATEUR ABC\Joe * Access-on-prem États-Unis
UTILISATEUR * joe.smith@example.com Access-in-cloud États-Unis
UTILISATEUR ABC\Ursula * Access-on-prem Allemagne
UTILISATEUR * ursula.schultz@example.com Access-in-cloud Allemagne
UTILISATEUR ABC\Stefan * Access-on-prem Suède
UTILISATEUR * stefan.svensson@example.com Access-in-cloud Suède

Script d'autorisation :

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

Notez que chaque utilisateur a deux enregistrements : L'un pour l'accès On-Premise et un pour l'accès dans le cloud. Les caractères génériques garantissent que seuls les champs d'authentification pertinents sont utilisés. Dans cet exemple, COUNTRY est utilisé comme champ de réduction des données.

Recommandations et conseils pour utiliser Section Access

Voici quelques faits importants et conseils utiles à savoir sur Section Access.

  • Tous les champs figurant dans les instructions LOAD ou SELECT de Section Access 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.

  • Vous ne pouvez pas utiliser les noms des champs système Section access indiqués comme noms de champ dans votre modèle de données.
  • Les applications doivent être publiées avant que les contrôles Section Access puissent être appliqués. Le chargement de l'application n'appliquera aucun script Section Access nouveau ou modifié.
  • 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.
  • 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 lors 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 caractère générique (*) est interprété comme toutes les valeurs (listées) du champ 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.
  • Les champs de sécurité peuvent être placés dans des tables différentes.
  • Lors du chargement de données à partir d'un fichier QVD, l'utilisation de la fonction Upper réduit la vitesse de chargement.
  • Si vous avez bloqué votre propre accès à une application en définissant Section Access, vous pouvez ouvrir l'application sans données et éditer Section Access dans le script de chargement de données. Cela nécessite un accès vous permettant de modifier et de charger le script de chargement de données.

    Pour plus d'informations, voir Ouverture d'une application sans données.

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