Discussion :

[gildaram]

Mes salutations cordiales,
depuis un bon moment je réfléchi à comment crypter l'accès du fichier password (ex: PWDtest.ora) et celui des fichiers d'initialisation (Ex: inittest.ora et spfile).
Je ne sais pas si c'est possible. Les seules types de sécurité que je connais sont: le cryptage avec DBMS_CRYPTO (pour les chaines de caractères), et la méthode de cryptage transparent TDE (pour les colonnes et les tablespaces) rien avoir avec le cryptage de fichier que je recherche à mon avis...
Si je m'égare merci de bien vouloir m'éclairer s'il vous plait pasarce que là je m'embrouille un peu.

[star]

Quelle plateforme d'accueil ? version, état technique...
.

[a.presles]

- le fichier password me semble déjas cripté.
Quel est l'interêt de crypter un fichier technique ne contenant aucune données comme le init.ora ou spfile ?

a mon avis toute tentative de cryptage du spfile empéchera la base de l'utiliser.
Sous unix un simple "crypte" du init.ora peu convenir mais oblige a le dérypter avant chaque lancement et n'est pas trés robuste.

[gildaram]

Merci pour vos réponses,
Alors la plateforme est windows xp pack2 et la version 2 de oracle 10g

Je signale que c'est un thème qui a été proposé à un ami et j'aimerais votre avis car pour moi aussi çà semble un peut confus.

En effet le fichier password est déjà crypter (ce qui soulève une ambiguïté) ensuite d'après moi on peut peut être crypter le fichier init car sans ce fichier plus de base de donnée à moins de créer un autre fichier init mais en entreprise un fichier qui peut empêcher une BDD de démarrer constitue une vraie faille de sécurité....

D'où ma question suivante ne serait il pas possible de crypter l'accès à ces fichiers (au lieu de leur contenu) de façon à ce que oracle puisse continuer à les utiliser sans problème??
MErci

[Invité]

Il ne serait pas plus simple de gérer l'accès à ce fichier par le biais des droits et rôles ?

[gildaram]

J'y ai pensé aussi mais en faisant cela est ce que je répond aux attentes du thème??

[star]

La question qu'il faut se poser est plutôt : Qui doit avoir accès à ces fichiers ?
En lecture, écriture, modification, suppression...
Le criptage n'est qu'un aspect de la problématique !

.

[Invité]

J'y ai pensé aussi mais en faisant cela est ce que je répond aux attentes du thème??

Pas vraiment, mais c'est la façon simple et propre de gérer le problème dans le réel...

[gildaram]

Pas vraiment, mais c'est la façon simple et propre de gérer le problème dans le réel...

Je suis d'accord...

La question qu'il faut se poser est plutôt : Qui doit avoir accès à ces fichiers ?
En lecture, écriture, modification, suppression...
Le criptage n'est qu'un aspect de la problématique !

.

Ok!! alors gardons l'utilisateur SYS dans ce cas. Je sais qu'il faut créer un utilisateur autre pour gérer la base de données (question sécurité); mais c'est pour aller vite. Merci

Ne pourrait on pas utiliser le package DBMS_CRYPTO pour aboutir à quelque choses??