All BD

SECURITATEA BAZELOR DE
DATE
1. Securitatea BD
dr. ing. Enache-Ducoffe Adriana Cristina
(adryanaenache@gmail.com)
dr. ing. Enache Adriana 1

Securitatea BD
• Cunostinte necesare
– Baze de date
• Design, modele relationale, SQL etc.
• Instructiuni SQL: DML, DDL, DCL.
• Tipuri de obiecte BD : index, constrangere etc.
– Notiuni de baza – criptografie
• alg de criptare

Securitatea BD
“Hardware is easy to protect: lock it in a

Hardware is easy to protect: lock it in a room,
chain it to a desk, or buy a spare. Information
poses more of a problem. It can exist in more than
one place; be transported halfway across the
planet in seconds; and be stolen without your
knowledge.”
— Bruce Schneier

Securitatea BD
• Riscuri de securitate
– Riscurile  accesibilitatii datelor
– Amenintari: externe / interne (80%-90%)
– NU exista un SISTEM 100% securizat
• Compromis: cost - risc
– Riscul = Vulnerabilitate + Amenintare
• Vulnerabilitatea – hiba din interiorul sistemului
• Amenintarea – evenimente sau situatii care pot
exploata o vulnerabilitate

Securitatea BD
• Amenintari Externe
– Utilizatori neautorizati
• software exploit, bypass password, crack
password, social engineering etc.
• Vulnerablitati:
– Parole simple, comunicarea din retea nu e securizata,
sesiuni car nu sunt verificate, recycle bin nu e sters etc.
– Accesul neautorizat la date

• atacatorul trece de autentificare  autorizare
 are privilegiile user_interior
• Principiul least privilege
– Exploituri: SQL injection, etc.

Securitatea BD
• Amenintari Interne
– Abuzarea privilegiilor
• utilizarea autorizatiilor pentru a obtine acces
neutorizat la anumite date /servicii
– Furtul de date
• o data autorizat  furtul date simplu
– Sabotajul - de catre utilizatorii autorizati:
• ex: responsabil financiar care acopera tranzactiile
ilegale, developer lasa hibe in mod deliberatSQL
injection, etc.
– Alterare / pierdere date  recuperarea
• defect sistemului  T_downtime
– Omisiunea – aplicarea politicilor control acces
• politici la nivel SO  nu sunt suficiente

Securitatea BD
• Securitatea BD – Cerinte fundamentale

Asigura faptul ca informatiile sunt
CONFIDENTIALITATE accesate numai de catre persoanele
autorizate
DISPONILIBILITATE INTEGRITATE
Mentinerea validitatii datelor

Livrarea datelor/resurselor/serviciilor (protejara de modificari
catre utilizatorii autorizati neintenionate/ useri malitiosi)
Securitatea BD
• Aplicatie de plata a salariilor

– Salariile angajatilor nu pot fi accesate de utilizatori
arbitrari din baza de date
– Salariile angajatilor pot fi modificate numai de catre
utilizatori autorizati
– Fluturasii de salariu trebuie sa fie disponibili la
sfarsitul perioadei

Securitatea BD
• Securitatea BD – Cerinte fundamentale

Asigura faptul ca informatiile sunt
CONFIDENTIALITATE accesate numai de carte persoanele
autorizate de a le accesa
Asigura ca entitatea primeste
anumite date de la o sursa autentica
(non-repudierea)
Responsabilizarea entitatilor
AUTENTICITATE pentru actiunile sale
RESPONSABILIZARE
DISPONILIBILITATE INTEGRITATE
Mentinerea validitatii datelor

Livrarea datelor/resurselor/serviciilor (protejara de modificari
catre utilizatorii autorizati neintenionate/ useri malitiosi)
Securitatea BD
• Scopul Securitatii
– Preveni
• prevenire prin protejarea BD : divulgare, distrugere, modificari
neautorizate în mod intenționat/neintenționat
• ex. controlul accesului etc.
– Detecta
• detectarea evenimentului de securitate
• Ex. loguri, auditare, etc.
– Recupera
• oprirea atacului, recuperarea datelor (alterare/distrugere)
• BD operationala, chiar daca atacul s-a realizat cu succes
• Ex. backup + recovery
– 3 Xcomponente = Defence-in-Depth – 1 nivel esuat …

Securitatea BD
• Principiul – Least Privileged

– Incepe de la nivelul cel mai inferior si continua cu
urmatorul nivel = nr cat mai mic de privilegii
– Limitarea accesului:
• root + administrare
• privilegii administrative : SYSDBA, SYSOPER
• privilegii sistem + obiect : nevoia de a cunoaste

Securitatea BD
• Autentificarea
– procesul de validare al credentialelor utilizatorului
– verificarea identitatii utilizatorilor
• Autorizarea
– Procesul de control al accesului (privilegii)
• Auditarea
– Procesul de responsabilizare al utilizatorilor (acces
neautorizat, utilizatori care nu isi folosesc privilegiile
corespunzator etc.)
• Criptarea
– Foloseste un algoritm pentru a transforma datele in
simboluri neinteligibile – chei
– Protejarea datelor de pe disc, din retea
Securitatea BD
1. Gestiune Useri, Privilegii, 4. Criptarea BD

Roluri, Profile
2. Auditare 5. Backup + Restore
3. Virtual Private DB

Securitatea BD
• Forma de evaluare
– Laboratoare: 20%
– Proiect : 30%
– Evaluare. 50%
• Forma de evaluare
– Laboratoare: 20%
– Evaluare: 80%

DATE
1.1 Arhitectura BD Oracle


Securitatea BD
• Serverul BD Oracle = Instanta Oracle + BD Oracle
Instanta Oracle
- Memorie
- Procese de Fundal
1 instanta  1 BD
SID = System ID
BD Oracle
- Fisierele (fisierele BD,
control, redolog etc.)

Instanta BD
• Memoria – SGA = System Global Area

– alocata in memoria virtuala a sistemului pe care
ruleaza serverul Oracle
• startup Instanta (nomount)
– Shared Global Area – partajata, pt a evita accesul
repetat pe disc
– Componente: Cele mai
recent
utilizate
instr. SQL +
PL/SQL; LRU
Copii ale
blocurilor Cele mai
de date recent
utilizate
Circular; Toate modificarile blocurilor definitii din
de date BD; LRU
Instanta BD
• Procese de fundal
– Database Writer (DBWn) - scrierea blocurilor
de date din bufferele de memorie in fisierele de pe
disc.
– Log Writer (LGWR) – scrie datele din Redo Log
Buffer pe disc ( fisier de Redo Log ).
– Checkpoint (CKPT) –proces de check point 
anunta actiunea lui DBWR, actualizeaza fisierele de
date si control ale bazei de date.

Instanta BD
• Procese de fundal
– System Monitor (SMON)– activitati de
“curatare” la nivel de sistem:
• instance recovery (roll forward modificarile din red log,
roll back tranzactiile uncomitted, deschide BD), …
– Process Monitor (PMON) – monitorizeaza alte
procese de fundal – “curatarea” dupa un process fail
• ex. Conexiunea de retea esueaza  eliberare memorie,
eliberare resurse, rollback etc.

Baza de Date
• Baza de date
– Identificare – variabile DB_NAME de la niv SO
Fisierele de redo log

Fisierele de date (*.dbf) Fisierul de control (*.ctl) - Inregistreaza toate
- contin: dictionarul BD, - fisier binar modificarile din BD
obiectele userului etc. - defineste starea fizica a (tranzactii
- 1 BD are cel putin un BD(nume BD, locatia fis commited/uncommited
fisier de date date, etc.) etc.)
- mentine integritatea BD - organizate in grupuri
- 1 BD are cel putin un fisier - 1 BD are cel putin doua
de control (MOUNT) grupuri de fisiere redo log
Baza de Date
• Alte fisiere
– Fisierul de parametrii – parametrii de initializare
(alocarea memoriei Instantei, parametrii de
optimizare, locatie fisierului de control etc.)
• Static (init.ora) / Dinamic (spfile.ora)
– Fisierul de parole – pentru autentificarea
utilizatorilor
– Fisierele RedoLog Arhivate – copiile offline
arhivate ale fisierelor Redo Log (pt. recovery)
– Fisierele de Alert Log – inregistrate anumite
informatii + erori ale BD (ex. Start/stop)
– etc.
Baza de Date
• Structura Logica vs Structura Fizica

Baza de Date
• Serverul BD

Baza de Date
• START Online : fisierele date + redoLog

Verifica consistenta
(Userii - acces)
Fisierul de control
Asociere instanta – BD
(activare/dezactivare archivelog)
Fisierul de parametrii
aloca mem. + porneste procesele
(recreare fis ctl, backup + recovery)

Baza de Date
• STOP

QUIZ
• Care dintre urmatoarele componente fac parte

din Instanta Bazei de date ?
a) System Global Area
b) Tablespaces
c) Control file
d) Redolog file
e) Procesele de fundal

QUIZ
• Care dintre urmatoarele componente fac parte

din Instanta Bazei de date ?
a) System Global Area
b) Tablespaces
c) Control file
d) Redolog file
e) Procesele de fundal

REVIEW
• Arhitectura Oracle
– Server = Instanta + BD
• Instanta
– Memorie
– Procesele de Fundal
• Baza de date
– fisierele de date, control, redo log
– Structura fizica vs Structura Logica
• Start / Stop

DATE
2. Gestiune utilizatori, privilegii, roluri, profile


Securitatea BD
• Obiective
1. Gestiunea utilizatorilor
• Creare / modificare / stergere
• Mecanisme de autentificare
2. Privilegii
• Tipuri de privilegii
• Acordare / revocare
3. Roluri
• Creare / stergere
• Activare / dezactivare
4. Profile

1. Gestiunea Utilizatorilor
• Utilizatorul
– cont – conectarea la baza de
date
• USER vs SCHEMA
• USER – cont in BD
• SCHEMA = User + Objects
• Crearea USER  creare

SCHEMA

• Setari pt. utilizator:
– Nume cont – unic
– Mecanism de autentificare
– Quota – pt tablespace-uri
• Implicit = 0 !!!
– Tablespace implicit
• crea obiectele
• Implicit  tablespace = SYSTEM / USERS
– Tablespace temporar
• operatii : Select Distinct, Order by, Merge Join …
– Limitari de resurse (profil)
– Privilegii
– Roluri

• Gestionare Utilizatori
A. Creare User
B. Modificare User
C. Stergere User

1. Gestiunea Utilizatorilor - creare
• Sintaxa pt. creare utilizator:
CREATE USER username

