7-Аудит

1. Лекция

1
ЛЕКЦИЯ
Аудит в СУБД ORACLE

2. АУДИТ БАЗЫ ДАННЫХ

• Аудит - способ отслеживания использования БД и
предупреждения
о
возможных
проблемах
с
безопасностью.
• Фиксирование и выявление злонамеренных действий
в базе данных.
• Получение величины нагрузки на БД со стороны
пользователей.
• Отслеживание модификаций конкретных объектов в
БД.
• Контроль
за
действиями
владельцев
привилегированных записей.
• Аудит использования БД позволяет убедиться,
действительно ли механизмы контроля доступа
работают так, как было задумано.

3. Активизация аудита

3
Активизация аудита
• AUDIT_TRAIL= {DB (TRUE)|OS|NONE (FALSE)}
• При установленном параметре AUDIT_TRAIL = OS данные аудита
пишутся в eventlog Windows. (Event Viewer)
• В Oracle 11 AUDIT_TRAIL=DB по умолчанию
• Все значения параметра AUDIT_TRAI:
• NONE or FALSE -> Auditing is disabled. Default until Oracle 10g.
• DB or TRUE -> Auditing is enabled, with all audit records stored in the database
audit trial (AUD$). Default from Oracle 11g.
• DB_EXTENDED –> Same as DB, but the SQL_BIND and SQL_TEXT columns
are also populated.
• XML-> Auditing is enabled, with all audit records stored as XML format OS files.
• XML_EXTENDED –> Same as XML, but the SQL_BIND and SQL_TEXT
columns are also populated.
• OS -> Auditing is enabled, with all audit records directed to the operating
system's file specified by AUDIT_FILE_DEST.
• To
audit
issuances
of
a
SQL
statement,
you
must
have AUDIT SYSTEM system privilege.

4. КОМАНДЫ АУДИТА

4
КОМАНДЫ АУДИТА
• alter system set audit_trail=xml scope = spfile;
• shutdown immediate;
• Startup
• Файлы Audit обычно расположены в папке adump.
show parameter audit_file_dest;

5. КОМАНДЫ АУДИТА

5
КОМАНДЫ АУДИТА

6. ВКЛЮЧЕНИЕ И ВЫКЛЮЧЕНИЕ КОМАНДАМИ АУДИТА

AUDIT {ВИД АУДИТА|ALL} BY {SESSION|ACCESS}
WHENEVER [NOT] SUCCESSFUL
NOAUDIT
NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE
PROCEDURE;
NOAUDIT session;
NOAUDIT session BY scott, hr;
NOAUDIT DELETE ON emp;

7. АУДИТ -обозначение ALL

7
АУДИТ -обозначение ALL
• Обозначение
ALL
может
использоваться
для
специфицирования всех возможных опций аудитинга
объекта для объекта схемы.
• Позволяет указать одним словом все опции аудитинга в
предложении AUDIT или NOAUDIT.
NOAUDIT ALL ON emp
• Можно отключить все опции аудитинга предложений
(системы) и привилегий:
NOAUDIT ALL;
NOAUDIT ALL PRIVILEGE
NOAUDIT ALL PRIVILEGES;

8. Умалчиваемые опций аудитинга

8
Умалчиваемые опций аудитинга
• Выключение умалчиваемых опций аудитинга объектов:
NOAUDIT ALL ON DEFAULT
NOAUDIT SELECT ON DEFAULT WHENEVER NOT
SUCCESSFUL
• Все
объекты схем, созданные до выдачи этого
предложения
NOAUDIT,
продолжают
использовать
умалчиваемые опции аудитинга объектов, действовавшие
во время их создания, пока эти опции не будут перекрыты
явным предложением NOAUDIT.

9. ВЫКЛЮЧЕНИЕ АУДИТА

9
ВЫКЛЮЧЕНИЕ АУДИТА
• NOAUDIT сбрасывает опции аудитинга предложений и
привилегий, она может включать фразу BY USER, чтобы
специфицировать
список
пользователей,
ограничивающий сферу действия команды.
• Чтобы установить дефолтные опции аудитинга объектов
для отслеживания всех безуспешных предложений
SELECT, BY SESSION (умолчание):
• Команда NOAUDIT лишь выключает опции аудитинга; она
не отключает аудитинг как таковой.
• Для отключения аудитинга и прекращения генерациии
аудиторских записей, даже если у вас установлены опции
аудитинга,
необходимо
установить
параметр
AUDIT_TRAIL в файле параметров БД.
• Пара
опций
BY
SESSION/BY
ACCESS
НЕ
ПОДДЕРЖИВАЕТСЯ командой NOAUDIT

10. Аудит

10
Аудит
• Аудит
команд
(операторов)
отдельными
пользователями или всеми пользователями.
• Аудит
привилегий
использования
системных
привилегий отдельными пользователями или всеми
пользователями.
• Аудит объектов схемы аудит определенного набора
команд SQL для конкретного объекта схемы.
• С Oracle9i появляется детальный аудит.
• Для всех типов аудита Oracle вносит записи в журнал
аудита базы данных, или таблицу SYS.FGA_LOG$,
DBA_FGA_AUDIT_TRAIL, в которое записывается
информация детального аудита, или же в файл
операционной системы (в двоичном формате).

