Основные сведения о контексте выполнения
Контекст выполнения определяется подключенным к сеансу пользователем, или именем входа или же выполняющимся (вызывающим) модулем. При этом устанавливается идентификатор, для которого проверяются разрешения на выполнение инструкций или совершение действий. Контекст выполнения представляется парой маркеров безопасности: маркером имени входа и маркером пользователя. Эти маркеры идентифицируют первичного и вторичного участников, для которых проверяются разрешения, а также источник, использующийся для проверки подлинности маркеров. У имени входа, соединяющегося с экземпляром SQL Server, есть один маркер имени входа и один или более маркеров пользователя, в зависимости от числа баз данных, к которым есть доступ у данной учетной записи.
Маркеры безопасности имени входа и пользователя
Маркер безопасности для пользователя и имени входа содержит:
- Одного участника сервера или базы данных в качестве первичного идентификатора
- Одного или более участников в качестве вторичных идентификаторов
- Ноль или более средств проверки подлинности
- Права и разрешения первичного и вторичного идентификаторов
Участниками могут быть отдельные пользователи, группы и процессы, которые могут запрашивать ресурсы SQL Server. Участники разделяются на категории по области их влияния: уровень Windows, уровень SQL Server или уровень базы данных. Дополнительные сведения см. в разделе Участники.
Средствами проверки подлинности могут быть участники, сертификаты или асимметричные ключи, которые подтверждают подлинность маркера. Часто средством проверки подлинности маркера является экземпляр SQL Server. Дополнительные сведения о средствах проверки подлинности см. в разделе Расширение олицетворения базы данных с помощью инструкции EXECUTE AS. Дополнительные сведения о сертификатах и асимметричных ключах см. в разделе Иерархия средств шифрования.
Маркер имени входа действителен в пределах экземпляра SQL Server. Он содержит первичный и вторичный идентификаторы, для которых проверяются разрешения, связанные с ними на уровне сервера и на уровне базы данных. Имя входа является первичным идентификатором. Вторичный идентификатор включает разрешения, унаследованные от правил и групп.
Маркер пользователя действителен только в пределах конкретной базы данных. Он содержит первичный и вторичный идентификаторы, для которых проверяются разрешения, связанные с ними на уровне базы данных. Имя пользователя базы данных само по себе является первичным идентификатором. Вторичный идентификатор содержит разрешения, унаследованные от правил и групп. Маркеры пользователя не содержат членства в серверных ролях, и идентификаторы маркеров пользователя не могут получать разрешения уровня сервера, в том числе те, которые даются членам серверной роли public.
Если имя входа или учетная запись SQL Server созданы явно, то созданные имя входа или идентификатор пользователя будут использоваться в качестве первичного идентификатора маркера имени входа или маркера пользователя. Когда у участника есть неявный доступ к экземпляру SQL Server или доступ к базе данных с помощью разрешений CONTROL SERVER, первичным идентификатором маркера имени входа по умолчанию считается роль public. Первичный идентификатор маркера пользователя — роль public.
.gif "ms187096.note(ru-ru,SQL.90).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 row(s) affected)
Из результирующего набора видно, что учетная запись Мэри в 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 row(s) affected)
Из результирующего набора понятно, что Мэри — неявный пользователь базы данных 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 2005 контекст выполнения текущего сеанса может быть явно изменен указанием в инструкции EXECUTE AS имени пользователя или входа. Контекст выполнения модуля, например хранимой процедуры, триггера или пользовательской функции, может быть явно изменен указанием имени пользователя или имени входа в предложении EXECUTE AS определения модуля. При переключении контекста на другого пользователя или другое имя входа SQL Server проверяет разрешения маркеров имени входа и пользователя для этой учетной записи. По существу, производится олицетворение этой учетной записи во время сеанса или выполнения модуля. Дополнительные сведения см. в разделах Основные сведения о контекстном переключении и Цепочки владения и контекстное переключение.
См. также
Основные понятия
Другие ресурсы
Контекстное переключение
EXECUTE (Transact-SQL)
EXECUTE AS (Transact-SQL)
EXECUTE AS, предложение (Transact-SQL)
sys.database_principals (Transact-SQL)
sys.server_principals (Transact-SQL)