Управление пользователями базы данных с помощью среды Management Studio. Создаем роли базы данных

Всем привет! Сейчас мы с Вами рассмотрим примеры создания и удаления пользователей в СУБД Microsoft SQL Server как с использованием инструкций Transact-SQL, так и с использованием среды Management Studio.

Процесс создания пользователей в MS SQL Server включает два этапа:

1. Создание имени входа на SQL Server. Данное имя необходимо, для того чтобы предоставить пользователю возможность подключиться к экземпляру SQL Server;
2. Создание пользователя базы данных. В данном случае мы уже предоставляем пользователю разрешения на объекты базы данных.

Примечание! В качестве SQL сервера у меня для примера будет выступать версия Microsoft SQL Server 2012 Express . На данном SQL сервере создана тестовая база данных Test.

Создание имени входа на MS SQL Server

Прежде чем приступать к созданию имени входа на SQL сервер необходимо определиться с методом аутентификации. Существует два варианта:

1. Проверка подлинности Windows – это когда имя входа может идентифицировать пользователя как учетную запись Windows или как члена группы Windows (в том числе и доменные учетные записи, и группы );
2. Проверка подлинности SQL Server . В данном случае имя входа существует только в SQL Server.

Давайте рассмотрим пару примеров создания имени входа на SQL сервер. Сначала мы это сделаем с помощью среды SQL Server Management Studio , а затем с использованием языка Transact-SQL.

Создание имени входа с использованием среды SQL Server Management Studio

Запускаем Management Studio, затем в обозревателе объектов находим пункт «Безопасность », раскрываем его плюсиком, кликаем правой кнопкой мыши по пункту «Имена входа » и выбираем пункт «Создать имя входа ».

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

Затем нажимаем на кнопку «ОК », после чего будет создано имя входа TestLogin. По умолчанию данное имя входа будет включено, и оно будет иметь права роли сервера «public».

Создание имени входа с использованием языка Transact-SQL

Для того чтобы создать имя входа на языке Transact-SQL необходимо в Management Studio открыть редактор запросов и выполнить следующую инструкцию (она делает ровно то же самое, что и наши действия выше в графическом интерфейсе Management Studio ).

CREATE LOGIN WITH PASSWORD=N"Pa$$w0rd", DEFAULT_DATABASE=, DEFAULT_LANGUAGE=[русский], CHECK_EXPIRATION=OFF, CHECK_POLICY=ON GO

Другими словами для создания имени входа в SQL сервер используется инструкция CREATE LOGIN .

Создание имени входа на SQL Server с проверкой подлинности Windows

Для того чтобы создать имя входа с проверкой подлинности Windows выполните следующую SQL инструкцию:

CREATE LOGIN FROM WINDOWS WITH DEFAULT_DATABASE=, DEFAULT_LANGUAGE=[русский]; GO

• ComputerName\NameUser – это Имя компьютера\Имя пользователя;
• FROM WINDOWS – указывает, что будет использоваться проверка подлинности Windows;
• WITH DEFAULT_DATABASE= – база данных по умолчанию;
• DEFAULT_LANGUAGE=[русский] – язык по умолчанию.

Отключение и включение имен входа в MS SQL Server

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

Отключение ALTER LOGIN TestLogin DISABLE; --Включение ALTER LOGIN TestLogin ENABLE;

Создание пользователя базы данных в MS SQL Server

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

Давайте создадим пользователя TestLogin также двумя способами, т.е. с помощью Management Studio и языка T-SQL .

Создание пользователя базы данных с помощью Management Studio

Открываем Management Studio, в обозревателе объектов находим нужную базу данных и открываем ее плюсиком. Затем также плюсиком открываем пункт «Безопасность » и кликаем по папке «Пользователи » правой кнопкой мыши и выбираем пункт «Создать пользователя ».

Далее вводим имя пользователя и имя входа, которое соответствует данному пользователю (в моем случае имена совпадают ), а также указываем схему по умолчанию (если не указывать, то присвоится схема dbo ).

Также давайте сразу отметим роль базы данных, которую будет иметь данный пользователь. На странице «Членство » я поставил галочку напротив роли db_datareader , т.е. пользователь будет иметь права на чтение данных из пользовательских таблиц. Жмем «ОК ».

Создание пользователя базы данных с помощью языка Transact-SQL

Следующая инструкция T-SQL создает пользователя базы данных (схема по умолчанию dbo ) и назначает ему роль db_datareader, т.е. делает то же самое, что и мы чуть ранее в графическом интерфейсе Management Studio.

USE Test GO CREATE USER FOR LOGIN WITH DEFAULT_SCHEMA= GO ALTER ROLE ADD MEMBER ; GO

Таким образом, инструкция CREATE USER используется для создания пользователя базы данных.

Удаление пользователя базы данных и имени входа в MS SQL Server

Для того чтобы удалить пользователя базы данных можно написать простую SQL инструкцию, например

DROP USER Testlogin;

