Тщательный контроль доступа (Fine Grained Access Control)
Так же называют
• виртуальная приватная база данных (Virtual Private Database - VPD);
• защита на уровне строк (Row Level Security), или пакет DBMS_RLS (этот PL/SQL- пакет реализует соответствующие возможности).
позволяет во время выполнения динамически добавлять условие (конструкцию WHERE)
ко всем запросам, обращенным к таблице или представлению базы данных. Теперь можно
процедурно изменять запрос во время выполнения, другими словами, динамически создавать представление. Можно проверить, кто выполнял запрос, с какого терминала и когда (например, по времени суток) он выполнялся, а затем создать условие на основе этой информации. С помощью контекстов приложений можно безопасно добавлять в среду информацию (например, роль пользователя в отношении приложения) и обращаться к этой информации в процедуре или условии.
Средства тщательного контроля доступа доступны только в редакциях Enterprise и Personal Edition. (из издания 2003г про Oracle 8i).
Средства тщательного контроля доступа позволяют с помощью одной таблицы и одной хранимой процедуры справиться с задачей, для решения которой могло бы понадобиться несколько представлений или триггеров, или большой объем специализированной обработки в приложениях.
Средства тщательного контроля доступа позволяют избежать потери функциональных возможностей с помощью всего двух объектов - исходной таблицы (или представления) и пакета (или функции) базы данных. Пакет можно изменить в любой момент, разработав новые правила защиты. Вместо поддержки десятков представлений, реализующих правила защиты для объекта, всю соответствующую информацию можно задавать в одном месте.
Средства тщательного контроля доступа позволяют отделить алгоритмы защиты от других алгоритмов работы приложения. Разработчик приложения может заняться прикладными алгоритмами, а не алгоритмами безопасного доступа к данным. Поскольку тщательный контроль доступа выполняется полностью на сервере баз данных, эти алгоритмы немедленно наследуются всеми приложениями. Раньше разработчикам приходилось включать алгоритмы защиты в приложения, что усложняло разработку и дальнейшее сопровождение приложений. Если приложения должны обеспечивать защиту доступа к данным, а доступ к одним и тем же данным выполняется во многих компонентах приложения, изменение правил защиты повлияет на десятки модулей приложения. При использовании средств тщательного контроля доступа все соответствующие модули автоматически наследуют новые правила доступа без каких-либо изменений в коде.
При использовании средств тщательного контроля доступа каждый пользователь может регистрироваться от имени уникальной учетной записи. Это позволяет выполнять полный учет и проверку действий на уровне пользователей. В прошлом многие разработчики приложений, столкнувшись с необходимостью обеспечивать разное представление данных для различных пользователей, создавали совместно используемые учетные записи.
Например, все сотрудники для доступа к кадровой информации использовали учетную запись EMPLOYEE; все руководители - учетную запись MANAGER и т.д. Это не позволяло контролировать действия на уровне отдельных пользователей. Невозможно было понять, регистрировался ли пользователь TKYTE - в системе работало несколько сеансов от имени учетной записи EMPLOYEE (кто бы из сотрудников ни подключался).
При желании можно использовать средства тщательного контроля доступа вместе с такими совместно используемыми учетными записями. Однако эти средства позволяют избежать необходимости создания и использования таких учетных записей.
С помощью контекста приложения можно использовать средства тщательного контроля доступа и в "однопользовательской" среде, например, используемой при организации пула подключений сервера приложений. Некоторые пулы подключений требуют при регистрации использования одной учетной записи базы данных. Средства тщательного контроля доступа прекрасно работают и в таких средах.
Средства тщательного контроля доступа позволяют поставщику прикладных служб (Application Service Provider - ASP), не изменяя существующее приложение, предоставить к нему как к службе доступ множеству клиентов. Предположим, имеется приложение по учету кадров, доступ к средствам которого хотелось бы за деньги предоставлять клиентам по сети Internet. Поскольку клиентов предполагается много и все они требу ют гарантий конфиденциальности данных, необходимо придумать способ защиты данных одного клиента от доступа других. Возможны следующие варианты:
• установить, сконфигурировать и поддерживать отдельные экземпляры базы данных для каждого клиента;
• переписать все используемые приложением хранимые процедуры так, чтобы они работали с правами вызывающего (это будет описано в главе 23), и создать для каждого клиента отдельную схему;
• использовать один экземпляр базы данных и одну схему со средствами тщательного контроля доступа.
Третий вариант - использование средств тщательного контроля доступа - наиболее безболезненный и простой. Можно, например, добавить в каждую таблицу, требующую защиты, столбец с идентификатором организации. Для поддержки значений в этом столбце надо использовать триггер (чтобы не пришлось изменять приложение). Триггер будет брать соответствующее значение из контекста приложения, устанавливаемого в системном триггере ON LOGON. Правила защиты будут задавать условие выбора строк только соответствующей организации. При этом можно ограничивать доступ к данным не только по идентификатору клиента, но и по любым другим необходимым условиям.
В нашей системе кадрового учета добавлять можно не только условие WHERE COMPANY = ЗНАЧЕНИЕ, но и дополнительные условия, в зависимости от того, работает ли с системой рядовой сотрудник, руководитель или сотрудник одела кадров.
Можно пойти еще дальше и добавить условия фрагментации, чтобы физически отделить данные крупных клиентов с целью обеспечения надежности хранения и высокой доступности
Как реализованы средства тщательного контроля доступа
Средства тщательного контроля доступа в Oracle 8i реализуются с помощью двух конструкций.
• Контекст приложения. Это пространство имен с соответствующим набором пар атрибут/значение. Например, в контексте OurApp можно обращаться к переменным DeptNo, Mgr и т.д. Контекст приложения всегда привязан к PL/SQL-пакету. Этот пакет - единственный метод установки значений в контексте. Чтобы установить значение атрибута DeptNo в нашем контексте OurApp, необходимо обратиться к соответствующему пакету, связанному с контекстом OurApp. Этот пакет может корректно устанавливать значения в контексте OurApp (вы сами его написали, поэтому и считается, что он будет правильно устанавливать значения в контексте). Это предотвращает установку значений в контексте приложений злонамеренными пользователями с целью получения несанкционированного доступа к информации. Читать значения в контексте приложения может кто угодно, но устанавливать их может только один пакет.
• Правила защиты. Это созданная разработчиком функция, возвращающая условие для динамического фильтрования данных при выполнении запроса. Эту функцию можно привязывать к определенной таблице или представлению, и вызываться она может для всех или только для некоторых операторов, обращающихся к таблице. Это означает, что можно задать одни правила для оператора SELECT, другие - для INSERT и третьи - для операторов UPDATE и DELETE. Обычно в этой функции используются значения атрибутов в контексте приложений для создания соответствующего условия (например, проверяется, кто зарегистрировался и что он пытается сделать и создается соответствующее подмножество строк для работы). Следует помнить, что для пользователя SYS (или INTERNAL) правила защиты никогда не применяются (соответствующие функции просто никогда не вызываются); эти пользователи всегда могут читать и изменять все данные.
Пример
Предположим, существуют правила защиты, определяющие, какие строки могут просматривать различные группы пользователей. Правила защиты позволяют разработать условие проверки, учитывающее, кто зарегистрирован и какую роль он имеет в системе. Средства тщательного контроля доступа позволяют переписать простой запрос 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_CONTEXT('OurApp', 'ptno')
)
Сотрудники отдела кадров могут видеть все записи в данном подразделении. В этом примере представлен способ получения значений переменных из контекста