Sql создание пользователя. Создание пользователя субд ms sql

Tutorial

Введение

После смены рабочей станции начал ставить на нее Micorosft SQL Server 2008 R2 и чуть было не натолкнулся на традиционные грабли, связанные с улучшенной безопасностью в этой версии. Если в Microsoft SQL Server 2005 группа локальных администраторов по умолчанию включалась в роль sysadmin на SQL сервере, то в 2008-й в эту роль не включается никто:

В итоге, в инсталляции по умолчанию получается ситуация, в которой к инстансу не имеет административного доступа никто, то есть сделать с этим инстансом нельзя ничего кроме как периодически перезагружать его. Также такая ситуация возникает, когда тот, кто устанавливал SQL сервер, назначив себя единственным администратором, увольняется - например такая ситуация возникла нашими админами.
Данный пост показывает решение этой проблемы и предоставляет автоматизированное решение этой проблемы в виде скрипта, ровно как и рассказывает историю его написания, иллюстрируя мощь WMI , которая недопустимо замалчивается в литературе и в интернете.

Описание процедуры

В решении нет ничего неожиданного или революционного:

Перезагрузить инстанс в однопользовательский режим (single user mode)
Добавить нужного пользователя в администраторы сервера из-под любого пользователя из группы локальных администраторов
Перезагрузить инстанс в нормальный режим

Разжеванное описание процедуры

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

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

Тут есть много способов, начиная от присоединения к серверу посредством SQL Server Management Studio и использования графической оснастки для добавления нужных прав и кончая использованием osql . Мы пойдем вторым путем. Запускаем cmd.exe под пользователем из группы локальных администаторов и выполняем сдедующую команду:
osql -E -S .\InstanceName -Q "EXEC sp_addsrvrolemember "DOM\User", "sysadmin"" , где InstanceName - имя инстанса, а DOM\User - это домен\пользователь, которому дается административный доступ к инстансу. В моем случае (с инстансом по умолчанию и для админского пользователя RU\venticello ) выглядит это так:

Запуск инстанса в обычном режиме

Идем в обратном порядке:

Останавливаем инстанс
Удаляем параметр -m;
Запускаем инстанс

Вот, собственно и все!

Автоматизация

Хоть процедура и не архисложная и никоим образом не каждодневная, она, если честно, немного занудная и утомительная. Одно количество скриншотов является тому подтверждением. Я же являюсь убежденным апологетом утверждения, что все, что занудно, должно делаться компьютером, а не человеком - на то их и создавали. Поэтому я взял и описал все эти шаги в виде скрипта , предлагаемого вашему вниманию. Чтобы воспользоваться скриптом, его надо запустить из-под пользователя с административными привилегиями на машине с инстансом следующим образом:
cscript /nologo acquire_admin_rights.js [] , где опциональный параметр instance-name обозначает инстанс, к которому надо предоставить админские права для запускающего пользователя. Если пропустить инстанс или задать имя MSSQLSERVER , доступ будет предоставлен к инстансу по умолчанию. Еще раз напоминаю, что надо удостовериться, что в течение процедуры нет никаких приложений, активно соединяющихся с этим инстансом, так как они могут перехватить единственное соединение, предоставляемое однопользовательским режимом.
В процессе работы скрипт честно рассказывает о своих деяниях, поэтому, если что-то пойдет не так, можно понять, в чем причина и в каком состоянии оставлена система:

Детали по скрипту

Когда я начал писать скрипт, у меня уже был некоторый опыт работы с конфигурацией SQL Server через WMI, но именно с параметрам командной строки запуска инстанса работать не приходилось. Именно в этом ключе я и поведу рассказ: что я знал, и как искал то, что мне нужно.

WMI

Вкратце, в контексте нашего повествования, WMI (Windows Management Instrumentation) - это сервис Windows, предоставляющий доступ к конфигурационной информации в унифицированном виде именованных классов, представленных набором свойств. Классы распиханы по пространствам имен (самое популярные из которых - это root\cimv2 , в котором живет большинство классов, описывающих систему, и root\default , в котором живет класс реестра). На основании класса может существовать один или более экземпляров, обозначающих реальные описываемые объекты. Например, класс Win32_Service - это понятие службы, а каждый экземпляр - это набор свойств, соответствующий реальным службам, установленным на системе.

Microsoft SQL Server в WMI

