Sécurité

Un mécanisme de sécurité peut être défini de deux manières dans QlikView : 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. En effet, 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, voir la documentation de QlikView Publisher.

Sécurité utilisant l'accès de section 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 Serveur QlikView.

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 selon la même procédure que celle habituellement utilisée pour charger les données. Cela permet de stocker ces tables dans une base de données standard ou dans une feuille de calcul. Les instructions de script gérant les tables de sécurité figurent dans une section d'autorisation qui démarre dans le script par l'instruction Section Access.

Si une section d'autorisation est définie dans le script, la partie du script chargeant les données d'application doit se trouver dans une autre section, qui commence 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 l'accès de section

Les niveaux d'accès sont attribués aux utilisateurs dans une ou plusieurs tables chargées dans l'accès de session. 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 l'accès de section seront utilisés pour les authentifications ou les autorisations. L'ensemble des champs système section access est décrit ci-dessous.

Dans la section d'accès, vous pouvez charger tous les champs de sécurité, seulement certains d'entre eux ou aucun. Il n'est par conséquent 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 Section Access, 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 listés 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) de ce champ, c'est-à-dire une valeur figurant ailleurs dans cette table. S'il est utilisé dans l'un des champs système (USERID, PASSWORD, NTNAME ou SERIAL) d'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 planifiez d'utiliser la même table d'autorisation dans QlikView et dans Qlik Sense SaaS, vous devez garder en mémoire les points suivants :

• USERID a des significations différentes dans QlikView et dans Qlik Sense SaaS et, s'il est utilisé, il pourrait causer 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, il se peut que l'accès soit 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 un caractère générique est utilisé.

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

 

Restrictions concernant les fonctionnalités QlikView

Les contrôles disponibles sous les onglets Propriétés du document : Sécurité et Propriétés de la feuille : Sécurité permettent de bloquer l'accès à certains éléments de menu et d'interdire les modifications dans 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 le serveur QlikView prennent en charge une fonction qui permet de cacher une partie des données d'un document à l'utilisateur, en fonction de ses droits d'accès.

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

Vous pouvez ensuite masquer les enregistrements (lignes) en liant les données Section Access aux données réelles : La sélection des valeurs à afficher/exclure se fait en indiquant un ou plusieurs champs portant le même nom dans section access et dans section application. Après la connexion de l'utilisateur, QlikView tentera de copier les sélections des champs figurant dans section access aux champs section application 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, activez l'option Réduction initiale des données basée sur l'accès aux sections sous l'onglet Propriétés du document : Ouverture. 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 section access et dans section application (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 l'accès aux sections 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 section access 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 seulement les enregistrements connectés à REDUCTION=2.

L'utilisateur C peut voir tous les champs à l'exception d'ALPHA et seulement 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 coder des données sensibles dans des fichiers QVD avec les paires de clés fournies par le client, ce qui vous permet de contrôler qui a accès aux données. Voir Chiffrement QVD (uniquement en anglais).