Аутентификация sql или аутентификация windows

SQL Server 2005 — режим аутентификации (authentification mode), Windows Authentification mode, mixed mode, логины Windows и SQL Server, преимущества и недостатки

На следующем экране мастера установки (рис. 2.6) вам предоставляется возможность выбрать режим аутентификации SQL Server 2005.

Рис. 2.6. Выбор доступных режимов аутентификации

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

В SQL Server 2005, как и в предыдущих версиях, предусмотрено два типа учетных записей для подключения SQL Server ( logins , не путайте с users — пользователями базы данных!): логины Windows ( Windows Authentification ) и логины SQL Server ( SQL Server Authentification ). Логины Windows основаны на учетных записях Windows , которым предоставляется право подключаться к серверу SQL Server . Пользователям нет необходимости вводить какие-то пароли при подключении к SQL Server , если они уже вошли в сеть Windows .

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

Что лучше использовать — логины Windows или логины SQL Server ? Microsoft однозначно рекомендует всегда стараться использовать только логины Windows (если у вас есть домен). Аргументы просты и бесспорны:

q пользователю нет необходимости запоминать дополнительные пароли, кроме пароля, под которым он входит в сеть;

q можно предоставлять разрешения при помощи групп Windows , что очень удобно на больших предприятиях;

q логины Windows лучше защищены (и с точки зрения возможности перебора паролей, и с точки зрения возможности перехвата парольных хэшей по сети);

q при использовании логинов Windows подключение производится быстрее.

Однако, по опыту автора, примерно на 80% установленных SQL Server на предприятиях используются логины SQL Server . Тех, кто выбирает этот способ, тоже можно понять:

q очень часто на предприятии за учетные записи домена и за SQL Server отвечают разные специалисты. Использование логинов SQL Server позволяет обойтись без обращения к администратору сети при появлении нового пользователя;

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

q логины SQL Server будут работать и в случае, если у вас есть домен Windows NT /2000/2003, и тогда, когда домена у вас на предприятии нет.

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

В SQL Server логины Windows можно использовать всегда (поскольку этот тип подключения используется учетными записями служб SQL Server ). Логины SQL Server можно использовать только тогда, когда режим аутентификации установлен в смешанный режим ( Mixed Mode ). Обычно на практике SQL Server при установке сразу переводится в смешанный режим. Выбирать использование только логинов Windows ( Windows Authentification Mode ) имеет смысл только тогда, когда у вас заведомо будут использоваться только логины Windows или этого требует политика безопасности вашего предприятия.

И еще один момент. Если вы выберете режим аутентификации Mixed Mode , вам потребуется определить пароль для учетной записи SA (системного администратора сервера). В отличие от предыдущих версий, в SQL Server 2005 к паролю для логина SA применяются те же требования, что и паролям для учетных записей Windows в вашем домене. Если вы устанавливаете SQL Server 2005 на компьютер, принадлежащий домену Windows 2003 с настройками по умолчанию, то вы не сможете ни оставить пароль пустым, ни использовать слишком простые пароли типа » password «. Подробнее про парольные политики в SQL Server 2005 будет рассказано в мод. 5.

Изменение режима проверки подлинности сервера Change server authentication mode

Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions)

В этом разделе описывается, как изменить режим проверки подлинности сервера в SQL Server SQL Server с помощью среды SQL Server Management Studio SQL Server Management Studio или Transact-SQL Transact-SQL . This topic describes how to change the server authentication mode in SQL Server SQL Server by using SQL Server Management Studio SQL Server Management Studio or Transact-SQL Transact-SQL . В процессе установки компонент Компонент SQL Server Database Engine SQL Server Database Engine настраивается на использование режима проверки подлинности Windows или режима проверки подлинности SQL Server и Windows. During installation, Компонент SQL Server Database Engine SQL Server Database Engine is set to either Windows Authentication mode or SQL Server and Windows Authentication mode. После установки вы можете изменить режим проверки подлинности в любое время. After installation, you can change the authentication mode at any time.

