Материал: Горбатов Аттестационные испытания автоматизированных систем от 2014

Работа 16

КОНТРОЛЬ ДЕТАЛЬНОГО АУДИТА ДЕЙСТВИЙ ПОЛЬЗОВАТЕЛЕЙ В СУБД ORACLE

Цель: получение практических навыков работы с методами контроля подсистем систем аудита (регистрации и учета действий пользователей) СУБД Oracle.

ПЛАН ПРОВЕДЕНИЯ РАБОТЫ

1.Выбор предметной области и пользователей для проверки FGAudit. Определение политики (правила) аудита без обработки событий для выбранной предметной области. Проверка выполнения детального аудита в соответствии с определенной политикой.

2.Проверка выполнения запросов, включающих переменные привязки, ретроспективных запросов, с использованием FGAudit.

3.Определение политики (правила) аудита с обработкой событий для выбранной предметной области. Проверка выполнения детального аудита с обработкой событий в соответствии с определенной политикой.

ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ

1. Выбор предметной области и пользователей для проверки FGAudit

В качестве предметной области будем использовать предметную область пользователя «scott» (присутствует в поставке Oracle, т.е. скрипты для нее не требуются), так как в ней есть таблица «emp», в которой представлены личные сведения о сотрудниках фирмы. Защита личных сведений – понятная цель для задействования и демонстрации возможностей детального аудита. Лабораторная работа выполняется копированием и выполнением нижеприводимых команд в окно SQL*Plus. Посмотрим содержимое таблицы

«emp»:

conn scott/scott@orcl SELECT * FROM emp;

411

Мы могли бы установить аудит на все действия с этой таблицей (с сохранением текста DML предложений) обычными средствами аудита, но при этом в таблице или в файле аудита будет накапливаться много лишней информации. Можно было бы, как мы делали это в предыдущей лабораторной работе, создать триггер регистрации действий с таблицей «emp» в специальной таблице аудита. Но триггер не работает на «SELECT».

Для создания политики аудита создадим пользователя «main» и наделим его соотвтетствующими привилегиями:

Conn sys/sys@orcl as sysdba

GRANT SELECT,INSERT,UPDATE,DELETE ON scott.emp TO PUBLIC;

DROP USER main CASCADE;

CREATE USER main IDENTIFIED BY main DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp

QUOTA 1m ON users;

GRANT connect, resource TO main; GRANT execute ON dbms_fga TO main;

GRANT select ON dba_fga_audit_trail TO main; GRANT DELETE on dba_fga_audit_trail to main; GRANT select ON dba_audit_policies TO main; GRANT FLASHBACK ANY TABLE TO main;

412

GRANT EXECUTE ON dbms_flashback TO main; Conn main/main@orcl

Удалим политику аудита, созданную предыдущим выполнением лабораторной работы:

DELETE FROM dba_fga_audit_trail; begin

DBMS_FGA.DROP_POLICY( OBJECT_SCHEMA => 'scott', OBJECT_NAME => 'emp', policy_name => 'CHK_EMPA'); end;

/

Создадим политику аудита таблицы «emp», предусматривающую регистрацию DML действий пользователей (команды «select», «insert», «update», «delete») с этой таблицей таких, которые затрагивают столбец «ename» и включают условие «'sal > 1500'».

BEGIN DBMS_FGA.ADD_POLICY( OBJECT_SCHEMA => 'SCOTT', OBJECT_NAME => 'EMP', POLICY_NAME => 'chk_empa',

AUDIT_CONDITION => 'sal > 1500', AUDIT_COLUMN => 'ename', HANDLER_SCHEMA=>null, HANDLER_MODULE=>null, ENABLE=>true);

END;

/

Проверим, что зарегисторирует политика FGA 'chk_empa'. conn king/king@orcl

--команда 1

SELECT * FROM scott.emp; --команда 2

SELECT empno,ename FROM scott.emp; --команда 3

SELECT empno, deptno FROM scott.emp; --команда 4

UPDATE scott.emp SET deptno=40 WHERE deptno=20;

413

ROLLBACK;

Посмотрим, что зарегистрировал аудит. conn main/main@orcl

Alter session set nls_date_format = 'yyyy-mon-dd:HH:MI:SS'; select db_user, sql_text, timestamp from dba_fga_audit_trail;

DB_USER SQL_TEXT TIMESTAMP

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

Команда 3 не зарегистрирована, так как команда 3 не затрагивает запросом столбцы, указанные в политике «chk_empa». Команда 4 не зарегистрирована, так как параметр «statement_types» политики по умолчанию имеет значение «SELECT». Скорректируем политику для учета действий с таблицей «emp» командами «INSERT, UPDATE, DELETE». Добавим условие, по которому аудит выпоняется и для столбца «sal». Так как программы UPDATE_POLICY не существует, сначала:

conn main/main@orcl begin

DBMS_FGA.DROP_POLICY( OBJECT_SCHEMA => 'scott', OBJECT_NAME => 'emp', policy_name => 'CHK_EMPA'); end;

/

Затем:

BEGIN DBMS_FGA.ADD_POLICY( OBJECT_SCHEMA => 'scott', OBJECT_NAME => 'emp', POLICY_NAME => 'chk_empa',

AUDIT_CONDITION => 'sal >1500', AUDIT_COLUMN => 'ename,sal', STATEMENT_TYPES => 'select, insert, update, delete', HANDLER_SCHEMA=>null, HANDLER_MODULE=>null,

ENABLE=>true);

414

END;

/

DELETE FROM dba_fga_audit_trail;

Проверим, что зарегистрирует скорректированная политика

FGA 'chk_empa'.

conn king/king@orcl --команда 1

SELECT * FROM scott.emp; conn smith/smith@orcl --команда 2

SELECT * FROM scott.emp; --команда 3

SELECT empno,job FROM scott.emp WHERE sal>1500; --команда 4

SELECT empno,job FROM scott.emp WHERE sal<1500; --команда 5

SELECT empno, deptno FROM scott.emp; --команда 6

SELECT ename FROM scott.emp; --команда 7

SELECT sal FROM scott.emp; --команда 8

UPDATE scott.emp SET sal=1600 WHERE sal<1500 AND job='CLERK';

ROLLBACK;

Посмотрим, что зарегистрировал аудит. conn main/main@orcl

Alter session set nls_date_format = 'yyyy-mon-dd:HH:MI:SS'; select db_user, sql_text, timestamp from dba_fga_audit_trail;