EXECUTE AS (Transact-SQL)

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse Analytics

Define o contexto de execução de uma sessão.

Por padrão, uma sessão é iniciada quando um usuário faz logon e é encerrada quando ele faz logoff. Todas as operações durante uma sessão estão sujeitas a verificações de permissão para aquele usuário. Quando uma EXECUTE AS instrução é executada, o contexto de execução da sessão é alterado para o login ou nome de usuário especificado. Após a troca de contexto, as permissões são verificadas contra os tokens de login e de segurança do usuário para essa conta, em vez da pessoa que chama a EXECUTE AS declaração. Em essência, o usuário ou a conta de logon são representados durante a execução da sessão ou do módulo, ou a alternância de contexto é explicitamente revertida.

Transact-SQL convenções de sintaxe

Sintaxe

{ EXEC | EXECUTE } AS <context_specification>  
[;]  
  
<context_specification>::=  
{ LOGIN | USER } = 'name'  
    [ WITH { NO REVERT | COOKIE INTO @varbinary_variable } ]   
| CALLER  

Argumentos

LOGIN
Applies to: SQL Server 2008 (10.0.x) e posterior.

Especifica que o contexto de execução a ser representado é um logon. O escopo de representação é em nível de servidor.

USER
Especifica que o contexto a ser representado é um usuário no banco de dados atual. O escopo de representação é restrito ao banco de dados atual. Uma opção de contexto para um usuário de banco de dados não herda as permissões em nível de servidor desse usuário.

“name” é um nome de logon ou usuário válido. name deve ser membro da função de servidor fixa sysadmin ou existir como uma entidade de segurança em sys.database_principals ou sys.server_principals, respectivamente.

name pode ser especificado como uma variável local.

name deve ser uma conta singleton e não pode ser um grupo, função, certificado, chave ou conta interna, como NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService ou NT AUTHORITY\LocalSystem.

Para obter mais informações, consulte Especificando um nome de logon ou usuário mais adiante neste tópico.

NÃO REVERT
Especifica que a alternância de contexto não pode ser revertida para o contexto anterior. A opção NÃO REVERT só pode ser usada no nível ad hoc.

Para mais informações sobre como reverter ao contexto anterior, veja REVERT (Transact-SQL).

COOKIE EM @varbinary_variable
Especifica que o contexto de execução só pode ser revertido para o contexto anterior se a instrução WITH COOKIE chamada REVERT contiver o valor correto de @varbinary_variable . O Mecanismo de Banco de Dados passa o cookie para @varbinary_variable. A opção COOKIE INTO pode ser usada apenas no nível ad hoc.

@varbinary_variable é varbinary(8000).

CALLER
Quando usado em um módulo, especifica que as instruções dentro dele são executadas no contexto do chamador do módulo. Quando usado fora de um módulo, a instrução não tem nenhuma ação.

Comentários

A alteração no contexto de execução permanece em vigor até que uma das seguintes situações ocorra:

• Outra EXECUTE AS afirmação é correr.

• Uma REVERT declaração é executada.

• A sessão é descartada.

• O procedimento armazenado ou gatilho onde o comando foi executado se encerra.

Você pode criar uma pilha de contexto de execução chamando a EXECUTE AS instrução várias vezes entre vários princípios. Quando chamada, a REVERT instrução troca o contexto para o login ou usuário no próximo nível da pilha de contexto. Para obter uma demonstração desse comportamento, veja o Exemplo A.

Especificando um nome de logon ou usuário

O nome de usuário ou login especificado em EXECUTE AS<context_specification> deve existir como principal em sys.database_principals ou sys.server_principals, respectivamente, ou a EXECUTE AS instrução falha. Além disso, as permissões IMPERSONATE devem ser concedidas na entidade de segurança. A menos que o chamador seja o proprietário do banco de dados ou seja membro da função de servidor fixa sysadmin, a entidade de segurança deve existir mesmo quando o usuário estiver acessando o banco de dados ou instância de SQL Server por meio de uma associação de grupo Windows. Por exemplo, considere as seguintes condições:

• O grupo CompanyDomain\SQLUsers tem acesso ao banco de dados Sales.

• CompanyDomain\SqlUser1 é um membro de SQLUsers e, por isso, tem acesso implícito ao banco de dados Sales.

