Аудит – это наблюдение за выбранными действиями пользователей базы данных. Его обычное применение это контроль подозрительных операций и сбор информации об отдельных действиях в базе данных. В этой главе мы научимся включать, настраивать, просматривать и анализировать аудит, а также рассмотрим его расширения. Включаем аудит
Для включения аудита нам достаточно изменить значение инициализационного параметра AUDIT_TRAIL. Для начала подключимся к экземпляру базы данных и выведем его значение:
SQL*Plus: Release 10.2.0.1.0 - Production on Mon Nov 24 21:39:30 2008
Copyright © 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 служит для вывода записей аудита, создаваемых по командам AUDIT NOT EXISTS и AUDIT EXISTS. Представление DBA_AUDIT_OBJECT показывает аудит всех объектов в базе данных. В DBA_AUDIT_SESSION содержатся записи касающиеся команд CONNECT и DISCONNECT. И наконец, последнее представление DBA_AUDIT_STATEMENT отображает записи аудита команд GRANT, REVOKE, AUDIT, NOAUDIT, ALTER SYSTEM. Делая запрос к этим представлениям, мы можем получить доступ ко всей протоколируемой информации собираемой с помощью аудита. Что даёт нам шанс провести её полный анализ.
Продолжение: Практическое администрирование Oracle - Аудит. Часть 2.
Цех по ремонту кузовов. ремонт кузова автомобиля профессионально
|