Или использовать графический инструмент Management Studio, т.е. в обозревателе объектов, в нужной базе данных выбираем «Безопасность -> Пользователи » и щелкаем правой кнопкой мыши по пользователю, которого необходимо удалить, и выбираем «Удалить ».

Примечание! Пользователи, которые владеют защищаемыми объектами, не могут быть удалены из базы данных.

Для удаления имени входа можно также использовать и графический инструмент Management Studio (т.е. «Безопасность -> Имена входа» правой кнопкой мыши по имени, а затем нажать на пункт «Удалить» ) и инструкцию Transact-SQL т.е.

DROP LOGIN TestLogin;

Примечание! Удалить текущее имя входа нельзя, как и имя входа, владеющее любым защищаемым объектом уровня сервера или заданием агента SQL Server. Также имя входа нельзя удалить, если в данный момент пользователь подключен к системе. Удалить имя входа без удаления сопоставленного пользователя базы данных можно, но это приведет к появлению пользователей, утративших связь с учетными записями.

На этом у меня все надеюсь, материал был Вам полезен, пока!

В данной статье я расскажу о том как добавлять новые или уже существующие базы данных на сервер «1С:Предприятия» 8.3 (для других версий платформы — 8.1 и 8.2 действия аналогичны). Будут рассмотрены варианты добавления информационной базы как из , так и через программу администрирования серверов «1С:Предприятия» (в ОС семейства Windows). А также затронуты некоторые вопросы администрирования информационных баз в кластере серверов «1С:Предприятия».

1. Добавление информационной базы из окна запуска «1С:Предприятие»

Создадим новую базу данных на сервере «1С:Предприятия» из типовой конфигурации. Для этого запустим «1С:Предприятие» и в окне запуска нажмем «Добавить… » для добавления информационной базы.

Запуститься мастер добавления информационной базы, выберем пункт «Создание новый информационной базы » установив соответствующий переключатель и нажмем «Далее ».

В списке установленных шаблонов конфигураций выберем необходимый нам шаблон и снова нажмем «Далее ».

Введем имя базы данных, как она будет отображаться в списке информационных баз, тип расположения укажем «На сервере 1С:Предприятие » и нажимаем «Далее ».

На следующей странице необходимо указать параметры создаваемой информационной базы, а именно:

(В данном примере параметры выбраны в соответствии с параметрами установки сервера «1С:Предприятия», принятыми в статье )

• Имя кластера серверов 1С:Предприятия — как правило, совпадает с сетевым именем компьютера, где установлен сервер «1С:Предприятия» (центральный кластер сервера);
• Имя создаваемой базы в кластере — имя по которому будет происходить обращаться к информационной базе. Должно быть уникальным в пределах данного кластера;
• Защищенное соединение — по умолчанию отключаем;
• Тип СУБД на которой будет храниться база данных — в данном примере MS SQL Server;
• Имя сервера базы данных — как правило, состоит из сетевого именем компьютера, где установлен сервер баз данных и имени экземпляра сервера (если есть), разделенными знаком «\»;
• Имя базы данных на сервере баз данных — для удобства будем придерживаться правила, что имя базы данных должно совпадать с именем информационной базы в кластере. Кроме того, в случае использования MS SQL Server, первый символ в имени базы данных может быть только буквой латинского алфавита или символом «_», последующие символы могут быть только буковой латинского алфавита, цифрой или символами «_» и «&», имя должно быть уникальным в пределах данного экземпляра сервера баз данных и не превышать 63 символов. Если база данных уже существует на сервере, будет использоваться текущая база, если нет и установлен флаг «Создать базу данных в случае ее отсутствия », произойдет добавление новой базы на сервер баз данных.
• Пользователь базы данных — пользователь СУБД, который станет владельцем базы на сервере в случае создания новой базы данных или имеющий права для работы с существующей;
• Пароль пользователя — пароль пользователя от лица которого будет осуществляться доступ к базе данных;
• Смещение дат — 0 или 2000. Данный параметр определяет число лет, которое будет прибавляться к датам при их сохранении в базе данных Microsoft SQL Server и вычитаться при их извлечении. Дело в том, что тип DATATIME, используемый Microsoft SQL Server, позволяет хранить даты в диапазоне с 1 января 1753 года по 31 декабря 9999 года. Если при работе с информационной базой может возникнуть необходимость хранения дат, предшествующих нижней границе данного диапазона, смещение дат следует выбрать 2000. Кроме того, если в прикладном решении используются регистры накопления или регистры бухгалтерии (а скорее всего так оно и будет) также в «поле смещение» дат необходимо установить значение 2000.
• Установить блокировку регламентных заданий — установка флага позволяет запретить выполнения регламентных заданий на сервере для данной информационной базы. Следует устанавливать в случае создания тестовых информационных баз, где выполнение регламентных заданий не несет никакой практической нагрузки.

Установив все параметры информационной базы нажимаем «Далее ».

