Программирование >>  Oracle 

1 ... 336 337 338 [ 339 ] 340 341 342 ... 469



Тщательный контроль

доступа

Тщательный контроль доступа (Fine Grained Access Control - FGAC) в Oracle 8i позволяет во время выполнения динамически добавлять условие (конструкцию WHERE) ко всем запросам, обращенным к таблице или представлению базы данных. Теперь можно процедурно изменять запрос во время выполнения, другими словами, динамически создавать представление. Можно проверить, кто выполнял запрос, с какого терминала и когда (например, по времени суток) он выполнялся, а затем создать условие на основе этой информации. С помощью контекстов приложений можно безопасно добавлять в среду информацию (например, роль пользователя в отношении приложения) и обращаться к этой информации в процедуре или условии.

В различных публикациях средства FGAC описываются под различными названиями. Обычно используются следующие:

тщательный контроль доступа (Fine Grained Access Control);

виртуальная приватная база данных (Virtual Private Database - VPD);

защита на уровне строк (Row Level Security), или пакет DBMS RLS (этот PL/SQL-пакет реализует соответствующие возможности).

Чтобы выполнять представленные в этой главе примеры, необходим сервер Oracle версии 8.1.5 или выше. Кроме того, средства тщательного контроля доступа доступны только в редакциях Enterprise и Personal Edition; в Standard Edition эти примеры работать не будут.

В этой главе мы рассмотрим следующее.

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



1438

Глава 21

Два примера в разделе Как реализованы средства тщательного контроля доступа , демонстрирующие применение правил защиты (security policies) и контекстов приложений.

Проблемы и нюансы, которые необходимо учитывать, в частности особенности функционирования средств тщательного контроля доступа при наличии требований целостности сс1лок, кэширование курсоров, особенности экспортирования и импортирования данных и тонкости отладки.

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

Пример

Предположим, существуют правила защиты, определяющие, какие строки могут просматривать различные группы пользователей. Правила защиты позволяют разработать условие проверки, учитывающее, кто зарегистрирован и какую роль он имеет в системе. Средства тщательного контроля доступа позволяют переписать простой запрос SELECT * FROM EMP следующим образом:

Пользователь зарегистрирован

Запрос переписывается так... Комментарии

как...

Сотрудник

Сотрудники отдела кадров.

select * from (select * from emp where ename = USER)

Рядовые сотрудники мог просматривать только собственные записи,

Руководитель select

подразделения from (select

from emp where mgr = (select empno from emp where ename = USER) or ename = USER

Руководители подразделений могут просматривать свои записи и записи сотрудников своего подразделения,

select * from (select *

from emp where deptno = SYS CONTE(OurApp,

Сотрудники отдела кадров могут видеть все записи в данном подразделении. В этом примере представлен ptno) способ получения значений переменных из контекста приложения с помощью встроенной функции SYS CONTEXT().



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

Когда использовать это средство?

В этом разделе рассмотрены причины и варианты использования средств тщательного контроля доступа.

Простота сопровождения

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

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

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

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

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



1 ... 336 337 338 [ 339 ] 340 341 342 ... 469

© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика