Контролирование роста и размера аудиторского журнала.

Если журнал переполняется, то всем пользователям будет выдано соответствующее сообщение.

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

Для контроля за ростом аудиторского журнала используются следующие методы:

1) Включение/выключение аудита базы данных.

2) Разборчивость в отношении включенных опций аудитинга.

3) Жесткий контроль возможности осуществления аудитинга объектов

§ всеми объектами владеет администратор защиты, а системная привилегия AUDIT ANY никогда не назначается другим пользователям. Альтернативно все объекты отслеживаемой системы могут принадлежать схеме, которая принадлежит пользователю, не имеющему привилегии CREATE SESSION.

§ все объекты, содержащиеся в схемах, не соответствуют реальным пользователям БД, т.е. привилегия CREATE SESSION не назначена пользователям и администратор защиты является единственным лицом, имеющим системную привилегию AUDIT ANY.

Максимальный размер аудиторского журнала БД определяется во время создания БД. По умолчанию в этой таблице может быть размещено 99 экстентов размером по 10Кб (для версии Oracle 7.3).

Примеры:

DELETE from SYS.AUD$; - удаление всех записей из аудиторского журнала

DELETE from SYS.AUD$ WHERE obj$name=' EMP'; - удаление всех записей, связанных с объектом EMP (EMP – обязательно писать большими буквами).

Если вам нужна информация о аудиторском журнале, то перед очищением журнала ее можно переписать в другую таблицу командой INSERT INTO.

Удалять записи из аудиторского журнала может лишь пользователь SYS, т.е. имеющий привилегию DELETE ANY TABLE.

Если аудиторский журнал переполнен, а включена опция аудита, то все обычные пользователи не смогут регистрироваться. Зарегистрироваться сможет только пользователь SYS (его операции не отслеживаются).

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

Для разрешения этой проблемы нужно выполнить следующие операции:

1) Скопировать информацию аудиторского журнала в другую таблицу БД.

2) Соединиться с БД как Internal.

3) Выполнить операцию усечения таблицы SYS.AUD$ с помощью команды TRUNCATE (эта команда удаляет кроме записей еще и распределенные экстенты).

4) Перезагрузить сохраненные записи в журнал.

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

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

Для того чтобы отслеживать изменения, выполняемые над самим аудиторским журналом, необходимо организовать аудит аудиторского журнала с помощью предложения AUDIT INSERT, UPDATE, DELETE on SYS.AUD$ by ACCESS.

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

Заключительной мерой является то, что любая операция, выполняемая от имени Internal, должна отслеживаться в аудиторском журнале.

Аудит с помощью триггеров

Сама система аудита не позволяет узнавать об изменениях в БД. С помощью системы аудита можно зафиксировать только сам факт внесения изменений. Чтобы иметь возможность фиксировать и сами изменения используют триггеры БД.

Преимущества стандартного аудита системы перед триггерами:

§ опции стандартного аудитинга покрывают предложения DDL и DML для любых типов объектов, схем и структур. Триггеры могут отслеживать только предложения DML, выдаваемые для таблиц.

§ вся аудиторская информация базы данных записывается централизованно и автоматически.

§ аудитинг, включаемый стандартными средствами Oracle, легче сопровождать и объявлять.

§ любые изменения существующих опций стандартного аудитинга также можно отслеживать.

§ используя средства аудитинга БД, можно генерировать аудиторские записи либо каждый раз при выдаче отслеживаемого предложения (опция BY ACCESS), либо один раз за сессию (опция BY SESSION).

§ аудитинг БД может отслеживать безуспешные попытки доступа к данным

Соединение и разъединение, а также статистика сессии могут отслеживаться только стандартным аудитингом базы данных. Применяя триггеры, нужно использовать триггеры, работающие по ALTER.