11. Опции аудитинга предложений (операторов)

11
Опции аудитинга предложений
(операторов)
• SYSTEM AUDIT ( AUDIT , NOAUDIT );
• INDEX (CREATE INDEX , DROP INDEX, ALTER INDEX );
• PROCEDURE (CREATE or replace FUNCTION, CREATE or
replace PROCEDURE , CREATE or PACKAGE, CREATE or
replace PACKAGE BODY, DROP PACKAGE, DROP
PROCEDURE, DROP FUNCTION)
• TABLE (CREATE TABLE, TRUNCATE TABLE, DROP TABLE )
• GRANT TABLE (grant …on таблица, revoke … on таблица)
• Аудит базируется на типе предложений SQL, например, на
любых предложениях SQL по таблицам (что регистрирует
каждое предложение CREATE, TRUNCATE и DROP TABLE)

12. Опции аудитинга привилегий и объектов схемы

12
Опции аудитинга привилегий и
объектов схемы
• Аудит
привилегий
отслеживает
использование
конкретной системной привилегии, такой как CREATE
TABLE :
AUDIT DELETE ANY TABLE BY ACCESS WHENEVER
NOT SUCCESSFUL
• Аудит объектов схемы отслеживает конкретные типы
предложений на конкретных объектах, например,
ALTER
TABLE
по
таблице
EMP

13. ПРИМЕРЫ АУДИТА

14.

14

15.

15

16. Опции аудитинга

16
Опции аудитинга
• В зависимости от того, какие опции аудитинга установлены,
аудиторские записи могут содержать различные типы
информации.
Все
опции
аудитинга
генерируют
информацию:
*имя
пользователя,
выполнявшего
отслеживаемое
предложение;
* код действия, указывающий выполненное предложение;
* объекты, адресуемые в отслеживаемом предложении;
* дату и время выполнения отслеживаемого предложения.
Для
аудитинга
предложений
и
привилегий
в зависимости от пользователя, можно установить
режим
действия
аудита
для
индивидуальных
пользователей:
AUDIT SESSION BY scott, lori;

17. ПРИМЕРЫ АУДИТА

AUDIT insert table, update table, delete table, select table BY ah, be

18. ПРИМЕРЫ АУДИТА

• AUDIT SYSTEM GRANT BY SCOTT ; -
аудит
использования
системной
привилегии/роли пользователем/ролью.
• AUDIT GRANT ON SYSTEM.TABLE1;
• AUDIT SYSTEM
AUDIT WHENEVER
SUCCESSFUL (контроль выдачи команд
настройки аудита);
• AUDIT
GRANT
ANY
OBJECT
PRIVELEGE BY SCOTT;

19.

20. ПАРАМЕТРЫ АУДИТА

20
ПАРАМЕТРЫ АУДИТА

21. АУДИТ СРЕДСТВАМИ СУБД

Cписок опций привилегий, к которым применён аудит:
SELECT audit_option FROM dba_stmt_audit_opts -аудит
операторов
SELECT
privilege,
success,
failure
FROM
dba_priv_audit_opts - аудит системных привилегий
Dba_obj_audit_opts
- аудит объектов БД
Audit_action – типы действий с журналом аудитов
Dba_audit_polices – стратегии детального аудита
Dba_audit_statement – записи журнала аудита, связанные
с командами grant, revoke, audit, noaudit, alter system

22.

23. ПРОСМОТР РЕЗУЛЬТАТОВ АУДИТА

SELECT * FROM sys.dba_obj_audit_opts WHERE owner =
'SCOTT' AND object_name LIKE 'EMP%';
OWNER OBJECT_N OBJECT_TY ALT AUD COM DEL GRA IND
INS LOC REN SEL UPD EXE ----- -------- --------- --- --- --- --- --- --- -- --- --- --- --- --- SCOTT EMP TABLE S/S -/- -/- A/- -/- S/S -/- -/S/S -/- -/- -/- SCOTT EMPLOYEE VIEW -/- -/- -/- -/- -/- -/- -/- -/- S/S
-/- -/- -/Символ "-" указывает, что опция аудитинга не установлена.
Символ "S" указывает, что опция аудитинга установлена в
режиме BY SESSION.
Символ "A" указывает, что опция аудитинга установлена в
режиме
BY
ACCESS.

24. Активность пользователей

24
Активность пользователей
select username, to_char(logoff_time,'mm/dd') ts,
sum(logoff_lread) lread,
sum(logoff_pread) pread,
sum(logoff_lwrite) lwrite,
sum(session_cpu) scpu
from dba_audit_trail
where logoff_time between
TO_DATE('01.01.2013:00:00:00','DD.MM.YYYY:HH24:MI:SS')
and
TO_DATE('30.01.2013:23:59:59','DD.MM.YYYY:HH24:MI:SS')
group by username, to_char(logoff_time,'mm/dd')
order by username, to_char(logoff_time,'mm/dd')

