Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применимо к:SQL Server
База данных SQL Azure
Управляемый экземпляр SQL Azure
Azure Synapse Analytics
Задает контекст выполнения для сеанса.
По умолчанию сеанс запускается при входе пользователя в систему и завершается при выходе пользователя из системы. Все операции во время сеанса подлежат проверке на наличие у пользователя соответствующих разрешений. При запуске EXECUTE AS оператора контекст выполнения сессии переключается на указанный логин или имя пользователя. После смены контекста права проверяются по токенам входа и пользовательским токенам безопасности для этого аккаунта, а не с оператором, вызывающим EXECUTE AS оператор. В сущности, либо входная или пользовательская учетная запись олицетворяется на время сеанса или на время выполнения модуля, либо явно обращается переключение контекста.
Transact-SQL соглашения о синтаксисе
Синтаксис
{ EXEC | EXECUTE } AS <context_specification>
[;]
<context_specification>::=
{ LOGIN | USER } = 'name'
[ WITH { NO REVERT | COOKIE INTO @varbinary_variable } ]
| CALLER
Аргументы
LOGIN
Применимо к: SQL Server 2008 (10.0.x) и более поздних версий.
Указывает, что контекст выполнения олицетворения — это имя входа. Область олицетворения — это уровень сервера.
Примечание.
Этот параметр недоступен в автономной базе данных, База данных SQL Azure или Azure Synapse Analytics.
USER
Определяет контекст для олицетворения пользователя в текущей базе данных. Область олицетворения ограничена текущей базой данных. При переключении контекста на пользователя базы данных разрешения уровня сервера этого пользователя не наследуются.
Внимание
Пока переключение контекста на пользователя базы данных активно, любая попытка подключиться к ресурсам вне базы данных будет приводить к завершению инструкции с ошибками. Это касается инструкций USE database, распределенных запросов, а также запросов, которые ссылаются на другую базу данных, использующую трех- и четырехчастные идентификаторы.
name — допустимое имя пользователя или имя входа. Аргумент name должен принадлежать предопределенной роли сервера sysadmin либо быть субъектом в базе данных sys.database_principals или sys.server_principals соответственно.
name можно задавать как локальную переменную.
Аргумент name должен быть одноэлементным и не может быть группой, ролью, сертификатом, ключом или встроенной учетной записью, например NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService или NT AUTHORITY\LocalSystem.
Дополнительные сведения см. в разделе Указание имени пользователя или имени входа далее.
НЕТ REVERT
Указывает, что переключение контекста нельзя вернуть к предыдущему контексту.
Опцию NO REVERT можно использовать только на adhoc-уровне.
Для получения дополнительной информации о возвращении к предыдущему контексту см. REVERT (Transact-SQL).
ФАЙЛ COOKIE В @varbinary_variable
Указывает, что контекст выполнения можно вернуть к предыдущему контексту только в том случае, если вызов REVERT оператора WITH COOKIE содержит правильное значение @varbinary_variable . ядро СУБД передает файл cookie в @varbinary_variable. Параметр COOKIE INTO можно использовать только на нерегламентированном уровне.
@varbinary_variablevarbinary(8000).
Примечание.
Параметр OUTPUT файла cookie в настоящее время описан в документации как varbinary(8000), что верно определяет его максимальную длину. Однако текущая реализация возвращает параметр varbinary(100). Для продолжения правильной работы в случае увеличения размера файлов cookie в последующих версиях в приложении должен быть зарезервирован тип varbinary(8000).
ВЫЗЫВАЮЩИЙ
При использовании внутри модуля указывает, что инструкции модуля выполняются в контексте вызывающей стороны.
При использовании вне модуля инструкция не действует.
Примечание.
Этот параметр недоступен в Azure Synapse Analytics.
Замечания
Изменение в контексте выполнения продолжает действовать до тех пор, пока не произойдет одно из следующих событий.
Запускается ещё одно EXECUTE AS утверждение.
Запускается REVERT заявление.
Сеанс удаляется.
Работа хранимой процедуры или триггера, где выполнялась команда, завершается.
Вы можете создать стек контекста исполнения, вызывая EXECUTE AS оператор несколько раз через несколько принципов. При вызове REVERT оператор переключает контекст на логин или пользователя на следующем уровне в контекстном стеке. Это показано в разделе Пример А.
Указание имени пользователя или имени входа
Имя пользователя или входа, указанное в EXECUTE AS<context_specification> , должно существовать как принципал в sys.database_principals или sys.server_principals соответственно, иначе EXECUTE AS оператор не работает. Кроме того, этому участнику должны быть предоставлены разрешения IMPERSONATE. Если вызывающий объект не является владельцем базы данных или членом sysadmin предопределенной роли сервера, субъект должен существовать, даже если пользователь обращается к базе данных или экземпляру SQL Server через членство в группе Windows. Для примера рассмотрим следующие условия.
Группа CompanyDomain\SQLUsers имеет доступ к базе данных Sales.
CompanyDomain\SqlUser1 является членом SQLUsers и поэтому имеет открытый доступ к базе данных Sales.
Хотя группа CompanyDomain\SqlUser1 имеет доступ к базе данных посредством членства в группе SQLUsers, инструкция EXECUTE AS USER = 'CompanyDomain\SqlUser1' завершается с ошибкой, потому что CompanyDomain\SqlUser1 не существует в базе данных в качестве субъекта.
Если пользователь остался сиротой (соответствующий логин больше не существует), и пользователь не был создан с помощью WITHOUT LOGIN, EXECUTE AS для пользователя не получится.
Рекомендации
Указывайте имя входа или пользователя, который имеет наименьшие права доступа, необходимые для выполнения операций в сеансе. Например, не указывайте имя входа с разрешениями уровня сервера, если требуются разрешения только уровня базы данных, а также не указывайте учетную запись владельца базы данных, если только эти разрешения не являются обязательными.
Внимание
Оператор EXECUTE AS может быть успешным, если ядро СУБД может разрешить имя. Если пользователь домена существует, Windows может разрешить пользователя для ядро СУБД, даже если у пользователя Windows нет доступа к SQL Server. Это может привести к условию, когда имя входа без доступа к SQL Server, как представляется, вошедшего в систему, хотя олицетворенный вход будет иметь только разрешения, предоставленные общедоступным или гостевым пользователям.
Вопросы безопасности
Выполнение в контексте владения dbo, например, с помощью оператора EXECUTE AS USER = 'dbo', меняет способ оценки явных DENY разрешений. Когда вы переключаете контекст выполнения на контекст владения dbo, ограничения на DENY основе разрешений, применимые к исходному вызывающему принципалу, не применяются на время имитации. В результате принципал, который может переключить контекст выполнения на dbo, например, через участие в db_owner фиксированной роли базы данных, может выполнять действия, которые в противном случае были бы заблокированы явными DENY разрешениями, применёнными к этому принципу.
Это поведение является намеренным. Учитывайте его при предоставлении разрешений, разрешающих олицетворение владения. DENY Разрешения не могут служить компенсирующим контролем, ограничивающим эффективные разрешения принципалов, которые могут выполняться как DBO.
Использование БЕЗ REVERT
Когда EXECUTE AS оператор содержит опциональное предложение WITH NO REVERT , контекст выполнения сессии нельзя сбросить с REVERT помощью или выполнить другой EXECUTE AS оператор. Контекст, заданный инструкцией, сохраняется до удаления сеанса.
Когда задаётся пункт БЕЗ REVERT COOKIE = @varbinary_variable, SQL Server Database Engine передаёт значение cookie в @varbinary_variable. Контекст выполнения, заданный этим оператором, может быть вернут к предыдущему только если вызов REVERT оператора WITH COOKIE = @varbinary_variable содержит то же @varbinary_variable значение.
Этот параметр может пригодиться в среде с организацией пула соединений. Организация пула соединений — это поддержка группы подключений к базе данных для повторного использования приложениями или сервером приложений. Поскольку значение, передаваемое @varbinary_variable , известно только вызывающему EXECUTE AS оператору, вызывающий может гарантировать, что установленный им контекст выполнения не может быть изменен никем другим.
Определение первоначального имени входа
Используйте функцию ORIGINAL_LOGIN, чтобы вернуть имя входа, подключенного к экземпляру SQL Server. Можно использовать эту функцию для возврата идентификатора исходного имени входа в сеансах, содержащих множество явных и неявных переключений контекста.
Разрешения
Чтобы указать EXECUTE AS при входе, звонящий должен иметь разрешение на имя имя входа и не должен быть лишён НИКАКОГО LOGINразрешения на империзацию. Чтобы указать EXECUTE AS пользователя базы данных, вызывающий должен иметь права на имя пользователя IMPERSONATE . При EXECUTE AS указании CALLER права на имитация не требуются.
Примеры
А. Использование EXECUTE AS и REVERT переключение контекста
В приведенном примере создается стек контекстов выполнения с использованием нескольких участников. Затем инструкция REVERT используется для сброса контекста выполнения к предыдущему участнику. Инструкция REVERT выполняется множество раз, передвигаясь вверх по стеку до тех пор, пока контекст выполнения не будет установлен на первоначального участника.
USE AdventureWorks2022;
GO
--Create two temporary principals
CREATE LOGIN login1 WITH PASSWORD = 'J345#$)thb';
CREATE LOGIN login2 WITH PASSWORD = 'Uor80$23b';
GO
CREATE USER user1 FOR LOGIN login1;
CREATE USER user2 FOR LOGIN login2;
GO
--Give IMPERSONATE permissions on user2 to user1
--so that user1 can successfully set the execution context to user2.
GRANT IMPERSONATE ON USER:: user2 TO user1;
GO
--Display current execution context.
SELECT SUSER_NAME(), USER_NAME();
-- Set the execution context to login1.
EXECUTE AS LOGIN = 'login1';
--Verify the execution context is now login1.
SELECT SUSER_NAME(), USER_NAME();
--Login1 sets the execution context to login2.
EXECUTE AS USER = 'user2';
--Display current execution context.
SELECT SUSER_NAME(), USER_NAME();
-- The execution context stack now has three principals: the originating caller, login1 and login2.
--The following REVERT statements will reset the execution context to the previous context.
REVERT;
--Display current execution context.
SELECT SUSER_NAME(), USER_NAME();
REVERT;
--Display current execution context.
SELECT SUSER_NAME(), USER_NAME();
--Remove temporary principals.
DROP LOGIN login1;
DROP LOGIN login2;
DROP USER user1;
DROP USER user2;
GO
B. Использование предложения WITH COOKIE
Следующий пример задает контекст выполнения сеанса указанному пользователю и указывает предложение WITH COOKIE INTO @varbinary_variable. Инструкция REVERT обязана указать значение, передаваемое переменной @cookie в EXECUTE AS инструкции, для успешного возвращения контекста обратно вызывающему. Чтобы запустить этот образец, должно существовать имя входа login1 и пользователь user1, созданные в примере А.
DECLARE @cookie VARBINARY(8000);
EXECUTE AS USER = 'user1' WITH COOKIE INTO @cookie;
-- Store the cookie in a safe location in your application.
-- Verify the context switch.
SELECT SUSER_NAME(), USER_NAME();
--Display the cookie value.
SELECT @cookie;
GO
-- Use the cookie in the REVERT statement.
DECLARE @cookie VARBINARY(8000);
-- Set the cookie value to the one from the SELECT @cookie statement.
SET @cookie = <value from the SELECT @cookie statement>;
REVERT WITH COOKIE = @cookie;
-- Verify the context switch reverted.
SELECT SUSER_NAME(), USER_NAME();
GO