Oracle как очистить аудит

Обновлено: 04.07.2024

Базы данных: Oracle

Администрирование баз данных Oracle

16. Аудит базы данных

Словарь данных каждой базы данных содержит таблицу с именем 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.

    Очистка аудиторских записей из аудиторского журнала

    После того, как аудит был включен в течение некоторого времени, администратор защиты может удалить записи из аудиторского журнала, - как для того, чтобы освободить память, так и для облегчения управления этим журналом. Например, чтобы удалить ВСЕ записи из аудиторского журнала, введите следующее предложение:

    DELETE FROM sys.aud$;

    Если информация аудиторского журнала должна архивироваться для целей накопления истории, администратор защиты может скопировать соответствующие записи в нормальную таблицу базы данных или экспортировать аудиторскую таблицу в файл операционной системы. Удалять записи из аудиторского журнала базы данных может лишь пользователь SYS, т.е. пользователь, имеющий привилегию DELETE ANY TABLE (или пользователь, которому SYS передал привилегию DELETE по таблице SYS.AUD$).

    Уменьшение размера аудиторского журнала

    Как и в любой таблице базы данных, после удаления записей из аудиторского журнала базы данных все экстенты, которые были распределены этой таблице, будут по-прежнему существовать. Если аудиторский журнал имеет слишком много экстентов, большинство из которых не используются, то можно уменьшить размер этого журнала, выполнив следующие шаги:

    • Если вы хотите сохранить информацию из аудиторского журнала, скопируйте ее в другую таблицу базы данных, или экспортируйте ее с помощью утилиты экспорта.
    • Соединитесь с базой данных как INTERNAL.
    • Выполните усечение таблицы SYS.AUD$ с помощью команды TRUNCATE.
    • Перезагрузите аудиторские записи, сохраненные вами на шаге 1.

    Защита аудиторского журнала

    Осуществляя отслеживание подозрительной деятельности в базе данных, защищайте целостность записей аудиторского журнала, чтобы гарантировать точность и полноту аудиторской информации. Чтобы защитить аудиторский журнал от несанкционированных удалений, назначайте системную привилегию DELETE ANY TABLE только администраторам защиты. Чтобы отслеживать изменения, выполняемые над самим аудиторским журналом, организуйте аудит аудиторского журнала с помощью следующего предложения:

    AUDIT INSERT, UPDATE, DELETE

    Аудит с помощью триггеров базы данных

    Вы можете использовать триггеры, чтобы дополнить встроенные средства аудита ORACLE. Хотя вы можете писать триггеры, которые регистрировали бы информацию, аналогичную той, которую генерирует команда AUDIT, старайтесь использовать триггеры лишь в том случае, когда вам необходима более детальная аудиторская информация. Например, с помощью триггеров вы можете отслеживать изменения значений по строкам таблицы.

    Государственный комитет Российской федерации
    по высшему образованию.
    ГОСУДАРСТВЕННЫЙ САНКТ-ПЕТЕРБУРГСКИЙ
    ИНСТИТУТ ТОЧНОЙ МЕХАНИКИ И ОПТИКИ
    (ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)
    кафедра вычислительной техники

    Многие включают аудит и обращают внимание, что таблицы AUD$ и FGA_LOG$ начинают расти (они располагаются в табличном пространстве SYSAUX). Необходимо отслеживать их рост и ежедневно контролировать их размеры.

    SELECT SUM ( BYTES ) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'AUD$' ;
    SELECT table_name , tablespace_name
    FROM dba_tables
    WHERE table_name IN ( 'AUD$' , 'FGA_LOG$' )
    ORDER BY table_name ;
    Если вам необходимо переместить журнал, например, в другое табличное пространство, можете сделать это с помощью процедуры
    BEGIN
    DBMS_AUDIT_MGMT . SET_AUDIT_TRAIL_LOCATION (
    audit_trail_type => DBMS_AUDIT_MGMT . AUDIT_TRAIL_ALL ,
    audit_trail_location_value => '<tablespace_name>' ) ;
    END ;
    /

    Можно использовать следующие типы записей аудита
    AUDIT_TRAIL_AUD_STD
    AUDIT_TRAIL_FGA_STD
    AUDIT_TRAIL_OS
    AUDIT_TRAIL_XML
    Либо, для всех из них: AUDIT_TRAIL_ALL

    Прежде, чем что-либо менять, убедитесь, что автоочистка журнала не включена

    set pagesize 150
    set linesize 200
    column parameter_name format a30
    column parameter_value format a20
    SELECT * FROM DBA_AUDIT_MGMT_CONFIG_PARAMS ;
    в этом выводе не должно быть параметра DEFAULT CLEAN UP INTERVAL, если он есть, то лучше его сначала отключить.
    BEGIN
    DBMS_AUDIT_MGMT . DEINIT_CLEANUP (
    AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT . AUDIT_TRAIL_ALL );
    END ;
    BEGIN
    DBMS_AUDIT_MGMT . INIT_CLEANUP (
    AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT . AUDIT_TRAIL_ALL ,
    DEFAULT_CLEANUP_INTERVAL => 24 * 14
    );
    END ;
    /

    CREATE OR REPLACE PROCEDURE SP_PURGE_AUDIT_TRAIL
    AS
    BEGIN

    DBMS_AUDIT_MGMT . CLEAR_LAST_ARCHIVE_TIMESTAMP (
    AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT . AUDIT_TRAIL_ALL );

    SYS . DBMS_AUDIT_MGMT . CLEAN_AUDIT_TRAIL (
    AUDIT_TRAIL_TYPE => SYS . DBMS_AUDIT_MGMT . AUDIT_TRAIL_ALL ,
    USE_LAST_ARCH_TIMESTAMP => TRUE );
    END ;
    /

    CREATE OR REPLACE PROCEDURE SP_PURGE_AUDIT_TRAIL
    AS
    retention NUMBER ;
    BEGIN
    retention := 14 ;

    SYS . DBMS_AUDIT_MGMT . SET_LAST_ARCHIVE_TIMESTAMP (
    AUDIT_TRAIL_TYPE => SYS . DBMS_AUDIT_MGMT . AUDIT_TRAIL_ALL ,
    LAST_ARCHIVE_TIME => SYSTIMESTAMP - retention
    );

    SYS . DBMS_AUDIT_MGMT . CLEAN_AUDIT_TRAIL (
    AUDIT_TRAIL_TYPE => SYS . DBMS_AUDIT_MGMT . AUDIT_TRAIL_ALL ,
    USE_LAST_ARCH_TIMESTAMP => TRUE );
    END ;
    /

    И так, мы настроили аудит. Информация о действиях пользователей в базе данных начала собираться. Мы знаем, где ёё можно посмотреть. Но всё это будет напрасно, если мы не сможем разобраться в этом большом количестве разнообразных данных. Поэтому попытаемся выработать основные этапы анализа аудита. Начнём с подключений пользователей к базе данных. Так как в больших системах количество соединений может составлять тысячи за день, нас в первую очередь будут интересовать подключения пользователей обладающих расширенными привилегиями. К таким пользователям относятся системные учётные записи, отдельная учётная запись администратора базы данных, если таковая имеется. Так же к ним можно отнести и пользователей, которые могут изменить критически важные данные, например известные нам пользователи AH и BE. Такие подключения следует, прежде всего, отслеживать по месту откуда делается попытка соединения. Если соединение осуществлялось с компьютера имя, которого отличается от привычного имени, то, скорее всего, произошёл взлом или утечка регистрационных данных учётной записи. Во всяком случае, на эти записи следует обратить внимание. Выполним, к примеру, следующий запрос:

    В результате мы видим, что было произведено успешное подключение под учётной системной записью BE с компьютера W005, хотя пользователь раньше всегда соединялся только с терминалов W003 или W004. Возможно, это говорит о том, что учётная запись BE была взломана. Если же проверка успешных подключений привилегированных пользователей не показала ничего подозрительного, то нам стоит проанализировать соединения, которые по тем или иным причинам завершились с ошибкой. Делается это с помощью следующего запроса:

    В данном случае видно, что попытка подключения под пользователями AH и BE окончилась неудачей. Но если одиночное неудачное соединение пользователя AH можно списать на ошибку ввода пароля. То аудит подключений пользователя BE может говорить о попытке взлома учётной записи. Кроме вопросов касающихся безопасности аудит подключений можно использовать и в целях определения сеансов сильно загружающих экземпляра базы данных. Всё дело в том, что при удачном завершении подключения в аудит происходит запись некоторой статистики сеанса. Поэтому обращаясь к столбцам SESSION_CPU, LOGOFF_LREAD, LOGOFF_PREAD, LOGOFF_DLOCK можно находить сеансы которые используют, слишком большое количество процессорного времени, осуществляют много физических и логических чтений или имеют взаимоблокировки. Выполним, к примеру, следующий запрос:

    Здесь мы видим, что сеанс пользователя VP длился девять часов, причём время, в течение которого использовался процессор, составило более восьми часов. Это, скорее всего, говорит о ненормальной работе приложения, в котором работал пользователь. Определить, какое это приложение можно только по числовому идентификатору сеанса SESSIONID. Ему соответствует поле AUDSID представления V$SESSION. К сожалению когда мы будем просматривать аудит мы уже не найдем в этом представлении информацию о сеансе. Поэтому нам придётся дополнительно вести историю сеансов с помощью системных триггеров. Разобравшись с подключениями и не выявив попыток взлома или несанкционированного использования учётных записей, можно попытаться разобраться в остальных действиях пользователей. И начать это лучше с проверки выполнения системных команд. К ним в первую очередь стоит отнести команду ALTER SYSTEM динамически меняющую экземпляр базы данных, команды выдачи, отбора привилегий GRANT и REVOKE, операторы изменения настройки аудита AUDIT и NOAUDIT. Выбрать все записи, образующиеся при выполнении этих команд можно с помощью следующего запроса:

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

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

    Подозрительных действий не обнаружено, и мы можем удалить, к примеру, первую запись. Удаление надо производить непосредственно из таблицы SYS.AUD$, используя при этом в качестве ключа значения столбцов SESSIONID и ENTRYID:

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

    Приведённые выше способы удаления подразумевают хранение оставшейся информации, которая нас интересует непосредственно в самом журнале аудита. Это может привести к тому, что, по мере роста журнала аудита, эту информацию также придётся удалять. Чтобы этого не делать, можно организовать архивирование нужных нам записей аудита. Для этого можно создать архивные таблицы по структуре соответствующие представлениям журнала аудита в схеме отличной от SYS. Попробуем продемонстрировать это на примере. Создадим архивную таблицу ARCH_AUDIT_SESSION в схеме SYSTEM. По структуре она будет соответствовать представлению DBA_AUDIT_SESSION, но располагаться в другом табличном пространстве.

    Теперь перенесём нужные нам записи из представления DBA_AUDIT_SESSION:

    После того как все архивные таблицы созданы и необходимые нам записи аудита будут в них перенесены, можно спокойно очистить журнал аудита одной командой DELETE. Правда само удаление записей не решит проблему роста журнала. Для её устранения необходим сброс маркера максимального уровня заполнения таблицы SYS.AUD$. И сделать это можно с помощью нескольких способов. Первый состоит в том, чтобы очистить таблицу SYS.AUD$ с помощью команды TRUNCATE TABLE. Это приведёт к сбросу маркера. Если в таблице должны оставаться какие-либо записи, то необходимо вначале создать копию таблицы с помощью оператора CREATE TABLE AS SELECT. Затем выполнить команду TRUNCATE TABLE и вставить записи из копии таблицы обратно. Если при создании копии таблицы возникают проблемы, например не хватает места в табличном пространстве, то можно выгрузить данные в файл экспорта. Затем провести импорт данных обратно в таблицу. В качестве недостатка этого способа следует отметить, что неиспользуемые блоки, возникшие в результате удаления записей из журнала аудита, не освобождаются. И хотя таблица SYS.AUD$ не будет больше расти по объёму до определённого уровня, она будет иметь такой же размер, как и до её очистки. Чтобы избежать этого, можно использовать ещё один способ сброса маркера. Он представляет собой перемещение таблицы SYS.AUD$ в другое табличное пространство с помощью команды ALTER TABLE MOVE TABLESPACE и последующий возврат таблицы в табличное пространство SYSTEM:

    При этом происходит не только сброс маркера максимального уровня, но и освобождение неиспользуемых блоков сегмента, то есть усечение таблицы. Единственно, что надо не забыть в этом случае, это перекомпилировать объекты, зависимые от таблицы SYS.AUD$, так как данная команда переводит их в статус инвалидных.

    Используем расширенный режим

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

    Рассматривая результат запроса, мы видим, что администратор выполнил какое-то изменение экземпляра базы данных с помощью команды ALTER SYSTEM. Но нам не видно, какие конкретно изменения он сделал. Это могло быть и изменение инициализационного параметра, и уничтожение сеанса пользователя. Если бы мы знали, какую команду выполнил пользователь в данный момент времени, мы могли бы точнее определить само действие и опасность его для системы. К счастью в Oracle начиная с девятой версии, предусмотрен расширенный режим аудита. В данном режиме в качестве дополнения в журнал аудита записываются исполняемые SQL команды, или значения переменных привязки, если таковые имеются. Включается данный режим изменением параметра инициализации AUDIT_TRAIL. Для этого надо присвоить ему значение DB,EXTENDED. Попробуем включить данный режим:

    Перезагрузим экземпляр и проверим правильность установки значения параметра:

    Расширенный режим установился. Заполним журнала аудита новой информацией. И если теперь мы повторим запрос к представлению журнала, то увидим, что в столбце SQL_TEXT появился текст выполненной команды:

    В результате становиться понятно, какие действия совершил пользователь SYSTEM с экземпляром базы данных. Правда иногда, когда в SQL операторе используются связанные переменные, текст команды не даёт полной информации о совершаемом действии. В этом случае нам надо знать значения этих переменных. К примеру, в результате выполнения следующего запроса мы видим две записи с совершенно одинаковыми DML командами. Единственное что их отличает это значения связанных переменных, отображённых в столбце SQL_BIND.

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

    Применяем другие виды журналов

    Журнал аудита, который мы рассматривали выше, представляет собой таблицу AUD$ в схеме пользователя SYS. Но это не единственно место для хранения записей аудита. Кроме таблицы, аудит можно помещаться в системный журнал операционной системы или в XML файлы. Для включения данных режимов требуется изменить значение параметра инициализации AUDIT_TRAIL. Попробуем включить один из таких режимов. Для этого выполним следующую команду:

    Перезагрузим экземпляр и вновь сгенерируем аудит. Если после этого мы сделаем запрос таблице SYS.AUD$, то увидим, что она пуста:

    Но зато в системном журнале операционной системы появились записи. В нашем случае это будет выглядеть примерно так:

    Информацию протоколирования можно записывать не только в системный журнал, но и в отдельные XML файлы. Их расположение определяется значением параметра AUDIT_FILE_DEST и по умолчанию может указывать на директории ORACLE_BASE/admin/DB_UNIQUE_NAME /adump или ORACLE_HOME/rdbms/audit. Попробуем включить данный режим, выполнив следующую команду:

    Перезагрузим экземпляр и проверим значения параметров инициализации:

    Далее проведём генерацию аудита. После чего мы обнаружим в директории C:\ORACLEXE\APP\ORACLE\ADMIN\XE\ADUMP несколько файлов. Это и будут файлы журнала аудита. В каждом отдельном файле с помощью XML формата будут отражены действия, выполняемые пользователем в течение одного сеанса. Имя файла при этом формируется из префикса ora_ и идентификатора серверного процесса. Приведем для примера содержимое одного такого файла:

    Здесь мы могли бы столкнуться с большими трудностями при анализе аудита, так как довольно сложно обрабатывать такие файлы. Но Oracle облегчает задачу, предоставив нам системное представление V$XML_AUDIT_TRAIL. Сделав запрос к нему, мы получим данные аудита в уже привычной для нас табличной форме, где большинство столбцов соответствуют столбцам уже рассмотренного нами представления DBA_AUDIT_TRAIL.

    Хочется отметить одну важную особенность, характерную для обоих режимов аудита. Так как Oracle не может прочитать такие журналы для поиска информации об уже выполнявшейся аналогичной команде в течение сеанса, то запись аудита будет генерироваться при каждом исполнении SQL оператора. Поэтому настройка опций с фокусировкой на сеанс, для данных режимов работы аудита не будет иметь смысла.


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

    1- Введение аудита системы Oracle

    Аудит (Auditing) означает мониторинг и запись (monitoring and recording) действий конфигурированных в базе данных. Включая действия от обоих пользователей (user) database user и nondatabase user.

    Nondatabase Users: Это пользователь определенного приложения. Данное приложение использует базу данных Oracle, и поэтому они могут выполнить действия с базой данных. Данные пользователи должны быть идентифицированы в базе данных используя атрибут CLIENT_IDENTIFIER. Аудит данных пользователей сложнее по сравнению с аудитом пользователей базы данных (Database users).


    Аудит (Auditing) является нужной и важной работой для администратора базы данных. Это эффективный инструмент, который предотврещает неверные действия. И всегда выполняется первым в любых инновациях безопасности в Oracle.

    Помимо этого существуют некоторые другие причины, которые должны быть аудитированы:

    1. Аудитор проверяет пользователей, у которые имеют привелегию доступа к чувствительным объектам.
    2. Аудит трейла (Audit Trail) эффективно предотвращает пользователя от неверных действий.
    3. Audit Trail это обязательно, если вы расследовать и хотите узнать, что выполняется неправильно.
    4. Audit Trail предупреждает вас о подозрительных действиях, вы можете выполнить анализ того, что вам кажется неясным.
    5. Audit Trail очень важен при определении контроля доступа, особенно в существующих приложениях.
    6. Очень сложно определить, что "правило аудита доступа" не разрушит бизнес процесс, только если вы знаете текущее состояние и что они делают.


    1. Действия аудита создают Audit Trail, включая записи, позволяющие найти, что было выполнено в базе данных.
    2. Основываясь на это, чтобы знать что сделали пользователи, и какие привилегии были использованы …
    3. Для каждой записи иеется важная информация как:
      • Кто выполнил
      • Где выполнено (какая Schema или какой Object)
      • Когда выполнено.
      • Как выполнено (Какие команды SQL были выполнены).
      • Так же другие полезные информации в расследовании и мониторинге.

    2- Активировать режим стандартного аудита (standard audit mode)

    Standard Audit (Стандартный аудит) это самая обширная и полная база аудита в базе данных Oracle. Позволяет аудитировать действия (Action), вид действий, объект, привилегию (Privilege), доступ пользователя..

    • Активировать режим аудита (Audit).
    • Определить категории (category) нужные для аудита, то есть определить какие действия будут создавать трейл (Создать Audit Trail).

    Чтобы активировать режим аудита базы данных, вам нужно получить доступ к Oracle с пользователем имеющим привилегию sysdba.


    Аудит трейлы (Audit trail) могут быть таблицей данных или файл на операционной системе. Если аудитор не имеет привилегию (privilege) DBA, лучше всего сохранять информацию аудита на файлах. Есть 4 способа для настройки хранения "аудит трейла".

    ПараметрОписание
    DBТрейл сохраненный в таблице AUD$, содержит только команду (statement) не полный текст.
    DB,EXTENDEDТрейл сохраненный в таблице AUD$, полный текст (Значения переменных (variable) для каждой записи..)
    XMLТрейл сохраненный в файле операционной системы, формата XML, содержание похожее на параметр DB.
    XML,EXTENDEDТрейл сохраненный в файле операционной системы, формата XML, содержание похожее на параметр​​​​​​​ DB,EXTENDED.

    3- Настроить Audit с параметром DB

    Для начала, вам нужно активировать режим аудита с параметром DB (audit_trail = DB), выполнить команды ниже:


    В данном примере мы выполним аудит (audit) таблицы для Scott.EMP, с параметром DB, это значит "аудит трейлы" (audit trail) будут сохранены в базе данных (Точнее будут сохранены в таблице AUD$).


    Использовать другой user чтобы выполнить некоторые действия на таблице Scott.EMP, например update. Данные действия будут сохранены в таблице AUD$.



    4- Настроить Audit с параметром DB,EXTENDED

    Настроить режим аудита с параметром audit_trail = DB,EXTENDED.


    Выполнить действие update на таблице Scott.EMP:


    Использовать другой user, ​​​​​​​чтобы выполнить определенное действие на таблице Scott.EMP:



    5- Set up Audit with XML parameter

    Используя параметр audit_trail = xml, "аудит трейлы (audit trail)" будут сохранены в файле с форматом XML.


    Файлы Audit обычно расположены в папке adump. Но чтобы знать точно, вы можете использовать следующую команду для проверки папки, содержащей файлы Audit.



    6- Set up Audit with XML,EXTENDED parameter

    Когда вы настраиваете аудит с параметром Audit_trail = xml,extended, полученный результат похож на использование параметра Audit_trail = xml, но в файлах XML добавит информацию про команды (statement), которые были выполнены.


    7- Просмотр связанных параметров

    Когда режим аудита уже настроен для базы данных, вы можете проверить использованный параметр.



    Проверить название папки, содержащей файлы Audit, которые будут созданы.


    Название папки содержащей файлы Audit сохранено в файле spfile<SID>.ora.



    Изменить папку содержащую файлы Audit:

    View more Tutorials:

    Это онлайн курс вне вебсайта o7planning, который мы представляем, он включает бесплатные курсы или курсы со скидкой.

    Читайте также: