Использование и Обслуживание Контрольной информации. Аудит, основанный на значениях

Рубрика: Реализация Аудита Базы Данных Oracle

Использование и Обслуживание Контрольной информации

Отключите опции аудита, если Вы не используете их.

11.13_2.gif

Совет из передовой практики

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

Аудит, основанный на значениях

Аудит, основанный на значениях

Аудит базы данных записывает вставки, обновления и удаления, которые произошли в контролируемых объектах, но не получает фактические значения, которые изменяются. Чтобы расширить аудит базы данных, есть возможность сконфигурировать контроль, основанный на значениях, применяя триггеры базы данных (событийно-управляемые конструкции PL/SQL), чтобы получить измененные значения.

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

Основанный на значениях аудит реализуется пользователем или сторонним кодом. База данных Oracle предоставляет PL/SQL конструкции, позволяющие построить системы аудита, основанным на значениях.

Ключ к основанному на значениях аудиту - контрольный триггер, который является обычным PL/SQL триггером, который создается для получения контрольной информации.

Пример типичного триггера аудита:

    
CREATE OR REPLACE TRIGGER system.hrsalary_audit
    AFTER UPDATE OF salary
    ON hr.employees 
    REFERENCING NEW AS NEW OLD AS OLD 
    FOR EACH ROW  
BEGIN
 IF :old.salary != :new.salary THEN
     INSERT INTO system.audit_employees  
     VALUES (sys_context('userenv','os_user'), sysdate, 
     sys_context('userenv','ip_address'),
     :new.employee_id ||
		    ' salary changed from '||:old.salary|| 
     ' to '||:new.salary);
  END IF; 
END;
/

Этот аудит, сфокусированный при помощи триггера, получает изменения в столбце зарплаты таблицы hr.employees. Когда строка обновляется, триггер проверяет столбец зарплаты. Если старая зарплата не равна новой зарплате, триггер вставляет контрольную запись в таблицу audit_employees (созданную в отдельной операции в схеме SYSTEM). Контрольная запись включает имя пользователя, IP-адрес с которого произведено изменение, первичный ключ, указывающий, какая запись изменяется, и фактические значения зарплаты, подверженные изменению.

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

  • IP-адрес человека, входящего в систему

  • Первые 48 символов названия программы, которая используется для соединения с экземпляром

  • Терминальное имя, которое используется, чтобы соединиться с экземпляром

Полный список пользовательских параметров см. в разделе “SYS_CONTEXT” в Oracle Database SQL Reference.

Основанные на значениях триггеры во многих случаях уступают функции тщательного аудита (FGA).

Далее: Статистика оптимизатора

Смотрите также
Комментарии
Написать

(обязательно)

(обязательно)

Это не спам (обязательно)