Разграничение доступа на основе ролей

В ролевой модели классическое понятие субъекта разделяется на 2 части:

1. Пользователь – человек, работающий с системой и выполняющий определенные служебные обязанности.

2. Роль – активно действующая в системе абстрактная сущность, с которой связан ограниченный, логически связанный набор привилегий, необходимый для осуществления определенной деятельности.

Ролевая модель включает 3 компонента, модель отображения:

1. Пользователь-роль

2. Привилегия-роль

3. Роль-роль

Так же вводится понятие иерархии ролей. Роль, входящая в иерархию, может включать другие роли, наследую все привилегии включаемых ролей.

Использование ролей в СУБД способствует избавлению администратора базы данных от большого объема рутинной работы в случаях, когда многим пользователям назначается одинаковый набор привилегий. В рамках СУБД Oracle под ролью понимается поименованный набор привилегий, который может быть предоставлен пользователю или другой роли.

Роль не является объектом какой-либо схемы. Описание привилегий, характерных для той или иной роли, готовится заранее; при регистрации нового пользователя администратор выполняет только предоставление пользователю привилегий конкретной роли.

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

Для работы с ролями в Oracle предусмотрены следующие системные привилегии

Create role

Grant any role – позволяет назначать любую роль любому пользователю

Drop any role – позволяет уничтожать любую роль

Alter any role – позволяет менять любую роль

Управлять ролями могут только владелец или же обладатель вышеперечисленных привилегий

Существует 3 предопределенные роли:

1. CONNECT - гость

2. RESOURCE - пользователь

3. DBA – all inclusive

>connect so/sopsw;

>create user igunmnov identified by igpsw;

>grant connect to igumnov;

>grant resource to igumnov;

Для того, чтобы пользователь мог воспользоваться привилегиями какой-либо роли, ему нужно предоставить эту роль и разрешить ее использовать.

При создании роли определяется механизм аутентификации, используемый при отображении на роль. По умолчанию аутентификацию при установке разрешения на использование роли не требуется. Однако использование конструкции identified by для роли(так же, как и для пользователя) позволяет задействовать аутентификацию при помощи пароля.

>connect so/sopsw;

>create role Sat;

>create role SUDat identified by sat_psw;

>grant select any table to Sat;

>grant select any table, delete any table, update any table to SUDat;

>grant Sat to u2;

Управление допустимостью использования ролей

В каждой сессии роли могут разрешаться или запрещаться. Управление разрешением или запрещением ролей для текущей сессии выполняется командой set role. До тех пор, пока не будет разрешено использование роли для сессии, привилегии, определенные для пользователя ролью не предоставляются. При создании пользователя можно указать, какие роли являются для него по умолчанию разрешенными, а какие – запрещенными.

>create user u1 identified by u1psw default role none;

Или

>create user u1 identified by u1psw default role all except SUDate;

Команда разрешения или запрещения ролей допускает использование модификаторов all, none и except.

В списке ролей, перечисленных при их разрешении, могут присутствовать только роли, явно назначаемые пользователю. Указание ролей, которые назначены через другие роли, не допускается.

>connect u2/u2psw;

>set role none;

>select *from u1.Tab1;



>set role Sat;

> select *from u1.Tab1;



>connect so/sopsw;

>grant SUDat to u2;

>connect u2/u2psw;

>set role all;

 - запароленная роль

>set role SUDat identified by sat_psw;

>update …

>delete …



===============

>connect so/sopsw;

>revoke delete any table from SUDat;

>grant insert any table to SUDat;

>revoke s.a.t. from u2; - нельзя отнимать привилегию, назначенную через роль.

>revoke s.a.t. from Sat; \/

>revoke s.a.t. fromSUDat; \/