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. QlikView permet en fait 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 l'accès de section 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 d'accès de section 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 la console QMC :

  • Name: Invisible
  • Value: True

Les informations ci-dessous concernent la méthode de sécurité consistant à utiliser l'accès de section dans le script QlikView.

Sections dans le script

QlikView gère le contrôle des accès grâce à une ou plusieurs tables de sécurité chargées de la même manière que les données normales. Il est ainsi possible de stocker ces tables dans une base de données normale. Les instructions de script gérant les tables de sécurité figurent dans la section d'accès qui démarre dans le script par l'instruction section access.

Si une section d'accès est définie dans le script, la partie du script chargeant les données « normales » doit se trouver dans une autre section, qui commence par l'instruction section application.

Exemple :  

Section Access;

Load * inline

[ACCESS,USERID,PASSWORD

ADMIN, A,X

USER,U,Y ];

Section Application;

Load... ... from... ...

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

Remarque: Les droits d'accès ADMIN s'appliquent uniquement aux documents locaux. Les documents ouverts sur un serveur sont toujours accessibles à l'aide de droits USER.

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 pas forcément nécessaire d'utiliser USERID. L'autorisation peut se faire à l'aide des autres champs, à partir du numéro de série, par exemple.

 

ACCESS Champ qui définit le type d'accès de l'utilisateur correspondant.
USERID Champ qui doit contenir un ID utilisateur accepté. QlikView invite l'utilisateur à saisir un ID utilisateur qu'il compare à la valeur de ce champ. Cet ID utilisateur est différent de l'ID utilisateur de Windows.
PASSWORD Champ qui doit contenir un mot de passe accepté. QlikView invite l'utilisateur à saisir un mot de passe qu'il compare à la valeur de ce champ. Ce mot de passe est différent du mot de passe de Windows.
SERIAL Champ qui doit contenir un nombre correspondant au numéro de série de QlikView.
Exemple : 4900 2394 7113 7304
QlikView vérifiera le numéro de série de l'utilisateur et le compare à la valeur de ce champ.
NTNAME Champ qui doit contenir une chaîne correspondant à un nom d'utilisateur ou à nom de groupe du domaine Windows NT.
QlikView récupérera les informations de connexion auprès du système d'exploitation et les comparera à la valeur de ce champ.
NTDOMAINSID Champ qui doit contenir une chaîne correspondant à un SID du domaine Windows NT.
Exemple : S-1-5-21-125976590-4672381061092489882
QlikView récupérera les informations de connexion auprès du système d'exploitation et les comparera à la valeur de ce champ.
NTSID Champ devant contenir un SID Windows NT.
Exemple : S-15-21-125976590-467238106-1092489882-1378
QlikView récupérera les informations de connexion auprès du système d'exploitation et les comparera à la valeur de ce champ.
OMIT

Champ devant contenir le champ à omettre pour cet utilisateur spécifique. On peut utiliser des caractères génériques et le champ peut être vide. La méthode la plus facile est d'utiliser une fonction subfield.

Remarque: Vous ne devez pas appliquer OMIT aux champs clés, au risque de modifier la structure de données sous-jacente. Cela peut provoquer des îlots logiques et des incohérences de calcul.

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.

Voir  : 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 répertoriée 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).

Remarque: Lors du chargement de données à partir d'un fichier QVD, l'utilisation de la fonction upper ralentit la vitesse de chargement.
Remarque: Pour générer des tables d'accès dans des instructions inline, utilisez l'Assistant Table de restriction d'accès.
Remarque: Si vous avez activé l'accès de section, vous ne pouvez pas utiliser les noms des champs système de l'accès de section indiqués ici comme noms de champ dans votre modèle de données.

Exemple 1 :  

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

ACCESS SERIAL
ADMIN 4900 2394 7113 7304
USER *

Exemple 2 :  

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

ACCESS SERIAL NTDOMAINSID USERID PASSWORD
ADMIN * S-1-5-21-125976590-467238106-1092489882 ADMIN ADMIN
ADMIN 4900 2394 7113 7304 * * *
USER * S-1-5-21-125976590-467238106-1092489882 USER USER

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.

Remarque: Tous les noms de champs utilisés dans le transfert décrit ci-dessus et toutes les valeurs de ces champs doivent être en majuscules, car les noms et les valeurs de champs sont par défaut convertis en majuscules dans section access.

Exemple :  

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,

RechNo() 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.