(Draft) Dba - Module 5 (2003-08-06) 2 - 0

Module n5
GESTION DES UTILISATEURS

1Z0-001
Auteur : Arnaud Bontemps

Version 1.3 7 aot 2003 Nombre de pages : 29
Ecole Suprieure dInformatique de Paris 23. rue Chteau Landon 75010 PARIS
www.supinfo.com
Gestion des utilisateurs
2 / 29
Table des matires

1. ADMINISTRATION DES UTILISATEURS ................................................................................................. 4 1.1. CREATION D'UN UTILISATEUR ....................................................................................................................... 4 1.1.1. Utilisateurs; Scurit du domaine......................................................................................................... 4 1.1.2. Cration d'un utilisateur : Checklist ..................................................................................................... 4 1.1.3. Cration d'un utilisateur : Serveur d'authentification........................................................................... 5 1.1.4. Cration d'un utilisateur : Authentification Os ..................................................................................... 5 1.1.5. Cration d'un utilisateur : Conseils ...................................................................................................... 5 1.2. GESTION DES UTILISATEURS.......................................................................................................................... 6 1.2.1. Gestion des mots de passe..................................................................................................................... 6 1.2.2. Compte bloqu ...................................................................................................................................... 6 1.2.3. Modification du quota d'un utilisateur .................................................................................................. 6 1.2.4. Suppression d'un utilisateur .................................................................................................................. 6 1.3. MONITORING DES UTILISATEURS................................................................................................................... 7 1.3.1. Affichage des quotas utilisateurs........................................................................................................... 7 1.3.2. Affichage du statut des comptes utilisateurs ......................................................................................... 7 2. ADMINISTRATION DES RESSOURCES ET DE LA SECURITE DES MOTS DE PASSE................... 8 2.1. ADMINISTRATIONS DES PROFILS.................................................................................................................... 8 2.1.1. Utilisation des profils............................................................................................................................ 8 2.1.2. Cration de profils ................................................................................................................................ 8 2.1.3. Assignation d'un profil un utilisateur................................................................................................. 9 2.2. ADMINISTRATION DES PROFILS ..................................................................................................................... 9 2.2.1. Modification d'un profil ........................................................................................................................ 9 2.2.2. Suppression d'un profil.......................................................................................................................... 9 2.2.3. Affichage des limitations de ressources ................................................................................................ 9 2.3. ADMINISTRATION DES MOTS DE PASSE ........................................................................................................ 10 2.3.1. Gestion des mots de passe................................................................................................................... 10 2.3.2. Cration de profil: Gestion des mots de passe.................................................................................... 11 2.3.3. Dfinition d'une fonction de gestion des mots de passe ...................................................................... 11 2.3.4. Afficher les informations sur les profils et les utilisateurs .................................................................. 11 3. CONSOMMATION DE RESSOURCES UTILISATEURS........................................................................ 12 3.1. CONTROLE DES RESSOURCES....................................................................................................................... 12 3.1.1. Limitations de ressources grce aux profils........................................................................................ 12 3.1.2. Activer les limitations de ressources ................................................................................................... 12 3.1.3. Afficher les limitations de ressources.................................................................................................. 13 3.1.4. Forcer l'utilisation des limitations de ressources ............................................................................... 13 3.2. UTILISATION DU GESTIONNAIRE DE RESSOURCES ........................................................................................ 13 3.2.1. Mise en place du gestionnaire de ressources ...................................................................................... 13 4. GESTION DES PRIVILEGES....................................................................................................................... 16 4.1. PRIVILEGES : INTRODUCTION ...................................................................................................................... 16 4.1.1. Privilges : Types................................................................................................................................ 16 4.1.2. Privilges systme ............................................................................................................................... 16 4.2. GESTION DES PRIVILEGES SYSTEME ............................................................................................................ 17 4.2.1. Accorder des privilges systme.......................................................................................................... 17 4.2.2. Les privilges SYSDBA et SYSOPER .................................................................................................. 17 4.2.3. L'authentification grce au fichier de mots de passe .......................................................................... 18 4.2.4. Mcanisme de protection du dictionnaire de donnes ........................................................................ 18 4.2.5. Retrait de privilges systme............................................................................................................... 19 4.2.6. Retrait de privilges : WITH ADMIN OPTION .................................................................................. 19 4.3. GESTION DES PRIVILEGES OBJET ................................................................................................................. 19 4.3.1. Accorder des privilges objet.............................................................................................................. 19 4.3.2. Retrait de privilges objet ................................................................................................................... 20 4.3.3. Retrait de privilges : GRANT OPTION............................................................................................. 20 http://www.labo-oracle.com Ce document est la proprit de Supinfo et est soumis aux rgles de droits dauteurs
3 / 29
4.4. MONITORING DES PRIVILEGES ..................................................................................................................... 20 4.4.1. Affichage des privilges systme ......................................................................................................... 20 4.4.2. Affichage des privilges objet ............................................................................................................. 20 5. GESTION DES ROLES.................................................................................................................................. 21 5.1. ROLES : INTRODUCTION .............................................................................................................................. 21 5.1.1. Caractristiques des rles................................................................................................................... 21 5.1.2. Bnfices des rles .............................................................................................................................. 21 5.2. IMPLEMENTATION DES ROLES ..................................................................................................................... 21 5.2.1. Cration d'un rle ............................................................................................................................... 21 5.2.2. Identification des rles prdfinis ....................................................................................................... 21 5.2.3. Modifier un rle .................................................................................................................................. 22 5.2.4. Assignation d'un rle un utilisateur ................................................................................................. 22 5.3. CONTROLER LES ROLES .............................................................................................................................. 22 5.3.1. Limitation du rle par dfaut .............................................................................................................. 22 5.3.2. Activation d'un rle ............................................................................................................................. 23 5.3.3. Retrait d'un rle un utilisateur ......................................................................................................... 23 5.3.4. Suppression d'un rle.......................................................................................................................... 23 5.4. ROLES : INFORMATIONS ET CONSEILS ......................................................................................................... 23 5.4.1. Conseils pour la cration de rles ...................................................................................................... 23 5.4.2. Affichage des infos concernant les rles ............................................................................................. 23 5.4.3. Affichage des rles et privilges actifs ................................................................................................ 23 6. AUDIT .............................................................................................................................................................. 25 6.1. UTILISATION DE L'AUDIT DE BASE DE DONNEES .......................................................................................... 25 6.1.1. Catgories d'audit ............................................................................................................................... 25 6.1.2. Audit de base de donnes: Phases....................................................................................................... 25 6.1.3. Valeur du paramtre AUDIT_TRAIL .................................................................................................. 25 6.1.4. Requte d'audit.................................................................................................................................... 26 6.1.5. Privilges d'audit ................................................................................................................................ 26 6.1.6. Audit des objets de base de donnes ................................................................................................... 27 6.1.7. Dsactiver les options d'audit ............................................................................................................. 27 6.2. AFFICHAGE DES RESULTATS D'AUDIT .......................................................................................................... 28 6.2.1. Vues concernant les options d'audit.................................................................................................... 28 6.2.2. Afficher les rsultats d'audit................................................................................................................ 28 6.3. VERIFICATION DE LA VALIDITE DE L'AUDIT ................................................................................................. 28 6.3.1. Conseils pour l'audit ........................................................................................................................... 28 6.3.2. Dplacer la table d'audit..................................................................................................................... 28
http://www.labo-oracle.com Ce document est la proprit de Supinfo et est soumis aux rgles de droits dauteurs
4 / 29
1. Administration des utilisateurs

1.1.Cration d'un utilisateur
1.1.1. Utilisateurs; Scurit du domaine
La scurit est une part intgrante de ladministration de la base de donnes. En tant quadministrateur, vous serez responsable de la scurit de la base de donnes. Vous pourrez effectuer ceci en dfinissant la scurit du domaine pour chaque utilisateur. Chaque composant de la scurit du domaine possde des fonctions distinctes. Le premier composant est le mcanisme dauthentification qui dfinit les diffrents privilges dun utilisateur. Un utilisateur pourra tre authentifi par le serveur Oracle ou bien par le systme dexploitation. Le mcanisme dauthentification est spcifi lors de la cration de lutilisateur et pourra tre modifi par la suite. Le second composant est le verrouillage des comptes. Les comptes utilisateurs peuvent tre verrouills afin dempcher un ou plusieurs utilisateurs de se connecter la base de donnes. Ce verrouillage pourra se faire de manire automatique aprs un certain nombre dchecs lors de lauthentification ou bien ladministrateur pourra verrouiller ou dverrouiller le compte manuellement. Le troisime composant est le tablespace par dfaut. Il spcifie dans quel tablespace les objets de lutilisateur seront stocks si celui-ci ne spcifie pas de manire explicite un tablespace lors de la cration de nouveaux objets. Si aucun tablespace par dfaut nest spcifi lors de la cration de lutilisateur, Oracle lui assignera automatiquement le tablespace SYSTEM. Le quatrime composant est le tablespace temporaire. Celui-ci est dfini par un nombre dextents qui seront allous par le serveur afin dcrire des donnes temporaires comme des donnes de tri. Si ce tablespace nest pas dfini lors de la cration de lutilisateur, Oracle lui assignera automatiquement le tablespace SYSTEM. Le cinquime composant est les quotas pour les tablespaces. Ces quotas permettront de grer la quantit despace disque alloue un utilisateur dans les tablespaces. Le sixime composant correspond aux limitations de ressources, qui permettent de contrler lutilisation des ressources systme. Ces ressources incluent le temps CPU, le nombre de connexions pour un utilisateur ainsi que le nombre dentres-sorties sur le disque. Le septime composant est reprsent par les privilges systme et les privilges objets qui permettent de contrler les accs aux donnes pour chaque utilisateur. Ces privilges permettent de dfinir les diffrentes actions que les utilisateurs pourront effectuer sur les donnes. Le huitime et dernier composant est reprsent par les rles qui permettent de contrler les actions d'un utilisateur comme faisant parti d'un ensemble d'utilisateur. Les rles peuvent tre assimils aux groupes d'utilisateurs sous Windows NT.
1.1.2. Cration d'un utilisateur : Checklist

