Dezvoltarea unui plan de auditare

Dezvoltarea unui plan de auditare

Auditarea este procesul de inregistrare a operatiunilor efectuate in baza de date. Se poate afla ce privilegii de sistem sunt folosite si cat se poate de des, cati utilizatori sunt conectati, cat dureaza o sesiune medie, ce comenzi sunt folosite relativ la un tabel, etc.De obicei se auditeaza pentru a se asigura ca nici-un utilizator neautorizat nu sterge date din dictionarul de date sau acceseaza tabele pe care nu ar avea privilegiul sa le acceseze.

RDBMS Oracle pune la dispozitie functii care permit auditarea celor mai multe actiuni care pot avea loc intr-o baza de date. Aceste actiuni includ (dar nu se limiteaza doar la acestea) urmatoarele:

Vizualizarea, modificarea, sau stergerea informatiilor din tabele

Crearea sau distrugerea unor obiecte ca: tabele, indexi, vederi, proceduri, declansatoare, etc.

Executarea programelor.

Functionalitatea standard a Oracle nu permite auditarea la nivel de rand. Cu alte cuvinte, prin auditarea standard, se pot audita actiuni care au avut loc asupra unui tabel, dar nu ceea ce s-a schimbat intr-un anume rand al tabelului. Pentru a se putea monitoriza cea anume s-a schimbat intr-o anumita coloana sau tabel, sau ce actiune s-a realizat exact, asupra unui rand al unui tabel, este necesar un cod specific.

1. De ce este necesara auditarea?

Primul pas in dezvoltarea unui plan de auditare este determinarea motivelor pentru care este necesara o auditare. Exista doua motive principale pentru auditare:

Auditare pentru securitate-pentru a determina daca cineva incearca sa intre in sistem

Auditarea pentru performanta-pentru a determina de ce sistemul este atat de incet.

1.1 Auditarea pentru confirmarea suspiciunilor

Un motiv bun pentru realizarea unui plan de auditare este pentru a determina daca cineva sau ceva cauzeaza o problema. De exemplu, poate exista suspiciunea ca date sunt sterse dintr-un tabel din care nu ar trebui sa se piarda inregistrari. Pentru a se verifica daca suspiciunea este intemeiata sau nu se poate activa auditarea pentru a monitoriza stergerile din acel tabel. Limitand scopul auditarii se obtine o imagine mai clara a activitatii care se urmareste. Pot exista situatii in care activitatea suspecta poate fi atat de subtila incat, mai intai trebuie activata auditarea generala si apoi, dupa ce au fost evaluate rezultatele auditarii, sa se indrepte auditarea catre un punct mai aproape de sursa problemei.

1.2. Auditarea pentru analiza performantei

Daca se realizeaza auditarea pentru determinarea volumului traficului in anumite zone ale bazei de date, se recomanda ca auditarea sa indrepte catre acele zone specifice care vor pune la dispozitie informatiile necesare. Astfel, daca se doreste monitorizarea I/O, atunci auditarea pentru obiecte nu va atinge acest scop. De asemenea, auditarea ar trebui realizata pe o perioada stabilita de timp pentru a se limita volumul de date colectate. Astfel informatiile obtinute nu vor fi aglomerate cu date nenecesare. Odata ce au fost adunate suficiente informatii pentru a indeplini scopul auditarii, se pot arhiva rezultatele auditarii si se pot sterge din istoricul auditarii bazei de date pentru a elibera spatiu in spatiul tabel system.

2. Unde sa auditezi?

Odata ce s-a hotarat activarea unei forme de auditare, urmatorul pas este hotararea locatiei unde vor fi salvate informatiile obtinute in urma auditarii. Daca sistemul de operare suporta o cale (trail) de auditare care este stocata in afara bazei de date, se poate inscrie calea de auditare fie direct intr-un fisier al sistemului de operare sau in baza de date. Doi parametrii ai fisierului INIT.ORA controleaza actiunea de auditare:

AUDIT_FILE_DEST

Transmite sistemului Oracle numele directorului in care va fi scrisa cale de auditare. Valoarea implicita pentru acest parametru este $ORACLE_HOME/RDBMS/AUDIT.

