comptes oracle , lock et passwords

Sécurité Oracle pas de Commentaire »

Quelques infos en vrac:

Infos générales sur le compte

SQL> select * from dba_users
where username='TOTO';
USERNAME 	USER_ID 	PASSWORD 	ACCOUNT_STATUS 	LOCK_DATE 	EXPIRY_DA 	DEFAULT_TABLESPACE 	TEMPORARY_TABLESPACE 	CREATED 	PROFILE 	INITIAL_RSRC_CONSUMER_GROUP 	EXTERNAL_NAME
TOTO 		5394 		EBD64F4E40B74042 	LOCKED 	24-FEB-11 	USERS 		TEMP						21-FEB-11 	DEFAULT 	DEFAULT_CONSUMER_GROUP

On voit notamment :

profil : DEFAUT
lockable apres 20 essai et LE PASSWORD crypté !

Infos plus détaillées (si on se souvient du USERID Oracle (USER# ici) vu précédemment :

SQL> select * from sys.user$
where user#=5394
USER# 	NAME 	TYPE# 	PASSWORD 	DATATS# 	TEMPTS# 	CTIME 	PTIME 	EXPTIME 	LTIME 	RESOURCE$ 	AUDIT$ 	DEFROLE 	DEFGRP# 	DEFGRP_SEQ# 	ASTATUS 	LCOUNT 	DEFSCHCLASS 	EXT_USERNAME 	SPARE1 	SPARE2 	SPARE3 	SPARE4 	SPARE5 	SPARE6
5394 	TOTO 	1 	EBD64F4E40B74042 	4 	250 	21-FEB-11 	03-MAR-11 	  	24-FEB-11 	0 	  	1 	  	  	8 	20 	DEFAULT_CONSUMER_GROUP 	  	0

Avec :

CTIME : date de création
PTIME : date de modification
LTIME: date du lock
EXPTIME : date d’expiration
LCOUNT :
ASTATUS : statut du compte. En gros ouvert, verrouillé ou expiré.

Plus d’infos sur la colonne ASTATUS de USER$ :

SQL> SELECT * FROM SYS.USER_ASTATUS_MAP;

STATUS# STATUS
———- ——————————–
0 OPEN
1 EXPIRED
2 EXPIRED(GRACE)
4 LOCKED(TIMED)
8 LOCKED
5 EXPIRED & LOCKED(TIMED)
6 EXPIRED(GRACE) & LOCKED(TIMED)
9 EXPIRED & LOCKED
10 EXPIRED(GRACE) & LOCKED

details du profile  (qui n’apparaissent pas tous dans la console) :

failed_login_attempts - This is the number of failed login attempts before locking the Oracle user account. The default is three failed attempts.
password_grace_time - This is the grace period after the password_life_time limit is exceeded.
password_life_time - This is how long an existing password is valid. The default here forces a password change every 60 days.
password_lock_time – This specifies how long to lock the account after the failed login attempts is met. Most DBA’s set this value to UNLIMITED.
password_reuse_max – This is the number of times that you may re-user a passwords and is intended to prevent repeating password cycles (north, south, east, west).
password_reuse_time – This parameter specifies a time limit before a previous password can be re-entered. To allow unlimited use of previously used passwords, set password_reuse_time to UNLIMITED.
password_verify_function - This allows you to specify the name of a custom password verification function.

Solution erreur ORA-01157 , ORA-01110 : datafile perdu , corrompu ou effacé

Administration Oracle, Musée des erreurs, Rman, Sécurité Oracle pas de Commentaire »

En 6 clics

(oui je sais c’est un peu long)
L’hypothese est toujours qu’on ait une suavegarde RMAN en place qui tienne la route ( voir mon article : Sauvegarde Oracle 11g avec RMAN en 5 clics , pour + d’infos)
Avec la console OEM :
Cliquer sur l’onglet ‘Availability’, puis le lien ‘perform recovery’, choisir ‘recovery scope = datafile’ , clic ‘recover’, clic ‘Next’, clic ‘Next’ et ‘Submit’.
C’est fini ;-(

En 2 commandes

On va voir ici comment récupérer un fichier perdu…sans savoir lequel ni connaitre RMAN !
En fait 2 commandes suffisent : ADVISE FAILURE et REPAIR FAILURE. C’est tout bonnement miraculeux ca s’appelle Data Recovery Advisor !

Supposons qu’on ait donc perdu un datafile.
Au bout d’un moment (si, si) Oracle va finir par s’en apercevoir et on aura une erreur ORA-1157.
Oracle ERROR at line 1:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: ‘/tmp/dd.dbf’ DATAFILE

Les étapes de restauration sont très simples grace à DATA RECOVERY ADVISOR disponible avec Oracle 11g.
Concrètement ce Data recovery advisor consiste en qq commandes que l’on pourra lancer sous RMAN.

3 commandes utiles :

RMAN> LIST FAILURE : liste les pbs en cours détectés (fichiers manquents, corrompus, etc…)

RMAN> ADVISE FAILURE : propose des solution de recovery et produit un script associé

RMAN> REPAIR FAILURE : execute le script de récupération

Voici un exemple concret :

Connexion a RMAN

$> rman target sys@portab2-a-dd:1521/DD1.dd.com
connected to target database: DD1 (DBID=1767735647, not open)
RMAN>

Recherche de problemes éventuels :

RMAN> list failure;
using target database control file instead of recovery catalog
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
1242 HIGH OPEN 23-JUL-10 One or more non-system datafiles are missing

Ou si l’on souhaite avoir des infos plus détaillées sur le problème on utilise l’ID qui nous intéresse , ici 1242

RMAN> list failure 1242 detail;

List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
1242 HIGH OPEN 23-JUL-10 One or more non-system datafiles are missing
Impact: See impact for individual child failures
List of child failures for parent failure ID 1242
Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
1245 HIGH OPEN 23-JUL-10 Datafile 6: ‘/tmp/dd.dbf’ is missing
Impact: Some objects in tablespace DD might be unavailable

En suite la partie Assistance / conseil proprement dite (ADvisor) :

RMAN> advise failure;

analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=155 device type=DISK
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
1. If file /tmp/dd.dbf was unintentionally renamed or moved, restore it
Automated Repair Options
========================
Option Repair Description
—— ——————
1 Restore and recover datafile 6
Strategy: The repair includes complete media recovery with no data loss
Repair script: /oracle/diag/rdbms/dd1/DD1/hm/reco_1841908370.hm

On peut dès lors récupérer le fichier de données effacé en une étape :

RMAN> REPAIR FAILURE

Ou si l’on veut mieux maitriser ce que l’on fait, visualiser le script et lancer les étapes de restauration et recovery manuellement :

Vérification du script généré :

$> more /oracle/diag/rdbms/dd1/DD1/hm/reco_1841908370.hm
# restore and recover datafile
restore datafile 6;
recover datafile 6;

Restauration (récupération) du fichier perdu à partir des Backups Sets de la sauvegarde RMAN :

RMAN> restore datafile 6;

Starting restore at 23-JUL-10
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00006 to /tmp/dd.dbf
channel ORA_DISK_1: reading from backup piece /oracle/flash_recovery_area/DD1/DD1/backupset/2010_07_22/o1_mf_nnnd1_BACUP_INCR_DEL_BAC_0_64jlhkvc_.bkp
channel ORA_DISK_1: piece handle=/oracle/flash_recovery_area/DD1/DD1/backupset/2010_07_22/o1_mf_nnnd1_BACUP_INCR_DEL_BAC_0_64jlhkvc_.bkp tag=BACUP_INCR_DEL_BAC_072210033828
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 23-JUL-10

Récupération de données supplémentaires et synchronisation des fichiers si nécessaire :

RMAN> recover datafile 6;

Starting recover at 23-JUL-10

using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 23-JUL-10

Oracle Transparent data encrytion (TDE) , tutoriel

Sécurité Oracle pas de Commentaire »

TDE  (Transparent Data Encryption) permet comme son nom l’indique le chiffrement transparent des données d’une table ou d’un Tablespace.
Transparent cette modification qui peut être faite à priori ou a posteriori ne nécessite aucune modification du code des programmes.
Techniquement l’authentification nécessaire à la lecture des données non cryptées est faite par un fichier externe associé à la base , un ‘Wallet’ Oracle.

Il permet d’éviter que des utilisateurs malveillants accèdent aux données OFFLINe, c’est à dire aux données stockées physiquement dans les fichiers en court-circuitant SQL.

Une simple commande Unix
$> strings mon_fichier.dbf
suffit à voir les données ASCII en clair. ce qui pour les CHAR et VARCHAR est très pratique.

Nous allons  détailler ici les étapes necessaires à la mise en place du chiffrement de données sur les colonnes d’une table. Bonne lecture.

1) création d’un Wallet.

Lancer OWM : Wallet /new donner un pwd, ne pas creer de certificat de securite additionnel
ignorer les warning
sauvegarder le wallet dans une directory accessible

On peut vérifier au niveau de l’OS la création d’un fichier wallet :
$> ls -l /data/pprqu/wallet
-rw——-  1 oracle dba 7917 2010-07-02 11:07 ewallet.p12

2) configurer la  base pour utiliser le wallet
rajouter dans sqlnet.ora ($ORACLE_HOME/network/admin/sqlnet.ora)
l’emplacement du Wallet.

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /data/pprqu/wallet)
)
)

tester la validité des paramaetres avec un eventuel
$> lsnrctl reload

3) ouvrir le Wallet

SQL> ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY  “mmxlv3ipu”;
– Attention aux guillemets !!!!!!!!!!!
– sensible à la casse en plus !!! (11g style !)

rem : on peut eviter cette ouverture manuelle à chaque redémarrage de la base, avec un AUTOLOGIN WALLET

4) créer le mot de passe de la clé de chiffrement principale

SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “mmxlv3ipu”

!!!!!!!!!!!! doit etre le meme mot de passe sinon :
ORA-28353: failed to open wallet

L’Algorithme de chiffrement par défaut est AES192. On peut en choisir d’autres plus ou moins complexes …voir la doc.

rem : cette commande est valide tant que la base n’est pas redémarrée…

5) chiffrer la colonne confidentielle

SQL> alter table emp_cryptee modify( ename encrypt)
Table altered.

Principes de base sécurité Oracle

Divers, Sécurité Oracle pas de Commentaire »

Les principaux sont expliqués ici :

Droits sur les procédures et packages (Sécurité Oracle)

Sécurité Oracle pas de Commentaire »

Il existe 2 types gestion des droits des procédures (et fonctions et packages bien sûr)
Procédure avec Droits du propriétaire ou Procédure avec droits de celui qui lance la procédure.
Respectivement DEFINER’S RIGHT Procedure et INVOKER’S Right procedure.

Nous allons étudier dans cet article les DEFINER’s RIGHT .

Par défaut une procédure stockée s’exécute avec les droits du propriétaire, et non les droits de celui qui l’exécute !
Ceci implique que, par défaut l’exécuteur n’a pas besoin de droits particuliers sur les objets sous jacents, mais juste le droit d’exécuter la procédure !
Ces procédures ont la visibilité par défaut des objets du propriétaire, et pas de celui qui lance la procédure.
Et dernier point : LES ROLES NE SONT PAS SUPPORTéS !!!!

————————————————————-
1er cas simple :
une procédure (PDD) appartenant a DD, accede à une table de DD (TDD).
Cette procédure est utilisée par SCOTT.

SQL> connect DD
SQL> CREATE TABLE tdd (n integer);
SQL> create or replace PROCEDURE PDD AS
BEGIN
INSERT INTO tdd values (1);
END;
SQL> GRANT EXECUTE ON pdd TO scott;
SQL> connect SCOTT
SQL> CREATE SYNONYM pdd for dd.pdd
SQL> EXECUTE PDD
—> OK !!