IDENTIFIED {BY password
| EXTERNALLY
| GLOBALLY AS 'external_name'}
[ DEFAULT TABLESPACE tablespace ]
[ TEMPORARY TABLESPACE tablespace ]
[ QUOTA int {K | M} ON tablespace ]
[ QUOTA UNLIMITED ON tablespace ]
[ PROFILE { profile_name | DEFAULT }]
[ PASSWORD EXPIRE ]
[ ACCOUNT {LOCK|UNLOCK} ]

• Metoda de autentificare
CREATE USER username
IDENTIFIED {BY password
| EXTERNALLY
– Password authenticated (db authentication)
• username + parola – prec. la login + stocate in BD
– External authenticated (OPS$ACCOUNT)
• user autentificat S.O. – autentificarea SO trusted de BD
• stocare in BD – nu parola
– Globally authenticated (3rd part)
• username – verif BD
• stocare in BD – nu parola
• bazeaza met. avansata de autentificare
– Ex. biometrice, certificate X509, Kerberos etc.

• Alte optiuni:
– clauza specifica tablespace-ul default (implicit)
– clauza specifica tablespace-ul pentru segmente temporare
– clauza specifica valoarea cotei pe un anumit tablespace in
bytes / KB / MB.
– clauza specifica faptul ca nu este fixata o limita superioara
pentru cota pe acel tablespace (bineinteles segmentele
userului nu pot depasi spatiul existent acolo)

• Alte optiuni:
– limitarile privind resursele pe care le poate consuma
userul + stab. reguli pwd management
– dc. nu se specifica --> va fi asociat un profil implicit.
[ PASSWORD EXPIRE ]
– parola este ‘pre-expirata’ -- userul trebuie sa o schimbe
inainte de a se putea intra in acel cont
– Implicit: not expired
– cont este blocat (LOCK), --> necesita deblocare inainte
de a fi utilizat.
– Implicit contul - deblocat (UNLOCK) + se poate lucra.

1. Gestiunea Utilizatorilor - modficare
• Modificare date User

ALTER USER username IDENTIFIED {BY password
| EXTERNALLY
[ PASSWORD EXPIRE ]
– LOCK – momentul in care user este logat ???


– LOCK – momentul in care user este logat ???

• Modificare date User - Quota setam ca fiind 0


– Quota setam ca fiind 0 – STUD1 are asignat rolul
RESOURCE nu este afectat

1. Gestiunea Utilizatorilor - stergere
• Stergere User
DROP USER username [CASCADE]
– CASCADE – sterge toate obiectele din schema

userului
– NU e prec. CASCADE
• Userul are obiecte ?
– Eroare
– Fara CASCADE – se pot sterge doar userii care NU au
obiecte

• Stergere User

• Stergere User – stud3 este conectat la BD

• Informatii despre userii din BD

2. Privilegii
• Privilegii
– Tipuri de privilegii
– Acordare / revocare

2. Privilegii
• Autorizarea
– Determina privilegiile la care utilizatorul are dreptul
– Autorizarea = administrarea privilegiilor
• Privilegiul
– Dreptul de a accesa un anumit obiect
– Dreptul de a executa un anumit tip de statement
– Obiect
– Sistem
2. Privilegii
– OBIECT = fiec. o.p. permite  actiuni la nivel OBJ
• User  poate accesa propriile obiecte
– Pt. a accesa obiectele altor useri  privilegii obiect
• Acordat:
– Administrator
– User cu GRANT ANY PRIVILEGE
– User cu dreptul explicit de a acorda privilegii pe acel obiect
– SISTEM = fiec. s.p. permite  operatiune la nivel BD

• Acordat :
– administrator
– User cu drept de administrare al privilegiului

2. Privilegii - Obiect
• Privilegii obiect – permite unui grantee sa

utilizeze obiectele din schema altui utilizator
– Pot fi acordate:
• Individual
• Grupat
• Toate - cuvantul cheie ALL

• TABEL

• TABEL

• Proceduri, functii, pachete

Procedure, Function,
Object Privilege Table View Package
SELECT X X
INSERT X X
UPDATE X X
DELETE X X
EXECUTE X
DEBUG X X X
ALTER X
INDEX X
REFERENCES X

• Acordare – Grant
GRANT {object_priv | ALL [PRIVILEGES]}

[ (column [, column] ...) ]
[, {object_priv | ALL [PRIVILEGES]}
[ (column [, column] ...) ] ] ...
ON [schema.]object
TO {user | role | PUBLIC}
[, {user | role | PUBLIC}] ...
[WITH GRANT OPTION]
• extinderea posibilitatii de a acorda mai departe privilegiul

• Revocare – Revoke
REVOKE {object_priv | ALL [PRIVILEGES]}

[ (column [, column] ...) ]
[, {object_priv | ALL [PRIVILEGES]}
[ (column [, column] ...) ] ] ...
ON [schema.]object
FROM {user | role | PUBLIC}
[, {user | role | PUBLIC}] ...
[CASCADE CONSTRAINTS]
• elimina constrangerile referentiale afectate

• Revocare priv. obiect – cascada

• Revocare priv. obiect – cale multipla

• BD – stocheaza grantor + grantee

– Putem obtine acelasi priv. obj. pe mai multe cai
– Dictionare din BD
• DBA_TAB_PRIVS – nivelul BD
• USER_TAB_PRIVS – nivelul USER
– Stergerea USER care a acordat privilegiile obiect
• Stergerea tuturor privilegiilor obiect acordate

• BD – stocheaza grantor + grantee

2. Privilegii - Sistem
• Privilegii sistem – permite unui grantee

execute instructiuni
– DDL – create, alter, drop
• Privilegii pt. operatii la nivel de sistem
– Ex. CREATE TABLESPACE, CREATE SESSION etc.
• Privilegii care afecteaza  obiectele din schema proprie
– Ex.: CREATE TABLE
• Privilegii care afecteaza  obiectele din orice schema
– Ex. : CREATE ANY TABLE
– DML – la niv. de sistem
• Privilegii care afecteaza  obiectele din orice schema
– Ex.: SELECT ANY TABLE, EXECUTE ANY PROCEDURE, …

• DDL
A. USER
– CREATE USER
– ALTER USER
– DROP USER
B. TABLE
– CREATE TABLE – grantee are dreptul de a crea tabele in
propria schema
– CREATE ANY TABLE – grantee are dreptul de a crea
tabele in orice schema
– ALTER ANY TABLE – modificarea tabelelor din orice
schema
– DROP ANY TABLE – stergerea tabelolor din orice
schema

• DDL
C. VIEW
– CREATE VIEW– grantee are dreptul de a crea tabele in
propria schema
– CREATE ANY VIEW– grantee are dreptul de a crea tabele in
orice schema
– DROP ANY VIEW– stergerea tabelolor din orice schema
D. PROCEDURE
– CREATE PROCEDURE– grantee are dreptul de a crea
proceduri in propria schema
– CREATE ANY PROCEDURE– grantee are dreptul de a crea
proceduri in orice schema
– ALTER ANY PROCEDURE– recompila procedurile din bd
– DROP ANY PROCEDURE– stergerea procedurile din orice
schema

• DDL
E. SESSION
– CREATE SESSION – grantee se poate conecta la baza de date
– ALTER SESSION – modificarea parametrilor sesiunii curente (la
reconactare acestia se vor reseta)
F. PROFILE
– CREATE PROFILE– grantee are dreptul de a crea profile (ALTER
USER)
– ALTER PROFILE– modifica profile existente in bd
– DROP PROFILE– stergerea profile din db
G. ROLE
– CREATE ROLE– dreptul de a crea roluri
– ALTER ANY ROLE– modificarea oricarui rol (schimbarea parolei)
– DROP ANY ROLE– stergerea oricarui rol din BD
H. BAZA DE DATE
– ALTER DATABASE– executa instructiunea alter database
– (ex. Alter database open)
– ALTER SYSTEM– executa instructiunea alter system
– (ex. Alter system set parameter_name = value)

• DML – la niv de sistem

A. TABLE
– SELECT ANY TABLE
– INSERT ANY TABLE
– UPDATE ANY TABLE
– DELETE ANY TABLE

• OBSERVATII
– ANY - arata ca userul are acel privilegiu in orice
schema din BD
– CREATE TABLE, CREATE PROCEDURE – include si
dreptul de a strege acel obiect
– Pt tuncherea unei tabele – avem nevoie de privilegiul
sistem DROP ANY TABLE
• Dictionare din BD
• DBA_SYS_PRIVS – privilegiile sistem acordate la nivelul
BD
– Retinut doar grantee + privilegiul
• SYSTEM_PRIVILEGE_MAP – toate privilegiile

• Acordare – Grant
GRANT { priv_sistem},
{ priv_sistem}…
TO { user | rol | PUBLIC },
{ user | rol | PUBLIC }…
[WITH ADMIN OPTION]
• extinderea posibilitatii de a acorda privilegiul sistem mai departe unor
alti useri / altor roluri
• PUBLIC - privilegiile respective sunt asignate tuturor userilor

• Revocare – Revoke
REVOKE { priv_sistem},
{ priv_sistem}…
FROM { user | rol | PUBLIC },
{ user | rol | PUBLIC }…

• Revocarea privilegiilor sistem
REVOCAREA privilegiilor sistem nu se cascadeaza
BD – retine doar : grantee + privilegiul sistem

(NU stim cine a acordat privilegiul sistem)

• Privilegii Administrative –
– efectuarea operatiilor de administrare de nivel inalt:
start/stop/backup/recover/etc.
• SYSDBA - administratorul BD cu drepturi

depline asupra BD
• SYSOPER – administratorul BD cu drepturi
restranse asupra BD

• SYSDBA
– Privilegiul de sistem cel mai permisiv + permite o
administrare complea a BD
– poate executa urmatoarele instructiuni:
• STARTUP and SHUTDOWN operations
• ALTER DATABASE: open, mount, back up, or change character
set
• CREATE DATABASE
• DROP DATABASE
• CREATE SPFILE
• …
• Toate privilegiile sistem
– T_conectare la BD (as sysdba)= cu privilegiul SYSDBA =
Userul SYS
• acces la toate datele din BD
• SYSOPER
– Privilegiul sistem mai putin permisiv decat SYSDBA
– Poate executa urmatoarele instruciuni:
• STARTUP and SHUTDOWN operations
• ALTER DATABASE OPEN/MOUNT/BACKUP
• ALTER DATABASE ARCHIVELOG
• ALTER DATABASE RECOVER
• ….
– T_conectare la BD (as sysoper)= cu privilegiul
SYSOPER = Userul PUBLIC
• are acces la ceea ce userul PUBLIC are dreptul


3. Roluri
• ROLURI
– Creare / Modificare / Stergere
– Acordare / Revocare / Activare

3. Roluri
• ROLURI
– sunt colectii de privilegii care pot fi
acordate/revocate impreuna unor useri / roluri
– Rolul nu apartine unei scheme

• Stregere user care a creat rolul  rolul nu este sters
– Scopul Rolurilor  simplifica activitatea de
administrare a privilegiilor
• Pot imbunatati nivelul de securitate

3. Roluri
• Rolurile au urmatoarele functionalitati

– putem acorda priv. sistem + priv. obiect
– orice rol poate fi acordat unui user
– orice rol poate fi acordat unui rol
• dar nu circular: rol_1  rol_2 si rol_2  rol_1
– un rol poate fi activat / dezactivat pentru un user
caruia i s-a acordat rolul
– rolul poate fi protejat cu parola,
• in aceste caz  pentru activarea rolului trebuie sa
introducem parola

3. Roluri
• Exemplu

3. Roluri
• Beneficiile oferite de roluri

– Gestionare mai simpla a privilegiilor
• Grupam privilegiilor  NU acordam toate priv de mm ori
– Gestionare dinamica a privilegiilor

• Modificarea privilegiilor dintr-un rol  actualizarea
privilegiilor utilizatorilor
– Disponibilitate selectiva a privilegiilor

• Rolurile pot fi activate/dezactivate temporar

3. Roluri
• Creare si Modificare ROL
{CREATE | ALTER} ROLE role_name

[NOT IDENTIFIED |
IDENTIFIED
{BY password | EXTERNALLY}]
• EXTERNALLY – user extern trebuie autorizat de un serviciu
extern (ex. Sistemul de operare)

3. Roluri
• Acordare ROL
GRANT ROLE role_name
to [user | role_name]
[WITH ADMIN OPTION]
• extinderea rolului – identic cu privilegiile sistem
• Revocare ROL
REVOKE ROLE role_name
from [user | role_name]

3. Roluri
• Activare / Dezactivare ROL
SET ROLE
{ role_name IDENTIFIED BY pwd |
ALL [EXCEPT {role1, role2, …}|
NONE}
– Dc. nu e rolul default  rolul tb activat din sesiunea curenta
– Activarea – roluri acordate
• Lista de roluri
• ALL
– Dezactivare
• EXCEPT – lista de exceptii (ALL)
• NONE – deactiveaza toate rolurile din sesiunea curenta (inclusiv rolul
default)
• Nu se poate dezactiva un sigur rol
• Nu se poate dezactiva un rol mostenit  trebuie dezactivat rolul parinte
– Ex. Resource mostenit prin rolul DBA

3. Roluri
• Roluri default
– roluri activate automat dupa autentificarea utilizatorului
• nu mai este necesar sa utilizam SET ROLE pentru activare
• lista de roluri predefinite exista rol cu parola
– Activarea este implicita  nu mai are nevoie de parola
ALTER USER user_name

default role
{role_list |
ALL [EXCEPT {role1, role2, …}|
NONE}

3. Roluri
• Roluri predefinite
Denumire rol
CONNECT are doar privilegiul CREATE SESSION
RESOURCE dreptul de a crea obiecte in schema (chiar
daca cota = 0)
DBA este cel mai complex rol din BD
trebuie acordat doar administratorilor BD
rolul are
• toate privilegiile sistem
• o parte din privilegiile de administrare
(NU – SYSDBA, SYSOPER)

3. Roluri
• Roluri cu parole

3. Roluri
• Dictionare din BD
– DBA_ROLES – rolurile definite in BD
– SESSION_ROLES – rolurile active in sesiunea curenta
• Activare / dezactivare roluri
• Parametrii din BD
– MAX_ENABLED_ROLES – numarul maxim de
roluri active permise

Utilizatori predefinit in BD
• Utilizatori predefiniti in BD
– SYS – rolul DBA (parola: schimba la instalare)
• Owner BD + Dictionarele BD
– SYSTEM – rolul DBA (parola: manager)
• Tabele aditionale cu informatii de administrare BD

4. Profile
• PROFILE
– Creare / asignate / modificare / stregere
– Ce resurse putem limita ?

4. Profile
• PROFILUL
– Un set de limitari de resurse + parametrii pentru parola
• restictioneaza accesul la BD + la resursele instantei
• asociate unui USER
– Fiecare USER  poate avea un sigur profil

• profil default – la niv. BD  asociat implicit
• asocierea unui profil  suprascrie pe cel anterior
– Profilul – poate fi asociat numai USERI
• NU – roluri / altor profile

4. Profile
• PROFILUL
– Limitarea resurselor
• activa doar daca parametrul RESOURCE_LIMIT = true
• SQL> show parameter resource_limit;
– Administrarea parolei
• activa permanent

4. Profile – Limitarea resurselor
• Limitarea resurselor
– activa -- parametrul RESOURCE_LIMIT = true
• SQL> show parameter resource_limit;
• SQL> alter system set resource_limit=true;
– Ce se limiteaza ?
• Resursele sistemului
• Profilul DEFAULT – resursele sistem = UNLIMITED

• Profilul DEFAULT

• Creare Profil
CREATE PROFILE profile_name

[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 [K|M] | UNLIMITED | DEFAULT}]

• Resurse pot avea valori:
– UNLIMITED – pt. acest profil resursa respectiva

este nelimitata
– DEFAULT – pt. acest profil resursa respectiva
poate fi folosita limitat , valoare fiind cea din profilul
default
– Valoare – unitatea de masura a resursei depinde de
tipul resursei

• Resurse ale sistemului

– sessions_per_user – nr. maxim de sesiuni
concurente pentru user.
– cpu_per_session - Timp CPU per sesiune

• masurat in sute de secunde.
– cpu_per_call - Timp CPU per operatie

• masurat in sute de secunde.
• 1 operatie este un ciclu parse, execute, fetch.
– Software parse / hardware parse
– DDL  ce tip de parsare ?


– connect_time - Timpul maxim de conectare
• masurat in minute.
• sesiunile userului sunt inchise de Oracle dupa expirarea
acestui timp.
– idle_time - Timp maxim de asteptare

• masurat in minute.
• sesiunile vor fi inchise de Oracle dupa expirarea perioadei
specificate daca in sesiunea respectiva nu s-a facut nimic (e
‘idle’).
• Atentie: cererile a caror executie este lunga nu
intra in aceasta categorie!


– logical_reads_per_session – nr. maxim de blocuri
citite per sesiune.
• nr. de blocuri citite de pe disc sau din memorie.
• acest parametru este gandit pentru a limita cererile care
fac citiri intensive.
– logical_reads_per_call – nr. maxim de blocuri

citite per operatie(call)
– private_sga– dimensiunea maxima de memorie

ocupata
• Resurse aferente parolei
– failed_login_attempts - nr. maxim de incercari
eronate de login.
• dupa acest nr. de incarcari --> contul e blocat (LOCKED)
– password_lock_time - nr. de zile cat contul este blocat

dupa incercari repetate de login.
• password_lock_time = UNLIMITED --> contul tb deblocat
manual
-- lock account for 10 minutes if

-- 3 consecutive logins fail
CREATE PROFILE agent LIMIT
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 10/1440;


– password_reuse_max – nr. minim de parole diferite
utilizate pana cand o parola poate fi reutilizata
– password_reuse_time – nr. minim de zile dupa
care o parola poate fi reutilizata
-- require at least 4 password

-- changes and 1 year
-- before a password may be reused.
CREATE PROFILE agent LIMIT
PASSWORD_REUSE_TIME 365
PASSWORD_REUSE_MAX 4;


– password_life_time – nr. maxim de zile cat parola
este valida
• Timpul expira  parola expira
– password_verify_function - daca parola este sau

nu verificata ca lungime, continut si complexitate
• Permite adaugarea unor reguli suplimentare pentru
verificarea parolei
CREATE PROFILE pwd_management LIMIT

PASSWORD_VERIFY_FUNCTION fct_verif_pwd;

4. Profile
• Ce se intampla daca nu se respecta

limitarile de resurse ?
– SESIUNE***
• sessions_per_user = nr. de sesiun a ajuns la val. MAX + se
incarca deschiderea unei noi sesiuni
– Se afiseaza un mesaj de eroare
• connect_time = durata maxima a sesiunii a fost atinsa

– Userul este deconetat

4. Profile
• Asignare Profilului
– Poate fi asignat USER
• CREATE USER
– clauza profile
– daca lipseste clauza PROFILE  profilul default
• ALTER USER
ALTER USER username

PROFILE profile_name;

4. Profile
• Asignare Profilului - exemplu

4. Profile
• Asignare Profilului - exemplu

4. Profile
• Modificarea Profilului – asemanatoare CREATE PROFILE
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 [K|M] | UNLIMITED | DEFAULT}]

4. Profile
• Modificarea Profilului
– Sesiunile curente  nu sunt afectate de modificari
• la urmatoarea sesiune, modificarile profilului vor avea
efect
– ALTER PROFILE
• Avem nevoie de privilegiul sistem pt a modifica profilul
– ALTER USER
• Avem nevoie de privilegiul sistem ALTER USER pt a asigna
profilul unui USER

4. Profile
• Stergere Profilului
DROP PROFILE nume [CASCADE]
– Sesiunile curente – NU sunt afectate de stergerea

profilului
– Profilul DEFAULT – NU poate fi sters
– CASCADE – revoca profilul de la userii care il au

• Userii cu profilul sters  in mod automat = profilul
default
– privilegiul sistem : DROP PROFILE
QUIZ
• Care dintre urmatoarele sunt privilegii sistem?

a) CREATE ANY TABLE
b) DBA
c) DROP TABLE
d) CREATE TABLE

QUIZ
• Care dintre urmatoarele sunt privilegii sistem?

a) CREATE ANY TABLE
b) DBA
c) DROP TABLE
d) CREATE TABLE

QUIZ
• Care dintre urmatoarele sunt conturi

predefinite ?
a) DBA
b) SYS, SYSTEM

QUIZ
• Care dintre urmatoarele sunt conturi

predefinite ?
a) DBA
b) SYS, SYSTEM

QUIZ
• Care dintre urmatoarele afirmatii sunt

adevarate despre roluri ?
a) Constau numai din privilegii sistem
b) Constau numai din privilegii obiect
c) Este un set de mai multe privilegii
d) Poate consta din mai multe roluri

QUIZ
• Care dintre urmatoarele afirmatii sunt

adevarate despre roluri ?
a) Constau numai din privilegii sistem
b) Constau numai din privilegii obiect
c) Este un set de mai multe privilegii
d) Poate consta din mai multe roluri

REVIEW
• USER
– SYS
– SYSTEM
• Privilegii
– Sistem
• SYSDBA, SYSOPER
– Obiect
• Roluri
– Colectie de privilegii
– DBA
• Profile
– Limita resursele sistemului + administra parolele
utilizatorilor
DATE
3. Auditarea

Securitatea BD
• Obiective
1. Auditarea
• Ce monitorizam ?
• Tipuri de auditari
2. Auditarea standard
• Statement
• Privilegii
• Obiecte
3. Auditarea conturilor privilegiate
4. FGA (Fine-Grained Auditing)