25. Словарь и информация по аудиту

25
Словарь и информация по аудиту
1. Некоторые действия протоколируются в alert-файле, он
находится
в
каталоге,
указываемом
параметром
background_dump_dest.
•В
файле регистрируются события: создание БД,
структурные изменения, соединения администраторов,
запуски и остановки БД.
2. В Oracle предусмотрен ряд представлений таблицы
sys.aud$, в которой хранятся
все данные. Список
представлений аудита можно получить следующим образом:
select object_name from dba_objects
where object_name like '%AUDIT%' and object_type='VIEW‘
and owner='SYS‘ order by object_name;

26. ПРИВИЛЕГИЯ "AUDIT SYSTEM"

ПРИВИЛЕГИЯ "AUDIT SYSTEM"
• Для пользователей, которые могут задать команду аудита,
необходимым условием является наличие привилегии
AUDIT SYSTEM.
• Для включения любой опции аудитинга объектов для
"чужих" объектов, или для установки умалчиваемых опций
аудитинга объектов, требуется системная привилегия
AUDIT ANY.

27. Словарь и информация по аудиту

27
Словарь и информация по аудиту
Чтобы проверить наличие того, что какие-нибудь
привилегии или выражения уже используются для
аудита, сделайте следующее:
SQL> select * from dba_stmt_audit_opts
union select * from dba_priv_audit_opts;

28. Аудит на уровне строк по триггерам

28
Аудит на уровне строк по триггерам
• Стандартные
средства
аудита
Oracle
не
поддерживают аудит на уровне строк или записей.
• Для аудита на уровне строк нужно использовать
триггеры базы данных и дифференцированный аудит.
• Следующий код поможет узнать, кто имеет триггеры и
для каких таблиц:
• SQL> select owner, trigger_name,trigger_type,
triggering_event,table_name
dba_triggers.
from

29.

29

30. ТАБЛИЦЫ СЛОВАРЯ ДАННЫХ ПО АУДИТУ

• AUD$
• ALL_DEF_AUDIT_OPTS
• DBA_OBJ_AUDIT_OPTS
• DBA_PRIV_AUDIT_OPTS
• DBA_STMT_AUDIT_OPTS
• DBA_AUDIT_SESSION
• DBA_AUDIT_TRAIL
• DBA_FGA_AUDIT_TRAIL
• DBA_COMMON_AUDIT_TRAIL (сочетает контрольные
записи журнала обычного и тонкого аудита.)
• DBA_AUDIT_POLICIES.

31. Рекомендации по выбору событий для мониторинга

31
Рекомендации по выбору событий для
мониторинга
• Определите вашу цель аудитинга. Определите точно,
какие типы действий вас интересуют.
• Сбалансируйте потребности в сборе информации с
возможностями хранить и обрабатывать эту
информацию.
• Отслеживайте сначала в общем, а потом конкретно.

32. Что мониторить?

32
Что мониторить?
• Масштабный аудит Oracle постоянно не используется, он
влияет на производительность.
• Простой набор основных действий аудита должен быть
активен все время.
• Необходимый минимум включает в себя отслеживание
доступа пользователей, использование системных
привилегий, и изменение в структуре базы данных (в
том числе в настройках аудита).
• Главный вопрос для взломщика БД – определить,
включен ли аудит и на каком уровне; это позволит ему
узнать, следят ли за ним и, в случае необходимости,
уничтожить журнал аудита. Такая информация должна
охраняться.

33. Рекомендации по аудиту

33
Рекомендации по аудиту
• Протоколирование команд, связанных с изменением
ролей и профилей пользователей:
CREATE PROFILE, ALTER PROFILE, DROP PROFILE,
CREATE ROLE, ALTER ROLE, DROP ROLE, SET ROLE.
• Также имеет смысл установить опцию SYSTEM GRANT,
для того чтобы могли отслеживать выдачу, отбор
системных привилегий и ролей с помощью команд
GRANT, REVOKE.
• Защите настройки аудита тоже надо уделить особое
внимание. Поэтому включают опцию SYSTEM AUDIT.

34. Рекомендации по аудиту

• AUDIT delete on SYS. AUD$ BY ACCESS
(SYS. AUD$ рекомендуют выносить за пределы
пространства system, но требуется уточнять об этом
у техподдержки, периодически очищать таблицу (
truncate)).
• Чтобы удалить записи из аудиторского журнала,
введите следующее предложения:
DELETE FROM sys.aud$;
DELETE FROM sys.aud$ WHERE obj$name = 'EMP';
• AUDIT_SYS_OPERATIONS=
TRUE (аудит
для пользователя SYS и пользователей,
имеющих привилегии SYSDBA и SYSOPER )

35. Пользователи с привилегиями SYSDBA или SYSOPER