rem : créer un synonyme pour la procédure est obligatoire ici (?!) car Oracle cherche l’objet
dans le shema courant..et il n’existe pas de DD.PDD dans SCOTT.
Le synonyme est lui traduit sans ambiguité.
- un EXECUTE DD.PDD donnerait:
erreur : ORA-06550: line 1, column 10:
PLS-00302: component ‘PDD’ must be declared

rem: il est à noter également que les objets accédés par la procédure sont implicitement
ceux du schéma propriétaire :
Bien que ce soit SCOTT qui appelle la procédure,
TDD référence un objet de DD
(sans avoir a le préfixer et même si SCOTT avait aussi une table qui s’appelle TDD !!!!)

————————————————————-
2eme cas simple :
une procédure (PDD) appartenant a DD, accede à une table de SCOTT (TSCOTT)

L’exécuteur n’étant pas le propriétaire de l’objet accédé il a donc besoin de droits explicites.

A) droit direct

SQL> connect SCOTT/TIGER
CREATE TABLE tscott (n INTEGER);
GRANT INSERT ON tscott to DD;

SQL> connect DD/DD
create or replace PROCEDURE PDD AS
BEGIN
INSERT INTO SCOTT.TSCOTT values (1);
END;

EXECUTE pdd –> OK !

B) via un role

SQL> REVOKE INSERT ON tscott FROM DD;
SQL> CREATE ROLE inscott;
SQL> GRANT INSERT ON scott.tscott TO inscott;

l’execution du package le rend invalide et sa recompilation nous donne plus de précisions :

SQL> CONNECT dd/dd
EXECUTE pdd

ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00905: object DD.PDD is invalid
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

SQL> ALTER PROCEDURE pdd COMPILE
Error
PL/SQL: SQL Statement ignored
PL/SQL: ORA-00942: table or view does not exist

CQFD les roles ne sont pas supportés.

securite-oracle-Droits systeme

Divers, Sécurité Oracle pas de Commentaire »

Privilèges système
Les privilèges systèmes d’accès aux objets s’intéressent plutôt au contenant qu’au contenu. Ils concernent principalement des ordres de création, de modification de structure et de suppression d’objets (SQL DDL plutot que DML)

Ce sont donc des privilèges d’assez haut niveau, que l’on réservera par exemple aux développeurs mais qui seront utilisés avec beaucoup de parcimonie en phase de production…

Liste de quelques privilèges système d’Oracle

Nom
du privilege
Type
d’action autorisée
ANALYZE
ANALYZE ANY
Analyser
toutes les tables, clusters, ou indexs
dans
la base de données.
AUDIT
AUDIT ANY
Auditer tous
les objets dans la base de données.
AUDIT SYSTEM
Auditer les
actions de type DBA
CLUSTER
CREATE CLUSTER
créer un
cluster .
CREATE ANY
CLUSTER
créer un
cluster dans tous les schémas.
ALTER ANY
CLUSTER
Modifier
tous les cluster dans la base de données.
DROP ANY
CLUSTER
Supprimer
tous les cluster dans la base de données.
DATABASE
ALTER DATABASE
Modifier
la structure physique de la base
DATABASE
LINK
CREATE DATABASE
LINK
Créer
des database links privés.
INDEX
CREATE ANY
INDEX
créer un
index dans tous les schemas sur toutes les tables.
ALTER ANY
INDEX
Modidier
tous les index dans la base de données.
DROP ANY
INDEX
Supprimer
tous les index dans la base de données.
PRIVILEGE
GRANT ANY
PRIVILEGE
Donner tous
les privileges système
PROCEDURE
CREATE PROCEDURE
Créer
des procedures stockées, fonctions, et packages .
CREATE ANY
PROCEDURE
Créer
des procedures stockées, fonctions, et packages dans tous les schemas.
(suppose ALTER ANY TABLE, BACKUP ANY TABLE, DROP ANY TABLE, SELECT ANY TABLE,
INSERT ANY TABLE, UPDATE ANY TABLE, DELETE ANY TABLE, ou GRANT ANY TABLE.)
ALTER ANY
PROCEDURE
Compiler
toutes les procedures stockées, fonction, ou packages dans tous les
schemas.
DROP ANY
PROCEDURE
Supprimer
toutes les procedures, function, ou package stockés dans tous les
schema.
EXECUTE ANY
PROCEDURE
Executer
toutes les procedures ou functions dans tous les schema.
PROFILE
CREATE PROFILE
Créer
des profils.
ALTER PROFILE
Modifier
tous les profils dans la base de données.
DROP PROFILE
Supprimer
tous les profils dans la base de données.
ALTER RESOURCE
COST
Modifier
la ressource ‘cost’ dans toutes les sessions.
PUBLIC
DATABASE LINK
CREATE PUBLIC
DATABASE LINK
Créer
des database links publics.
DROP PUBLIC
DATABASE LINK
Supprimer
database links publics.
PUBLIC
SYNONYM
CREATE PUBLIC
SYNONYM
Créer
des synonyms publics.
DROP PUBLIC
SYNONYM
Supprimer
des synonyms publics.
ROLE
CREATE ROLE
Créer
des roles.
ALTER ANY
ROLE
Modifier
tous les roles dans la base de données.
DROP ANY
ROLE
Supprimer
tous les roles dans la base de données.
GRANT ANY
ROLE
Grant tous
les roles dans la base de données.
ROLLBACK
SEGMENT
CREATE ROLLBACK
SEGMENT
Créer
des rollback segments.
ALTER ROLLBACK
SEGMENT
Modifier
des rollback segments.
DROP ROLLBACK
SEGMENT
Supprimer
des rollback segments.
SESSION
CREATE SESSION
Se connecter
!!!
ALTER SESSION
faire des
ALTER SESSION .
RESTRICTED
SESSION
Se connecter
malgré un démarrage ‘RESTRICT’. (OSOPER et OSDBA donnent ce
privilege.)
SEQUENCE
CREATE SEQUENCE
crée une
sequence dans son schema.
CREATE ANY
SEQUENCE
Créer
toutes les sequences dans tous les schemas.
ALTER ANY
SEQUENCE
Modifier toutes
les sequence dans tous les schémas.
DROP ANY
SEQUENCE
Supprimer toutes
les sequence dans tous les schémas.
SELECT ANY
SEQUENCE
Reference
toutes les sequence dans tous les schémas.
SNAPSHOT
CREATE SNAPSHOT
Créer
des snapshots (clichés) dans son schema
.
(l’utilisateur doit aussi avoir le privilege CREATE TABLE.)
CREATE SNAPSHOT
Créer
des snapshots dans tous les schémas.
(
CREATE ANY TABLE nécessaire.)
ALTER SNAPSHOT
Modifier
tous les snapshots dans tous les schémas.
DROP ANY
SNAPSHOT
Supprimer
tous les snapshots dans tous les schémas.
SYNONYM
CREATE SYNONYM
créer un
synonym dans son schema.
CREATE SYNONYM
Créer
tous les synonyms dans tous les schémas.
DROP ANY
SYNONYM
Supprimer
tous les synonyms dans tous les schémas.
SYSTEM
ALTER SYSTEM
faire des
ALTER SYSTEM .
TABLE
CREATE TABLE
Créer
des tables ou des indexs dans son propre schéma
CREATE
ANY TABLE
Créer
des tables dans tous les schémas.
ALTER ANY
TABLE
Modifier
toutes les table dans tous les schémas et compiler toutes les vues dans
tous les schémas.
BACKUP ANY
TABLE
Réaliser
des exports incrémentaux.
DROP ANY
TABLE
Supprimer
ou vider toutes les table dans tous les schémas.
LOCK ANY
TABLE
Verrouiller
toutes les tables ou vues dans tous les schémas.
COMMENT ANY
TABLE
Commenter
toutes les tables, vues, ou colonnes dans son schema.
SELECT ANY
TABLE
Interroger
toutes les tables, vues, ou clichés dans tous les schémas.
INSERT ANY
TABLE
Insert rows
into toutes les table ou view dans tous les schémas.
UPDATE ANY
TABLE
Update rows
in toutes les table ou view dans tous les schémas.
DELETE ANY
TABLE
Delete rows
from toutes les table ou view dans tous les schémas.
TABLESPACE
CREATE TABLE
SPACE
Créer tablespaces;
add files to the operating system via Oracle, regardless of the l’utilisateur’s
operating system privileges.
ALTER TABLESPACE
Modifier tablespaces;
add files to the operating system via Oracle, regardless of the l’utilisateur’s
operating system privileges.
MANAGE TABLESPACE
Take toutes
les tablespace offline, bring toutes les tablespace online, et begin et
end backups of toutes les tablespace.
DROP TABLESPACE
Supprimer tablespaces.
UNLIMITED
TABLESPACE
Use an unlimited
amount of toutes lestablespace. This privilege overrides toutes les
specific quotas assigned. If revoked, the grantee’s schema objects remain
but further tablespace allocation is denied unless allowed by specific tablespace
quotas. This system privilege can be granted only to l’utilisateurs et
not to roles. In general, specific tablespace quotas are assigned instead
of granting this system privilege.
TRANSACTION
FORCE TRANSACTION
Fouce the
commit ou rollback of own in-doubt distributed transaction in the local
database.
FORCE ANY
TRANSACTION
Fouce the
commit ou rollback of toutes les in-doubt distributed transaction in the
local database.
TRIGGER
CREATE TRIGGER
crée un trigger
in own schema.
CREATE ANY
TRIGGER
Créer toutes
les trigger dans tous les schémas associated with toutes les table dans
tous les schémas.
ALTER ANY
TRIGGER
Enable, disable,
ou compile toutes les trigger dans tous les schémas.
DROP ANY
TRIGGER
Supprimer toutes
les trigger dans tous les schémas.
USER
CREATE ANY
USER
Créer l’utilisateurs;
assign quotas on toutes les tablespace, set default et tempouary
tablespaces, et assign a profile as part of a CREATE USER statement.
BECOME ANY
USER
Become another
l’utilisateur. (Required by toutes les l’utilisateur perfouming a full database
impout.)
ALTER USER
Modifier other
l’utilisateurs: change toutes les l’utilisateur’s passwoud ou authentication
method, assign tablespace quotas, set default et tempouary tablespaces,
assign profiles et default roles, in an ALTER USER statement. (Not required
to alter own passwoud.)
DROP USER
Supprimer another
l’utilisateur.
VIEW
CREATE VIEW
crée un view
in own schema.
CREATE ANY
VIEW
crée un view
dans tous les schémas. (Requires that l’utilisateur also have ALTER ANY
TABLE, BACKUP ANY TABLE, DROP ANY TABLE, LOCK ANY TABLE, COMMENT ANY TABLE,
SELECT ANY TABLE, INSERT ANY TABLE, UPDATE ANY TABLE, DELETE ANY TABLE,
ou GRANT ANY TABLE.)
DROP ANY
VIEW
Supprimer toutes
les view dans tous les schémas.

Changer le mot de passe de DBSNMP en 9iDB

Sécurité Oracle pas de Commentaire »

Le compte DBSNMP présent par défaut sur les bases Oracle, peut être facilement exploiter pour accéder ? des données.

Ce compte est nécessaire pour pour pouvoir utiliser les agents de la console Oracle Enterprise Manager ou de la Grid console.

Pour des raisons de sécurité, il est important de changer le mot de passe par défaut qui vaut DBSNMP !!!!) mais en respectant la procédure suivante :
Changement de Mot de passe pour DBSNMP

1] Arreter l’agent
Oracle7 - Oracle8i
% lsnrctl dbsnmp_stop

Oracle9i
% agentctl stop

2] Editer le $ORACLE_HOME/network/admin/snmp_rw.ora file
Rajouter les parametres suivants :

snmp.connect.{SID}.NAME = dbsnmp
snmp.connect.{SID}.PASSWORD = {new password}

Sous UNIX, pensez ? donner la permission suivante au fichier SNMP_RW.ORA

% chmod 600 snmp_rw.ora

3] Changez le mdp de DBSNMP dans la base avec la commande
La 2ieme commande a le mérite de ne pas avoir de traces en clair dans le sqlnet.trc.

