3.1.      Использование идентификаторов безопасности (SID)
3.2.      Отказ от Server User Identification Numbers (SUIDs)
3.3.      Генерация GUID для не доверительных подключений пользователей
3.4.      Переименование пользователя Windows или учётной записи группы
3.5.      Системная таблица sysxlogins
3.6.      Столбец xstatus
3.7.      Столбцы dbid и language
3.8.      Состояние hasaccess
3.9.      Состояние denylogin
3.10.    Представление sysremotelogins
3.11.    Представление sysoledbuser

3. Реализация безопасности на уровне сервера

3.1. Использование идентификаторов безопасности (SID)

Вначале SQL Server 2000 проверяет идентификатор безопасности пользователя или группы (SID), что бы определить, не был ли он лишён доступа к серверу. Если это так, доступ пользователю предоставлен не будет. Если доступ не запрещён, проверяется факт предоставления доступа, как непосредственно пользователю, так и через его членство в группах. Если доступ предоставлен, осуществляется подключение к SQL Server 2000. После этого, пользователь подключается к заданной ему по умолчанию базе данных (где он также должен иметь доступ). Будут проверены его права доступа на любые объекты, к которым он попытается обратиться. Если в доступе было отказано для какого-нибудь набора прав логина, подключение к серверу будет закончено.
В Windows NT 4.0 пользователям или группам доступ к SQL Server 2000 предоставлялся или запрещался, и информация об этом сохранялась в системной таблице sysxlogins. Разрешения, прописанные в ключах системного реестра больше не используются для управления доступом к серверу. SQL Server 2000 идентифицирует SID пользователей, подключающихся через доверительное соединение или через SID группы, в которой располагается пользователь.

[В начало]

3.2. Отказ от Server User Identification Numbers (SUIDs)

Столбца SUID больше нет в SQL Server 2000. В SQL Server 6.5 и ранних версиях, защита была основана на использовании значения идентификационного номера пользователя сервера (SUID), который хранился в системной таблице sysxlogins в базе данных master. Этот столбец также существовал в нескольких системных таблицах SQL Server 7.0 Столбец <name> был удалён из следующих системных таблиц:

· Sysdatabases
· Syslogins
· Sysremotelogins
· Sysusers
· Sysprocesses

Также, было полностью удалено представление sysalternates. Функции SUSER_ID() и SUSER_NAME() были выведены из обращения, и теперь всегда возвращают null.

[В начало]

3.3. Генерация GUID для не доверительных подключений пользователей

Для не доверительных (Non-Trusted) подключений, например, когда SQL Server 2000 установлен на операционной системе Windows 98, Windows SID - не доступен. В этом случае, SQL Server 2000 генерирует 16 байтный уникальный, глобальный идентификатор (GUID). Сгенерированный GUID может используется таким же образом, как Windows SID используется для пользователей и групп Windows. Таким образом, безопасность может функционировать одинаково хорошо при доверительном и не доверительном подключении.

[В начало]

3.4. Переименование пользователя Windows или учётной записи группы

Когда переименовывается пользователь или группа Windows средствами User Manager for Domains из состава Windows NT 4.0 или с помощью утилиты Active Directory Users, SQL Server 2000 не будет знать ничего об этой операции. SQL Server 2000 поддерживает полностью квалифицированные имена пользователей или групп, которые он хранит таблице sysxlogins для обеспечения высокой эффективности, и отнюдь не часто делает запросы к контроллеру домена для обновления этой информации. Это будет так, если выполняется много выборок или контроллер домена доступен по медленному каналу. Фактические имена пользователей и групп Windows могут отличаться от хранящихся в SQL Server 2000, и это не вызовет проблем безопасности. Набор разрешений для пользователя или группы будет функционировать правильно, поскольку SQL Server полагается только на свой внутренний SID.
Когда функции SUSER_SNAME() и SUSER_SID() используются, чтобы получить имя пользователя и соответствующий ему SID, они, первым делом, обращаются к таблице sysxlogins. Запрос к Windows Local Security Authority (LSA) делается только тогда, когда таблица sysxlogins не содержит имя пользователя или SID.
Другой эффект от использования этих функций в том, что имя пользователя в системных таблицах может не совпадать с современном его именем.

[В начало]

3.5. Системная таблица sysxlogins

Системная таблица sysxlogins содержит права логина (или отказ в них) для каждого пользователя. Эта системная таблица существует только в базе данных master.
SQL Server 2000 имеет три представления, которые зависят от таблицы sysxlogins:

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

[В начало]

3.6. Столбец xstatus

Столбец xstatus хранит параметры состояния, включая членство в серверных ролях. Возможные состояния перечислены в таблице:

Назначение      Значение    Описание
------------------------------------------------------------
Denylogin       1           --
Hasaccess       2           --
Isntname        3           Not "ISN'T", but "IS WINDOWS" :)
Isntgroup       3           Only if status bit 4 is not set
Isntuser        4           Must also have status bit 3 set
Sysadmin        5           Server role
Securityadmin   6           Server role
Serveradmin     7           Server role
Setupadmin      8           Server role
Processadmin    9           Server role
Diskadmin       10          Server role
Dbcreator       11          Server role
Bulkadmin       12          Server role