35
Пользователи с привилегиями SYSDBA
или SYSOPER
• Пользователи с привилегиями SYSDBA
или SYSOPER могут подключиться,
когда БД закрыта.
• Контрольный
журнал
для
этих
привилегий должен быть сохранен вне
базы данных – журнал Windows, alertфайлы.
• Соединения SYSDBA или SYSOPER
всегда контролируются.

36. Пользователи с привилегиями SYSDBA или SYSOPER

36
Пользователи с привилегиями SYSDBA или
SYSOPER
• Можно управлять контрольным журналом посредством
параметра AUDIT_FILE_DEST.
• Если
операции
SYS
контролируются,
параметр
инициализации AUDIT_FILE_DEST управляет местом
хранения контрольных записей.
• На платформе Windows, значение по умолчанию для
журнала аудита приравнивается к журналу событий
Windows. На платформах UNIX и Linux, контрольные
записи сохраняются в расположении AUDIT_FILE_DEST.
• Определяет
директорию операционной системы для
журнала
аудита
в
случае
установки
параметра
AUDIT_FILE_DEST в значения os, xml, или xml, extended.
Так же в эту директорию пишется обязательная аудитная
информация и аудит для пользователя SYS при
установленном параметре AUDIT_SYS_OPERATIONS.

37.

Защита словаря данных
Пользователи,
которым
предоставлены
системные
полномочия ANY, могут удалять таблицы словаря данных.
Чтобы защитить словарь данных, конфигурационный
параметр
07_DICTIONARY_ACCESSIBILITY
в
файле
параметров необходимо установить в FALSE. Это ограничит
выдачу полномочий ANY только тем пользователям, которые
регистрируются с полномочиями SYSDBA.

38.

39. РЕКОМЕНДАЦИИ ПО ЗАЩИТЕ ТАБЛИЦ АУДИТА В СЛОВАРЕ БД

• ALTER TABLE AUD$ MOVE
TABLESPACE …;
• TRUNCATE TABLE AUD$;
• DELETE_CATALOG_ROLE,
SELECT_CATALOG_ROLE

40. ТРИГГЕРЫ И АУДИТ

41. Триггеры и аудит

