ватель с учетной записью TestAccount право на выполнение оператора CREATE. Зарегистрируйтесь с помощью учетной записи TestAccount, а затем выполните следующую команду (напомним, что для выполнения этого кода необходимо использовать доменное имя ARISTOTLE): USE NorthwindSecure

CREATE TABLE TestCreate {

Coll int Primary Key

Как и следовало ожидать, получим сообщение об ошибке: Server: Msg 262, Level 14, State 1, Line 2

CREATE TABLE permission denied, database NorthwindSecure, owner dbo.

Теперь зарегистрируйтесь в СУБД SQL Server, используя учетную запись sa (или другую учетную запись с правами пользователя dbo базы данных NorthwindSecure). Затем выполните команду, предназначенную для предоставления необходимых разрешений:

GRANT CREATE TABLE TO [ARISTOTLE\TestAccount]

Должно быть получено подтверждение, что команда выполнена успешно. После этого попытайтесь снова вызвать на выполнение оператор CREATE (не забудьте еще раз зарегистрироваться с использованием учетной записи TestAccount): USE NorthwindSecure

CREATE TABLE TestCreate {

Coll int Primary Key

Ha этот раз попытка выполнения команды должна закончиться успешно. Команды DENY и REVOKE действуют по такому же принципу, как и при определении разрешений на уровне объектов.

Роли сервера и базы данных

До выхода версии 7.0 в СУБД SQL Server поддерживалось понятие группы. Под этим понятием подразумевалась совокупность прав пользователя, которые можно было присваивать одновременно, назначая пользователя в соответствующую группу. Такой подход к определению группы отличался от способа организации групп в операционной системе Windows, согласно которому пользователь мог принадлежать больше чем к одной группе Windows, благодаря чему обеспечивалась возможность применять по отношению к пользователю различные сочетания прав пользователей этих групп. В SQL Server 6.5 (и более ранних версиях) пользователю было разрешено входить в состав только одной группы в расчете на каждую базу данных.

В связи с тем, что в версиях, предшествующих SQL Server 7.0, применялся такой подход к группированию прав доступа, обнаруживались три недостатка.

Наряду с правами доступа на уровне группы часто приходилось дополнительно задавать права на уровне пользователя.

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

Многие администраторы для упрощения своей работы назначали больше прав доступа, чем требовалось.

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

С выходом версии SQL Server 7.0 произошли весьма значительные изменения. Начиная с этой версии, пользователи относятся не к группе, а к роли. На первый взгляд может показаться, что по своему определению понятие роли ничем не отличается от понятия группы.

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

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

Роли подразделяются на две категории:

роли сервера;

роли базы данных.

Кроме того, ниже описано еще одно соглагиение, касающееся роли, которое именуется в терминологии Microsoft ролью приложения (хотя, по мнению автора, это название не совсем приемлемо). Роль приложения представляет собой специальный способ, позволяющий связать пользоватеш с помощью псевдонима с другим набором прав. Роль приложения не присваивается пользователю, а предоставляет способ назначить приложению другой набор прав, полученный от пользователя. По этой причине роли приложения не совсем соответствуют определению понятия роли в полном смысле этого слова.

Перечень ролей сервера ограничивается теми ролями, которые уже встроены в СУБД SQL Server ко времени ее передачи в эксплуатацию. Роли сервера в основном предназначены для сопровождения системы, а также предоставления возможностей выполнять некоторые действия, не связанные с конкретной базой данных, такие как создание учетных записей и определение связанных серверов.

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

Ниже роли сервера и базы данных рассматриваются отдельно.

Роли сервера

Все имеющиеся роли сервера являются фиксированными и доступны с самого начала эксплуатации СУБД SQL Server; иными словами, все роли сервера, которые когда-либо приходится использовать, определены со времени инсталляции программного обеспечения SQL Server. Основные роли сервера описаны в табл. 22.6.

Предусмотрена возможность применять различные сочетания ролей, описанных в табл. 22.6, присваивая их отдельным пользователям, ответственным за выполнение административных функций на конкретном сервере. Вообще говоря, по мнению автора, роли, функции которых выходят за рамки ролей sysadmin и securityadmin, целесообразно применять лишь на предприятиях с очень крупными базами данных, но все равно весьма удобно иметь в своем распоряжении столь широкий набор ролей.

Таблица 22.6. Основные роли сервера

Роль

Описание

sysadmin Данная роль позволяет выполнять в СУБД SQL Server любые действия.

Любой пользователь, которому назначена роль sysadmin, получает права пользователя sa по отношению к определенному серверу. Благодаря созданию этой роли сервера корпорация Microsoft немедленно получила возможность исключить необходимость в использовании учетной записи sa; в действительности в документации Books Online указано, что со временем следует отказаться от использования учетной записи sa.

Следует отметить, что членам группы Administrators операционной системы Windows автоматически присваивается роль sysadmin в СУБД SQL Sen/er. Это означает, что любой пользователь, являющийся членом группы Administrators на том компьютере, где эксплуатируется сервер базы данных, получает также доступ к данным базы данных на уровне пользователя sa. В случае необходимости членов группы Administrators операционной системы Windows можно удалить из числа владельцев роли sysadmin, чтобы исключить возможное нарушение защиты данных

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

setupadmin Офаничивается управлением связанными серверами и процедурами запуска

securityadmin Данная роль является очень удобной, поскольку может присваиваться учетным записям, созданным для управления учетными записями, чтения журналов регистрации ошибок и назначения прав доступа на уровне оператора CREATE DATABASE. Во МНОГИХ отношениях роль securityadmin соответствует классическим функциям оператора системы, поскольку она позволяет выполнять основную часть повседневных обязанностей и вместе с тем не предоставляет такого рода глобальный доступ, который имел бы всемогущий суперпользователь

processadmin Предоставляет возможность управлять процессами, выполняющимися в СУБД SQL Server; именно эта роль позволяет в случае необходимости уничтожать процессы, которые функционируют в течение слишком продолжительного времени

dbcreator Ограничивается созданием и модификацией баз данных

diskadmin Позволяет управлять файлами на диске (указывать, какие файлы назначены в те или иные файловые группы, присоединять и отсоединять базы данных и т.д.)