SQL> alter user “dbsnmp” identified by “”;

SQL> password DBSNMP
Modification de mot de passe pour dbsnmp
Nouveau mot de passe : *******
Ressaisir le nouveau mot de passe : *******
Mot de passe modifié

4] Redemarrez l’agent
En 10g le simple fait de changer l’agent comme ? l’étape 3, arrête la collecte des informations et vous propose de changer le mot de passe.

Row Level Security (RLS) …un peu plus loin

Divers, Sécurité Oracle 1 Commentaire »

DEMO de la sécurité au niveau LIGNE avec Oracle 10g
(A.K.A Row Level Security / RLS / Fine Grained Access Control / VPDs)

Le but de cette demo est de mettre en place une strategie sur la table
SCOTT.EMP, qui s’appuie sur un contexte utilisateur, défini de manière automatique..
Un user ne devra voir que la (les) ligne’s) qui le concerne dans la table,
même en faisant un ‘SELECT * FROM emp’.
ex : KING ne voit que la ligne de KING, CLARK la ligne de CLARK.
On créera un user Oracle ‘CLARK’ présent dans la table des employés,
pour tester les filtres appliqués au user connecté.

—————————-
– 0) Environnement de TEST
—————————-
– en tant que SYS

– créer un user spécifique pour mettre en place la sécurié
CREATE USER sec IDENTIFIED BY nbvcxw;
– les privileges minimum necessaire pour DEV1
GRANT CREATE SESSION, CREATE TABLE, CREATE PROCEDURE,
CREATE ANY CONTEXT TO sec;
GRANT EXECUTE ON DBMS_RLS TO sec;
GRANT EXECUTE ON DBMS_SESSION TO sec;
– rem on peut remplacer les 2 precedents par un
– GRANT EXECUTE_CATALOG_ROLE TO dev1 (moins ciblé / sécurisé)
CREATE USER clark IDENTIFIED BY clark;
GRANT CREATE SESSION TO clark;
GRANT SELECT ON scott.emp TO PUBLIC;
GRANT EXECUTE ON sec.pack_contexte_emp TO PUBLIC; (pour debug)
GRANT EXECUTE ON filtre_emp TO PUBLIC; (pour debug)

—————————
– 1) déclarer le contexte
—————————

CONNECT sec/nbvcxw
CREATE OR REPLACE CONTEXT contexte_employe
USING pack_contexte_emp;

——————————————————————————–
– 2) definir le contexte applicatif (code du package et attributs du contexte)
——————————————————————————–

– ici c’est le no d’emp et le niveau (chef ou nom)
– qui determineront les privileges d’acces ? l’applicatif

– les specs du package :

CREATE OR REPLACE PACKAGE pack_contexte_emp
AS
PROCEDURE def_contexte;
END;

– le corps du package :

CREATE OR REPLACE PACKAGE BODY pack_contexte_emp
IS
PROCEDURE def_contexte
IS
v_empno NUMBER;
nb_subordonnes NUMBER;
BEGIN

– on recupere le no de l’employe et sa fonction (chef ou non)
– et on definit les attributs du contexte en consequence
– le ‘NAMESPACE’ ‘contexte_employe’ a donc 2 attributs ici
– on ne se sert que du premier dans cet exemple…

– d’abord le no d’emp
– en utilisant le ‘SESSION_USER’ de SYS_CONTEXT
– equivallent a un SELECT username FROM dual
– rem : si le user n’apparait pas dans la table –> no data found (a trapper)

SELECT empno INTO v_empno FROM scott.emp
WHERE ename = SYS_CONTEXT(’USERENV’, ‘SESSION_USER’);

DBMS_SESSION.SET_CONTEXT(’contexte_employe’, ‘no_emp’, v_empno);

– puis son niveau de responsabilite : chef ou non
– si oui son no d’emp est le no de manager de quelqu’un…

SELECT COUNT(*) INTO nb_subordonnes
FROM scott.emp
WHERE mgr= v_empno;
IF (nb_subordonnes <> 0) THEN
DBMS_SESSION.SET_CONTEXT(’contexte_employe’, ‘niveau’, ‘chef’);
ELSE
DBMS_SESSION.SET_CONTEXT(’contexte_employe’, ‘niveau’, ‘employe’);
END IF;

END def_contexte;
END pack_contexte_emp;

– test

select SYS_CONTEXT(’USERENV’, ‘SESSION_USER’) from DUAL
exec sec.pack_contexte_emp.def_contexte

———————————————-
– 3) definir les fonctions limitant les acces
———————————————-

– la ou les fonctions vont retourner une chaine
– qui sera ajoutee a la clause WHERE (predicat supplementaire)
– on utilise le contexte ‘employe’ pour identifier le user

CREATE OR REPLACE PACKAGE filtre_emp
AS
FUNCTION vue_emp (owner VARCHAR2, objname VARCHAR2)
RETURN VARCHAR2;
END;

CREATE OR REPLACE PACKAGE BODY filtre_emp
IS
FUNCTION vue_emp (owner VARCHAR2, objname VARCHAR2)
RETURN VARCHAR2
IS
predicat VARCHAR2(1000);
BEGIN
predicat := ‘empno=SYS_CONTEXT(”contexte_employe”,”no_emp”)’;
RETURN predicat;
END;
END;

– test

SELECT SYS_CONTEXT(’contexte_employe’,'no_emp’) FROM dual
SELECT sec.filtre_emp.vue_emp(’SCOTT’,'EMP’) FROM dual

————————————————————
– 4) creer stratégie d’acces (policy) attachée a la table
————————————————————

DBMS_RLS.ADD_POLICY (proprietaire_objet,nom_objet,nom strategie,proprietaire strategie,fonction_filtre, SQL_concerne) :
execute DBMS_RLS.ADD_POLICY (’scott’, ‘emp’, ‘policy_emp’,’sec’, ‘filtre_emp.vue_emp’, ‘SELECT’);

(si necessaire
DBMS_RLS.DROP_POLICY (nom_owner, nom_table, nom_police) :
execute DBMS_RLS.DROP_POLICY (’scott’, ‘emp’, ‘policy_emp’); )

–test

select * from sys.rls$ where PFSCHMA=’DEV1′;
OBJ# GNAME PNAME STMT_TYPE CHECK_OPT ENABLE_FLAG PFSCHMA PPNAME PFNAME PTYPE
52606 SYS_DEFAULT POLICY_EMP 513 0 1 DEV1 FILTRE_EMP VUE_EMP

———————————————————————
– 5) activer le contexte, avant l’acces aux données des utilisateurs
———————————————————————
– manuellement (ou géré par l’applicatif)
connect clark/clark
exec sec.pack_contexte_emp.def_contexte;

– ou automatiquement par un trigger, en tant que DBA !!

CREATE OR REPLACE TRIGGER dev1.active_contexte_emp
AFTER LOGON ON DATABASE
BEGIN
sec.pack_contexte_emp.def_contexte;
END;

——————-
– 6) Test VPD
——————-

SQL> connect clark/clark
SQL> select * from emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
—– —– ——– —- ——– —- —- ——
7782 CLARK MANAGER 7839 09/06/81 2450 10

SQL> connect system/xdcfvgh
SQL> select * from emp;
aucune ligne sélectionnée.

et sans la VPD :

SQL> execute DBMS_RLS.DROP_POLICY (’dev1′, ‘emp’, ‘policy_emp’);
ou moins violent :
SQL> grant exempt access policy to DEV1;
SQL> connect dev1/dev1
SQL> select * from emp;EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
—– ———- ——— ———- ——– ———- —– ——
7369 SMITH CLERK 7902 17/12/80 800 20
7499 ALLEN SALESMAN 7698 20/02/81 1600 300 30
7521 WARD SALESMAN 7698 22/02/81 1250 500 30
7566 JONES MANAGER 7839 02/04/81 2975 20
7654 MARTIN SALESMAN 7698 28/09/81 1250 1400 30
7698 BLAKE MANAGER 7839 01/05/81 2850 30
7782 CLARK MANAGER 7839 09/06/81 2450 10
7788 SCOTT ANALYST 7566 19/04/87 3000 20
7839 KING PRESIDENT 17/11/81 5000 10
7844 TURNER SALESMAN 7698 08/09/81 1500 0 30
7876 ADAMS CLERK 7788 23/05/87 1100 20
7900 JAMES CLERK 7698 03/12/81 950 30
7902 FORD ANALYST 7566 03/12/81 3000 20
7934 MILLER CLERK 7782 23/01/82 1300 10
1111 DEV1 Engineer 7782 01/01/07 2000 10

15 ligne(s) selectionnee(s).

L’erreur ORA-28112

l’utilisation des policies déclenche parfois une erreur ORA-28112 , même si les polices sont correctes et les packages aussi.
Voir le musée des erreurs - erreur ORA-28112 ” Failed to execute policy function ”

——-
Notes
——-

1) Pourquoi un compte SEC spécifique pour les objets nécessaire ? la VPD ?
- c’est + sécurisé, les données ne sont pas mélangées avec les règles d’accès
- c’est + facile a debugger : on peut soustraire ce compte aux règles des VPDs
- on évite les pbs d’accès récursif de la VPD

2) les parametres des fonctions de filtre sont OBLIGATOIRES !

3) Les DBAs soont normalement soumis aux stratégies comme tous les autres users.
Il est néanmoins possible d’outrepasser les VPDs
(pour le deboggage, pour l’administration, ou pour eviter les pbs de récursion)
SQL> grant exempt access policy to nom_user_cible;

4) une ORA-28112 = echec d’execution de la fonction de regle, lors du SELECT
==> la fonction est OK, mais il y a une exception qui n’est pas trappée par la fonction.
voir le fichier trace généré par l’erreur dans le répertoire USER_DUMP_DEST
pour résoudre le problème

5) vues du referentiel utiles
%_POLICIES, V$VPD_POLICY, RLS$, v$SQL

6) ne pas confondre les policies générales et les policies utilisées pour l’audit (Fine Grain Auditing).
Les packages, procédures et vues du dictionnaire ne sont pas les mêmes !
exemple : les packages DBMS_RLS (généraux) et DBMS_FGA (audit)

7) il n’existe pas de DISABLE_POLICY en 9i !!! mais un DBMS_RLS.ENABLE_POLICY avec ENABLE=….FALSE !!!

Introduction a la Sécurité au niveau ligne (RLS)

Divers, Sécurité Oracle pas de Commentaire »

Les prémices

Le principe de base des accès au données Oracle, s’appelle le ‘Discretionary Access Control’ ou DAC.
Il s’appuie sur des privilèges d’accès aux objets donnés aux utilisateurs concernés, grace ? la commande SQL ‘GRANT’.
Ainsi on donne ? Mr Clark le droit de consulter la table EMP de SCOTT, par la commande
GRANT SELECT ON scott.EMP TO clark’.
Ce controle d’accès ne gère pas de niveau plus fin que la table complète : soit CLARk ? a l’accès ? la totalité de la table ou ? aucune de ses lignes…
Ceci peut être affiné en utilisant des vues.
On peut limiter l’accès ? un niveau plus fin, par exemple autoriser CLARK ? ne lire que la ou les lignes qui le concerne, en créant une vue avec prédicat :

SQL> CREATE VIEW v_emp AS SELECT * FROM scott.emp
WHERE ename=user;
SQL> CONNECT clark/clark
SQL> SELECT * FROM scott.v_emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
7782 CLARK MANAGER 7839 09-JUN-81 2450 10

Ceci peut néanmoins dans certains être contourné si Mr Clark iu d’autres utilisateurs accèdent directement ? la table sous jacente EMP.
La sécurité au niveau ligne (RLS) ou l’accès au niveau fin (Fine Grain Access Control ou FGAC)

sont une solution complètement ttransparente pour tous les users, ? ce type de besoin.
Faire du RLS (FGAC) nécessite
- 1 fonction predicat, qui limite les accès ? certaines lignes
Cette fonction, a 2 paramètres obligatoires (le proprietaire et le nom de l’objet filtré) et retourne