Ну и наконец, указываем параметры запуска для создаваемой базы и нажимаем «Готово » для запуска процесса создания новой информационной базы. При этом будет создана новая информационная база на на сервере «1С:Предприятия», в случае необходимости, создана новая база данных на сервере баз данных, а также произойдет загрузка данных из шаблона конфигурации.

Если все вышеперечисленные действия завершились успешно, мастер завершит свою работу, а мы увидим только что созданную базу и в списке информационных баз в окне запуска «1С:Предприятие».

2. Добавление информационной базы из консоли администрирования серверов «1С:Предприятия»

Теперь добавим еще одну информационную базу в кластер серверов, но уже через оснастку «Администрирование серверов 1С:Предприятия » (предварительно ). Найти ее можно:

Ну и в любом случае оснастку можно запустить выполнив файл «1CV8 Servers.msc » располагающийся в каталоге установки «1С:Предприятие» в подкаталоге «common ».

Если оснастка «» запускается на том же самом компьютере, где установлен сервер «1С:Предприятия», то в дереве слева, в ветке с сетевым именем текущего компьютера, мы должны увидеть данный кластер серверов под названием «Локальный кластер ». Раскрыв вкладку «Информационные базы » увидим все информационные базы в данном кластере серверов (например базу данных созданную через окно запуска «1С:Предприятие» на предыдущем шаге). Для добавления новой информационной базы кликнем правой кнопкой мыши по данной вкладке, в контекстном меню выберем «Создать » — «Информационная база ».

Откроется окно параметров создаваемой информационной базы. Список параметров тот же самый, что был описан выше в п.1 данной инструкции. Заполнив все параметры нажимаем «ОК » для запуска процесса создания новой информационной базы. При этом будет создана новая информационная база на на сервере «1С:Предприятия» и, в случае необходимости, создана новая база данных на сервере баз данных.

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

А если зайти в программу «Среда SQL Server Management Studio » и подключиться к текущему экземпляру MS SQL Server, можно увидеть созданные на предыдущих шагах базы данных.

3. Свойства информационной базы

Чтобы просмотреть или изменить параметры конкретной информационной базы необходимо в оснастке «Администрирование серверов 1С Предприятия », в списке информационных баз кликнуть по ней правой кнопкой мыши и в контекстном меню выбрать «Свойства ». Для аутентификации в консоли администрирования необходимо использовать администраторов в соответствующих информационных базах. Другими словами данная проверка аналогична аутентификации при подключении к информационной базе через клиента «1С:Предприятие».

Как видно, к списку уже знакомых нам параметров добавились:

• Блокировка начала сеансов включена — флаг, позволяющий включить блокировку начала сеансов с информационной базой, если флаг установлен, то:
  • Существующие сеансы могут продолжать работу, устанавливать новые соединения, а также запускать фоновые задания;
  • Установка новых сеансов и соединений с информационной базой запрещено.
• Начало и Конец — время действия блокировки сеансов;
• Сообщение — текст, который будет частью сообщения об ошибке при попытке установки соединения с заблокированной информационной базой;
• Код разрешения — строка которая должна быть добавлена к параметру /UC при запуске «1С:Предприятие» для соединения с информационной базой вопреки блокировке;
• Параметры блокировки — произвольный текст, который может использоваться в конфигурациях для различных целей;
• Внешнее управление сеансами — строка, описывающая параметры Web-сервиса внешнего управления сеансами;
• Обязательное использование внешнего управления — если флаг установлен, то при недоступности Web-сервиса внешнего управления сеансами происходит ошибка и установка подключения к информационной базе невозможна;
• Профиль безопасности — в случае указания имени профиля прикладное решение начинает работать с учетом ограничений, которые накладывает указанный профиль безопасности;
• Профиль безопасности безопасного режима — то же, что и профиль безопасности, но ограничения будут накладываться на фрагменты прикладного решения, работающие в безопасном режиме.

Изменив необходимые параметры нажимаем «Применить » для сохранения изменений или «ОК » для сохранения и закрытия окна свойств информационной базы.

4. Добавление существующей информационной базы в список информационных базы окна запуска «1С:Предприятие»

Ну и наконец, нам осталось только добавить созданную с помощью оснастки «Администрирование серверов 1С Предприятия » информационную базу в список информационных баз окна запуска «1С:Предприятие». Для чего в данном окне нажимаем «Добавить… » и в запустившемся мастере добавления информационной базы/группы выбираем соответствующий пункт и нажимаем «Далее ».

Вводим имя информационной базы, как она будет отображаться в списке, тип расположения информационной базы выбираем «На сервере 1С:Предприятия » и снова жмем «Далее ».

Вводим адрес кластера серверов «1С:Предприятия» и имя информационной базы, как оно задано в данном кластере. Нажимаем «Далее ».

Ну и наконец задаем параметры запуска информационной базы и нажимаем «Готово » для завершения работы мастера.

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

Помогла ли Вам данная статья?

