Oracle Database Security:Databaserevision

I denne artikel vil jeg fortsætte med Oracle Database Security, og jeg vil præsentere nogle vigtige fakta om standard databaserevision, revisionstriggere og revisionspolitikker i Oracle. Databaserevision har to komponenter:overvågning og vedvarende registrering af etablerede databaseaktivitetssæt og hændelser. Formålet med databaserevision er ikke-afvisning, undersøgelse af mistænkelige aktiviteter, opdagelse af problemer genereret af konfigurationer vedrørende autorisation (ressourceadgang), overholdelse af faktisk lovgivning og kontrol.

Standard revision

Hvilke aktiviteter reviderer vi? Databasestart og -stop samt forbindelserne lavet af databaseadministratoren bliver implicit revideret af Oracle, og data gemmes automatisk i operativsystemet. Tabellen nedenfor viser andre aktiviteter, der kan overvåges:

Hvor opbevarer vi de reviderede aktiviteter?

i databasen , ved hjælp af databaserevisionsspor, hvor vi har to muligheder:
- audit_trail =DB
  hvilket kan gøres med følgende kode:
```
alter system set audit_trail=db scope=spfile;
```

- audit_trail =DB,UDVIDET
  ved hjælp af følgende kode:
```
alter system set audit_trail= db, extended scope=spfile;
```
Forskellen mellem DB og DB,EXTENDED er, at den anden udfylder kolonnerne SQLBIND og SQLTEXT CLOB i tabellen SYS.AUD$.

ekstern , ved hjælp af operativsystemets revisionsspor, med følgende muligheder:
- audit_trail =OS
  og den anvendte kode er:
```
alter system set audit_trail=os scope=spfile;
```
- audit_trail =XML og AUDIT_FILE_DEST =filstien (implicit er $ORACLE_BASE/admin/$ORACLE_SID/adump)
  med koden:
```
alter system set audit_trail=xml scope=spfile;
```

For at finde den aktuelle konfiguration af de lagrede reviderede aktiviteter, kan man køre følgende forespørgsel, skrevet med små bogstaver:

select value from v$parameter where name='audit_trail';

Flere nyttige kommandoer:

[tabel id=43 /]

Lad os nu have nogle eksempler på databaserevision.

Her er et eksempel på en standardrevision med revideret information gemt i databasen:

Den reviderede information består af SELECT-sætningerne udført på databasetabellerne.

I SQL Developer skal du udføre følgende script:

alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

Derefter skal databasen genstartes. For at gøre det skal du i SQLPlus-terminalen forbinde med brugernavn sys som sysdba / password og køre følgende sætninger:

SHUTDOWN IMMEDIATE
STARTUP

Bemærk, at ovenstående størrelser er forskellige fra et system til et andet.

For at kontrollere, om revisionssporet er indstillet korrekt, skal du køre følgende forespørgsel:

select value from v$parameter where name='audit_trail';

eller:

show parameter audit_trail;

Når du vil stoppe revisionen, skal du udføre:

NOAUDIT SELECT TABLE;

For at se, hvilke erklæringer der blev registreret af revisionen, kan du bruge:

select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

eller

select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);

Et andet eksempel er standardrevision med reviderede data gemt i en XML-fil i standardstien.

alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

Genstart databasen igen:opret forbindelse til SQLPlus-terminalen med brugernavn sys som sysdba / adgangskode og kør kommandoerne SHUTDOWN IMMEDIATE og STARTUP.

Derefter, hver gang en udvælgelses-, indsæt-, opdaterings- og sletningsforespørgsel mislykkes på medarbejdertabellen, skal den registreres i XML-filen.

Når vi ønsker at stoppe revisionen, kører vi følgende kommandoer i databaseudviklingsmiljøet:

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

Og gendan standard revisionssporet:

alter system set audit_trail=db scope=spfile;

Nedenfor er et eksempel på en del af en XML-revisionsfil:

Hvordan sletter vi de reviderede oplysninger?

Mængden af de reviderede data kan blive meget stor på grund af antallet af de reviderede aktiviteter og deres hyppighed. Det er derfor, det anbefales at periodisk arkivere de reviderede data og slette dem fra produktionssystemet.

Hvis de reviderede data er gemt i databasen (database revisionsspor), så kan vi bruge sletteerklæringer (men først efter vi har arkiveret dataene!):

DELETE FROM SYS.AUD$;

Du kan vælge at slette de reviderede oplysninger for et specifikt databaseobjekt, for eksempel en tabel kaldet produkter:

DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

Revisionsudløsere

En trigger er en PL/SQL-blok eller CALL-sætningen for en PL/SQL-procedure, der udføres automatisk, hver gang en hændelse opstår. Der er to typer triggere:på databaseniveau (databaseudsagn) og på applikationsniveau (for eksempel ved at trykke på en knap på en Oracle-formular). De udløsere, der bruges til revision, er udløsere på databaseniveau. De klassificeres i følgende kategorier:

