2. Добавление новых пользователей. Удаление идентификаторов и пользователей

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

Синтаксис процедуры SP_ADDUSER:

SP_ADDUSER [@loginame =] ‘идентификтор_пользова-теля’

[, [@name_in_db =] ‘имя__пользователя’

[, [@rolename =] 'имя_роли']]

Параметры имеют следующий смысл:

• идентификатор_пользователя - это имя входа в сис­тему, которое будет добавлено к базе данных в качестве пользо­вателя Неверные идентифика­торы добавлены не будут.

• имя__пользователя - псевдоним, который идентифи­катор будет иметь в этой базе данных. Эта функция позволяет с помощью одного и того же идентификатора присоединяться к различным базам данных на одном и том же сервере и иметь раз­личные имена в каждой из них.

• имя_роли — дает возможность указания группы поль­зователей, к которой будет принадлежать данный идентифи­катор. Применение роли упрощает поддержку безопасности, т к. вместо предоставления прав доступа от­дельным пользователям эти права предоставляются всей роли. Все ее члены будут иметь права, предоставленные этой роли.

Пример добавления пользователя в теку­щую активную базe данных:

SP_ADDUSER 'Ronald'

В главном окне SQL Server Enterprise Manager есть кнопка Delete, располо­женная на панели управления. Для удале­ния любого пользователя или иден­тификатора, которым вы больше не хотите предоставлять доступ к базе дан­ных или сер­веру, следует нажать эту кнопку.

Для удаления идентификатора или пользователя в базе данных следует применять системные процедуры SP_DROPLOGIN и SP_DROPUSER соответственно.

Их синтаксис очень сходен, особенно когда имя пользова­теля базы данных совпадает с именем идентификатора:

SP_DROPLOGIN идентификатор

и

SP_DROPUSER имя_пользователя

3. Создание ролей. Удаление ролей

Роль (Role) — это новое понятие, появившееся в SQL Server 7.0. Говоря простым и понятным языком, роль — это именованный набор прав в рам­ках сервера или конкретной базы данных. В каком-то смысле роли похожи на группы Windows NT. Права доступа предоставляются всем членам роли одновре­менно. Это более практичный и безопасный подход в сравнении с предоставлением прав специального доступа к каждому набору таблиц ин­дивидуальным пользователям.

При установке SQL Server в сервере появляется несколько стандартных ро­лей. Все пользователи, создаваемые в системе, будут принадлежать к этой группe и иметь все установленные для нее права доступа.

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

Помимо стандартных ролей на уровне сервера можно соз­давать сколько угодно ролей для конкретной базы данных. Это значит, что когда вы опре­деляете роль для одной базы данных, другие базы недоступны для этой ро­ли. Для каждой базы данных роль должна быть создана заново. Обойти это ограничение можно с помощью модели базы данных (Model database). Соз­дайте в этой базе данных необходимые роли. После этого, когда модель ба­зы данных будет использована в качестве образца для новой базы, все соз­данные в ней роли будут автоматически на­следоваться.

Роль Public - это специальная роль на уровне базы данных, к которой приписаны все пользователи, зарегистрированные в базе данных. Ей придается определен­ный набор прав, которые передаются лю­бому пользователю, приписанному к базе данных. Все пользова­тели, роли и группы Windows NT попадают в нее автоматически. Она присутствует во всех пользовательских базах дан­ных, а также в Master, Msdb, Tempdb и Model. Уничтожить эту роль нельзя.

При подключении пользователя к серверу oн автоматиче­ски получает некоторый минимальный набор прав, унаследован­ный от этой роли. Этот набор достаточно ограничен и в основном связан с возможностью просмотра содержимого таб­лиц и выполнения некоторых хранимых процедур для получения информации из базы данных Master и пользовательских баз дан­ных.

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

SQL Server Enterprise Manager позволяет легко добав­лять роли к базам данных. Активизируйте SQL Server Enterprise Manager и раскройте в дереве сервера базу данных, в которой надо создать роль. Щелкните правой кнопкой мыши на папке Da­tabase Roles и в контекстном меню выберите команду New Database Role. Появится диалоговое окно Database Role Properties - New Role. Переключатель Database Role Type позволяет выбирать тип создаваемой роли. SQL Server поддерживает два типа ролей базы данных:

• включающие пользователей;

• роли для приложения.

Установив переключатель в положение Standard Role, мы получаем доступ к списку User и кнопкам Add и Remove, с по­мощью которых можно увидеть пользователей, приписанных к роли, а также добавлять и/или удалять поль­зователей из роли. При нажатии кнопки Add открывается диалоговое окно Add Role Members, где представлены пользователи, зарегистрированные в системе. Удалить пользователя из роли еще проще — просто вы­делите его и нажмите кнопку Remove.

Серверу совершенно безразлично, кто именно — пользо­ватель или прило­жение — обращается к данным. Но в некоторых случаях стандартные роли не позволяют создавать защищенное окружение, которое может потребо­ваться для определенного приложения. В этом случае на помощь приходит роль для прило­жения, которая исключает неавторизованный доступ к данным вне рамок этого приложения. Такая роль имеет несколько прин­ципиальных отличий от стандартных ролей:

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

• Для активизации роли приложение должно передать серверу только па­роль.

• При активизации роли пользователь до момента вы­хода из приложения обладает только теми правами, которые опи­саны в этой роли, т.е. на время работы с приложением лишается всех своих прав.

Под­ключаясь к серверу, пользова­тель сразу же получает весь набор прав, ассоциированных с ним и с теми ролями, к которым он приписан. Совсем другая картина при подключении посредством приложения. В этом случае подключение возможно с исполь­зо­ванием любого разрешенного идентификатора. Однако сразу же за этим клиентское приложение должно выполнить хранимую процедуру SP_SETAPPROLE, чтобы активизировать связанные с ролью права:

SP_SETAPPROLE { ‘имя_роли’, ‘пароль’}

Эта процедура может быть выполнена только как само­стоятельная команда, т е. не может входить в другую хранимую процедуру или пользовательскою транзакцию. Несколько заме­чаний относительно роли для приложения:

• Приложение обязано передать пароль для активизации роли выпол­нить хранимую процедуру SP_SETAPPROLE.

• После активизации роли ее нельзя отключить от теку­щей базы данных до выхода пользователя из SQL Server.

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

Помимо системной хранимой процедуры SP_SETAPPROLE, в SQL Server опре­делены еще несколько специальных процедур:

• SP_ADDAPPROLE — создает новую роль для прило­жения в текущей базе данных.

• SP_DROPAPPROLE — удаляет существующую роль для приложения из те­кущей базы данных.

• SP_APPROLEPASSOWRD — изменяет пароль роли для приложения в текущей базе данных.

Microsoft не разрешает сразу же назначать права для соз­даваемой роли (кнопка Permissions заблокирована). Тем не ме­нее, их необходимо определить. Для этого после создания роли щелкните на ней пра­вой кнопкой мыши и в контекстном меню выберите команду Properties. В результате на экране появится диало­говое окно Database Role Properties, в котором кнопка Permis­sions теперь доступна.

Процесс удаления роли с помощью SQL Server Enterprise Man­ager состоит практически из тех же самых шагов, что и процесс ее создания. Для удаления любой ненужной роли щелкните на ней правой кнопкой мыши и в контекст­ном меню выберите ко­манду Delete. Поскольку возможны всякие случайно­сти, SQL Server запросит подтверждение на удаление роли. Удалить роль вместе с ее ассоциированными пользовате­лями нельзя, сначала надо удалить всех входящих в нее пользова­телей. Не все роли можно удалить. Например, для ролей Public или db_owner в контекстном меню вообще отсутствует команда Delete.

Удаление роли можно выполнить также с помощью инст­рукций Transact-SQL. Правда, здесь для удаления стандартной роли и роли для приложения должны использоваться различные хранимые процедуры:

SP_DROPROLE [@rolename =] ‘роль’

SP_DROPAPPROLE [@rolename ="] 'роль'.