AUDIT_TRAIL

Activeaza sau dezactiveaza auditarea.

Pentru AUDIT_TRAIL, se poate specifica una din valorile: "NONE", "OS", sau "DB". Daca se specifica "NONE" (valoarea implicita), nu va avea loc nici o auditare implicita. Daca se specifica "OS" auditarea intregului sistem va fi activata si rezultatele scrise intr-un fisier in directorul AUDIT FILE DEST. Informatia scrisa in fisierul sistemului de operare va fi codata si nu va putea fi citita. Daca se specifica "DB" auditarea intregului sistem va fi activata si rezultatele stocate in tabelul SYS.AUD$ in schema utilizatorului sys intr-un format necodat, lizibil.

Oracle pune la dispozitie cateva vederi ale tabelului SYS.AUD$ pentru a face vizualizarea informatiilor mai usoara. Utilitarele Oracle, ca SQL*Plus pot fi folosite pentru a genera rapoarte despre rezultatele auditarii.

2.1. Despre tabelul SYS.AUD$

Deoarece tabelul SYS.AUD$ este proprietatea utilizatorului sys, valorile sunt stocate in spatiul tabel sistem. Multe activitatii de auditare pot avea ca rezultat fragmentarea spatiului tabel system. De aceea, daca se hotaraste folosirea bazei de date pentru a pastra informatiile auditarii, este necesara mutarea tabelului SYS.AUD$ intr-un alt spatiu tabel. Pentru a realiza aceasta este necesara conectare la sistem pe contul utilizatorului sys. Totusi se poate lucra din SQL*Plus daca se doreste. Adica nu este obligatorie conectarea prin utilitarul Server Manager pentru a se realiza acest lucru.

Este indicat sa se creeze un nou spatiu tabel cu nume semnificative ca 'audit_storage' sau 'audit_info.' Dimensionarea spatiului tabel pentru a se asigura spatiul necesar pentru pastrarea informatiilor obtinute in urma auditarii, poate fi dificila. Initial, se poate dimensiona spatiul tabel mai mare, si se poate ajusta apoi in functie de nevoile particulare auditarii.

Volumul diferitelor activitati care se auditeaza.

Cantitatea de informatii care trebuie mentinuta online.

Cat timp se doreste mentinerea acelui tabel; daca tabelul este prea mic, este necesar sa se arhiveze si/sau stearga din tabel foarte des.

Odata ce spatiul tabel a fost creat, se creeaza un tabel temporar folosind comanda

AS SELECT * FROM SYS.AUD$, apoi se distruge tabelul curent SYS.AUD$ , si se redenumeste tabelul temporar AUD$.

SQL> connect sys/<appropriate_sys_password>

Connected.

SQL> CREATE TABLESPACE audit_storage

2 DATAFILE 'E:ORANTDATABASEAUDSTOR01.ORA'

3 SIZE 40M;

Tablespace created.

SQL> CREATE TABLE audit_temp

2 TABLESPACE audit_storage

3 STORAGE (INITIAL 10M

4 NEXT 1M

5 MINEXTENTS 1

6 MAXEXTENTS 10

7 PCTINCREASE 1)

8 AS SELECT *

9 FROM sys.aud$;

Table created.

SQL> DROP TABLE sys.aud$;

Table dropped.

SQL> RENAME audit_temp TO aud$;

Table renamed.

SQL> SELECT table_name, tablespace_name

2 FROM user_tables

3 WHERE table_name = 'AUD$';

TABLE_NAME TABLESPACE_NAME

AUD$  AUDIT_STORAGE

2.2. O problema

Exista o problema in abordarea descrisa mai sus. Cand se creeaza un tabel as SELECT * from AUD$ nu sunt pastrate vederile bazate pe tabelul AUD$. Cand se distruge adevaratul tabel AUD$, vederile vor deveni invalide. Dupa redenumirea tabelului temporar AUD$, vederile vor fi inca invalide si trebuie recompilate. Pentru recompilarea manuala a vederilor:

SQL> ALTER VIEW dba_audit_exists COMPILE;

View altered.