Vous pouvez contrler l'accs une base de donnes en crant, modifiant, supprimant et en surveillant des utilisateurs. Nous allons voir les diffrentes tapes de la cration d'un utilisateur. La premire tape consiste choisir un nom d'utilisateur et un mode d'authentification. Ces informations sont ncessaires afin de crer le schma du nouvel utilisateur. Lorsqu'un utilisateur est cr, un schma portant le mme nom est lui aussi cr pour l'utilisateur. Un schma est un espace qui va contenir tous les objets de l'utilisateur comme des tables, des vues, des triggers, des procdures, des index. Un utilisateur ne peut tre associ qu' un seul schma (portant le mme nom). Quand un utilisateur se connectera, il aura alors accs tous les objets du schma correspondant.
5 / 29
La seconde tape consiste choisir les tablespaces qui serviront stocker les objets de son schma. Il faudra ensuite choisir le quota d'espace disponible pour cet utilisateur sur ses diffrents tablespaces. Par dfaut, le quota est de zro octets pour chaque tablespace. Le quota correspond l'espace disponible maximum pour les objets d'un utilisateur sur un tablespace. Il faut ensuite assigner un tablespace par dfaut et un tablespace temporaire ce nouvel utilisateur. La troisime tape consiste excuter la commande CREATE USER qui va permettre de crer de manire proprement dite l'utilisateur. Il faudra ensuite lui assigner des privilges ainsi que des rles en fonction des diffrentes actions que pourra effectuer ce nouvel utilisateur. La dernire tape consiste former ce nouvel utilisateur pour qu'il puisse se connecter la base de donnes et lui expliquer comment changer son mot de passe.
1.1.3. Cration d'un utilisateur : Serveur d'authentification

Il existe deux situations distinctes pour crer un utilisateur : - Vous crez un utilisateur quand cet utilisateur doit se connecter une base de donnes et accder ses objets. - Vous crez un utilisateur quand un utilisateur existant veut se connecter une autre base de donnes. Dans ce cas, vous pourrez alors avoir deux ou trois comptes pour un mme utilisateur. Voici la syntaxe de la commande pour crer un utilisateur.
CREATE USER user IDENTIFIED {BY password | EXTERNALLY} [DEFAULT TABLESPACE default_tablspace_name] [TEMPORARY TABLESPACE temporary_tablespace_name] [QUOTA {integer [K | M] | UNLIMITED } ON tablespace_name ] [PASSWORD EXPIRED] [ACCOUNT {LOCK | UNLOCK}] [PROFILE {profile_name | DEFAULT}];
1.1.4. Cration d'un utilisateur : Authentification Os

La mthode d'authentification est un choix obligatoire lors du processus de cration d'un utilisateur. Dans cette partie, nous allons voir comment doit faire un DBA pour tre sur que l'utilisateur sera authentifi par le systme d'exploitation. Quand vous utilisez l'authentification du systme d'exploitation, le serveur Oracle conserve le compte utilisateur bien que ce soit le systme d'exploitation qui authentifie l'utilisateur. La premire tape consiste utiliser les mots cls IDENTIFIED EXTERNALLY dans la commande CREATE USER et initialiser le paramtre OS_AUTHENT_PREFIX qui est utilis pour spcifier le format des noms d'utilisateur. Le serveur rajoutera le OS_AUTHENT_PREFIX au nom d'utilisateur du systme d'exploitation. Il comparera ensuite cet utilisateur avec un utilisateur de la base de donnes. (La valeur par dfaut du paramtre OS_AUTHENT_PREFIX est OPS$.) Il vous faudra aussi initialiser le paramtre REMOTE_OS_AUTHENT qui permet de dfinir si l'utilisateur est authentifi par le serveur Oracle (REMOTE_OS_AUTHENT=FALSE) ou par le systme d'exploitation (REMOTE_OS_AUTHENT=TRUE).
1.1.5. Cration d'un utilisateur : Conseils

Il est prfrable de choisir un mot de passe standard que l'utilisateur sera plus mme de se souvenir et de changer par la suite.

-
6 / 29
Il est prfrable d'utiliser l'authentification du systme d'exploitation (mais ce choix reste discutable). Il peut tre intressant d'utiliser l'option EXPIRE lors de la cration de l'utilisateur ce qui forcera l'utilisateur changer son mot de passe lors de sa premire connexion. Il est ncessaire de spcifier les tablespaces temporaire et par dfaut pour tous les utilisateurs afin d'viter que le tablespace SYSTEM soit mi par dfaut et ne se fragmente trop rapidement. Il peut tre judicieux d'utiliser des quotas car des quotas illimits peuvent crer des problmes d'espace. De plus, les utilisateurs ne ncessitent aucuns quotas sur les tablespaces temporaires ou sur les tablespaces de rollback.
1.2.Gestion des utilisateurs

1.2.1. Gestion des mots de passe
Lors de la cration d'un utilisateur, le DBA assigne un mot de passe l'utilisateur. Ce mot de passe peut tre modifi par l'utilisateur ou bien par le DBA. Le DBA peut quant lui forcer l'expiration du mot de passe. Voici la syntaxe SQL pour changer de mot de passe:
ALTER USER user_name [IDENTIFIED { BY password | EXTERNALLY }] [PASSWORD EXPIRE];
Le changement de mot de passe ne sera effectif que pour les sessions suivantes et non pas pour celles en cours.
1.2.2. Compte bloqu

Il peut parfois tre ncessaire de bloquer temporairement un compte utilisateur. Pour rendre indisponible un compte, le DBA va bloquer ce compte. Voici la syntaxe pour bloquer ou non un compte utilisateur :
ALTER USER user_name [ACCOUNT { LOCK | UNLOCK}];
1.2.3. Modification du quota d'un utilisateur

Voici la syntaxe SQL pour modifier le quota d'un utilisateur sur un tablespace :
ALTER USER user_name [DEFAULT TABLESPACE default_tablespace_name] [TEMPORARY TABLESPACE temporary_tablespace_name] [QUOTA { integer [K | M] | UNLIMITED} ON tablespace_name];
1.2.4. Suppression d'un utilisateur

Il faut, pour pouvoir supprimer un utilisateur, que celui soit dconnect. Voici la syntaxe SQL pour supprimer un utilisateur :
DROP USER user_name [ CASCADE ];
Si l'option CASCADE est utilise alors tous les objets de l'utilisateur seront d'abord supprims avant de supprimer l'utilisateur. Si l'option CASCADE n'est pas utilise alors que le schma de l'utilisateur contient encore des objets, une erreur se produira lors de la suppression de l'utilisateur.
7 / 29
1.3.Monitoring des utilisateurs

1.3.1. Affichage des quotas utilisateurs
C'est grce la vue DBA_TS_QUOTAS que l'on pourra trouver toutes les informations sur les quotas des diffrents utilisateurs.
1.3.2. Affichage du statut des comptes utilisateurs

Vous pourrez avoir toutes les informations concernant un utilisateur grce la vue DBA_USERS. Cette vue va vous permettre d'obtenir des informations concernant les utilisateurs. Voici quelques informations intressantes : USERNAME : nom de l'utilisateur. USER_ID : Id de l'utilisateur. PASSWORD : Mots de passe de l'utilisateur (encrypt pour des raisons de scurit). CREATED : Date de cration de l'utilisateur. ACCOUNT_STATUS : Statut du compte (actif ou autre.). LOCK_DATE : Date laquelle le compte a t bloqu. EXPIRY_DATE : Date d'expiration du compte. DEFAULT_TABLESPACE : Tablespace par dfaut du compte. PROFILE : Profil du compte. EXTERNAL_NAME : Nom externe de l'utilisateur.
8 / 29
2. Administration des ressources et de la scurit des mots de passe

