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

L'ensemble des noms de champ et des valeurs de champ répertoriés dans Accès de section sont toujours convertis en majuscules. Ainsi, tous les champs qui font partie d'une réduction de données doivent être convertis en majuscules afin de correspondre aux éléments indiqués dans l'instruction Section Access, même s'ils se trouvent en dehors de l'instruction Section Access. Vous pouvez convertir tout nom 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.

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

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.

USERID

Contient une chaîne correspondant à un nom d'utilisateur Qlik Cloud. Qlik Cloud récupère ensuite les informations de connexion de l'objet IdP et les compare à la valeur de ce champ. Pour une autre méthode permettant de vérifier l'identité de l'utilisateur via son adresse e-mail, voir USER.EMAIL. Pour les environnements multicloud, l'objet IdP peut être mappé par rapport à l'identité Windows interne. Lors de l'utilisation de Qlik Account, l'objet ne peut pas être mappé par rapport à l'identité Windows interne. L'objet IdP de l'utilisateur peut être affiché dans la section Utilisateurs de la Console de gestion.

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 à la version NetBIOS d'un nom de groupe ou d'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 Cloud récupère ensuite les informations de connexion de la revendication subject du fournisseur d'identité et les compare à la valeur de ce champ.

USER.EMAIL

Contient une chaîne correspondant à l'adresse e-mail d'un utilisateur. Qlik Cloud récupère ensuite ces informations auprès du fournisseur d'identité et les compare à la valeur de ce champ.

GROUP

Contient une chaîne correspondant à un groupe dans Qlik Cloud. Qlik Cloud obtient ensuite les informations auprès de la revendication “groups” du fournisseur d'identité et les compare à la valeur de ce champ.

Cette fonctionnalité n'est pas disponible dans Qlik Sense Business, dans Qlik Cloud Analytics - Standard ni lors de l'utilisation du fournisseur d'identité (IdP) Qlik.

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

Un utilisateur avec USERID AD_DOMAIN\C ne peut absolument pas ouvrir l'application, parce que cet ID utilisateur ne figure pas dans la table de sécurité.

Accès de section, 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 l'adresse e-mail d'un 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 USER.EMAIL 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, USER.EMAIL ADMIN, USER1@EXAMPLE.COM USER, USER2@EXAMPLE.COM USER, USER3@EXAMPLE.COM ]; Section Application;

Un utilisateur avec USER.EMAIL USER4@exemple.com ne peut absolument pas ouvrir l'application, parce que l'adresse e-mail de cet utilisateur ne figure pas dans la table de sécurité.

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

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

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;

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 USER1@EXAMPLE.COM peut voir tous les champs et uniquement les enregistrements visibles par les autres utilisateurs quand REDUCTION = 1 ou REDUCTION =2.
L'utilisateur USER2@EXAMPLE.COM peut voir tous les champs, mais uniquement les enregistrements associés à REDUCTION=1.
L'utilisateur USER3@EXAMPLE.COM peut voir tous les champs, mais uniquement les enregistrements associés à REDUCTION=2.
L'utilisateur USER4@EXAMPLE.COM 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, 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;

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 USER1@example.com peut voir tous les champs et uniquement les enregistrements visibles par les autres utilisateurs.
L'utilisateur USER2@example.com peut voir tous les champs, mais uniquement les enregistrements associés à REDUCTION=1.
L'utilisateur USER3@example.com peut voir tous les champs à l'exception de NUM, et uniquement les enregistrements associés à REDUCTION=2.
L'utilisateur USER4@example.com 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, AD_DOMAIN\DEV, *, *, ]; 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.
L'utilisateur AD_DOMAIN\DEV est autorisé à consulter toutes les données dans tous les champs.

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

Chargement de données dans Qlik Cloud

Pour charger une application sans réduction des données dans Qlik Cloud, il est recommandé d'utiliser le champ système USER.EMAIL de la table de sécurité. La valeur du champ USER.EMAIL doit être l'adresse e-mail des utilisateurs en mesure d'éditer et de charger l'application. Cela s'applique aux applications des espaces partagés et gérés. Par exemple :

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, TEST@EXAMPLE.COM, * ];

Dans cet exemple, l'utilisateur disposant de l'adresse e-mail test@example.com est ADMIN et peut charger l'application.

Si vous utilisez des groupes, l'exemple suivant fonctionne de la même manière pour Qlik Sense et pour Qlik Cloud :

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