[В начало]

3.7. Столбцы dbid и language

Часто можно встретить неправильное толкование того, как пользователь получает заданную по умолчанию базу данных и заданные по умолчанию параметры настройки языка. Когда пользователь подсоединяется к SQL Server 2000, сервер ищет в таблице sysxlogins строку, содержащую конкретный SID пользователя (или GUID в случае не доверительных подключений). Если идентификатор найден, заданная по умолчанию база данных и заданные по умолчанию параметры настройки языка берутся из найденной строки. Если идентификатор пользователя не найден, сервер ищет SID, которые принадлежат группам, членом которых этот пользователь является. Заданная по умолчанию база данных и язык берутся от первой группы, которая будет найдена. Этот алгоритм применяется для каждого значения по умолчанию.
Если группа, которая найдена первой (членом которой является пользователь), содержит заданный по умолчанию язык, но заданная по умолчанию база данных - null, SQL Server перейдёт к следующей группе пользователя, и попробует установить заданную по умолчанию базу данных, указанную для этой группы.
Таким образом, если пользователь является членом более чем одной группы, и не имеет заданной по умолчанию базы данных и языка, установка ему значений по умолчанию не гарантируется.
Можно назначить базу данных и язык по умолчанию определённому пользователю без предоставления его логину доступа к этой базе. Тогда, пользователю будет разрешен доступ к SQL Server на основании его членства в группах, но он получит параметры по умолчанию из своей строки в системной таблице sysxlogins. В этом случае, флаг hasaccess в таблице sysxlogins для строки этого пользователя будет установлен в ноль.

[В начало]

3.8. Состояние hasaccess

Колонка состояния hasaccess в системной таблице sysxlogins используется для фиксации параметров по умолчанию, заданных пользователю, и не предоставляет даже неявно никакого доступа. Как правило, таблица sysxlogins используется для предоставления прав логинам пользователей или группам. Если состояние hasaccess установлено в ноль, логину пользователя явно доступ не предоставляется. Однако, если пользователь подключается через предоставленный членством в группы доступ, значения по умолчанию будут установлены.
Состояние hasaccess является важным и по другой причине, которую лучше продемонстрировать на примере. Пусть Боб является членом группы REDMOND\SALES, и ему не было явно предоставлено разрешение на подключение к SQL Server 2000 и в таблице sysxlogins нет строки для логина Боба. Однако, группе REDMOND\SALES было предоставлено разрешение на логин, благодаря чему Боб сможет осуществить вход. Когда Боб становится членом фиксированной серверной роли, он не должен автоматически получать разрешение обращаться непосредственно к SQL серверу; его доступ должен осуществляться через группу SALES. В этом случае, новая строка для Боба будет добавлена в sysxlogins, но флаг hasaccess будет установлен в ноль, а включить Боба в необходимые серверные роли можно без неявного предоставления доступа к серверу. Другая ситуация, когда таблица sysxlogins содержит логины пользователей или групп, которым явно отказано в доступе, т.е. установлен флаг denylogin.

[В начало]

3.9. Состояние denylogin

Состояние denylogin используется для явного лишения доступа к SQL Server 2000 пользователя или группы. Например, если определенному пользователю (или группе) необходимо запретить доступ к SQL Server, может быть выполнена следующая инструкция Transact-SQL:

Exec sp_denylogin 'REDMOND\Bob'

Это не то же самое, что:

Exec sp_revokelogin 'REDMOND\Bob'

Различие между этими двумя инструкциями в том, что первая запрещает доступ к SQL Server, а вторая отменяет предоставленный доступ. Если пользователь был членом группы MARKETING, которая доступ имеет, исполнение второй инструкции не отменило бы Бобу возможность обращения к серверу на основании членства в группе MARKETING. Первая инструкция запрещает доступ независимо от членства в любых группах, которые могут предоставлять доступ.
Обратите внимание: В операционной системе Windows, наличие одного Deny - это всё, что требуется для блокирования ресурса пользователю.

[В начало]

3.10. Представление sysremotelogins

Представление sysremotelogins обеспечивает обратную совместимость с SQL Server 6.5 и более ранними версиями и отображает внешние логины.

[В начало]

3.11. Представление sysoledbuser

Когда пользователь хочет выполнить запрос на удалённом сервере, локальный сервер должен подключится к прилинкованному серверу от имени какого-нибудь пользователя.
Хранимая процедура sp_addlinkedsrvlogin используется для добавления новых учетных записей для подключения к прилинкованным серверам. Эта информация сохраняется в таблице sysxlogins. Эта хранимая процедура требует в качестве параметров: имя удалённого сервера, имя локального пользователя, имя внешнего пользователя и его пароль.