2.1.Administrations des profils
2.1.1. Utilisation des profils
Un profil est un ensemble nomm de limitations sur les ressources systmes, pouvant tre protg d'un mot de passe, et servant optimiser les ressources et augmenter la scurit de la base de donnes. Voici les diffrentes ressources contrles par un profil : CPU Time I/O Opration Idle Time Connect Time Memory Space Concurrent Sessions Password aging and expiration Password History Password Complexity Verification Account Locking
Le DBA devra assigner un profil chaque utilisateur. Si aucun profil n'est dfini par dfaut, l'utilisateur se verra assigner le profil par dfaut DEFAULT, qui est automatiquement cre lors de la cration de la base. Le profil par dfaut ne comporte initialement aucunes limitations mais pourra ensuite tre modifi par le DBA. Les profils peuvent tre d'un grand intrt lorsque l'on souhaite restreindre les oprations qui vont ncessiter trop de ressources systme. Les profils permettent aussi de vrifier que l'utilisateur sera bien dconnect de la base si sa session reste inactive un certain moment. Ils peuvent aussi permettrent de regrouper les diverses utilisations de ressources systmes et permettent finalement de grer les mots de passe.
2.1.2. Cration de profils

Pour crer un profil, vous devrez tout d'abord identifier les ressources qui devront tre limites par chaque profil. Vous devrez aussi savoir quelles seront ces limites. Pour vous aidez dans votre choix, vous pourrez utiliser les donnes historiques de la base ou bien les fichiers de trace utilisateur ou finalement en auditant la base de donnes afin d'avoir des donnes plus prcises. Voici la syntaxe qui va vous permettre de cre un profil :
CREATE PROFILE profile LIMIT [SESSIONS_PER_USER {integer | UNLIMITED | DEFAULT}] [CPU_PER_SESSION {integer | UNLIMITED | DEFAULT}] [CPU_PER_CALL {integer | UNLIMITED | DEFAULT}] [CONNECT_TIME {integer | UNLIMITED | DEFAULT}] [IDLE_TIME {integer | UNLIMITED | DEFAULT}] [LOGICAL_READS_PER_SESSION {integer | UNLIMITED | DEFAULT}] [LOGICAL_READS_PER_CALL {integer | UNLIMITED | DEFAULT}] [COMPOSITE_LIMIT {integer | UNLIMITED | DEFAULT}] [PRIVATE_SGA {integer | UNLIMITED | DEFAULT}] [FAILED_LOGIN_ATTEMPTS {integer | UNLIMITED | DEFAULT}] [PASSWORD_LIFE_TIME {integer | UNLIMITED | DEFAULT}] [PASSWORD_REUSE_TIME | PASSWORD_REUSE_MAX {integer | UNLIMITED | DEFAULT}] [PASSWORD_LOCK_TIME {integer | UNLIMITED | DEFAULT}] [PASSWORD_GRACE_TIME {integer | UNLIMITED | DEFAULT}]

[PASSWORD_VERIFY_FUNCTION {function | NULL | DEFAULT}];
9 / 29
Lorsque vous crez un profil vous n'tes pas oblig de spcifier tous les paramtres. Tous les paramtres qui n'auront pas t spcifis se verront automatiquement assigner la valeur par dfaut.
2.1.3. Assignation d'un profil un utilisateur

Les profils ne peuvent tre assigns qu' des utilisateurs. Et chaque utilisateur ne peut avoir qu'un seul profil. Les utilisateurs peuvent, soit avoir le profil DEFAULT, soit celui assign par le DBA. L'assignation d'un profil ne mettra pas en place les limitations de ressources sur la session courante d'un utilisateur. Pour assigner un profil un utilisateur lors de sa cration, vous devrez utiliser le mot cl PROFILE. Vous pourrez aussi assigner un nouveau profil aprs la cration de l'utilisateur avec la syntaxe suivante:
ALTER USER user PROFILE profile;
2.2.Administration des profils

2.2.1. Modification d'un profil
Vous pouvez aussi modifier un profil mais celui-ci ne sera valable pour l'utilisateur que lors de sa prochaine ouverture de session. Voici la syntaxe qui permet de modifier un profil :
ALTER PROFILE profile LIMIT [SESSIONS_PER_USER {integer | UNLIMITED | DEFAULT}] [CPU_PER_SESSION {integer | UNLIMITED | DEFAULT}] [CPU_PER_CALL {integer | UNLIMITED | DEFAULT}] [CONNECT_TIME {integer | UNLIMITED | DEFAULT}] [IDLE_TIME {integer | UNLIMITED | DEFAULT}] [LOGICAL_READS_PER_SESSION {integer | UNLIMITED | DEFAULT}] [LOGICAL_READS_PER_CALL {integer | UNLIMITED | DEFAULT}] [COMPOSITE_LIMIT {integer | UNLIMITED | DEFAULT}] [PRIVATE_SGA {integer | UNLIMITED | DEFAULT}] [FAILED_LOGIN_ATTEMPTS {integer | UNLIMITED | DEFAULT}] [PASSWORD_LIFE_TIME {integer | UNLIMITED | DEFAULT}] [PASSWORD_REUSE_TIME | PASSWORD_REUSE_MAX {integer | UNLIMITED | DEFAULT}] [PASSWORD_LOCK_TIME {integer | UNLIMITED | DEFAULT}] [PASSWORD_GRACE_TIME {integer | UNLIMITED | DEFAULT}] [PASSWORD_VERIFY_FUNCTION {function | NULL | DEFAULT}];
2.2.2. Suppression d'un profil

Voici la syntaxe qui permet de supprimer un profil :
DROP PROFILE profile [CASCADE];
L'option CASCADE permet de rassigner le profil DEFAULT aux utilisateurs dont le profil vient d'tre supprim.
2.2.3. Affichage des limitations de ressources

Pour avoir des informations sur les limitations de ressources, vous pouvez consulter les vues systmes suivantes : DBA_USERS et DBA_PROFILES.
10 / 29
2.3.Administration des mots de passe

2.3.1. Gestion des mots de passe
Pour augmenter le contrle de la scurit, les profils permettent de grer, avec certaines fonctionnalits, les mots de passe des utilisateurs. La gestion des mots de passe grce aux profils va permettre de grer le blocage des comptes, le renouvellement et l'expiration des mots de passe, un historique des mots de passe et finalement permettre de grer la complexit des mots de passe. Le blocage d'un compte utilisateur : Cette fonctionnalit va permettre de bloquer automatiquement un compte lorsqu'un utilisateur se sera tromp de mots de passe un certain nombre de fois. Les paramtres qui permettent de grer cette fonctionnalit sont : FAILED_LOGIN_ATTEMPTS et PASSWORD_LOCK_TIME Le renouvellement et l'expiration d'un compte utilisateur : Cette fonctionnalit va permettre de dterminer la dure de vie du mot de passe. C'est la fin de cette dure de vie qu'il faudra renouveler son mot de passe. Les paramtres qui permettent de grer cette fonctionnalit sont : PASSWORD_LIFE_TIME et PASSWORD_GRACE_TIME. Si cet utilisateur se retrouvait avec son compte bloqu, voici la syntaxe qui vous permettrait de dverrouiller son compte.
ALTER USER <nom du user> [ IDENTIFIED { BY <mot de passe> | EXTERNALLY } ] [ PASSWORD EXPIRE ] [ ACCOUNT { LOCK | UNLOCK } ];
Dont voici un exemple d'utilisation

ALTER USER toto IDENTIFIED BY tata ACCOUNT UNLOCK;
Cet exemple va permettre de dverrouiller le compte de toto en lui assignant tata comme nouveau mot de passe. L'historique des mots de passe : Cette fonctionnalit va permettre de comparer le nouveau mot de passe aux anciens mots de passe de l'utilisateur afin d'tre sur qu'il ne puisse pas rutiliser un ancien mot de passe pendant un certain nombre de fois ou pendant un certain temps. Les paramtres qui permettent de grer cette fonctionnalit sont : PASSWORD_REUSE_TIME et PASSWORD_REUSE_MAX. La vrification de la complexit des mots de passe : Cette fonctionnalit va permettre de vrifier la complexit du mot de passe afin d'viter toutes possibilits de piratage. Le paramtre qui permet de grer cette fonctionnalit est : PASSWORD_VERIFY_FUNCTION. Cette fonction devra tre cre dans le schma de SYS et devra avoir le prototype suivant :
<nom de la fonction> ( <id du user (nom du paramtre)> IN VARCHAR2(30), <password du user(nom du paramtre) IN VARCHAR2(30), <ancien password(nom du paramtre)>IN VARCHAR2(30)) RETURN BOOLEAN
11 / 29
Si le mot de passe convient, la fonction devra retourner la valeur TRUE et FALSE si le mot de passe ne convient pas. Il est possible d'utiliser la fonction qui vous est fournie par Oracle dans le fichier utlpwdmg.sql qui devra tre excute dans le schma SYS.
2.3.2. Cration de profil: Gestion des mots de passe

