Gestion de la sécurité des données grâce à Accès de section

Accès de section 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 lorsque l'utilisateur ouvre l'application, à savoir, 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. Pour plus d'informations, voir Fiabilité et sécurité chez Qlik.

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.

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 actualiser les données pour que les modifications soient effectives.

Champs système Accès de section

Les niveaux d'accès sont attribués aux utilisateurs dans une ou plusieurs tables de sécurité chargées dans la partie Accès de section 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 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. 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 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 Accès de section. 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 ... ];

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

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

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

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.

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 Accès de section du script de chargement. il est possible de masquer des enregistrements (lignes) spécifiques à des utilisateurs en liant les données Accès de section 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 Accès de section 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é.

Lorsque Qlik Sense compare le champ de réduction d'Accès de section aux champs du modèle de données, les comportements suivants sont à prévoir :

Si une valeur de champ du modèle de données correspond au champ de réduction d'Accès de section, l'application s'ouvrira en affichant les données correspondant à l'utilisateur spécifié. Les autres données seront masquées.
Si la valeur du champ de réduction ne correspond à aucune des valeurs du modèle de données, l'application ne s'ouvrira pas pour un UTILISATEUR normal. En revanche, elle s'ouvrira sans réduction pour un utilisateur marqué comme ADMIN.

Il n'est pas recommandé d'utiliser plusieurs champs de réduction dans Accès de section, car cela permet d'autres combinaisons d'accès que celles prévues.

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.

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.

Par défaut, si vous souhaitez activer le chargement du script dans une tâche Console de gestion Qlik, 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.

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 Accès de section 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 à Accès de section, 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 Accès de section. 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.

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 Accès de section 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.

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

Accès de section 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é d'Accès de section et définissez les valeurs du champ GROUP.

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 :

Dans cet exemple, lorsque REDUCTION est 1, 2 ou 3, les utilisateurs appartenant au groupe ADMIN sont autorisés à voir tous les champs et uniquement les enregistrements visibles par les autres utilisateurs.
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 à 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é Accès de section est vérifiée par le service de proxy. Dans Qlik Cloud, un fournisseur d'identité assume ce rôle d'authentification. C'est pourquoi Accès de section, qui est configuré pour un environnement sur site tel que Qlik Sense Enterprise on Windows, ne fonctionnera pas dans un environnement cloud.

Lors de l'utilisation d'un fournisseur d'identité OIDC (IdP Qlik ou IdP personnalisé) avec Qlik Cloud, subject claim est utilisé pour identifier les utilisateurs lorsqu'ils se connectent. Avec Accès de section, 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 la valeur subject claim de votre fournisseur d'identité. Par exemple, si le nom de compte SAM est AD_DOMAIN\Dev, définissez 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 : Un pour l'accès sur site 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.

Utilisation d'Accès de section et de Insight Advisor Chat

Pour que les applications qui utilisent Section Access soient disponibles dans Insight Advisor Chat, vous devez vous assurer que les utilisateurs de services suivants disposent d'un accès admin dans le script Section Access :

INTERNAL/sa_repository : cela met le script Section Access à disposition avec le service de référentiel pour contrôler l'accès utilisateur.
INTERNAL/sa_scheduler : cela permet le chargement de l'application via des tâches QMC.

Si vous avez des informations sensibles dans des noms d'application, des noms de champ ou des noms d'élément principal, elles risquent d'être exposées si vous rendez les applications qui utilisent Section Access disponibles pour Insight Advisor Chat. Les suggestions d'applications pour les requêtes incluent les applications des flux auxquels les utilisateurs ont accès. Elles peuvent inclure des applications auxquelles les utilisateurs n'ont pas accès dans Section Access d'une application. En revanche, la sélection de ces applications n'aura aucun effet. Si vous cliquez sur Dimensions ou sur Mesures pour afficher les éléments disponibles depuis une application qui utilise Section Access, les utilisateurs peuvent voir des éléments auxquels ils n'ont pas accès. En revanche, s'ils cliquent sur ces éléments, ils n'obtiendront aucune donnée.

Par exemple :

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

Une fois que ces utilisateurs figurent dans le script Section Access, vous pouvez mettre l'application à disposition pour Insight Advisor Chat. Une fois l'application chargée, elle sera disponible dans Insight Advisor Chat.

Recommandations et conseils pour utiliser Section Access

Voici quelques faits importants et conseils utiles à savoir sur Accès de section.

L'ensemble des valeurs et noms de champ figurant dans les instructions LOAD ou SELECT d'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.
Vous ne pouvez pas utiliser les noms des champs système Accès de section indiqués comme noms de champ dans votre modèle de données.
Les applications doivent être publiées avant que les contrôles Accès de section puissent être appliqués. Le chargement de l'application n'appliquera aucun script Accès de section 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 Accès de section 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.

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 !

Laissez vos commentaires ici