Дискреционный принцип контроля доступа

Для каждой пары субъект-объект можно задать явное и недвусмысленное перечисление возможных действий субъекта (таблица 2).

Таблица 2. Допустимые действия субъекта
Действие Описание
SELECT Чтение данных объекта
INSERT Добавление новых данных в объект
DELETE Удаление некоторых/всех данных объекта
UPDATE Изменение данных объекта
ALTER Изменение физической/логической структуры базовой таблицы (изменение размеров и числа файлов таблицы, введение дополнительного столбца и т.п.)
INDEX Создание/удаление индексов на столбцы базовой таблицы
REFERENCE Запрещение/разрешение создавать ссылки на столбец (столбцы) таблицы
BACKUP Запрещение/разрешение архивирования объектов БД
ALLВсе возможные действия, т.е. все предыдущие действия вместе взятые

Разрешение тех или иных действий над объектом для какого-то субъекта – прерогатива владельца этого объекта. Только субъект-владелец объекта может (рисунок 1) предоставить некоторые/все права на этот объект другим (и даже всем) субъектам.

Схема прямой передачи доступа в СУБД ЛИНТЕР
Рисунок 1. Схема прямой передачи доступа в СУБД ЛИНТЕР

В серьезных БД, где много (тысячи) субъектов и объектов, очень сложно определять возможности (или права) каждого субъекта при работе с каждым объектом. Для упрощения этой процедуры в ЛИНТЕР реализован аппарат ролей.

Роль – это именованный набор прав на множество объектов БД. Введенные роли разбивают всех пользователей БД на группы. Те, кому присвоена (назначена) определенная роль, образуют естественную группу.

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

Итак, инициатором передачи/ограничения прав могут быть только владельцы информации, только владельцы объектов. В этом и проявляется принцип ограничения распространения прав на доступ.

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

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

Возникают естественные вопросы о том:

  1. кто может создать роль?

  2. кто имеет право назначить или отнять роль?

Схема построения ролей в СУБД ЛИНТЕР
Рисунок 2. Схема построения ролей в СУБД ЛИНТЕР

Из рисунка 2 следует, что:

  1. создать роль (и, значит стать ее владельцем) может только субъект DBA-категории;

  2. назначить/отнять роль может только ее владелец/создатель.

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

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

Итак, в СУБД ЛИНТЕР присутствуют две схемы передачи прав: напрямую и косвенно, через аппарат ролей. Причем обе эти схемы можно использовать в совокупности.

Примечания

  1. Для доступа к объекту БД с требуемой привилегией данная привилегия должна быть назначена пользователю либо с помощью механизма назначения привилегий пользователям, либо с помощью механизма назначения привилегий роли, при назначении этой роли пользователю, либо при назначении привилегии доступа к объекту PUBLIC (под PUBLIC имеется в виду команда вида "grant < привилегия > on < объект > to PUBLIC").

    То есть, для пользователя действует совокупность (объединение) всех привилегий дискреционного доступа: полученных напрямую, через роли, через PUBLIC и привилегии, которые он имеет, как владелец объектов.

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