Voici les deux tapes qui vont permettre au DBA de pouvoir administrer les mots de passe des utilisateurs: - Cration d'un profil avec les options concernant les mots de passe et l'assigner ensuite aux utilisateurs. - Blocage, dblocage, expiration des mots de passe avec les commandes CREATE USER ET ALTER USER. Les options sur les mots de passe sont toujours actives mme si le paramtre RESOURCE_LIMIT du fichier init.ora est FALSE.
2.3.3. Dfinition d'une fonction de gestion des mots de passe

Pour vrifier la complexit d'un mot de passe, il est possible grce aux profils de passer une fonction PL/SQL qui va permettre de vrifier la complexit du mot de passe. De plus il est possible de crer soit mme cette fonction en respectant certaines restrictions. Pour utiliser la fonction par dfaut fournie par Oracle il faudra lancer le script utlpwdmg.sql.
2.3.4. Afficher les informations sur les profils et les utilisateurs

Le dictionnaire de donnes contient un grand nombre d'informations utiles sur les mots de passes et les comptes utilisateurs. Pour obtenir ces informations vous pouvez consulter les vues DBA_USERS et DBA_PROFILES.
12 / 29
3. Consommation de ressources utilisateurs

3.1.Contrle des ressources
3.1.1. Limitations de ressources grce aux profils
Les profils vous permettent d'appliquer des limitations de ressources aux utilisateurs. A chaque fois qu'un utilisateur se connecte une session est alors cre. Chaque session est consommatrice de ressources mmoire et processeur. Les restrictions lies la session seront donc appliques aux ressources utilises durant la session. Les profils permettent non seulement de grer les ressources au niveau de la session mais aussi au niveau des appels de requtes ou autres appels systme. Les limitations au niveau de la session sont les restrictions sur ressources lors de la dure de la session (par exemple, un utilisateur laisse sa session inactive, vous pouvez limiter le temps dinactivit dune session). Les limitations au niveau des appels sont les restrictions qui seront appliques lors de chaque appel systme. Voila comment vont se drouler les tapes lors du dpassement d'une limite au niveau des appels systme. Si une limite au niveau instruction est dpasse : Le processus traitant l'instruction SQL sera alors stopp et l'instruction courante sera alors annule. Un message d'erreur est ensuite affich l'utilisateur. Toutes les transactions prcdentes restent valide et l'utilisateur reste connect. Si une limite au niveau session est dpasse : Un message d'erreur est envoy l'utilisateur qui est ensuite dconnect automatiquement.
3.1.2. Activer les limitations de ressources

Il existe trois tapes ncessaires pour mettre en place la gestion des ressources par les profils : - Crer un profil. - Assigner ce profil aux utilisateurs - Mettre en place les limitations de ressources. Par dfaut, les rgles de gestion des ressources sont inactives. Il existe deux moyens de mettre en place ces rgles de gestion : - En modifiant le paramtre RESOURCE_LIMIT (TRUE ou FALSE) du fichier init.ora. Cette mthode nest seulement possible que lorsque vous pouvez arrter la base. - En modifiant le paramtre RESOURCE_LIMIT grce la commande ALTER SYSTEM. Cette mthode permet de modifier de manire dynamique le paramtre mais ne permettra pas de garder la valeur de ce paramtre si la base de donne est redmarre et que vous n'avez pas modifi le fichier init.ora.
ALTER SYSTEM SET RESOURCE_LIMIT = TRUE ;
13 / 29
Il est aussi possible de modifier ce paramtre grce Oracle Entreprise Manager et en allant dans Oracle Instance Manager.
3.1.3. Afficher les limitations de ressources

Il existe deux vues systme qui permettent dobtenir des informations sur les limitations de ressources. La premire vue est DBA_USERS. Grce cette vue vous pourrez savoir quel profil a t attribu chaque utilisateurs grce la colonne PROFILE. La deuxime vue est DBA_PROFILES. Grce cette vue vous pourrez savoir toutes les limitations qui ont t mises en place pour un profil donn.
3.1.4. Forcer l'utilisation des limitations de ressources

Nous allons maintenant voir quelques exemples de limitations. Limitations au niveau de la session : - CPU_PER_SESSION : Limite le temps dutilisation du processeur pour une session. Le temps devra tre saisi en 100me de secondes. - SESSION_PER_USER : Limite le nombre de sessions concurrentes pour un utilisateur. - CONNECT_TIME : Limite le temps de connexion pour une session. Le temps devra tre saisi en minutes. - IDLE_TIME : Limite le temps dinactivit dune session. Le temps devra tre saisi en minutes. Cette limitation ne concerne que le processus serveur seulement. Elle ne tient pas compte dautres oprations comme les activits dune application tierce. - LOGICAL_READS_PER_SESSION : Limite le nombre total de lectures logique de blocs de donnes durant la session. Cette limitation permet dviter un trop grand nombre dentre/sortie qui monopoliseraient les ressources systme. - PRIVATE_SGA : Limite la mmoire utilise dans la SGA par un utilisateur connect par lintermdiaire dun serveur multi-thread. - COMPOSITE_LIMIT : Limite le cot total en ressource pour une session. Le cot total en ressource correspond la somme des paramtres CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION et PRIVATE_SGA. Pour connatre la valeur de ces diffrents paramtres vous pouvez interroger la vue RESOUCE_COST. Limitations au niveau des appels systme : - CPU_PER_CALL : Limite le temps dutilisation processeur par appel. Le temps devra tre saisi en 100me de secondes. - LOGICAL_READS_PER_CALL : Limite le nombre de lecture de blocs pour chaque appel.
3.2.Utilisation du gestionnaire de ressources