Похожих статей достаточно много, но эту я в первую очередь писал для себя, останавливаясь на примечаниях, в которых описаны возможные проблемы. Надеюсь статья будет полезна и другим.
1. Устанавливаем 1С платформу
2. Устанавливаем MS SQL server 2008. При установке задаем пользователя баз данных. (Который SA).

После установки открываем панель администрирования серверов 1С предприятия и видим что она пуста.
Нужно создать сервер: Открываем console root->Central 1C: Enterprise 8.2 servers. Кликаем по нему правой кнопкой мыши и выбираем пункт new. В выпадающем меню выбираем Центральный сервер 1С Предприятия 8.2. Перед нами откроется окошко с 4-мя полями:
Протокол - протокол по которомы будут передаваться данные
Имя - имя компьютера в сети на котором располагается сервер
IP порт- порт по которому доступен сервер
Описание -описание. не обязательно.

Примечание:
Если платформа 1С была установлена на компьютер, и потом компьютер был переименован, то достучаться до него вы не сможете, потому что платформа 1С шибко умная платфома и записывает в определенные файлики при установке имя компьютера, но потом, когда имя компьютера менятся платформа их уже не перепишет. Эти файлики нужны для работы сервиса RAGENT 1С (его можно найти в запущеных службах, через панель администрирования сервера windows). Это все говорит о том, что чтобы переименовать эти файлы-необходимо остановить службу RAGENT. Сами файлы находятся в следующих местах:
C:\Program Files (x86)\1cv82\srvinfo\srvribrg
C:\Program Files (x86)\1cv82\srvinfo\reg_1541\1CV8Reg
Открываем эти файлии блокнотом и правим прошлое имя машины на настоящее ручками. Сохраняем и запускаем RAGENT.

Возвращаемся к настройке:
После того как заполнено окно с полями нажимаем кнопку OK и если все сделано верно то у нас появляется сервер по имени машины, на которй он стоит.

И так. Сервер запущен и теперь нам нужно создать базу на MYSQL server и связать ее с севером 1C. Есть несколько способов-здесь я опишу самый простой:
На сервере 1С предприятия открываем наш новый созданный сервер кликом по + рядом с названием сервера и на пункте «ИНФОРМАЦИОННЫЕ БАЗЫ» кликаем правой кнопочкой мыши, выбираем New->Информационная база
Перед нами откроется окно в котором будут следующие поля:

Имя -имя нашей базы данных на сервере 1С (Как правило многие его пишут таким же как как и в поле база данных, чтобы не путаться)
Описание -описание
Защищенное соединение -по умолчанию выключено. можно включить но тогда нагрузка на сервер возрастет
Сервер баз данных -если сервер на этом же сервере то указываем (local) именно так в скобочках, если не на этом сервере то указываем ip сервера
Тип СУБД -Выбираем тип MS SQL
База данных -имя базы данных на сервере MS SQL. Если базы нет то в одном из чекбоксов можно поставить галочку и она создастся
Пользоватлель сервера БД -Указываем либо того пользователя которого создаваи при установке, либо создаем отдельного пользователя в MS SQL, задаем ему права и прописываем его здесь.
Пароль пользователя сервера БД -пароль
Разрешить выдачу лицензий сервером 1С предприятие -выбираем да
Страна -Выбираем страну
Смещение дат -ставим в 0
Чекбокс «Создать базу в случае отсутсвия» -тот самый чекбокс для создания базы, если ее нет
Чекбокс «Установить блокировку регламентных заданий» -не ставим галочку

Нажимаем ОК и видим что серверы настроены и у нас в закладке «Информационные базы» появилась информационная база под именем которое мы ей дали.

Чтобы нстроить Backup нам нужно открыть Microsoft SQL MANAGEMENT STUDIO.
Вводим логин и подключаемся к серверу.
Перед нами административная консоль. В Object explorer открываем вкладку Management и в ней видим Maintance plans. Здесь будем создавать нужный нам BackUP. Как обычно правый клик по Maintance plans->new maintance plan . В главном окне появится вкладка subplan, а под Object Explorer появится еще одно окошечко ToolBox в котором вложен Maintance Plans Tasks . В ней мы выберем Back Up DataBase Task кликнув по нему 2 раза. Он перенесется на главное окно. На нем кликаем 2 раза и перед нами появляется окно опять же с полями, где мы можем выбрать какой Back Up делать, какую базу BackUp-ить, и куда это сохранять. По окончании настроек нужно нажать Ok.

Примечание:
Сохраняя Back Up в какую либо сетевую папку (путь кстати придется прописать ручками, потому, что оконко выбора директории видит только локальные рессурсы) проследите за правами доступа, и заодно проследите какая у вас аутентификация на сервере MySql потому что если аутентификация выставлена не по учетным записям Windows, а по внутреннему пользователю СУБД и если при этом у вас поднят сервер AD то BackUp будет выдавать ошибку при попытке исполнения, поскольку будет это делать от имени внутреннего пользователя СУБД и AD его не пропустит никуда кроме локального компьютера.

