Тщательный контроль доступа 1443

Третий вариант - использование средств тщательного контроля доступа - наиболее безболезненный и простой. Можно, например, добавить в каждую таблицу, требующую защиты, столбец с идентификатором организации. Для поддержки значений в этом столбце надо использовать триггер (чтобы не пришлось изменять приложение). Триггер будет брать соответствующее значение из контекста приложения, устанавливаемого в системном триггере ON LOGON. Правила защиты будут задавать условие выбора строк только соответствующей организации. При этом можно ограничивать доступ к данным не только по идентификатору клиента, но и по любым другим необходимым условиям. В нашей системе кадрового учета добавлять можно не только условие WHERE COMPANY = ЗНАЧЕНИЕ, но и дополнительные условия, в зависимости от того, работает ли с системой рядовой сотрудник, руководитель или сотрудник одела кадров. Можно пойти еще дальше и добавить условия фрагментации, чтобы физически отделить данные крупных клиентов с целью обеспечения надежности хранения и высокой доступности.

Как реализованы средства тщательного контроля доступа

Средства тщательного контроля доступа в Oracle 8i реализуются с помощью двух конструкций.

Контекст приложения. Это пространство имен с соответствующим набором пар атрибут/значение. Например, в контексте OurApp можно обращаться к переменным DeptNo, Mgr и т.д. Контекст приложения всегда привязан к PL/SQL-паке-ту. Этот пакет - единственный метод установки значений в контексте. Чтобы установить значение атрибута DeptNo в нашем контексте OurApp, необходимо обратиться к соответствующему пакету, связанному с контекстом OurApp. Этот пакет может корректно устанавливать значения в контексте OurApp (вы сами его написали, поэтому и считается, что он будет правильно устанавливать значения в контексте). Это предотвращает установку значений в контексте приложений злонамеренными пользователями с целью получения несанкционированного доступа к информации. Читать значения в контексте приложения может кто угодно, но устанавливать их может только один пакет.

Правила защите!. Это созданная разработчиком функция, возвращающая условие для динамического фильтрования данных при выполнении запроса. Эту функцию можно привязывать к определенной таблице или представлению, и вызываться она может для всех или только для некоторых операторов, обращающихся к таблице. Это означает, что можно задать одни правила для оператора SELECT, другие - для INSERT и третьи - для операторов UPDATE и DELETE. Обычно в этой функции используются значения атрибутов в контексте приложений для создания соответствующего условия (например, проверяется, кто зарегистрировался и что он пытается сделать и создается соответствующее подмножество строк для работы). Следует помнить, что для пользователя SYS (или INTERNAL) правила защиты никогда не применяются (соответствующие функции просто никогда не вызываются); эти пользователи всегда могут читать и изменять все данные.

1444

Глава 21

Также следует упомянуть средства сервера Oracle 8i, расширяющие возможности средств тщательного контроля доступа.

Функция SYS CONTEXT. Эта функция используется в языках SQL и PL/SQL для

доступа к значениям в контексте приложения. Подробное описание этой функции и список стандартных значений в автоматически устанавливаемом сервером Oracle контексте USERENV можно найти в руководстве Oracle SQL Reference. Из этого контекста можно получить имя пользователя, организовавшего сеанс, IP-адрес клиента и другую полезную информацию.

Триггеры на соб1тие регистрации в базе данн1х. Они позволяют выполнять любой код при регистрации пользователя в базе данных. Это очень удобно для настройки первоначального, стандартного контекста приложения.

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

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

EXECUTE CATALOG ROLE. Эта роль позволяет разработчику выполнять подпрограммы пакета DBMS RLS. Достаточно также, подключившись как SYS, предоставить пользователю привилегию на выполнение пакета DBMS RLS.

CREATE ANY CONTEXT. Эта привилегия позволяет разработчику создавать контексты приложений.

Контекст приложения создается с помощью SQL-оператора:

SQ create or replace context OurApp using Our Context Pkg;

Здесь OurApp - имя контекста, a Our Context Pkg - PL/SQL-пакет, которому разрешается устанавливать значения атрибутов контекста. При реализации средств тщательного контроля доступа контексты приложений существенны по двум причинам.

Они обеспечивают надежн1й способ установки значений переменн1х в пространстве имен. Устанавливать значения в контексте можно только с помощью PL/SQL-пакета, связанного с этим контекстом. Это гарантирует целостность значений в контексте. Поскольку контекст используется для ограничения или обеспечения доступа к данным, необходимо гарантировать целостность значений в контексте.

Сс1лки на значения атрибутов контекста в SQL-запросе обрабат1ваются как свя-з1ваемые переменн1е. Например, если установить значение атрибута DeptNo в контексте OurApp и реализовать правило защиты, возвращающее конструкцию WHERE deptno = SYS CONTEXT(OurApp,DeptNo), соответствующий оператор не будет в разделяемом пуле уникальным, поскольку обращение к функции SYS CONTEXT аналогично deptno = :bl. В сеансах можно будет задавать различные значения атрибута Deptno, но все они будут повторно использовать одни и те же оптимизированные планы запросов.

Тщательный контроль доступа 1445

Пример 1: Реализация правил защиты

Чтобы продемонстрировать возможности средств тщательного контроля доступа, будут реализованы очень простые правила зашиты. Зададим следующие правила.

Если текущий пользователь является владельцем таблицы (OWNER), он может обращаться ко всем ее строкам.

В противном случае пользователь может обращаться только к строкам, у которых значение в столбце OWNER совпадает с его именем.

Кроме того, добавлять можно только строки, в столбце OWNER которых указано имя обращающегося пользователя. Попытки добавить строку с другим значением в этом столбце отвергаются.

Для реализации этих правил необходимо создать следующую PL/SQL-функцию:

tkyte@TKYTE816> create or replace

2 function security policy function(p schema in varchar2,

3 p object in varchar2)

4 return varchar2

5 as

6 begin

7 if (user = p schema) then

8 return ;

9 else

10 return owner = USER;

11 end if;

12 end;

13 / Function created.

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

3anpoc: SELE * FROM T

Будет переписан как: SELE * FROM (SELECT * FROM T owner = USER)

или: SELE * FROM (SELECT * FROM T)

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

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