3.2.1. Mise en place du gestionnaire de ressources
La gestion des ressources pourra permettre diffrents types dutilisateurs de pouvoir utiliser aux mieux les ressources disponibles (par exemple les utilisateurs travaillant avec une application de type DSS ou de type OLTP). Le gestionnaire de ressource va vous permettre de dfinir des groupes dutilisateurs et de spcifier les ressources qui pourront leur tre allou. Ces groupes sont appels groupe de consommateur de ressources. Il est possible quun utilisateur fasse parti de plusieurs groupes. La liste des groupes de consommateurs de ressource et leurs allocations de ressources est appele un "Resource Plan". Ces "Resource Plan" sont uniques et sont stocks dans le dictionnaire de donnes. Il
14 / 29
peut exister plusieurs "Resource Plan" mais il ne peut y avoir qu'un seul "Resource Plan" actif la fois. Il existe ensuite des directives de planification de ressource qui permettent de pouvoir assigner aux groupes de consommateur de ressource, les ressources dont ils ont besoin. Pour mettre en place cette gestion des ressources, vous aurez besoin de 2 packages PL/SQL : - DBMS_RESOURCE_MANAGER - DBMS_RESOURCE_MANAGER_PRIVS Avant de pouvoir dfinir ces "Resource Plan" ou tout les autres objets ncessaires la gestion des ressources, il est ncessaire de crer une zone d'attente (ou Pending Area). Cette Pending Area est une zone de travail qui va permettre de crer et de modifier les "Resource Plan". Toutes les modifications seront effectues dans cette zone de travail jusqu' ce qu'elles soient valides. Pour pouvoir cre cette zone, il vous faudra utiliser la procdure CREATE_PENDING_AREA du package DBMS_RESOURCE_MANAGER. Ensuite il faudra dcider du nombre de groupes de consommateurs ncessaires puis les nommer et les crer. Il est tout fait possible d'utiliser les groupes prdfinis comme SYS_GROUP, LOW_GROUP, DEFAULT_CONSUMER_GROUP et OTHER_GROUPS. SYS_GROUP : est attribu pour les utilisateurs SYS et SYSTEM et tant en relation avec le SYSTEM_PLAN. LOW_GROUP : est donn aux utilisateurs ayant une priorit plus faible. Il est aussi en relation avec le SYSTEM_PLAN. DEFAULT_CONSUMER_GROUP : est attribu tous les utilisateurs comme groupe par dfaut jusqu' ce que vous changiez l'utilisateur de groupe de consommateurs de ressources. OTHER_GROUPS : Ce groupe devra tre inclus obligatoirement dans chaque "Resource Plan".
Voici la commande PL/SQL excuter pour crer un groupe de consommateurs:

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP( '<nom du groupe>', '<Description>');
Ensuite une fois le groupe cre, voici la commande PL/SQL qui permet de rajouter un utilisateur un groupe :
DBMS_RESOURCE_MANAGER_PRIVS.CREATE_CONSUMER_GROUP( '<nom du user>', '<nom du groupe>', <option d'administration>);
L'option d'administration (valeur TRUE et FALSE) permet de dfinir si cet utilisateur pourra ou non ajouter d'autres utilisateurs ce groupe. Quand vous crez de nouveaux utilisateurs, ceux-ci sont automatiquement ajouts au groupe DEFAULT_CONSUMER_GROUP jusqu' ce que vous les en changiez. Le groupe initial d'un utilisateur peut tre modifi grce la commande suivante :
DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP ( '<nom du user>',

'<nom du groupe>');
15 / 29
Les utilisateurs faisant partis de plusieurs groupes peuvent changer leur groupe actuel. Ce changement pourra impliquer une seule des sessions de l'utilisateur ou toutes ses sessions. Voici les deux syntaxes : Pour changer de groupe pour toutes les sessions de l'utilisateur :
DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER ( '<nom du user>', '<nom du groupe>');
Pour changer de groupe pour une session particulire :

DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ( <SID de la session>, <SERIAL# de la session>, '<nom du groupe>');
Le gestionnaire de ressource ncessite un ou plusieurs "Resource Plan". Comme vu prcdemment un "Resource Plan" est une liste nomme de groupes de consommateurs de ressources et de spcification sur les ressources associes chaque groupe. Voici la syntaxe qui permet de crer un "Resource Plan" :
DBMS_RESOURCE_MANAGER.CREATE_PLAN ( '<nom du resource plan>', '<description du resource plan>');
Chaque "Resource Plan" doit contenir une directive qui permettra d'tre redirig vers le groupe OTHER_GROUPS. Voici la syntaxe qui permet de crer une directive :
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE ( '<nom du resource plan>', '<nom du groupe de consommateur de ressource>', '<description de la directive>', <limitation de ressource>, []);
Un seul "Resource Plan" ne pouvant tre actif la fois, on dfinira le "Resource Plan" actif grce au paramtre RESOURCE_MANAGER_PLAN du fichier init.ora. On pourra modifier la valeur de ce paramtre soit directement dans le fichier init.ora, soit de manire dynamique avec la syntaxe suivante :
SQL> ALTER SYSTEM SET 2 RESOURCE_MANAGER_PLAN=<nom du plan>;
Pour obtenir toutes les informations relatives tous les objets du gestionnaire de ressource, il suffit d'interroger les vues du dictionnaire de donnes : - DBA_RSRC_PLANS - DBA_RSRC_PLAN_DIRECTIVES - DBA_RSRC_CONSUMER_GROUPS - DBA_RSRC_CONSUMER_GROUPS_PRIVS - DBA_USERS
16 / 29
4. Gestion des privilges

4.1.Privilges : Introduction
4.1.1. Privilges : Types
Les privilges sont une part importante de la scurit d'une base de donnes Oracle. Quand un utilisateur se connecte une base de donnes celui-ci est alors authentifi. Le serveur Oracle effectue cette authentification en vrifiant la validit du nom et du mot de passe de l'utilisateur. Cette authentification constitue la premire tape vers la "scurisation" de la base de donnes. Les autres tapes permettant de scuriser la base de donnes, est de donner des privilges aux utilisateurs. Il existe deux types de privilges: - Les privilges systmes : Ce type de privilge permet d'autoriser l'utilisateur d'effectuer un certain nombre d'oprations dans la base de donnes (comme se connecter ou bien crer modifier ou bien supprimer des objets de la base).Ces privilges ne sont pas spcifiques un objet de schma. - Les privilges objets : Ce type de privilge permet d'autoriser l'utilisateur effectuer des modifications et accder certains objets de la base de donnes comme une table, une vue. Vous pouvez donner des droits sur des objets comme UPDATE ON, DELETE ON, EXECUTE ON, SELECT ON. Attention : Il est dangereux d'attribuer les privilges systme comportant le mot cl ANY, car ceux-ci sont trs puissants et peuvent dans certains cas rendre accessible tout les objets de la base de donnes.
4.1.2. Privilges systme

Nous allons maintenant voir de manire plus spcifique les privilges systmes. Il faut savoir que tout les privilges contenant le mot cl CREATE (tels que CREATE TABLE, CREATE PROCEDURE, etc) incluent aussi les privilges de suppression (tels que DROP TABLE, DROP PROCEDURE, etc) car les objets de la base peuvent toujours tre supprims par leur propritaire. Les utilisateurs possdant le privilge CREATE TABLE ont donc aussi de manire implicite les droits de faire toutes les actions possible sur leur table comme de crer des index (CREATE INDEX mais ce privilge n'existe pas rellement mais il existe un privilge objet INDEX) ou de lancer des analyses statistiques (ANALYSE) sur leurs tables. Les rles sont des groupes nomms qui peuvent contenir un ou plusieurs privilges systmes et tre ainsi donns des utilisateurs ou bien d'autres rles. Attention : Le privilge systme UNLIMITED TABLESPACE ne peut en aucun cas tre donn un rle. Il faut aussi le donner avec prcaution car ce rle donne accs tout l'espace disponible dans tous les tablespaces y compris le tablespace SYSTEM. Voici des exemples de privilges systme :

Catgorie INDEX Exemples CREATE ANY INDEX ALTER ANY INDEX DROP ANY INDEX CREATE TABLE CREATE ANY TABLE ALTER ANY TABLE DROP ANY TABLE SELECT ANY TABLE UPDATE ANY TABLE DELETE ANY TABLE CREATE SESSION ALTER SESSION RESTRICTED SESSION CREATE TABLESPACE ALTER TABLESPACE DROP TABLESPACE UNLIMITED TABLESPACE
17 / 29
TABLE
SESSION
TABLESPACE
4.2.Gestion des privilges systme

4.2.1. Accorder des privilges systme
Un rle est donc un ensemble nomm de privilges qui peut ensuite tre donn des utilisateurs ou bien d'autres rles. Voici la syntaxe qui permet de donner un rle :
GRANT {<nom du privilge> | <nom du rle>} [, {<nom du privilge> | <nom du rle>}] TO {<nom d'un user> | <nom d'un rle> | PUBLIC} [, {<nom d'un user> | <nom d'un rle> | PUBLIC}] [WITH ADMIN OPTION];
Le mot cl PUBLIC permet de donner un privilge systme ou un rle l'ensemble des utilisateurs. Les mots cl WITH ADMIN OPTION permettent d'autoriser la personne ayant reu ce rle de le donner lui-mme d'autres utilisateurs ou rles. Il y a quelques points savoir, dans l'environnement Oracle, pour donner un privilge systme ou un rle : - Pour pouvoir donner un privilge systme, il faut tre DBA ou avoir reu explicitement ce privilge avec l'option WITH ADMIN OPTION. - La personne ayant l'option WITH ADMIN OPTION pourra son tour donner ce privilge systme d'autres utilisateurs avec ou sans l'option WITH ADMIN OPTION. - N'importe quel utilisateur ayant reu le privilge systme GRANT ANY ROLE peut donner n'importe quel rle. - L'utilisateur ayant l'option WITH ADMIN OPTION pourra donner ou retirer ce privilge systme n'importe quel utilisateur de la base de donnes sauf celui lui ayant donn ce privilge.
4.2.2. Les privilges SYSDBA et SYSOPER

Pour permettre un utilisateur d'effectuer les nombreuses oprations de DBA, il faut lui donner des privilges de DBA comme SYSDBA et SYSOPER. Le choix entre ces deux privilges dpendant bien sur des actions que ce "DBA" devra effectuer.
18 / 29
Lorsque l'utilisateur possdant un des deux privilges SYSDBA ou SYSOPER se connecte la base, il est connect de manire implicite au schma de SYS. Il faut savoir que le privilge SYSDBA fournit l'utilisateur des privilges DBA illimits qui lui permettent d'effectuer n'importe quelle opration. Le privilge SYSOPER est un sous ensemble du privilge SYSDBA. Ce privilge permet de dmarrer, arrter, sauvegarder la base, mais ne permet pas de crer une base de donnes. Voici un exemple des privilges systmes fournit par les deux diffrents privilges. Catgorie Exemples STARTUP SHUTDOWN ALTER DATABASE OPEN | MOUNT ALTER DATABASE BACKUP CONTROLFILE ALTER DATABSE BEGIN | END BACKUP RECOVER DATABASE ALTER DATABASE ARCHIVELOG RESTRICTED SESSION Tous les privilges de SYSOPER mais avec l'option WITH ADMIN OPTION CREATE DATABASE RECOVER DATABASE UNTIL
SYSOPER
SYSDBA
Il est important de savoir que les privilges SYSDBA et SYSOPER ne peuvent tre attribus un rle.
4.2.3. L'authentification grce au fichier de mots de passe

Il y a 4 tapes pour mettre en place le fichier de mots de passe servant identifier les utilisateurs SYSDBA et SYSOPER: - Cration du fichier de mots de passe si celui-ci n'existe pas. Pour cela vous pouvez utiliser l'utilitaire de cration de fichier de mot de passe ORAPWD. - Vrifier que le paramtre REMOTE_LOGIN_PASSWORD_FILE du fichier init.ora possde la valeur EXCLUSIVE. - Donner les privilges SYSDBA et SYSOPER aux utilisateurs souhaits. Leur login sera alors automatiquement ajout au fichier de mot de passe. - Vrifier les utilisateurs prsents dans le fichier de mot de passe grce la vue V$PWFILE_USERS. Cette vue contient 3 colonnes, l'une correspondant au nom du user, une autre correspondant au fait qu'il possde le privilge SYSDBA et une autre correspondant au fait qu'il possde le privilge SYSOPER.
4.2.4. Mcanisme de protection du dictionnaire de donnes

Les utilisateurs ont des accs restreint aux objets du dictionnaire de donnes sauf si ils ont t autoriss accder des objets d'autres schmas. Vous pouvez contrler la protection du dictionnaire de donnes en modifiant le paramtre O7_DICTIONNARY_ACCESSIBILITY du fichier init.ora. Si ce paramtre a pour valeur la valeur TRUE alors l'accs aux objets de SYS est autoris, ce qui dsactive le mcanisme de protection. Si ce paramtre a pour valeur la valeur FALSE alors l'accs aux objets de SYS n'est plus autoris; ce qui permet des privilges systmes tels que EXECUTE ANY PROCEDURE d'excuter n'importe quelle procdure de la base sauf celle du schma de SYS.

4.2.5. Retrait de privilges systme
19 / 29
Il faut avoir la vision la plus prcise possible des privilges que vous allez fournir un utilisateur car donner trop de droits un utilisateur peut entraner de nombreux problmes de scurit. Vous devrez donc retirer des privilges systmes un utilisateur ou bien un rle si ceux-ci ne sont plus utiles aux actions de l'utilisateur. Voici la syntaxe :
REVOKE {<nom du privilge> | <nom du role>} [,{<nom du privilge> | <nom du role>}] FROM {<nom du user> | <nom du role> | PUBLIC} [,{<nom du user> | <nom du role> | PUBLIC} ;
4.2.6. Retrait de privilges : WITH ADMIN OPTION

Nous avons vu prcdemment qu'un utilisateur ayant reu un privilge systme avec l'option WITH ADMIN OPTION, pouvait son tour donner des droits d'autres utilisateurs. Il faut tre extrmement prudent avec cette option car quand vous retirerez le privilge systme cet utilisateur, tout les autres utilisateurs, ayant reu ce mme privilge de cet utilisateur, conserverons ce privilge. La rvocation de ce privilge ne produit pas un effet en cascade.
4.3.Gestion des privilges Objet

4.3.1. Accorder des privilges objet
Les privilges objets permettent aux utilisateurs d'effectuer des actions bien spcifiques sur des objets de la base de donnes, comme par exemple effacer des lignes d'une table en particulier. Voici un tableau vous donnant une ide des privilges objets que vous allez pouvoir utiliser sur certains objets: Privilge Objet ALTER DELETE EXECUTE INDEX INSERT REFERENCES SELECT UPDATE Table Vue Squence Procdure
9 9 9 9 9 9 9
9 9 9 9 9 9 9
Il est tout fait possible de donner ces privilges objets des rles ou bien des utilisateurs. Voici la syntaxe permettant de donner un ou plusieurs privilges objet :
GRANT {<nom du privilge> [<liste de colonne>] [,<nom du privilge> [<liste de colonne>]] | ALL [PRIVILEGES]} ON <nom de l'objet> TO {<nom du user> | <nom du rle> | PUBLIC} [,{<nom du user> | <nom du rle> | PUBLIC}] [WITH GRANT OPTION] ;
20 / 29
L'option WITH GRANT OPTION permet l'utilisateur ayant reu ce privilge objet de donner son tour ce privilge.
Exemple :
GRANT EXECUTE ON dbms_pipe TO public; GRANT UPDATE (empno, ename) ON emp TO Karen WITH GRANT OPTION;
Il y a certaines rgles suivre avant de donner des privilges objets. - Pour donner un privilge objet quelqu'un, il faut que cet objet vous appartienne ou bien que vous ayez reu ce privilge avec l'option WITH GRANT OPTION. - Vous possdez tous les privilges objets ainsi que l'option WITH GRANT OPTION pour tous les objets qui vous appartiennent. - Pour des raisons de scurits, faites trs attention lorsque vous donner des droits sur vos objets. - L'option WITH GRANT OPTION ne peut tre utilise lorsque vous donnez un privilge objet un rle.
4.3.2. Retrait de privilges objet

Il faut toujours se rappeler que donner trop de droits peut engendrer des problmes de scurit. Nous allons donc voir comment retirer des droits des utilisateurs ou des rles. Voici la syntaxe :
REVOKE {<nom du privilge> [, <nom du privilge>] | ALL [PRIVILEGES]} ON <nom de l'objet> FROM {<nom du user> | <nom du rle> | PUBLIC} [, {<nom du user> | <nom du rle> | PUBLIC }] [CASCADE CONSTRAINTS];
4.3.3. Retrait de privilges : GRANT OPTION

A la diffrence de l'option WITH ADMIN OPTION, l'option WITH GRANT OPTION se retire en cascade. Si l'utilisateur qui vous aviez donn un privilge avec l'option WITH GRANT OPTION l'avait donn son tour un autre utilisateur, et bien lorsque vous retirez ce privilge cet utilisateur, alors tout ceux qui ont reu ce mme privilge de cet utilisateur se le verront retirer automatiquement.
4.4.Monitoring des privilges

4.4.1. Affichage des privilges systme
Vous pourrez en tant que DBA aller chercher toutes les informations concernant les privilges systmes dans les vues systme DBA_SYS_PRIVS, et SESSION_PRIVS.
4.4.2. Affichage des privilges objet

Vous pourrez trouver les informations concernant les privilges objets dans les vues DBA_TAB_PRIVS et DBA_COL_PRIVS.
21 / 29
5. Gestion des Rles

5.1.Rles : Introduction
5.1.1. Caractristiques des rles
Les rles ont t mis en place afin de faciliter l'administration des privilges de la base de donnes. Ces rles : - Peuvent tre compos de privilges systme et objet. - Peuvent tre donn des utilisateurs et des rles (except lui-mme). - Les rles peuvent tre activs ou dsactivs. - Le nom d'un rle ne pourra en aucun cas tre celui d'un autre rle ou celui d'un utilisateur. - Les rles n'appartiennent aucun utilisateur et ne font partis d'aucun schma. - La description et les privilges associs un rle sont stocks dans le dictionnaire de donnes. - Pour donner ou retirer un droit, il suffit d'utiliser la mme commande que pour donner un privilge.
5.1.2. Bnfices des rles

L'utilisation des rles permet de : - Rduire le besoin de donner des droits de manire individuel. Grce aux rles vous pouvez donner des droits un rle et donner ce rle des utilisateurs, ce qui vous vitera de donner tous ces droits chaque utilisateur. - Grer de manire dynamique la gestion des privilges. Si vous modifiez les privilges associs un rle, alors tout les utilisateurs, possdant ce rle, obtiendront les modifications de manire transparente et automatique. - Grer la scurit en activant ou dsactivant ces rles, et en les scurisant au moyen d'un mot de passe. - Supprimer les effets de suppressions en cascade absent lors de la suppression de privilges systme ayant t fournit avec l'option WITH ADMIN OPTION. - Diminuer le stockage de tous les ordres GRANT dans le dictionnaire de donnes. - Rduire le nombre de privilges vrifier si le rle est dsactiv. Si le rle est dsactiv, il faudra moins de temps pour vrifier les droits de l'utilisateur lors de l'excution d'une requte.
5.2.Implmentation des Rles

5.2.1. Cration d'un rle
Voici la syntaxe qui permet de crer un rle :
CREATE ROLE <nom du rle> [NOT IDENTIFIED | IDENTIFIED {BY <mot de passe> | EXTERNALLY}];
5.2.2. Identification des rles prdfinis

Il existe plusieurs rles prdfinis, dont voici un tableau rcapitulatif : Rles prdfinis Descriptions Permet d'accder aux ressources systme. Attention ce rle donne le privilge systme UNLIMITED TABLESPACE. Il procure aussi une rtro-compatibilit avec la version 6 d'Oracle.
RESOURCE
22 / 29
CONNECT DBA EXP_FULL_DATABASE
Permet l'utilisateur de se connecter et de cre des objets la condition que vous lui donniez un quota sur un tablespace. Donne tout les privilges systme avec l'option WITH ADMIN OPTION Permet de faire des exports complets de la base de donnes. Permet de faire des imports complets de la base de donnes.
IMP_FULL_DATABASE Permet de vider les tables d'audit. DELETE_CATALOG_ROLE Permet d'excuter les packages PL/SQL systme. EXECUTE_CATALOG_ROLE SELECT_CATALOG_ROLE Permet d'avoir accs sur les tables et vues du dictionnaire de donnes.
Mis part le rle DBA, il n'est pas conseill d'utiliser les rles prdfinis d'Oracle mais plutt de crer et d'utiliser vos propres rles.
5.2.3. Modifier un rle

La seule chose qu'il est possible de modifier dans un rle est son systme de protection par mots de passe. Ceci peut tre fait grce la syntaxe suivante:
ALTER ROLE <nom du rle> { NOT IDENTIFIED | IDENTIFIED { BY <mot de passe> | EXTERNALLY }};
Le mot cl EXTERNALLY signifie que l'utilisateur devra tre authentifi par le systme d'exploitation avant de pouvoir activer ou dsactiver ce rle.
5.2.4. Assignation d'un rle un utilisateur

Voici la syntaxe pour assigner un rle un utilisateur ou un autre rle :
GRANT <nom du rle> [,<nom du rle>] TO {<nom du user> | <nom du rle> | PUBLIC} [, {<nom du user> | <nom du rle> | PUBLIC}] [WITH ADMIN OPTION];
5.3.Contrler les Rles

5.3.1. Limitation du rle par dfaut
Le rle par dfaut des utilisateurs doit tre dfini en fonction de leur travail, ce qui permet de restreindre leurs activits sur les schmas. Voici la syntaxe pour modifier le rle par dfaut d'un utilisateur:
ALTER USER <nom du user> DEFAUTL ROLE {<nom du rle> [, <nom du rle>] | ALL [EXCEPT <nom du rle> [, <nom du rle>] ] | NONE};

5.3.2. Activation d'un rle
23 / 29
Il est possible d'activer ou de dsactiver un rle temporairement pour une session. Quand un rle est activ, l'utilisateur pourra alors utiliser les privilges de ce rle. Voici la syntaxe qui permet d'activer ou de dsactiver un rle :
SET ROLE { <nom du rle> [IDENTIFIED BY PASSWORD] [, <nom du rle> [IDENTIFIED BY PASSWORD>]] | ALL [EXCEPT <nom du rle> [, <nom du rle>] ] | NONE};
Cette commande dsactive tout les rles et ractive seulement ceux cits dans la commande.
5.3.3. Retrait d'un rle un utilisateur

Voici la syntaxe qui permet de retirer un rle un utilisateur ou un autre rle :
REVOKE <nom du rle> [,<nom du rle>] FROM {<nom du user> | <nom du rle> | PUBLIC} [,{<nom du user> | <nom du rle> | PUBLIC}] ;
5.3.4. Suppression d'un rle

Afin de s'assurer qu'un rle ne peut plus tre utilis, il vaut mieux supprimer le rle avec la syntaxe suivante :
DROP ROLE <nom du rle>;
5.4.Rles : Informations et Conseils

5.4.1. Conseils pour la cration de rles
Nous allons voir les diffrents points qu'il faut suivre pour mettre en place des rles appropris aux besoins des utilisateurs. Crer autant de rle que de fonctions existantes. Assigner les privilges ncessaires pour effectuer une fonction au rle correspondant. Crer un rle (rle utilisateur) distinct pour chaque type d'utilisateur. Donner au rle utilisateur, les rles des diffrentes fonctions que ce type d'utilisateur pourra effectuer. Donner chaque utilisateur son rle utilisateur. Donner un mot de passe chaque rle.
5.4.2. Affichage des infos concernant les rles

Vous pourrez trouver des informations sur les diffrents rles dans les vues systme suivantes : - ROLE_SYS_PRIVS : vue concernant les privilges systme accords des rles. - ROLE_TAB_PRIVS : vue concernant les privilges sur une table accords des rles. - ROLE_ROLE_PRIVS : vue concernant les rles accorder d'autres rles. - DBA_SYS_PRIVS : vue permettant de voir les privilges systmes accords des utilisateurs et des rles. - DBA_ROLES : vue permettant d'accder tous les rles prsents dans la base de donnes. - DBA_ROLE_PRIVS : vue permettant les rles qui ont t accords d'autres rles ou utilisateurs.
5.4.3. Affichage des rles et privilges actifs

Vous pouvez savoir quels sont les rles actuellement actif pour un utilisateur en consultant la vue SESSION_ROLES.
24 / 29
La vue SESSION_PRIVS permet quand elle de savoir quels sont les privilges systmes actuellement disponible pour une session d'un utilisateur.
25 / 29
6. Audit
6.1.Utilisation de l'audit de base de donnes
6.1.1. Catgories d'audit
Il existe trois catgories d'audit dans une base de donnes Oracle - Audits des privilges : Ces audits enregistrent les dmarrages et arrts de l'instance. Ils incluent le nom de l'utilisateur, le nom du terminal, la date et l'heure. Ils enregistrent aussi toutes les connexions effectues par des utilisateurs SYSDBA ou SYSOPER. Audits de la base de donnes : Ces audits servent de moniteur et permettent d'enregistrer des informations sur les utilisateurs et sur les activits de la base de donnes. Toutes ces informations d'audit sont enregistres dans un protocole d'audit qui est stock dans la table AUD$ qui se trouve dans le dictionnaire de donnes. Ce protocole d'audit peut tre utilis pour dtecter toutes les activits douteuses survenues dans la base. Ces audits permettent aussi d'enregistrer certaines activits de la base de donnes comme les entres / sorties. Audits d'applications : Ces audits permettent de chercher toutes les modifications sur les colonnes et enregistrent ces modifications. Ce type d'audit doit tre cod (par exemple sous forme de trigger) car il ne fait pas parti des outils standard d'audit.
6.1.2. Audit de base de donnes: Phases

Avant de faire un audit, il est important de dfinir une mthode d'audit qui va nous viter de gnrer un trop grand nombre d'informations inutiles et de faire grossir de manire incontrle l'audit. La premire phase dans un audit de base de donnes est d'activer l'audit au moyen du paramtre AUDIT_TRAIL du fichier init.ora. Puis de dfinir les actions d'audit au moyen de la commande AUDIT. Le paramtre AUDIT_TRAIL permet de dfinir o est ce que les informations d'audit seront enregistres (dans la base ou dans le gestionnaire d'audit du systme d'exploitation). Vous devrez ensuite grce la commande AUDIT dfinir des audits sur certains objets ou privilges et dfinir si cet audit devra tre enregistr pour chaque occurrence de cet vnement ou bien une seule fois par session. La seconde phase dans un audit de base de donnes est de gnrer des actions SQL et PL/SQL. Ce sont alors les options d'audit qui dtermineront si oui ou non il faut gnrer des enregistrements d'audit. La troisime et dernire phase d'audit consiste analyser les informations d'audit en allant examiner les vues du dictionnaire de donnes ou en utilisant un logiciel du systme d'exploitation.
6.1.3. Valeur du paramtre AUDIT_TRAIL

Vous seul, en tant que DBA, pourrez activer ou dsactiver l'audit grce au paramtre AUDIT_TRAIL. Ce paramtre pourra avoir les valeurs suivantes : - DB : Ce paramtre signifie que tous les enregistrements seront stocks dans la table AUD$. - OS : Ce paramtre signifie que tous les enregistrements seront stocks dans le gestionnaire d'audit du systme d'exploitation (par exemple dans le Gestionnaire des vnements de Windows NT). - NONE : L'audit est dsactiv. A noter qu'il est possible d'utiliser les commandes AUDIT et NOAUDIT lorsque le paramtre AUDIT_TRAIL est la valeur NONE.

6.1.4. Requte d'audit
26 / 29
L'audit des ordres SQL se fera indpendamment du schma de l'utilisateur. L'audit de requte se fera au moyen de la syntaxe suivante :
AUDIT <requte> [,<requte>] [BY <nom du user> [,<nom du user>] ] [BY {SESSION | ACCESS}] [WHENEVER [NOT] SUCCESSFUL];
L'option BY permet de spcifier le ou les utilisateurs qui devront tre audits (le paramtre par dfaut est : tous les utilisateurs). L'option BY SESSION permet d'enregistrer une seule fois un vnement par session alors que l'option BY ACCESS permet d'enregistrer le mme vnement autant de fois que celui-ci ce produit. La valeur par dfaut de l'option WHENEVER correspond au deux valeurs. Voici un exemple d'audit de requte :
AUDIT DELETE ON scott.s_emp BY ACCESS WHENEVER NOT SUCCESSFUL;
Cet exemple enregistre toutes les tentatives de DELETE, sur la table s_emp de SCOTT, qui n'ont pas abouties.
6.1.5. Privilges d'audit

L'audit des privilges ne se base pas sur un objet particulier mais seulement sur le privilge utilis. Voici la syntaxe :
AUDIT < privilge systme > [,<privilge systme>] [BY <nom du user> [,<nom du user>] ] [BY {SESSION | ACCESS}] [WHENEVER [NOT] SUCCESSFUL];
Oracle fournit un certain nombre de raccourci sur les privilges systme qui vous permettront d'auditer des privilges multiple de manire simple. Voici des exemples de raccourci : RESOURCE contient les privilges suivants : ALTER SESSION CREATE CLUSTER CREATE DATABASE LINK CREATE PROCEDURE CREATE ROLLBACK SEGMENT CREATE SEQUENCE CREATE SYNONYM CREATE TABLE CREATE TABLESPACE CREATE VIEW CONNECT contient les privilges suivants : CREATE SESSION DBA contient les privilges suivants : AUDIT SYSTEM CREATE PUBLIC DATABASE LINK CREATE PUBLIC SYNONYM

CREATE ROLE CREATE USER ALL PRIVILEGES contient les privilges suivants : Tous les privilges systme.
27 / 29
Exemple :
AUDIT ALTER ANY TABLE BY scott WHENEVER SUCCESSFUL;
6.1.6. Audit des objets de base de donnes

Il y a diffrents types d'objets qui peuvent tre audit : - Les tables - Les vues - Les squences - Les packages - Les procdures - Les fonctions Voici la syntaxe permettant d'auditer un objet en particulier :
AUDIT <operation devant tre audite> [,<operation devant tre audite>] ON {<nom de l'objet> | DEFAULT} [BY {SESSION | ACCESS}] [WHENERVER [NOT] SUCCESSFUL];
L'option DEFAULT spcifie que les options d'audit seront mises en place pour tout les objets nouvellement cres. Ce type d'audit ne tiens pas compte de l'utilisateur ayant effectu l'opration audite.
Exemple :
AUDIT DELETE ON scott.s_emp BY SESSION WHENEVER SUCCESSFUL;
6.1.7. Dsactiver les options d'audit

Aprs avoir effectu tous vos audits, il est ncessaire de dsactiver cette fonction afin d'viter une augmentation inutile du rfrentiel d'audit. Pour cela, il existe deux possibilits : - Soit donner la valeur NONE au paramtre AUDIT_TRAIL - Soit dsactiver chaque commande d'audit au moyen de la commande NOAUDIT Voici la syntaxe de la commande NOAUDIT :
NOAUDIT { <requte> | <privilge systme> } [ BY <nom du user> ] [ WHENERVER [ NOT ] SUCCESSFUL ];
Et voici la syntaxe de la commande NOAUDIT pour un audit base sur une requte :
NOAUDIT <requte> ON { <nom de l'objet> | DEFAULT } [ WHENERVER [ NOT ] SUCCESSFUL ];

Exemple :
NOAUDIT ALTER TABLE BY scott WHENEVER SUCCESSFUL;
28 / 29
6.2.Affichage des rsultats d'audit

6.2.1. Vues concernant les options d'audit
Voici les vues ou vous pourrez allez chercher les informations concernant l'audit en gnral : - ALL_DEF_AUDIT_OPTS : Cette vue contient toutes les options d'audit par dfaut. Ces options correspondent toutes les options d'audits dont hritera tout nouvel objet de la base. - DBA_STMT_AUDIT_OPTS : Cette vue affichera toutes les options sur les audits de requte SQL. - DBA_PRIV_AUDIT_OPTS : Cette vue contient toutes les options sur les audits de privilges systmes. - DBA_OBJ_AUDIT_OPTS : Cette vue contient toutes les options sur les audits d'objets.
6.2.2. Afficher les rsultats d'audit

Voici les vues contenant le rsultat des audits : - DBA_AUDIT_TRAIL : Cette vue contient absolument tous les rsultats de tous les audits. - DBA_AUDIT_SESSION : Cette vue contient toutes les connections et dconnections. - DBA_AUDIT_STATEMENT : Cette vue contient les rsultats des audits de requtes SQL. - DBA_AUDIT_OBJECT : Cette vue contient les rsultats des audits d'objets. - DBA_AUDIT_EXISTS : Cette vue contient les rsultats sur les audits de type EXISTS/NOT EXISTS.
6.3.Vrification de la validit de l'audit

6.3.1. Conseils pour l'audit
Pour effectuer un audit intressant, il est essentiel de suivre quelques rgles : - Identifier les ncessits auditer, et dfinir les options minimales d'audit qui permettront d'obtenir le rsultat escompt. - Spcifier l'utilisateur qui devra tre audit lors de l'audit des privilges et des requtes. - Il est prfrable d'utiliser l'option BY SESSION et non BY ACCESS. Cela permettra d'viter d'enregistrer de nombreuses fois les mmes oprations. - Vous devez vrifier, lors d'audit d'objets, la vue DBA_AUDIT_OBJECT car les utilisateurs peuvent auditer leur propre objets. - Vous devez faire attention lorsque vous donnez le privilge AUDIT ANY car cela donne le droit un utilisateur d'auditer n'importe quel objet de son schma. - Ne pas oublier d'effacer le contenu de l'audit une fois les analyses termines. - Pour minimiser le nombre de lignes gnres par l'audit, il est fortement conseill d'utiliser l'option WHENEVER et de lui spcifier une valeur. - Il est conseill de dplacer la table AUD$, qui lors d'audit ne fait qu'augmenter et fragmenter le tablespace SYSTEM. - Il est ncessaire de surveiller rgulirement la taille de la table AUD$. - Il faut scuriser les informations de l'audit. Pour cela seul le DBA devra possder le rle DELETE_CATALOG_ROLE. - Vous ne devrez activer l'audit que lorsque cela est ncessaire.
6.3.2. Dplacer la table d'audit

Nous allons maintenant voir comment dplacer la table AUD$ sur un tablespace diffrent du tablespace SYSTEM.
29 / 29
Avant de dplacer cette table il est ncessaire de vrifier que l'audit est bien dsactiv. Ensuite il suffit de taper la commande suivante :
ALTER TABLE aud$ MOVE TABLESPACE <nom du nouveau tablespace>;
Nous allons ensuite crer un nouvel index pour la table AUD$ dans un tablespace diffrent du tablespace SYSTEM et du tablespace de la table AUD$ avec la syntaxe suivante :
CREATE INDEX <nom de l'index> ON aud$(sessionid,ses$tid) TABLESPACE <nom du tablespace>;

(Draft) Dba - Module 5 (2003-08-06) 2 - 0

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

(Draft) Dba - Module 5 (2003-08-06) 2 - 0

Transféré par

Droits d'auteur :

Formats disponibles

Module n5

GESTION DES UTILISATEURS

Auteur : Arnaud Bontemps

Gestion des utilisateurs

Table des matires

Gestion des utilisateurs

Gestion des utilisateurs

1. Administration des utilisateurs

1.1.2. Cration d'un utilisateur : Checklist

Gestion des utilisateurs

1.1.3. Cration d'un utilisateur : Serveur d'authentification

1.1.4. Cration d'un utilisateur : Authentification Os

1.1.5. Cration d'un utilisateur : Conseils

Gestion des utilisateurs

1.2.Gestion des utilisateurs

1.2.2. Compte bloqu

1.2.3. Modification du quota d'un utilisateur

1.2.4. Suppression d'un utilisateur

Gestion des utilisateurs

1.3.Monitoring des utilisateurs

1.3.2. Affichage du statut des comptes utilisateurs

Gestion des utilisateurs

2. Administration des ressources et de la scurit des mots de passe

2.1.2. Cration de profils

Gestion des utilisateurs

2.1.3. Assignation d'un profil un utilisateur

2.2.Administration des profils

2.2.2. Suppression d'un profil

2.2.3. Affichage des limitations de ressources

Gestion des utilisateurs

2.3.Administration des mots de passe

Dont voici un exemple d'utilisation

Gestion des utilisateurs

2.3.2. Cration de profil: Gestion des mots de passe

2.3.3. Dfinition d'une fonction de gestion des mots de passe

2.3.4. Afficher les informations sur les profils et les utilisateurs

Gestion des utilisateurs

3. Consommation de ressources utilisateurs

3.1.2. Activer les limitations de ressources

Gestion des utilisateurs

3.1.3. Afficher les limitations de ressources

3.1.4. Forcer l'utilisation des limitations de ressources

3.2.Utilisation du gestionnaire de ressources

Gestion des utilisateurs

Voici la commande PL/SQL excuter pour crer un groupe de consommateurs:

Gestion des utilisateurs

Pour changer de groupe pour une session particulire :

Gestion des utilisateurs

4. Gestion des privilges

4.1.2. Privilges systme

Gestion des utilisateurs

4.2.Gestion des privilges systme

4.2.2. Les privilges SYSDBA et SYSOPER

Gestion des utilisateurs

4.2.3. L'authentification grce au fichier de mots de passe

4.2.4. Mcanisme de protection du dictionnaire de donnes

Gestion des utilisateurs

4.2.6. Retrait de privilges : WITH ADMIN OPTION

4.3.Gestion des privilges Objet

Gestion des utilisateurs

4.3.2. Retrait de privilges objet

4.3.3. Retrait de privilges : GRANT OPTION

4.4.Monitoring des privilges