1. Auditarea
• Auditarea
– Monitorizarea + jurnalizarea actiunilor asupra DB
• ce resurse BD (obiecte: tabele …)
• dc sunt autorizat (privilegii, roluri)
– Principalele intrebari la care trebuie sa raspunda auditul:

• “Who accessed or changed data?”
• “When was it actually changed?”
• “What was the old content prior to the change?”

1. Auditarea
• De ce avem nevoie de auditare ?
– Determinarea responsabilizarii utilizatorilor pt actiunile pe care le realizeaza

• Ex. auditarea modificarilor de continut din obiectele BD
– Descurajarea utilizatorilor sau a intrusilor in efectuarea unor activitati

inadecvate
– Investigarea activitatilor suspicioase

• Stergerea / alterarea datelor / obiectelor din BD
• Intern
– ex. utilizatori care au mai multe drepturi decat ar trebui (revizuirea modelelor de autorizare)
• Extern
– ex. auditarea activitatilor sucessful / unsuccesful (login in BD)
– Monitorizarea + crearea unor statistici ref. la activitatea din BD

• Exemple:
– idetificarea momentelor critice (nr. Max de useri concurenti),
– nr de operatiuni I/O logice realizate etc.

1. Auditarea
• Bune Practici
– Regula generala: adoptarea unor strategii de auditare pentru

colectarea informatiilor, cu accent pe acele activitati care pot
determina evenimente critice de securitate
• Ex. Auditarea tututot tabelelor din BD nu este fezabila, dar putem audita anumite
coloane din tabele (ex. Salariile)
– Arhivarea si stergerea periodica a inregistrarilor de audit

• Informatii colectate  nu mai sunt de actualitate

1. Auditarea
• Tipuri de audit
Tipul de audit Ce este auditat ?
STANDARD -Intructiune / Privilegiu / Obiect
-Informatii despre eveniment:
-Actiunea
-Cand a avut loc
-Userul care a declansat actiunea
-Masina utilizata de user
USERI PRIVILEGIATI -Implicit : conectarea (ex. SYSDBA, SYSOPER)
-Activat: toate instructiunile executate
Fine-Grained Auditing - Nu necesita activare (param audit_trail)
(FGA) - Exindere a auditarii standard
- Instructiuni SQL (INSERT, UPDATE, DELETE) pe baza
continutului

2. Auditarea Standard
• Activare  audit_trail
• Putem colecta informatii despre :
a) INSTRUCTIUNE
b) PRIVILEGIU
c) OBIECT

• Parametrul audit_trail:
– NONE – auditarea NU este activata

– DB* – auditarea BD este activata [val implicita]
• datele de audit sunt salvate in BD (tabela SYS.AUD$)
– DB,EXTENDED – auditarea BD este activata
• datele de audit sunt salvate in BD (tabela SYS.AUD$)
• in plus sunt populate coloanele : SQLTEXT + SQLBIND  retinerea instructiunii SQL +
variabilele de binding
– OS – auditarea BD este activata
• datele de audit sunt salvate la nivelul sistemului de operare (locatie fisierelor:
audit_file_dest)
– XML – auditarea BD este activata
• datele de audit sunt salvate la nivelul SO in fisiere XML
– XML,EXTENDED – auditarea BD este activata
• datele de audit sunt salvate la nivelul SO in fisiere XML
• Sunt colectate : instructiunile SQL + variabilele de binding

• Modificarea parametrului audit_trail

– Privilegiul: ALTER SYSTEM
• ALTER SYSTEM SET audit_trail=DB SCOPE=spfile;
– Restart Instantei

2. Auditarea Standard - INSTRUCTIUNE
• Auditul - INSTRUCTIUNE
– monitorizarea + inregistrarea executarii anumitor tipuri de
instructiuni SQL
– Activarea auditului - INSTRUCTIUNE
• Instructiunea AUDIT
› AUDIT TABLE;
– Auditeaza instruciuni DDL (create, alter,truncate)
• BY USER
› AUDIT TABLE BY student;
• WHENEVER [NOT] SUCCESSFUL

› AUDIT TABLE BY student WHENEVER SUCCESFUL;
– NU e precizat  auditeaza succes / fara succes

• BY ACCESS | BY SESSION
– Instructiunile non DDL
» AUDIT INSERT BY student BY ACCESS;

• Auditul - INSTRUCTIUNE
Optiune de Instructiuni SQL care declaseaza
AUDIT AUDITAREA
SESSION LOGON
USER { CREATE | ALTER | DROP} USER
ROLE { CREATE | ALTER | DROP | SET} ROLE
TABLE { CREATE | ALTER | TRUNCATE } TABLE
SELECT TABLE SELECT any table / view
UPDATE TABLE UPDATE any table / view
PROCEDURE {CREATE | DROP } FUNCTION
{CREATE | DROP } PROCEDURE
CREATE {PACKAGE | PACKAGE BODY}
DROP PACKAGE
SYSTEM AUDIT AUDIT
NOAUDIT
SYSTEM GRANTS GRANT
REVOKE
– Dezactivarea auditului - INSTRUCTIUNE

• Instructiunea NOAUDIT
› NOAUDIT TABLE;
• Am precizat USER-ul in AUDIT

– NOAUDIT TABLE by student;
– Tabele + Dictionare din BD

• DBA_STMT_AUDIT_OPTS – optiunile active de
auditare la nivel de intructiune
• DBA_AUDIT_TRAIL – contine inregistrarile auditate
• SYS.AUD$ - contine inregistrarile auditate

2. Auditarea Standard - PRIVILEGIU
• Auditul - PRIVILEGIU
– monitorizarea + inregistrarea executarii anumitor instructiuni SQL care
necesita privilegii sistem (ex. CREATE ANY TABLE)
– Activarea auditului - PRIVILEGIU

› AUDIT create any TABLE;
– Auditeaza orice instructiune care necesita privilegiul sistem create
any table
• BY USER
› AUDIT create any table BY student;
– Instructiunile non DDL
» AUDIT delete any BY student BY ACCESS;

2. Auditarea Standard - PRIVILEGIU
– Dezactivarea auditului la nivel de

PRIVILEGIU
› NOAUDIT create any table;
• Am precizat USER-ul in AUDIT

– NOAUDIT create any table by student;

• DBA_PRIV_AUDIT_OPTS – optiunile active de
auditare la nivel de privilegiu
• DBA_AUDIT_TRAIL – contine inregistrarile auditate
• SYS.AUD$ - contine inregistrarile auditate

2. Auditarea Standard - OBIECT
• Auditul - OBIECT
– monitorizarea + inregistrarea executarii anumitor
instructiuni SQL care necesita privilegii obiect (ex.
SELECT, INSERT, UPDATE, DELETE, EXECUTE etc.)
– Activarea auditului la nivel de OBIECT
› AUDIT select on student.tb_stud;
– Auditeaza orice instructiune de select asupra tabelei tb_stud;
• WHENEVER [NOT] SUCCESSFUL
› --o inregistrare in audit pt sesiunile care
au avut ---cel putin o instructiune nereusita
› AUDIT select on student.tb_stud BY SESSION
WHENEVER NOT SUCCESFUL;
• BY USER – NU este permisa (auditam toti userii /

niciunul)
– Dezactivarea auditului la nivel de OBIECT
› NOAUDIT select on student.tb_stud whenever not
succesful;

• DBA_OBJ_AUDIT_OPTS
– optiunile active de auditare la nivel de obiect
– are cate o inregistrare pt fiecare obiect
» INS, SEL etc.  [succesful / not succesful] = [A / S]
– SELECT owner, object_name, object_type, ins,
sel from dba_obj_audit_opts where owner =
‘STUDENT’;

Exemplu: AUDITARE – by access / by session
Schema STUDENT – tabelul tb_stud

STUDENT2 – nu are drept SELECT tb_stud
• Student2 (by session)

• Student (by access)

• Student2 (by session) - doua instructiuni fara succes in aceeasi sesiune
• Student (by access)– doua instrutiuni cu succes in aceeasi sesiune
 SELECT username, owner, obj_name, action_name from

dba_audit_trail WHERE action_name LIKE ‘SELECT’

1.
3.
2.
4.

3. Auditarea Userilor Privilegiati
• Auditul – Userilor PRIVILEGIATI
– SYSDBA + SYSOPER  pot realiza modificari in timp ce baza
de date NU este in starea OPEN
• modificarile  nu pot fi auditate in BD
• pot fi stocate la nivelul S.O.
– Unix : adump  ora_N.aud (N = PID)
– Windows : Event Log
– mod implicit anumite activitati sunt inregistrare in fisierele de
audit de la nivel de S.O.
• conectarea la BD  SYSDBA / SYSOPER
• Start / stop BD
– Parametrul audit_file_dest
• locatia fisierelor de la nivelul S.O.
– Parametrul audit_sys_operations
• auditarea tuturor actiunilor – {SYS, SYSDBA/SYSOPER}

• Windows – Event Viewer

• Unix – audit

– Windows
• Auditul poate fi suprascris  in mod periodic tb. salvat
manual
– Chiar daca DBA – este de incredere
• Conectarile SYSDBA tb auditate
• De ce ?
– Password cracking
– Brue force attacks

4. Fine-Grained Auditing
• FGA – permite auditarea dupa continut
– Auditarea std – BD (+extended  SQLTEXT + SQLBIND)
– FGA – extinde aceste capabilitati prin restrangerea auditului
• accesarea anumitor coloane
• satisfacerea unor conditii
– Putem audita DML: {SELECT, INSERT, UPDATE, DELETE}
– Administratorul cfg. FGA util pachetul DBMS_FGA
• Crearea unei politici de securitate pe target {table | view}
• Stabileste o conditie
– FGA auditul  SYS.FGA_LOG$
• Conditia = true  adauga inregistrari in audit
– Auditarea FGA  la nivel de instructiune
• In cazul in care avem un SELECT care intoarce 100 de inregistrari  Cate
inregistrari se adauga in FGA_LOG$ ?

• Crearea unei Politici
DBMS_FGA.ADD_POLICY(
object_schema VARCHAR2,
object_name VARCHAR2,
policy_name VARCHAR2,
audit_condition VARCHAR2,
audit_column VARCHAR2,
handler_schema VARCHAR2,
handler_module VARCHAR2,
enable BOOLEAN,
statement_types VARCHAR2,
audit_trail BINARY_INTEGER IN DEFAULT,
audit_column_opts BINARY_INTEGER IN DEFAULT);