После того как вы настроили путь, базу и тип BackUp нужно настроить расписание. Для этого в главном окошке над созданным вами Task есть табличка SubPlan . В конце таблички (справа) есть иконка календаря. Кликнув на нее вы попадете в настройку расписания. Отмечая чекбоксы дней и выставляя время вы настроите расписание. Кликнув 2 раза на поле под названием SubPlan вы сможете изменить название Task-a. Настроив все пройдите в File->Save All . После сохранения в Maintance plans появится Task c вашим названием который вы дали BackUp-у.

По окончании настройки нужно обязательно проверить Работу. Для этого Правой клавишей мыши кликните на созданном Task и выполние Exicute.

Примечание:
Если Exicute выполняется с ошибкой читайте ошибки которые вам выдаст Studio, и первым делом проверьте запуще ли у вас SQL server agent . Это он занимается выполнением заданий и функция Exicute обращается именно к нему за выполнением заданий. Если он не запущен попытка выполнения потерпит неудачу. Дял того чтобы посмотреть работатет ди агент или нет в Studio в Object Explorer пройдите во вкладку SQL Server Agent . Если на иконке булет красный кружок с крестиком- значит агент остановлен. ЗАпустить его можно кликнув на нем правой кнопкой мыши и выбрав к контекстном меню опцию START.

Управление пользователями базы данных

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

Управление пользователями в среде MS SQL Server

Рассмотрим вопрос создания пользователей в среде MS SQL Server.

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

В системе SQL-сервер организована двухуровневая настройка ограничения доступа к данным. На первом уровне необходимо создать так называемую учетную запись пользователя (login), что позволяет ему подключиться к самому серверу, но не дает автоматического доступа к базам данных. На втором уровне для каждой базы данных SQL-сервера на основании учетной записи необходимо создать запись пользователя . На основе прав , выданных пользователю как пользователю базы данных (user), его регистрационное имя (login) получает доступ к соответствующей базе данных. В разных базах данных login одного и того же пользователя может иметь одинаковые или разные имена user с разными правами доступа . Иначе говоря, с помощью учетной записи пользователя осуществляется подключение к SQL-серверу, после чего определяются его уровни доступа для каждой базы данных в отдельности.

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

Итак, на уровне сервера система безопасности оперирует следующими понятиями:

• аутентификация ;
• учетная запись ;
• встроенные роли сервера.

На уровне базы данных применяются следующие понятия;

• пользователь базы данных;
• фиксированная роль базы данных;
• пользовательская роль базы данных.

Режимы аутентификации

SQL Server предлагает два режима аутентификации пользователей :

• режим аутентификации средствами Windows NT/2000;
• смешанный режим аутентификации (Windows NT Authentication and SQL Server Authentication).

Администрирование системы безопасности

Для создания пользователя в среде MS SQL Server следует предпринять следующие шаги:

1. Создать в базе данных учетную запись пользователя , указав для него пароль и принятое по умолчанию имя базы данных (процедура sp_addlogin ).
2. Добавить этого пользователя во все необходимые базы данных (процедура sp_adduser ).
3. Предоставить ему в каждой базе данных соответствующие привилегии (команда GRANT ) .

Создание новой учетной записи может быть произведено с помощью системной хранимой процедуры:

sp_addlogin [@login=] "учетная_запись" [, [@password=] "пароль"] [, [@defdb=] "база_данных_по_умолчанию"]

После завершения аутентификации и получения идентификатора учетной записи (login ID) пользователь считается зарегистрированным, и ему предоставляется доступ к серверу. Для каждой базы данных, к объектам которой он намерен получить доступ , учетная запись пользователя (login) ассоциируется с пользователем (user) конкретной базы данных, что осуществляется посредством процедуры:

sp_adduser [@loginame=] "учетная_запись" [, [@name_in_db=] "имя_пользователя"] [, [@grpname=] "имя_роли"]

Отобразить учетную запись Windows NT в имя пользователя позволяет хранимая процедура:

sp_grantdbaccess [@login=] ‘учетная_запись’ [, [@name_in_db=]‘имя_пользователя’]

Пользователь , который создает объект в базе данных (таблицу, хранимую процедуру, просмотр), становится его владельцем . Владелец объекта (database object owner dbo) имеет все права доступа к созданному им объекту. Чтобы пользователь мог создать объект, владелец базы данных (dbo) должен предоставить ему соответствующие права . Полное имя создаваемого объекта включает в себя имя создавшего его пользователя .

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

SQL Server позволяет передавать права владения от одного пользователя другому с помощью процедуры:

sp_changeobjectowner [@objname=] ‘имя_объекта’ [@newowner=] ‘имя_владельца’

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

В SQL Server реализовано два вида стандартных ролей : на уровне сервера и на уровне баз данных. При установке SQL Server создаются фиксированные роли сервера (например, sysadmin с правом выполнения любых функций SQL-сервера) и фиксированные роли базы данных (например, db_owner с правом полного доступа к базе данных или db_accessadmin с правом добавления и удаления пользователей ). Среди фиксированных ролей базы данных существует роль public, которая имеет специальное назначение, поскольку ее членами являются все пользователи , имеющие доступ к базе данных.

