Детальный контроль доступа и контексты приложения. Часть 1

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

Примером детального контроля доступа может служить политика безопасности, которая определяет, какие строки могут быть доступны различным группам пользователей. Политика безопасности формирует предикат, вид которого зависит от соединенного с базой пользователя и группы, к которой он относится. Детальный контроль доступа позволяет при вводе запроса "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’, ‘Deptno’ ) )

Почему используется эта возможность

Есть много причин, чтобы использовать этот механизм. Наиболее распространенные из них:

• Легко поддерживается. Детальный контроль доступа позволяет иметь только одну таблицу и одну хранимую управляющую процедуру, которые заменят использование множества представлений. Создание множества представлений обычно приводит к увеличению числа объектов базы данных, так как для каждой группы пользователей требуется создание отдельного представления. Например, в описанном выше примере со служащими, менеджерами и контролерами в обычной системе необходимо создать 3 представления базы данных. Если потребуется еще одна группа пользователей, то придется добавить еще один набор представлений, которым надо будет управлять и поддерживать. Если политика безопасности изменится (то есть, потребуется, чтобы менеджеры видели не только своих непосредственных подчиненных, но и на 2 уровня ниже), необходимо будет пересоздать представления базы данных, после чего все объекты, ссылающихся на эти представления, станут недействительными.

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

• Запрет на соединение с базой данных от имени обобщенных пользователей. Благодаря детальному контролю доступа каждый пользователь должен соединяться с базой данных под своим именем. В этом случае обеспечивается полная подотчетность - можно отслеживать действия на уровне пользователя. Раньше многие приложения при работе с различными представлениями данных для различных пользователей должны были применять обобщенных пользователей базы данных, соответственно выбираемым данным. Например, в вышеописанном случае служащий/менеджер/контролер в приложении должно быть создано три учетных записи. Каждый служащий должен использовать учетную запись "Служащий". Каждый менеджер должен использовать учетную запись "Менеджер". Каждый контролер должен использовать учетную запись "Контролер". Это делает невозможным учитывать действия на уровне истинных пользователей

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

• Применение развитых средств разработки приложения. Во многих средах политика безопасности по началу еще должным образом не определена и через некоторое время может измениться. Если происходит слияние компаний или другие структурные перемены или вводятся правила секретности, то политику безопасности необходимо изменить. Благодаря тому, что управление доступом осуществляется на уровне, близком к данным, можно создать условия для развития приложения с минимальным влиянием, и на него, и на средства разработки. Это является одной из причин для того, чтобы перейти к автоматическому использованию как новой логики, так и всех приложений и инструментов, позволяющих осуществлять доступ к базе данных со встроенной новой логикой.

Способы использования этой возможности

В Oracle8i существует два типа детального контроля доступа:

• "Контекст" приложения. Это пространство имен с набором пар соответствующих параметров переменная/значение. Например, в контексте, называемом ‘OurApp’, можно получить доступ к переменным ‘DeptNo’, ‘Mgr’ и так далее. Контексты приложения всегда связываются с некоторым PL/SQL-пакетом. Единственный способ присваивания значений контекста - это вызов пакета. Например, для получения переменной ‘DeptNo’ и установки ее значения в контексте ‘OurApp’ необходимо вызвать специальный пакет, связанный с контекстом ‘OurApp’. Этот пакет гарантирует корректную установку значений контекста ‘OurApp’ (вы сами так написали, поэтому корректная установка контекста гарантируется). В этом случае предотвращается установка значений контекста приложения злоумышленниками, которые в противном случае могли бы получить доступ к той информации, доступа к которой у них быть не должно. Любой пользователь может читать значения контекста приложения, но установить их может только пакет.
• Политика безопасности. Политика безопасности представляет собой просто функцию, построенную так, чтобы во время выполнения запроса она могла возвращать предикат для динамической фильтрации данных. Эта функция обычно использует значения контекста приложения для формирования и возврата корректного предиката (т.е. она просматривает, ‘кто’ присоединен к базе данных, ‘что’ он собирается сделать, и проверяет, есть ли у него привилегии для выполнения этих операций). Следует обратить внимание, что по отношению к пользователю SYS (или INTERNAL) никогда не используется политика безопасности, эти пользователи могут видеть все данные.

Для того, чтобы воспользоваться этой возможностью, разработчик, кроме стандартных ролей connect и resource, должен иметь следующие привилегии:

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

OurApp - это имя контекста, а Our_Context_Pkg - это PL/SQL-пакет, через который устанавливаются значения контекста. Возможность использования контекстов приложения для детального контроля доступа имеет большое значение по двум причинам:

Пример 1. Реализация политики безопасности

Если требуется, чтобы политика безопасности позволяла пользователю, не являющемуся RLS_ADMIN, видеть только такие строки, "владельцем" которых он является, то необходимо выполнить команду:\

Функция создана.

Предикат "where owner = USER" будет динамически добавляться ко всем запросам по таблице, с которой связана эта функция, что значительно уменьшает количество строк, доступных пользователю. Предикат NULL (пусто) возвращается только в том случае, когда на данный момент к базе данных присоединен пользователь RLS_ADMIN. Пустой возвращаемый предикат выглядит как "1=1" или "TRUE".

Для того, чтобы связать эту функцию с таблицей, необходимо использовать PL/SQL-процедуру "dbms_rls.add_policy". Например, имеется следующая таблица:

Теперь все DML-предложения, относящиеся к таблице EMP, будут иметь предикат, возвращаемый связанной функцией my_security_function, независимо от источника, вызвавшего DML-операцию (т.е. независимо приложения, получающего доступ к данным). Посмотрим на это в действии:

Итак, полученный результат показывает, что строки отфильтрованы надлежащим образом - текущий пользователь RLS может видеть только свои строки - он является их владельцем. Строки, владельцем которых является SCOTT, стали невидимы. Присоединимся теперь как учетная запись RLS_ADMIN:

Результат показывает, что учетная запись RLS_ADMIN может видеть все данные, какие пожелает. Присоединимся опять учетной записью RLS и посмотрим, что произойдет при попытке создания данных, которые нельзя 'увидеть' (пользователь не являемся их владельцем):

по аналогии с созданием представления с включенной возможностью "CHECK OPTION". Такая политика позволяет создавать только те данные, которые можно выбрать. По умолчанию можно создавать данные, которые выбрать нельзя.

Часть 2