Если во время установки был выбран Режим проверки подлинности Windows , то имя входа sa отключено, а пароль присваивается программой установки. If Windows Authentication mode is selected during installation, the sa login is disabled and a password is assigned by setup. Если впоследствии изменить режим проверки подлинности на проверку подлинности SQL Server и Windows, то имя входа sa останется отключенным. If you later change authentication mode to SQL Server and Windows Authentication mode, the sa login remains disabled. Чтобы можно было пользоваться именем входа sa, включите его и присвойте ему новый пароль с помощью инструкции ALTER LOGIN. To use the sa login, use the ALTER LOGIN statement to enable the sa login and assign a new password. Имя входа sa может подключаться к серверу только с использованием проверки подлинности SQL Server SQL Server . The sa login can only connect to the server by using SQL Server SQL Server Authentication.

Перед началом Before you begin

Учетная запись sa — хорошо известная учетная запись SQL Server SQL Server и часто становится мишенью злоумышленников. The sa account is a well known SQL Server SQL Server account and it is often targeted by malicious users. Не включайте учетную запись sa, если это не требуется для работы приложения. Do not enable the sa account unless your application requires it. Для имени входа sa очень важно использовать надежный пароль. It is important that you use a strong password for the sa login.

Изменение режима проверки подлинности с помощью SSMS Change authentication mode with SSMS

В обозревателе объектов среды SQL Server Management Studio SQL Server Management Studio щелкните правой кнопкой мыши сервер и выберите пункт Свойства. In SQL Server Management Studio SQL Server Management Studio Object Explorer, right-click the server, and then click Properties.

На странице Безопасность , в разделе Серверная проверка подлинности выберите новый режим проверки подлинности сервера, а затем нажмите кнопку ОК. On the Security page, under Server authentication, select the new server authentication mode, and then click OK.

В диалоговом окне среды SQL Server Management Studio SQL Server Management Studio нажмите кнопку ОК , чтобы подтвердить необходимость перезапуска SQL Server SQL Server . In the SQL Server Management Studio SQL Server Management Studio dialog box, click OK to acknowledge the requirement to restart SQL Server SQL Server .

В обозревателе объектов щелкните правой кнопкой мыши сервер и выберите пункт Перезапустить. In Object Explorer, right-click your server, and then click Restart. Если работает агент SQL Server SQL Server , он тоже должен быть перезапущен. If SQL Server SQL Server Agent is running, it must also be restarted.

Включение имени входа sa Enable sa login

Имя входа sa можно включить с помощью SSMS или T-SQL. You can enable the sa login with SSMS or T-SQL.

использование SSMS; Use SSMS

В обозревателе объектов разверните узел Безопасность, разверните «Имена входа», щелкните правой кнопкой мыши имя входа sa и выберите Свойства. In Object Explorer, expand Security, expand Logins, right-click sa, and then click Properties.

На вкладке Общие, возможно, придется создать и подтвердить пароль для имени входа sa. On the General page, you might have to create and confirm a password for the sa login.

На странице Состояние в разделе Имя входа щелкните Включить и нажмите кнопку ОК. On the Status page, in the Login section, click Enabled, and then click OK.

Использование Transact-SQL Using Transact-SQL

В следующем примере включается имя входа sa и устанавливается новый пароль. The following example enables the sa login and sets a new password. Замените надежным паролем. Replace with a strong password before you run it.

Изменение режима проверки подлинности (T-SQL) Change authentication mode (T-SQL)

В следующем примере проверка подлинности сервера переключается со смешанного режима (Windows + SQL) на Windows. The following example changes Server Authentication from mixed mode (Windows + SQL) to Windows only.

В следующем примере для изменения реестра сервера используется расширенная хранимая процедура. The following example uses an extended stored procedure to modify the server registry. При неправильном изменении реестра могут возникнуть серьезные проблемы. Serious problems might occur if you modify the registry incorrectly. В результате может потребоваться переустановка операционной системы. These problems might require you to reinstall the operating system. Корпорация Майкрософт не гарантирует, что эти проблемы можно устранить. Microsoft cannot guarantee that these problems can be resolved. Ответственность за изменение реестра лежит на пользователе. Modify the registry at your own risk.

