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 SaaS 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, 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 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.

USERID

Contient une chaîne correspondant à un nom d'utilisateur Qlik Sense SaaS. Qlik Sense SaaS 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 multi-cloud, 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 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 ... ];
Note Informations 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

Note InformationsNTNAME 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 Sense SaaS récupère ensuite les informations de connexion de la demande 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 Sense SaaS 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 Sense SaaS. Qlik Sense SaaS obtient ensuite les informations auprès de la demande “groups” du fournisseur d'identité et les compare à la valeur de ce champ.

Note InformationsLes groupes d'utilisateurs ne sont pas pris en charge dans Qlik Sense Business ou 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.

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

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

Note Informations

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.

Note InformationsTous 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.

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

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 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 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.
Note InformationsCertaines 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.

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 :

  • 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.
  • L'utilisateur AD_DOMAIN\DEV est autorisé à consulter toutes les données dans tous les champs.

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

Pour charger une application sans réduction des données dans Qlik Sense SaaS, 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 Sense SaaS :

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 Sense SaaS et pour les environnements multi-cloud. Pour plus d'informations sur le mappage 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é Section Access est vérifiée par le service de proxy. Dans Qlik Sense SaaS, 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 Qlik Sense SaaS, 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 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 : 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.

Champs d'autorisation QlikView

À des fins de rétrocompatibilité, Qlik Sense SaaS reconnaît les champs d'autorisation de QlikView. Même si USERID est interprété différemment dans QlikView et dans Qlik Sense SaaS, il est interprété de la même façon dans Qlik Sense SaaS 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 Section Access 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 Sense SaaS, 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 Sense SaaS, notez les points suivants :

USERID a différentes significations dans QlikView et dans Qlik Sense SaaS, 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 Sense SaaS. Si vous utilisez ces champs dans votre Section Access, l'accès peut être refusé dans Qlik Sense SaaS.

PASSWORD, NTSID et NTDOMAINSID ne peuvent pas être utilisés dans Qlik Sense SaaS. 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 Sense SaaS. 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 Sense SaaS), et la ligne 2 accorde l'accès dans Qlik Sense SaaS (mais pas dans QlikView).

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

Script d'autorisation :

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

Utilisation de Section Access et de Insight Advisor Chat

Les applications qui utilisent Section Access 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 Section Access. Cependant, les données fournies aux utilisateurs finaux sont toujours contrôlées par les limitations de Section Access.

Note Avertissement

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

  1. Dans Qlik Cloud, accédez à l'application.

  2. Cliquez sur Plus dans l'application et sélectionnez Détails.

  3. Sous Utilisateur de l'index, sélectionnez l'utilisateur de l'index.

  4. Cliquez sur Précédent.

  5. Cliquez sur Plus dans l'application et sélectionnez Charger.

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.