Embora CompanyDomain\SqlUser1 tenha acesso ao banco de dados por meio de associação no grupo SQLUsers, a instrução EXECUTE AS USER = 'CompanyDomain\SqlUser1' falhará porque CompanyDomain\SqlUser1 não existe como entidade de segurança no banco de dados.

Se o usuário for órfão (o login associado não existir mais) e o usuário não foi criado com WITHOUT LOGIN, EXECUTE AS falhará para o usuário.

Melhor prática

Especifique um logon ou usuário que tenha pelo menos os privilégios necessários para executar as operações da sessão. Por exemplo, não especifique um nome de logon com permissões em nível de servidor se apenas as permissões em nível de banco de dados forem necessárias; ou não especifique uma conta de proprietário de banco de dados, a menos que essas permissões sejam necessárias.

Considerações de segurança

Executar sob o contexto de propriedade do DBO, por exemplo, usando a instrução EXECUTE AS USER = 'dbo', muda a forma como as permissões explícitas DENY são avaliadas. Quando você muda o contexto de execução para o contexto de propriedade do DBO, as restrições baseadas DENY em permissão que se aplicam ao principal chamador original não são aplicadas durante a duração da personificação. Como resultado, um principal que pode mudar o contexto de execução para o dbo, por exemplo, por meio da pertença ao db_owner papel fixo de banco de dados, pode realizar ações que seriam bloqueadas por permissões explícitas DENY aplicadas a esse principal.

Esse comportamento é por design. Leve-o em conta ao conceder permissões que permitem a representação de propriedade. DENY Permissões não podem servir como um controle compensatório para limitar as permissões efetivas dos principais que podem ser executados como DBO.

Usando WITH NO REVERT

Quando a EXECUTE AS instrução inclui a cláusula opcional WITH NO REVERT , o contexto de execução de uma sessão não pode ser resetado usando REVERT ou executando outra EXECUTE AS instrução. O contexto definido pela instrução permanece em efeito até que a sessão seja descartada.

Quando a cláusula SEM REVERT COOKIE = @varbinary_variable é especificada, o Mecanismo de Banco de Dados do SQL Server passa o valor do cookie para @varbinary_variable. O contexto de execução definido por essa instrução só pode ser revertido para o contexto anterior se a instrução chamada REVERT WITH COOKIE = @varbinary_variable contiver o mesmo valor @varbinary_variable .

Essa opção é útil em um ambiente no qual um pool de conexão é usado. O pool de conexão é a manutenção de um grupo de conexões de banco de dados para reutilização por aplicativos em um servidor de aplicativos. Como o valor passado para @varbinary_variable é conhecido apenas pelo chamador da EXECUTE AS instrução, o chamador pode garantir que o contexto de execução que estabelece não pode ser alterado por mais ninguém.

Determinando o logon original

Use a função ORIGINAL_LOGIN para retornar o nome do logon conectado à instância do SQL Server. Você pode usar essa função para retornar a identidade do logon original em sessões nas quais há muitas alternâncias de contexto explícitas ou implícitas.

Permissões

Para especificar EXECUTE AS em um login, o usuário deve ter permissão de IMPERSONAR no nome de login especificado e não pode ser negado ao IMPERSONADO NENHUMA LOGIN permissão. Para especificar EXECUTE AS em um usuário do banco de dados, o chamador deve ter permissões de IMPERSONAGEM no nome de usuário especificado. Quando EXECUTE AS o CALLER é especificado, não são necessárias permissões para PERSONIFICAÇÃO .

Exemplos

a. Usando EXECUTE AS e REVERT para trocar de contexto

O exemplo a seguir cria uma pilha de execução de contexto usando várias entidades. A instrução REVERT é usada para redefinir o contexto de execução para o chamador anterior. A instrução REVERT é executada várias vezes movendo a pilha para cima até o contexto de execução ser definido como o chamador original.

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. Usando a cláusula WITH COOKIE

O exemplo a seguir define o contexto de execução de uma sessão para um usuário especificado e especifica a cláusula WITH COOKIE INTO @varbinary_variable. A instrução REVERT deve especificar o valor passado para a variável @cookie na instrução EXECUTE AS para reverter com êxito o contexto de volta para o chamador. Para executar este exemplo, o logon login1 e o usuário user1 criados no exemplo A devem existir.

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  

Consulte Também

REVERT (Transact-SQL)
EXECUTE AS Cláusula (Transact-SQL)