Vous pouvez également mapper USERID de la table de sécurité vers subject claim du fournisseur d'identité, comme indiqué dans l'exemple suivant. Cette configuration est suggérée pour la migration de Qlik Sense vers Qlik Cloud et pour les environnements multi-cloud. Pour plus d'informations sur le mapping de USERID vers subject claim, voir Gestion de l'accès utilisateur dans un environnement multi-cloud.

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

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 ou SAML (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é :

ACCESS	USERID	USER.EMAIL	Commentaire	COUNTRY
USER	ABC\JOE	*	Access-on-prem	États-Unis
USER	*	JOE.SMITH@EXAMPLE.COM	Access-in-cloud	États-Unis
USER	ABC\URSULA	*	Access-on-prem	Allemagne
USER	*	URSULA.SCHULTZ@EXAMPLE.COM	Access-in-cloud	Allemagne
USER	ABC\STEFAN	*	Access-on-prem	Suède
USER	*	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.

Champs d'autorisation QlikView

À des fins de rétrocompatibilité, Qlik Cloud reconnaît les champs d'autorisation de QlikView. Même si USERID est interprété différemment dans QlikView et dans Qlik Cloud, il est interprété de la même façon dans Qlik Cloud et dans Qlik Sense : Il est comparé au nom de l'utilisateur authentifié.

PASSWORD, NTSID et NTDOMAINSID

Si l'un des champs PASSWORD, NTSID et NTDOMAINSID est utilisé et s'il contient une valeur pertinente, l'accès au document est refusé. Si le champ contient un caractère générique (*), l'accès peut être accordé, suivant les autres champs de la table d'autorisation.

SERIAL

Si le champ SERIAL est utilisé et s'il contient un numéro de licence, la ligne Accès de section refuse l'accès au document. Si le champ contient un caractère générique (*), l'accès peut être accordé, suivant les autres champs de la table d'autorisation.

De plus, dans Qlik Cloud, ce champ peut aussi être utilisé pour définir l'environnement. Cela signifie que si le champ contient la chaîne 'QLIKCLOUD', l'accès peut être accordé, suivant les autres champs de la table d'autorisation.

Environnements mixtes

Si vous planifiez d'utiliser la même table de sécurité dans QlikView et dans Qlik Cloud, notez les points suivants :

• USERID a différentes significations dans QlikView et dans Qlik Cloud, et, en cas d'utilisation, il pourrait entraîner des problèmes de sécurité. À la place, utilisez NTNAME, ou combinez-le avec SERIAL, comme décrit ci-dessous.

• GROUP et les champs commençant par ‘USER.’, tels que 'USER.NAME' et 'USER.EMAIL', sont (ou seront) des champs d'autorisation dans Qlik Cloud. Si vous utilisez ces champs dans votre Accès de section, l'accès peut être refusé dans Qlik Cloud.

• PASSWORD, NTSID et NTDOMAINSID ne peuvent pas être utilisés dans Qlik Cloud. L'accès sera refusé, sauf si vous utilisez un caractère générique.

• SERIAL ne peut pas être utilisé pour vérifier le numéro de licence dans Qlik Cloud. Cependant, si ce champ contient la chaîne ‘QLIKCLOUD’, il se peut que l'accès soit accordé. Cela signifie qu'il est possible d'avoir une table de sécurité comme la suivante, dans laquelle la ligne 1 accorde l'accès dans QlikView (mais pas dans Qlik Cloud), et la ligne 2 accorde l'accès dans Qlik Cloud (mais pas dans QlikView).

Tableau de sécurité
Ligne	SERIAL	USERID	Commentaire
1	4600 0123 4567 8901	*	Accorde l'accès au numéro de licence correct dans QlikView.
2	QLIKCLOUD	JOHN DOE	Accorde l'accès à l'utilisateur correct dans Qlik Cloud.

Script d'autorisation :

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

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

Les applications qui utilisent Accès de section ont recours à un utilisateur de l'index pour déterminer la quantité d'informations récupérée par Insight Advisor Chat auprès d'une application. L'utilisateur de l'index doit être l'utilisateur titulaire du plus haut niveau d'accès à l'application dans le script Accès de section. Cependant, les données fournies aux utilisateurs finaux sont toujours contrôlées par les limitations d'Accès de section.

Pour une démo visuelle de l'utilisation de l'accès de section et d'Insight Advisor Chat, voir :

Utilisation de l'accès de section et d'Insight Advisor Chat

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 des applications dans des espaces auxquels les utilisateurs ont accès. Elles peuvent inclure des applications auxquelles les utilisateurs n'ont pas accès dans Accès de section 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 défaut, le propriétaire de l'application est l'utilisateur de l'index. Vous pouvez modifier l'utilisateur de l'index dans Détails.

Procédez comme suit :

Dans Qlik Cloud, accédez à l'application.
Cliquez sur dans l'application et sélectionnez Détails.
Sous Utilisateur de l'index, sélectionnez l'utilisateur de l'index.
Cliquez sur Précédent.
Cliquez sur dans l'application et sélectionnez Charger.

Utilisation de QVD avec Accès de section

Il est possible de lire des fichiers QVD sous forme de chargement normal ou optimisé. Un chargement optimisé s'applique lorsqu'aucune transformation de données n'est effectuée lors du chargement et qu'il n'existe pas de filtres dans une clause WHERE.

Les chargements optimisés ne fonctionnent pas lors de l'utilisation de QVD avec Accès de section. Pour utiliser un fichier QVD pour charger des données dans Accès de section, vous devez développer le fichier QVD. La meilleure manière de développer le fichier QVD consiste à modifier le formatage lors du chargement des données.

Dans l'exemple suivant, le fichier QVD n'est pas développé, car aucun formatage n'est appliqué aux données.

Exemple d'échec en l'absence de formatage des données (chargement optimisé)

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd);

Au lieu de cela, vous pouvez par exemple utiliser la fonction upper() pour formater les données, ce qui développera le fichier QVD.

Exemple de fonctionnement correct avec formatage des données

section access; LOAD ACCESS, USERID, PASSWORD, upper([GROUP]) as [GROUP] FROM SAccess.qvd (qvd);

Vous pouvez également ajouter une instruction Where 1=1 à l'instruction LOAD.

Autre exemple de fonctionnement correct avec formatage des données

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd) where 1=1;

Recommandations et conseils pour utiliser Accès de section

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

L'ensemble des noms de champ et des valeurs de champ répertoriés dans Accès de section sont toujours convertis en majuscules. Ainsi, tous les champs qui font partie d'une réduction de données doivent être convertis en majuscules afin de correspondre aux éléments indiqués dans l'instruction Section Access, même s'ils se trouvent en dehors de l'instruction Section Access. Vous pouvez convertir tout nom 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.

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