Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

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

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

Детальный аудит

Аудитом называется механизм регистрации действий пользователей базы данных. Позволяя определить, кем из пользователей выполнены определенные действия, аудит обеспечивает контролируемость (accountability), которая является краеугольным камнем безопасности. Традиционный аудит в Oracle сохраняет сведения о сделанных пользователями изменениях данных, но не о выполненных ими запросах. Детальный аудит (Fine-grained audit, FGA), введенный в Oracle9i, расширяет возможности регистрации, позволяя сохранять сведения как об изменениях, так и о запросах. Детальный аудит очень важен с точки зрения безопасности; помимо этого он служит прекрасным средством анализа использования SQL и оценки производительности как отдельных операторов, так и приложения в целом. Он предоставляет метод для исследования типовых обращений к данным, который может стать мощным инструментом для повышения производительности базы данных.
Эта глава поможет вам в эффективном использовании детального аудита, который (позволяя выбирать, какие события и какие сведения о них должны регистрироваться) может настраиваться для наилучшего соответствия требованиям вашей базы данных и приложений.
Функциональность детального аудита Oracle базируется на встроенном пакете DBMS_FGA. В этой главе описаны программы DBMS_FGA, позволяющие создавать и использовать политики детального аудита; также рассмотрено соответствие возможностей FGA в версиях Oracle9i и Oracle 10g. Кроме того, рассматривается взаимодействие детального аудита с другим нововведением Oracle 10g - ретроспективными запросами (flashback query), позволяющими точно определить, какие результаты получали пользователи при выполнении своих запросов (а не то, что в данный момент находится в базе данных). Затем мы сравним FGA с триггерами базы данных, которые традиционно использовались для реализации отдельных функций детального аудита.
В силу того, что многие администраторы еще работают с Oracle9i, эта глава начинается с описания возможностей FGA этой версии, большая часть которых аналогично реализуется в Oracle 10g. Затем в разделе «FGA в Oracle 10g» описываются усовершенствования, сделанные в Oracle 10g.
Не путайте аббревиатуры FGA и FGAC; последняя означает «детальный контроль доступа» (fine-grained access control) - другое название технологии RLS, описанной в главе 5.
введение в детальный аудит
Чтобы извлечь максимум возможного из технологии FGA, начнем с изучения общих требований к аудиту, а затем рассмотрим простой пример использования детального аудита FGA.
Для обеспечения корректной работы FGA необходимо, чтобы база данных функционировала в режиме оптимизации по стоимости. Запросы должны использовать оптимизатор по стоимости (то есть они не должны использовать хинты RULE); таблицы (или представления) запроса должны анализироваться хотя бы на основе приблизительных оценок. В противном случае возможно ложное срабатывание FGA, то есть запись в журнал аудита будет вестись даже в отсутствии необходимости. Имейте в виду, что Oracle 10g использует оптимизатор по стоимости по умолчанию, о чем мы поговорим далее.
Что такое аудит?
Одним из основных требований компьютерной безопасности является контролируемость, то есть возможность отслеживания действий пользователя таким образом, чтобы впоследствии можно было сопоставить действия выполнившим их пользователям. Oracle обеспечивает контролируемость за счет применения аудита: отслеживания того, кто что сделал. Предположим, что пользователь Scott выполняет такой запрос:

Если аудит корректно настроен, то база данных зарегистрирует факт того, что пользователь Scott что-то выбрал из таблицы EMP, а также запишет ряд других данных: время доступа, использованный терминал и т. д. Записываемая информация называется журналом аудита (audit trail) и при необходимости может использоваться для последующего анализа действий Scott. Журнал аудита принадлежит пользователю SYS, поэтому обычные пользователи не могут изменить его содержимое и соответственно скрыть сведения о своих действиях. Традиционный журнал аудита Oracle хранится в таблице AUD$, принадлежащей пользователю SYS. Информация журнала доступна пользователям через такие
представления словаря данных, как DBA_AUDIT_TRAIL. Журнал аудита может храниться не только в таблицах базы данных, но и в файлах операционной системы.
По умолчанию действия пользователя SYS не отслеживаются. Для того чтобы выполнять аудит и для его объектов, следует установить параметр инициализации базы данных AUDIT_SYS_OPERA- TI0NS в значение TRUE. Однако в этом случае записи аудита будут вноситься в файлы операционной системы, а не в таблицы базы данных. Общее эмпирическое правило говорит о том, что никогда не следует выполнять обычные операции DML от имени SYS.
К сожалению, обычный аудит имеет серьезные ограничения: записывается лишь сам факт того, что Scott что-то выбрал из таблицы EMP, но не результат выполнения запроса. А чаще всего вопрос «Что?» не менее важен, чем «Кто?». Например, в финансовых компаниях финансовые данные клиентов должны быть защищены от любопытных. Для обеспечения конфиденциальности компания может захотеть регистрировать пользователей, просматривающих секретные клиентские данные. В этом случае необходимо записывать не только личность пользователя, обращавшегося к данным, но и то, какие именно данные просматривались. Обычный аудит не позволяет определить, какие записи просматривали пользователи, фиксируется только факт просмотра каких-то данных в таблице.
Один из способов сбора информации об изменяющих данные операторах DML заключается в создании триггеров для таблицы. Однако обычно администратор базы данных хочет знать не только об изменении данных, но и о выборке. Триггеры не могут быть сопоставлены операторам SELECT, поэтому получить подобную информацию из DML- триггеров для строк невозможно. В версиях, предшествующих Orac- le9i, вообще не было возможности сбора сведений об операторах SELECT.
Начиная с Oracle9i эту брешь заполняет FGA. Используя эту технологию, вы можете отслеживать действия над таблицами, не создавая (и не поддерживая) триггеры. Oracle записывает сведения FGA в отдельную таблицу (не в ту, которая используется для обычного аудита) - FGA_LOG$ в схеме SYS. Этой таблице соответствует представление словаря данных DBA_FGA_AUDIT_TRAIL.
Далее в этой главе мы будем обсуждать и сравнивать различные виды аудита, поддерживаемые Oracle в настоящее время. Вы сможете выбрать тот подход, который наиболее полно отвечает требованиям вашего приложения.
 



jAntivirus