Тут, как почти всегда с Microsoft, не обошлось от курчавости. Хоть сами SQL сервера обеспечивают обратную совместимость, что-то у них там не срослось на уровне конфигурации, так что абсолютно аналогичные классы конфигурации живут в двух разных пространствах имен:

root\Microsoft\SqlServer\ComputerManagement - для SQL Server 2005
root\Microsoft\SqlServer\ComputerManagement10 - для SQL Server 2008

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

wbemtest

wbemtest.exe - это стандартный клиент WMI (настолько стандартный, что присутствует в путях), поставляемый c WMI с первых дней появления этого сервиса аж в Windows 2000. Как следствие, интерфейс у этой утилиты суров, что, однако, не приумаляет его мощь. Выглядит он так:

Пока мы не присоединимся к нужному пространству имен, делать нам в этой утилитке особо нечего. К счастью, мы знаем нужное пространство имен: root\Microsoft\SqlServer\ComputerManagement10:

Если с WMI все нормально (а у этого сервиса есть тенденция изредка отваливаться), то соединение будет успешным, приглашая нас к взаимодействию активными кнопками:

Ну все, теперь мы готовы копаться в пространстве имен в поисках нужных классов и свойств.

Поиск нужных свойств

Сначала смотрим, какие классы вообще существуют в этом пространстве имен. Для этого, очевидно, жмем на кнопку Enum Classes и в появившемся не совсем понятном диаложке нажимаем OK. В итоге появляется следующее окно:

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

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

Находим объект SqlServiceAdvancedProperty.PropertyIndex=13,SqlServiceType=1,PropertyName="STARTUPPARAMETERS",ServiceName="MSSQLSERVER" . Вот оно счастье!

Работа с WMI из скрипта

Зная, какие классы и свойства нам нужны, остается только получить к ним доступ из скрипта. Рассматривать будем JScript, потому что распространяется со всеми Windows, да еще и JavaScript. Работа на VBScript или PowerShell ведется аналогично. Работа с WMI в скрипте начинается как и в случае wbemtest с подключения к нужному пространству имен. Делается это следующим кодом:
function LookupInstanceContext(instance, scope) { try { var wmi = GetObject("WINMGMTS:\\\\.\\root\\Microsoft\\SqlServer\\" + scope); var settings = new Enumerator(wmi.ExecQuery("SELECT * FROM ServerSettings WHERE InstanceName="" + instance + """)); if (!settings.atEnd()) { return wmi; } } catch (exception) {} return null; } В качестве scope подается либо «ComputerManagement» либо «ComputerManagement10», в зависимости от того, какой версии SQL Server мы ищем. Примерно таким же кодом мы присоединяемся к пространству имен root\cimv2 , посредством которого работаем со службами. Полученный объект wmi реализует интерфейс IWbemServices , но нас интересуют три следующих метода:

ExecQuery - выполнить запрос на языке WQL и вернуть список результатов
Get - получить конкретный экземпляр класса по идентификатору
ExecMethod - вызвать метод на объекте

Чтобы потренироваться в умении делать WQL запросы и смотреть на результаты, нам поможет наш старый друг wbemtest нажатием кнопки Query... на основном окне. Вкратце, WQL (WMI Query Language) - это подмножество SQL в котором в качестве таблицы используется имя класса и выбирать конкретные колонки нельзя - только SELECT * . Например, чтобы найти все экземпляры инстанса сервера с именем MSSQLSERVER, можно написать следующий WQL запрос:

Результат представлен в том же виде, в котором нам возвратились экземпляры класса (это и был результат запроса SELECT * FROM SqlServiceAdvancedProperty).
Для получения одного объекта по первичного ключу или полному набору свойств (для классов, у которых нет первичных ключей), используется метод Get . Вот функция, которая ответственна за получение строкового значения объекта SqlServiceAdvancedProperty по заданному пути:
function GetPropertyValue(wmi, path) { return wmi.Get(path).PropertyStrValue; } Изменение значения свойства подразумевает вызов метода SetStringValue (который указан в описании класса SqlServiceAdvancedProperty). Чтобы его вызвать надо предварительно создать его аргумент, в который установить требуемое значение. Делается это следующей пачкой вызовов:
function SetPropertyValue(wmi, path, value) { var arg = wmi.Get(path).Methods_("SetStringValue").inParameters.SpawnInstance_(); arg.Properties_.Item("StrValue") = value; var result = wmi.ExecMethod(path, "SetStringValue", arg); if (result.ReturnValue != 0) { throw new Error("Failed to set property "" + path + "" to value "" + value + """); } }

