Planning Analytics - Sécurités et habilitations

Il n’est pas rare, fort heureusement, que les utilisateurs et contributeurs d’élaboration et de pilotage budgétaire n’aient pas accès à toutes les informations disponibles.

On pourrait par exemple citer quelques règles classiquement rencontrées un peu partout :

"Un Chef de Service ne peut saisir que les informations de son propre service, bien qu’il puisse consulter les informations de sa direction."

"Un chef de département peut consulter les informations de paie d’un salarié dès lors que ce salarié lui est affecté, uniquement le temps de cette affectation".

"Dès qu’un contributeur a soumis sa saisie dans le workflow, il ne peut plus la modifier." 

Comment peut-on traduire tout cela avec  Planning Analytics ?

Comment peut-on mettre en place ce que l’on appelle, entre informaticiens, le "Row Level Security" dans Planning Analytics ?  Très simplement ! Nopus allons vous le montrer dans ce tuto. 

[A] Quelques informations liminaires 

Les droits sont définis et appliqués sur des "groupes utilisateurs". 

Un utilisateur peut appartenir à zéro ou plusieurs groupes.

Si des droits contradictoires s’appliquent à plusieurs groupes auxquels appartient un même utilisateur, ce dernier bénéficiera des plus permissifs. 

On ne peut restreindre les droits des utilisateurs ayant le profil "Admin" (Le profil Admin est et reste omnipotent)

Nous restreindrons notre étude aux droits suivants :

• READ : autorisation de Lecture
• WRITE : Autorisation d’écriture (saisie)
• NONE : aucun droit, ne sait même pas que la chose existe

[B] Les droits sur les objets 

Nous pouvons (devons) appliquer des droits sur les objets de Planning Analytics.

À minima, nous définissons les droits sur les objets suivants :

Objet	Droit	Conséquence
Cube	NONE	Je ne sais même pas que le cube existe
	READ	J’ai la possibilité de lire des données de ce cube
	WRITE	J’ai la possibilité de saisir des données dans ce cube
Dimension	NONE	Je ne sais même pas que cette dimension existe
	READ	J’ai la possibilité de parcourir des membres de cette dimension
	WRITE	J’ai la possibilité de saisir des données sur des membres de cette dimension
Processus	NONE (par défaut)	Je ne peux pas exécuter ce processus, je ne sais même pas qu’il existe
	READ	J’ai le droit d’exécuter ce processus
Ecrans et arborescence	READ (par defaut)	Je peux utiliser cet écran
	NONE	Je ne peux pas utiliser cet écran, je ne sais même pas qu’il existe

[C] Les droits sur les données

Nous pouvons (devons) appliquer des droits sur les données contenues dans Planning Analytics.

Nous pouvons adosser ces droits à deux supports différents :

1/ Des membres d’une dimension

Lorsque j’ai les droits de lecture ou d’écriture sur un membre d’une dimension alors, sauf indication contraire par ailleurs, j’aurais ces droits sur les cellules des cubes utilisant cette dimension.

Dans cet exemple, le "Président" peut tout lire, les responsables de magasin ne peuvent écrire et lire que sur leur propre magasin.

2 / Des croisements de dimension

Imaginons la situation suivante :

Mon responsable du magasin 12 est autorisé à saisir les données de "Coûts" sur le 1er trimestre uniquement et peut en visualiser la marge résultante. On parle alors de sécurité à la cellule.

Bien-sûr, il a la capacité intellectuelle de déduire le montant du CA, mais il ne l’aura pas en lecture directe. Il ne saura même pas qu’il existe une vie après le premier trimestre !

[D] La gestion et manipulation de ces droits

Nous pouvons saisir ces informations manuellement, au travers des écrans d’administration dédiés du workspace. 

1/ En éditant la dimension

2/ En jouant avec le cube de sécurité de la dimension

[a] Préambule et rappel

Rappel des règles édictées par le Dr Edgar Frank Codd (informaticien britannique) qui a défini le relationnel dans les années 1970, les règles SGBDR début 80, et les règles OLAP début 90

Citons quelques unes de ces règles. 

RÈGLE 4 - Catalogue relationnel, dynamique et accessible directement :
La description de la base de données et de son contenu est représentée au niveau logique de la même manière que les données ordinaires (des tables).

RÈGLE 10 - Indépendance vis-à-vis de l’intégrité :
Les contraintes d'intégrité spécifiques à une base de données relationnelle sont définies à l'aide du langage relationnel et leur définition doit être stockée dans le catalogue et non dans des programmes d'application.

RÈGLE 12 - Non subversion :
Il ne doit pas être possible de transgresser les règles d’intégrité et les contraintes définies par le langage relationnel du SGBDR en utilisant un langage de plus bas niveau

Multidimensionnalité :
Le Modèle OLAP est multidimensionnel par nature

Transparence :
L’emplacement physique du serveur OLAP est transparent pour l’utilisateur

Accessibilité :
L’utilisateur OLAP dispose de l’accessibilité à toutes les données nécessaires à ses analyses

Stabilité :
La performance des reporting restent stables indépendamment du nombre de dimensions.

Client-Serveur :
Le serveur OLAP s’intègre dans une architecture client serveur

Dimensionnement :
Le dimensionnement est générique afin de ne pas fausser les analyses

Gestion complète :
Le serveur OLAP assure la gestion des données clairsemées

Multi-Utilisateurs :
Le serveur OLAP offre un support multi-utilisateurs (gestion des mises à jour, intégrité, sécurité)

Inter Dimension :
Le serveur OLAP permet la réalisation d’opérations inter dimensions sans restriction

Intuitif :
Le serveur OLAP permet une manipulation intuitive des données

Flexibilité :
La flexibilité (ou souplesse) de l’édition des rapports est intrinsèque au modèle.

Analyse sans limites :
Le nombre de dimensions et de niveaux d’aggrégation possibles est suffisant pour autoriser les analyses les plus poussées.

Bonne nouvelle : IBM Planning Analytics respecte complètement les 12 règles OLAP et va même plus loin en intégrant les règles SGBDR relatives aux métadonnées. 

Toutes les informations de "contrôle" d’une instance Planning Analytics sont stockées dans l’instance dans des cubes dit de "Contrôle".

On y trouve, pour notre plus grand bonheur, des cubes et dimensions comme : 

• Les dimensions listant les utilisateurs, les groupes, les cubes, les dimensions etc.



• Les cubes stockant les droits sur les dimensions, les cubes, les processus etc.

[b] Application dans les cubes

Nous avons donc des cubes de contrôles contenant la définition des règles de sécurité. Comme chacun sait, les valeurs contenues dans des cellules de cube peuvent-être définies :

• Par de la saisie
• Par des règles de calcul
• Par des processus Turbo-Integrator

Il en va de même pour les cubes de contrôles de sécurité sur lesquels nous pouvons opérer de la saisie, des règles de calculs, des alimentations par processus. 

Exemple avec le cube }ElementSecurity_Dim_Organisation : 

Exemple avec le cube de sécurité à la cellule :

Testons maintenant en nous connectant en tant que RespMagasin12. Nous avons pu saisir (dans un bac à sable) des coûts sur Janvier et Février, du CA sur Mars et nous ne pouvons pas visualiser le CA de Janvier et de Février ;-)

Dans la liste de choix des magasins, je n’ai que mon magasin de disponible :

[E] Sur couche de sécurité durant le Workflow

Lors d’un précédent article Gestion des workflows au sein du workspace Plannnig Analytics, nous avons évoqué la possibilité de poser des "surcouches" de sécurité en fonction de l’avancement du workflow, par exemple :

• En début de workflow, j’ai les droits d’écriture
• Lorsque je soumets, je n’ai plus les droits d’écriture, mais seulement de lecture

Bien sûr, cela ne concerne que la phase Budget !

Bonne nouvelle ! Il est possible de créer ces fameuses surcouches de sécurité, avec la notion de sécurité via les "cubes d’overlays"

[a] création du cube d’overlay :

Avant de définir notre cube d’overlay, nous devons définir quelles sont les dimensions nécessaires pour faire porter nos "surcharges de sécurité". 

• Dim_Phases : Oui, il faut différencier le Reel du Budget
• Dim_Mensuelle : Disons que Non, ce sera tout ou rien
• Dim_Organisation : Oui, bien évidement
• Dim_Indicateur : Disons que Non, ce sera tout ou rien

Au sein d’un processus Turbo integrator, nous allons exécuter l’instruction suivante :

Cette instruction indique que la première et troisième dimension du cube sera impliquée dans cette surcouche de sécurité. 

Après exécution, notre cube est présent et vide :

[b] utilisation du cube d’overlay :

Nous allons maintenant renseigner ce cube ( en mettant 1 (verouillé) ou 0 (déverouillé) ) dans les cellules idoines, soit manuellement (peu conseillé) soit au travers de de la fonction Turbo Integrator :

Renseignons maintenant ce cube cube d’overlay, en indiquant que nous désirons verrouiller les cellules : ‘Budget’ , ‘Magasin12’ de manière à ce qu’aucune saisie n’y soit possible. 

Avec un processus, nous exécutions la commande suivante :

Après exécution :

[c] vérification sur les données et vues

Qu’advient-t-il de notre Responsable du magasin 12 ?

Il ne peut plus saisir de données sur le budget de son seul et unique magasin !

D’ailleurs, personne ne peut saisir de données budget sur ce magasin ! Pas même le ChefRegion1 (qui peut cependant saisir sur Magasin 11)

(Le profil Admin, lui, peut continuer de tout faire, car il est omnipotent. )

Que pensez-vous qu’il va se passer si le ChefRegion1 saisie en masse sur la Région1 ?

• Réponse A : tous les magasins vont bouger
• Réponse B : Seul le magasin 11 va bouger

Solution :

[F] En synthèse

Avec IBM Planning Analytics, la mise en œuvre de la sécurité est extrêmement puissante mais elle peut se révéler extrêmement complexe à mettre en œuvre. 

=> Réfléchissez calmement et longuement avant de la mettre en œuvre.

=> Challengez vos key users qui pourraient avoir tendance à vous demander la lune.

=> Documentez à l’excès ce que vous mettez en œuvre.

[F] Pour aller plus loin

Codd’s Twelve Rules – Rel

Codd, E. F., Codd, S. B., & Salley, C. T. (1993). Providing OLAP (Online Analytical Processing) to User-Analysts: An IT Mandate. Technical Report. E. F. Codd & Associates, Camp Ridge, TX, USA

Surcouche de sécurité - Documentation IBM

SecurityOverlayGlobalLockCell - Documentation IBM

(Fonction plus lisible que SecurityOverlayGlobalLockNode) mais qui fait la même chose ;-) 

Retour page précédente Retour au Wiki

Vous souhaitez bénéficier d'experts, de développeurs, ou d'une formation sur Planning Analytics ? Rendez-vous sur la page Contact !