une chaine qui contient une expression booleenne.
- 1 strategie (policy) attachée ? la table qui met en oeuvre automatiquement cette fonction.
cette strategie, a un nom et doirt preciser l’objet filtré et la fonction utilisée.
Les stratégies sont gérées par un package prédéfini appelé DBMS_RLS. Le créateur de la startégie doit

donc avoir les droits d’EXECUTE sur ce package.
Pour la création on utilisera par exemple DBMS_RLS.ADD_POLICY(…)

Dans un Schmé sécurité (compte SEC) cela nous donne :

création de la fonction prédicat et de la stratégie

SQL> CONNECT sec/sec
SQL> CREATE OR REPLACE PACKAGE filtre_emp
AS
FUNCTION vue_emp (owner VARCHAR2, objname VARCHAR2)
RETURN VARCHAR2;
END;

SQL> CREATE OR REPLACE PACKAGE BODY filtre_emp
IS
FUNCTION vue_emp (owner VARCHAR2, objname VARCHAR2)
RETURN VARCHAR2
IS
predicat VARCHAR2(1000);
BEGIN
predicat := ‘ename=user’;
RETURN predicat;
END;
END;

– si nécessaire
execute DBMS_RLS.DROP_POLICY (’scott’, ‘emp’, ‘policy_emp’);
– et on crée donc…
execute DBMS_RLS.ADD_POLICY (’scott’,'emp’,'policy_emp’,’sec’,'filtre_emp.vue_emp’, ‘SELECT’);

Démontration du résultat de la stratégie mise en place

SQL> CONNECT clark/clark
SQL> SELECT COUNT(*) FROM scott.emp;
–> 1
SQL> CONNECT system/xxxx
SQL> SELECT COUNT(*) FROM scott.emp;
–> …
no row selected
car tout le monde est a priori sousmis ? la stratégie de sécurité !
y compris le DBA, et comme son nom d’utilisateur n’apparait pas dans la table EMP de SCOTT, le prédicat renvoie un résultat faux…et aucune ligne n’est affichée.

Nous verrons dans un prochain article comment créer une ébauche de VPD en associant ? cette stratégie un contexte utilisateur.

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…

Sécurité Oracle 10g: Les rôles

Divers, Sécurité Oracle 4 Commentaires »

Les rôles
———

Il n’existe pas de notion de groupes d’utilisateur sous Oracle, mais la notion de rôle, qui permet de nommer un

groupe de privilèges. On peut affecter un rôle ? un ou n utilisateurs, voir ? un rôle.

Roles prédéfinis
—————-

Il existe un certain nombre de rôles prédéfinis, fournis avec Oracle 10g. Voici une liste de ces rôles avec les

privilèges système qu’ils offrent :
CONNECT :
Se connecter ! équivallent du privilède système ‘CREATE SESSION’

Attention !!! en version 10gR1 et antérieures, ce rôle donnait beaucoup + de privilèges, ? savoir :
ALTER SESSION, CREATE CLUSTER, CREATE DATABASE LINK, CREATE SEQUENCE,
CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE VIEW
RESOURCE :
créer des données avec des quotas sur tous les tablespaces ->
CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE,
CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE

DBA :
Tous les privilèges système avec ADMIN OPTION

EXP_FULL_DATABASE :
export complet ou incrémental ->
SELECT ANY TABLE, BACKUP ANY TABLE, EXECUTE ANY PROCEDURE, EXECUTE ANY TYPE, ADMINISTER RESOURCE MANAGER, and

INSERT, DELETE, and UPDATE on the tables SYS.INCVID, SYS.INCFIL, and SYS.INCEXP. Also the following roles:

EXECUTE_CATALOG_ROLE and SELECT_CATALOG_ROLE.

IMP_FULL_DATABASE :
import full + tous les privilèges système + role

DELETE_CATALOG_ROLE :
droit DELETE sur la table SYS.AUD$

EXECUTE_CATALOG_ROLE : privilège EXECUTE sur les objets du dictionnaire + HS_ADMIN_ROLE.

SELECT_CATALOG_ROLE : accès en consultation au dictionnaire + HS_ADMIN_ROLE.

RECOVERY_CATALOG_OWNER : privilèges pour le propriétaire du catalogue de restauration ->
CREATE SESSION, ALTER SESSION, CREATE SYNONYM, CREATE VIEW, CREATE DATABASE LINK,
CREATE TABLE, CREATE CLUSTER, CREATE SEQUENCE, CREATE TRIGGER, and CREATE PROCEDURE

HS_ADMIN_ROLE
protection des accès (SELECT et EXECUTE) au référentiel HS (Heterogeneous Services) data dictionary tables

(grants SELECT) and packages
AQ_ADMINISTRATOR_ROLE
privilèges d’administration de l’ Advance Queuing. Notamment : ENQUEUE ANY QUEUE, DEQUEUE ANY QUEUE, et MANAGE

ANY QUEUE + SELECT sur les tables AQ + EXECUTE sur les packages AQ.

roles applicatifs
—————–
Des roles définis pour les applicatifs, en fonction des besoins et ? minima !
Ainsi on peut créer un rôle qui donne des droits de consultation sur les tables d’un schéma :

– creation du role
SQL> create role consult_finance;
– affectation des privileges au role
SQL> grant select on budget to consult_finance;
SQL> grant select on fournisseur to consult_finance;
SQL> grant select on client to consult_finance;
– cession du role aux utilisateurs
SQL> grant consult_finance to user_finance_1;
SQL> grant consult_finance to user_finance_2;

Note : un user ne peut pas hériter de plus de ‘MAX_ENABLED_ROLES’ paramètre d’initialisation de la base, dont la valeur par défaut est 30 en 10g. CEla parait peu probable pour un applicatif classique (voire déraisonnable).
Dans le cas d’une console d’administration centrale (console 10g GRID ou server manager console). Le user d’administration cionnecté hérite de tous les droits qu’il crée…ce qui est beaucoup plus fréquent ! et la limite MAX_ENABLED_ROLES peut être facilement atteinte et … empêcher une connexion ? la console !
Informations sur les rôles dans le référentiel (dictionnaire) Oracle 10g
————————————————————————

DBA_ROLES
Tous les roles !
DBA_ROLE_PRIVS, USER_ROLE_PRIVS
roles données aux users et/ou aux roles
ROLE_ROLE_PRIVS
roles donnés aux roles
ROLE_SYS_PRIVS
privilèges systèmes donnés aux roles (accessible au user)
ROLE_TAB_PRIVS
privilèges objets donnés aux roles (accessible au user)
SESSION_PRIVS
privilèges de la session courante
SESSION_ROLES
roles de la session courante

Les roles et la console GRID 10g
———————————

La console donne par defaut le role CONNECT, cela ne pose pas de pb de sécurité sur une base 10g…mais si on s’en sert pour administrer une base 9i (avec l’agent qui va bien) le role CONNECT offre presque tous les privilèges de création/suppression de données dans le schéma.

Problèmes classiques sur les droits : 0RA-00942 , ORA-01031

Divers, Sécurité Oracle pas de Commentaire »

————————————————–
– une vue de BLAKE sur une table de SCOTT
————————————————–
connect scott
(scott a les droits sur la table)
create view vscott as select * from emp

connect blake
select * from scott.vscott
*
ERROR at line 1:
ORA-00942: table or view does not exist

connect scott
grant select on emp to blake

…le droit sur la table sert pour accéder …a la table
connect blake
select * from scott.vscott
*
ERROR at line 1:
ORA-00942: table or view does not exist

…Le droit sur la vue suffit
connect scott
grant select on vscott to blake

connect blake
select * from scott.vscott
–> OK

———————————————————
—KING accede a une vue de BLAKE sur une table de SCOTT
———————————————————
connect SYSTEM
grant select on scott.emp to blake;
create view blake.vblake as select * from scott.emp
connect SYSTEM
SQL> grant select on blake.vblake to king;
Autorisation de privilèges (GRANT) acceptée.
connect KING
select * from blake.vblake
*
ERROR at line 1:
ORA-01031: insufficient privileges

Si on avait tenté de donner les droits en tant que BLAKE
cela aurait été plus clair :
connect blake
grant select on blake.vblake to king
*
ERROR at line 1:
ORA-01720: grant option does not exist for ‘SCOTT.EMP’

LA SOLUTION
connect SCOTT (ou SYSTEM)
grant select on scott.emp to blake WITH GRANT OPTION

Droits sur les objets

Divers, Sécurité Oracle pas de Commentaire »

Pour des raisons de sécurité évidentes, un utilisateur autre que DBA n’a aucun droit a priori….même pas celui de se connecter ? la base de données !

Droits implicites

Par contre, le créateur d’un objet (TABLE, VUE , INDEX, etc.) est son propriétaire,et a implicitement des droits sur cet objet. Il possède tous les droits sur son contenu : consultation, mises ? jour, mais aussi suppression complète de sa structure (le contenant).

– exemple

– on suppose que l’utilisateur DD a reçu le droit de se connecter et de creer des tables…
SQL> connect DD/DD
SQL> create table essai (n integer);
Table created
– droit d’insertion (mais aussi suppression et modification) implicite
SQL> insert into essai values (1);
1 ligne créée.
SQL> commit;
Validation effectuée.
– a fortiori droit de consultation
SQL> select * from essai;
N
———-
1
– suppression de la table et de son contenu
SQL> drop table essai;
Table supprimée.Par contre un autre utilisateur (s’il n’est pas DBA) n’a a priori aucun droit sur les tables des autres:

– exemple

– on suppose que DD possede une table T1…
SQL> connect toto/toto
SQL> select * from dd.t1;
select * from dd.t1
*
ERREUR ? la ligne 1 :
ORA-00942: table or view does not exist

Droits explicites - GRANT et REVOKE

GRANT et REVOKE permettent respectivement de donner ou de supprimer les droits explicites d’accès en lecture ou

mise ? jour ? un utilisateur particulier, pour un objet particulier.
C’est en général le propriétaire de l’objet peut donner des droits d’accès ? un autrer utilisateur.

– exemples:

SQL> GRANT SELECT ON TAB_CLIENTS TO MARTIN
SQL> GRANT UPDATE, INSERT ON TAB_CLIENTS TO DUPONTpar défaut un DBA ne peut pas donner des droits d’accès ? un objet qui ne lui appartient pas. Le propriétaire doit lui céder les drois avec un grant option (!?) :

SQL> connect system/xxxx
Connected.
SQL> grant select on intranet.annuaire to scott;
ERROR at line 1: ORA-01031: insufficient privilegesLe type de privilège dépend évidemment de l’objet sur lequel il s’applique. Ceci est résumé ici :

SELECT (uniquement !) -> les séquences

SELECT, INSERT, UPDATE, DELETE -> les tables, les vues, les vues matérialisées

REFERENCE (possibilité de créer une clé étrangère sur la table) -> les tables et les vues

EXECUTE -> les procédures

INDEX, ON COMMIT REFRESH, QUERY REWRITE -> les tables

Il est possible de donner un privilège avec le droit de transférer ce privilège ? d’autres (? utiliser avec parcimonie). Ceci se fait avec l’otion ‘GRANT’ du GRANT (!) :GRANT SELECT ON TAB_CLIENTS TO DUPONT WITH GRANT OPTION
(on suppose que TAB_CLIENTS est un synonyme public visible par tout le monde). Dupont, même s’il n’est pas propriétaire pourra alors ? son tour faire :
GRANT SELECT ON TAB_CLIENTS TO MARTIN

une erreur très répandue consiste ? référencer un objet (dont on n’est pas proprétaire et sur lequel il n’y pas de synonyme) par son nom, SANS le préfixer par le nom du propriétaire. exemple : SELECT * from EMP au lieu de

SELECT * FROM SCOTT.EMP
ceci donne une erreur d’accès du type

ERROR at line 1:
ORA-00942: table or view does not exist (?!)

même si on a les droits de lecture…

Les privilèges du DBA

Divers, Sécurité Oracle pas de 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.