Десятки лет существовала возможность определения пользовательских ролей в базах данных для облегчения управления процессом предоставления разрешений на доступ к базе данных, но на уровне экземпляра всегда существовало девять фиксированных ролей (или восемь, если вы используете версию, предшествующую SQL Server 2000, - роль bulkadmin появилась в SQL Server 2005). Теперь, с появлением SQL Server 2012 наконец появилась возможность создания нестандартных, или пользовательских, ролей сервера.

Многие годы недоступность такой функциональности была источником головной боли администраторов SQL Server. Что вы делали, если нужно было предоставить права нескольким пользователям или группам на уровне экземпляра и обеспечить синхронизацию этих прав? Допустим, вам нужно предоставить право View System State большому числу пользователей, чтобы они могли видеть информацию о блокировке в центрах разработки. Приходилось предоставлять права по отдельности каждому пользователю или доменной группе.

Если все имена входа являлись доменными, был обходной путь: можно было создать доменную группу, в которую включить всех пользователей, кому были нужны такие права (при этом надо было создавать отдельные группы для каждого сервера, если нужно было предоставить права на нескольких серверах). Можно было добавить пользователей в эту группу, создать имя входа, связанное с этой доменной группой, после чего предоставить группе право View Server State на сервере. Но это нужно было делать очень внимательно. Иначе можно было предоставить право входа пользователям, у которых такого права раньше не было. Существовала даже возможность предоставления пользователям прав, которых им предоставлять нельзя.

Создание роли средствами T/SQL

Существует много способов создания пользовательской роли на сервере, в том числе средствами T/SQL, SQL Server Management Studio и Windows PowerShell. Если нужно создать пользовательскую серверную роль с применением T/SQL, нужно воспользоваться тремя командами: инструкция Create Server Role создаст пользовательскую серверную роль, инструкция Alter Server Role добавит пользователя в роль и, наконец, инструкция Grant предоставит нужные права роли.

Использование этих трех инструкций показано в следующем коде, который создает пользовательскую серверную роль по имени ViewServerState. В роль добавляется пользователь SomeFakeLogin, и роли предоставляется право View Server State. Чтобы предоставить это право другим пользователям, достаточно просто добавить их в готовую роль инструкцией Alter Server Role.

USE GO CREATE SERVER ROLE AUTHORIZATION GO ALTER SERVER ROLE ADD MEMBER GO GRANT VIEW SERVER STATE TO GO

Для удаления пользователя из роли используется инструкция Alter Server Role. При этом используется на параметр Add Member, а Drop Member:

ALTER SERVER ROLE DROP MEMBER GO

Когда нужно развернуть одну или более пользовательских серверных ролей на многих экземплярах SQL Server, есть несколько возможных вариантов. Наверняка вам не понравится подключаться к каждому серверу по отдельности и создавать на них пользовательские серверные роли. Один из вариантов - использование консоли SQL Server Management Studio. В ней можно выполнять сценарии на T/SQL сразу на нескольких экземплярах.

Можно также воспользоваться компонентами Windows PowerShell сервера SQL Server для развертывания новых пользовательских серверных ролей на всех экземплярах SQL Server в организации. (Существует много вариантов использования Windows PowerShell для выполнения задачи, но их описание выходит за рамки этой статьи.)

Консоль SQL Server Management Studio

Задачу можно легко выполнить средствами графического интерфейса SQL Server Management Studio. Чтобы создать пользовательскую серверную роль, подключитесь к экземпляру средствами Object Explorer. В обозревателе объектов перейдите к узлу <имя_экземпляра >/Security/Server Roles. Щелкните правой кнопкой Server Roles и выберите New Server Role. В открывшемся окне New Server Role в поле Server role name укажите имя роли, в поле Owner укажите владельца роли, после чего укажите объекты и разрешения, которые должны предоставляться членам роли (рис. 1 ).

Рис. 1. Укажите права, которые должна предоставлять роль

По завершении работы на странице General перейдите на страницу Members (рис. 2 ) и укажите имена входа SQL Server, которые должны входить в эту пользовательскую серверную роль.

Рис. 2. Определение членов роли