Parametru Descriere
object_schema Schema de care apartine obiectul auditat
Implicit: NULL (util. schema curenta)
object_name Numele obiectului de auditat
policy_name Numele politicii de securitate (tb sa fie unic)
audit_condition predicatul SQL care stabileste cand se va declansa auditul
Implicit: NULL (valoarea TRUE)
Audit_column Coloana care trebuie verificata
Implicit: NULL (orice coloana selectata)
Handler_schema Schema care contine event_handler
Implicit: NULL (util. schema curenta)
Handler_module Denumirea event handler-ului, incluzand denumirea pachetului
Enable Activeaza politica de securitate daca are valoarea TRUE
Implicit: TRUE

Parametru Descriere
Statement_type Tipurile de instructiuni SQL care vor declansa auditarea
Implicit: SELECT
Audit_trail Destinatia inregistrarilor auditate (DB sau XML)
Precizeaza daca se vor popula coloanele LSQLTEXT + LSQLBIND
Implicit: DB_EXTENDED
Audit_columns_opt Stabileste daca auditarea se va declasa la accesarea
s - oricarei coloane precizata in audit_column
- la accesarea tuturor coloanelor precizata in audit_column

– Politica de securitate pe tabelul EMPLOYEES

• Coloana – salary
• Conditia – department_id = 10
Cand va genera inregistrari de audit ?

– Politica de securitate
• drept EXECUTE DBMS_FGA

• Observatii
– Politicile FGA se declanseaza la T_parsing, nu in
T_returneaza_rows:
• poate genera inregistrari false positive
– generarea unor inregistrari de audit  SQL nu a accesat coloanele + conditia
• Nu poate genera inregistrari false negative
– Daca cineva a executat instructiunea SQL  sigur a fost auditat
– Politicile FGA sunt declansate in functie de: coloanele auditate +

predicatul SQL
• T_parsing – conditiile intrunite
– Intructiunea e auditata
– Event Handler-ul este lansat
– Functia de auditare = tranzactie autonoma

– Fiecare politica de auditare – aplicata individual
• 1 instructiune SQL declasa auditul  genera 1 inregistrare in FGA audit trail

• Exemple
Salary + department_id = 10
department_id = 10

Dictionare BD Descriere
DBA_FGA_AUDIT_TRAIL Toate evenimentele FGA (inregitrarile auditului)
SYS.FGA_LOG$ Inregistrarile Auditului FGA
DBA_AUDIT_POLICIES Toate politicile FGA din BD atasate obiectelor
USER_AUDIT_POLICIES Toate politicile FGA atasate obiectelor la care userul curent
are acces

• Adaugarea unei politici FGA
• Dezactivarea unei politici FGA

• Stergerea unei politici FGADB+EXTENDED
?

• Generarea unor inregistrari de audit
Instructiunea SQL
Cine + cand + de unde

+ Instructiunea SQL?

• Dezactivarea unei politici FGA
Politica FGA ramane in

dictionar - dezactivata

• Politica FGA este dezactivata
– Nu se mai adauga inregistrari in Audit

• Activarea unei politici FGA

• Stergerea unei politici FGA

• Auditarea Standard vs FGA

– FGA
• Independent de parametrul audit_trail
• SQLTEXT + SQLBIND colectate in mod implicit
• Mai multa flexibilitate (coloane + conditii)
– Mai putine inregistrari in FGA trail + sistemul nu mai este
supraincarcat
• FGA poate fi activat / dezactivat in mod dinamic
– Auditarea standard  NOAUDIT (pierdem metadatele)

• Auditarea Standard vs FGA

– Auditarea Std.
• Inregistreaza operatiunile fara succes
– FGA auditeaza doar daca sunt indeplinite conditiile
– Break-in attempts  inregsitrate numai de auditarea std.
• FGA poate audita numai instructiuni DML
– Auditarea std. login/logout, privilegi, obiecte etc.
• Auditarea standard va genera inregistrarile de audit in DB /
S.O.
– DBA nu are acces la audit (S.O.)
• Auditarea standard nu este atasata unor obiecte
– Ex. Obiecte temporare care exista numai T_runtime
– FGA  targetul trebuie sa existe in T_creare_policy

Auditarea BD
• Alte mecanisme de auditare DML

– Triggerii
• proceduri SQL declansate in anumite momente
– Executarea unei instructiuni DML
– Anumite evenimente din BD (ex. Login, logout etc.)
• Accepta 6 X DML (incluzand timing-ul Trigger = [BEFORE | AFTER]) :
– {INSERT | UPDATE | DELETE}
• SCOPUL
– Auditarea BD
– Implementarea unor reguli de business, generarea unor valori (ex
calcularea automata a unor sume)

Auditarea BD
• Alte mecanisme de auditare DML

Auditarea BD
– Triggerii
• USER_TRIGGERS – dictionar din BD ce contine
informatii despre toti triggerii unei tabele
• Tipuri de tiggeri
– Nivelul de executie
» Row-level [FOR EACH ROW]– triger-ul este declansat dupa
fiecare rand (updated, inserted, deleted)
• :old , :new
» Statement-level - triger-ul este declansat dupa fiecare
instructiune
– Timing de executie
» BEFORE
» AFTER

Auditarea BD
– Triggerii – ordinea de executare

• Instructiune - N X randuri
– Trigger statement – 1 inregistrare
– Trigger row-level – n X inregistrari

Auditarea BD
– Logurile de audit – trebuie protejate
• Cine are acces la ele ?
– Auditul din BD
» SYSDBA
» Rolul DBA
» Oricine cu privilegiul * ANY TABLE
– Auditul inregistrat la niv S.O.
» Utilizatorul root / oracle = admin BD
» Orice user, in functie de permisiunile S.O.
• Solutii de protejare a inregistrarilor de audit
– Syslog – Unix
» Accepta mesaje de la procese, pe care le poate scrie mai apoi ca user root
intr-o alta locatie din S.O. / chiar pe alta masina remote, unde parola lui
root difera
– Oracle Audit Vault
» Accepta inregistrarile de audit de la colectori + le pastreaza intr-o BD
separata securizata cu ajutorul Oracle database Vault

QUIZ
• Pentru a auditarea standard a obiectelor, este

suficient sa setam paramaterul audit_trail la
valoarea DB, EXTENDED?
a) DA
b) NU

QUIZ
• Pentru a auditarea standard a obiectelor, este

suficient sa setam paramaterul audit_trail la
valoarea DB, EXTENDED?
a) DA
b) NU

QUIZ
• Pentru a auditarea coloanelor ce tip de audit

vom utiliza?
a) Audiul – obiecte
b) Auditul - privilegii
c) FGA

QUIZ
• Pentru a auditarea coloanelor ce tip de audit

vom utiliza?
a) Audiul – obiecte
b) Auditul - privilegii
c) FGA

REVIEW
• Auditarea
• Tipuri de Audit
– Standard – { audit_trail | instructiune AUDIT }
• Instructiune
• Obiect
• Privilegiu
– Userilor Privilegiati { SYSDBA, SYSOPER | S.O. }
– Fine-Grained Auditing – DML {pacheul DBMS_FGA}
– DML  auditat Trigger
• Securitatea logurilor de audit

DATE
4.Virtual Private Databases


Securitatea BD
• Obiective
1. Virtual Private Databases
• Ce inseamna ?
• De ce avem nevoie ?
2. Implementarea VPD
• View
• Application Context
• Fine-Grained Access Control
• VPD

1.VPD
• Virtual Private Database

– Mecanism de mascare al datelor din BD, astfel incat, în mod
aparent, fiecare subset de date să rezide separat
• Ex. Organizatie cu mai multe departamente. Dorim ca angajatii sa poata
accesa doar acele inregistrari specifice propriului departament.
– se refera la accesarea datelor

• controlul accesului la nivel de rand + coloana
• construieste un predicat pe care apoi il va asocia unui tabel / view /
sinonim
– Oracle – mecanisme:
• Fine Grained access Control - asociaza politici de
securitate obiectelor
• Application Context – defineste atribute la nivel de
aplicatie / sesiune
• VPD = FGAC + AC
1.VPD
• Virtual Private Database

2.VPD
2. IMPLEMENTAREA VPD
– View
– Fine Grained Access Control
– Application Context

2.VPD - View
• View
– Obiect al bazei de date care limiteaza accesul utilizatorilor la
date (inregistrari / coloane)
– reprezentare logica a unui / mai multor tabele (nu contine date)
– Ex. User  propriile informatii
CREATE VIEW EMPLOYEES_VIEW1 AS

SELECT EMPLOYEE_ID, FIRST_NAME,
LAST_NAME, EMAIL, PHONE_NUMBER,
HIRE_DATE, JOB_ID, SALARY, MANAGER_ID,
DEPARTMENT_ID, CTL_UPD_USER USER_NAME
FROM EMPLOYEES_VER1
WHERE CTL_UPD_USER = USER

2.VPD - View
• View
– Acordarea permisiunilor INSERT + SELECT userilor
> GRANT SELECT, INSERT ON EMPLOYEE_VEIEW1 TO SCOTT
– Adaugarea unei inregistrari in VIEW
> INSERT INTO
DBSEC.EMPLOYEES_VIEW1(EMPLOYEE_ID,
FIRST_NAME, LAST_NAME, EMAIL,
PHONE_NUMBER, HIRE_DATE, JOB_ID, SALARY,
MANAGER_ID, DEPARTMENT_ID, USER_NAME)
VALUES(100, ‘John’, ‘DOE’, ‘SAFYOUNI’,
‘123.234.3456’, SYSDATE, ‘WM_CLK’, 1000,
1000, 10, USER);
• USER – functie care intoarce contul userului logat in BD

– Login DB_SEC USER = DB_SEC

2.VPD - View
• View
– Alternativa INSERT modificat  crearea unui TRIGGER
> CREATE OR REPLACE TRIGER
TRG_EMPLOYEES_VER1_BEFORE_INS
BEFORE INSERT
ON EMPLOYEES_VER1
FOR EACH ROW
BEGIN
: NEW.CTL_UPD_USER := USER;
END;

2.VPD - View
• Observatii
– View pot deveni dificil de administrat

• Permisiuni , triggeri etc.
– Implementarea este limitata

• Fiecare filtru  view diferit
• Ex. USER vada propriul salariu
USER  vada toti angajatii din departament, dar fara
a vedea salariul acestora

2.VPD – Oracle VPD
• VPD = FGAC + Application Context

– FGAC – tehnica pin care :
• definim fct de filtrare + politica asociem : fct + obj
• limita accesul la date (row + column)
– Application Context – “secure cache”
• completare FGAC

2.VPD – FGAC
• FGAC
– Cand un user acceseaza Tabel /View protejat de o
politica FGAC
1. Userul acceseaza Tabelul protejat de politica FGAC
2. Serverul invoca functia atasata politicii FGAC, in
functie de contextul aplicatiei / atribute ale sesiunii /
continutul bazei de date
3. Instructiunea SQL este rescrisa in mod dinamic
• adaugarea predicatului in clauza WHERE
4. Instructiunea SQL modificata se executa

