Sécurité

Dernière mise à jour : 07/10/2026

Un mécanisme de sécurité dans QlikView peut être configuré de deux manières différentes : Il peut être intégré au script du document QlikView ou défini à l'aide de QlikView Publisher.

Authentification et autorisation

L'authentification est une procédure permettant de vérifier l'identité d'un utilisateur. QlikView peut laisser le système d'exploitation Windows effectuer l'authentification, demander l'ID utilisateur et le mot de passe (différents de l'ID utilisateur et du mot de passe Windows) ou utiliser le numéro de série de la licence QlikView comme méthode d'authentification simple.

Les autorisations permettent de vérifier, après identification de l'utilisateur, que ce dernier est autorisé à accéder à la ressource. QlikView peut laisser le système d'exploitation Windows effectuer les autorisations ou bien les effectuer lui-même. Pour cela, QlikView doit créer une table de sécurité dans le script.

Sécurité dans QlikView Publisher

Si QlikView Publisher est paramétré pour gérer la sécurité, chaque fichier QlikView est séparé en plusieurs fichiers contenant chacun les données de l'utilisateur ou du groupe d'utilisateurs concerné. Ces fichiers sont stockés dans des dossiers avec les paramètres de sécurité appropriés du système d'exploitation, c'est-à-dire que QlikView permet au système d'exploitation de gérer l'authentification et les autorisations.

Cependant, aucune sécurité n'est intégrée au fichier lui-même et il n'existe donc aucune protection pour les fichiers téléchargés.

Étant donné qu'un fichier est séparé en plusieurs fichiers et qu'un utilisateur n'ouvre que le fichier contenant ses propres données, les fichiers sont généralement plus petits. Cependant, cela implique que QlikView Server puisse éventuellement utiliser plus de mémoire que si toutes les données étaient contenues dans un seul fichier. En effet, plusieurs fichiers contenant les mêmes données peuvent être chargés.

Pour plus d'informations, consultez la documentation de QlikView Publisher.

Sécurité utilisant Section Access dans le script QlikView

Si Section Access est défini dans le script QlikView pour gérer la sécurité, un seul fichier est créé pour contenir les données d'un certain nombre d'utilisateurs ou de groupes d'utilisateurs. QlikView se sert des informations de Section Access pour l'authentification et les autorisations et réduit les données de façon dynamique afin que chaque utilisateur ne puisse consulter que ses propres données.

Le système de sécurité est intégré au fichier. Ainsi, un fichier téléchargé est également protégé. Cependant, si les demandes de sécurité sont importantes, il faut empêcher le téléchargement et l'utilisation hors ligne des fichiers. Les fichiers ne doivent être publiés que par QlikView Server.

Les données étant rassemblées dans un seul fichier, ce fichier peut potentiellement être très volumineux.

Il est possible de rendre invisibles les documents QlikView en mode Hors connexion. Pour rendre invisible un document utilisateur hors connexion, ajoutez l'attribut suivant dans la section des informations sur le document d'un document utilisateur à l'aide de QMC :

• Name:  Invisible
• Value: True

L'ensemble des informations ci-dessous concernent la méthode de sécurité consistant à utiliser Section Access dans le script QlikView.

Sections dans le script

L'accès au niveau des lignes 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.

Niveaux d'accès dans Section Access

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

Une personne disposant d'un accès ADMIN peut tout modifier dans le document. Grâce à l'onglet Sécurité des boîtes de dialogue Propriétés du document et Propriétés de la feuille, elle peut limiter les possibilités de modification du document dont disposent les utilisateurs. Une personne disposant de privilèges USER ne peut pas accéder aux onglets Sécurité.

Champs système de Section Access

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

Dans la section d'accès, vous pouvez charger tous les champs de sécurité, seulement certains d'entre eux ou aucun. Par conséquent, il n'est pas nécessaire d'utiliser USERID. L'autorisation peut être accordée au moyen d'autres champs, par exemple le numéro de série uniquement.

QlikView comparera le numéro de série QlikView au champ SERIAL, le nom d'utilisateur et les groupes Windows NT à NTNAME, le SID du domaine Windows NT à NTDOMAINSID et le SID Windows NT à NTSID. Il demandera ensuite un ID utilisateur et un mot de passe et les comparera aux champs USERID et PASSWORD.

Si l'ID utilisateur, le mot de passe et les propriétés d'environnement sont associés de la même manière que dans la table d'accès de section, le document s'ouvre avec le niveau d'accès correspondant. Sinon, QlikView refusera l'accès au document. Si l'ID utilisateur et/ou le Mot de passe ne sont pas saisis correctement au bout de trois tentatives, la procédure de connexion doit être reprise au début.

Comme la logique interne qui distingue QlikView est aussi utilisée dans la section d'accès, les champs de sécurité peuvent être indiqués dans différentes tables. (Ainsi, un gestionnaire de système peut créer un document QlikView en dehors des tables de sécurité. Dans ce cas, on simule un bon numéro de série, un mot de passe, etc. en cliquant sur la valeur de champ correspondante.)

Au cours de la procédure de connexion, QlikView vérifiera d'abord les champs SERIAL, NTNAME, NTDOMAINSID et NTSID afin de voir si ces informations sont suffisantes pour autoriser l'accès au document. Si c'est le cas, QlikView ouvrira le document sans demander d'ID utilisateur ni de Mot de passe.

Si seulement certains champs d'accès sont chargés, le programme utilise les informations requises appropriées parmi celles énumérées ci-dessus.

Tous les champs figurant dans les instructions LOAD ou SELECT de l'accès de section doivent être écrits en MAJUSCULES. Tout nom de champ contenant des lettres minuscules dans la base de données doit être converti en lettres majuscules à l'aide de la fonction upper avant d'être lu par l'instruction Load ou Select.

Upper - fonction de script et fonction de graphique

En revanche, l'ID utilisateur et le mot de passe saisis par l'utilisateur final ouvrant les documents QlikView ne tiennent pas compte de la casse.

Un caractère générique (*) est interprété comme toutes les valeurs (listées) du champ, c'est-à-dire une valeur figurant ailleurs dans la table. S'il est utilisé dans l'un des champs système (USERID, PASSWORD, NTNAME ou SERIAL) dans une table chargée dans la section d'accès du script, il est interprété comme toutes les valeurs possibles du champ (y compris celles qui ne figurent pas dans la liste).

Seul le numéro de série est vérifié. Le niveau d'accès ADMIN est accordé à un seul ordinateur. Tous les autres ordinateurs obtiennent le niveau d'accès USER. Notez que l'astérisque peut servir à indiquer « n'importe quel numéro de série ».

L'administrateur et le serveur sur lequel QlikView est exécuté en traitement par lots obtiennent un accès ADMIN. Tous les autres utilisateurs du domaine obtiennent un accès USER en saisissant l'ID utilisateur et le mot de passe « USER ».

Environnements mixtes

Si vous prévoyez d'utiliser la même table d'autorisation à la fois dans QlikView et Qlik Cloud, vous devez prendre en compte certains éléments :

• USERID a des significations différentes dans QlikView et Qlik Cloud, et pourrait, s'il est utilisé, 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 », etc. sont (ou seront) des champs d'authentification dans Qlik Sense Enterprise SaaS. Si vous utilisez ces champs dans votre Section Access, l'accès sera 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’ ou 'QLIKVIEW', l'accès peut être accordé. Cela signifie qu'il est possible d'avoir une table d'autorisation comme la suivante, où la ligne 1 accordera l'accès dans QlikView (mais pas dans Qlik Cloud) et la ligne 2 accordera l'accès dans Qlik Cloud (mais pas dans QlikView).

Restrictions concernant les fonctionnalités QlikView

Les contrôles figurant sur la page Propriétés du document : Sécurité et sur la page Propriétés de la feuille : Sécurité permettent de refuser l'accès à certains éléments de menu et d'interdire les modifications de la disposition. Pour que ces paramètres constituent une véritable mesure de protection, il est important que les utilisateurs du document soient connectés en tant que USER. Toute personne connectée en tant qu'ADMIN peut modifier les paramètres de sécurité à tout moment.

Un utilisateur qui a ouvert le document en disposant des droits USER ne dispose pas des onglets Sécurité dans les boîtes de dialogue Propriétés.

Réduction dynamique des données

QlikView et QlikView Server supportent une fonction qui permet de cacher une partie des données d'un document à l'utilisateur, en fonction de sa connexion à l'accès de section.

On peut d'abord cacher les champs (colonnes) à l'aide du champ système OMIT.

Deuxièmement, les enregistrements (lignes) peuvent être masqués en liant les données de l'Accès de section aux données réelles : la sélection des valeurs affichées/exclues est contrôlée au moyen d'un ou de plusieurs champs portant des noms communs dans la section access et la section application. Après la connexion de l'utilisateur, QlikView tentera de copier les sélections des champs figurant dans l'accès de section aux champs de l'application de section portant exactement les mêmes noms (qui doivent être écrits en MAJUSCULES). Ces sélections effectuées, QlikView masquera en permanence à l'utilisateur toutes les données ainsi exclues.

Pour pouvoir exécuter cette procédure, l'option Réduction initiale des données basée sur Accès de section sur la page Propriétés du document : Ouverture doit être sélectionnée. Si cette fonction est utilisée dans des documents censés être distribués par d'autres moyens que QlikView Server, cochez l'option Interdire le chargement de fichiers binaires disponible sous le même onglet afin de maintenir la protection des données.

section access;

LOAD * inline [

ACCESS, USERID, REDUCTION, OMIT

ADMIN, ADMIN, *,

USER, A, 1

USER, B, 2, NUM

USER, C, 3, ALPHA

];

section application;

T1:

LOAD *,

NUM AS REDUCTION;

LOAD

Chr( RecNo()+ord('A')-1) AS ALPHA,

RecNo() AS NUM

AUTOGENERATE 3;

Le champ REDUCTION (en lettres majuscules) existe désormais à la fois dans l'accès de section et l'application de section (toutes les valeurs de champ sont également en majuscules). Les deux champs seraient normalement complètement distincts, mais si l'option Réduction initiale des données basée sur Section Access est sélectionnée, ils seront liés et réduiront le nombre d'enregistrements affichés pour l'utilisateur.

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

Le résultat sera le suivant :

L'utilisateur A peut voir tous les champs, mais seulement les enregistrements connectés à REDUCTION=1.

L'utilisateur B peut voir tous les champs à l'exception de NUM, et uniquement les enregistrements connectés à REDUCTION=2.

L'utilisateur C peut voir tous les champs à l'exception de ALPHA, et uniquement les enregistrements connectés à REDUCTION=3.

Restrictions d'accès héritées

Avec un chargement binaire, les droits d'accès sont hérités par le nouveau document QlikView. Toute personne possédant des droits ADMIN pour ce nouveau document peut en modifier les droits d'accès en ajoutant une nouvelle section access. Une personne possédant des droits USER peut exécuter et modifier le script, ajoutant ainsi ses propres données au fichier binaire chargé. Il ne peut pas modifier les droits d'accès. Cela permet à un administrateur de base de données de contrôler l'accès des utilisateurs, y compris aux documents QlikView binaires chargés.

Chiffrement

La communication entre QlikView Server et un client QlikView Windows est codée. Cependant, en cas d'utilisation du client AJAX, la communication n'est pas codée.

En outre, tous les documents QlikView sont brouillés, ce qui rend les informations illisibles pour des visionneurs, débogueurs, etc.

Vous pouvez également chiffrer les données sensibles dans les fichiers QVD à l'aide de paires de clés fournies par le client, ce qui vous permet de contrôler qui a accès à vos données. Voir Chiffrement QVD (uniquement en anglais).

Propriétés du document : Sécurité

Propriétés du document : Sécurité

Propriétés de la feuille : Sécurité