41
Триггеры и аудит
CREATE OR REPLACE TRIGGER
system.hrsalary_audit AFTER UPDATE OF salary ON
hr.employees REFERENCING NEW AS NEW OLD AS
OLD FOR EACH ROW BEGIN IF :old.salary !=
:new.salary THEN INSERT INTO
system.audit_employees VALUES
(sys_context('userenv','os_user'), sysdate,
sys_context('userenv','ip_address'), :new.employee_id
|| ' salary changed from '||:old.salary|| ' to
'||:new.salary); END IF; END; /

42. Триггеры и аудит

42
Триггеры и аудит
• Посредством триггеров для отслеживания входа в систему
администратор
может
получить
данные,
идентифицирующие пользователя, который соединяется с
базой данных.
Примеры включают следующее:
• IP-адрес человека, входящего в систему.
• Первые 48 символов названия программы, которая
используется для соединения с экземпляром.
• Терминальное
имя,
которое
используется,
чтобы
соединиться с экземпляром.

43. ПРОВЕРКА ПОЛЬЗОВАТЕЛЕЙ, КОТОРЫЕ ИСПОЛЬЗУЮТ ОБЩУЮ УЧЕТНУЮ ЗАПИСЬ В БД ПО ДАННЫМ ТАБЛИЦ СЛОВАРЯ БД

select count(distinct(terminal)),
username from
dba_audit_session having
count (distinct(terminal))>1
group by username

44. НЕУДАЧНЫЕ ПОПЫТКИ ВХОДА

select count(*),username, terminal, to_char
(timestamp, 'DD-MON-YYYY'), returncode
from dba_audit_session
group by username, terminal,
to_char(timestamp,'DD-MON-YYYY'),
returncode;

45. ПОПЫТКИ ДОСТУПА НЕСУЩЕСТВУЮЩИХ ПОЛЬЗОВАТЕЛЕЙ В БАЗУ ДАННЫХ

select username, terminal, to_char
(timestamp,'DD-MON-YYYY
HH24:MI:SS') from
dba_audit_session where returncode
<>0 and not exists (select 'x'
from
dba_users
where
dba_users.username =
dba_audit_session.username)

46. ПОПЫТКИ ДОСТУПА В БАЗУ ДАННЫХ В НЕОБЫЧНОЕ ВРЕМЯ

select username, terminal,
action_name,
returncode,
to_char(timestamp,'DD-MON-YYYY HH24:MI:SS'),
to_char(logoff_time,'DD-MON-YYYY HH24:MI:SS')
from dba_audit_session where
to_date(to_char(timestamp,'HH24:MI:SS'),'HH24:MI
:SS') < to_date('08:00:00','HH24:MI:SS') or
to_date(to_char(timestamp,'HH24:MI:SS'),'HH24:MI
:SS') >to_date('19:30:00','HH24:MI:SS‘)

47. МНОЖЕСТВЕННЫЕ ПОПЫТКИ ДОСТУПА ПОД РАЗЛИЧНЫМИ УЧЕТНЫМИ ЗАПИСЯМИ С ОДНОГО ТЕРМИНАЛА

select
count
(distinct(username)),
terminal
from dba_audit_session
having
count(distinct(username))>1
group by terminal

48. Системные триггеры (System triggers)

48
Системные триггеры (System
triggers)
• Триггеры уровня схемы (schema triggers)- срабатывает
всегда, когда пользователь-владелец схемы запускает
событие (выполняет операцию), на которую должен
срабатывать триггер.
• В случае, если любой другой пользователь запускает
процедуру/функцию, которая вызывается с правами
создателя, и в этой процедуре/функции выполняется
операция, на которую создан системный триггер – этот
триггер сработает.
• Триггеры уровня базы данных (database triggers) триггер срабатывает, когда любой пользователь БД
выполняет команду, на которую срабатывает триггер.

49. Атрибуты системных триггеров

49
Атрибуты системных триггеров
ora_client_ip_address
• Возвращаемое значение и тип
• -ip-адрес клиента и Varchar2
• Пример:
IF (ora_sysevent = 'LOGON') THEN
v_addr := ora_client_ip_address; END
IF;

50. События срабатывания системных триггеров

50
События срабатывания системных
триггеров
• AFTER STARTUP - При запуске БД. Бывает только
уровня БД. При ошибке пишет в системный лог.
(ora_sysevent
ora_login_user
ora_instance_num
ora_database_name)
• BEFORE SHUTDOWN - Перед тем, как сервер начнет
процесс останова. Бывает только уровня БД. При
ошибке пишет в системный лог.
(ora_sysevent
ora_login_user
ora_instance_num
ora_database_name)

51. События срабатывания системных триггеров

51
События срабатывания системных
триггеров
• BEFORE DDL, AFTER DDL
• BEFORE GRANT, AFTER GRANT
Словари данных с информацией о
триггерах:
• dba_triggers – информация о триггерах
• dba_source — код тела триггера
• dba_objects – валидность триггера

52. ПРИМЕРЫ СИСТЕМНЫХ ТРИГГЕРОВ

52
ПРИМЕРЫ СИСТЕМНЫХ ТРИГГЕРОВ
create or replace trigger ddl_trigger
after create or alter or drop on SCHEMA
declare
l_sysevent varchar2(25); l_text varchar2(1000);
begin
if ora_dict_obj_owner <> 'METAXPO' then return; -- если
схема не METAXPO, то проигнорируем end if;
select ora_sysevent into l_sysevent from dual; -- запишем
название события
if (l_sysevent='CREATE' OR l_sysevent='DROP') then –
Создание/удаление объекта insert into log (operation, owner,
nameobject, typeobject) select ora_sysevent,
ora_dict_obj_owner, ora_dict_obj_name, ora_dict_obj_type
from dual;

53. ПРИМЕРЫ СИСТЕМНЫХ ТРИГГЕРОВ

53
ПРИМЕРЫ СИСТЕМНЫХ
ТРИГГЕРОВ
CREATE OR REPLACE TRIGGER
sys.on_logon1
AFTER LOGON ON DATABASE
begin
if user in ('ALEXEY') then
if USERENV('TERMINAL') <> 'ALEXEY' then
RAISE_APPLICATION_ERROR(-20001, '
'ALEXEY! Соединяйся со своего терминала!.');
end if;
end if;
end;

54. Пример использования функции Oracle USERENV

54
Пример использования функции Oracle
USERENV
USERENV( parameter )
Parameter
Explanation
CLIENT_INFO
Returns user session information stored using the
DBMS_APPLICATION_INFO package
ENTRYID
Available auditing entry identifier
INSTANCE
The identifier number of the current instance
ISDBA
Returns TRUE if the user has DBA privileges. Otherwise, it will return
FALSE.
LANG
The ISO abbreviation for the language
LANGUAGE
The language, territory, and character of the session. In the following
format: language_territory.characterset
SESSIONID
The identifier of the auditing session
TERMINAL
The OS identifier of the current session

55. Пример использования функции Oracle USERENV

55
Пример использования функции
Oracle USERENV

56. ДЕТАЛЬНЫЙ АУДИТ - FGA

Средства FGA позволяют отслеживать
доступ к конкретным строкам таблиц .
Оператор SELECT не инициируют запуск
триггеров,
но
средства
FGA
перехватывают операторы SELECT.
Пакет PL/SQL - DBMS_FGA применяется
для добавления, удаления, включения и
отключения политик детального аудита.
Политика определяет: критерии аудита,
действие аудита.

57. ДЕТАЛЬНЫЙ АУДИТ - FGA

• Процедура ADD_POLICY добавляет политику FGA
для таблицы.
• Процедура ENABLE_POLICY включает политику
FGA, ранее созданную для таблицы. Включаемая
политика должна быть создана заранее.
• Процедура DISABLE_POLICY отключает политику
FGA, ранее созданную для таблицы. Политика не
удаляется, но перестает действовать.
• В FGA события аудита инициируются при
каждом обращении к столбцам независимо от
того, изменяются они или нет. Это свойство
делает FGA более универсальным механизмом,
чем триггеры.

58. НЕКОТОРЫЕ ПАРАМЕТРЫ DBMS_FGA.ADD_POLICY

59. ДЕТАЛЬНЫЙ АУДИТ -ПРИМЕР

59
ДЕТАЛЬНЫЙ АУДИТ -ПРИМЕР
begin
dbms_fga.add_policy
( object_schema => 'BANK',
object_name => 'ACCOUNTS',
policy_name => 'ACCOUNTS_ACCESS',
audit_column => 'BALANCE',
audit_condition => 'BALANCE >= 1000' );
end;
Правило аудита определено для столбца BALANCE (остаток на
счете).
После добавления правила при выполнении оператора
update accounts set balance = 1200 where balance >= 3000;
в таблице FGA_LOG$ не появится запись аудита, т.к.
statement_types по умолчанию -. SELECT.
А в примере оно не специфицировано.

60. ДЕТАЛЬНЫЙ АУДИТ -ПРИМЕР

BEGIN
dbms_fga.add_policy
(object_schema => 'HR',
object_name => ' accounts ',
policy_name => 'policy_emp_sal_comm',
audit_condition => NULL,
audit_column =>' ACCOUNT_NO , BALANCE ',
audit_column_opts=> DBMS_FGA.ALL_COLUMNS,
statement_types => 'SELECT, UPDATE');
END;
/
Параметр audit_column_opts заставит FGA создавать записи аудита только
тогда, когда запрос обращается к обоим столбцам: ACCOUNT_NO и
BALANCE.
Запрос select account_no, balance from accounts инициирует создание записи
аудита:
А запрос select account_no from accounts не будет инициировать создание
записи аудита:
При обновлении заданных колонок заданной таблицы запись аудита
вставляется в автономной транзакции, поэтому она останется в таблице
даже после отката оператора UPDATE.

61. Различные сценарии, иллюстрирующие, выполняется или не выполняется аудит действий

SQL-оператор
select balance from
accounts;
select * from accounts;
Состояние аудита
Аудит выполняется. Пользователь выбирает
данные из столбца аудита BALANCE, заданного
при добавлении правила аудита.
Аудит выполняется. Даже если пользователь явно
не указывает столбец BALANCE, метасимвол "*" в
списке выборки неявно задает его выборку.
select cust_id from
Аудит выполняется. Даже если пользователь явно
accounts where balance < не указывает столбец BALANCE, его выборка
10000;
неявно задается в предложении WHERE.
select cust_id from
Аудит не выполняется. Пользователь не выбирает
accounts;
данные из столбца BALANCE.
Аудит не выполняется. Пользователь явно или
select count(*) from
неявно не выбирает данные из столбца
accounts;
BALANCE.

62.

62

63. ДЕТАЛЬНЫЙ АУДИТ

63
ДЕТАЛЬНЫЙ АУДИТ
Чтобы удалить правило, можно использовать
следующее:
begin dbms_fga.drop_policy
( object_schema => 'BANK',
object_name => 'ACCOUNTS',
policy_name => 'ACCOUNTS_ACCESS' );
end;
Чтобы изменить любые параметры правила, вы должны
удалить правило и добавить его снова с измененными
параметрами.

64. ДЕТАЛЬНЫЙ АУДИТ

64
ДЕТАЛЬНЫЙ АУДИТ
Вы можете отключить правило FGA :
begin dbms_fga.enable_policy
( object_schema => 'BANK',
object_name => 'ACCOUNTS',
policy_name => 'ACCOUNTS_ACCESS',
• enable => FALSE );
end;
• Для повторного включения правила используйте эту
же функцию, но в параметре enable (включение)
нужно установить значение TRUE.

65. Особенности FGA

65
Особенности FGA
• FGA вставляют записи аудита, используя автономные транзакции,
которые фиксируются в их собственном контексте. Если в DMLоператоре возникает ошибка или выполняется его откат,
вставленная запись аудита не откатывается.
• FGA записывают SQL-операторы, выполняемые пользователем, и
номера SCN, но не значения данных до и после изменения.
• Для извлечения этих значений следует применять отдельное
средство, использующее ретроспективные запросы к таблицам.
• Подход на основе триггеров позволяет фиксировать изменения в их
источнике, следовательно, регистрация старых и новых значений
гарантируется.
• Поскольку аудит происходит в сервере базы данных, а не в
приложении, действия регистрируются независимо от методов
доступа, используемых пользователями (через инструментальные
средства типа SQL*Plus или приложения), обеспечивая защиту от
неосторожного или неумелого обращения.

66. ДЕТАЛЬНЫЙ АУДИТ

• Представление DBA_AUDIT_POLICIES отображает
сведения об имеющихся в базе данных политиках
FGA.
• Представление
DBA_FGA_AUDIT_TRAIL
отображает журнал аудита FGA.
• Представление DBA_COMMON_AUDIT_TRAIL
объединяет записи аудита FGA и обычного аудита.
• Чтобы проверить оба журнала аудита, используйте
следующий запрос:
• select * from dba_common_audit_trail;

67. Представлениe DBA_AUDIT_POLICIES

67
Представлениe DBA_AUDIT_POLICIES
OBJECT_NAME
Владелец таблицы или представления, для которого
определено правило FGA.
Имя таблицы или представления.
POLICY_NAME
Имя правила аудита, например, ACCOUNTS_ACCESS.
POLICY_TEXT
Условие аудита, заданное при добавлении правила
аудита, например, BALANCE >= 11000.
POLICY_COLUMN
Столбец аудита, например, BALANCE.
OBJECT_SCHEMA
ENABLED
PF_SCHEMA
PF_PACKAGE
PF_FUNCTION
YES, если проверка правила аудита включена; NO − в
противном случае.
Схема, которой принадлежит модуль обработчика для
правила аудита, если он существует.
Имя пакета, содержащего модуль обработчика, если он
существует.
Имя процедуры модуля обработчика, если она
существует.

68. Представлениe DBA_FGA_AUDIT_TRAIL

68
Представлениe DBA_FGA_AUDIT_TRAIL
Идентификатор сеанса, в котором был выполнен запрос (Audit Session
SESSION_ID
Identifier); не совпадает с идентификатором сеанса (SID, Session
Identifier) в представлении V$SESSION.
TIMESTAMP
Отметка времени генерации записи аудита.
DB_USER
Имя пользователя базы данных, который выполнил запрос.
OS_USER
Имя пользователя операционной системы.
USERHOST
Имя машины, с которой соединен пользователь.
Идентификатор клиента, если установлен с помощью пакетной
CLIENT_ID
процедуры dbms_session.set_identifier.
Имя клиента, аутентифицированного внешне, например, LDAPEXT_NAME
пользователь.
OBJECT_SCHEMA Владелец таблицы, доступ к которой инициирует событие аудита.
OBJECT_NAME
Имя таблицы, доступ к которой инициирует событие аудита.
Имя правила аудита, инициирующего событие аудита. (Если для
таблицы определено несколько правил аудита, для каждого из них
POLICY_NAME
будет генерироваться запись аудита. В таком случае этот столбец
показывает, для какого правила была вставлена запись аудита.)
Системный номер изменения Oracle (System Change Number), на
SCN
момент которого была записана запись аудита.
SQL_TEXT
SQL-оператор, выполненный пользователем.
Переменные связывания, использованные в SQL-операторе, если
SQL_BIND
использовались.

69. Аудит FGA и обычный аудит: различия

69
Аудит FGA и обычный аудит:
различия
• Стандартный аудит должен быть включен на уровне БД
установкой AUDIT_TRAIL и перезапуском экземпляра
Oracle, чтобы он вступил в силу. FGA не требует никаких
изменений параметров;
• Включенная опция стандартного аудита для объекта
остается
постоянно.
Чтобы
дезактивировать
ее,
используют оператор NOAUDIT. Средства FGA могут быть
временно отключены и вновь включены без какой-либо
потери информации о метаданных;
• FGA могут обрабатывать только четыре типа операторов:
SELECT, INSERT, UPDATE и DELETE. Регулярный аудит
может обрабатывать много других.

70. Аудит FGA и обычный аудит: различия

70
Аудит FGA и обычный аудит: различия
• Средства стандартного аудита создают только одну
запись для сеанса (режим by session) или одну запись
при каждом доступе к объекту (режим by access). Это
умеренное потребление пространства важно для
управления пространством в таблицах журнала аудита.
Средства FGA более расточительны: они срабатывают
при каждом доступе, что приводит к большему росту
журнала аудита;
• Средства стандартного аудита могут записывать журнал
аудита в таблицы БД или в файлы ОС. Журнал аудита
FGA пишется только в таблицу базы данных FGA_LOG$.
В
FGA
вы
можете
создать
определяемые
пользователями обработчики событий аудита, чтобы
писать в файлы ОС, но их целостность не гарантируется;

71. Аудит FGA и обычный аудит: различия

71
Аудит FGA и обычный аудит:
различия
• Средства стандартного аудита могут быть настроены для
аудита объектов, создаваемых по умолчанию. Эта
возможность становится чрезвычайно полезной в тех
случаях, когда таблицы создаются во время исполнения.
Опция аудита объектов, создаваемых по умолчанию,
позволяет
включать
аудит
без
вмешательства
администратора базы данных.
• Это невозможно в FGA; правила аудита нужно создавать
для существующей таблицы, а это можно сделать только
после фактического создания таблицы;
• Для
выполнения
обычного
аудита
требуется
соответствующая системная привилегия или привилегия
выполнения оператора аудита; для FGA требуется только
привилегия выполнения пакета dbms_fga.

72. Рекомендации

72
Рекомендации
• Отслеживайте
минимальное
количество
предложений, пользователей или объектов,
необходимое
для
получения
целевой
информации.
• Это позволит не засорять аудиторский журнал
ненужной информацией и сэкономит ценную
память в табличном пространстве SYSTEM.

73. Рекомендации

73
Рекомендации
• Сбалансируйте потребности в сборе информации с
возможностями
хранить
и
обрабатывать
эту
информацию.
• Например, если вы организуете аудитинг с целью
собрать информацию о действиях в базе данных,
определите точно, какие типы действий вас
интересуют, и отслеживайте только эти действия, и
только в течение того времени, какое необходимо для
сбора нужной вам информации.
• Не отслеживайте объекты, если вас интересует лишь
информация о логическом вводе-выводе по каждой
сессии.

74. Рекомендации

74
Рекомендации
• Когда
начинают
отслеживать
подозрительные
действия, сначала, как правило, недостаточно
информации,
чтобы
подозревать
конкретного
пользователя или конкретные объекты.
• Поэтому опции аудитинга должны быть сначала более
общими.
• Когда предварительная аудиторская информация
получена и проанализирована,
общие опции
аудитинга должны быть отключены, и включены более
конкретные режимы.

75. Рекомендации

75
Рекомендации
• Отслеживая
в
базе
данных
подозрительную
деятельность,
защищайте аудиторский журнал, чтобы
нельзя
было
вручную
добавлять,
изменять
или
удалять
из
него
информацию.
• Архивируйте
аудиторские записи и
очищайте журнал.

76.

СПАСИБО ЗА ВНИМАНИЕ

77.

77
• 1. Какие два утверждения о возможностях FGA в Oracle
Database 10g являются правильными?
• Записи FGA хранятся в таблице SYS.FGA_LOG$ и
доступны через представление
DBA_FGA_AUDIT_TRAIL.
• Привилегия EXECUTE для пакета DBMS_FGA
необходима для того, чтобы управлять политикой
аудита FGA.
• Для активизации FGA на уровне базы данных необходимо
задать параметр инициализации AUDIT_TRAIL.
• Политику FGA нельзя активировать и заблокировать без
потери информации о метаданных.

78. МАСКАРАД - регистрация в качестве другого пользователя

79. SQL - инъекция

79
SQL - инъекция
• SQL-инъекция - способ нападения на БД в обход межсетевой
защиты.
• В методе параметры, передаваемые к БД через приложения,
изменяются таким образом, чтобы изменить выполняемый
SQL запрос (например, добавляя символ (‘) к параметру,
можно выполнить дополнительный запрос совместно с
первым).
Защита от SQL инъекции на ORACLE :
• Ревизия кода приложений и устранение проблем, которые
могут способствовать SQL- инъекции.
• Использование
принципа
наименьшего
количества
привилегий на уровне БД так, чтобы даже если кто-то смог
изменить SQL запрос, он не смог бы получить больше
информации, чем бы он мог получить через предназначенный
для этого интерфейс приложения.

80. SQL-инъекция

80
SQL-инъекция
Неправильные обращения против БД ORACLE:
• UNION можно добавить к SQL инструкции, чтобы выполнить
вторую инструкцию;
• Существующий SQL запрос может использовать обходные
пути, чтобы возвратить все данные.
• Доступен большой выбор установленных пакетов и
процедур, которые могут использоваться для чтения и
записи файлов на операционной системе;
• Могут быть внедрены INSERT, UPDATE и DELETE.
• Data Definition Language (DDL) может эксплуатироваться,
если он используется в динамической SQL строке;

81. SQL-инъекция

81
SQL-инъекция
• Web приложения наиболее уязвимы к нападениям SQL
инъекции. Они могут быть написаны, используя ASP, JSP
или другие языки.
• SQL инъекция это не проблема базы данных, а проблема
неправильно написанного Web приложения.
• https://www.securitylab.ru/analytics/216253.php
• https://defcon.ru/web-security/2784/
• https://habrahabr.ru/post/148151/

82. SQL-инъекция

82
SQL-инъекция
• Динамические
SQL-запросы
обычно
используют, чтобы обойти синтаксические
ограничения. Но часто использовать их не
рекомендуется, т.к.
есть
некоторые
проблемы в безопасности.
• Для
этого
используется
команда
EXECUTE.

83. SQL-инъекция

83
SQL-инъекция
Вот как выглядит пример:
DECLARE @TableName VarChar(200)
SET @TableName = "Products "
EXECUTE ('SELECT * FROM' + @TableName)
• Для сервера это просто строка. Т.к. сервер воспринимает
код как строку, то туда можно ставить все, что угодно.
• А EXECUTE пытается сделать из этой строки работающий
запрос и выполнить его.

84. ПОВЫШЕНИЕ ПРИВИЛЕГИЙ

CREATE OR REPLACE FUNCTION HACKIT RETURN
NUMBER
AUTHD CURRENT_USER
AS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT ';
COMMIT;
RETURN(0);
END;
/