Sécurité des données : cacher une application, une feuille ou une feuille communautaire ?

La sécurité et la confidentialité des données sont des éléments clé dans la gestion d’un environnement Qlik Sense. D’une part, certaines données ne peuvent être vues que par certains utilisateurs. D’autre part, certaines applications ou feuilles d’analyses aux sujets délicats ne devraient être vues/accessibles que par des utilisateurs clés.

Donner accès à des données à certains utilisateurs seulement

Pour le premier cas, la résolution est aisée et directement intégrée dans le script de chargement. En effet, la mise en place d’un « Section Access » permet, pour un utilisateur donné, de ne rendre visibles que les données qui lui sont liées.

Ainsi, un team leader d’un département « Sales » n’aura accès qu’aux données propres à son équipe.

Donner accès à des applications, des feuilles d’analyses aux sujets délicats à certains utilisateurs seulement

Pour le second cas, en revanche, la résolution devra passer par la console de gestion de Qlik Sense (Qlik Management Console) et plus particulièrement par les règles de sécurité.

Par défaut, un utilisateur ayant un droit d’accès à un Stream, aura le droit de vue sur l’ensemble de son contenu : applications, feuilles, graphiques, bookmarks, …

Afin de répondre à l’exigence de confidentialité, il est nécessaire qu’au sein d’un même Stream, certaines applications et/ou feuilles soient invisibles par défaut.

Seul un groupe défini d’utilisateurs aura la possibilité de les consulter, si et seulement si, leur catégorie correspond à la catégorie de l’application et/ou de la feuille.

Ainsi, une personne ayant la capacité de voir des éléments cachés, ne verra pas nécessairement tous les éléments cachés.

Afin d’illustrer la problématique, considérons le cas suivant :

Cas de l’application HR – Cacher des feuilles

Description :

Dans une entreprise de construction, une application HR analyse les prestations des ouvriers, les maladies et les salaires. Cette application est accessible pour l’ensemble de l’équipe HR (manager, collaborateurs administratif, responsable Payroll). Cette application comprend également quelques feuilles uniquement destinées à nourrir un rapport Nprinting.  Le reste des feuilles sont toujours en cours de développement (Analyse Bradford).

Besoin :

Les feuilles de prestations et de maladies doivent être visibles par tous les utilisateurs ayant un droit d’accès à l’application.  Les feuilles développées pour Nprinting ne doivent être visibles que par les développeurs. Les feuilles analysant les salaires ne doivent être visibles que par le manager HR et les responsables Payroll. Enfin, les feuilles Bradford (DEV) ne doivent être visibles de personne.

(Les développeurs peuvent consulter ces feuilles lorsqu’ils dupliquent l’application sur leur MyWork.)

Table 1 : Matrice de visibilité

Solution :

La solution présentée ci-dessous ignore volontairement les aspects plus techniques pour mettre en avant la logique générale (il n’est pas possible d’appliquer de « custom propreties » directement sur les feuilles. Pour cela, nous utilisons nom et description de feuille).

Dans un premier temps, il faudra assigner aux feuilles deux flags :

• HiddenSheet (YES/NO) : Est-ce une feuille à cacher ?
• HiddenSheetType(CONF, NP, DEV) : S’il s’agit bien d’une feuille à cacher, quel est son type de contenu ?

Le flag CONF sera utilisé pour toutes les feuilles dont le contenu peut-être qualifié de sensible. Le flag NP sera utilisé pour les feuilles dites « techniques » ne servant qu’à alimenter un rapport Nprinting sans réelle valeur pour un utilisateur QS. Enfin, le Flag DEV sera utilisé pour désigner les feuilles toujours en cours de développement.

Table 2 : Flags sur feuille

Une fois les flags utilisateurs/feuilles assignés, la règle de sécurité consistera à n’autoriser un utilisateur à voir une feuille cachée (HiddenSheet=’YES’) que si cette personne a le droit de voir des feuilles cachées (SeeHiddenSheet=’YES’) et que le type de contenu qu’il peut voir correspond bien au contenu de la feuille en question (User@HiddenSheetType = Sheet@HiddenSheetType).

Par exemple, le manager aura accès aux feuilles de salaires, car, bien que ces feuilles soient cachées par défaut, celui-ci a le droit de voir les feuilles cachées et le type de feuille qu’il est autorisé à voir correspond bien au type de la feuille (User@HiddenSheetType = Sheet@HiddenSheetType=’CONF’).

En revanche, le manager n’aura pas accès à la feuille NP, car bien que pouvant voir les feuilles cachées, celui ne possède pas le flag ‘NP’ (ici, seuls les développeurs possèdent ce flag).

On peut également signaler, que personne n’aura accès aux feuilles ‘Bradford (DEV)’, car aucun flag ‘DEV’ n’a été assigné.

Ce flag pourra ultérieurement être assigné à un utilisateur de référence en charge de valider les données tout en laissant la feuille invisible pour le reste des utilisateurs. Une fois les données validées, la feuille pourra être rendue visible pour tous via HiddenSheet=’NO’ et la suppression du flag ‘DEV’. Il n’est donc plus obligatoire de travailler avec un Stream de développement.

En conclusion :

La méthode présentée ci-dessus s’applique aussi bien aux Stream, aux apps, aux feuilles ou aux feuilles communautaires. Seul diffère le type de flag utilisé (« Propreties », « Customer Propreties » ou « Eléments de la feuille »). Elle permet ainsi aux entreprises de gérer la confidentialité de leurs données avec un maximum de flexibilité et permet également de simplifier certains processus (celui de validation des données notamment).