Gestion des habilitations

Bonjour à tous :ccool:


Je travaille actuellement sur une base de données Oracle qui contient les données d'une société dans domaine médical, prochainement cette même base accueillera les données d'autres sociétés, dans l'expression de besoin il est bien précisé que une gestion des habilitations doit être mise en place afin d'empêcher les utilisateurs d'une société donnée de visualiser les données d'autres société

Pour l'instant j'ai pensé à deux solutions possibles :

01) Intégration de toutes les sociétés dans la base actuelle + création des vues matérialisée par société

- Avantages :
- Facile à mettre en place
- Inconvénients
- Vu la volumétrie des données, les temps de traitements vont êtres longs

02) Séparation des données par schéma

- Avantages :
- Temps de traitements faibles
- Plus sécurisé
- Inconvénients
- la mise en place est extrêmement complexe


Que en pensez-vous ?

D'autres informations seraient nécessaires pour vous faire des suggestions :
- Quelle est votre version d'Oracle ?
- Êtes-vous en édition Entreprise ?
- Combien de sociétés environ allez-vous avoir ?
- Y a-t-il des périodes (la nuit notamment) sans activité applicative qui permettent de faire des opérations de maintenance ?

Merci de votre réponse :ccool:et voici quelques informations utiles :

- La version oracle est 9.2, Edition entreprise
- Pour la volumétrie :
- La base contient une 40 de tables environ, parmi ces tables il y a 4 grosse tables (environ 20 millions de lignes pour chacune), le reste c'est du référentiel et des tables de paramétrage
- Pour les Indexes : les temps de réponses actuellement restent acceptables
- la base est alimentée quotidiennement la nuit (temps de traitement ne dépasse pas les 20 minutes)
- la base se trouve sur une instance qui contient d'autres schémas
- les statistiques de traitement (DBMS_STAT) sont calculées quotidiennement pour alimenter la table (Plan_table)
- le Plan d'exécution des principales requêtes, passe principalement par les index
- la volumétrie moyenne du fichier source est 100 Mo Quotidiennement (20 chargement/mois)
- 6 Nouvelles sociétés à intégrer dans la base (Même volumétrie et même procédure d'alimentation)
- La purge de la base est faite tous les 4 ans

Cordialement.

La solution industrielle adaptée à votre contexte, c'est typiquement les prédicats dynamiques à la VPD.
Soit la table T1, dans laquelle vous avez vos données, toutes sociétés confondues.
On peut se débrouiller pour que les requêtes qui touchent T1 soient transformées à la volée pour ajouter un filtrage dépendant de l'utilisateur qui les a lancées.

Par exemple, si l'utilisateur S1 exécute "SELECT * FROM T1", ça se transforme en "SELECT * FROM T1 WHERE SOCIETE='S1'".
Si c'est S2, ça se transforme en "SELECT * FROM T1 WHERE SOCIETE='S2'".
Voir le tutoriel suivant pour plus de détails : http://schelabi.developpez.com/securitegranulaire/

L'avantage de cette formule, c'est que vous avez un seul schéma de données, que vous n'avez aucun objet à dupliquer, et que ça sera facilement évolutif indépendamment du nombre de sociétés.

Si vous faites un schéma applicatif par société, il faudra bien sûr dupliquer tous les objets (tables, procédures, déclencheurs) à chaque nouvelle société ; mais de plus, il faudra reporter chaque petite correction ou évolution dans tous les schémas. Ça complexifie aussi la procédure de chargement des données.
Je doute que cela soit très viable pour 7 sociétés, mais imaginez si vous en avez 50.

Du point de vue du PL/SQL, on peut néanmoins s'alléger la tâche en utilisant les procédures en mode AUTHID CURRENT USER. De cette sorte, un seul exemplaire des procédures serait suffisant, au lieu de les dupliquer dans chaque schéma. Par contre, il faudrait gérer les droits, donc il n'est pas certain que le jeu en vaille la chandelle.

Quant aux vues matérialisées, bienvenue au pays de l'usine à gaz !
Si je vous suis bien, vous auriez une VM différente par société, ce qui veut donc dire que toutes vos requêtes devront être construites dynamiquement pour aller attaquer la VM adaptée, selon l'identité de l'utilisateur.
En outre, vous serez à la merci des problématiques de rafraîchissement (ATOMIC_REFRESH qui ne fonctionne pas en V9, etc), du besoin de modifier vos données au lieu de faire du SELECT pur...
A mon avis, à fuir comme la peste !

J'ajouterai que vous pouvez également partitionner vos grosses tables par société !

Merci pour toutes ces précisions :ccool:

• Je trouve la solution vraiment intéressante, sur tous les cotés (Mise en place, maintenance, fiabilité ....)
• Je pense qu'une restructuration des index sera nécessaire puisque la requête fera un filtrage supplémentaire sur la colonne société (Varchar2) ..!!!
• Pensez-vous que le partitionnement de ces tables volumineuses sera nécessaire pour éviter les ralentissements qui seront liés à l'augmentation de la taille des tables ?

Cordialement.

Citation:

---

Envoyé par bar_79

...[*]Pensez-vous que le partitionnement de ces tables volumineuses sera nécessaire pour éviter les ralentissements qui seront liés à l'augmentation de la taille des tables ?

---

Ptêt ben qu'oui... ou le contraire !
Tout dépend du type de requête que vous faites et de la dispersion des données dans les blocs de la table.
Si vos requêtes sont très ciblées, que vous ramenez seulement une ou quelques lignes à la fois, les index devraient faire leur boulot et rendre inutile le partitionnement.

En revanche, si vous faites des requêtes plus massives, par exemple calcul sur toutes les données d'une société X, les index seront écartés au profit d'un balayage de table intégral
- soit en raison d'une sélectivité insuffisante (on lit 1/7e des données)
- soit en raison d'un mauvais facteur de regroupement, dû au fait que dans les blocs de la table, les différentes sociétés soient mélangées. Ceci dépend de la manière dont les données sont chargées : soit société après société, soit en vrac.
Dans un cas comme dans l'autre, le partitionnement a toutes les chances de vous apporter un bénéfice très net, en évitant de lire inutilement 6/7e des données.