Можно включить любую учетную запись SQL Server (login) или учетную запись Windows NT в любую роль сервера.

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

В роль базы данных можно включить пользователей SQL Server, роли SQL Server, пользователей Windows NT.

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

• создание новой роли :

  sp_addrole [@rolename=] "имя_роли" [, [@ownername=] "имя_владельца"]

• добавление пользователя к роли :

  sp_addrolemember [@rolename=] "имя_роли", [@membername=] "имя_пользователя"

• удаление пользователя из роли :

  sp_droprolemember [@rolename=] "имя_роли", [@membername=] "имя_пользователя"

• удаление роли :

  sp_droprole [@rolename=] "имя_роли"

Управление доступом к данным

Определение привилегий в стандарте языка

Каждая СУБД должна поддерживать механизм, гарантирующий, что доступ к базе данных смогут получить только те пользователи , которые имеют соответствующее разрешение. Язык SQL включает операторы GRANT и REVOKE , предназначенные для организации защиты таблиц в базе данных. Механизм защиты построен на использовании идентификаторов пользователей , предоставляемых им прав владения и привилегий .

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

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

Привилегиями , или правами , называются действия, которые пользователь имеет право выполнять в отношении данной таблицы базы данных или представления. В стандарте SQL определяется следующий набор привилегий :

• SELECT – право выбирать данные из таблицы;
• INSERT – право вставлять в таблицу новые строки;
• UPDATE – право изменять данные в таблице;
• DELETE – право удалять строки из таблицы;
• REFERENCES – право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных;
• USAGE – право использовать домены, проверки и наборы символов.

Привилегии INSERT и UPDATE могут ограничиваться лишь отдельными столбцами таблицы, в этом случае пользователю разрешается модифицировать значения только указанных столбцов. Аналогичным образом привилегия REFERENCES может распространяться исключительно на отдельные столбцы таблицы, что позволит использовать их имена в формулировках требований защиты целостности данных – например, в предложениях CHECK и FOREIGN KEY , входящих в определение других таблиц, тогда как применение для подобных целей остальных столбцов будет запрещено .

Когда пользователь с помощью оператора CREATE TABLE создает новую таблицу, он автоматически становится ее владельцем и получает по отношению к ней полный набор привилегий , которых остальные пользователи исходно не имеют. Чтобы обеспечить им доступ , владелец должен явным образом предоставить необходимые права , для чего используется оператор GRANT .

Создавая представление с помощью оператора CREATE VIEW , пользователь автоматически становится владельцем этого представления и также получает полный набор прав . Для создания представления пользователю достаточно иметь привилегию SELECT для всех входящих в него таблиц и привилегию REFERENCES для всех столбцов, упоминаемых в определении этого представления. Привилегии INSERT , UPDATE и DELETE в отношении созданного представления пользователь получит только в том случае, если имеет соответствующие привилегии в отношении всех используемых в представлении таблиц.

Предоставление привилегий пользователям

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

<предоставление_привилегий>::= GRANT {<привилегия>[,...n] | ALL PRIVILEGES} ON имя_объекта TO {<идентификатор_пользователя> [,...n]| PUBLIC} [ WITH GRANT OPTION]

Параметр <привилегия> представляет собой:

<привилегия>::= {SELECT | DELETE | INSERT [(имя_столбца[,...n])] | UPDATE [(имя_столбца[,...n])]} | REFERENCES [(имя_столбца[,...n])] | USAGE }

Из соображений упрощения в операторе GRANT можно указать ключевое слово ALL PRIVILEGES , что позволит предоставить указанному пользователю все существующие привилегии без необходимости их перечисления. Кроме того, в этом операторе может указываться ключевое слово PUBLIC , означающее предоставление доступа указанного типа не только всем существующим пользователям , но также и всем тем, кто будет определен в базе данных впоследствии.

Параметр имя_объекта может использоваться как имя таблицы базы данных, представления, домена, набора символов, проверки.

Благодаря параметру WITH GRANT OPTION , указанные в операторе GRANT пользователи имеют право передавать все предоставленные им в отношении указанного объекта привилегии другим пользователям , которые, в свою очередь, будут наделены точно таким же правом передачи своих полномочий. Если данный параметр не будет указан, получатель привилегии не сможет передать свои права другим пользователям . Таким образом, владелец объекта может четко контролировать, кто получил право доступа к объекту и какие полномочия ему предоставлены .

Отмена предоставленных пользователям привилегий

В языке SQL для отмены привилегий , предоставленных пользователям посредством оператора GRANT , используется оператор REVOKE . С помощью этого оператора могут быть отменены все или некоторые из привилегий , полученных указанным пользователем раньше. Оператор REVOKE имеет следующий формат:

<отмена_привилегий>::= REVOKE {<привилегия>[,...n] | ALL PRIVILEGES} ON имя_объекта FROM {<идентификатор_пользователя> [,...n]| PUBLIC}

Ключевое слово ALL PRIVILEGES означает, что для указанного пользователя отменяются все привилегии , предоставленные ему ранее тем пользователем, который ввел данный оператор. Необязательная фраза GRANT OPTION FOR позволяет для всех привилегий , переданных в исходном операторе GRANT фразой WITH GRANT OPTION , отменять возможность их передачи независимо от самих привилегий .

Если в операторе указано ключевое слово RESTRICT , успешное выполнение команды REVOKE возможно лишь в том случае, когда перечисленные в операторе привилегии не могут послужить причиной появления у каких-либо других пользователей так называемых "оставленных" привилегий . С помощью параметра CASCADE удаляются все привилегии , которые иначе могли бы остаться у других пользователей .

"Оставленными" являются привилегии , сохранившиеся у пользователя , которому они в свое время были предоставлены с помощью параметра GRANT OPTION .

Поскольку наличие привилегии необходимо для создания определенных объектов, вместе с ее удалением можно лишиться права , за счет использования которого был образован тот или иной объект (подобные объекты называются "брошенными"). Если в результате выполнения оператора REVOKE могут появиться брошенные объекты (например, представления), право будет отменено при условии, что в нем не указывается ключевое слово CASCADE . Если ключевое слово CASCADE в операторе присутствует, то для любых брошенных объектов, возникающих при выполнении исходного оператора REVOKE , будут автоматически выданы операторы DROP .

Привилегии , которые были предоставлены указанному пользователю другими пользователями , не могут быть затронуты оператором REVOKE . Следовательно, если другой пользователь также предоставил данному пользователю удаляемую привилегию , то право доступа к соответствующей таблице у указанного пользователя сохранится. Например, пусть пользователь A и пользователь Е имели право INSERT на таблицу Товар . Пользователь А предоставил пользователю B привилегию INSERT для таблицы Товар , причем с указанием WITH GRANT OPTION (этап 1). Пользователь B передал эту привилегию пользователю C (этап 2). Затем пользователь C получил ее же от пользователя E (этап 3). Далее пользователь C предоставил упомянутую привилегию пользователю D (этап 4). Когда пользователь A отменяет привилегию INSERT для пользователя B , она не может быть отменена и для пользователя C , поскольку ранее он уже получил ее от пользователя E . Если бы пользователь E не предоставил данной привилегии пользователю C , то удаление привилегии пользователя B имело бы следствием каскадное удаление привилегий для пользователей C и D (см. таблицу 17.1).

Реализация прав на доступ к объектам баз данных в среде MS SQL Server

Категории прав в среде MS SQL Server

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

Права можно разделить на три категории:

• права на доступ к объектам ;
• права на выполнение команд ;
• неявные права .

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

Для различных объектов применяются разные наборы прав доступа к ним:

• SELECT , INSERT , UPDATE , DELETE , REFERENCES – для таблицы или представления;
• SELECT , UPDATE – для конкретного столбца таблицы или представления;
• EXECUTE – для хранимых процедур и функций.

Право INSERT позволяет вставлять новые строки в таблицу или представление и выдается только на уровне таблицы или представления; оно не может быть выдано на уровне столбца.

Право UPDATE выдается либо на уровне таблицы, что позволяет изменять в ней все данные, либо на уровне отдельного столбца, что разрешает изменять данные только в его пределах.

Право DELETE позволяет удалять строки из таблицы или представления, выдается только на уровне таблицы или представления, но не может быть выдано на уровне столбца.

Право SELECT разрешает выборку данных и может выдаваться как на уровне таблицы, так и на уровне отдельного столбца.

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

Предоставление прав

Для управления разрешением пользователя на доступ к объектам базы данных используется команда:

<предоставление_привилегий>::= GRANT { ALL [ PRIVILEGES] | <привилегия> [,...n]} { [(имя_столбца [,...n])] ON { имя_таблицы | имя_просмотра} | ON {имя_таблицы | имя_просмотра } ([имя_столбца [,...n])] | ON {имя_хранимой_процедуры | имя_внешней_процедуры}} TO { имя_пользователя | имя_группы | имя_роли} [,...n]

Параметр <привилегия>

<привилегия>::= {SELECT | DELETE | INSERT | UPDATE | EXECUTE | REFERENCES }

Параметр WITH GRANT OPTION поможет пользователю , которому вы предоставляете права , назначить права на доступ к объекту другим пользователям . Его использование требует особой осторожности, поскольку при этом владелец теряет контроль над предоставлением прав на доступ другим пользователям . Лучше всего ограничить круг пользователей , обладающих возможностью управлять назначением прав .

Необязательный параметр AS {имя_группы | имя_роли } позволяет указать участие пользователя в роли , обеспечивающей предоставление прав другим пользователям .

Единственное право доступа , которое может быть предоставлено для хранимой процедуры, – право на ее выполнение (EXECUTE ). Естественно, кроме этого владелец хранимой процедуры может просматривать и изменять ее код.

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