DML-udløsere – hvor en DML-sætning udløses på en tabel. Disse udløsere kan udføres én gang på kommandoniveau uanset antallet af poster (udløsere på sætningsniveau), eller de kan udføres FOR HVER RÆKKE (udløsere på postniveau). Typer af triggere på rekordniveau:FØR STATEMENT, EFTER STATEMENT, FØR HVER RÆKKE, EFTER HVER RÆKKE;
I STEDET FOR triggere – hvor en DML-sætning udløses på en visning;
SYSTEM-udløsere – udløst af hændelser som f.eks. start/stop af databasen, DDL-sætninger, brugerlogin/logout. Typer af systemudløsere:EFTER BEGIVENHED, FØR BEGIVENHED.

Forespørger på SYS.TRIGGER$ tabellen eller ALL_TRIGGERS view tilbyder information om alle udløsere på databaseniveau. For eksempel kan den distinkte triggertype fra databasen findes som følger:

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

DBA_TRIGGERS-visningen tilbyder information om de triggere, der automatisk oprettes af Oracle-produkterne ved installationen. Hvis vi ønsker at finde information om SYSTEM-triggerne ('FØR BEGIVENHED' og 'EFTER BEGIVENHED'), kan vi køre følgende sætning:

SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

Også ved installationen oprettes DML-udløsere automatisk på HR-brugerskemaet:

SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

Til revision kan vi oprette tilpassede triggere til at registrere den ønskede information, men man bør oprette en speciel tabel til at gemme de reviderede oplysninger.

Det er vigtigt at sikre sig, at de udviklede triggere ikke påvirker den normale databaseaktivitet. Formålet med revision er passivt at overvåge den normale, daglige databaseaktivitet og gemme den til senere analyse. Det anbefales derfor ikke at oprette I STEDET FOR triggere for at returnere resultaterne fra måltabellerne til revisionstabellen.

DML-udløsere på udsagnsniveau kan eksistere side om side med DML-udløsere på postniveau. Rækkefølgen af opkald er:

udløs BEFORE-sætning
for hver berørt post
- udløs FØR registrering
- aktuel DML-handling
- udløs AFTER record
udløs AFTER-sætning

Brugerdefinerede triggere vil kun blive udført, hvis sætningen ifølge Oracle er korrekt og kan forekomme. For en forkert DML-sætning eller en, der overtræder en begrænsning, vil en fejl blive returneret, og triggeren vil ikke blive udført. Derfor anbefales det til revision at bruge især LMD-triggerne på erklæringsniveau.

Eksempel på revisionstrigger:

Lad os antage, at vi ønsker at skabe en trigger til at registrere i en revisionstabel (kaldet TAB_AUDIT_EMP) oplysninger om de DML-opgørelser, der etablerer lønninger over 20.000 (valuta er ikke vigtig her) for virksomhedens medarbejdere. Vi ønsker at gemme sekvensnummeret for forespørgslen, brugernavnet, sessionen, værten og datoen i TAB_AUDIT_EMP.

Dette kan gøres med følgende:

CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;

Antag, at vi laver en lønændring for medarbejderne i en bestemt afdeling:

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

Og så verificerer vi overvågningen:

select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;

Revisionspolitikker

Den tredje revisionsmetode henviser til revisionspolitikker. Definitionen af en revisionspolitik indeholder følgende:

specifikation af objektet (skema, objektnavn, kolonner), der er udsat for overvågning
specifikation af de handlinger, der er revideret for et objekt (SELECT, INSERT, UPDATE, DELETE):implicit er det SELECT
angivelse af de betingelser, der skal være opfyldt for at registrere de reviderede oplysninger, det sker i udløserens WHEN-klausul og er valgfri
en hændelseshandler, der desuden håndterer hændelsen, hvilket den er valgfri.

En revisionspolitik kan være aktiv (AKTIVERET status) eller inaktiv (DEAKTIVERET status). Listen over revisionspolitikkerne kan fås ved at undersøge visningen ALL_AUDIT_POLICIES:

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

Til administration af revisionspolitik har vi DBMS_FGA-pakken. For at bruge denne pakke er det nødvendigt at give privilegier til de brugere, der vil skrive PL/SQL-kode:

grant execute on dbms_fga to username;

Eksempel på revisionspolitik:

Vi ønsker at oprette en revisionspolitik for registrering af DML-erklæringerne, der ændrer lederne (MANAGER_ID) i tabellen AFDELINGER. Vi kan vælge at oprette en behandler for politikken, kaldet proc_audit_alert, der informerer os om en ændring vedrørende manageren:

CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

Og politikken kan være:

CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

Bemærk, at objektskema, objektnavn, politiknavn, revisionskolonne, erklæringstyper og handlermodul skal tilpasses til den politik, du vil skrive.

Derefter udfører vi proceduren:

EXECUTE proc_audit_manager;

Vi kan bekræfte, om politikken er aktiveret:

SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';

Bekræft derefter, om proceduren og politikken fungerer korrekt, ved at udføre en opdatering:

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

Som konklusion er revision nødvendig for hver database, og metoderne ovenfor hjælper dig med at finde en mistænkelig aktivitet, der kan påvirke din databasesikkerhed. For flere detaljer om Oracle-databaserevision, se bibliografien nedenfor.

Bibliografi:

http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
http://docs.oracle.com/cd/B10501_01/server.920/a96521/audit.htm
https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000