Pentru a afla lista vederilor invalide, se poate realiza urmatoarea interogare-conectat ca utilizator sys.

SQL> COLUMN object_name FORMAT a30

SQL> SELECT object_name, status

2 FROM user_objects

3 WHERE status = 'INVALID';

OBJECT_NAME STATUS

DBA_AUDIT_EXISTS INVALID

DBA_AUDIT_OBJECT  INVALID

DBA_AUDIT_SESSION INVALID

DBA_AUDIT_STATEMENT  INVALID

USER_AUDIT_OBJECT INVALID

USER_AUDIT_SESSION INVALID

USER_AUDIT_STATEMENT INVALID

USER_AUDIT_TRAIL  INVALID

8 rows selected.

Recompilarea vederilor cu noul tabel SYS.AUD$ va avea ca rezultat transformarea vederilor din invalide in valide pentru tabelul redenumit.

2.3 Privilegii de auditare predefinite

Chiar daca se activeaza parametrii de auditare prin fisierul de parametrii INIT.ORA, numai acele zone pentru care se specifica vor fi auditate. Pentru ca un cont sa fie capabil sa activeze auditarea, trebuie ca privilegiul AUDIT SYSTEM sa fie acordat acelui cont.

Chiar si fara privilegii acordate unui cont, sunt cateva actiuni care vor fi stocate intr-un fisier al sistemului de operare, chiar daca auditarea este activata sau nu. Cand o baza de date este creata, este creat un fisier care este numit de obicei alert log. Locatia si numele acestui fisier sunt dependente de sistemul de operare. Pe un sistem Windows NT pe care ruleaza Oracle8 cu o baza de date numita ORCL, de exemplu, alert log este numit

orclALRT.LOG si se gaseste in directorul C:orantRDBMS80TRACE. Actiunile legate de securitate din alert log pentru baza de date includ:

• Pornirea bazei de date
• Oprirea bazei de date
• Orice conectare realizata de un cont care are privilegii de administrator
• Orice schimbare in structura bazei de date, ca, de exemplu, crearea unui spatiu tabel sau adaugarea unui fisier de date.

Cand se doreste o conectare ca sys sau internal, in alert log nu este generata o inregistrare. Singurul mod in care se poate realiza conectarea la o baza de date ca sys sau internal este prin un cont al sistemului de operare care, fie apartine unui grup DBA fie are privilegiul OPSYS. Aceste conturi ocolesc securitatea normala a bazei de date, si deci conectarea lor la baza de date ca utilizatori privilegiati se presupune ca este normala si nu va fi inregistrata.

Cu auditarea activata si informatia stocata fie in baza de date sau in sistemul de operare (sau amandoua), spatiul devine o problema. Daca spatiul tabel sau discul pe care calea de auditare este scrisa se umple, calea de auditare va inceta sa mai fie conectata si informatiile se vor pierde. De aceea trebuie sa se asigure un spatiu amplu pentru zona unde se vor scrie informatiile obtinute in urma auditarii.

3. Cum functioneaza auditarea

Implicit in Oracle8, urmatoarele evenimente au loc cand o baza de date este creata.

1. CATALOG.SQL ruleaza si apeleaza cateva alte scripturi.
2. CATAUDIT.SQL este rulat ca unul dintre scripturile apelate de CATALOG.SQL.
3. Vederi pentru auditare sunt create.
4. Este creat cate un sinonim public pentru fiecare dintre vederile pentru auditare.
5. Este permis accesul public pentru a activa SELECT pentru fiecare dintre vederile pentru auditare.

Asadar, posibilitatea de a se audita o baza de date exista din momentul in care baza de date este creata. Pe majoritatea platformelor scriptul CATAUDIT.SQL poate fi gasit in directorul $ORACLE_HOME/RDMBS80/ADMIN.

3.1. Vederile pentru auditare

Vederile pentru auditare necesita resurse inainte de a fi activate. Rularea scriptului CATAUDIT.SQL va crea urmatoarele vederi pentru auditare:

AUDIT_ACTIONS

ALL_DEF-AUDIT_OPTS

DBA_OBJ_AUDIT_OPTS

USER_OBJ_AUDIT_OPTS