Права на выполнение команд SQL

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

<предоставление_права_выполнения>::= GRANT {ALL | <команда>

Параметр <команда> представляет собой следующую конструкцию:

<команда>::= {CREATE DATABASE | CREATE TABLE | CREATE VIEW | CREATE DEFAULT | CREATE RULE | CREATE PROCEDURE | BACKUP DATABASE | BACKUP LOG | ALL }

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

Неявные права

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

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

Запрещение доступа

Система безопасности SQL Server имеет иерархическую структуру, и поэтому роли базы данных включают в себя учетные записи и группы Windows NT, пользователей и роли SQL Server. Пользователь же, в свою очередь, может участвовать в нескольких ролях и одновременно иметь разные права доступа для разных ролей . Когда одна из ролей , в которых состоит пользователь , имеет разрешение на доступ к данным, он автоматически имеет аналогичные права . Тем не менее, если возникает необходимость, пользователю можно запретить доступ к данным или командам, тогда аннулируются все разрешения на доступ , полученные им на любом уровне иерархии. При этом гарантируется, что доступ останется запрещенным независимо от разрешений, предоставленных на более высоком уровне.

Для запрещения доступа

<запрещение_доступа>::= DENY {ALL | | <привилегия> [,...n]} { [(имя_столбца [,...n])] ON { имя_таблицы | имя_просмотра} | ON {имя_таблицы | имя_просмотра } [имя_столбца [,...n])] | ON {имя_хранимой_процедуры | имя_внешней_процедуры}} TO {имя_пользователя | имя_группы | имя_роли} [,...n]

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

Для запрещения выполнения команд SQL применяется оператор:

<запрещение_выполнения>::= DENY {ALL | <команда>[,...n]} TO {имя_пользователя | имя_группы | имя_роли} [,...n]

Неявное отклонение доступа

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

<неявное_отклонение_доступа>::= REVOKE {ALL [ PRIVILEGES]| | <привилегия> [,...n]} { [(имя_столбца [,...n])] ON { имя_таблицы | имя_просмотра} | ON {имя_таблицы | имя_просмотра } [имя_столбца [,...n])] | ON {имя_хранимой_процедуры | имя_внешней_процедуры}} TO | FROM {имя_пользователя | имя_группы | имя_роли}[,...n]

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

<неявное_отклонение_разрешения>::= REVOKE {ALL | <команда>[,...n]} FROM {имя_пользователя | имя_группы | имя_роли}[,...n]

Смысл параметров аналогичен параметрам команд GRANT и DENY . Параметр GRANT OPTION FOR используется, когда необходимо отозвать право , предоставленное параметром WITH GRANT OPTION команды GRANT . Пользователь сохраняет разрешение на доступ к объекту, но теряет возможность предоставлять это разрешение другим пользователям .

Конфликты доступа

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

При разрешении конфликтов доступа SQL Server руководствуется следующим принципом: разрешение на предоставление доступа имеет самый низкий приоритет, а на запрещение доступа – самый высокий. Это значит, что доступ к данным может быть получен только явным его предоставлением при отсутствии запрещения доступа на любом другом уровне иерархии системы безопасности. Если доступ явно не предоставлен , пользователь не сможет работать с данными.

Пример 17.1. Создать новую базу данных, нового пользователя для этой базы данных, предоставив ему все права.

Создание администратором новой -- базы данных CREATE DATABASE basa_user -- создание нового пользователя с -- именем UserA и паролем ‘123’ -- базой данных по умолчанию для -- пользователя UserA будет база -- с именем basa_user. sp_addlogin "UserA","123","basa_user" -- переход в базу данных basa_user USE basa_user -- добавление в текущую базу данных -- (basa_user) пользователя с именем -- userA sp_adduser "UserA" -- предоставление пользователю userA -- в базе данных basa_user всех прав GRANT ALL TO UserA Пример 17.1. Создание новой базы данных, нового пользователя для этой базы данных, с предоставлением ему всех прав.

Пример 17.2. Использование ролей.

Создадим роль stud и включим в эту роль двух пользователей user1 и user2 :

sp_addrole "stud" sp_addrolemember "stud","user1" sp_addrolemember "stud","user2"

Предоставим права роли stud и непосредственно пользователю user2 :

GRANT SELECT, INSERT ON Товар TO stud GRANT SELECT, INSERT ON Товар TO user2

После выполнения этих команд пользователи user1 и user2 могут выполнять команды выборки и добавления записи в таблицу Товар .

Приостановим право на выполнение вставки в таблицу Товар для роли stud :

REVOKE INSERT ON Товар TO stud

После выполнения предыдущей команды пользователь user1 теряет право вставки записи, а user2 сохраняет это право , поскольку право вставки предоставлено ему явно.

Выполним команду

DENY INSERT ON Товар TO stud.

После выполнения этой команды оба пользователя лишаются права вставки в таблицу Товар .