После определения членов роли на странице Members перейдите на страницу Memberships. Здесь задаются серверные роли, членом которых должна быть пользовательская серверная роль. Если на этой странице выбрать какую-то роль, пользователи, члены создаваемой пользовательской серверной роли, будут также обладать правами выбранной роли.

Если создать пользовательскую роль и сделать ее членом фиксированной серверной роли serveradmin (рис. 3 ), все члены вновь созданной пользовательской роли будут также обладать правами роли serveradmin. Как и при вложении доменных групп или ролей баз данных, при вложении ролей надо соблюдать большую осторожность, чтобы не предоставить пользователям прав, которых у них быть не должно.

Рис. 3. Пользовательские роли можно включать в другие серверные роли

Чтобы организовать вложение ролей средствами T/SQL, снова потребуется инструкция Alter Server Role с параметром Add Member. Например, чтобы сделать пользовательскую серверную роль ViewServerState членом фиксированной серверной роли setupadmin, нужно изменить фиксированную серверную роль setupadmin.

ALTER SERVER ROLE ADD MEMBER GO

В пользовательских серверных ролях может быть много пользователей. Есть десятки прав уровня экземпляра, которые можно предоставить пользовательской серверной роли для упрощения управления этими правами. Можно также создать роль для младшего администратора БД, которой предоставить часть, но не все права администратора. Можно создать группу AlwaysOnAdmin, которая предоставляет право на выполнение перехода базы данных AlwaysOn (что должно выполняться в рамках SQL Server) не предоставляя всей полноты административных прав.

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

При развертывании информационных баз предприятий на основе решений 1С в клиент-серверном режиме с использованием СУБД MS SQL иногда бывает нужно, чтобы разные базы создавались от имени разных пользователей. Т.е. нам бывает нужно завести в SQL Management Studio пользователя, отличного от sa и ввести его данные в поля окна добавления новой ИБ. (рис1.)

Каковы минимальные права, при которых это всё будет функционировать?

В материалах методической поддержки ИТС говорится, что «этот пользователь должен иметь не только полные права на базу данных информационной базы, но и права на создание баз данных в SQL-сервере и на чтение таблиц базы данных Master». Чтобы посмотреть, как это работает на практике, проведем тестовую установку ИБ в клиент-серверном варианте, используя MS SQL Server 2008 R2 Express. Можно, конечно же, тупо скопировать параметры пользователя sa, но давайте сделаем это осмысленно, это всегда полезно.

Запустим среду SQL Management Studio 2008 R2, установим соединение с SQL-сервером и откроем раздел Безопасность->Имена входа и выберем команду контекстного меню «Создать имя входа», зададим имя пользователя и установим права dbcreator, public (рис.2)

На странице свойств пользователя «Сопоставление пользователей» отметим флажком «Схема» все базы в таблице сопоставленных пользователей master, model, msdb, tempdb, и для каждой базы из таблицы отметим членство в ролях public, db_owner (рис.3)

Теперь можно вернуться к окну, изображенному на рис. 1 и применить введенные параметры. Нажимаем Далее- > Готово и... база создана, список баз увеличился на одну позицию.

Таким образом, мы сможем обрадовать и успокоить системного администратора, ведь указанная комбинация прав пользователя MS SQL минимально достаточна для использования с платформой 1С в клиент-серверном режиме, и пароль «sa» останется не скомпрометированным, а у нас есть нужные нам права пользователя MS SQL.

Добавление пользователей базы данных

Исходники баз данных

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

Управлять пользователями баз данных можно с помощью среды Management Studio или инструкций языка Transact-SQL. Оба эти способа рассматриваются в следующих подразделах.

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

Чтобы добавить пользователя базы данных с помощью среды Management Studio, разверните узел сервера в окне Object Explorer и в нем папку "Databases", в этой папке разверните узел требуемой базы данных, а в ней папку "Security". Щелкните правой кнопкой мыши папку "Users" и в контекстном меню выберите пункт New User. Откроется диалоговое окно Database User - New, в котором следует ввести имя пользователя User name и выбрать соответствующее регистрационное имя Login name:

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

Управление безопасностью базы данных посредством инструкций языка Transact-SQL

Для добавления пользователя в текущую базу данных используется инструкция CREATE USER . Синтаксис этой инструкции выглядит таким образом:

CREATE USER user_name Соглашения по синтаксису

