АУДИТ БАЗ ДАННЫХ ORACLE

Аудит – набор действий, автоматически протоколирующие воздействия пользователей на экземпляр БД.

Необходимо объяснить, что такое экземпляр. При установке БД Oracle связывается с экземпляром, каждой БД в соответствие он ставится один. Экземпляр состоит из структур оперативной памяти и комплекса поддерживающих БД фоновых процессов, взаимодействующих между собой.

Итак, действия, выполняемые аудитом, позволяют контролировать операции, производимые внутри экземпляра БД пользователем, проверять соответствие прав и действий, своевременное выявлять уязвимости и, следовательно, устранять возможности атак на экземпляр БД. Поэтому аудит и считают одним из средств обеспечения информационной безопасности баз данных.

Следует заметить, что проведение качественного аудита всегда нуждается в существенных кадровых и финансовых затратах, но при этом многие компании не отказываются от него.

В настоящее время наблюдается увеличение потребности проведения профессионального независимого аудита.  Можно выделить две основные причины складывающейся ситуации: 1) возрастающая роль информационных технологий в современных методах ведения бизнеса и, как следствие, более высокие требования к защищенности ИС; 2) увеличение сложности информационных систем и их подсистем обеспечения безопасности; возрастающие требования к организации деятельности и квалификации персонала, ответственного за обеспечение безопасности ИС [2, c. 281].

Прежде чем настраивать аудит необходимо определить, что именно необходимо отслеживать. Главный принцип организации аудита – простота и предусмотрительность, т.е. находиться в рабочем состоянии должны только самые необходимые опции.

Аудит в СУБД Oracle можно представить в виде перечня из четырёх эшелонов, каждый из которых расширяет возможности предыдущих в списке, но также увеличивает затраты на реализацию и поддержание в рабочем состоянии: 1) Аудит событий операционной системы; 2) Стандартный аудит событий СУБД (Standart Audit); 3) Системные триггеры (System triggers); 4) Детализированный аудит (Fine-grained audit). Теперь о каждом подробнее.

Аудит событий OC. Операционная система ведет собственный журнал событий. В журнале фиксируется: 1) Подключение к СУБД с привилегиями администратора SYSDBA или SYSOPER; 2) Включение СУБД; 3) Выключение СУБД.

Для примера рассмотрим ОС Windows. В данной ОС несколько журналов: 1) системный (события ОС); 2) безопасности (все попытки выполнения действий); 3) приложений (события приложений). Просмотреть журналы в Windows возможно с помощью утилиты Event Viewer. Начать работу с ней можно, если зайти в папку “%Systemroot%\System32\” и запустить “eventvwr.msc”. Аудит описанных выше событий заносится ОС в журнал приложений.

Стандартный аудит (аудит событий СУБД Oracle). Данный эшелон аудита разделяется на три подвида по критерию отслеживаемых событий. По умолчанию стандартный аудит отключен, его запуск зависит от версии СУБД ORACLE.

Для активация службы аудита необходимо выполнить команду “ALTER SYSTEM SET audit_trail = <Value1> scope = <Value2>”. Также необходимо перезапустить базу данных.

Value1 может принимать одно из следующих значений: 1) “db” или “true” – данные аудита записываются в словарь данных, а именно в таблицу AUD$, владелец которой пользователь SYS. Данная таблица находится в табличном пространстве SYSTEM, что представляет опасность для базы данных, т.к. если табличное пространство исчерпает запас памяти, то на лицо будет отказ в обслуживании (DDoS-атака). Поэтому в целях безопасности необходимо переместить данную таблицу в другое табличное пространство или контролировать заполнение текущего; 2) “os” – данные аудита записываются в журнал аудита ОС (для Windows). Но другие ОС, к примеру из семейства операционных систем Unix, записывают данные аудита в файл, путь к которому есть значение параметра “audit_file_dest”. По умолчанию параметр равен “ORACLE_BASE/admin/DB_UNIQUE_NAME/adump” или “ORACLE_HOME/rdbms/audit”; 3) “none” – аудит не разрешен (по умолчанию установлено данное значение); 4) “false” – аудит отключен.

Value2 может принимать одно из следующих значений: 1) “memory” –изменения вносятся только в экземпляр (для немедленного воздействия); 2) “spfile” – изменения вносятся только в SPFILE; 3) “both” – изменения вносятся и в экземпляр, и в SPFILE. Oracle хранит параметры экземпляра БД в двух файлах: Pfile – файл параметров (локальный) и Spfile – серверный файл параметров (добавлен в версии 9i), причем Pfile хранит информацию в текстовом формате, а Spfile – в двоичном виде. С точки зрения безопасности Spfile, использующийся по умолчанию, лучше, т.к. его невозможно изменить текстовым редактором. Spfile расположен в каталоге “ORACLE_HOME/dbs/spfile<SID_name>. оrа”.

С версии 9i стало возможно отслеживать действия привилегированных пользователей, к примеру, SYS или имеющих привилегии SYSDBA и SYSOPER. Контроль осуществляется командой: “ALTER SYSTEM SET audit_sys_operations=true”.

Первый вид стандартного аудита – аудит операций (Statement audit). Он представляет собой аудит запуска SQL-операции. Второй вид – аудит назначения привилегий (Privilege audit). Если говорить проще, то первый вид аудита представляет собой совокупность, группу системных привилегий, влияющие на определенный тип объекта БД и обозначаемые как один оператор. Второй вид аудита состоит из системных привилегий. Для этих видов аудита одинаковый формат команд активации и выглядит он следующим образом:

“AUDIT {statement_option | privilege_option} [, {statement_option | privilege_option}] [BY пользователь {[, пользователь] ...}] [BY {SESSION | ACCESS}] [WHENEVER [NOT] SUCCESSFUL]; ”

Прежде чем разбирать синтаксис команды следует сказать, что для добавления перечня фиксируемых событий данным оператором необходимо, что бы пользователю, осуществляющего данную операцию, была предоставлена привилегия “AUDIT SYSTEM” (аудит системных событий). Проверить у кого из пользователей в БД есть соответствующая привилегия возможно, если выполнить следующий запрос к БД: “SELECT * FROM dba_sys_privs WHERE privilege like '%AUDIT%';”. Итак, обязательной частью команды является указание “statement_option | privilege_option”, остальные части опционы.

Опция “BY пользователь” определяет, что будут фиксироваться действия указанного пользователя или группы пользователей. Если данная опция не указана, то аудит осуществляется по всем пользователям.

Опция “BY SESSION” определяет, что при выполнении аудита заносится единственная запись о фиксируемом действии независимо от того, сколько раз это действие произошло за сеанс работы с БД. Опция “BY ACCESS” определяет, что при выполнении аудита для каждого действия пользователя производится запись.

Опция “WHENEVER SUCCESSFUL” определяет, что при выполнении аудита запись производится, если операция выполнилась успешно; Опция “WHENEVER SUCCESSFUL” – если операция выполнилась неуспешно. Если данная опция не указана, то независимо от выполнения операции действие фиксируется.

Прекращение регистрации событий (всех или некоторых) осуществляется командой, которая идентична команде активации за исключение того, что вместо “AUDIT” необходимо указывать “NOAUDIT” и не нужна опция “BY {SESSION | ACCESS}”.

И наконец, третий вид стандартного аудита – аудит доступа к объектам (Object audit). Он записывает действия операторов DML, “EXECUTE”, “GRANT”, “AUDIT”, “ALTER”, “RENAME” при обращению к контролируемому объекту. Для осуществления данного вида аудита соответствующему пользователю должна быть предоставлена привилегия “AUDIT ANY”. Синтаксис команды данного вида аудита:

“AUDIT {object_option} [, {object_option}...] ON {[схема.]объект | DEFAULT} [BY { SESSION | ACCESS }] [WHENEVER [NOT] SUCCESSFUL];”

Обязательной частью команды является указание “object_option” и объекта аудита, остальные части опционы. Прекращение регистрации событий аналогично случаю двух других видов аудита.

Системные триггеры. Данный эшелон аудита Oracle введён в 8 версии Oracle. Он позволяет с помощью триггеров контролировать операции “INSERT”, “UPDATE” и “DELETE” при работе с таблицей, сохраняя значения таблиц до и после изменений, кроме того возможно контролировать системные события такие, как запуск и остановка БД, подключение к БД, различные манипуляции с объектами схемы. Но у этого метода есть и обратная сторона – оно весьма ресурсоёмко.

Суть работы эшелона проста: 1) создаётся таблицы, куда будут заноситься данные аудита; 2) создаётся триггер, срабатывающий на интересующее нас событие и записывающий в созданную таблицу новые значения.

Синтаксис команды создания триггера следующий:

“CREATE [OR REPLACE] TRIGGER {схема.имя_триггера} {BEFORE | AFTER | INSTEAD OF} активизирующее_событие ON ссылка_на_таблицу [FOR EACH ROW] [WHEN условие_срабатывания] тело_триггера;”

Если при создании триггера задействована опция “FOR EACH ROW”, то триггер называется строковым и активируется активируется один раз для каждой из строк, на которую воздействует; если же опция не задействована, то триггер – операторный, и он активируется 1 раз до или после оператора.

Детализированный аудит (FGA). FGA, добавленный в версии 9i, позволяет контролировать доступ на чтение, а также модификацию и удаление данных, основываясь на дополнительных условиях. Аудит оператора “SELECT” – ключевая особенность FGA. Т.к. данный оператор не инициализирует запуск триггера и информация о выполнении оператора не записывается в журнал, то предыдущие эшелоны аудита в данном случае бесполезны.

Данная возможность основана на внутренних триггерах, срабатывающих при разборе частей SQL-предложения, тем самым обеспечивая более низкоуровневый доступ. [1, c. 300].

Для работы пользователя с FGA необходимо предоставить ему права на выполнение пакета “DBMS_FGA”. Аудит событий в FGA осуществляется с помощью правил аудита (policy), которые возможно добавлять, удалять, включать и выключать.

Рисунок 1. Запись о подключении к СУБД Oracle в журнале событий ОС Windows

Рисунок 2. Включение ведения журнала аудита

Рисунок 3. Пример аудита операций (statement audit)

Рисунок 4. Пример аудита назначения привилегий (privilege audit)

Рисунок 5. Пример аудита доступа к объектам (object audit)

Рисунок 6. Пример аудита с использованием триггеров

Список литературы:

1. Поляков А.М. Безопасность Oracle глазами аудитора: нападение и защита. – М.: ДМК Пресс, 2010. – 336 с.
2. Смирнов С. Н. Безопасность систем баз данных. – М.: Гелиос АРВ, 2007. —352 с.