DBAs Oracle et Privilèges d’exploitation

Divers, Sécurité Oracle pas de Commentaire »

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 niveaux 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’exploitation

C’est une forme d’authentification externe, en ce sens que ce n’est pas Oracle qui contrôle la connexion grace a 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 a 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écurité 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 utilisateur 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 caractéristiques que précédemment sauf que la base est située sur une machine distante 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’invalider cette possibilité.

Authentification via fichier de mots de passe
Dans ce cas de figure, les privilèges seront controlés a 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 a EXCLUSIVE (c’est le défaut) pour pouvoir utiliser et modifier le password file

Utilisateurs Oracle 10g

Divers, Sécurité Oracle 2 Commentaires »

La notion d’utilisateur

Quels que soient l’architecture utilisée,le programme client, ou votre profil utilisateur : administrateur, développeur ou simple utilisateur final, l’accès aux données d’une base exige de se connecter ? un compte utilisateur.

note : les utilitaires système d’export, d’import, de sauvegarde, et de chargement par exemple impliquent également une connexion ? un compre utilisateur.

Un compte peut éventuellement contenir des données (tables principalement) on l’appelle dans ce cas un SCHEMA. Il peut également être verrouillé par l’administrateur.

Pour créér un utilisateur on utilisera soit du SQL : instruction CREATE USER…
soit un outil d’administration graphique comme la console OEM ou la console GRID.
Pour le supprimer on utilisera la commande :
DROP USER nom_user CASCADE pour supprimer également les données associées.

La description de tous les utilisateurs est donnée par la vue SYS.DBA_USERS ou pour un user non privilégié dans USER_USERS

Les principaux attributs d’un utilisateur sont les suivants :
- le nom
- la méthode d’authentification…et le mot de passe associé le cas échéant
- ses espaces logiques de travail : TABLESPACEs par défaut et temporaire
- ses quotas de création de structures données sur ses TABLESPACES permanents (optionnel)
- ses droits
- son PROFIL de consommation de ressources (optionnel)

note : un utilisateur final n’a pas besoin de quota, puisque’il ne créé pas de structure, mais tout au plus insère des données dans des structures existantes.
Il n’a besoin que de privilèges minimaux, celui de se connecter et de consulter voire mettre ? jour quelques tables d’un schéma.

Voir l’article sur les Roles et l’article sur les privilèges objets pour plus d’infos

En pratique dans les entreprises il existe un nombre limités de types d’utilisateurs. Ceci aura pour conséquence de pouvoir limiter sensiblement les ‘groupes d’utilisateur’.
On trouve, du moins privilégié au + privilégié :
- l’utilisateur d’infocentre (consultation de données uniquement)
- l’utilisateur d’application (consultation et mise ? jour)
- le responsable ou administrateur d’application (idem + gestion des utilisateurs et de l’accès aux fonctionnalités de l’application)
- le développeur (droit de cration de tables, vues, indexs, procédures stockées, triggers, séquences,…)
- le DBA (accès en lecture total au dictionnaire et droits de consultation mis ? jour de toutes les données utilisateurs, tous les droits sur la base)

Les ‘profils’ (PROFILE) Oracle

Ces ‘profils’ assez mal nommés, fixent des limites de consommation de ressouces (temps de session et de connexion, consommation mémoire partagée et E/S disque), la politique de mot de passe des utilisateurs (expiration et historique) et peuvent être comme les roles, partagés par un groupe d’utilisateurs.

Il existe 2 profils prédéfinis : DEFAULT, pours les users lambdas et MONITORING_PROFILE utilisé pour le compte DBSNMP.

SQL> SELECT * FROM DBA_PROFILES
WHERE profile=’DEFAULT’

DEFAULT COMPOSITE_LIMIT 	  KERNEL 	UNLIMITED
DEFAULT SESSIONS_PER_USER 	  KERNEL 	UNLIMITED
DEFAULT CPU_PER_SESSION 	  KERNEL 	UNLIMITED
DEFAULT CPU_PER_CALL 		  KERNEL 	UNLIMITED
DEFAULT LOGICAL_READS_PER_SESSION KERNEL 	UNLIMITED
DEFAULT LOGICAL_READS_PER_CALL 	  KERNEL 	UNLIMITED
DEFAULT IDLE_TIME 		  KERNEL 	UNLIMITED
DEFAULT CONNECT_TIME 		  KERNEL 	UNLIMITED
DEFAULT PRIVATE_SGA 		  KERNEL 	UNLIMITED
DEFAULT FAILED_LOGIN_ATTEMPTS 	  PASSWORD 	30
DEFAULT PASSWORD_LIFE_TIME 	  PASSWORD 	UNLIMITED
DEFAULT PASSWORD_REUSE_TIME 	  PASSWORD 	UNLIMITED
DEFAULT PASSWORD_REUSE_MAX 	  PASSWORD 	UNLIMITED
DEFAULT PASSWORD_VERIFY_FUNCTION  PASSWORD 	NULL
PROFILE RESOURCE_NAME 		  RESOURCE 	LIMIT
DEFAULT PASSWORD_LOCK_TIME        PASSWORD 	UNLIMITED
DEFAULT PASSWORD_GRACE_TIME 	  PASSWORD 	UNLIMITED

Ils permettent par exemple de limiter le nombre de sessions simultanées (très pratique en cas de développeurs trop enthousiastes !)SQL> CREATE PROFILE deux_sessions_max LIMIT
SESSIONS_PER_USER 2
SQL> ALTER USER dev1 PROFILE deux_sessions