DBA_STMT_AUDIT_OPTS

DBA_PRIV_AUDIT_OPTS

DBA_AUDIT_TRAIL

USER_AUDIT_TRAIL

DBA_AUDIT_SESSION

USER_AUDIT_SESSION

DBA_AUDIT_STATEMENT

USER_AUDIT_STATEMENT

DBA_AUDIT_OBJECT

USER_AUDIT_OBJECT

DBA_AUDIT_EXISTS

In documentatia ultimei vederi DBA_AUDIT_EXISTS, documentatia Oracle din script nu inseamna ca DBA este un clarvazator. Declaratia "Numai DBA pot vedea informatii din calea de auditare despre obiecte care nu exista" este o referinta la o eroare de cod a Oracle care apare atunci cand o interogare solicita un obiect la care utilizatorul nu are privilegii de acces. De exemplu, o eroare cu codul 942 este generata , cand este facuta o cerere pentru un tabel al carui nume nu este inregistrat in dictionarul de date. Aceasta eroare transmite utilizatorului ca tabelul sau vederea nu exista. Aceasta eroare poate aparea si atunci cand, din greseala se tasteaza gresit numele unui tabel. Totusi, un angajat care primeste in mod repetat aceasta eroare, ar putea fi banuit ca incearca sa aiba acces la informatii din zone in care nu ar trebui sa aiba acces. Daca exista aceasta banuiala se poate activa auditarea pentru a urmarii erorile 942 (printre altele). Astfel, exista posibilitatea de a descoperi pe cineva care primeste in mod repetat aceasta eroare.

3.2. Actiuni disponibile pentru auditare

Intr-o baza de date Oracle8, exista 121 tipuri de auditari care pot fi realizate. Odata ce scriptul CATAUDIT.SQL a fost rulat, se poate realiza un select pe AUDIT_ACTIONS pentru a vizualiza lista completa a actiunilor care se pot realiza. Aceasta lista contine

SQL> SELECT * FROM audit_actions;

ACTION NAME

0 UNKNOWN

1 CREATE TABLE

2 INSERT

3 SELECT

4 CREATE CLUSTER

5 ALTER CLUSTER

6 UPDATE

7 DELETE

8 DROP CLUSTER

9 CREATE INDEX

10 DROP INDEX

11 ALTER INDEX

12 DROP TABLE

13 CREATE SEQUENCE

14 ALTER SEQUENCE

15 ALTER TABLE

16 DROP SEQUENCE

17 GRANT OBJECT

18 REVOKE OBJECT

19 CREATE SYNONYM

20 DROP SYNONYM

21 CREATE VIEW

22 DROP VIEW

23 VALIDATE INDEX

24 CREATE PROCEDURE

25 ALTER PROCEDURE

26 LOCK

27 NO-OP

28 RENAME

29 COMMENT

30 AUDIT OBJECT

31 NOAUDIT OBJECT

32 CREATE DATABASE LINK

33 DROP DATABASE LINK

34 CREATE DATABASE

35 ALTER DATABASE

36 CREATE ROLLBACK SEG

37 ALTER ROLLBACK SEG

38 DROP ROLLBACK SEG

39 CREATE TABLESPACE

40 ALTER TABLESPACE

41 DROP TABLESPACE

42 ALTER SESSION

43 ALTER USER

44 COMMIT

45 ROLLBACK

46 SAVEPOINT

47 PL/SQL EXECUTE

48 SET TRANSACTION

49 ALTER SYSTEM

50 EXPLAIN

51 CREATE USER

52 CREATE ROLE

53 DROP USER

54 DROP ROLE

55 SET ROLE

56 CREATE SCHEMA

57 CREATE CONTROL FILE

59 CREATE TRIGGER

60 ALTER TRIGGER

61 DROP TRIGGER

62 ANALYZE TABLE

63 ANALYZE INDEX

64 ANALYZE CLUSTER

65 CREATE PROFILE

66 DROP PROFILE

67 ALTER PROFILE

68 DROP PROCEDURE

70 ALTER RESOURCE COST

71 CREATE SNAPSHOT LOG

72 ALTER SNAPSHOT LOG

73 DROP SNAPSHOT LOG

74 CREATE SNAPSHOT

75 ALTER SNAPSHOT

76 DROP SNAPSHOT

77 CREATE TYPE

78 DROP TYPE

79 ALTER ROLE

80 ALTER TYPE

81 CREATE TYPE BODY

82 ALTER TYPE BODY

83 DROP TYPE BODY

84 DROP LIBRARY

85 TRUNCATE TABLE

86 TRUNCATE CLUSTER

91 CREATE FUNCTION

92 ALTER FUNCTION

93 DROP FUNCTION

94 CREATE PACKAGE

95 ALTER PACKAGE

96 DROP PACKAGE

97 CREATE PACKAGE BODY

98 ALTER PACKAGE BODY

99 DROP PACKAGE BODY

100 LOGON

101 LOGOFF

102 LOGOFF BY CLEANUP

103 SESSION REC

104 SYSTEM AUDIT

105 SYSTEM NOAUDIT

106 AUDIT DEFAULT

107 NOAUDIT DEFAULT

108 SYSTEM GRANT

109 SYSTEM REVOKE

110 CREATE PUBLIC SYNONYM

111 DROP PUBLIC SYNONYM

112 CREATE PUBLIC DATABASE LINK

113 DROP PUBLIC DATABASE LINK

114 GRANT ROLE

115 REVOKE ROLE

116 EXECUTE PROCEDURE

117 USER COMMENT

118 ENABLE TRIGGER

119 DISABLE TRIGGER

120 ENABLE ALL TRIGGERS

121 DISABLE ALL TRIGGERS

122 NETWORK ERROR

123 EXECUTE TYPE

157 CREATE DIRECTORY

158 DROP DIRECTORY

159 CREATE LIBRARY

121 rows selected.

Numarul si tipul actiunilor de auditare care se pot realiza depinde de la versiune la versiune a SGBDR Oracle.

3.3. Optiuni de auditare

Optiunile predefinite de auditare care pot fi luate pentru un obiect sunt de obicei activate cu clauza WHENEVER SUCCESSFUL sau WHENEVER UNSUCCESSFUL. Comanda pentru activarea auditarii cand un utilizator ralph a modificat cu succes o valoare intr-un tabel ar arata astfel:

AUDIT UPDATE BY ralph BY SESSION WHENEVER SUCCESSFUL;

Optiunile de auditare predefinite si prescurtarile lor sunt:

Pentru vederile USER_OBJ_AUDIT_OPTS si DBA_OBJ_AUDIT_OPTS, valorile din fiecare coloana a vederii, de la coloana ALT pana la coloana UPD sunt siruri de 3 caractere reprezentand diferite nivele de detaliu. Celelalte coloane din aceasta vedere sunt OWNER, OBJECT_NAME si OBJECT_TYPE. Pentru fiecare obiect pe care un utilizator il are, va exista o intrare in vederile USER_OBJ_AUDIT_OPTS si DBA_OBJ_AUDIT_OPTS. Un posesor al unui tabel poate activa auditarea pentru retine de fiecare data cand cineva inlatura date din tabelul lui.

Deoarece se poate activa auditarea de fiecare data cand un utilizator acceseaza un obiect sau , alternativ, la fiecare sesiune a utilizatorului, nivelele de detalii sunt Access (A), Session (S), sau None (-). Valorile apar in secvente ca 'A/S', 'A/-', etc. Valoarea care precede "/" indica nivelul de auditare daca actiunea a avut succes. Valoarea de dupa "/" indica nivelul de auditare daca actiunea nu a avut succes. Aceasta forma de afisare a fost aleasa pentru a pentru a permite afisarea tuturor formelor de auditare pe o singura linie. Din acelasi motiv coloanele au nume alcatuite din trei litere. Un exemplu de linie din vederea DBA_OBJ_AUDIT_OPTS fara coloanele OBJECT_NAME si OBJECT_TYPE-fara nici-un fel e auditare activata-ar arata asa:

ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE CRE REA WRI

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-

Nu exista nici un nivel de actiune in acest exemplu, deci exista cate o liniuta "-" de fiecare parte a "/" .

