DeepEdit!

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

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Аудит и различные версии СУБД Oracle

Аудит и детальный аудит отличаются для версий Oracle9i и Oracle 10g. Здесь перечислены основные различия. Более подробная информация об использовании этих особенностей будет приведена ниже (в частности, в разделе «FGA в Oracle 10g»).
 В Oracle 10g расширена функциональность оператора AUDIT, используемого в обычном аудите для регистрации факта выборки из опре деленной таблицы. Теперь он может собирать информацию о выполненном операторе SQL, что было невозможно в предыдущей версии. (Может показаться, что усовершенствование делает обычный и детальный аудит в версии Oracle 10g практически идентичными, но на самом деле это не так, о чем еще будет рассказано дальше.)
В Oracle9i детальный аудит ведется только для операторов SELECT, но не для таких операторов DML, как INSERT, UPDATE и DELETE. В Oracle9i собрать информацию о том, что было изменено, можно только посредством создания триггеров для этих операторов и внесения записей в журнальную таблицу. В Oracle 10g механизм FGA позволяет собирать сведения и об этих операторах DML. Хотя триггеры не очень часто востребованы при работе с Oracle 10g, но иногда имеет смысл использовать именно триггеры, а не FGA. Оба подхода имеют свои достоинства и недостатки, которые будут рассмотрены ниже.
В Oracle9i детальный аудит запускается при ссылке на любой столбец из списка, заданного при создании политики. В Oracle 10g предоставлена возможность выбора: выполнять аудит при ссылке на любой столбец из списка или только при упоминании всех столбцов списка.
Какие еще сведения собирает FGA?
В рассмотренном ранее примере использования аудита мы выбирали данные о пользователе, выполнившем запрос, и о тексте запроса. В журнал аудита записывается еще много другой информации, при этом важнейшим является время выполнения действия. Столбец TIMESTAMP представления DBA_FGA_AUDIT_TRAIL хранит временную метку, для просмотра которой вы, вероятно, захотите использовать следующий формат (для отображения полного значения):
TO_CHAR(TIMESTAMP,'mm/dd/yyyy hh24:mi:ss')
Еще ряд полезных столбцов позволяет установить личность пользователя и получить подробные сведения об отслеживаемых действиях (что поможет обеспечить контролируемость и удобство анализа). Перечислим наиболее важные столбцы представления DBA_FGA_AUDIT_TRAIL:
DB_USER
Пользователь, выполнивший оператор.
SQL_TEXT
Текст выполненного пользователем SQL-оператора.
TIMESTAMP
Момент времени, в который пользователь выполнил действие.
OS_USER
Имя пользователя операционной системы, подключившегося к базе данных.
USERHOST
Терминал или клиентский компьютер, с которого было осуществлено подключение.
EXT_NAME
Пользователь может проходить внешнюю аутентификацию (например, через LDAP). В этом случае имя пользователя в системе внешней аутентификации является важным параметром, который записывается в данный столбец.
SQL_BIND
Значения переменных связывания, использованных в запросе (при их наличии).
FGA и ретроспективные запросы
Затем 10 июля она была повышена моим начальником до 13000, информация о чем была занесена в базу данных.
Для того чтобы понять, почему полезно использовать детальный аудит в сочетании с ретроспективными запросами Oracle, рассмотрим один пример. Предположим, что я (администратор базы данных) смотрю в журнал аудита и обнаруживаю там, что пользователь Scott выдал такую команду:

Так случилось, что служащий с номером 100, - это я, поэтому я испытываю шок от того, что Scott подглядел, какая у меня зарплата. Он уже нацеливался на мое место, так что неудивительно, что он решил проверить мою зарплату. Потом мне в голову приходит такая мысль: за последнее время у меня было несколько повышений, изменивших мою зарплату с 12000 до 13000, затем до 14000 и наконец до 15000. Интересно, что увидел Scott: новую или старую зарплату. И если старую, то какую именно: 12000, 13000 или 14000? Если я сам выполню тот же запрос, что и Scott, то увижу текущую величину - 15000, а не то старое значение, которое было доступно при выдаче запроса Scott.
Oracle9i поддерживает замечательную функциональность, называемую ретроспективным запросом (flashback query), которая поможет ответить на наши вопросы. С ее помощью можно выбирать значение на определенный момент времени в прошлом вне зависимости от того, изменялось ли оно и/или фиксировалось впоследствии. Давайте посмотрим, как это работает.
Предположим, что изначально величина зарплаты равнялась 12000.

Однако такое повышение меня не устроило. 11 июня после повторных переговоров моя зарплата была увеличена до 14000.
SQL> UPDATE emp set salary = 14000 WHERE empid = 100;
1 row updated. SQL> COMMIT;
Но я все еще хотел большего. (Ну что я могу сказать? У меня очень много расходов.) После долгих дискуссий мне удалось убедить моего начальника в том, что такие работники, как я, на вес золота. 12 июня значение было изменено на 15000.

Сегодня, 13 июня, моя зарплата составляет 15000. Для того чтобы увидеть ее величину на 9 июня, следует использовать ретроспективный запрос. Синтаксис AS OF позволяет создать такой запрос:

Точно так же, указывая другие временные метки, можно выяснить значения столбца в другие моменты времени.
Если вы указываете временную метку в предложении AS OF после имени таблицы, то Oracle получает значение из сегментов отката, а не из реальной таблицы (при условии, что сегмент отката достаточно велик и в нем содержится предшествующее изменению значение столбца). В рассмотренном примере предполагается, что сегмент отката хранит изменения за четыре дня. Определить или изменить это значение можно через параметр инициализации базы данных UNDO_RETENTION (задается в секундах). Выбранное мною значение в 4 дня вполне обычно для медленно изменяющихся баз данных (как наша HR), но в быстро меняющихся OLTP базах данных (например, в системах бронирования) следует выбрать большее значение.
При внесении изменения в базу данных Oracle записывает возрастающий счетчик - системный номер изменения (System Change Number - SCN), который однозначно идентифицирует изменения. Благодаря тому, что каждому изменению сопоставлен номер SCN, Oracle может получить старое значение, найдя соответствующий номер SCN и затем запросив значение для данного номера из сегмента отката.

В предыдущем примере использовалась временная метка, а не номер SCN. Как же Oracle сопоставляет номер SCN временной метке, и наоборот? Для этого используется таблица SMON_SCN_TIME, поддерживаемая процессом SMON, который записывает временную метку и соответствующий ей номер SCN. Следует, однако, иметь в виду, что номера SCN записываются с интервалом в пять минут. Приведем пример использования таблицы:


Обратите внимание на пятиминутные промежутки между временными метками. Если в предложении AS OF ретроспективного запроса указана временная метка, то Oracle считает, что номер SCN остается неизменным на протяжении пяти минут. Например, в приведенном выше выводе отображается номер SCN 1167826228 в 15:29:26, и 1167826655 в 15:34:33, что подразумевает, что пять минут между этими временными метками значение SCN всегда оставалось равным 1167826228. Конечно, это неверно. Номер SCN увеличился с 1167826228 до 1167826655, на 427 единиц за 5 минут, что является результатом последовательных приращений в соответствии с многочисленными изменениями, не отраженными в таблице SMON_SCN_TIME. Ретроспективный запрос не может получить более детальную информацию, чем номер SCN, поэтому он считает, что этот номер остается неизмененным на протяжении пятиминутного интервала. Поэтому запрос ищет один и тот же номер SCN - 1167826228 - в 15:29:26, в 15:30:00 и так вплоть до 15:34:33. Так что, указав любую из этих временных меток в предложении AS OF ретроспективного запроса, вы получите одни и те же данные, потому что Oracle будет производить поиск по одному и тому же номеру SCN.

Использование временной метки в ретроспективном запросе позволяет получить результаты с дискретностью в пять минут, но не более точно. Для получения данных на точный момент времени следует использовать предложение AS OF SCN.
Для получения фактических значений необходимо указывать конкретный номер SCN. Предыдущий запрос можно изменить следующим образом:

Значение будет получено для SCN 1167826230 и в результате будет возвращено точное значение для указанного номера SCN, а не округленное в рамках пятиминутного интервала.
Номер SCN является ключевой составляющей журнала детального аудита. Номера SCN позволяют «вернуться в прошлое» для определения значений, впоследствии подвергшихся изменениям, на определенный момент времени. Столбец SCN представления DBA_FGA_AUDIT_TRAIL регистрирует номера SCN на всем протяжении ведения журнала. Для того чтобы определить, какое именно значение столбца SALARY увидел пользователь Scott, можно выполнить следующий запрос, который получает номер SCN при выборке записи пользователем Scott:

Предположим, что запрос вернул 14122310350. Тогда выполняем еще один запрос, теперь уже чтобы узнать точное значение столбца SALARY, которое увидел Scott.

Сведения об SCN в журнале детального аудита чрезвычайно важны, так как сохранение данных, которые пользователь увидел в результате выполнения своего запроса, обеспечивает контролируемость. Помните о том, что объем доступных данных отката зависит от размера табличного пространства отката и значения параметра инициализации базы данных UNDO_RETENTION_PERIOD. Эффективными будут только оперативно выполненные ретроспективные запросы. В противном случае данные могут быть перезаписаны, и получение точных ретроспективных данных окажется невозможным.
При необходимости как можно более точно определить значения столбца на указанный момент времени следует использовать в предложении AS OF не временную метку, а номер SCN.
Настройка FGA
Посмотрим код, использованный в предыдущем разделе, для ввода в действие механизма детального аудита для таблицы:


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

Если внимательно посмотреть на столбцы, то окажется, что для некоторых из них аудит можно считать более важным, чем для остальных. Например, все обращения к столбцу SALARY регистрировать необходимо, а значения столбца HIREDATE, возможно, не следует так же строго контролировать. Давайте предположим, что на этот раз необходим аудит доступа только к столбцам SALARY и COMM, но не ко всем остальным. Для этого следует задать значение параметра audit_column процедуры ADD_POLICY следующим образом:

Такая настройка приводит к тому, что журнал аудита пишется только в случае, если пользователь выбирает данные из столбца SALARY или COMM. Если запрос обращается только к столбцу ENAME, журнал вестись не будет.
Все вышесказанное относится не только к столбцам, явно названным в запросе, но и к столбцам, на которые запрос ссылается неявно. Например, запрос

выбирает все столбцы из таблицы EMP, включая COMM и SALARY. Поэтому это действие записывается. Несмотря на то что имена столбцов явно не названы, запрос ссылается на них неявно.
В Oracle9/ детальный аудит запускается, как только встречается ссылка на любой из столбцов, перечисленных в параметре audit_column. В Oracle 10* существует возможность указать, следует ли включать аудит при ссылке на один из столбцов, или же только при ссылке на все столбцы (см. раздел «FGA для Oracle 10*»).
 









jAntivirus