Параметр user_name определяет имя, по которому пользователь идентифицируется в базе данных, а в параметре login указывается регистрационное имя, для которого создается данный пользователь. В параметрах cert_name и key_name указываются соответствующий сертификат и асимметричный ключ соответственно. Наконец, в параметре WITH DEFAULT_SCHEMA указывается первая схема, с которой сервер базы данных будет начинать поиск для разрешения имен объектов для данного пользователя базы данных.

Применение инструкции CREATE USER показано в примере ниже:

USE SampleDb; CREATE USER Vasya FOR LOGIN Vasya; CREATE USER Alex FOR LOGIN WITH DEFAULT_SCHEMA = poco;

Для успешного выполнения на вашем компьютере второй инструкции примера требуется сначала создать учетную запись Windows для пользователя Alexandr и вместо домена (сервера) ProfessorWeb указать имя вашего сервера.

В этом примере первая инструкция CREATE USER создает пользователя базы данных Vasya для пользователя Vasya учетной записи Windows. Схемой по умолчанию для пользователя Vasya будет dbo, поскольку для параметра DEFAULT_SCHEMA значение не указано. Вторая инструкция CREATE USER создает нового пользователя базы данных Alex. Схемой по умолчанию для этого пользователя будет схема poco. (Параметру DEFAULT_SCHEMA можно присвоить в качестве значения схему, которая в данное время не существует в базе данных.)

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

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

Для удаления пользователя из текущей базы данных применяется инструкция DROP USER . Пользователя, который является владельцем защищаемых объектов (объектов базы данных), удалить нельзя.

Схемы базы данных по умолчанию

Каждая база данных в системе имеет следующие схемы по умолчанию.

07.12.2016 Тим Форд

Что должен знать о защите администратор базы данных: объяснение терминов и общий обзор объектов, применяемых на практике

Безопасность SQL Server и доверенная проверка подлинности

Существует два вида схем безопасности в Microsoft SQL Server: безопасность SQL Server и доверенная проверка подлинности (также известная как проверка подлинности Windows). Безопасность SQL Server - стандартная комбинация имени пользователя для регистрации и пароля, а доверенная проверка подлинности предполагает, что устройство, которое пытается подключиться к экземпляру SQL Server, одобрено процедурой проверки подлинности домена, и результаты этой проверки переданы экземпляру SQL Server: считается, что домен, в котором размещен экземпляр SQL Server, доверяет учетной записи пользователя - проверка выполнена ранее.

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

Имена и пользователи

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