3.4. Vederi relative la SYS.AUD$

Toata informatia referitoare la audit este inmagazinata in tabelul, SYS.AUD$. Vederea folosita cel mai des pentru a obtine date despre rezultatele auditarii este vederea DBA_AUDIT_TRAIL. Acesta contine urmatoarele coloane:

SQL> DESCRIBE dba_audit_trail

Name Null? Type

----- ----- --------- ----- ------- -------- ----

OS_USERNAME VARCHAR2(255)

USERNAME VARCHAR2(30)

USERHOST VARCHAR2(128)

TERMINAL VARCHAR2(255)

TIMESTAMP NOT NULL DATE

OWNER VARCHAR2(30)

OBJ_NAME VARCHAR2(128)

ACTION NOT NULL NUMBER

ACTION_NAME VARCHAR2(27)

NEW_OWNER VARCHAR2(30)

NEW_NAME VARCHAR2(128)

OBJ_PRIVILEGE VARCHAR2(16)

SYS_PRIVILEGE VARCHAR2(40)

ADMIN_OPTION VARCHAR2(1)

GRANTEE VARCHAR2(30)

AUDIT_OPTION VARCHAR2(40)

SES_ACTIONS VARCHAR2(19)

LOGOFF_TIME DATE

LOGOFF_LREAD NUMBER

LOGOFF_PREAD NUMBER

LOGOFF_LWRITE NUMBER

LOGOFF_DLOCK VARCHAR2(40)

COMMENT_TEXT VARCHAR2(4000)

SESSIONID NOT NULL NUMBER

ENTRYID NOT NULL NUMBER

STATEMENTI NOT NULL NUMBER

RETURNC NOT NULL NUMBER

PRIV_ RAW MLSLABEL

SESSION_LABEL RAW MLSLABEL

4.Auditarea si performanta

De obicei auditarea nu afecteaza drastic performanta, dar exista un impact. In general costurile pentru realizarea auditarii nu depasesc 5%. Activarea auditarii in diferite zone ale bazei de date poate afecta performanta in doua moduri.

Poate umple spatiul de stocare

Poate incetinii timpul de raspuns pentru niste interogarii.

Daca se activeaza auditarea pentru un tabel cu care utilizatorii interactioneaza in mod frecvent, va exista cate o intrare pentru fiecare data cand intervin actiuni de auditare. In cadrul unui program PL/SQL, comenzile sunt auditate individual. De aceea, daca un script PL/SQL este rulat cu auditarea activata pe un tabel care este accesat in cadrul unei instructiuni loop, de fiecare data cand tabelul este accesat o inregistrare va fi scrisa in calea de auditare.

Daca se realizeaza o auditare in baza de date, fiecare rand din datele auditate este scris in spatiul tabel system, implicit. Cu cat mai multe obiecte sunt auditate, cu atat este mai mare cantitatea de spatiu consumat si mai posibila fragmentarea spatiului tabel. Auditarea trebuie sa se realizeze astfel in cat sa indeplineasca scopurile urmarite fara sa fie excesiva. Monitorizarea cantitatii de date care sunt stocate zilnic in tabelul SYS.AUD$ pe perioada cand auditarea este activata poate ajuta DBA sa concluzioneze cat de des tabelul SYS.AUD$ trebuie arhivat si sters.

Odata ce un utilizator s-a conectat la o baza de date cu privilegii sau sesiuni de auditare activate, auditarea va ramane in vigoare pentru toata acea sesiune, chiar daca va fi dezactivata dupa ce sesiune a inceput. Pe de alta parte, daca sunt facute modificari in optiunile auditarii obiectelor din schema, aceste optiuni devin active imediat si au efect in timpul sesiunii curente.

5. Auditatea predefinita

Anumite actiuni vor fi inregistrate in fisierele sistemului de operare indiferent daca auditarea este activata sau nu. Aceste actiuni sunt:

Pornirea bazei de date

Oprirea bazei de date

Conectarea la baza de date printr-un cont privilegiat

Schimbari structurale facute in baza de date

Cand baza de date este pornita, o inregistrare este inscrisa automat in fisierele sistemului de operare. Daca baza de date este pornita cu sys sau internal, informatiile despre utilizator nu vor fi inregistrate. Informatiile se salveaza cu scopul de a pastra o inregistrare a oricarei incercari de a porni baza de date si de a dezactiva auditarea pentru a putea fi efectuate neobservate anumite activitati. La momentul pornirii bazei de date calea de auditare pentru baza de date nu este inca disponibila, deci informatiile despre pornire sunt scrise intotdeauna intr-un fisier al sistemului de operare.

In toate situatiile de auditare de mai sus, informatia este inregistrata intr-un jurnal al sistemului de operare. Daca sistemul de operare nu permite sistemului Oracle sa acceseze facilitatile sale pentru audit, Oracle va inregistra informatiile intr-un jurnal in acelasi director in care procesele de fundal isi inregistreaza activitatea.

5.1. Auditarea in timpul pornirii bazei de date

Primul tip de auditare predefinita intervine in timpul pornirii bazei de date. Un exemplu de rezultate ale auditarii in sistemul de operare salvate automat, pentru Windows NT cu versiunea Oracle 8:

Audit trail: ACTION : 'startup' OS_AUTHENT_PREFIX : OPS$. (3:55:41 a.m.)

Audit trail: ACTION : `startup' AUDIT_TRAIL : none. (3:55:40 a.m.)

Audit trail: ACTION : `connect INTERNAL' OSPRIV : OPER CLIENT USER:

SYSTEM CLIENT TERMINAL: MLT-PC. (3:55:31 a.m.)

Calea catre aceste intrarii: Start→Programs →Administrative Tools→ Event Viewer, meniul de optiuni pe un sistem Windows NT. Exista trei jurnale e evenimente in care oricine poate insera un eveniment: System, Security si Application.

Prima intrare din secventa de mai sus este de fapt cea listata ultima. Acesta intrare arata conectarea facuta initial la baza de date pentru a o porni. Interesanta in cea de-a treia intrare este notatia folosita pentru terminalul client de la care baza de date a fost pornita -MLT-PC-si privilegiile de sistem folosite-OSPRIV. Cele trei notatii de audit au fost prezente in Windows NT Administrative Tools Event Viewer, in Application log dupa ce baza de date a fost pornita. Pe masura ce fiecare proces de fundal (PMON, SMON, DBWR, LGWR, CKPT, RECO) a fost pornit, cate o inregistrare a fost facuta in jurnalul de evenimente. Exista de asemenea o intrare pentru momentul in care SGA a fost initializata.

5.2. Auditarea in timpul opririi bazei de date

A doua forma de auditare predefinita care poate aparea este in momentul opririi bazei de date. De fiecare data cand baza de date este oprita, o inregistrare poate fi facuta in calea de auditare indicand numele utilizatorului pentru sistemul de operare, identificatorul terminalului utilizatorului, si data si timestamp cand actiunea are loc. In functie de sistemul de operare, daca un utilizator privilegiat, ca sysdba si sysoper, opresc baza de date, evenimentul nu va fi inregistrat in jurnalul de evenimente al sistemului.

5.3. Auditarea in timpul conectarii cu privilegii la baza de date

Cea de-a treia forma de auditare predefinita, are loc cand un utilizator se conecteaza la baza de date cu privilegii administrative. Sunt inregistrate informatiile despre utilizatorul sistemului de operare. Aceste informatii sunt foarte valoroase in incercarea de a determina daca cineva a reusit sa dobandeasca privilegii pe care nu ar fi trebuit sa le aiba.

5.4. Auditarea in timpul modifcarii structurii bazei de date

Cand este lansata o comanda din baza de date pentru modificarea structurii acestei baze de date, comanda si urmarile sale sunt capturate in alert log pentru acea baza de date. Acesta este a patra actiune predefinita. Exemplu:

CREATE TABLESPACE <tablespace_name>

ALTER TABLESPACE <tablespace_name> ADD DATAFILE

ALTER TABLESPACE OFFLINE DROP TABLESPACE <tablespace_name>

INCLUDING CONTENTS

CREATE ROLLBACK SEGMENT <rollback_segment_name>