GRANT, которые необходимо выполнить для передачи пользователю Ivanov права на выполнение хранимой процедуры FactorialSet:

GRANT EXECUTE ON PROCEDURE FactorialSet TO Ivanov; Если пользователь Ivanov попытается выполнить хранимую процедуру FactorialSet, то эта попытка потерпит неудачу, т.к. эта процедура вызывает процедуру Factorial. Таким образом, процедуре FactorialSet требуется привилегия на выполнение хранимой процедуры Factorial, которую SYSDBA может предоставить, используя следующий запрос:

GRANT EXECUTE ON PROCEDURE Factorial TO PROCEDURE FactorialSet;. Но и в этом случае пользователь Ivanov не сможет выполнить процедуру FactorialSet, т.к. процедура Factorial использует рекурсивный вызов самой себя и при этом производится проверка на наличие привилегий доступа при вызове процедуры Factorial. Таким образом, процедуре Factorial требуется привилегия EXECUTE на процедуру Factorial:

GRANT EXECUTE ON PROCEDURE Factorial TO PROCEDURE Factorial;. Теперь осталась одна проблема, не позволяющая пользователю Ivanov выполнить процедуру FactorialSet. Дело в том, что процедура FactorialSet (созданная SYSDBA) не имеет доступа на вставку в таблицу Ftable. Следующий запрос GRANT предоставляет необходимую привилегию процедуре FactorialSet:

GRANT INSERT ON Ftable TO PROCEDURE FactorialSet;.

Таким образом, был рассмотрен один вариант передачи привилегий. Можно также перечисленные выше привилегии передать непосредственно пользователю Ivanov следующим образом:

GRANT INSERT ON Ftable TO Ivanov;

GRANT EXECUTE ON PROCEDURE Factorial TO Ivanov;

GRANT EXECUTE ON PROCEDURE FactorialSet TO Ivanov;, но это является крайне нежелательным с точки зрения безопасности.

Следует отметить, что в IBExpert для передачи привилегий можно использовать Менеджер прав , который упрощает процедуру наделения различными правами пользователей и других объектов БД, избавляя пользователя от непосредственного написания SQL-запросов.

7.1.3. SQL роли

Концепцию планирования безопасности можно представить следующим образом. Администратор SYSDBA в соответствии с информационной моделью создает БД. Затем с помощью запроса GRANT передает привилегии определенным пользователям в соответствии с их уровнем доступа к данным.

Пусть, например, пользователи 1, 2 и 3 последовательно получили привилегию SELECT на таблицу А и привилегию DELETE на таблицу В (рис. 7.1).

Рис. 7.1. Пример передачи привилегий

Роль представляет собой метод обеспечения безопасности на уровне групп привилегий. Для объединения привилегий SELECT и DELETE в данном примере используем понятие роль. На рис. 7.2 представлена иллюстрация предыдущего примера, но при использовании механизма роли.

Можно сказать, что роль выступает в качестве объекта БД, концентрирующего в себе заданные привилегии доступа к определенным объектам БД.

Рис. 7.2. Пример передачи привилегий при использовании роли

Роль создается запросом CREATE ROLE, а удаляется запросом DROP ROLE. Эти запросы имеют следующий синтаксис:

CREATE ROLE имя роли; DROP ROLE имя роли;.

Реализация механизма использования роли для передачи привилегий состоит из следующих четырех шагов:

1) создать роль, используя следующий запрос: CREATE ROLE имя роли;.

2) передать этой роли одну или более привилегий, используя следующий запрос:

GRANT <привилегии> TO имя роли;.

3) передать право на использование этой роли одному или более пользователям с помощью следующего запроса:

GRANT имя роли TO <список пользователей>;. При этом роль может быть передана с указанием предложения WITH ADMIN OPTION, которое означает, что пользователи, обладающие данной ролью, могут передавать право на использование этой роли другим пользователям;

4) при подключении к БД пользователь, обладающий какой-либо ролью (ролями), должен указать имя этой роли.

Например, чтобы передать пользователю Petrov привилегии SELECT, INSERT и DELETE соответственно на таблицы Abonent, Request и PaySumma, используя роль PetrovROLE, объединяющую в себе перечисленные выше привилегии доступа, необходимо применить следующие запросы:

CREATE ROLE Petrov ROLE;

GRANT SELECT ON Abonent TO Petrov ROLE; GRANT INSERT ON Request TO Petrov ROLE; GRANT DELETE ON PaySumma TO Petrov ROLE; GRANT Petrov ROLE TO Petrov;.

Для передачи пользователю Petrov права на передачу роли PetrovROLE другим пользователям необходимо использовать следующий запрос: GRANT Petrov ROLE TO Petrov WITH ADMIN OPTION;.

Существуют контекстные переменные для получения имени пользователя и имени роли, под которыми текущий пользователь подключился к БД [18]. Это переменные CURRENTUSER (тип данных VARCHAR (128), можно использовать переменную USER, описанную ранее) и CURRENTROLE (тип данных VARCHAR (31)). Переменная CURRENTROLE возвращает пустую строку, если текущее соединение не использовало роль.

7.1.4. Отмена привилегий

Для отмены привилегий используется запрос REVOKE, имеющий следующий синтаксис:

REVOKE {[GRANT OPTION FOR] <привилегии>

ON [TABLE] {базовая таблица представление}

FROM {<объект> <список пользователей> }} EXECUTE ON PROCEDURE имя процедуры

FROM {<объект> <список пользователей>}

[ADMIN OPTION FOR] <список ролей>

FROM {PUBLIC <список пользователей>};,