Существует ряд причин, по которым FGA является чрезвычайно полезным инструментом для администратора базы данных. Сейчас мы познакомим вас с ними, а затем изучим эти вопросы подробно.
Повышение безопасности
Конечно же, основным предназначением FGA является обеспечение безопасности. Возможность регистрации действий пользователя, производимых над базой данных, чрезвычайно важна для безопасности, а FGA предоставляет наилучший способ записи сведений о подобных действиях (в некоторых случаях это и единственно возможный способ, так как традиционный аудит не позволяет собирать данные о том, какой именно запрос был выдан пользователем).
Анализ выполнения SQL
FGA выявляет, кто что сделал. Видя реальные SQL-операторы, выполненные пользователями, администратор базы данных может судить о типах операторов, которые выдаются из приложений конкретными пользователями в определенные моменты времени. Такая информация полезна при принятии решения об индексировании схемы или при анализе повторяемости. Она еще более полезна для систем поддержки принятия решений (Decision Support Systems), в которых запросы обычно специально подбираются к каждому случаю и не могут быть предсказаны заранее. Принимая во внимание возможность отображения другой важной информации, такой как временная метка и имя терминала, а также то, что вся информация находится в таблице, диагностика проблем и анализ доступа значительно упрощаются.
Оптимизация производительности при использовании переменных
Журнал аудита FGA также содержит информацию о значениях переменных связывания, которые широко используются в любом хорошо спроектированном приложении. Откуда можно было бы узнать о том, какие различные значения передаются в ходе работы приложения? Такая информация помогла бы упростить и ускорить принятие решения о необходимости создания индекса для таблицы. Ее предоставит вам журнал аудита FGA.
Эмуляция триггеров SELECT
Хотя такая возможность и не проектировалась специально, скрытая ценность FGA заключается в возможности определения или эмуляции «триггеров на SELECT», которые никаким другим способом в Oracle не доступны. FGA позволяет указать необходимость выполнения PL/SQL-процедуры при выборке данных, так же, как и для изменения данных посредством операторов INSERT, UPDATE или DELETE. FGA имитирует триггер на SELECT, автоматически выполняя хранимую процедуру при выдаче пользователем запроса. Вы можете и далее контролировать выполнение запроса, применяя различные условия (например, выбираемые столбцы, значения использованных столбцов).
Давайте рассмотрим простой пример использования FGA, иллюстрирующий основные возможности детального аудита. Предположим, что таблица EMP в схеме HR базы данных отдела кадров определена следующим образом:
Для удовлетворения требований безопасности и конфиденциальности необходимо отслеживать любые запросы к этой таблице. Использование триггеров или традиционного аудита не подходит, так что обратимся к FGA. Начинаем с создания политик посредством программы
ADD POLICY пакета DBMS FGA:
Для выполнения кода, приведенного в примере, пользователь должен обладать привилегией EXECUTE на пакет DBMS_FGA или запускать код от имени пользователя SYS.
В целом политика FGA управляет отслеживанием операторов, выполняемых для определенной таблицы. Она определяет условия, при которых включается аудит, а также предпринимаемые действия. В предыдущем примере политика EMP_SEL создается и применяется к таблице EMP схемы HR. Имя политики должно быть уникальным в рамках экземпляра базы данных. Для одной таблицы можно определить до 256 отдельных политик. Использование нескольких политик позволяет обеспечить большую гибкость и упростить управление ими. Мы подробнее поговорим об определении политик и управлении ими ниже в этой главе.
Термин «политика», используемый как в рамках FGA, так и RLS, понимается при этом по-разному (о чем уже говорилось в этой главе и в главе 5). Политика FGA похожа на свою RLS- «тезку» тем, что она не является объектом схемы (то есть не принадлежит никакому пользователю). Любой пользователь с при
вилегией EXECUTE на пакет DBMS_FGA может создать и удалить политику, созданную другим пользователем. Поэтому разумно отзывать привилегию EXECUTE для роли PUBLIC (если она была выдана). Следует выдавать привилегию EXECUTE на данный пакет только тем пользователям, которым она действительно необходима.
Политика добавлена - теперь таблица находится под надзором, и действия любого обращающегося к ней пользователя будут регистрироваться. Так что если пользователь Scott выполнит такой оператор:
Для запроса, выполненного только что к таблице EMP, выводятся следующие данные:
Зафиксирован не только сам факт выборки данных из таблицы пользователем Scott, но и точный текст выполненного запроса.
Для просмотра журнала аудита выполните запрос к представлению словаря данных DBA_FGA_AUDIT_TRAIL. (Естественно, для этого необходимо обладать привилегией SELECT на это представление, которая может быть получена через роль или быть выдана напрямую, как SELECT ANY DICTIONARY.) Например:
Если для таблицы определена политика FGA, то такую таблицу нельзя преобразовать средствами встроенного пакета Oracle DBMS_REDEFINITION. Попытка переопределения таблицы, находящейся под контролем FGA, приводит к ошибке ORA-12090: «cannot online redefine table». Поэтому перед созданием политики FGA для таблицы следует подумать о возможности ее реорганизации в будущем.
| < Предыдущая | Следующая > |
|---|
