Discussion :

[guigui_cwoco]

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 ?!

[orafrance]

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

[guigui_cwoco]

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 ?

[orafrance]

il y a le password (encrypté mais c'est quand même problèmatique) dans DBA_USERS

[guigui_cwoco]

Oui certes ...
Enfin ... Ca se décrypte facilement un mot de passe Oracle ?

[orafrance]

non mais ça peut permettre de se connecter si on a le privilege alter user... évidemment je n'en dirais pas plus

[guigui_cwoco]

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 ?!

[Noren]

J'avais que ca a faire donc ..

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
 
StrligneCommande	VARCHAR2(255);
 
CURSOR CurAllTable IS
	select table_name
	FROM ALL_ALL_TABLES
	where owner  not like '%SYS%';
	;
 
 
BEGIN
 
	FOR R0 IN CurAllTable 
	LOOP
 
	 StrLigneCommande := 'GRANT SELECT ON'|| R0.TABLE_NAME ||' TO APPS_READ';
  	 EXECUTE IMMEDIATE   StrLigneCommande ;
 
 
    END LOOP;
 
END;

Pas testé, ca devrai marcher si t'as pas de users qui contiennent 'SYS' dans leur nom ^^

Tu me payera un totem à la pirogue.

[lapincretin]

Un petit UP ici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
create user apps_read identified by manager account unlock;
 
grant create session to APPS_READ;
 
REM select 'grant ' || privilege || ' on ' || owner || '.' || table_name || ' to ' || 'APPS_READ;'
REM from dba_tab_privs
REM where grantee = 'APPS'
REM and privilege = 'SELECT'
REM and not owner = 'SYS'
REM ad not owner = 'SYSTEM'
REM and not owner = 'CTXSYS'
REM order by owner, table_name, privilege;