Для изменения режима аутентификации необходимы разрешения системного администратора или сервера контроля The permissions required to change the authentication mode are sysadmin or Control Server

Аутентификация и шифрование данных

заключается в предоставлении ответа на следующий вопрос: «Имеет ли данный пользователь законное право на доступ к системе?» Таким образом, данная концепция безопасности определяет процесс проверки подлинности учетных данных пользователя, чтобы не допустить использование системы несанкционированными пользователями. Аутентификацию можно реализовать путем запроса, требуя, чтобы пользователь предоставил, например, следующее:

нечто, что известно пользователю (обычно пароль);

нечто, что принадлежит пользователю, например, идентификационную карту;

физические характеристики пользователя, например, подпись или отпечатки пальцев.

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

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

Аутентификация

Система безопасности компонента Database Engine состоит из двух разных подсистем безопасности:

системы безопасности Windows;

системы безопасности SQL Server.

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

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

На основе этих двух подсистем безопасности компонент Database Engine может работать в одном из следующих режимов аутентификации: в режиме Windows и в смешанном режиме.

Режим Windows требует, чтобы пользователи входили в систему баз данных исключительно посредством своих учетных записей Windows. Система принимает данные учетной записи пользователя, полагая, что они уже были проверены и одобрены на уровне операционной системы. Такой способ подключения к системе баз данных называется доверительным соединением (trusted connection), т.к. система баз данных доверяет, что операционная система уже проверила подлинность учетной записи и соответствующего пароля.

Смешанный режим позволяет пользователям подключаться к компоненту Database Engine посредством аутентификации Windows или аутентификации SQL Server. Это означает, что некоторые учетные записи пользователей можно настроить для использования подсистемы безопасности Windows, а другие, вдобавок к этому, могут использовать также и подсистему безопасности SQL Server.

Аутентификация SQL Server предоставляется исключительно в целях обратной совместимости. Поэтому зачастую следует использовать аутентификацию Windows.

Реализация режима аутентификации

Выбор одного из доступных режимов аутентификации осуществляется посредством среды SQL Server Management Studio. Чтобы установить режим аутентификации Windows, щелкните правой кнопкой сервер баз данных в окне Object Explorer и в контекстном меню выберите пункт Properties. Откроется диалоговое окно Server Properties, в котором нужно выбрать страницу Security, а на ней Windows Authentication Mode. Для выбора смешанного режима в этом же диалоговом окне Server Properties вам нужно выбрать Server and Windows Authentication Mode.

После успешного подключения пользователя к компоненту Database Engine его доступ к объектам базы данных становится независимым от использованного способа аутентификации для входа в базу данных — аутентификации Windows или SQL Server аутентификации.

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

Шифрование данных

Шифрование — это процесс приведения данных в запутанное непонятное состояние, вследствие чего повышается уровень их безопасности. Обычно конкретная процедура шифрования осуществляется с использованием определенного алгоритма. Наиболее важный алгоритм шифрования называется RSA, по первым буквам фамилий его создателей — Rivers, Shamir и Adelman.

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

На рисунке выше главный сервисный ключ задает ключ, который управляет всеми другими ключами и сертификатами. Главный сервисный ключ создается автоматически при установке компонента Database Engine. Этот ключ зашифрован с помощью API-интерфейса защиты данных Windows (DPAPI — Data Protection API).

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

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

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

Эти формы пользовательских ключей рассмотрены в следующих далее подразделах.

Симметричные ключи

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

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

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

Язык Transact-SQL поддерживает несколько инструкций и системных функций применительно к симметричным ключам. В частности, для создания симметричного ключа применяется инструкция CREATE SYMMETRIC KEY, а для удаления существующего симметричного ключа — инструкция DROP SYMMETRIC KEY. Прежде чем симметричный ключ можно использовать для шифрования данных или для защиты другого ключа, его нужно открыть. Для этого используется инструкция OPEN SYMMETRIC KEY.

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

Асимметричные ключи

В случае если у вас имеется распределенная система или если использование симметричных ключей не обеспечивает достаточного уровня безопасности данных, то следует использовать асимметричные ключи. состоит из двух частей: личного закрытого ключа (private key) и соответствующего общего открытого ключа (public key). Каждый из этих ключей может расшифровывать данные, зашифрованные другим ключом. Благодаря наличию личного закрытого ключа асимметричное шифрование обеспечивает более высокий уровень безопасности данных, чем симметричное шифрование.

Язык Transact-SQL поддерживает несколько инструкций и системных функций применительно к асимметричным ключам. В частности, для создания нового асимметричного ключа применяется инструкция CREATE ASYMMETRIC KEY, а для изменения свойств асимметричного ключа используется инструкция ALTER ASYMMETRIC KEY. Для удаления асимметричного ключа применяется инструкция DROP ASYMMETRIC KEY.

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

Сертификаты

Сертификат открытого ключа, или просто сертификат, представляет собой предложение с цифровой подписью, которое привязывает значение открытого ключа к определенному лицу, устройству или службе, которая владеет соответствующим открытым ключом. Сертификаты выдаются и подписываются центром сертификации (Certification Authority — CA). Сущность, которая получает сертификат из центра сертификации (CA), является субъектом данного сертификата (certificate subject).

Между сертификатами и асимметричными ключами нет значительной функциональной разницы. Как первый, так и второй используют алгоритм RSA. Основная разница между ними заключается в том, что асимметричные ключи создаются вне сервера.

Сертификаты содержат следующую информацию:

значение открытого ключа субъекта;

информацию, идентифицирующую субъект;

информацию, идентифицирующую издателя сертификата;

цифровую подпись издателя сертификата.

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

Сертификаты предоставляют самый высший уровень шифрования в модели безопасности компонента Database Engine. Алгоритмы шифрования с использованием сертификатов требуют большого объема процессорных ресурсов. По этой причине сертификаты следует использовать при реальной необходимости.

Наиболее важной инструкцией применительно к сертификатам является инструкция CREATE CERTIFICATE. Использование этой инструкции показано в примере ниже:

Чтобы создать сертификат без параметра ENCRYPTION BY, сначала нужно создать главный ключ базы данных. (Все инструкции CREATE CERTIFICATE, которые не содержат этот параметр, защищаются главным ключом базы данных.) По этой причине первой инструкцией в примере выше является инструкция CREATE MASTER KEY. После этого инструкция CREATE CERTIFICATE используется для создания нового сертификата cert01, владельцем которого является объект dbo базы данных SampleDb, если этот объект является текущим пользователем.

Редактирование пользовательских ключей

Наиболее важными представлениями каталога применительно к шифрованию являются следующие:

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

Представление каталога sys.database_principals можно соединить с любым из первых трех, чтобы получить информацию о владельце определенного ключа. В примере ниже показано получение информации о существующих сертификатах. Подобным образом можно получить информацию о симметричных и асимметричных ключах.

Часть результата этого запроса:

Расширенное управление ключами SQL Server

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

повышение безопасности ключей посредством выбора поставщика функций шифрования;

общее управление ключами по всему приложению.

Расширенное управление ключами позволяет сторонним разработчикам регистрировать свои устройства в компоненте Database Engine. Когда такие устройства зарегистрированы, регистрационные имена (logins) в SQL Server могут использовать хранящиеся в них ключи шифрования, а также эффективно использовать продвинутые возможности шифрования, поддерживаемые этими модулями. Расширенное управление ключами позволяет защитить данные от доступа администраторов базы данных (за исключением членов группы sysadmin). Таким образом система защищается от пользователей с повышенными привилегиями. Данные можно зашифровывать и расшифровывать, используя инструкции шифрования языка Transact-SQL, а SQL Server может использовать внешнее устройство расширенного управления ключами для хранения ключей.