2.VPD – FGAC
• Implementare FGAC
– Definirea FUNCTII – genereza predicatul din clauza WHERE
– Definirea unei POLITICI (DBMS_RLS)
• atasa: Obiectul protejat + Functia de securitate
• restrictionarea la nivel de coloana
– Implicit : restrictioneaza numarul de inegistrari
– Masca : afiseaza toate inregistrarile, dar pentru coloana protejata va
afisa NULL

2.VPD – FGAC
• DBMS_RLS
– Pachet pentru gestionarea politicilor FGA :
Creare DBMS_RLS.ADD_POLICY
Stergere DBMS_RLS.DROP_POLICY
Activare DBMS_RLS.ENABLE_POLICY
Dezactivare DBMS_RLS.DISABLE_POLICY

2.VPD – FGAC
• DBMS_RLS - parametrii ADD_POLICY

Parametrii Descriere Parametru
Object_schema Identifica schema obiectului protejat
Implicit: schema curenta (NULL)
Object_name Numele obiectului protejat
Policy_name Numele politicii de securitate
Function_schema Schema in care rezida functia politicii FGAC
Policy_function Denumirea functiei. Daca functia este definita in cadrul
unui pachet, atunci trebuie precizat.
Statement_types Orice combinatie: SELECT, INSERT, UPDATE, or DELETE

2.VPD – FGAC
• DBMS_RLS - parametrii ADD_POLICY

Parametrii Descriere Parametru
enable Implicit: True
sec_relevant_cols Lista de coloane protejate. Politica se aplica numai daca
coloana este referentiata in instructiunea SQL
Implicit: toate coloanele sunt luate in considerare
sec_relevant_cols_opt Se aplica numai pentru instructiunea SELECT, si
determina mascarea coloanelor protejate, care apar ca
fiind NULL.
Implicit: NULL (aplica sec_relevant_cols)
dbms_rls.ALL_ROWS : comportamentul de mascare.

2.VPD – FGAC
• Exemplu
– Student este proprietarul tabelului
Tb_stud(id varchar2(30), nume varchar2(20));
– Vrem ca toti userii sa poata accesa propriile informatii,

dar Administratorul sa poata accesa toate inregistrarile

2.VPD – FGAC
• Exemplu
– Crearea functiei pentru politica FGCA
Create function sec_function
(p_schema varchar2, p_obj varchar2) Identificati
Return varchar2 eroarea din
As Instructiune
user VARCHAR2(100);
Begin
if ( SYS_CONTEXT('userenv', 'ISDBA') ) then
return ''; //Admin can access any data
else
user := SYS_CONTEXT('userenv', 'SESSION_USER');
return ‘nume = ' || user;
// Users can only access their own data
end if;
End;
// USERENV = application context predefinit

2.VPD – FGAC
• Exemplu
– Student2 are permisiunea SELECT student.tb_stud
 SELECT * from student.tb_stud;
Select * from student.tb_stud
WHERE nume = ‘Student2’
 INSERT INTO student.tb_stud
OK
VALUES (2, ‘STUDENT2’);
 INSERT INTO student.tb_stud EROARE

VALUES (2, ‘STUDENT1’);
ORA-28115: policy with check option violation

2.VPD – FGAC
• Exemplu- Column level VPD

– Alice are acces la tabelul
Employees(e_id number(2),
name varchar2(10), salary number(3));
E_id Name Salary

1 Alice 80
2 Bob 60
3 John 99
– Vrem ca toti userii

• sa poate accesa doar propriul salariu
• sa vada informatii despre angajati

2.VPD – FGAC

– Definim o functie pentru politica de securitate
Create function sec_function

(p_schema varchar2, p_obj varchar2)
Return varchar2
As
user VARCHAR2(100);
Begin
user := SYS_CONTEXT(‘userenv’, ‘SESSION_USER’);
return ‘Name = ‘ || user;
end if;
End;

2.VPD – FGAC

– Definim o politica de securitate pentru functie
=> comportament implicit
dbms_rls.add_policy (object_schema => ‘Alice’,

object_name => ‘employees’,
policy_name => ‘my_policy’,
function_schema => ‘Alice’,
policy_function => ‘sec_function’,
sec_relevant_cols=>’salary’);

2.VPD – FGAC

– Bob acceseaza tabelul Employees
Select e_id, name from Employees;
E_id Name
1 Alice
2 Bob
3 John
Select e_id, name, salary from Employees;
E_id Name Salary

2 Bob 60

2.VPD – FGAC

– Definim o politica de securitate pentru functie
=> comportament de mascare
dbms_rls.add_policy (object_schema => ‘Alice’,

object_name => ‘employees’,
policy_name => ‘my_policy’,
function_schema => ‘Alice’,
policy_function => ‘sec_function’,
sec_relevant_cols=>’salary’,
sec_relevant_cols_opt=>dbms_rls.ALL_ROWS);

2.VPD – FGAC

– Bob acceseaza tabelul Employees
Select e_id, name from Employees;
E_id Name
1 Alice
2 Bob
3 John
Select e_id, name, salary from Employees;

E_id Name Salary
1 Alice
2 Bob 60
3 John

2.VPD – FGAC
• Exercitiu
–Ce se intampla cu userul SYS ?
• Are accesul restrictionat la
inregistrarile din BD?
–NU – este mai “presus” de politicile
aplicate  are acces la toate
informatiile din BD

2.VPD – Aplication Context
– Container de memorie cu atribute read-only
– Atributele pot fi populate de un pachet
• secure cache = pereche atribut – valoare
– Functionalitate:
• permite accesarea atributelor = grupate intr-un
namespace
– Atributele pot fi : setate + accesate la nivel de sesiune BD
• Atributele
– au valori de tip string
– Utilizate pentru:
» variabile frecvent apelate (ex. evita interogari frecvente in BD)
» Variabile pentru setarea unui context de securitate

– “USERENV” – application context predefinit
(V$SESSION, V$PROCESS)
• descrie sesiunea utilizatorului curent
• Atribute
– Hostname
– IP_ADDRESS
– OS_USER
– DB_NAME
– etc.

–Definire: nume + pachet (seta atributele)
> CREATE CONTEXT hrapp USING hr_context;
–Setare atribute la nivel de sesiune (pachet)

> DBMS_SESSION. SET_CONTEXT(‘hrapp’,
‘nume_atribut’, ‘valoare’)
–Accesarea atributelor
> SYS_CONTEXT(‘hrapp’, ‘nume_atribut’)

• VPD – Implementare in BD
Step 3. Politica de securitate va
intoarce un predicat in functie Step 0. Definire policy +
de atributele sesiunii sau de functia asociata
continutul bazei de date
Step 5. Instructiunea
Step 1 User trimite o SQL modificata
interogare SQL catre server se executa
Step 2 Tabela tinta va

declansa politica de
Step 4. Serverul va rescrie in mod dinamic
securitate configurata
instructiunea SQL prin adaugarea
predicatului contruit pentru clauza WHERE

2.VPD
• Pasi pentru implementarea VPD

1. Crearea unui pachet pentru setarea contextului
– set_context
2. Crearea context aplication

3. Crearea unei functii pentru a genera predicatul
4. Crearea unei politici pentru a asocia functia cu
tabelul tinta

2.VPD
• Exemplu – definire VPD

– Fiecare angajat poate accesa anumite informatii din
tabelul Customers, in functie de postul de care il detine
in organizatie
• Un functionar – poate accesa doar informatiile
clientilor din regiunea pe care o are in gestiune
• Un manager – poate accesa toate inregistrarile
– Vom presupune ca denumirea posturilor angajatilor
sunt stocate in LDAP (sau in tabelul Employees)
– Acest tip de informatii pot fi accesate si memorate
in application context la T_user_login.

2.VPD

1. Creare pachet pentru setarea contextului
Create package Emp_env_context IS
procedure Set_job_position IS
jp varchar(100);
begin
select job_pos into jp from Employee
where name = SYS_CONTEXT(‘USERENV’,
‘SESSION_USER’);
DBMS_SESSION.SET_CONTEXT(‘emp_env’, ‘job’, jp);
end;
End;
2. Creare application context

Create Context emp_env Using Emp_env_context;
=> Orice atribut din emp_env poate fi setat numai in
cadrul pachetului Emp_env_context

2.VPD
3. Crearea unei functii pentru a genera predicatul
Create function HR.Emp_fct_policy
(object_schema varchar2, object_name varchar2)
return varchar2 IS
begin
if (SYS_CONTEXT(‘emp_env’, ‘job’) = ‘manager’);
return ‘’;
else
....
end;
End;
4. Crearea unei politici pentru a asocia functia cu tabelul

tinta
dbms_rls.add_policy ( object_schema => ‘HR’,
object_name => ‘Customers’,
policy_name => ‘Customer_emp_set’,
function_schema => ‘HR’,
policy_function => ‘Emp_fct_policy’,
statement_types => ‘select’
);

2.VPD

Ce lipseste ?
5. Setarea contextului la nivel de sesiune

• trigger T_logon in BD
Create or Replace Trigger Emp_trig
After Logon On Database
Begin
Emp_env_context. Set_job_position
End

1.VPD
• Mai multe politici

– Putem asocia mai multe politici unui obiect din BD
• in acest caz predicatele generate vor fi concatenate la
clauza WHERE utilizand operatorul AND
• Ex.T = {P1, P2, P3}  WHERE P1 and P2 and P3

1.VPD
• Beneficii VPD ?
– Securitate
• Securitate implementata la nivel de server de BD (nu la niv
aplicatie)
– Simplitate
• Cream 1 VPD cu mai multe optiuni de limitare a accesului la
inregistrarile din baza de date
• Nu trebuie sa definim la nivel de aplicatie / View etc.
– Flexibilitate
• putem implementa o singura politica pentru mai multe
instructiuni SQL ( INSERT, UPDATE, DELETE, SELECT)

QUIZ
• Care sunt mecasnimele utilizate pentru

construirea VPD?
a) Application Context
b) Fine Grained Acces Control

REVIEW
• VPD
– rolul de a restrictiona accesul
– View
• nr mare  dificil de gestionat
• VPD = FGAC + AC
• Fine Grained Acces Control
– functie + politica
– zona de memorie => atribute read-only

DATE
5. Criptarea BD
dr. ing. Enache -Ducoffe Adriana Cristina

Criptarea BD
• Obiective
1. Criptarea BD
• Date in miscare
• Date in repaus
2. Mecanisme de criptare
• TDE
• DBMS_CRYPTO

Criptarea BD
• Criptarea / Decriptarea datelor

–Algoritm de criptare
• Trecut : secret, Astazi : public
–Utilizeaza : cheie / secret
• Managementul cheilor – elementul critic

– Transmiterea securizata a cheilor (useri autorizati)
– Stocarea cheilor (pierderea / useri neautorizati)

Criptarea BD
• De ce avem nevoie de criptare ?

–Componenta cheie a principiului
“defense-in-depth”
• Controlul accesului, planuri BKP, auditarea etc. = practici
necesare
• Plus de protectie  ultima linie de aparare =
implementarea criptarii
–Proteja date “critice”

• Ex. CNP, date medicale despre pacienti,etc.

Criptarea BD
• Costurile criptarii
– Criptarea + descriptarea datelor
• performanta - consumatoare de resurse
• disponibilitatea – pierderea cheii
– Managementul cheilor
• Tansmiterea securizata
– Ex. inregsitrarile HR criptate  partajate toti angajatii
• Administrarea cheilor
– Schimbarea periodica, personal instruit etc.

Criptarea BD
• Categorii de date care pot fi criptate

– Date – in – miscare
• datele transmise catre + de la BD
• Ex. SSL, TLS, IPSEC etc.
– Date – in - repaus
• datele ce rezida in BD
• criptarea se face in interiorul BD
• Ex. TDE (tier DB), DBMS_CRYPTO(tier App) etc.
• Criptarea = confidentialitatea datelor

• Criptarea <> controlul accesului
– (permisiuni, roluri etc.)

2. Criptare - TDE
• Transparent Database Encryption(TDE)

– Cripteaza datele inainte de a fi scrise pe disc
– Decripteaza datele inainte de a fi transmise app
– Criptarea/Decriptarea  nivel SQL

• Transparent pt
– user (nu observa)
– aplicatie (nu tb modificata)
• Backup  va fi criptate

2. Criptare - TDE
• Beneficii TDE
– Criptarea datelor de pe disc
• fisiere de date, redo logs, arhive, fisiere de backup etc.
• elimina accesul direct la datele din fisierele S.O.(root, fisiere
furate de atacator etc.)
– Managementul cheilor este automatizat
• Cheie master  la niv BD (stocata in afara bazei de date)
• Cheie la nivel Tabel – criptare coloane
• Cheie la nivel de Tablespace – criptare tablespace
• BD stie sa asocieze tipul cheie – tipul de operatiune
– Nu necesita modificarea aplicatiei
– Putem cripta indecsi (in anumite conditii)

2. Criptare - TDE
• Componente TDE
– Arhitectura cheilor – 2 –tier
Cheia Tabel Cheia Tablespace
Cheia Master
• Cheie Master – stocata intr-un modul extern (wallet / HSM)

• Cheie Tabel – cripta coloane (stocata Dictionare BD)
• Cheie Tablespace – cripta tablespace (stocata fisierele de date tablespace)
– Gestionarea cheilor – automatizat
• schimbarea periodica – schimbarea cheii Master
– recriptarea cheilor Tabel + Tablespace
– doar cheile sunt recriptate, datele criptate raman aceleasi.
2. Criptare - TDE
• Componente TDE
– Module de securitate externe
• Oracle wallet – container protejat cu parola care
poate stoca certificate, chei de criptare etc.
– format PKCS12
– stocat in afara BD
– stoca istoricul cheilor master (cheile vechi pot fi accesate in cazul
in care date vechi sunt accesate)
• Locatie de stocare a wallet-ului este precizata :
sqlnet.ora

2. Criptare - TDE
• Componente TDE
– Algoritmi (Oracle 11g)
• 3DES168
• AES128
• AES192
• AES256
• Tipuri de date:

2. Criptare - TDE
• Implementare TDE
1. Generare Cheie Master
 Crearea Oracle wallet, daca nu exista deja
 Deschide wallet
 Crearea / recreare Cheie Master pentru TDE
 Re-criptarea Cheilor la nivel de Tabel si a celor la nivel de
TableSpace
2. Crearea unor coloane criptate

3. Crearea unor tablespace criptate

2. Criptare - TDE
• Generarea Cheii Master

> ALTER SYSTEM SET ENCRYPTION KEY
IDENTIFIED BY “parola”
– Daca NU exista wallet (in directorul definit in sqlnet.ora)

• Creaza wallet-ul + utillizeaza parola pentru a proteja wallet-ul
• Deschide wallet-ul
• Genereaza Cheia Master pt TDE
– Daca exista wallet
• Deschide wallet
• Genereaza / Re-genereaza Cheia Master pt TDE
• Re-cripteaza cheile la nivel tabel si la nivel tablespace

2. Criptare - TDE
• Deschidere wallet
> ALTER SYSTEM SET WALLET OPEN
IDENTIFIED BY “parola”
– Inainte de a decripta datele, wallteul trebuie sa fie deschis, altfel

TDE NU va reusi sa decripteze cheile de criptare de la nivelul
Tabelelor sauTablespace
– In cazul in care: BD este deschisa + Wallet-ul e inchis
» accesarea coloanelor criptate  EROARE
– exista wallet – Auto Login (dechis automat la pornirea BD)

2. Criptare - TDE
• Crearea unei COLOANE Criptate

> create table customers (
cust_id number,
cust_name varchar2(100),
cust_phone varchar2(50) encrypt
credit_card varchar2(32));
> alter table customers modify

(credit_card { encrypt | decrypt });
• Modificarea cheii
> alter table customers rekey using „AES256‟
– Informatiile criptate vor fi re-criptate, conform noii chei generate

2. Criptare - TDE
• Limitari – criptarii coloanelor

– Toate coloanele din acelasi tabel  trebuie sa utilizeze
acelasi algoritm de criptare
• ORA-28340: a different encryption algorithm
has been chosen for the table exception.
– NU poate cripta coloane utilizate ca FK

• Fiecare tabel are propria cheiei
• NU utilizati CNP ca PK
– Obiectele din schema SYS nu pot fi criptate

2. Criptare - TDE
• Crearea unui TABLESPACE criptat

> create tablespace encrypt_ts
datafile „…‟ size 100 M
encrypt using „AES128‟
default storage (encrypt)

2. Criptare - TDE
• Avantaje – criptarii Tablespace
– Datele sunt intotdeauna protejate la orice scriere pe disk
• chiar si in cazul operatiilor de tip : SORT, JOIN
– Permite index range scans
• in cazul criptarii TDE coloana – nu este posibil - mai intai trebuie
decriptat continutul
– Putem defini orice tip de index
• Limitari – criptarii Tablespace

– Cheia de criptare Tablespace – NU poate fi modificata
• Solutie: crearea unui alt tablespace cu o noua chei in care sa se mute
obiectele din vechiul tablespace
– NU putem cripta Tablespace-uri de tip: Temporar sau Undo

2. Criptare - TDE
• TDE ofera securitate:

– Datele furate sunt: fisierele fizice din S.O., backup-ul fisierelor etc.
• fara wallet - inutil
– un user autentificat in BD nu vede nicun fel de schimbare =
Transparent

2. Criptare – DBMS_CRYPTO
• DBMS_CRYPTO
– Faciliteaza criptarea datelor la nivel de aplicatie
– Pachet care permite
• criptarea / decriptarea datelor - diversi alg
– DES, 3DES, AES
• generarea de numere aleatoare pentru generarea cheilor
de criptare
• algoritmi de tip hash
– MD5, MD4, SHA-1
– Este parte din schema SYS

• DBMS_CRYPTO – Generare cheie

> Raw_key := DBMS_CRYPTO.RANDOMBYTES
(number_bytes => 24);
– number_bytes – dimensiunea cheii
• ex. AES – 16, 24, 32 bytes

• DBMS_CRYPTO – Criptare
> ecrypted_raw := DBMS_CRYPTO.ENCRYPT (
src => raw_input,
Type =>dbms_crypto.ENCRYPT_AES256,
Key => raw_key);
– src – in format RAW

• UTL_RAW – pachet pentru convertirea in / din format RAW
> result := UTL_RAW.CAST_TO_RAW(input);
• DBMS_CRYPTO – Decriptare
> ecrypted_raw := DBMS_CRYPTO.DECRYPT (
encrypted_raw,
dbms_crypto.ENCRYPT_AES256,
raw_key);

QUIZ
• Pentru a utiliza TDE trebuie sa generam, o

cheie master pentru cheia de la nivelul tabelului
si o cheie master separata pentru cheia de la
nivelul Tablespace ?
a) DA
b) NU

QUIZ
• Pentru a utiliza TDE trebuie sa generam, o

cheie master pentru cheia de la nivelul tabelului
si o cheie master separata pentru cheia de la
nivelul Tablespace ?
a) DA
b) NU

QUIZ
• Pachetul DBMS_CRYPTO permite utilizatorilor

sa :
a) Genereze chei in mod aleatoriu
b) Implementeze criptarea coloanelor la nivel de
aplicatie

QUIZ
• Pachetul DBMS_CRYPTO permite utilizatorilor

sa :
a) Genereze chei in mod aleatoriu
b) Implementeze criptarea coloanelor la nivel de
aplicatie

REVIEW
• Criptarea BD
– Date in miscare
– Date in repaus
• TDE
– Tipuri de chei: master, tabel, tablespace
– Transparent : user + aplicatie
• DBMS_CRYPTO
– Pachet criptare / decriptare
– Implementarea nivel aplicatie

DATE
6. Backup si Restore BD
dr. ing. Enache -Ducoffe Adriana Cristina

Securitatea BD
• Obiective
1. Backup
• Cold / hot
• Consistent / Inconsistent
• Full / Incremental (diferential / cumulativ)
2. Recover
• Restore + Recover

1. Backup
• Backup
– Polita de asigurare
– "Cât de mult sunt eu dispus să plătesc şi cât de mult
pierderea este acceptabilă pentru mine? “
– Frecventa de salvare a datelor = cantitatea
de date pe care suntem dispusi sa o pierdem
– Costuri
• durata acceptabila de timp cat sistemul va fi neoperational
• valoarea acceptabilă a pierderilor de date
– Eroare sistem (defectarea unui disc, stergerea permanenta a unor fisiere de pe disc
etc.)
• durata crearii backup-ului
• spatiul de pe disc pe care il ocupa

1. Backup
• Backup
– strategie de backup pentru a minimiza pierderea de date
– se pot pierde date ca rezultat al defectelor hardware sau
software :
• Utilizarea accidentală sau rău intenţionată a instrucţiunii DELETE.
• Utilizarea accidentală sau rău intenţionată a instrucţiunii UPDATE -de
exemplu, nu se foloseşte o clauză WHERE cu instrucţiunea UPDATE
(toate rândurile sunt actualizate, mai degrabă decât un singur rând
dintr-un tabel).
• Stergerea accidentala a unor fisiere din BD.
– Fisierul de control – un mai putem BD – starea mount
– Fisiere de date – numai putem BD – starea open
• Viruşi distructivi.
• Dezastre naturale, cum ar fi incendii, inundaţii, cutremure.
• Furt.

