2.3.2.2 Другие подходы реализации fgac

Подход с использованием нескольких представлений достаточно типичен, хотя и имеет преимущества независимости от СУБД. Разработчики приложений создают несколько учетных записей в базе данных, например EMPLOYEE, MANAGER, HR_REP, и устанавливают в каждой из соответствующих схем полный набор представлений, выбирающих только необходимые данные. Для рассматриваемого примера в каждой схеме создается отдельное представление ЕМР со специализированным условием выбора данных для соответствующей группы пользователей.

Для управления тем, что конечные пользователи могут просматривать, создавать, изменять и удалять, придется создавать до четырех различных представлений для таблицы ЕМР - для операторов SELECT, INSERT, UPDATE и DELETE. Это быстро приводит к запредельному увеличению количества объектов базы данных — каждый раз при добавлении новой группы пользователей придется создавать и поддерживать новый набор представлений.

Если правила защиты изменятся (например, если необходимо разрешить руководителям просматривать записи не только непосредственных подчиненных, но и подчиненных следующего уровня), придется пересоздать представление в базе данных, делая недействительными все объекты, которые на него ссылаются. Такой подход приводит не только к увеличению количества представлений в базе данных, но и требует, чтобы пользователи регистрировались от имени нескольких совместно используемых учетных

записей, что осложняет контроль работы пользователей. Кроме того, этот подход требует дублирования значительного объема кода в базе данных. При наличии хранимой процедуры, работающей с таблицей ЕМР, придется устанавливать ее в каждой из задействованных схем. Это относится и ко многим другим объектам (триггерам, функциям, пакетам и т.д.). Теперь при внесении изменений в программное обеспечение придется каждый раз изменять N схем, чтобы все пользователи выполняли один и тот же код.

Еще один подход связан с использованием, кроме представлений, триггеров базы данных. Вместо создания отдельных представлений для операторов SELECT, INSERT, UPDATE и DELETE, для построчного просмотра выполняемых пользователем изменений используется триггер, принимающий или отвергающий эти изменения. Эта реализация не только приводит к созданию большого количества дополнительных представлений, но и влечет расходы ресурсов на поддержку срабатывания триггера (иногда весьма

сложного) для каждой изменяемой строки.

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

2.3.3.3 Реализация FGAC

Реализовать FGAC решено с помощью Oracle пакета DBMS_RLS. Этот пакет обеспечивает функциональный интерфейс для добавления, удаления, изменения, включения и отключения правил защиты. Соответствующие подпрограммы можно вызвать из любого языка программирования или среды, из которых можно подключиться к СУБД Oracle. Его самое главное достоинство простота в использовании и минимум кода. Для реализации требуется только одна функция.

create or replace function security_policy_function(p_schema in varchar2,

p_object in varchar2)

return varchar2

as

begin

if (user = p_schema) then

return '';

else

return 'owner = USER';

end if;

end;

Эта функция, реализующей правила защиты, всегда возвращает значение типа VARCHAR2. Возвращаемое значение представляет собой условие, которое будет добавлено к запросу. Фактически это условие будет добавляться к таблице или представлению, к которым применяется это правило защиты, с помощью подставляемого представления (inline view):

3anpoc: SELECT * FROM T

Будет переписан как:

SELECT * FROM (SELECT * FROM T WHERE owner = USER)

или:

SELECT * FROM (SELECT * FROM T)

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

Итак, в нашем примере условие owner = USER будет динамически добавляться ко всем запросам к таблице, с которой связана эта функция, эффективно ограничивая множество строк, доступных пользователю. Пустое условие будет возвращаться только в том случае, если текущий зарегистрированный пользователь является владельцем таблицы. Вернуть пустое условие — то же самое, что вернуть условие 1=1 или True. Возврат значения Null равносилен возвращению пустого условия. В представленном выше примере вместо пустой строки можно было с тем же результатом возвращать Null.

Чтобы связать функцию с таблицей, используется рассматриваемая далее PL/SQL- процедура DBMS_RLS.ADD_POLICY. В нашем примере имеется следующая таблица, а сеанс выполняется от имени пользователя CRM:

Alter table crm.contact add column OWNER varchar2(30) default USER

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

begin

dbms_rls.add_policy

(object_schema => 'CRM',

object_name => 'contac',

policy_name => 'CRM_POLICY',

function_schema => 'CRM',

policy_function => 'security_policy_function',

statement_types => 'select, insert, update, delete',

update_check => TRUE,

enable => TRUE

);

end;