Les privilèges du DBA

Divers, Sécurité Oracle Ajouter un commentaire

DBA et droits Oracle (privilèges et roles)

Un utilisateur Oracle (déclaré au sein de la base, ? distinguer de l’utilisateur au niveau OS) peut être DBA.
Il a tous les ‘privilèges système’ AU SEIN DE LA BASE, et le droit de les transmettre (ADMIN OPTION)
Grace ? quoi, il peut essentiellement :
* consulter et mettre ? jour (SELECT, UPDATE, INSERT, DELETE) toutes les données utilisateur de la base
* créer, modifier des structures de données utilisateur (CREATE, ALTER, DROP) n’importe ou (ANY TABLESPACE)
* gérer des utilisateurs et des droits (CREATE/DROP USER, GRANT, REVOKE)
* consulter la totalité du dictionnaire
* exécuter des ordres d’administration purs (CREATE DATABASE, DATAFILE, TABLESPACE)

Il y a 2 utilisateurs privilégiés prédéfinis, SYS et SYSTEM (dont les mots de passe sont définis ? la création de la base ou par ‘ORAPWD’)
Ils sont tous les 2 DBA, mais SYS est plus privilégié en ce sens qu’il est propriétaire des tables et vues du dictionnaire.

Il existe un ensemble de privilège (ROLE) prédéfini nommé ‘DBA’ qui donne les privilèges nécessaire ? un DBA.
Après avoir créé un utilisateur ‘normal’ il suffit de lui donner ce rôle pour en faire un DBA :
SQL> GRANT DBA TO

note : Il existe un autre rôle prédéfini, parmi quelques dizaines, qui est également intéressant c’est le role ‘SELECT_CATALOG_ROLE’. Il est souvent utilisé par des progiciels ou applicatifs utilisant Oracle pour récupérer des méta données.

Privilèges d’exploitation (SYSDBA et SYSOPER)

Certains ‘administrateurs’ : les opérateurs et techniciens d’exploitation, ou ‘exploitants’ pour faire court, n’ont pas forcément besoin d’un niveau de privilège DBA.

Les opérations concernés sont par exemple :

* les démarrage / arrêts,

* les sauvegardes / restaurations,

* la planification et l’exécution de batch

Oracle fournit 2 niveaux de privilèges, qui peuvent être assimilés ? des niveuax de connexion, qui satisfont ces besoins : les privilèges d’exploitation ‘SYSDBA’ et ‘SYSOPER’.
Comme tout accès privilégié il s’acquiert via un processus d’identification / authentification.

Authentification locale au niveau du système d’explotation

C’est une forme d’authentification externe, en ce sens que ce n’est pas Oracle qui contrôle la connexion grace ? son référentiel interne. On se connecte directement (via telnet ou ssh par exemple) au système qui héberge le serveur de données, puis ? la base locale, sans plus faire intervenir le réseau.
Ce type de connexion originale ne nécessite pas d’identifiant ni de mot de passe Oracle, mais d’être un utilisateur privilégié au niveau O.S.

note : un utilisateur quelconque, non privilégié de la base, peut aussi être défini avec une authentificatin externe, et se connecter localement avec une commande du type : sqlplus /

On peut dire que dans ce cas la sécrité est déportée au niveau O.S. et qu’Oracle accorde sa ‘confiance’ aux mécanismes d’identification / authentification de ce dernier.

exemples de connexion avec le client SQL standard :
connexion ‘normale’
$sqlplus scott/tiger
connexion avec authentification externe
$sqlplus / as sysdba
$sqlplus / as sysoper

Pour obtenir un ‘privilège’ d’exploitation il suffit d’appartenir au groupe utilsateur correspondant au niveau système :

privilège  gpe unix    groupe windows
SYSDBA     dba         ORA_DBA
SYSOPER    oper        ORA_OPER

Ces groupes sont créés lors de l’installation, et un administrateur système en ‘hérite’ automatiquement

note : Le ‘CONNECT INTERNAL’ des versions précédentes est définitivement obsolète et a été remplacé par le ‘CONNECT SYS AS SYSDBA. Parallèlement il n’est plus possible de se connecter SYS ‘tout court’ sans préciser ‘AS SYSDBA’.

Authentification distante au niveau du système d’explotation

Elle présente les mêmes caratéristiques que précédemment saus que la base est située sur une machine distate de la connexion système courante.

La syntaxe de connexion devient donc :
$ sqlplus /@nom_base_distante AS SYSDBA (ou SYSOPER)

Un paramètre d’initialisation de la base : REMOTE_OS_AUTJENTICATION=TRUE autorise cette fonctionnalité.

Note importante : il est vivement conseillé pour des raisons de sécurité d’invalité cette possibilité.

Authentification via fichier de mots de passe
Dans ce cas de figure, les privilèges seront controlés ? partir d’un fichier de mot de passe cryptés local.
exemple de création du fichier :
$ ORAPWD FILE=monfic PASSWORD=monpasse ENTRIES=100
avec
PASSWORD : le mot de passe de SYS
ENTRIES : le nb mas d’utilisateurs référencables dans le fichier.

on peut ensuite créer un utilisateur TOTO avec mot de passe TUTU et que le DBA lui donne le privilège oracle (et non pas système cette fois) nécessaire : SYSDBA ou SYSOPER :

$> sqlplus / AS SYSDBA
SQL> CREATE USER TOTO IDENTIFIED BY TUTU;
SQL> GRANT CREATE SESSION TO TOTO (qu’il aie le droit de se connecter quand même…)
$ GRANT SYSDBA TO TOTO (et lui donner le privilège d’exploitation qui va bien)

note : le paramètre d’initialisation REMOTE_LOGIN_PASSWORDFILE doit être ? EXCLUSIVE (c’est le défaut) pour pouvoir utiliser et modifier le password file

DBA et droits niveau OS (système d’exploitation)

La fonction de DBA, nécessite des privilèges au niveau Système d’exploitation :
- pour l’installation,
- la maintenance,
- la gestion et l’execution de batchs, de scripts (SQL ou shell),
- les sauvegardes / restauration

Sur Unix / Linux :
Il existe un user Unix nommé ‘oracle’ et un groupe associé nommé ‘dba’.
Tous les fichiers Oracle, appartiennent ? ‘utilisateur Oracle.

On peut (doit ?) crééer autant d’utilisateur Unix que de DBAs dans l’entreprise ; dba1, dba2, appartenant au groupe ‘dba’.Ceci permet d’éviter les recouvrements et d’avoir une meilleure tracabilité.
On évitera de travailler connecté en tant qu’utilisateur ‘oracle’ pour éviter toute erreur de manipulation des fichiers Oracle.

Note : les programmes et processus, qui constituent le coeur d’Oracle, s’executent en tant qu’oracle, et ont conséquemment les droits nécessaires pour écrire dans les fichiers de données, journaux, archives, etc.

Le DBA et le super utilisateur ‘root’ :
lors de l’installation, il est nécessaire d’écrire dans certains répertoires protégés du système (/etc par exemple) ou d’exécuter certaines taches privilégiées.
Cependant l’installation se fait bien en tant qu’Oracle, et l’installeur demande simplement le privilège root pendant la période nécessaire ? ces opérations.
Il execute 2 scripts autonomes root.sh et rootpre.sh, en tant que root.
Il retourne ensuite en mode ‘normal’.
En production les no de ports TCP/IP utilisés par Oracle 10g sont tous > 1024, et ne nécessitent donc pas de privilèges particuliers.

Sur Windows :

Le principe est plus simple. L’install se fait en général en tant qu’administrateur système.

Faire un commentaire