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

Для создания пользователя базы данных нужно открыть контейнер «Базы данных», открыть контейнер базы данных, контейнер «Безопасность», в нем щелкнуть правой кнопкой мыши по контейнеру «Пользователи» и выбрать «Создать пользователя».

Пользователь БД - "Общие"

При создании пользователя нужно указать:

Имя пользователя (User name), к которому применяются те же правила, что и для других объектов SQL Server.

Имя входа (SQL Server или Windows), которой будет назначен пользователю этой базы данных. После создания пользователя назначенный ему логин изменять будет нельзя. Можно создать пользователя, которому не будет назначен никакой логин (при помощи переключателя Without login). Такому пользователю уже не получится назначить логин. Пользователи этого типа — без логинов — используются только для дополнительной настройки безопасности в Service Broker. Отметим также, что если какой-то логин уже был назначен пользователю, то другому пользователю одновременно назначить его нельзя.

Сертификат (Certificate name) или асимметричный ключ (Key name).

Схема по умолчанию (Default schema). К этой схеме SQL Server будет по умолчанию обращаться в первую очередь, например при поиске данных.

Для каких схем этот пользователь будет являться владельцем (Owned schemas).

Какие роли базы данных (Database roles) будут ему назначены (о ролях ниже).

Пользователь БД - "Расширенные свойства"

Расширенные свойства предусмотрены не только для баз данных, но и для многих других объектов SQL Server, например, для таблиц, столбцов таблиц, представлений, хранимых процедур, триггеров, функций и т. п. Расширенных свойств у объектов SQL Server может быть неограниченное количество. Для каждого из свойств предусмотрен единственный тип данных SQL_VARIANT, который вмещает в себя до 7500 байт данных. Расширенные свойства используются для хранения любой информации, которую разработчик или администратор хочет сохранить вместе с данным объектом. Наиболее часто расширенные свойства для баз данных используются в качестве флага, который о чем-то сигнализирует. Например, в расширенные свойства можно поместить информацию о времени последней массовой загрузки данных в базу, о версии структуры базы данных, если разработчики периодически ее изменяют, о том, обрабатывалась ли она каким-то скриптом или приложением (например, если такое приложение на регулярной основе перестраивает все индексы) и т. п. На уровне столбца таблицы в расширенные свойства, например, можно поместить дополнительную информацию, которая может быть использована клиентским приложением для проверки вводимых значений. Как правило, решение об использовании расширенных свойств принимается разработчиком, а изменение и чтение расширенных свойств производится внешним приложением при помощи команд Transact-SQL или при помощи объектов объектной модели SMO.

Роли

Обычно после создания логина и пользователя базы данных следующее, что нужно сделать, — предоставить пользователю разрешения в базе данных. Один из способов сделать это — воспользоваться ролями базы данных. Роли базы данных — это специальные объекты, которые используются для упрощения предоставления разрешений в базах данных. В отличие от серверных ролей, которые могут быть только встроенными, роли баз данных могут быть как встроенными, так и пользовательскими. Встроенные роли баз данных обладают предопределенным набором разрешений, а пользовательские роли можно использовать для группировки пользователей при предоставлении разрешений. Обычно пользовательские роли используются только для логинов SQL Server (хотя им можно назначать любых пользователей баз данных, в том числе созданных на основе логинов Windows). Для группировки логинов Windows обычно удобнее и проще использовать группы Windows.

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

db_owner — этой роли автоматически предоставляются полные права на базу данных. Изначально права этой роли предоставляются только специальному пользователю dbo, а через него — логину, который создал эту базу данных.

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

dbo_securityadmin — эта роль дополняет роль dbo_accessadmin. Сотрудник с правами этой роли получает возможность назначать разрешения на объекты базы данных и изменять членство во встроенных и пользовательских ролях. Прав на создание и изменение объектов пользователей у этой роли нет.

db_backupoperator — эта роль дает право, как понятно из ее названия, выполнять резервное копирование базы данных.

db_ddladmin — эта роль применяется в редких ситуациях, когда пользователю необходимо дать право создавать, изменять и удалять любые объекты в базе данных, не предоставляя прав на информацию, которая содержится в существующих объектах.

db_datareader и db_datawriter — эти встроенные роли дают право просматривать и изменять соответственно (в том числе добавлять и удалять) любую информацию в базе данных. Очень часто пользователю необходимо дать права на чтение и запись информации во всех таблицах базы данных, не предоставляя ему лишних административных разрешений (на создание и удаление объектов, изменение прав и т. п.). Самый простой вариант в этой ситуации (о котором забывают некоторые администраторы) — воспользоваться этими двумя ролями.

db_denydatareader и db_denydatawriter — эти роли, как понятно из названий, противоположны ролям db_datareader и db_datawriter. Роль db_denydatareader явно запрещает просматривать какие-либо данные, а db_denydatawriter запрещает внесение изменений. Явный запрет всегда имеет приоритет перед явно предоставленными разрешениями. Обычно эти роли используются в ситуации, когда "разрешаем всем, а потом некоторым запрещаем".