Les utilisateurs prédéfinis d’Oraclel 10g

Essentiellement 2 catégories, les utilisateurs d’administration ou système :
- SYS : DBA et propriétaire du dictionnaire
- SYSTEM : DBA et propriétaire de qq vues système et outils
- SYSMAN : utilisateur de la console OEM ou GRID
- DBSNMP : utile pour Oracle AGent qui remonte des infos sur la base locale ? la console
- XDB, pour la BD XML
et les users/schémas de démo :
- le célèbre SCOTT et ses tables EMP et DEPT
- HR, schéma « ressources Humaine », purement relation au niveau du modèle de données
- OE, schéma « gestion des commandes » au modèle relationnel / objet
- SH, schéma « ventes », modèle relationnel en étoile
et des users génériques
PUBLIC et ANONYMOUS

La liste exhaustive des USERS prédéfinis est donnée par le SQL suivant (principales colonnes seulement):

SQL> SELECT username, account_status, lock_date, default_tablespace,
temporary_tablespace, profile
FROM DBA_USERS

USERNAME ACCOUNT_STATUS DEFAULT_TABLESPACE TEMPORARY_TABLESPACE PROFILE
——– ————– —————— ——————– ——-
SYS OPEN SYSTEM TEMP DEFAULT
SYSTEM OPEN SYSTEM TEMP DEFAULT
DBSNMP OPEN SYSAUX TEMP MONITORING_PROFILE
SYSMAN OPEN SYSAUX TEMP DEFAULT
SCOTT OPEN USERS TEMP DEFAULT

note : il est vivement conseillé de se connecter au minimum dans SYS ou SYSTEM. On créera un compte avec le role ‘DBA’ pour l’administration.
Il est également conseillé de verrouiller les comptes non utilisés et de changer leur mot de passe par défaut car ils peuvent présenter des failles de sécurité.

Les méthodes d’authentification

Pour assurer la confidentialitté d’accès aux données des utilisateurs, on doit s’authentifier pour se connecter ? la base de données.
Il existe 3 formes différentes d’authentification : par mot de passe, externe ou globale.

1) authentification par mot de passe
C’est une authentification classique, et répandue qui utilise un mot de passe crypté, stocké localement dans la table des utilisateurs de la base.

SQL> SELECT username, password FROM dba_users;

USERNAME PASSWORD
——– —————-
SYS 4C1C01757062C16D
SYSTEM D4DF7931AB130E37
DD EXTERNAL
SCOTT F894844C34402B67

2) authentification externe

Oracle offre une possibilité de se connecter sans fournir explicitement le mot de passe du compte. Ceci ne veut pas dire que le compte n’est pas protégé, mais que la protection est déporté au niveau de l’OS, ou en d’autres termes que le SGBD ‘fait confiance’ au système d’authentification de l’OS qui le porte. Pour que ceci soit possible il faut

- que l’utilisateur, soit défini comme authentifié de manière externe,
- que le nom du compte aie pour suffixe le nom du compte de l’OS et pour préfixe un préfixe générique défini dans les paramètres d’initialisation de la base (init.ora ou spfile) par la variable OS_AUTHENT_PREFIX.
Par défaut OS_AUTHENT_PREFIX vaut ‘OPS$’.
- que l’utilisateur se connecte ? Oracle en ne fournissant ni nom ni mot de passe mais simplement le séparateur ‘/’.
exemple :
— creation du user par le DBA
SQL> CREATE USER OPS$DD IDENTIFIED EXTERNALLY
– on pourra ensuite (moyennant que l’utilisateur aie au moins
– un privilège ‘CREATE SESSION’…) se connecter en externe :
– connexion ? l’OS
login: DD
pwd : *******
– connexion externe dans le compte OS
$> sqlplus /
SQL> user OPS$DD connected…

note : l’authentification externe permet d’une certaine façon de sécuriser les scripts Shell ou d’une manière générale les batchs, car le mot de passe Oracle n’apparait plus en clair dans les scripts

3) authentification globale

… ? compléter…

Quelques exemples de commandes SQL

Autant que faire se peut on utilisera la console, mais ca peut dépanner de connaitre un minimum de SQL (ca peut aussi épater les filles…mais lequelles?)

SQL> CREATE USER TOTO IDENTIFIED BY TUTU;
– créé un user toto avec mot de passe tutu
SQL> DROP USER TOTO
– supprime icelui
SQL> ALTER USER tete IDENTIFIED BY tata
– on modifie le mot de passe
SQL> CREATE USER dev1 IDENTIFIED BY xxx
DEFAULT TABLESPACE hr
TEMPORARY TABLESPACE temp
QUOTA 100M ON hr
PROFILE profile_standard_de_ma_societe

SQL> GRANT CREATE SESSION to dev1;
SQL> CREATE ROLE role_developpeur_standard;
– ce role sera partagé par tous les développeurs
SQL> GRANT CREATE TABLE, CREATE VIEW, CREATE INDEX,
CREATE PROCEDURE, CREATE SEQUENCE TO role_developpeur_standard;
SQL> GRANT ROLE role_developpeur_standard TO dev1 WITH GRANT OPTION;
– on donne le droit de crééer des objets standards
SQL> GRANT CREATE TRIGGER TO dev1;
– on rajoute un droit spécifique ? DEV1…