· выполнение некоторого набора команд SQL.
Данный перечень является приблизительным, поскольку, повторимся, наборы типов доступа различны для разных СУБД.
Из сказанного можно заключить, что фактически управление доступом осуществляется в СУБД на двух уровнях.
На уровне СУБД:
· выполняется идентификация и аутентификация по имени учетной записи и паролю, соответственно;
· учетные записи наделяются основными и дополнительными разрешениями на использование сервисов СУБД.
На уровне БД:
· выполняется идентификация пользователя – проверяется, есть ли в БД пользователь, соответствующий данной учетной записи;
· пользователи наделяются правами доступа к объектам БД.
Что касается назначения прав доступа, традиционным способом здесь является назначение их субъекту «напрямую»: субъект S наделяется правами R к объекту O. Однако возможны ситуации, когда целая группа субъектов должна получить множество одинаковых прав. Чтобы избежать непосредственного назначения одинаковых прав каждому субъекту, целесообразно использовать механизм ролей.
В отличие от пользователя или учетной записи, роль – это административная единица доступа, соответствующая не одному, а целой группе субъектов. В роль можно включить один и более субъектов, при этом все права доступа, предоставленные данной роли, будут распространяться на субъекты, являющиеся ее членами.
Различают серверные роли, используемые для группирования учетных записей, и роли БД, - для группирования пользователей БД. Типичными для СУБД являются такие серверные роли, как системный администратор и администратор безопасности. Системный администратор наделяется абсолютными привилегиями по администрированию сервера, администратор безопасности – правами создания, обновления и удаления учетных записей, включения учетных записей в серверные роли, назначения прав доступа на уровне СУБД. На уровне БД также имеется администратор безопасности. Он управляет пользователями БД, ролями БД, правами доступа пользователей к объектам БД. Абсолютными правами доступа на уровне БД обладает владелец БД.
Управление правами доступа включает разрешение, запрещение и неявное отклонение доступа.
Учетная запись получает возможность выполнять разрешенные ей операции над указанным объектом, если только они не запрещены ей через членство в роли БД, т. к. запрещение имеет более высокий приоритет, чем разрешение.
Запрещение доступа пользователя (роли) к объекту гарантирует, что пользователь (роль) никакими средствами не получит возможность выполнять запрещенные операции над данным объектом. Если некоторому пользователю User1 запретить выборку данных из таблицы Table1, то он не сможет ее производить, даже если он включен в роль, которой эта выборка разрешается. Запрещение прав доступа может каскадироваться. Допустим, имеется пользователь User1, которому было дано некоторое разрешение доступа, и который передавал это разрешение пользователям User2, …, UserN. При замене этого разрешения на данный запрет с применением каскадирования запрещение будет распространено как на User1, так и на User2, …, UserN. Каскадирование не является обязательным, но в некоторых случаях может оказаться полезным.
Неявное отклонение доступа является своего рода «средним состоянием», когда отсутствует явное разрешение или явное запрещение. Пользователь, которому явно не запрещен и не разрешен доступ к объекту, может получить (или потерять) его через членство в роли. В этом заключается принципиальная разница между неявным отклонением и запрещением: запрещение не может быть преодолено через участие в роли. Неявное отклонение, как и запрещение, может каскадироваться.
Таковы общие принципы построения подсистем управления доступом в СУБД. Далее будут рассмотрены конкретные примеры их реализации.
6.1.2. Подсистема управления доступом в СУБД Microsoft SQL Server 2005
6.1.2.1. Управление учетными записями
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.