Oracle Database Security:Одит на база данни

В тази статия ще продължа с Oracle Database Security и ще представя някои важни факти за стандартния одит на база данни, тригерите за одит и политиките за одит в Oracle. Одитът на база данни има два компонента:наблюдение и постоянна регистрация на установени набори от дейности и събития в базата данни. Целите на одита на базата данни са недопускане на отказ, разследване на подозрителни дейности, откриване на проблеми, генерирани от конфигурации по отношение на оторизацията (достъп до ресурси), съответствие с действителното законодателство и контрол.

Стандартен одит

Какви дейности одитираме? Стартирането и спирането на базата данни, както и връзките, направени от администратора на базата данни, се одитират имплицитно от Oracle и данните се съхраняват автоматично в операционната система. Таблицата по-долу показва други дейности, които могат да бъдат наблюдавани:

Къде съхраняваме одитираните дейности?

в базата данни , използвайки следа за одит на базата данни, където имаме две възможности:
- audit_trail =DB
  което може да се направи със следния код:
```
alter system set audit_trail=db scope=spfile;
```

- audit_trail =DB,EXTENDED
  с помощта на следния код:
```
alter system set audit_trail= db, extended scope=spfile;
```
Разликата между DB и DB,EXTENDED е, че втората попълва колоните SQLBIND и SQLTEXT CLOB на таблицата SYS.AUD$.

външно , използвайки следа за одит на операционната система, със следните възможности:
- audit_trail =OS
  и използвания код е:
```
alter system set audit_trail=os scope=spfile;
```
- audit_trail =XML и пътят на файла AUDIT_FILE_DEST =(имплицитно е $ORACLE_BASE/admin/$ORACLE_SID/adump)
  с кода:
```
alter system set audit_trail=xml scope=spfile;
```

За да се намери текущата конфигурация на съхранените одитирани дейности, може да се изпълни следната заявка, написана с малки букви:

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

Още полезни команди:

[table id=43 /]

Сега нека имаме няколко примера за одит на база данни.

Ето пример за стандартен одит с одитирана информация, съхранявана в базата данни:

Одитираната информация се състои от операторите SELECT, изпълнени в таблиците на базата данни.

В SQL Developer изпълнете следния скрипт:

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

След това базата данни трябва да се рестартира. За да направите това, в терминала SQLPlus се свържете с потребителско име sys като sysdba / парола и изпълнете следните оператори:

SHUTDOWN IMMEDIATE
STARTUP

Имайте предвид, че горните размери се различават в различните системи.

За да проверите дали одитната пътека е зададена правилно, изпълнете следната заявка:

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

или:

show parameter audit_trail;

Когато искате да спрете одита, изпълнете:

NOAUDIT SELECT TABLE;

За да видите какви изявления са записани от одита, можете да използвате:

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

или

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

Друг пример е за стандартен одит с одитирани данни, съхранявани в XML файл, в стандартния път.

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

Отново рестартирайте базата данни:свържете се с терминала SQLPlus с потребителско име sys като sysdba / парола и изпълнете командите SHUTDOWN IMMEDIATE и STARTUP.

След това, всеки път, когато заявка за избор, вмъкване, актуализиране и изтриване се провали в таблицата на служителите, тя трябва да бъде записана в XML файла.

Когато искаме да спрем одита, изпълняваме следните команди в средата за разработка на база данни:

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

И възстановете следата за одит по подразбиране:

alter system set audit_trail=db scope=spfile;

По-долу е даден пример за част от XML файл за одит:

Как да изтрием одитираната информация?

Обемът на одитираните данни може да стане много голям поради броя на одитираните дейности и тяхната честота. Ето защо се препоръчва периодично да архивирате одитираните данни и да ги изтривате от производствената система.

Ако одитираните данни се съхраняват в базата данни (одитна пътека на базата данни), тогава можем да използваме изрази за изтриване (но само след като сме архивирали данните!):

DELETE FROM SYS.AUD$;

Можете да изберете да изтриете одитираната информация за конкретен обект на база данни, например таблица, наречена продукти:

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

Задействания за одит

Тригерът е PL/SQL блок или оператор CALL на PL/SQL процедура, който се изпълнява автоматично всеки път, когато възникне събитие. Има два типа задействания:на ниво база данни (изрази на базата данни) и на ниво приложение (например натискане на бутон върху формуляр на Oracle). Тригерите, използвани за одит, са тригери на ниво база данни. Те се класифицират в следните категории:

DML тригери – където DML израз се задейства върху таблица. Тези тригери могат да бъдат изпълнени веднъж на ниво команди, независимо от броя на записите (задействания на ниво оператор) или могат да бъдат изпълнени ЗА ВСЕКИ РЕД (задействания на ниво запис). Видове задействания на ниво на запис:ПРЕДИ ИЗЯВЛЕНИЕ, СЛЕД ИЗЯВЛЕНИЕ, ПРЕДИ ВСЕКИ РЕД, СЛЕД ВСЕКИ РЕД;
ВМЕСТО тригери – където DML израз се задейства в изглед;
СИСТЕМНИ тригери – задействат се от събития като стартиране/спиране на базата данни, DDL изрази, влизане/излизане на потребител. Видове системни тригери:СЛЕД СЪБИТИЕ, ПРЕДИ СЪБИТИЕ.

Запитване наSYS.TRIGGER$ таблицата или ALL_TRIGGERS view предлага информация за всички тригери на ниво база данни. Например, отделният тип тригер от базата данни може да бъде намерен, както следва:

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

Изгледът DBA_TRIGGERS предлага информация за тригерите, автоматично създадени от продуктите на Oracle при инсталиране. Ако искаме да намерим информация за тригерите SYSTEM („ПРЕДИ СЪБИТИЕ“ и „СЛЕД СЪБИТИЕ“), можем да изпълним следния израз:

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;

Също така, при инсталацията, DML тригерите се създават автоматично в схемата на HR потребителя:

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

За одит можем да създадем персонализирани тригери за записване на желаната информация, но трябва да създадем специална таблица за съхраняване на одитираната информация.

Важно е да се уверите, че разработените тригери не влияят на нормалната активност на базата данни. Целта на одита е пасивно да наблюдава нормалната, ежедневна дейност на базата данни и да я съхранява за по-късен анализ. Следователно не се препоръчва създаването на тригери INSTEAD OF за връщане на резултатите от целевите таблици към таблицата за одит.

DML тригери на ниво израз могат да съществуват съвместно с DML тригери на ниво запис. Редът на повикване е:

задействайте израз BEFORE
за всеки засегнат запис
- задействане ПРЕДИ запис
- текущо DML действие
- задействане СЛЕД запис
задействане на оператор AFTER

Дефинирани от потребителя тригери ще се изпълняват само ако, според Oracle, изявлението е правилно и може да се случи. За грешен DML оператор или такъв, който нарушава ограничение, ще бъде върната грешка и тригерът няма да бъде изпълнен. Ето защо, за одит, се препоръчва да се използват особено LMD тригери на ниво отчет.

Пример за задействане на одит:

Да предположим, че искаме да създадем задействане за записване в таблица за одит (наречена TAB_AUDIT_EMP) информация за DML отчетите, които установяват заплати над 20000 (валутата не е важна тук) за служителите на компанията. Искаме да съхраним в TAB_AUDIT_EMP поредния номер на заявката, потребителското име, сесията, хоста и датата.

Това може да стане със следното:

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;

Да приемем, че правим промяна на заплатата за служителите в конкретен отдел:

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

И след това проверяваме наблюдението:

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

Правила за одит

Третият метод на одит се отнася до политиките за одит. Дефиницията на одитната политика съдържа следното:

спецификация на обекта (схема, име на обект, колони), подложен на наблюдение
спецификация на одитираните действия за обект (SELECT, INSERT, UPDATE, DELETE):имплицитно това е SELECT
уточняване на условията, които трябва да бъдат изпълнени, за да се запише одитираната информация, това се прави в клаузата WHEN на тригера и е по избор
манипулатор на събитие, който допълнително обработва събитието, което не е задължително.

Политиката за одит може да е активна (състояние ВКЛЮЧЕНО) или неактивна (състояние ИЗКЛЮЧЕНО). Списъкът с правилата за одит може да бъде получен чрез запитване на изгледа ALL_AUDIT_POLICIES:

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

За администриране на политиката на одит имаме пакета DBMS_FGA. За да използвате този пакет, е необходимо да предоставите привилегия на потребителите, които ще пишат PL/SQL код:

grant execute on dbms_fga to username;

Пример за политика за одит:

Искаме да създадем политика за одит за записване на DML изразите, които променят мениджърите (MANAGER_ID) в таблицата DEPARTMENTS. Можем да изберем да създадем манипулатор за правилото, наречено proc_audit_alert, което ни информира за промяна по отношение на мениджъра:

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;

И политиката може да бъде:

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;

Обърнете внимание, че object_schema, object_name, policy_name, audit_column, statement_types и handler_module трябва да бъдат адаптирани към политиката, която искате да напишете.

След това изпълняваме процедурата:

EXECUTE proc_audit_manager;

Можем да проверим дали политиката е активирана:

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

След това проверете дали процедурата и политиката работят правилно, като изпълните актуализация:

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

В заключение, одитът е необходим за всяка база данни и методите, предоставени по-горе, ви помагат да откриете подозрителна дейност, която може да повлияе на сигурността на вашата база данни. За повече подробности относно одита на базата данни на Oracle вижте библиографията по-долу.

Библиография:

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