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





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

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


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



 

DeepEdit!

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

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

FGA и обычный аудит

Начиная с Oracle 10* Release 1 обычный аудит Oracle (реализуемый командой AUDIT) был расширен и обеспечивает регистрацию информации, которая была недоступна в предыдущих версиях (например, текст выданного оператора SQL, переменные связывания и т. д.). Он во многом стал похож на FGA. Избавляет ли он при этом от необходимости использования FGA? Не совсем. Давайте рассмотрим различия между обычным и детальным аудитом.
Типы операторов
Обычный аудит может отслеживать множество различных видов операторов: DML, DDL, операторы управления сеансом, операторы управления привилегиями и т. д. FGA может отслеживать только один оператор (SELECT) в версии Oracle9i и четыре (SELECT, INSERT, UPDATE, DELETE) - в Oracle 10*.
Специальные параметры
FGA запускается, не требуя никаких специальных параметров. Таблица FGA_LOG$ - хранилище записей журнала аудита FGA, уже существует в схеме SYS. Обычный аудит сначала необходимо включить на уровне базы данных, только потом можно будет регистрировать действия с отдельными объектами. Для этого следует задать параметр инициализации AUDIT_TRAIL. Параметр не является динамическим, поэтому после его установки придется перезапустить базу данных, чтобы он начал действовать.
Успех или неудача
Обычный аудит можно настроить так, чтобы он проводился вне зависимости от того, успешным или неудачным оказалось действие пользователя. FGA работает только для успешно выполненных операций.
Отключение/включение
FGA можно временно отключить, а затем включить. С обычным аудитом так поступать нельзя. Для приостановки обычного аудита следует использовать команду NOAUDIT для объекта. Если впоследствии вы захотите заново применить те же настройки аудита, что и раньше, вам придется их вспомнить, так как эта информация будет утеряна.
Выборочный аудит строк
FGA регистрирует доступ к данным каждый раз, когда пользователь выполняет оператор, вне зависимости от того, сколько строк
было изменено. Для обычного аудита можно указать, следует ли вносить записи в журнал по одной на обращение к данным или по одной на сеанс. Таким образом, при обычном аудите возможно уменьшение размера журнала аудита.
Таблицы базы данных или файлы операционной системы
Обычный аудит можно настроить так, чтобы журнал записывался в таблицы базы данных (AUDIT_TRAIL=DB) или в файлы операционной системы (AUDIT_TRAIL=OS). Последний вариант удобен тогда, когда предполагается обращение к журналам не администратора базы данных, а аудитора. Использование файлов операционной системы удобно также тем, что резервные копии журналов можно делать соответствующими средствами для файлов. В Windows, если AUDIT_TRA- IL=OS, журналы аудита пишутся в журнал событий (Event Log), и доступ к ним осуществляется специальным образом. Использование операционной системы позволяет обеспечить целостность журналов аудита. В отличие от журналов обычного аудита, журналы FGA могут храниться только в таблице базы данных FGA_LOG$. В FGA вы можете создать модули обработки для записи в файлы, но так как такие модули пишутся от имени владельца программного обеспечения Oracle, они не защищены от возможных злоупотреблений со стороны администраторов баз данных.
Объекты по умолчанию
Обычный аудит может быть задан для объектов по умолчанию - объектов, которые еще только будут созданы. Например, команда AUDIT UPDATE ON DEFAULT; указывает, что база данных должна включить аудит для операции обновления всех таблиц, в том числе и тех, которые еще не созданы. При создании новой таблицы она автоматически помещается под контроль аудита для обновлений. FGA позволяет создание политик только для уже существующих таблиц и представлений.
Выборочные столбцы
Обычный аудит не обеспечивает возможности детального распознавания действий, таких как доступ к отдельному столбцу. FGA позволяет выборочно вести аудит для определенных столбцов, в результате чего журнал аудита имеет приемлемые размеры.
Запись текста SQL и переменных связывания
Мы уже говорили о том, что FGA записывает текст выполненных операторов SQL и значения переменных связывания. Это поведение по умолчанию, которое можно изменить, задав параметр audit_trail процедуры ADD_POLICY пакета DBMS_FGA. При обычном аудите для сбора таких сведений необходимо установить параметр инициализации базы данных AUDIT_TRAIL в значение DB_EXTENDED и перезагрузить базу данных, чтобы настройки вступили в силу.
Привилегии
Для выдачи команды включения обычного аудита пользователю необходимо обладать системной привилегией AUDIT SYSTEM или AUDIT ANY. Для работы с FGA пользователю необходима только привилегия EXECUTE на пакет DBMS_FGA.
Как видите, FGA значительно отличается от обычного аудита даже при том, что в версии Oracle 10* их журналы стали очень похожи друг на друга. Их сходство привело к тому, что в Oracle 10* новое представление DBA_COMMON_AUDIT_TRAIL отображает записи из обоих журналов аудита: для обычного аудита и детального аудита.
Пользователи, не зарегистрированные в базе данных
Уже не раз говорилось о том, что FGA регистрирует не только того, кто выполнил какое-то действие, но и то, что собственно произошло: изменившаяся строка, номер SCN на момент выполнения действия, терминал и многое другое. Конечно, наиболее важными являются сведения о пользователе, выполнившем отслеживаемую операцию. Они заносятся в столбец DB_USER представления DBA_FGA_AUDIT_TRAIL.
Однако в некоторых случаях имя пользователя базы данных не идентифицирует реального пользователя. В главе 5 при обсуждении безопасности на уровне строк вы видели, что некоторые типы архитектуры (например, трехзвенные веб-системы) устроены так, что для создания пула соединений с базой данных используется один идентификатор пользователя. Веб-пользователь подключается к серверу приложений, который в свою очередь подключается к пулу соединений, из которого пользователю выделяется одно соединение. После того как пользователь переходит в режим ожидания, это соединение может быть передано другому пользователю. Тем самым относительно небольшое количество сеансов базы данных может обслуживать большое число пользователей.
Однако такой сценарий создает проблему идентификации реальных пользователей базой данных. Для базы данных именем пользователя является разделяемый идентификатор, используемый пулом соединений, а не имя стоящего за ним реального пользователя. Таким образом столбец DB_USER записей аудита FGA содержит разделяемый идентификатор пользователя, который не может обеспечить настоящую контролируемость. Чтобы точно определить пользователя, выполнившего действие, необходимо идентифицировать реального отдельного пользователя внутри пула. Как это сделать?
Существует несколько способов. Большинство из них основывается на передаче дополнительной информации о реальном пользователе во вспомогательных элементах данных, соответствующих сеансу. Эти элементы заполняются клиентом и считываются базой данных при
сборе данных об изменениях. Важнейшими элементами являются идентификатор клиента и контекст приложения. Мы уже встречались с ними в главе 5, поэтому сейчас сразу приступим непосредственно к тому, как использовать эти элементы для детального аудита.
Идентификатор клиента
В результате в столбец CLIENT_IDENTIFIER представления V$SESSION попадет значение REAL_USER. Из другого сеанса можно будет запросить значение данного столбца.
Возвращается REAL_USER.
Данные сведения доступны не только в представлении V$SESSION; они также отображаются в журналах FGA:
Начиная с версии Oracle9i символьная строка переменной длины может использоваться в качестве атрибута пользовательского сеанса. Это значение можно впоследствии извлечь в другой программе при помощи запроса к представлению V$SESSION и получить отличительную информацию о реальном пользователе. Предположим, что пользователь подключается к базе данных как DBUSER и выдает такой оператор:
Также возвращается значение REAL_USER.
Если данное значение соответствует имени реального пользователя, это позволит обеспечить контролируемость для данного пользователя.
Существует несколько возможностей надежного и безопасного задания идентификатора клиента, которые рассматривались в главе 5.
Контексты приложения
Контексты приложения - это множества пар имя-значение, которые могут быть определены в сеансе посредством выполнения специально определенной хранимой процедуры. Они чаще всего используются для контроля доступа к ресурсам базы данных согласно правилам, зависящим от текущего пользователя (которые подробно рассматривались при обсуждении безопасности на уровне строк в главе 5). Как и идентификаторы клиента из предыдущего раздела, контексты приложения могут использоваться для передачи индивидуальных характеристик реального пользователя. Любой из способов (или их комбинация)
обеспечивает возможность идентификации пользователей, не зарегистрированных в базе данных.
Описание и примеры использования контекстов приложения приведены в главе 5.
 



jAntivirus