Способы шифрования данных

SQL Server поддерживает два способа шифрования данных:

шифрование на уровне столбцов;

прозрачное шифрование данных.

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

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

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

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

Применения прозрачного шифрования для защиты определенной базы данных реализуется в четыре этапа:

Используя инструкцию CREATE MASTER KEY, создается главный ключ базы данных.

С помощью инструкции CREATE CERTIFICATE создается сертификат.

Используя инструкцию CREATE DATABASE ENCRYPTION KEY, создается ключ шифрования.

Выполняется конфигурирование базы данных для использования шифрования. (Этот шаг можно реализовать, присвоив параметру ENCRYPTION инструкции ALTER DATABASE значение ON.)

Настройка безопасности компонента Database Engine

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

с помощью среды управления Management Studio сервера SQL Server;

используя инструкции языка Transact-SQL.

Эти два метода рассматриваются в последующих подразделах.

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

Чтобы с помощью среды Management Studio создать новое регистрационное имя, разверните в обозревателе объектов Object Explorer узел сервера, затем разверните папку «Security», в этой папке щелкните правой кнопкой папку «Logins» и в контекстном меню выберите опцию New Login. Откроется диалоговое окно Login — New:

Первым делом нужно решить, какой способ аутентификации применять: Windows или SQL Server. В случае выбора аутентификации Windows, в качестве регистрационного имени (Login name) необходимо указать действительное имя пользователя Windows в форме domain\user_name (домен\имя_пользователя). А если выбрана аутентификация SQL Server, необходимо ввести новое регистрационное имя (Login name) и соответствующий пароль (Password). Можно также указать базу данных и язык по умолчанию. База данных по умолчанию — это база данных, к которой пользователь автоматически подключается сразу же после входа в компонент Database Engine. Выполнив все эти действия, пользователь может входить в систему под этой новой учетной записью.

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

Для управления безопасностью компонента Database Engine применяются три инструкции языка Transact-SQL: CREATE LOGIN, ALTER LOGIN и DROP LOGIN. Инструкция CREATE LOGIN создает новое регистрационное имя входа в SQL Server. Синтаксис этой инструкции следующий:

В параметре login_name указывается создаваемое регистрационное имя. Как можно видеть в синтаксисе этой инструкции, в предложении WITH можно указать один или несколько параметров для регистрационного имени или указать в предложении FROM сертификат, асимметричный ключ или учетную запись пользователя Windows, связанную с соответствующим регистрационным именем.

В списке option_list1 указывается несколько параметров, наиболее важным из которых является параметр password, который задает пароль для данного регистрационного имени. (Другие возможные параметры — DEFAULT_DATABASE, DEFAULT_LANGUAGE и CHECK_EXPIRATION.)

Как видно из синтаксиса инструкции CREATE LOGIN, предложение FROM может содержать один из следующих параметров:

Параметр WINDOWS

Указывает, что данное регистрационное имя соотносится с существующей учетной записью пользователя Window. Этот параметр можно указать с другими подпараметрами, такими как default_database и default_language.

Параметр CERTIFICATE

Задает имя сертификата для привязки к данному регистрационному имени.

Параметр ASYMMETRIC KEY

Задает имя асимметричного ключа для привязки к данному регистрационному имени. (Сертификат и асимметричный ключ уже должны присутствовать в базе данных master.)

В примерах ниже показано создание разных форм регистрационного имени. В следующем примере создается регистрационное имя «Vasya» с паролем «12345!»:

В примере ниже создается регистрационное имя «Vasya», которое сопоставляется с учетной записью пользователя Windows с таким же самым именем пользователя:

Для конкретной системной среды нужно должным образом изменить имя компьютера и имя пользователя (в примере выше это ProfessorWeb и vasya соответственно).

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

Наконец, инструкция DROP LOGIN применяется для удаления существующего регистрационного имени. Однако регистрационное имя, которое ссылается (владеет) на другие объекты, удалить нельзя.