|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre habitué
![]() Inscription : janvier 2005 Messages : 129 ![]() |
Bonjour,
Sur un serveur E-Business Suite 11i, j'aimerai faire une petite modification. Mon équipe se décompose de la manière suivante : Je m'occupe de l'administration système (technique) et de la base de données. Mes collegues s'occupent de tout ce qui est fonctionnel/applicatif dans les modules d'Oracle Applications. Bien souvent, le support Oracle nous demande de leur fournir des extractions SQL de données de la base pour résoudre certains bugs. Jusqu'ici mes collegues viennent me voir et me demande de leur extraire les données. Il n'ont pas les moyens de faire du SQL, et n'en n'ont pas les connaissances. C'est une situation voulue, seulement moi et mon chef sommes capables de modifier directement les données dans la base. Cependant, ces extractions pour moi sont sans intérets, me dérangent un peu. J'estime qu'il est temps pour mes collegues de se mettre au SQL et de faire eux meme leurs extractions SQL (SELECT seulement). J'aimerai donc leur donner un outil et les acces minimum (PRINCIPE OF LEAST PRIVILEGES) pour qu'ils se débrouillent seuls. Sous la E-Business suite, les applications ansi que les extractions se font en se connectant a la base via l'utilisateur APPS. C'est un utilisateur qui possede pas mal de vue sur les autres objets de la base. 9 cas sur 10, les SELECT a faire sont des objets du schéma APPS. Afin de confier donc ces responsabilités aux utilisateurs, je pense qu'il faut créer un autre utilisateur de base, sous lequel, mes collegues se connecterons via SQL Developer. J'attribuerai les privileges CREATE SESSION et SELECT ANY TABLE. Je pense que c'est la meilleure solution. Qu'en pensez vous ?! |
|
|
00
|
|
|
#2 |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
SELECT ANY TABLE constitue une faille de sécurité majeur. L'idéal c'est donc de créer un user APPS_READ avec le role CONNECT et sous APPS fait un GRANT SELECT TO APPS_READ pour chaque tables qui ne sont pas dans les shémas SYS et SYSTEM.
En PL/SQL, une boucle FOR et un EXECUTE IMMEDIATE te permettront de faire ça facilement |
|
|
00
|
|
|
#3 |
|
Membre habitué
![]() Inscription : janvier 2005 Messages : 129 ![]() |
En quoi SELECT ANY TABLE constitue une faille de sécurité majeure ?
L'utilisateur ne peux que consulter les tables ... dans tous les schémas certes mais ... Peux tu m'en dires plus ? |
|
|
00
|
|
|
#4 |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
il y a le password (encrypté mais c'est quand même problèmatique) dans DBA_USERS
|
|
|
00
|
|
|
#5 |
|
Membre habitué
![]() Inscription : janvier 2005 Messages : 129 ![]() |
Oui certes ...
Enfin ... Ca se décrypte facilement un mot de passe Oracle ? |
|
|
00
|
|
|
#6 |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
non mais ça peut permettre de se connecter si on a le privilege alter user... évidemment je n'en dirais pas plus
|
|
|
00
|
|
|
#7 |
|
Membre habitué
![]() Inscription : janvier 2005 Messages : 129 ![]() |
Voui évidemment avec le privilege ALTER USER, c'est pas tres malin ...
Dans notre cas, l'utilisateur APPS_READ n'a que 2 privileges : CREATE SESSION (pour se connecter, ca peut aider SELECT ANY TABLE (pour pouvoir intérroger la base) D'autres avis ?! |
|
|
00
|
|
|
#8 | ||
|
Invité de passage
![]() Inscription : mai 2003 Messages : 7 ![]() |
J'avais que ca a faire donc ..
Code :
Tu me payera un totem à la pirogue. |
||
|
|
00
|
|
|
#9 | ||
|
Nouveau Membre du Club
![]() Inscription : juin 2007 Messages : 52 ![]() |
Un petit UP ici :
Code :
|
||
|
|
00
|
Copyright © 2000-2012 - www.developpez.com