DBA.UCOZ.RU

Аудит – это наблюдение за выбранными действиями пользователей базы данных. Его обычное применение это контроль подозрительных операций и сбор информации об отдельных действиях в базе данных. В этой главе мы научимся включать, настраивать, просматривать и анализировать аудит, а также рассмотрим его расширения.

Для включения аудита нам достаточно изменить значение инициализационного параметра AUDIT_TRAIL. Для начала подключимся к экземпляру базы данных и выведем его значение:

Видно, что по умолчанию аудит действий для этой группы пользователей выключен. Включим его:

Проверим, правильность установки значения инициализационных параметров:

Значения правильные. Аудит включён, и можно переходить к его настройке.

Настройка аудита представляет собой включение или выключение опций протоколирования выполняемых операций. Установка опций требует наличие привилегий AUDIT SYSTEM и AUDIT ANY, и  может происходить на трёх уровнях аудита: команд, привилегий и объектов схемы. Рассмотрим настройку каждого уровня по отдельности. Первое,  что мы сделаем, это применим аудит для команды ALTER SYSTEM, которая может динамически изменить текущий экземпляр базы данных. Включение опции производится следующим оператором:

В результате, мы имеем первую установленную опцию и можем уже отслеживать действия по изменению текущего экземпляра базы данных. Правда следует сразу отметить, что включение опции не означает немедленное протоколирование команды для пользователей, которые в текущий момент времени уже подключены к базе данных. Аудит для них будет действовать, только начиная со следующего сеанса.
После того как мы произвели включение данной опции, мы должны проверить правильность её установки. Для этого нам надо сделать запрос к следующему представлению:

Из результатов запроса видно, что сейчас у нас в системе одна установленная опция ALTER SYSTEM, настроенная на протоколирование действий одноимённой команды. На самом деле большинство опций аудита команд включают в себя группы связанных операторов. Включим, к примеру, следующую опцию:

В результате мы добавили аудит сразу на три команды: 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, которая в определённом смысле является уникальной, так как не ассоциируется ни с одной командой. Смысл этой опции в формировании записи аудита при подключении сеанса и обновлении записи при его отключении.  Включение всех вышеперечисленные опций можно оформить в виде одного оператора, что мы сейчас и сделаем:  

После того как нами была произведена установка аудита операторов относящихся в основном к системе, мы можем перейти к включению опций команд, связанных непосредственно с объектами, как типом. В первую очередь мы должны настроить протоколирование 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 применяемые к хранимым объектам. Активация данной опции зависит от нескольких условий и специфична для конкретной системы. Если, к примеру, происходит частая модификация хранимых объектов, которую осуществляет только администратор по просьбе разработчиков приложения, то данную опцию можно выключить, чтобы ограничить число записей в аудите. Если же лиц, которые могут модифицировать данный тип объектов несколько, то данную опцию лучше активировать.  Мы же этого делать не будем, и поэтому произведем включение только первых трёх опций:

Последние опции, которые мы включим, относятся к протоколированию команд GRANT REVOKE, предоставляющих или отбирающих объектные  привилегии. В качестве объектов здесь выступают хранимые объекты и таблицы. Для  обнаружения несанкционированной выдачи на них привилегий, мы и включим две опции GRANT PROCEDURE и GRANT TABLE:

Теперь проверим результат нашей работы:

Минимальный набор опций включен, и мы можем уже иметь хоть какое-то представление о действиях пользователей в базе данных. Но если  количество этих действий достаточно велико это  может привести к неоправданному росту журнала аудита и впоследствии к трудностям его анализа. Для того чтобы избежать этой ситуации, в аудите можно использовать фокусировку. Предназначение фокусировки вытекает из самого названия. Она необходима для сужения области действия аудита, с целью уменьшить количество генерируемых контрольных записей. По умолчанию, фокусировка для опций не осуществляется. Поэтому мы рассмотрим, её применение на конкретном примере  установленной  нами опции ROLE. Эта опция включает протоколирование четырёх команд: CREATE ROLE, ALTER ROLE, DROP ROLE, SET ROLE. Если приложения базы данных построены по принципу включения ролей, то при большом количестве работающих пользователей будет генерироваться значительное количество записей аудита из-за выполнения команды SET ROLE. Попробуем избежать это ситуации,  установив эту опцию только для неудачного  выполнения команд. Для начала посмотрим режим фокусировки для всех настроенных нами опций аудита команд, выполнив следующий запрос:

Значение BY ACCESS в столбце SUCCESS(FAILURE) говорит о том, что записи аудита для данной опции будут образовываться при каждом удачном (неудачном) выполнении команды. Этот режим для DDL команд устанавливается по умолчанию и фокусировка здесь отсутствует. Отменим регистрацию удачного выполнения команды для опции ROLE:

В столбце SUCCESS напротив опции ROLE появилось значение NOT SET. Теперь при удачном выполнении команд связанных с действиями над ролями аудит генерироваться не будет. Количество записей, конечно, уменьшится, но  мы  не сможем больше отслеживать создание, изменение и удаление ролей. Впрочем, как обойти этот недостаток, мы рассмотрим в настройке следующего типа аудита - аудита привилегий.
В настройке аудита привилегий в качестве опций используются непосредственно системные привилегии, и генерация аудита осуществляется в том случае, если эти привилегии применяются при выполнении SQL оператора. Настройка этого типа аудита осуществляется тогда, когда требуется настроить протоколирование не связанного списка команд, а конкретных операторов. Рассмотрим это на примере всё той же опции ROLE. С целью уменьшения количества генерируемых записей  для неё была применена фокусировка, и теперь удачные выполнения DDL команд над ролями не попадают в аудит. Чтобы исправить эту ситуацию мы будем отслеживать удачное применение привилегий  CREATE ROLE, ALTER ANY ROLE, DROP ANY ROLE. Для этого выполним следующий оператор:

Теперь выберем список опций привилегий, к которым применён аудит:

В результате, все удачно выполненные команды, которые требуют привилегий, CREATE ROLE, ALTER ANY ROLE и DROP ANY ROLE теперь будут попадать в аудит. Так, используя совместную фокусировку аудита команд и привилегий, нам удалось сократить количество генерируемых записей за счет исключения протоколирования успешного выполнения команды SET ROLE. Но фокусировка этих двух типов аудита не ограничивается только результатом выполнения команд, её также можно применять  и для конкретных пользователей. Рассмотрим это на основе демонстрационной схемы HR. Для этого создадим  предварительно нужные нам роли и учётные записи пользователей. Сделав запрос к справочнику EMPLOYEES, мы увидим, что в фирме имеются пять служащих IT отдела:

Допустим, что двое из них Alexander Hunold и Bruce Ernst осуществляют сопровождение объектов схемы HR. Так как у этих пользователей довольно широкие привилегии в этой схеме, нам потребуется отслеживать все DML команды, которые они могут выполнить. Поэтому включим для них следующие опции:

Проверим список опций команд для пользователей:

Теперь мы будем знать, осуществлялся ли доступ к таблицам и представлениям схемы HR со стороны пользователей AH и BE. Это позволит сократить количество записей по сравнению со случаем, когда нам пришлось бы включать  протоколирование этих действий для всех пользователей, а затем выискивать в журнале аудита записи нужного нам пользователя.
Здесь я хочу обратить внимание на содержание столбцов SUCCESS и FAILURE в списке опций, как ещё одного из видов фокусировки. До этого мы встречали в них только значение BY ACCESS, что означало, что запись аудита будет создаваться при каждом выполнении SQL оператора включенной опции. Данный режим является единственным для опций, содержащих набор DDL команд. Но для аудита DML операторов существует и ещё один режим - BY SESSION. При данном виде фокусировки запись аудита будет образовываться только один раз за  весь сеанс и только при первом выполнении команды. Данный режим используется для фиксации самого факта доступа к данным и для опций DML команд устанавливается по умолчанию,
Рассматривая последний пример, мы увидели, как можно настроить аудит доступа пользователя к  данным таблиц и представлений. Но используемый нами вариант  не лишен недостатков. В аудит попутно попадут  все обращения пользователя к доступным ему  представлениям и таблицам. Такой аудит удобно включать только кратковременно, для поиска подозрительной активности в базе данных. Если же нам потребуется постоянно отслеживать доступ к одному или нескольким объектам, то такой метод становиться очень затратным. Для того чтобы исключить такую ситуацию можно применить ещё один тип аудита – аудит объектов схемы. Его отличие от аудита команд и привилегий состоит в том, что протоколирование применяется только к  конкретному объекту, а опции ассоциируются с одиночными командами. Рассмотрим это на основе последнего примера. Для того чтобы сократить количество записей аудита генерируемых текущей настройкой, попробуем отследить доступ к данным только критически важных таблиц HR.EMPLOYEES и HR.JOBS. Вначале отключим лишние опции аудита DML команд для пользователей AH и BE:

Теперь активируем опции аудита объектов схемы для таблиц hr.employees и hr.jobs:

В заключение посмотрим результат нашей работы:

Столбцы DEL, INS, UPD, SEL обозначают сокращенные названия опций аудита объектов схемы, а значение S/S является фокусировкой и расшифровывается следующим образом. Буква S перед знаком / и после означает, что протоколирование настроено на удачное или неудачное выполнение команды. Запись при этом будет образовываться только один раз за сеанс при первом выполнении команды (режим SESSION). В результате, мы можем отслеживать доступ только к этим двум таблицам, что позволит сократить количество протоколируемой информации. Правда, данный вид аудита имеет один недостаток. К нему не может применяться  фокусировка по конкретному пользователю. Вследствие чего, в данном примере нам придётся отфильтровывать аудитные записи сделанные командами пользователей AH и BE непосредственно при просмотре аудита.

Включая  аудит, мы указали значение инициализационного параметра AUDIT_TRAIL равное DB. Это означает, что в качестве хранилища записей (журнала аудита) у нас выступает таблица AUD$ в схеме SYS. Поэтому, для просмотра аудита мы можем обратиться непосредственно к этой таблице напрямую. Но гораздо удобнее это делать через системные представления журнала аудита. Ознакомимся с ними более подробно. Первое представление, которое мы рассмотрим, называется DBA_AUDIT_TRAIL. Оно единственное напрямую обращается к таблице AUD$ и  содержит список всех её записей. Выведем описание этого представления:

Предназначение столбцов 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 служит для вывода записей аудита, создаваемых по командам AUDIT NOT EXISTS и AUDIT EXISTS. Представление DBA_AUDIT_OBJECT показывает аудит всех объектов в базе данных. В DBA_AUDIT_SESSION содержатся записи касающиеся команд CONNECT и DISCONNECT. И наконец, последнее представление DBA_AUDIT_STATEMENT отображает записи аудита команд GRANT, REVOKE, AUDIT, NOAUDIT, ALTER SYSTEM. Делая запрос к этим представлениям, мы можем получить доступ ко всей протоколируемой информации собираемой с помощью аудита. Что даёт нам шанс провести её полный анализ.