Аудит – это наблюдение за выбранными действиями пользователей базы данных. Его обычное применение это контроль подозрительных операций и сбор информации об отдельных действиях в базе данных. В этой главе мы научимся включать, настраивать, просматривать и анализировать аудит, а также рассмотрим его расширения.
Включаем аудит
Для включения аудита нам достаточно изменить значение инициализационного параметра AUDIT_TRAIL. Для начала подключимся к экземпляру базы данных и выведем его значение:
SQL*Plus: Release 10.2.0.1.0 - Production on Mon Nov 24 21:39:30 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. Enter user-name: sys as sysdba Enter password: Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production SQL> SHOW PARAMETERS audit_trail; NAME TYPE VALUE ------------------------------------ ----------- ---------------------------- audit_trail string NONE
Как видим параметр, имеет значение NONE, то есть аудит находиться по умолчанию в выключенном состоянии. Включим его, присвоив параметру значение DB:
SQL> ALTER SYSTEM SET audit_trail=db SCOPE=SPFILE; System altered.
Для того чтобы изменения вступили в силу, нам необходимо перезагрузить экземпляр базы данных. Но прежде чем это сделать, изменим ещё один дополнительный инициализационный параметр AUDIT_SYS_OPERATIONS, отвечающий за включение аудита для пользователя SYS и пользователей имеющих привилегии SYSDBA и SYSOPER. Выведем его значение:
SQL> show parameters audit_sys_operations NAME TYPE VALUE --------------------------- ----------- ------------------------------------- audit_sys_operations boolean FALSE
Видно, что по умолчанию аудит действий для этой группы пользователей выключен. Включим его:
SQL> ALTER SYSTEM SET audit_sys_operations=true SCOPE=SPFILE; System altered.
Теперь, после того как все параметры были установлены в нужные значения, можно перезагрузить экземпляр:
SQL> SHUTDOWN Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 440401920 bytes Fixed Size 1287904 bytes Variable Size 130025760 bytes Database Buffers 306184192 bytes Redo Buffers 2904064 bytes Database mounted. Database opened.
Проверим, правильность установки значения инициализационных параметров:
SQL> SHOW PARAMETERS audit%r; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_sys_operations boolean TRUE audit_trail string DB
Значения правильные. Аудит включён, и можно переходить к его настройке.
Приступаем к настройке
Настройка аудита представляет собой включение или выключение опций протоколирования выполняемых операций. Установка опций требует наличие привилегий AUDIT SYSTEM и AUDIT ANY, и может происходить на трёх уровнях аудита: команд, привилегий и объектов схемы. Рассмотрим настройку каждого уровня по отдельности. Первое, что мы сделаем, это применим аудит для команды ALTER SYSTEM, которая может динамически изменить текущий экземпляр базы данных. Включение опции производится следующим оператором:
SQL> AUDIT alter system; Audit succeeded.
В результате, мы имеем первую установленную опцию и можем уже отслеживать действия по изменению текущего экземпляра базы данных. Правда следует сразу отметить, что включение опции не означает немедленное протоколирование команды для пользователей, которые в текущий момент времени уже подключены к базе данных. Аудит для них будет действовать, только начиная со следующего сеанса.
После того как мы произвели включение данной опции, мы должны проверить правильность её установки. Для этого нам надо сделать запрос к следующему представлению:
SQL> SELECT audit_option FROM dba_stmt_audit_opts; AUDIT_OPTION ---------------------------------------- ALTER SYSTEM
Из результатов запроса видно, что сейчас у нас в системе одна установленная опция ALTER SYSTEM, настроенная на протоколирование действий одноимённой команды. На самом деле большинство опций аудита команд включают в себя группы связанных операторов. Включим, к примеру, следующую опцию:
SQL> AUDIT user; Audit succeeded. SQL> SELECT audit_option FROM dba_stmt_audit_opts; AUDIT_OPTION ---------------------------------------- ALTER SYSTEM USER
В результате мы добавили аудит сразу на три команды: CREATE USER, ALTER USER и DROP USER, и с помощью одной включенной опции USER можем полностью отслеживать все действия, совершаемые с учетными записями пользователей. Всего опций аудита команд не один десяток. Можно конечно могли включить их все с помощью сокращения ALL, но политика аудита подразумевает ограничивать количество отслеживаемых событий, насколько это возможно. Поэтому мы включим только те опции, которые необходимы для минимального функционирования аудита. В дополнение к уже двум ранее установленным опциям, нам необходимо настроить протоколирование команд связанных с изменением ролей и профилей пользователей: CREATE PROFILE, ALTER PROFILE, DROP PROFILE, CREATE ROLE, ALTER ROLE, DROP ROLE, SET ROLE. Делается это с помощью включения двух опции PROFILE и ROLE. Также имеет смысл установить опцию SYSTEM GRANT, для того чтобы мы могли отслеживать выдачу, отбор системных привилегий и ролей с помощью команд GRANT, REVOKE. Защите настройки аудита тоже надо уделить особое внимание. Поэтому мы включим опцию SYSTEM AUDIT. Это позволит протоколировать действия совершаемые командами AUDIT и NOAUDIT. В заключение произведём установку опции SESSION, которая в определённом смысле является уникальной, так как не ассоциируется ни с одной командой. Смысл этой опции в формировании записи аудита при подключении сеанса и обновлении записи при его отключении. Включение всех вышеперечисленные опций можно оформить в виде одного оператора, что мы сейчас и сделаем:
SQL> AUDIT profile, role, system grant, system audit, session; Audit succeeded.
После того как нами была произведена установка аудита операторов относящихся в основном к системе, мы можем перейти к включению опций команд, связанных непосредственно с объектами, как типом. В первую очередь мы должны настроить протоколирование DDL команд, осуществляющих действия над таким важным объектом как таблица. Надо отследить не только создание, изменение и удаление таблицы, но и полную очистку хранящихся в ней данных. Поэтому следующей опцией, которую мы включим, будет опция TABLE. Она активирует аудит сразу трёх команд CREATE TABLE, DROP TABLE и TRUNCATE TABLE. В перечисленном списке нет команды ALTER TABLE, поэтому нам придётся настроить дополнительную опцию с одноимённым названием.
В качестве следующего типа объекта, который подвергнется аудиту, мы выберем триггер, так как он является важной частью в поддержании целостности данных. Здесь нам надо учитывать, что триггеры могут находиться в двух состояниях. Поэтому надо протоколировать не только команды создания и удаления триггера, но также и операторы его включения и выключения. И сделать это нам поможет включение опции TRIGGER, которая активирует аудит команд CREATE TRIGGER, ALTER TRIGGER EHABLE (DISABLE), DROP TRIGGER, ALTER TABLE ENABLE (DISABLE) ALL TRIGGERS.
Следующая опция аудита, которую мы рассмотрим, объединяет целый список типов объектов. Она имеет название PROCEDURE и включает аудит на команды CREATE и DROP применяемые к хранимым объектам. Активация данной опции зависит от нескольких условий и специфична для конкретной системы. Если, к примеру, происходит частая модификация хранимых объектов, которую осуществляет только администратор по просьбе разработчиков приложения, то данную опцию можно выключить, чтобы ограничить число записей в аудите. Если же лиц, которые могут модифицировать данный тип объектов несколько, то данную опцию лучше активировать. Мы же этого делать не будем, и поэтому произведем включение только первых трёх опций:
SQL> AUDIT table, alter table, trigger; Audit succeeded.
Последние опции, которые мы включим, относятся к протоколированию команд GRANT REVOKE, предоставляющих или отбирающих объектные привилегии. В качестве объектов здесь выступают хранимые объекты и таблицы. Для обнаружения несанкционированной выдачи на них привилегий, мы и включим две опции GRANT PROCEDURE и GRANT TABLE:
SQL> AUDIT grant procedure, grant table; Audit succeeded.
Теперь проверим результат нашей работы:
SQL> SELECT audit_option FROM dba_stmt_audit_opts; AUDIT_OPTION ---------------------------------------- ALTER SYSTEM SYSTEM AUDIT SYSTEM GRANT CREATE SESSION TABLE USER ROLE TRIGGER PROFILE ALTER TABLE GRANT TABLE GRANT PROCEDURE 11 rows selected.
Минимальный набор опций включен, и мы можем уже иметь хоть какое-то представление о действиях пользователей в базе данных. Но если количество этих действий достаточно велико это может привести к неоправданному росту журнала аудита и впоследствии к трудностям его анализа. Для того чтобы избежать этой ситуации, в аудите можно использовать фокусировку. Предназначение фокусировки вытекает из самого названия. Она необходима для сужения области действия аудита, с целью уменьшить количество генерируемых контрольных записей. По умолчанию, фокусировка для опций не осуществляется. Поэтому мы рассмотрим, её применение на конкретном примере установленной нами опции ROLE. Эта опция включает протоколирование четырёх команд: CREATE ROLE, ALTER ROLE, DROP ROLE, SET ROLE. Если приложения базы данных построены по принципу включения ролей, то при большом количестве работающих пользователей будет генерироваться значительное количество записей аудита из-за выполнения команды SET ROLE. Попробуем избежать это ситуации, установив эту опцию только для неудачного выполнения команд. Для начала посмотрим режим фокусировки для всех настроенных нами опций аудита команд, выполнив следующий запрос:
SQL> SELECT audit_option, success, failure FROM dba_stmt_audit_opts; AUDIT_OPTION SUCCESS FAILURE ---------------------------------------- ---------- ---------- ALTER SYSTEM BY ACCESS BY ACCESS SYSTEM AUDIT BY ACCESS BY ACCESS SYSTEM GRANT BY ACCESS BY ACCESS CREATE SESSION BY ACCESS BY ACCESS TABLE BY ACCESS BY ACCESS USER BY ACCESS BY ACCESS ROLE BY ACCESS BY ACCESS TRIGGER BY ACCESS BY ACCESS PROFILE BY ACCESS BY ACCESS ALTER TABLE BY ACCESS BY ACCESS GRANT TABLE BY ACCESS BY ACCESS GRANT PROCEDURE BY ACCESS BY ACCESS 11 rows selected.
Значение BY ACCESS в столбце SUCCESS(FAILURE) говорит о том, что записи аудита для данной опции будут образовываться при каждом удачном (неудачном) выполнении команды. Этот режим для DDL команд устанавливается по умолчанию и фокусировка здесь отсутствует. Отменим регистрацию удачного выполнения команды для опции ROLE:
SQL> NOAUDIT role WHENEVER SUCCESSFUL; Noaudit succeeded. SQL> SELECT audit_option, success, failure FROM dba_stmt_audit_opts; AUDIT_OPTION SUCCESS FAILURE ---------------------------------------- ---------- ---------- ALTER SYSTEM BY ACCESS BY ACCESS SYSTEM AUDIT BY ACCESS BY ACCESS SYSTEM GRANT BY ACCESS BY ACCESS CREATE SESSION BY ACCESS BY ACCESS TABLE BY ACCESS BY ACCESS USER BY ACCESS BY ACCESS ROLE NOT SET BY ACCESS TRIGGER BY ACCESS BY ACCESS PROFILE BY ACCESS BY ACCESS ALTER TABLE BY ACCESS BY ACCESS GRANT TABLE BY ACCESS BY ACCESS GRANT PROCEDURE BY ACCESS BY ACCESS 11 rows selected.
В столбце SUCCESS напротив опции ROLE появилось значение NOT SET. Теперь при удачном выполнении команд связанных с действиями над ролями аудит генерироваться не будет. Количество записей, конечно, уменьшится, но мы не сможем больше отслеживать создание, изменение и удаление ролей. Впрочем, как обойти этот недостаток, мы рассмотрим в настройке следующего типа аудита - аудита привилегий.
В настройке аудита привилегий в качестве опций используются непосредственно системные привилегии, и генерация аудита осуществляется в том случае, если эти привилегии применяются при выполнении SQL оператора. Настройка этого типа аудита осуществляется тогда, когда требуется настроить протоколирование не связанного списка команд, а конкретных операторов. Рассмотрим это на примере всё той же опции ROLE. С целью уменьшения количества генерируемых записей для неё была применена фокусировка, и теперь удачные выполнения DDL команд над ролями не попадают в аудит. Чтобы исправить эту ситуацию мы будем отслеживать удачное применение привилегий CREATE ROLE, ALTER ANY ROLE, DROP ANY ROLE. Для этого выполним следующий оператор:
SQL> AUDIT create role, alter any role, drop any role WHENEVER SUCCESSFUL; Audit succeeded.
Теперь выберем список опций привилегий, к которым применён аудит:
SQL> SELECT privilege, success, failure FROM dba_priv_audit_opts; PRIVILEGE SUCCESS FAILURE ---------------------------------------- ---------- ---------- ALTER ANY ROLE BY ACCESS NOT SET DROP ANY ROLE BY ACCESS NOT SET CREATE ROLE BY ACCESS NOT SET CREATE SESSION BY ACCESS BY ACCESS ALTER SYSTEM BY ACCESS BY ACCESS 5 rows selected.
В результате, все удачно выполненные команды, которые требуют привилегий, CREATE ROLE, ALTER ANY ROLE и DROP ANY ROLE теперь будут попадать в аудит. Так, используя совместную фокусировку аудита команд и привилегий, нам удалось сократить количество генерируемых записей за счет исключения протоколирования успешного выполнения команды SET ROLE. Но фокусировка этих двух типов аудита не ограничивается только результатом выполнения команд, её также можно применять и для конкретных пользователей. Рассмотрим это на основе демонстрационной схемы HR. Для этого создадим предварительно нужные нам роли и учётные записи пользователей. Сделав запрос к справочнику EMPLOYEES, мы увидим, что в фирме имеются пять служащих IT отдела:
SQL> SELECT first_name, last_name FROM hr.employees WHERE job_id = 'IT_PROG'; FIRST_NAME LAST_NAME -------------------- ------------------------- Alexander Hunold Bruce Ernst David Austin Valli Pataballa Diana Lorentz
Допустим, что двое из них Alexander Hunold и Bruce Ernst осуществляют сопровождение объектов схемы HR. Так как у этих пользователей довольно широкие привилегии в этой схеме, нам потребуется отслеживать все DML команды, которые они могут выполнить. Поэтому включим для них следующие опции:
SQL> AUDIT select table, insert table, update table, delete table BY ah, be; Audit succeeded.
Проверим список опций команд для пользователей:
SQL> SELECT user_name, audit_option, success, failure FROM dba_stmt_audit_opts WHERE user_name IS NOT NULL; USER_NAME AUDIT_OPTION SUCCESS FAILURE --------- ---------------------------------------- ---------- ---------- AH SELECT TABLE BY SESSION BY SESSION AH INSERT TABLE BY SESSION BY SESSION AH UPDATE TABLE BY SESSION BY SESSION AH DELETE TABLE BY SESSION BY SESSION BE SELECT TABLE BY SESSION BY SESSION BE INSERT TABLE BY SESSION BY SESSION BE UPDATE TABLE BY SESSION BY SESSION BE DELETE TABLE BY SESSION BY SESSION
Теперь мы будем знать, осуществлялся ли доступ к таблицам и представлениям схемы HR со стороны пользователей AH и BE. Это позволит сократить количество записей по сравнению со случаем, когда нам пришлось бы включать протоколирование этих действий для всех пользователей, а затем выискивать в журнале аудита записи нужного нам пользователя. Здесь я хочу обратить внимание на содержание столбцов SUCCESS и FAILURE в списке опций, как ещё одного из видов фокусировки. До этого мы встречали в них только значение BY ACCESS, что означало, что запись аудита будет создаваться при каждом выполнении SQL оператора включенной опции. Данный режим является единственным для опций, содержащих набор DDL команд. Но для аудита DML операторов существует и ещё один режим - BY SESSION. При данном виде фокусировки запись аудита будет образовываться только один раз за весь сеанс и только при первом выполнении команды. Данный режим используется для фиксации самого факта доступа к данным и для опций DML команд устанавливается по умолчанию.
Рассматривая последний пример, мы увидели, как можно настроить аудит доступа пользователя к данным таблиц и представлений. Но используемый нами вариант не лишен недостатков. В аудит попутно попадут все обращения пользователя к доступным ему представлениям и таблицам. Такой аудит удобно включать только кратковременно, для поиска подозрительной активности в базе данных. Если же нам потребуется постоянно отслеживать доступ к одному или нескольким объектам, то такой метод становиться очень затратным. Для того чтобы исключить такую ситуацию можно применить ещё один тип аудита – аудит объектов схемы. Его отличие от аудита команд и привилегий состоит в том, что протоколирование применяется только к конкретному объекту, а опции ассоциируются с одиночными командами. Рассмотрим это на основе последнего примера. Для того чтобы сократить количество записей аудита генерируемых текущей настройкой, попробуем отследить доступ к данным только критически важных таблиц HR.EMPLOYEES и HR.JOBS. Вначале отключим лишние опции аудита DML команд для пользователей AH и BE:
SQL> NOAUDIT insert table, update table, delete table, select table BY ah, be; Noaudit succeeded.
Теперь активируем опции аудита объектов схемы для таблиц hr.employees и hr.jobs:
SQL> AUDIT select, insert, update, delete ON hr.employees; Audit succeeded. SQL> AUDIT select, insert, update, delete ON hr.jobs; Audit succeeded.
В заключение посмотрим результат нашей работы:
SQL> SELECT owner, object_name, object_type, del, ins, upd, sel FROM dba_obj_audit_opts; OWNER OBJECT_NAME OBJECT_TYPE DEL INS UPD SEL ----- ----------- ----------------- --------- --------- --------- --------- HR JOBS TABLE S/S S/S S/S S/S HR EMPLOYEES TABLE S/S S/S S/S S/S
Столбцы DEL, INS, UPD, SEL обозначают сокращенные названия опций аудита объектов схемы, а значение S/S является фокусировкой и расшифровывается следующим образом. Буква S перед знаком / и после означает, что протоколирование настроено на удачное или неудачное выполнение команды. Запись при этом будет образовываться только один раз за сеанс при первом выполнении команды (режим SESSION). В результате, мы можем отслеживать доступ только к этим двум таблицам, что позволит сократить количество протоколируемой информации. Правда, данный вид аудита имеет один недостаток. К нему не может применяться фокусировка по конкретному пользователю. Вследствие чего, в данном примере нам придётся отфильтровывать аудитные записи сделанные командами пользователей AH и BE непосредственно при просмотре аудита.
Как посмотреть аудит?
Включая аудит, мы указали значение инициализационного параметра AUDIT_TRAIL равное DB. Это означает, что в качестве хранилища записей (журнала аудита) у нас выступает таблица AUD$ в схеме SYS. Поэтому, для просмотра аудита мы можем обратиться непосредственно к этой таблице напрямую. Но гораздо удобнее это делать через системные представления журнала аудита. Ознакомимся с ними более подробно. Первое представление, которое мы рассмотрим, называется DBA_AUDIT_TRAIL. Оно единственное напрямую обращается к таблице AUD$ и содержит список всех её записей. Выведем описание этого представления:
SQL> DESC dba_audit_trail;
Name Null? Type
----------------------------------------- -------- -------------------------
OS_USERNAME VARCHAR2(255)
USERNAME VARCHAR2(30)
USERHOST VARCHAR2(128)
TERMINAL VARCHAR2(255)
TIMESTAMP DATE
OWNER VARCHAR2(30)
OBJ_NAME VARCHAR2(128)
ACTION NOT NULL NUMBER
ACTION_NAME VARCHAR2(28)
NEW_OWNER VARCHAR2(30)
NEW_NAME VARCHAR2(128)
OBJ_PRIVILEGE VARCHAR2(16)
SYS_PRIVILEGE VARCHAR2(40)
ADMIN_OPTION VARCHAR2(4)
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
STATEMENTID NOT NULL NUMBER
RETURNCODE NOT NULL NUMBER
PRIV_USED VARCHAR2(40)
CLIENT_ID VARCHAR2(64)
ECONTEXT_ID VARCHAR2(64)
SESSION_CPU NUMBER
EXTENDED_TIMESTAMP TIMESTAMP(6) WITH TIME
ZONE
PROXY_SESSIONID NUMBER
GLOBAL_UID VARCHAR2(32)
INSTANCE_NUMBER NUMBER
OS_PROCESS VARCHAR2(16)
TRANSACTIONID RAW(8)
SCN NUMBER
SQL_BIND NVARCHAR2(2000)
SQL_TEXT NVARCHAR2(2000)
Предназначение столбцов OS_USERNAME, USERNAME, USERHOST, TERMINAL особо объяснять не надо. Они идентифицируют пользователя, аудит действий которого был выполнен, и компьютер на котором эти действия исполнялись. Столбцы TIMESTAMP и EXTENDED_TIMESTAMP определяют временную метку создания записи в локальном и гринвичском часовом поясе. Поля OWNER, OBJ_NAME указывают объект, на который направлено действие. Код и название этого действия можно узнать из столбцов ACTION и ACTION_NAME. Если была применена команда RENAME, то столбцы NEW_OWNER и NEW_NAME покажут новое название объекта, также здесь содержится имя основного объекта для некоторых типов команд. Группа столбцов OBJ_PRIVILEGE, SYS_PRIVILEGE, ADMIN_OPTION, GRANTEE относиться к выдаче, отбору прав и указывает на сами привилегии, опцию ADMIN и имя пользователя, всё то, что задаётся в командах GRANT или REVOKE. Следующий столбец AUDIT_OPTION показывает параметры аудита, установленные командой AUDIT. В поле SES_ACTIONS отображается суммарная информация по сеансу, в случае установления режима фокусировки SESSION. Группа столбцов LOGOFF_TIME, LOGOFF_LREAD, LOGOFF_PREAD, LOGOFF_LWRITE, LOGOFF_DLOCK относится к информации завершения работы сеанса и обозначает время завершения сеанса, количество логических, физических чтений за сеанс, логических записей и взаимоблокировок, обнаруженных во время работы. В поле COMMENT_TEXT содержится текстовый комментарий к записи аудита. Иногда кстати довольно полезная вещь. Группа столбцов SESSIONID, ENTRYID, STATEMENTID, является, пожалуй, самой главной в представлении. Она содержит информацию о числовых идентификаторах сеанса, записи и выполняемой команды аудита. Именно по информации из двух первых полей можно гарантированно удалить отдельную запись аудита. Следующее поле RETURNCODE – это код ошибки, генерируемый действием. Столбец PRIV_USED при этом показывает системную привилегию, которая использовались для выполнения этого действия. И наконец, последние поля SQL_BIND и SQL_TEXT относятся к расширенному режиму работы аудита и содержат информацию обо всех связанных переменных и тексте SQL оператора, выполняемого действия.
Следующие представления журнала аудита, которые мы рассмотрим, базируются на представлении DBA_AUDIT_TRAIL, и служат для удобства просмотра записей аудита, так как различаются только информацией выводимой для определённых групп действий. Например, представление DBA_AUDIT_EXISTS служит для вывода записей аудита операций, которые завершились неудачей из-за того, что объект не был найден. Представление DBA_AUDIT_OBJECT показывает аудит всех объектов в базе данных. В DBA_AUDIT_SESSION содержатся записи касающиеся команд CONNECT и DISCONNECT. И наконец, последнее представление DBA_AUDIT_STATEMENT отображает записи аудита команд GRANT, REVOKE, AUDIT, NOAUDIT, ALTER SYSTEM. Делая запрос к этим представлениям, мы можем получить доступ ко всей протоколируемой информации собираемой с помощью аудита. Что даёт нам шанс провести её полный анализ.
Проводим анализ
И так, мы настроили аудит. Информация о действиях пользователей в базе данных начала собираться. Мы знаем, где ёё можно посмотреть. Но всё это будет напрасно, если мы не сможем разобраться в этом большом количестве разнообразных данных. Поэтому попытаемся выработать основные этапы анализа аудита. Начнём с подключений пользователей к базе данных. Так как в больших системах количество соединений может составлять тысячи за день, нас в первую очередь будут интересовать подключения пользователей обладающих расширенными привилегиями. К таким пользователям относятся системные учётные записи, отдельная учётная запись администратора базы данных, если таковая имеется. Так же к ним можно отнести и пользователей, которые могут изменить критически важные данные, например известные нам пользователи AH и BE. Такие подключения следует, прежде всего, отслеживать по месту откуда делается попытка соединения. Если соединение осуществлялось с компьютера имя, которого отличается от привычного имени, то, скорее всего, произошёл взлом или утечка регистрационных данных учётной записи. Во всяком случае, на эти записи следует обратить внимание. Выполним, к примеру, следующий запрос:
SQL> SELECT username, terminal, timestamp
2 FROM dba_audit_session
3 WHERE ((username IN ('SYS', 'SYSTEM') AND terminal 'W001')
4 OR (username = 'AH' AND terminal 'W002')
5 OR (username = 'BE' AND terminal NOT IN ('W003', 'W004'))
6 )
7 AND returncode = 0;
USERNAME TERMINAL TIMESTAMP
-------- --------- -------------------
BE W005 17.01.2009 21:48:56
В результате мы видим, что было произведено успешное подключение под учётной системной записью BE с компьютера W005, хотя пользователь раньше всегда соединялся только с терминалов W003 или W004. Возможно, это говорит о том, что учётная запись BE была взломана. Если же проверка успешных подключений привилегированных пользователей не показала ничего подозрительного, то нам стоит проанализировать соединения, которые по тем или иным причинам завершились с ошибкой. Делается это с помощью следующего запроса:
SQL> SELECT username, timestamp, returncode FROM dba_audit_session WHERE returncode 0; USERNAME TIMESTAMP RETURNCODE -------- ------------------- ---------- AH 17.01.2009 21:48:54 1017 BE 17.01.2009 21:48:55 1017 BE 17.01.2009 21:48:55 1017 BE 17.01.2009 21:48:55 1017 BE 17.01.2009 21:48:55 1017
В данном случае видно, что попытка подключения под пользователями AH и BE окончилась неудачей. Но если одиночное неудачное соединение пользователя AH можно списать на ошибку ввода пароля. То аудит подключений пользователя BE может говорить о попытке взлома учётной записи. Кроме вопросов касающихся безопасности аудит подключений можно использовать и в целях определения сеансов сильно загружающих экземпляра базы данных. Всё дело в том, что при удачном завершении подключения в аудит происходит запись некоторой статистики сеанса. Поэтому обращаясь к столбцам SESSION_CPU, LOGOFF_LREAD, LOGOFF_PREAD, LOGOFF_DLOCK можно находить сеансы которые используют, слишком большое количество процессорного времени, осуществляют много физических и логических чтений или имеют взаимоблокировки. Выполним, к примеру, следующий запрос:
SQL> SELECT username, sessionid, timestamp, logoff_time, session_cpu FROM dba_audit_session WHERE session_cpu > 2880000; USERNAME SESSIONID TIMESTAMP LOGOFF_TIME SESSION_CPU -------- ---------- ------------------- ------------------- ----------- VP 162 28.12.2008 08:00:00 28.12.2008 17:00:00 3000000
Здесь мы видим, что сеанс пользователя VP длился девять часов, причём время, в течение которого использовался процессор, составило более восьми часов. Это, скорее всего, говорит о ненормальной работе приложения, в котором работал пользователь. Определить, какое это приложение можно только по числовому идентификатору сеанса SESSIONID. Ему соответствует поле AUDSID представления V$SESSION. К сожалению когда мы будем просматривать аудит мы уже не найдем в этом представлении информацию о сеансе. Поэтому нам придётся дополнительно вести историю сеансов с помощью системных триггеров. Разобравшись с подключениями и не выявив попыток взлома или несанкционированного использования учётных записей, можно попытаться разобраться в остальных действиях пользователей. И начать это лучше с проверки выполнения системных команд. К ним в первую очередь стоит отнести команду ALTER SYSTEM динамически меняющую экземпляр базы данных, команды выдачи, отбора привилегий GRANT и REVOKE, операторы изменения настройки аудита AUDIT и NOAUDIT. Выбрать все записи, образующиеся при выполнении этих команд можно с помощью следующего запроса:
SQL> SELECT username, TIMESTAMP, owner, obj_name, action_name, obj_privilege, 2 sys_privilege, admin_option, grantee, audit_option, returncode 3 FROM dba_audit_statement; USERNAME TIMESTAMP OWNER OBJ_NAME ACTION_NAME OBJ_PRIVILEGE SYS_PRIVILEGE ADMI GRANTEE AUDIT_OPTION RETURNCODE -------- ------------------- ----- ----------- ------------ ---------------- ------------- ---- ------- ------------ ---------- SYSTEM 17.01.2009 22:46:13 SYSTEM AUDIT PROCEDURE 0 SYSTEM 17.01.2009 22:46:13 HR COUNTRIES GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:13 HR DEPARTMENTS GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:13 HR EMPLOYEES GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:13 HR JOB_HISTORY GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:14 HR JOBS GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:14 HR LOCATIONS GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:14 HR REGIONS GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:14 SYSTEM GRANT ALTER SESSION - HR_PROG 0 SYSTEM 17.01.2009 22:46:14 CONNECT GRANT ROLE - AH 0 SYSTEM 17.01.2009 22:46:14 CONNECT GRANT ROLE - BE 0 SYSTEM 17.01.2009 22:46:14 CONNECT GRANT ROLE - VP 0 SYSTEM 17.01.2009 22:46:14 HR_PROG GRANT ROLE A AH 0 SYSTEM 17.01.2009 22:46:14 ALTER SYSTEM 0 AH 17.01.2009 22:46:15 HR_PROG GRANT ROLE - BE 0 BE 17.01.2009 22:46:15 HR_PROG GRANT ROLE - VP 1932 16 rows selected.
Попробуем провести анализ полученного результата. Первая запись говорит нам о том, что администратором была включена опция аудита PROCEDURE. На это указывает действие SYSTEM AUDIT в столбце ACTION_NAME и название опции в столбце AUDIT_OPTION. Далее следует семь записей, отображающие выдачу администратором объектных привилегий роли HR_PROG, о чём свидетельствует тип действия SYSTEM AUDIT. Столбцы OWNER и OBJ_NAME при этом идентифицируют объект, на который выдаются права, а столбец GRANTEE получателя этих привилегий. Расшифровку выдаваемых прав, можно осуществить с помощью значения столбца OBJ_PRIVILEGE. Здесь каждое положение символа соответствует определённой объектной привилегии. Если символ имеет значение Y, то значит, привилегия на объект была предоставлена. В нашем случае роли были предоставлены все объектные привилегии, которые имеются для данного типа объекта. В следующей записи аудита присутствует действие SYSTEM GRANT, означающее, что администратором была произведена выдача системной привилегии роли HR_PROG. Посмотреть какая привилегия при этом выдавалась можно в столбце SYS_PRIVILEGE. В нашем случае там находится значение ALTER SESSION. Далее мы видим группу записей с общим действием GRANT ROLE. Это действие относится к предоставлению роли пользователям или другим ролям, выдаваемая роль при этом отображается в столбце OBJ_NAME. В нашем случае была произведена выдача администратором роли CONNECT пользователям AH, BE, VP и роли HR_PROG пользователю AH. Причём в последнем случае роль была предоставлена пользователю с правом передачи, о чём свидетельствует присутствие символа A в столбце ADMIN_OPTION. Четырнадцатая запись аудита, пожалуй, не нуждается в пояснении. Действие ALTER SYSTEM явно указывает на то, что администратором была выполнена в системе одноименная команда и дополнительной информации мы здесь не увидим. Последние две записи аудита относятся, как было ранее рассмотрено, к предоставлению ролей пользователям. Но выдачу этих ролей осуществляют не привилегированные пользователи. Так мы видим, что пользователь AH предоставил роль HR_PROG пользователю BE, без права передачи, который в свою очередь попытался выдать эту роль пользователю VP, но потерпел неудачу. Ошибка при этом отобразилась в столбце RETURNCODE. Анализ аудита, осуществляемый с использованием представления DBA_AUDIT_STATEMENT, имеет большое значение, так как именно на этом этапе есть возможность определить попытки повышения привилегий учётной записи и вероятность замести следы несанкционированных действий путём изменения настроек аудита. Поэтому надо внимательно анализировать все без исключения записи на предмет, кто выполняет, какие действия, в какое время и главное откуда. Если же нам на этом этапе не удалось обнаружить никаких подозрительных действий, то мы можем спокойно переходить к следующему виду анализа аудита – анализу действий над объектами. Под объектами здесь подразумевается не только объекты схемы, но и системные объекты: пользователи, профили, роли, табличные пространства и т.д. Посмотреть аудит этих объектов можно с помощью следующего запроса:
SQL> SELECT username, timestamp, owner, obj_name, action_name, new_owner, 2 new_name, ses_actions, returncode 3 FROM dba_audit_object; USERNAME TIMESTAMP OWNER OBJ_NAME ACTION_NAME NEW_O NEW_NAME SES_ACTIONS RETURNCODE -------- ------------------- ----- ---------------- -------------- ----- --------- ---------------- ---------- SYSTEM 17.01.2009 22:46:13 HR_PROG CREATE ROLE 0 SYSTEM 17.01.2009 22:46:14 AH CREATE USER 0 SYSTEM 17.01.2009 22:46:14 BE CREATE USER 0 SYSTEM 17.01.2009 22:46:14 VP CREATE USER 0 SYSTEM 17.01.2009 22:46:14 HR SECURE_EMPLOYEES ENABLE TRIGGER 0 AH 17.01.2009 22:46:15 HR EMPLOYEES SESSION REC ----------F----- 0 AH 17.01.2009 22:46:15 HR SECURE_EMPLOYEES DISABLE TRIGGER 1031 AH 17.01.2009 22:46:15 HR JOBS SESSION REC ---------SS----- 0 SYSTEM 17.01.2009 22:46:15 HR SECURE_EMPLOYEES CREATE TRIGGER HR EMPLOYEES 0 AH 17.01.2009 22:46:15 HR EMPLOYEES SESSION REC ----------S----- 0 BE 18.01.2009 20:31:56 HR JOBS SESSION REC ---------B------ 0 11 rows selected.
Проанализируем полученный результат. В первых четырёх записях мы видим, что администратор создал роль HR_PROG и учетные записи пользователей AH, BE, VP. Их имена отображены в столбце OBJ_NAME, а действия совпадают с названиями применяемых SQL команд. После этого администратор включил триггер безопасности HR.SECURE_EMPLOYEES. На это указывает действие ENABLE TRIGGER и имя объекта в полях OWNER и OBJ_NAME. Далее пользователь AH попытался обратиться к таблице HR.EMPLOYEES. Но вместо какого либо понятного нам действия, в столбце ACTION_NAME мы видим лишь значение SESSION REC. На самом деле это значение означает, что запись факта всех действий для этого объекта в течение сеанса будет отображаться в этой записи, так как настройке опций был применён режим по умолчанию BY SESSION. Определить какие команды применялись к данному объекту можно по положению специального символа в столбце SES_ACTIONS. В нашем случае это положение соответствует команде UPDATE, а сам символ имеет значение F, что означает неудачное выполнение команды. После этого пользователь AH попытался выключить триггер безопасности HR.EMPLOYEES. Но потерпел неудачу. Это видно по значению поля RETURNCODE. Далее этим же пользователем были выполнены две команды SELECT и UPDATE применительно к объекту HR.JOBS. Это было определено из положения символов S в значении столбца SES_ACTIONS. Кстати данный символ свидетельствует об успешном выполнении команды. Продолжая анализ, мы видим, что в следующей записи присутствует действие CREATE TRIGGER, которое говорит нам о том, что администратор изменил триггер HR.SECURE_EMPLOYEES. Поле NEW_NAME здесь указывает на основной объект. В нашем случае это таблица HR.EMPLOYEES, к которой относится данный триггер. После того как триггер пересоздан, пользователь AH получил возможность удачно выполнить команду UPDATE для таблицы HR.EMPLOYEES, на это указывает положение символа S в значении столбца SES_ACTIONS. И наконец, в последней записи аудита видно как пользователь BE осуществил доступ к таблице HR.JOBS. Но в значении столбца SES_ACTIONS мы видим только символ B. Позиция его соответствует выполненной команде SELECT, но результат выполнения команды неизвестен. На самом деле присутствие этого символа означает, что произошло удачное и одновременно неудачное выполнение команды в течение сеанса.
Сопровождаем журнал
По мере роста количества записей в журнале аудита, возникает необходимость в проведении определённых действий связанных с сопровождением этого журнала. Если этого не делать, то мы можем столкнуться с рядом проблем, от сложности в анализе аудита, до полной остановки системы в случае переполнения табличного пространства SYSTEM. Что же это за действия? Перечислим их - это удаление лишних и архивирование нужных записей, сброс маркера максимального уровня заполнения таблицы SYS.AUD$, а также проведение усечения данной таблицы. Теперь рассмотрим их более подробно. В первую очередь необходимо время от времени удалять лишние записи из журнала аудита. Стратегия удаления может быть разнообразной. Допустим можно выборочно удалять отдельные записи аудита непосредственно в процессе анализа. Например, выполним следующий запрос и проанализируем полученный результат:
SQL> SELECT username, terminal, timestamp, owner, obj_name, action_name, 2 sessionid, entryid, statementid 3 FROM dba_audit_object 4 WHERE username = 'SYSTEM'; USERNAME TERMINAL TIMESTAMP OWNER OBJ_NAME ACTION_NAME SESSIONID ENTRYID STATEMENTID -------- --------- ------------------- ----- ---------------- -------------- --------- ------- ----------- SYSTEM W001 18.01.2009 20:31:53 HR_PROG CREATE ROLE 831 3 13 SYSTEM W001 18.01.2009 20:31:53 AH CREATE USER 831 12 58 SYSTEM W001 18.01.2009 20:31:53 BE CREATE USER 831 13 63 SYSTEM W001 18.01.2009 20:31:53 VP CREATE USER 831 14 68 SYSTEM W001 18.01.2009 20:31:53 HR SECURE_EMPLOYEES ENABLE TRIGGER 831 19 83 SYSTEM W001 18.01.2009 20:31:55 HR SECURE_EMPLOYEES CREATE TRIGGER 852 2 8
Подозрительных действий не обнаружено, и мы можем удалить, к примеру, первую запись. Удаление надо производить непосредственно из таблицы SYS.AUD$, используя при этом в качестве ключа значения столбцов SESSIONID и ENTRYID:
SQL> DELETE sys.aud$ WHERE sessionid = 831 AND entryid = 3; 1 row deleted.
Но такой способ годится только при небольшом количестве записей. Гораздо более удобно групповое удаление. Для этого можно использовать запросы, к представлениям журнала аудита применяемые при анализе. В качестве примера удалим с помощью следующей команды все санкционированные подключения привилегированных пользователей:
SQL> DELETE
2 FROM sys.aud$
3 WHERE sessionid IN
4 (
5 SELECT sessionid
6 FROM dba_audit_session
7 WHERE (
8 (username IN ('SYS', 'SYSTEM') AND terminal = 'W001')
OR
9 (username = 'AH' AND terminal = 'W002') OR
10 (username = 'BE' AND terminal IN ('W003','W004'))
11 ) AND returncode = 0
12 ) AND action# IN (100,101,102);
6 rows deleted.
Приведённые выше способы удаления подразумевают хранение оставшейся информации, которая нас интересует непосредственно в самом журнале аудита. Это может привести к тому, что, по мере роста журнала аудита, эту информацию также придётся удалять. Чтобы этого не делать, можно организовать архивирование нужных нам записей аудита. Для этого можно создать архивные таблицы по структуре соответствующие представлениям журнала аудита в схеме отличной от SYS. Попробуем продемонстрировать это на примере. Создадим архивную таблицу ARCH_AUDIT_SESSION в схеме SYSTEM. По структуре она будет соответствовать представлению DBA_AUDIT_SESSION, но располагаться в другом табличном пространстве.
SQL> CREATE TABLE system.arch_audit_session TABLESPACE users AS SELECT * FROM dba_audit_session WHERE ROWNUM < 1; Table created.
Теперь перенесём нужные нам записи из представления DBA_AUDIT_SESSION:
SQL> INSERT INTO SYSTEM.arch_audit_session
2 SELECT *
3 FROM dba_audit_session
4 WHERE ( (username IN ('SYS', 'SYSTEM') AND terminal 'W001')
5 OR (username = 'AH' AND terminal 'W002')
6 OR (username = 'BE' AND terminal NOT IN ('W003', 'W004'))
7 )
8 AND returncode = 0;
6 rows created.
После того как все архивные таблицы созданы и необходимые нам записи аудита будут в них перенесены, можно спокойно очистить журнал аудита одной командой DELETE. Правда само удаление записей не решит проблему роста журнала. Для её устранения необходим сброс маркера максимального уровня заполнения таблицы SYS.AUD$. И сделать это можно с помощью нескольких способов. Первый состоит в том, чтобы очистить таблицу SYS.AUD$ с помощью команды TRUNCATE TABLE. Это приведёт к сбросу маркера. Если в таблице должны оставаться какие-либо записи, то необходимо вначале создать копию таблицы с помощью оператора CREATE TABLE AS SELECT. Затем выполнить команду TRUNCATE TABLE и вставить записи из копии таблицы обратно. Если при создании копии таблицы возникают проблемы, например не хватает места в табличном пространстве, то можно выгрузить данные в файл экспорта. Затем провести импорт данных обратно в таблицу. В качестве недостатка этого способа следует отметить, что неиспользуемые блоки, возникшие в результате удаления записей из журнала аудита, не освобождаются. И хотя таблица SYS.AUD$ не будет больше расти по объёму до определённого уровня, она будет иметь такой же размер, как и до её очистки. Чтобы избежать этого, можно использовать ещё один способ сброса маркера. Он представляет собой перемещение таблицы SYS.AUD$ в другое табличное пространство с помощью команды ALTER TABLE MOVE TABLESPACE и последующий возврат таблицы в табличное пространство SYSTEM:
SQL> ALTER TABLE sys.aud$ MOVE TABLESPACE users; Table altered. SQL> ALTER TABLE sys.aud$ MOVE TABLESPACE system; Table altered. SQL> ALTER INDEX sys.i_aud1 REBUILD; Index altered.
При этом происходит не только сброс маркера максимального уровня, но и освобождение неиспользуемых блоков сегмента, то есть усечение таблицы. Единственно, что надо не забыть в этом случае, это перекомпилировать объекты, зависимые от таблицы SYS.AUD$, так как данная команда переводит их в статус инвалидных.
Используем расширенный режим
Проводя анализ аудита мы видели, что в журнале сохраняется довольно много информации, достаточной для того чтобы идентифицировать то действие которое выполнил пользователь. Но если мы захотим более подробно разобраться в том какая, же команда была выполнена, то здесь нас ждёт неудача. Поясним это на примере:
SQL> SELECT username, timestamp, action_name FROM dba_audit_statement WHERE action_name = 'ALTER SYSTEM'; USERNAME TIMESTAMP ACTION_NAME -------- ------------------- -------------- SYSTEM 18.01.2009 20:31:54 ALTER SYSTEM
Рассматривая результат запроса, мы видим, что администратор выполнил какое-то изменение экземпляра базы данных с помощью команды ALTER SYSTEM. Но нам не видно, какие конкретно изменения он сделал. Это могло быть и изменение инициализационного параметра, и уничтожение сеанса пользователя. Если бы мы знали, какую команду выполнил пользователь в данный момент времени, мы могли бы точнее определить само действие и опасность его для системы. К счастью в Oracle начиная с девятой версии, предусмотрен расширенный режим аудита. В данном режиме в качестве дополнения в журнал аудита записываются исполняемые SQL команды, или значения переменных привязки, если таковые имеются. Включается данный режим изменением параметра инициализации AUDIT_TRAIL. Для этого надо присвоить ему значение DB,EXTENDED. Попробуем включить данный режим:
SQL> ALTER SYSTEM SET audit_trail= db,extended SCOPE=SPFILE; System altered.
Перезагрузим экземпляр и проверим правильность установки значения параметра:
SQL> SHOW PARAMETERS audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB, EXTENDED
Расширенный режим установился. Заполним журнала аудита новой информацией. И если теперь мы повторим запрос к представлению журнала, то увидим, что в столбце SQL_TEXT появился текст выполненной команды:
SQL> SELECT username, timestamp, action_name, sql_text FROM dba_audit_statement WHERE action_name = 'ALTER SYSTEM'; USERNAME TIMESTAMP ACTION_NAME SQL_TEXT -------- ------------------- -------------- --------------------------------- SYSTEM 09.01.2009 22:23:29 ALTER SYSTEM ALTER SYSTEM FLUSH SHARED_POOL
В результате становиться понятно, какие действия совершил пользователь SYSTEM с экземпляром базы данных. Правда иногда, когда в SQL операторе используются связанные переменные, текст команды не даёт полной информации о совершаемом действии. В этом случае нам надо знать значения этих переменных. К примеру, в результате выполнения следующего запроса мы видим две записи с совершенно одинаковыми DML командами. Единственное что их отличает это значения связанных переменных, отображённых в столбце SQL_BIND.
SQL> SELECT username, timestamp, action_name, ses_actions, sql_bind, sql_text
2 FROM dba_audit_object
3 WHERE owner = 'HR' AND obj_name = 'EMPLOYEES';
USERNAME TIMESTAMP ACTION_NAME SES_ACTIONS SQL_BIND SQL_TEXT
-------- ------------------- -------------- ---------------- ---------- ---------------------------------
AH 09.01.2009 23:10:47 SESSION REC ----------F----- #1(3):102 UPDATE hr.employees SET email = '
ALHUNOLD' WHERE employee_id = :id
AH 09.01.2009 23:10:47 SESSION REC ----------S----- #1(3):103 UPDATE hr.employees SET email = '
ALHUNOLD' WHERE employee_id = :id
В заключение хочется сказать, что расширенный режим аудита является очень затратным в плане ресурсов. Поэтому включать его без острой необходимости не рекомендуется.
Применяем другие виды журналов
Журнал аудита, который мы рассматривали выше, представляет собой таблицу AUD$ в схеме пользователя SYS. Но это не единственно место для хранения записей аудита. Кроме таблицы, аудит можно помещаться в системный журнал операционной системы или в XML файлы. Для включения данных режимов требуется изменить значение параметра инициализации AUDIT_TRAIL. Попробуем включить один из таких режимов. Для этого выполним следующую команду:
SQL> ALTER SYSTEM SET audit_trail= os SCOPE=SPFILE; System altered.
Перезагрузим экземпляр и вновь сгенерируем аудит. Если после этого мы сделаем запрос таблице SYS.AUD$, то увидим, что она пуста:
SQL> SELECT * FROM sys.aud$; no rows selected
Но зато в системном журнале операционной системы появились записи. В нашем случае это будет выглядеть примерно так:
Тип события: Уведомление Источник события: Oracle.xe Категория события: Отсутствует Код события: 34 Дата: 10.01.2009 Время: 9:32:12 Пользователь: Н/Д Компьютер: W001 Описание: Не найдено описание для события с кодом ( 34 ) в источнике ( Oracle.xe ). Возможно, на локальном компьютере нет нужных данных в реестре или файлов DLL сообщений для отображения сообщений удаленного компьютера. Попробуйте использовать ключ /AUXSOURCE= для получения этого описания, - дополнительные сведения об этом содержатся в справке. В записи события содержится следующая информация: SESSIONID: "585" ENTRYID: "11" STATEMENT: "53" USERID: "SYSTEM" USERHOST: "DBA\W001" TERMINAL: "W001" ACTION: "51" RETURNCODE: "0" OBJ$NAME: "AH" OS$USERID: "W001\Сергей" PRIV$USED: 20.
Информацию протоколирования можно записывать не только в системный журнал, но и в отдельные XML файлы. Их расположение определяется значением параметра AUDIT_FILE_DEST и по умолчанию может указывать на директории ORACLE_BASE/admin/DB_UNIQUE_NAME /adump или ORACLE_HOME/rdbms/audit. Попробуем включить данный режим, выполнив следующую команду:
SQL> ALTER SYSTEM SET audit_trail= xml SCOPE=SPFILE; System altered.
Перезагрузим экземпляр и проверим значения параметров инициализации:
SQL> SHOW PARAMETERS audit;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string C:\ORACLEXE\APP\ORACLE\ADMIN\X
E\ADUMP
audit_sys_operations boolean TRUE
audit_trail string XML
Далее проведём генерацию аудита. После чего мы обнаружим в директории C:\ORACLEXE\APP\ORACLE\ADMIN\XE\ADUMP несколько файлов. Это и будут файлы журнала аудита. В каждом отдельном файле с помощью XML формата будут отражены действия, выполняемые пользователем в течение одного сеанса. Имя файла при этом формируется из префикса ora_ и идентификатора серверного процесса. Приведем для примера содержимое одного такого файла:
<?xml version="1.0" encoding="UTF-8"?> <Audit xmlns="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail- 10_2.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrai l-10_2.xsd"> <Version>10.2</Version> <AuditRecord><Audit_Type>1</Audit_Type><Session_Id>635</Session_Id><StatementI d>1</StatementId><EntryId>1</EntryId><Extended_Timestamp>2009-01- 10T10:20:07.765000</Extended_Timestamp><DB_User>AH</DB_User><OS_User>W002\Серг ей</OS_User><Userhost>DBA\W002</Userhost><OS_Process>308:1400</OS_Process><Ter minal>W002</Terminal><Instance_Number>0</Instance_Number><Action>100</Action>< Returncode>1017</Returncode> <Comment_Text>Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1067))</Comment_Text> </AuditRecord> </Audit>
Здесь мы могли бы столкнуться с большими трудностями при анализе аудита, так как довольно сложно обрабатывать такие файлы. Но Oracle облегчает задачу, предоставив нам системное представление V$XML_AUDIT_TRAIL. Сделав запрос к нему, мы получим данные аудита в уже привычной для нас табличной форме, где большинство столбцов соответствуют столбцам уже рассмотренного нами представления DBA_AUDIT_TRAIL.
Хочется отметить одну важную особенность, характерную для обоих режимов аудита. Так как Oracle не может прочитать такие журналы для поиска информации об уже выполнявшейся аналогичной команде в течение сеанса, то запись аудита будет генерироваться при каждом исполнении SQL оператора. Поэтому настройка опций с фокусировкой на сеанс, для данных режимов работы аудита не будет иметь смысла.
Аудит можно включить установив параметр audit_trail в значение db. При этом потребуется перезагрузка экземпляра.
Пример:
SQL> ALTER SYSTEM SET audit_trail=db SCOPE=SPFILE;
ИЗ ЛЕКЦИИ ПО АДМИНИСТРИРОВАНИЮ
Словарь данных каждой базы данных содержит таблицу с именем SUS.AUD$, обычно называемую АУДИТОРСКИМ ЖУРНАЛОМ базы данных. Аудиторские записи, генерируемые как результат отслеживания предложений, привилегий или объектов, можно помещать как в аудиторскую таблицу базы данных, так и в аудиторский журнал операционной системы. Использование аудиторского журнала дает возможность просматривать выбранные порции аудиторского журнала с помощью предопределенных представлений словаря данных, а также использовать инструменты ORACLE, такие как SQL*ReportWriter, для генерации аудиторских отчетов.
Использование аудиторского журнала операционной системы помогает консолидировать аудиторские записи из многих источников, включая ORACLE и другие приложения. Поэтому исследование активности системы может быть более эффективным, так как аудиторские записи сосредоточены в одном месте.
Аудиторский журнал базы данных (SYS.AUD$) - это единственная таблица в словаре данных каждой базы данных ORACLE. Если вы решили использовать аудит, создайте аудиторские представления, подключившись как SYS и запустив скрипт CATAUDIT.SQL. Если вы решили отключить аудит и больше не нуждаетесь в аудиторских представлениях, удалите их, подключившись как SYS и запустив скрипт CATNOAUD.SQL. Точное имя и местоположение этого скрипта зависит от операционной системы.
Установка опций аудита
все опции аудита генерируют следующую общую информацию:
- имя пользователя, выполнявшего отслеживаемое предложение;
- код действия, указывающий выполненное предложение;
- объекты, адресуемые в отслеживаемом предложении;
- дату и время выполнения отслеживаемого предложения;
Аудиторский журнал не сохраняет информации о каких-либо значениях данных, которые могли быть вовлечены в отслеживаемое предложение; например, при аудите предложения UPDATE не сохраняются старые и новые значения данных. Однако, такой специализированный тип аудита можно осуществить для предложений DML, работающих с таблицами, с помощью триггеров базы данных.
ORACLE позволяет устанавливать опции аудита на трех уровнях:
- предложение аудита базируется на типе предложений SQL, например, на любых предложениях SQL по таблицам (что регистрирует каждое предложение CREATE, TRUNCATE и DROP TABLE)
- привилегия отслеживает использование конкретной системной привилегии, такой как CREATE TABLE
- объект отслеживает конкретные типы предложений на конкретных объектах, например, ALTER TABLE по таблице EMP
Для удобства спецификации часто встречающихся групп связанных опций аудита предоставляются специальные обозначения. Эти обозначения сами не являются опциями; они просто позволяют указать одним словом целую группу опций в предложении AUDIT или NOAUDIT.
Включение и выключение аудита базы данных
Любой пользователь базы данных ORACLE может в любой момент установить опции аудита предложений, привилегий или объектов, но ORACLE не генерирует аудиторских записей и не помещает их в аудиторский журнал, если не включен режим аудита базы данных. Обычно за эту операцию отвечает администратор. Аудит базы данных включается и выключается параметром инициализации AUDIT_TRAIL в файле параметров базы данных. Этот параметр может быть установлен в следующие значения:
- DB - включает аудит базы данных и направляет все аудиторские записи в аудиторский журнал базы данных
- OS - включает аудит базы данных и направляет все аудиторские записи в аудиторский журнал операционной системы
- NONE - выключает аудит (умолчание)
Администратор защиты обязан контролировать рост аудиторского журнала и его размер. Когда аудит включен и генерируются аудиторские записи, аудиторский журнал растет за счет двух факторов:
- числа включенных опций аудита
- частоты выполнения отслеживаемых предложений
Для контроля за ростом аудиторского журнала вы можете использовать следующие методы:
- Включать и выключать аудит базы данных. Когда аудит включен, аудиторские записи генерируются и поступают в журнал; когда аудит выключен, аудиторские записи не генерируются.
- Жестко контролировать возможности осуществлять аудит объектов. Это можно делать двумя различными способами:
- Всеми объектами владеет администратор защиты, привилегия AUDIT ANY никогда не назначается никаким другим пользователям. Все объекты схемы могут принадлежать схеме, соответствующий пользователь которой не имеет привилегии CREATE SESSION.
- Все объекты содержатся в схемах, которые не соответствуют реальным пользователям базы данных (т.е. привилегия CREATE SESSION не назначена пользователям, одноименным со схемами), и администратор защиты является единственным лицом, имеющим системную привилегию AUDIT ANY.
- Все объекты содержатся в схемах, которые не соответствуют реальным пользователям базы данных (т.е. привилегия CREATE SESSION не назначена пользователям, одноименным со схемами), и администратор защиты является единственным лицом, имеющим системную привилегию AUDIT ANY.
После того, как аудит был включен в течение некоторого времени, администратор защиты может удалить записи из аудиторского журнала, - как для того, чтобы освободить память, так и для облегчения управления этим журналом. Например, чтобы удалить ВСЕ записи из аудиторского журнала, введите следующее предложение:
DELETE FROM sys.aud$;
Если информация аудиторского журнала должна архивироваться для целей накопления истории, администратор защиты может скопировать соответствующие записи в нормальную таблицу базы данных или экспортировать аудиторскую таблицу в файл операционной системы. Удалять записи из аудиторского журнала базы данных может лишь пользователь SYS, т.е. пользователь, имеющий привилегию DELETE ANY TABLE (или пользователь, которому SYS передал привилегию DELETE по таблице SYS.AUD$).
Уменьшение размера аудиторского журнала
Как и в любой таблице базы данных, после удаления записей из аудиторского журнала базы данных все экстенты, которые были распределены этой таблице, будут по-прежнему существовать. Если аудиторский журнал имеет слишком много экстентов, большинство из которых не используются, то можно уменьшить размер этого журнала, выполнив следующие шаги:
- Если вы хотите сохранить информацию из аудиторского журнала, скопируйте ее в другую таблицу базы данных, или экспортируйте ее с помощью утилиты экспорта.
- Соединитесь с базой данных как INTERNAL.
- Выполните усечение таблицы SYS.AUD$ с помощью команды TRUNCATE.
- Перезагрузите аудиторские записи, сохраненные вами на шаге 1.
Осуществляя отслеживание подозрительной деятельности в базе данных, защищайте целостность записей аудиторского журнала, чтобы гарантировать точность и полноту аудиторской информации. Чтобы защитить аудиторский журнал от несанкционированных удалений, назначайте системную привилегию DELETE ANY TABLE только администраторам защиты. Чтобы отслеживать изменения, выполняемые над самим аудиторским журналом, организуйте аудит аудиторского журнала с помощью следующего предложения:
AUDIT INSERT, UPDATE, DELETE
ON sys.aud$
BY ACCESS;
Аудит с помощью триггеров базы данных
Вы можете использовать триггеры, чтобы дополнить встроенные средства аудита ORACLE. Хотя вы можете писать триггеры, которые регистрировали бы информацию, аналогичную той, которую генерирует команда AUDIT, старайтесь использовать триггеры лишь в том случае, когда вам необходима более детальная аудиторская информация. Например, с помощью триггеров вы можете отслеживать изменения значений по строкам таблицы.
Аудит FGA и обычный аудит: различия
Если стандартный и детальный аудит похожи в сервере Oracle Database 10g, вы вполне вправе спросить, в каких случаях выбор будет явно в пользу средств FGA? Рассмотрим различия:
- стандартный аудит должен быть включен на уровне базы данных установкой параметра AUDIT_TRAIL (журнал аудита). Этот параметр не является динамическим: вы должны перезапустить экземпляр Oracle, чтобы он вступил в силу. Напротив, FGA не требует никаких изменений параметров;
- включенная опция стандартного аудита для объекта остается такой постоянно. Чтобы дезактивировать ее, вы должны удалить эту опцию аудита, используя оператор NOAUDIT. Это может быть неудобно, потому что удаление опции аудита для таблицы приводит также к удалению информации о метаданных. Средства FGA, однако, могут быть временно отключены и вновь включены без какой-либо потери информации о метаданных;
- средства FGA могут обрабатывать только четыре типа операторов: SELECT, INSERT, UPDATE и DELETE. Регулярный аудит, напротив, может обрабатывать много других операторов и привилегий, даже соединения и отсоединения сеансов от базы данных;
- средства стандартного аудита создают только одну запись для сеанса (режим by session) или одну запись при каждом доступе к объекту (режим by access). Это умеренное потребление пространства важно для управления пространством в таблицах журнала аудита. Средства FGA более расточительны: они срабатывают при каждом доступе, что приводит к большему росту журнала аудита;
- стандартный аудит может использоваться для обнаружения любых попыток взлома; при записи в журнал аудита, если попытка была неудачной, записывается код ошибки. Средства FGA не умеют этого делать;
- средства стандартного аудита могут записывать журнал аудита в таблицы базы данных или в файлы операционной системы. Последний режим полезен, когда доступ к журналу имеет только аудитор, а не администратор базы данных. В ОС Windows записи аудита могут вноситься в файл регистрации событий системы Event Log. Эта опция позволяет защищать целостность записей аудита. Журнал аудита FGA пишется только в таблицу базы данных FGA_LOG$. В FGA вы можете создать определяемые пользователями обработчики событий аудита, чтобы писать в файлы ОС, но их целостность не гарантируется;
- средства стандартного аудита могут быть настроены для аудита объектов, создаваемых по умолчанию. Эта возможность становится чрезвычайно полезной в тех случаях, когда таблицы создаются во время исполнения. Опция аудита объектов, создаваемых по умолчанию, позволяет включать аудит без вмешательства администратора базы данных. Это невозможно в FGA; правила аудита нужно создавать для существующей таблицы, а это можно сделать только после фактического создания таблицы;
- в FGA средства аудита становятся намного более гибкими – только тогда, когда выполняется доступ к определенным столбцам, когда выполняется определенное условие и т.д. Эта многосторонность удобна, если необходимо управлять ростом журнала аудита;
- переменные связывания в SQL-операторах в FGA записываются в журнал аудита по умолчанию. Для обычного аудита в параметре инициализации audit_trail для этого должно быть установлено значение db_extended;
- требуемые привилегии различны: для выполнения обычного аудита требуется соответствующая системная привилегия или привилегия выполнения оператора аудита; для FGA требуется только привилегия выполнения пакета dbms_fga.
Данное сравнение позволяет понять, почему средства FGA в определенных случаях могут оказаться полезными. Расширенные средства обычного аудита в сервере Oracle Database 10g обеспечивают решение некоторых задач, которое раньше было невозможно, например, регистрацию значений переменных связывания.
Комментариев нет:
Отправить комментарий