Основные сведения о контексте выполнения
Контекст выполнения определяется подключенным к сеансу пользователем, или именем входа или же выполняющимся (вызывающим) модулем. При этом устанавливается идентификатор, для которого проверяются разрешения на выполнение инструкций или совершение действий. Контекст выполнения представляется парой токенов безопасности: токеном имени входа и маркером пользователя. Эти токены идентифицируют первичного и вторичного участников, для которых проверяются разрешения, а также источник, использующийся для проверки подлинности токенов. У имени входа, соединяющегося с экземпляром SQL Server, есть один токен имени входа и один или более токенов пользователя, в зависимости от числа баз данных, к которым есть доступ у данной учетной записи.
Токены безопасности имени входа и пользователя
Токен безопасности для пользователя и имени входа содержит:
Одного участника сервера или базы данных в качестве первичного идентификатора
Одного или более участников в качестве вторичных идентификаторов
Ноль или более средств проверки подлинности
Права и разрешения первичного и вторичного идентификаторов
Участниками могут быть отдельные пользователи, группы и процессы, которые могут запрашивать ресурсы SQL Server. Участники разделяются на категории по области их влияния: уровень Windows, уровень SQL Server или уровень базы данных. Дополнительные сведения см. в разделе Участники (компонент Database Engine).
Средствами проверки подлинности могут быть участники, сертификаты или асимметричные ключи, которые подтверждают подлинность токена. Часто средством проверки подлинности токена является экземпляр SQL Server. Дополнительные сведения о средствах проверки подлинности см. в разделе Расширение олицетворения базы данных с помощью инструкции EXECUTE AS. Дополнительные сведения о сертификатах и асимметричных ключах см. в разделе Иерархия средств шифрования.
Токен имени входа действителен в пределах экземпляра SQL Server. Он содержит первичный и вторичный идентификаторы, для которых проверяются разрешения, связанные с ними на уровне сервера и на уровне базы данных. Имя входа является первичным идентификатором. Вторичный идентификатор включает разрешения, унаследованные от ролей и групп.
Токен пользователя действителен только в пределах конкретной базы данных. Он содержит первичный и вторичный идентификаторы, для которых проверяются разрешения, связанные с ними на уровне базы данных. Имя пользователя базы данных само по себе является первичным идентификатором. Вторичный идентификатор содержит разрешения, унаследованные от правил и групп. Токены пользователя не содержат членства в ролях сервера, и идентификаторы токенов пользователя не могут получать разрешения уровня сервера, в том числе те, которые даются членам роли сервера public.
Если имя входа или учетная запись SQL Server созданы явно, то созданные имя входа или идентификатор пользователя будут использоваться в качестве первичного идентификатора токена имени входа или маркера пользователя. Если у участника есть неявный доступ к экземпляру SQL Server или доступ к базе данных с помощью разрешений CONTROL SERVER, то первичным идентификатором маркера имени входа является роль public по умолчанию. Первичный идентификатор токена пользователя — роль public.
.gif "Важное примечание") Важно! |
|---|
У членов предопределенной роли сервера sysadmin в качестве первичного идентификатора токена пользователя всегда используется dbo. |
Пример токена имени входа
У Мэри есть имя входа SQL Server, соответствующее учетной записи Windows MyDomain\Mary. Чтобы получить данные о созданном для нее токене имени входа, Мэри выполняет следующую инструкцию:
SELECT principal_id, sid, name, type, usage FROM sys.login_token;
GO
Результирующий набор может выглядеть примерно так:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
261 0x583EA MyDomain\Mary WINDOWS LOGIN GRANT OR DENY
2 0x02 public SERVER ROLE GRANT OR DENY
(Обработано строк: 2)
Из результирующего набора видно, что учетная запись Мэри в Windows является первичным идентификатором токена имени входа. Идентификатор principal_id, созданный вместе с ее учетной записью, используется как первичный идентификатор principal_id токена имени входа. Роль public указана как вторичный идентификатор, так как у Мэри есть членство в этой роли по умолчанию. Если бы Мэри была членом других ролей сервера, они также были бы перечислены как вторичные идентификаторы. Во время создания имени входа действительность ее учетной записи в Windows была проверена экземпляром SQL Server. Поэтому, когда Мэри входит в экземпляр SQL Server, именно он является средством проверки подлинности ее токена имени входа. Так как экземпляр SQL Server является средством проверки подлинности токена имени входа Мэри, никакие другие средства проверки подлинности — участники, сертификаты или асимметричные ключи — этим запросом не возвращаются.
Пример токена пользователя
У Мэри есть по одному токену пользователя для каждой базы данных, к которой у нее есть доступ. В первом примере Мэри подключена к базе данных master. Чтобы получить данные о созданном для нее в базе данных master токене пользователя, Мэри выполняет следующую инструкцию:
SELECT principal_id, sid, name, type, usage FROM sys.user_token;
GO
Результирующий набор может выглядеть примерно так:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
2 NULL guest SQL USER GRANT OR DENY
0 NULL public ROLE GRANT OR DENY
(Обработано строк: 2)
Из результирующего набора понятно, что Мэри — неявный пользователь базы данных master, но имеет к ней доступ по учетной записи guest. Первичный идентификатор ее токена пользователя — пользователь guest. Роль public указана как вторичный идентификатор, так как у пользователя guest есть членство в этой роли по умолчанию. Токен пользователя для Мэри в базе данных master содержит все права и разрешения уровня базы данных, принадлежащие пользователю guest и роли public.
В следующем примере для Мэри была явно создана учетная запись в базе данных Sales. Кроме того, Мэри получила членство в предопределенной роли базы данных db_ddladmin этой базы данных. Подключившись к базе данных Sales, Мэри снова выполняет запрос SELECT * FROM sys.user_token.
Результирующий набор может выглядеть примерно так:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
5 0x36CC4BBD1 Mary SQL USER GRANT OR DENY
0 NULL public ROLE GRANT OR DENY
16387 NULL db_ddladmin ROLE GRANT OR DENY
Этот результирующий набор отражает токен пользователя, созданный для Мэри в базе данных Sales. Так как Мэри была явно добавлена как пользователь базы данных Sales, ее имя используется в качестве первичного идентификатора. Две роли, в которых она состоит, перечислены как вторичные идентификаторы. Средством проверки подлинности маркера пользователя Мэри является экземпляр SQL Server.
Переключение контекста выполнения
В SQL Server контекст выполнения текущего сеанса может быть явно изменен указанием в инструкции EXECUTE AS имени пользователя или входа. Контекст выполнения модуля, например хранимой процедуры, триггера или пользовательской функции, может быть явно изменен указанием имени пользователя или имени входа в предложении EXECUTE AS определения модуля. При переключении контекста на другого пользователя или другое имя входа SQL Server проверяет разрешения токенов имени входа и пользователя для этой учетной записи. По существу, производится олицетворение этой учетной записи во время сеанса или выполнения модуля. Дополнительные сведения см. в разделе Основные сведения о переключении контекста.
См. также