Architecture d'une base oracle - Les erreurs à ne pas faire

[Nicolus]

Bonjour à tous,

Je me suis lancé récemment dans un projet de taille conséquente (à savoir la réalisation d'une application web en Java JEE / Oracle) avec pour objectif de l'intégrer au sein d'un parc informatique professionnel.

Jusqu'à présent j'ai toujours utilisé Oracle sans trop me poser de questions (en allant même jusqu'à me connecter à ma base avec le compte "system") dans le cadre de petits projets réalisés en école.

N'ayant jamais travaillé en milieu professionnel sur une base oracle je fais appel à vos connaissances qui, je l'espère, couplées à quelques recherches sur le web me permettront de mieux comprendre ce SGBD et de pouvoir intégrer mon projet en entreprise.

Mon post sera orienté selon quatre axes:

1. Authentification des utilisateurs
2. Architecture de la base
3. Versions de la base
4. Sécurité

1. Authentification

Je souhaite pouvoir gérer les utilisateurs via une interface d'administration.
En effet n'étant pas raccordé au réseau de l'entreprise je ne peux effectuer de couplage avec l'Active Directory. Je me penche donc sur une authentification via des utilisateurs oracle.

Pour cela je pense créer manuellement (càd en SQL, lors du déploiement de l'application) le compte administrateur. Ensuite, exécuter le script de création de la base avec cet utilisateur. Puis créer les utilisateurs via l'application en leur associant les privilèges systèmes et objets qui leur seront associés.

Que pensez-vous de cette manière de faire ?

2. Architecture de la base

..Seulement voilà, les utilisateurs créés, il faut les faire accéder aux objets ! Et c'est là que je fais face à quelques limites de connaissances.

D'après ce que j'ai compris, lorsque l'on crée un utilisateur on crée également un schéma portant son nom, un ensemble qui contiendrait les objets créés par ce dernier. Moi qui pensait que c'était le rôle du tablespace, me voilà servi !


Mes questions sont donc les suivantes:
- Quelles sont les différences entre un schéma et un tablespace ?
- Finalement, qu'est-ce qu'un tablespace ? Est-ce uniquement une notion physique, et non pas logique ?
- Comment les utilisateurs peuvent-ils accéder au même conteneur d'objets (qui semble être le schéma) ? Peut-on modifier le schéma d'un utilisateur pour le faire pointer vers celui d'un autre, en l'occurence ici le schéma de l'utilisateur ayant créé la base ?
- Faut-il utiliser le tablespace "system" ?

3. Versions de la base

Récemment, j'ai effectué un stage au sein d'une SSII qui utilisait notamment des bases SQL SERVER. J'ai découvert la notion de schémas (et oui, encore eux !) qui étaient utilisés pour versionner les tables des bases, de sorte que pour une table TOTO présente sous plusieurs versions il suffisait de suffixer dans la clause FROM du SQL '[SCHEMA_X].[TOTO]'.

Concrètement on pouvait faire le parrallèle entre un schéma et un utilisateur.

Qu'en est-il sous oracle ?

Émettons que je crée 3 utilisateurs utilisant un même schéma (dans le sens Oracle, cf partie 2). Est-il possible d'avoir au sein de ce schéma plusieurs versions des différentes tables (autrement qu'en modifiant leur nom ?).

4. Sécurité

Un dernier point, après je vous laisse, vous devez déjà en avoir assez.. =)

Le cryptage des mots de passe sous oracle est il fiable ? Est-il réversible ?

A partir de mon application, quelle méthode employer pour envoyer les requêtes de manière cryptée vers la base ? Typiquement, lorsque l'administrateur va créer un utilisateur, je ne voudrais pas que la requête transite en clair sur le réseau avec le MDP.

Je vous avoue que je ne me suis pas beaucoup renseigné sur ce point, peut être que JDBC crypte déjà les requêtes avec les objets "statement".

Voilà, j'en ai terminé, rassurez-vous j'effectue des recherches sur internet mais on trouve parfois vraiment de tout et c'est un point assez critique. Merci d'avance pour vos éclaircissements =)

[fadace]