1. Backup
• Backup-ul poate fi realizat

– User managed – manual de catre administrator
– RMAN (Recovery Manager) – utilitar nivelul BD
• Tipuri de Backup
– Physical Backup – copierea fisierelor de pe disk
– Logical Backup – copierea obiectelor din BD

1. Backup
• BD oprita / pornita
– Cold Backup – offline
– Hot Backup – online
• Tipul de Recovery
– Consistent – refacerea BD NU necesita etapa recovery
• restore backup este suficient (SCN_datafile = SCN_controlfile)
• Etapa de Recovery  nu este necesara
• Offline backup
– Inconsistent – refacerea BD necesita etapa recovery
• Restore de backup nu este suficient (SCN_datafile !=SCN_controlfile)
• Etapa de Recovery  aplicarea arhivelor
• Online backup

1. Backup
• Tipuri de Backup
BACKUP COLD BACKUP

CONSISTENT • NU nec. recovery
BACKUP HOT BACKUP/RMAN backup

INCONSISTENT • nec. recovery

1. Backup
• Ce trebuie sa salvam ?
BD – MOUNT STAGE BD – OPEN STAGE
Fisierul de Fisierele de
CONTROL DATE

1. Backup
IMPLEMENTARE BACKUP

1. Backup
• Cold Backup - offline

– Backup consistent
– BD – trebuie oprita T_backup
• Downtime
• Userii nu pot accesa BD
– Implementarea – copierea bruta a fisierelor din S.O.
– Concret – acest tip de backup NU este utilizat
• Nu se accepta T downtime
• Recuperare – incompleta  exemplul

1. Backup
Cold Backup
- BD shutdown
- Copiere fisiere

1. Backup
Cold Backup
- BD shutdown
- Copiere fisiere

1. Backup
Cold Backup
- BD shutdown
- Copiere fisiere
Cold Backup
- Consistent
- Recuperarea BD numai pana
T_crearea_cold Backup
- Recover - incomplet

1. Backup
• Hot Backup - online

– Backup inconsistent
– BD – NU trebuie oprita T_backup
• NU Downtime
• BD – trebuie sa fie in modul ArchiveLog
– Implementarea –
• user managed
– BD modificat Begin Backup mode
– Copiere fisiere S.O. intr-o locatie sigura
– BD modificat End Backup mode
– Switch Log file
– Copiere Arhive Logs
• RMAN

1. Backup
Hot Backup
- BD running
- BD – modul archivelog

1. Backup
Hot Backup
- BD running
Fisiere arhive
Fisiere arhive
Fisiere arhive

1. Backup
Hot Backup
- BD running
Fisiere arhive
Fisiere arhive
Hot Backup
Fisiere arhive - Inconsistent
- Restore BD + Aplicare Arhive
- Recover - completa

1. Backup

– Recuperarea BD
• Completa – T_fail
• Restore– copierea fisierelor backup
• Recover – aplicarea arhivelor (archived logs)

1. Backup
• RMAN
– Tool Oracle – vine o data cu binarele BD
– Permite operatiuni: backup, restore, recover
– Mai rapid decat user managed
• Backup la nivel de block - doar acele blocks utilizate
• Procesare paralela – crearea channels
– Detecteaza + repara blocurile corupte
– Destinatii multiple backup
• Ex. Disk, tape etc.
– Pt a utiliza RMAN – BD trebuie sa fie CEL PUTIN in
MOUNT STAGE  fis de control

1. Backup
• Metodologia Backup
• BACKUP – toata BD
FULL • NU se pot aplica backup-uri
BACKUP incrementale
• Level0  Full DB Backup

INCREMENTAL
• Level1  Backup doar
BACKUP schimbarile de la ultimul backup

1. Backup
• RMAN
– FULL Backup
RMAN > BACKUP DATABASE [PLUS ARCHIVELOG];
― ALTER SYSTEM ARCHIVE LOG CURRENT => checkpoint consistent
― Salveaza arhivele
― Salveaza datele
― ALTER SYSTEM ARCHIVE LOG CURRENT
― Salveaza arhivele generate T_backup
– INCREMENTAL Backup
• Level 0 = FULL backup
RMAN > BACKUP INCREMENTAL LEVEL 0 DATABASE;
• Level 1 = INCREMENTAL backup – multinivel

RMAN > BACKUP INCREMENTAL LEVEL 1 DATABASE;

1. Backup
• RMAN - Incremental
– DIFERENTIAL (parintele = Level 0 / Level 1)
• backup doar modificarile de la ultimul backup incremental
Level 0 / Level 1
• Avantaj:
– Backup: rapid + ocupa putin spatiu
• Dezavantaj:
– Recovery: lent-trebuie aplicate toate backup diferentiale Level 1
RMAN> BACKUP INCREMENTAL LEVEL 1

DATABASE;
- Optinea implicita

1. Backup
– DIFERENTIAL (parintele = Level 1)

1. Backup
– CUMULATIV (parintele = Level 0)
• Backup doar modificarile de la ultimul backup incremental
Level 0
• Avantaj:
– Recover : rapid ( 1 Level 0 + 1 Level 1)
• Dezavantaj:
– Backup: lent + ocupa mai mult spatiu
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE

DATABASE;

1. Backup
– CUMULATIV(parintele = Level 0)

2. Recover
• SCN – System Change Number

– Numar gestionat intern prin care BD jurnalizeaza
modificarile din BD
– T_commit al Tranzactii
• LGWR scrie in mod sincron:
– modificarile din SGA (RLBuffer)  fisierul Redo Log
– SCN asociat tranzactiei  fisierul Redo Log online
– T_checkpoint
• Modificarile din SGA  DBWn  scriere pe disk
• Update SCN  Control File + header Data File
– T_recovery  doar acele operatii dupa checkpoint
trebuie recuperate (recovery) din arhive

2. Recover
• Recuperarea BD
– RESTORE
• identifica si copiaza pe disc fisierele de date din backup si
le face disponibile la nivelul BD
• BD – stare : mounted
– RECOVERY
• Preia copia restored + aplica modificarile care au avut loc
intre timp = aplicare modificarilor din arhive

2. Recover
• Restore + Recovery

2. Recover
• Instance Fail
– Exemple: pana de curent (SO), Shutdown abort etc.
– Recuperarea BD – aproape automat la pornirea
instantei
• ROLLING FORWARD  Tranzactii_commited (nu au fost
scrise pe disc)
• ROLLING BACK  Tranzactii_uncommited
• Fisiere Redo Log – inregistreaza modificarile din BD
– Retin tranzactiile + starea lor (commited/ uncommited)
– Putem regenera Segmentele Rollback (valorile vechi)

2. Recover
• Rolling Forward + Rolling Back

2. Recover
• Alte situatii:
– Sunt afectate fisierele BD: data files, control file,
online redo log files.
– Recovery
• Complet – am adus BD dinainte fail = toate modificarile
• Incomplet - point – in –time recovery
– Cand putem avea RECOVERY incomplet ?
• Pierderea fisiere redo log
• Pierderea unor arhive – arhivele lipsesc / corupte

2. Recover
• Tipuri de Recovery Incomplete

– Time-based – clauza UNTIL TIME
• Precizarea point-in-time de recuperare a BD
• Este folosit: user sterge informatii critice din BD
– Cancel Based – prompt de recovery introducem
CANCEL, in locul unui fisier log
• Fisierul redo log curent – alterat
• Arhiva - pierduta
– Change Based
• clauza UNTIL CHANGE - in cazul user managed backups
• clauza UNTIL SCN – in cazul RMAN backup (SCN –ul
ultimei tranzactii commited)

QUIZ
• Care dintre afirmatiile urmatoare sunt

adevarate?
a) Cold Backup este consistent
b) Hot Backup este consistent
c) Cold Backup este inconsistent
d) Hot Backup este inconsistent

QUIZ
• Care dintre afirmatiile urmatoare sunt

adevarate?
a) Cold Backup este consistent
b) Hot Backup este consistent
c) Cold Backup este inconsistent
d) Hot Backup este inconsistent

REVIEW
• Backup – polita de asigurare

– Full
– Incremental
• Diferential - default
• Cumulativ
• Recover
– Restore – data files
– Recovery – aplicare arhive

All BD

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

All BD

Încărcat de

Drepturi de autor:

Formate disponibile

SECURITATEA BAZELOR DE

dr. ing. Enache Adriana 1

dr. ing. Enache Adriana 2

“Hardware is easy to protect: lock it in a

dr. ing. Enache Adriana 3

dr. ing. Enache Adriana 4

– Accesul neautorizat la date

dr. ing. Enache Adriana 5

dr. ing. Enache Adriana 6

• Securitatea BD – Cerinte fundamentale

Mentinerea validitatii datelor

• Aplicatie de plata a salariilor

dr. ing. Enache Adriana 8

• Securitatea BD – Cerinte fundamentale

Mentinerea validitatii datelor

dr. ing. Enache Adriana 10

• Principiul – Least Privileged

dr. ing. Enache Adriana 11

1. Gestiune Useri, Privilegii, 4. Criptarea BD

2. Auditare 5. Backup + Restore

dr. ing. Enache Adriana 13

dr. ing. Enache Adriana 14

1.1 Arhitectura BD Oracle

dr. ing. Enache Adriana 1

dr. ing. Enache Adriana 2

• Memoria – SGA = System Global Area

dr. ing. Enache Adriana 5

dr. ing. Enache Adriana 6

Fisierele de redo log

• Structura Logica vs Structura Fizica

dr. ing. Enache Adriana 9

dr. ing. Enache Adriana 10

• START Online : fisierele date + redoLog

dr. ing. Enache Adriana 11

dr. ing. Enache Adriana 12

• Care dintre urmatoarele componente fac parte

dr. ing. Enache Adriana 13

• Care dintre urmatoarele componente fac parte

dr. ing. Enache Adriana 14

dr. ing. Enache Adriana 15

2. Gestiune utilizatori, privilegii, roluri, profile

dr. ing. Enache Adriana 1

dr. ing. Enache Adriana 2

• Crearea USER  creare

dr. ing. Enache Adriana 3

dr. ing. Enache Adriana 4

dr. ing. Enache Adriana 5

• Sintaxa pt. creare utilizator:

CREATE USER username

dr. ing. Enache Adriana 6

dr. ing. Enache Adriana 7

dr. ing. Enache Adriana 8

dr. ing. Enache Adriana 9

• Modificare date User

– LOCK – momentul in care user este logat ???

dr. ing. Enache Adriana 10

• Modificare date User

dr. ing. Enache Adriana 11

• Modificare date User - Quota setam ca fiind 0

dr. ing. Enache Adriana 12

• Modificare date User

dr. ing. Enache Adriana 13

DROP USER username [CASCADE]