Есть два способа создать эти учетные записи пользователя: с помощью Transact-SQL (https://msdn.microsoft.com/en-us/library/ms189751.aspx? f=255&MSPPError=-2147217396) или через графический интерфейс. Процедура использования T-SQL для создания учетных записей хорошо документирована, и лучше всего воспользоваться ссылкой на официальную документацию по Microsoft SQL Server. А пока рассмотрим способ создания учетной записи в графическом интерфейсе. Чтобы запустить диалоговое окно для создания учетных записей пользователей, подключитесь к экземпляру SQL Server в среде SQL Server Management Studio (SSMS) в обозревателе объектов, а затем разверните узел Security\Logins («Безопасность\Имена пользователя»). Щелкните правой кнопкой мыши на пункте Logins и выберите в контекстном меню пункт New Login («Создать учетную запись») (см. экран 1).

Вы увидите диалоговое окно для настройки параметров учетной записи, показанное на экране 2. Изменить имя пользователя можно в том же окне.

Это вкладка General («Общие») для создания (и изменения) параметров учетной записи. Она отличается от двух ранее описанных схем безопасности. На вкладке General можно задать:

Login name («Имя пользователя»). Используется при проверке подлинности. В случае Windows, или доверенной проверки подлинности, необходимо задать имя в формате DOMAIN\LOGIN, где LOGIN - имя пользователя внутри домена, из которого пользователь выполняет проверку подлинности. Если экземпляр SQL Server расположен в другом домене, то необходимы отношения доверия между этим доменом и доменом SQL Server.
Password («Пароль»). При проверке подлинности SQL Server текстовое поле пароля включено, и вы вводите как имя пользователя, так и связанный с ним пароль.
Password Policy («Настройки политики паролей») и Expiration («Срок действия»). Флажки для политики пароля и срока действия также установлены в режиме проверки подлинности SQL Server, и применяются те политики, которые действуют в Active Directory в домене, где размещается SQL Server. Назначая имя пользователя SQL Server, вы можете разрешить пользователям менять свои пароли после регистрации. В результате администратор базы данных лишается доступа к имени учетной записи конечного пользователя.
Certificates («Сертификаты»), Keys («Ключи»), Credentials («Учетные данные»). В этой статье, предназначенной для начинающих, мы не будем рассматривать сертификаты, ключи и учетные данные.
Default Database («База данных по умолчанию»). Когда подключение к SQL Server установлено, выполняются два шага: проверка подлинности (должно существовать имя пользователя для учетных данных домена пользователя, если используется Windows или доверенная проверка подлинности либо необходимо передать комбинацию имени пользователя и пароля в экземпляр SQL Server). Это первый барьер. Второй заключается в том, что у проверенного имени пользователя имеется связанный объект пользователя в базе данных по умолчанию - базе данных, первоначально настроенной как контекст имени пользователя после проверки удостоверения. Даже если первое препятствие преодолено, при отсутствии соответствующего пользователя базы данных в базе данных по умолчанию подключение не будет установлено, и соответствующая запись будет внесена в журнал ошибок SQL. Но есть исключения: если серверная роль пользователя настолько важна, что нужно установить для него по умолчанию неявные права в каждой базе данных, то необязательно наличие соответствующего пользователя в базе данных по умолчанию. Однако я забегаю вперед, так как мы еще не рассматривали пользователей базы данных или роли сервера. Достаточно отметить, что, когда вы выбираете базу данных по умолчанию в графическом интерфейсе, связанный пользователь базы данных не создается. Вы просто указываете, какой должна быть база данных по умолчанию. При этом вы используете вкладку User Mapping («Сопоставление пользователей») диалогового окна Create Login («Создание учетной записи»), чтобы создать связанного пользователя базы данных.

Перейдем к следующей вкладке Server Roles («Роли сервера»), показанной на экране 3. На этой странице можно выбрать любые роли на уровне SQL Server (экземпляра) для нового пользователя. Роли сервера представляют собой коллекции прав, также известные как защищаемые объекты, которые упаковываются в коллекцию, чтобы вам не приходилось назначать права каждому защищаемому объекту отдельно. По умолчанию каждая учетная запись является членом общедоступной роли, что позволяет установить основное подключение к экземпляру SQL Server. Далее в статье будет рассмотрена каждая роль сервера в составе Microsoft SQL Server.

Следующая страница диалогового окна Create Login в среде SQL Server Management Studio предназначена для сопоставления учетных записей пользователей. Каждая учетная запись может иметь пользователя в одной или нескольких базах данных. На этой странице можно создать пользователей базы данных, связанных с новой учетной записью. Для этого нужно предоставить следующую информацию.

Database («База данных»). Установите флажок рядом с базой данных, в которой нужно создать связанного пользователя для учетной записи.
User Name («Имя пользователя»). Имя объекта пользователя не обязательно соответствует имени учетной записи, и далее будет показано, как это можно изменить.
Default Schema («Схема по умолчанию»). Каждый пользователь базы данных должен быть назначен схеме по умолчанию. Схема представляет собой коллекцию объектов базы данных, отделенных логически (но не обязательно физически) от других объектов в базе данных. Можно предоставить пользователю или группе пользователей права для всех объектов данной схемы, например предоставить всем пользователям из бухгалтерии (или учетной записи службы бухгалтерского приложения) определенные права для всех объектов в схеме Billing, но не давать доступ к этим объектам другим пользователям. При назначении схемы по умолчанию для пользователя базы данных нет необходимости включать имя схемы в вызовы T-SQL к базе данных при адресации объектов в этой схеме. Это также означает, что если пользователю предоставлены права на создание объектов, то по умолчанию они будут созданы в этой схеме, если только не указать имя схемы при создании объектов. Далее в статье мы еще коснемся концепции схем.
Database Role Membership («Членство в роли базы данных»). Точно так же, как на уровне экземпляра или сервера, каждая база данных располагает заранее определенной коллекцией прав, упакованных в ролях. Чуть позже мы рассмотрим роли базы данных, поставляемые с Microsoft SQL Server.

Обратимся к примеру диалогового окна для учетной записи пользователя SQLCRUISE\skipper (см. экран 4).

В этом примере пользователю SQLCRUISE\skipper предоставляются права для базы данных по умолчанию (lifeboat), где связанное имя пользователя - просто skipper. Схема по умолчанию - skipper_only. В двух других базах данных, в которых будут созданы пользователи для этой учетной записи, применяется то же имя пользователя, что и в имени пользователя (обычно ради упрощения идентификации), а схема по умолчанию - dbo, которая применяется по умолчанию в Microsoft SQL Server для всех определяемых пользователем объектов. Дополнительные сведения об этом будут приведены в следующем разделе. В случае с базой данных lifeboat мы предоставляем только членство в общедоступной роли базы данных, что предусматривает подключение к базе данных без дополнительных разрешений.

На следующей странице, Securables, представлены защищаемые объекты на уровне сервера или экземпляра. Как отмечалось выше, защищаемые объекты - это разрешения, предоставленные объектам. Защищаемые объекты обычно предоставляются в следующих случаях:

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

В нашем примере я предоставил SQLCRUISE\skipper членство в общедоступной роли сервера и разрешил просматривать любые определения объектов, существующие на уровне сервера (см. экран 5).

Наконец, переходим к странице Status («Состояние»). На этой странице можно разрешить или отменить доступ для пользователя (по умолчанию выбирается Grant - разрешить). Поэтому можно создать учетную запись, предоставить права, создать связанных пользователей, а затем отменить доступ. Вы можете вернуться в это окно для существующего пользователя и отменить доступ к экземпляру SQL Server. Аналогично происходит включение и отключение учетной записи (см. экран 6). Наконец, мы можем просмотреть состояние учетной записи пользователя и узнать, была ли учетная запись заблокирована из-за слишком большого числа неудачных попыток регистрации с неверным паролем.

Каждый вариант работает успешно, если имеется только одна таблица с именем tblFoo в базе данных SQL_Cruise и текущим контекстом базы данных была база данных SQL_Cruise. Однако только первый вариант будет работать корректно, независимо от того, к какой базе данных в настоящее время вы подключены на экземпляре SQL Server, содержащем базу данных SQL_Cruise. Второй вариант будет выполнен, если вы подключены к базе данных SQL_Cruise, независимо от числа схем, имеющих tblFoo, так как вы указали схему dbo. Третий вариант выдаст сообщение об ошибке (см. экран 8), если в базе данных SQL_Cruise имеется несколько схем с tblFoo, как показано в листинге 4, где я создал как таблицу dbo.tblFoo, так и таблицу user.tblFoo.

Да, все верно - объект существует, но вы получаете сообщение об ошибке Invalid object name («Недопустимое имя объекта»). Никогда не будьте уверены заранее, что объекта с таким именем не существует. Сообщение может свидетельствовать о проблеме с синтаксисом.

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

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

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

Листинг 1. Код, соответствующий настройкам, сделанным в графическом интерфейсе

USE GO CREATE LOGIN FROM WINDOWS WITH DEFAULT_DATABASE= GO USE GO CREATE USER FOR LOGIN ALTER USER WITH DEFAULT_SCHEMA= GO CREATE SCHEMA AUTHORIZATION GO USE GO CREATE USER FOR LOGIN ALTER USER WITH DEFAULT_SCHEMA= GO USE GO CREATE USER FOR LOGIN ALTER USER WITH DEFAULT_SCHEMA= GO use GO GRANT VIEW ANY DEFINITION TO GO

Листинг 2. Информация о пользователях системы и базы данных

SELECT name , sid , principal_id , type_desc , default_database_name FROM sys.server_principals WHERE name = "professor"; SELECT name , sid , principal_id , type_desc , default_schema_name FROM lifeboat.sys.database_principals WHERE name = "professor";

Листинг 3. Пример запроса для выбора столбцов и строк таблицы

ВАРИАНТ 1: полное доменное имя -========================================================================= SELECT * FROM SQL_Cruise.dbo.tblFoo; -========================================================================= - ВАРИАНТ 2: имя, определенное через схему -========================================================================= SELECT * FROM dbo.tblFoo; -========================================================================= - ВАРИАНТ 3: только имя объекта -========================================================================= SELECT * FROM tblFoo; Листинг 4. Создание таблиц с несколькими схемами USE GO CREATE SCHEMA AUTHORIZATION GO CREATE TABLE dbo.tblFoo (id INT); CREATE TABLE .tblFoo (id INT); SELECT * FROM tblFoo;

Основы безопасности SQL Server