1) 2 options s'offent à toi : créer les utilisateurs au niveau d'Oracle même OU (c'est ce que font la plupart des ERP) ne travailler qu'avec un seul utilisateur (dont le mot de passe n'est connu d'aucun utilisateur final) Oracle et gérer des utilisateurs applicatifs dans une table à ta sauce.

Oracle n'est pas le plus simple à gérer au niveau des droits et de leur ganularité (droit au niveau de chaque objet OU uniquement sur le schéma propre OU sur toute la base) : j'opterai pour la version 2.

2) Le schéma est en fait un conteneur d'objet logique. Chaque utilisateur propriétaire d'un premier objet devient schéma. Sous Oracle, contrairement à la plupart des autres SGBDR, il n'y a pas de distinction entre schéma et utilisateur...ma foi, c'est une couche d'abstraction qui manque à Oracle.

Un tablespace n'a rien à voir avec la notion de droit ou de schéma : c'est la couche d'abstraction qui gère le stockage. C'est le lien logique qui rattache un objet/segment de base à des fichiers des disques durs. On résume ainsi : une table est rattachée à un tablespace qui, lui, est composé d'un ou plusieurs fichiers sur disque.

Les utilisateurs peuvent accéder aux tables via les droits. Si la connexion se fait avec l'utilisateur-schéma (l'option 2 sous 1.), c'est quasi automatique. Sinon on peut leur donner le droit sur la table via ordre DCL direct (grant select, insert, update, delete on schema1.matable to monUser | monRole), ordre système (grant select any table to public, à déconseiller) ou encore des droits sur des synonymes...

Le tablespace system est dévolu à Oracle. Il faut a tout prix éviter de l'utiliser... et éviter qu'il ne devienne une poubelle. Préférer le tablespace USERS par défaut est mieux, créer un (ou plus) tablespace spécifique pour chaque schéma est préférable.

3) on peut faire de même avec des schémas distincts et un schéma "directeur" ne contenant, par exemple, que des synonymes.

4) C'est du hash, donc irréversible par définition, par contre, il y a d'autres méthodes. Je te laisse avec cet article sur le sujet de la sécurisation. Oracle offre une kyrielle d'options payantes pour plus ou moins crypter le flux réseau, la base, les objets... mais t'as déjà essayé de relire ce qu'il envoie à la base ?

[Nicolus]

Bonsoir,

Merci pour ta réponse

J'ai un peu travaillé le sujet et tu me donnes des informations intéressantes donc c'est parfait

1. Authentification

Je pense me tourner plutôt vers du 100% utilisateurs oracle. Cela m'évitera de devoir mettre en place moi même une solution de cryptage/hash et surtout cela me permettra d'avoir un double contrôle des droits d'accès (côté applicatif et côté base) et donner le minimum de droits possibles (par exemple: SELECT sur une table, INSERT uniquement sur une autre et pas des droits communs à tous les utilisateurs).

J'admets que c'est purement conceptuel puisque l'on peut gérer tout cela côté applicatif, mais je pense que ce n'est pas plus mal..

2.Architecture de la base

En effet, merci pour ces précisions, j'ai effectué quelques recherches entre temps et je pense avoir bien compris

Je m'oriente vers ce scénario:

a. Via le compte system
- Création d'un tablespace

Code :

1
2
3
4
CREATE TABLESPACE nomDuTablespace datafile '.../fichier.dbf'
size                                  50M
autoextend ON maxsize                5000M
extent management LOCAL uniform size  64K;

Que penses-tu des paramètres? Je n'ai aucune prévision concernant la taille de la base, je pense qu'elle sera assez légère (de l'ordre de quelques milliers d'enregistrements toutes tables confondues, quelques dizaines de milliers MAX). L'objectif serait de laisser faire Oracle pour augmenter dynamiquement la taille du fichier.

- Création du compte administrateur:

Code :

1
2
CREATE USER ROOT IDENTIFIED BY "mdp" DEFAULT TABLESPACE nomDuTablespace;
ALTER user ROOT  quota unlimited ON  nomDuTablespace;

- Attribution des privilèges système et objet nécessaires au compte administrateur.

b. Via le compte administrateur créé

- Création d'un utilisateur fictif: la version 1 de la base (la création sera déclenchée manuellement via l'application).
- Création de la base dans le schéma 'version1'
- Création des utilisateurs (idem que pour la création d'une version, déclenchée manuellement) et attribution des privilèges sur les tables créées.

3. Versions

De quelle manière penserais-tu utiliser les synonymes ?

4. Sécurité

Merci pour le lien ! J'irais le consulter le moment venu !
Je n'ai pas encore regardé les flux réseaux, mais je compte bien le faire avec un petit wireshark dès qu'il y aura quelques envois de requêtes !