Compartilhar via

  • Artigo

Compreendendo alternância de contexto

O contexto de execução é determinado pelo usuário ou logon conectado à sessão ou executando (chamando) um módulo. Ele estabelece a identidade na qual são verificadas permissões para executar instruções ou ações. No SQL Server, o contexto de execução pode ser alternado para outro usuário ou logon executando a instrução EXECUTE AS ou especificando a cláusula EXECUTE AS em um módulo. Depois da alternância de contexto, o SQL Server verifica as permissões de logon e usuário daquela conta e não da pessoa que está chamando a instrução EXECUTE AS ou o módulo. O logon do usuário do banco de dados ou do SQL Server é representado no restante da sessão ou módulo de execução ou até que a alternância de contexto seja explicitamente revertida. Para obter mais informações sobre contexto de execução, consulte Compreendendo o contexto de execução.

Alternância de contexto explícita

O contexto de execução de uma sessão ou módulo pode ser explicitamente alterado especificando um nome de usuário ou logon em uma instrução EXECUTE AS. A representação permanece em vigor até ocorrer um dos seguintes eventos:

  • A sessão é descartada.

  • O contexto é alterando para outro logon ou usuário.

  • O contexto é revertido ao contexto de execução anterior.

O uso de EXECUTE AS para representar outro usuário explicitamente é semelhante a SETUSER em versões anteriores do SQL Server. Para obter mais informações, consulte EXECUTE AS versus SETUSER.

Alternância de contexto explícita de nível de servidor

Para alternar contexto de execução no nível de servidor, use a instrução EXECUTE AS LOGIN = 'login_name'. O nome de logon deve ser visível como uma entidade no sys.server_principals e o chamador da instrução deve ter permissão IMPERSONATE para nome de logon especificado.

O escopo de representação, quando o contexto de execução está no nível do servidor, é como segue:

  • O token de logon para login_name é autenticado pela instância do SQL Server e é válido naquela instância.

  • As permissões de nível de servidor e as associações de função do login_name são consideradas.

Use a instrução REVERT para retornar ao contexto anterior. O chamador da instrução REVERT deve estar no mesmo banco de dados onde a representação ocorreu.

Exemplo

No exemplo a seguir, Peter Connelly, um administrador de rede do Adventure Works Cycles, quer criar uma conta de logon do SQL Server para um novo funcionário, Jinghao Liuhas. O logon SQL Server de Peter não tem a permissão de nível de servidor necessária SQL Server, mas tem a permissão IMPERSONATE no adventure-works\dan1, um logon do SQL Server que não tem a permissão de nível de servidor necessária. Quando Peter se conecta ao SQL Server, o contexto de execução para a sessão é derivado de seu logon no SQL Server. Para criar um logon SQL Server, Peter temporariamente assume o contexto de execução do adventure-works\dan1. Ele, então, cria o logon. Finalmente, abandona suas permissões assumidas.

-- Switch execution context to the adventure-works\dan1 login account.
EXECUTE AS LOGIN = 'adventure-works\dan1';
-- Create the new login account.
CREATE LOGIN Jinghao1 WITH PASSWORD = '3KHJ6dhx(0xVYsdf';
-- Revert to the previous execution context.
REVERT;

Alternância de contexto explícita de nível de banco de dados

Para alternar contexto de execução no nível de banco de dados, use a instrução EXECUTE AS USER = 'user_name'. O nome de usuário deve existir como uma entidade no sys.server_principals e o chamador da instrução deve ter permissões IMPERSONATE para o nome de usuário especificado.

O escopo da representação, quando o contexto de execução está no nível do banco de dados, é como segue:

  • O token de usuário para user_name é autenticado pela instância do SQL Server e é válido no banco de dados atual. Para obter informações sobre como estender a representação de usuário além do escopo do banco de dados atual, consulte Estendendo representação de banco de dados com EXECUTE AS.

  • Permissões e associações de função de nível de banco de dados de user_name para o banco de dados atual são consideradas. Permissões de nível de servidor concedidas explicitamente a identidades no token de usuário ou por associações de função não são consideradas.

Use a instrução REVERT para retornar ao contexto anterior. O chamador da instrução REVERT deve estar no mesmo banco de dados onde a representação ocorreu.

Exemplo

No exemplo a seguir, François Ajenstat, um administrador de banco de dados do Adventure Works Cycles, quer executar a instrução DBCC CHECKDB no banco de dados AdventureWorksDW, mas não tem permissão de nível de banco de dados para isso. No entanto, ele tem permissões IMPERSONATE no usuário dan1, uma conta que tem a permissão exigida.

Quando François se conecta ao banco de dados AdventureWorksDW, o contexto de execução mapeia para o token de segurança de seu usuário. As permissões para executar instruções são verificadas nas entidades primária e secundária no token de usuário. Como ele não tem as permissões exigidas para executar a instrução DBCC CHECKDB, executa as instruções a seguir.

-- EXECUTE AS USER = 'dan1';
-- Create a table in dan1's default schema
CREATE TABLE t_NewTable( data nvarchar(100) );
go
-- Revert to the previous execution context.
REVERT
go;

Alternância de contexto implícita

O contexto de execução de um módulo, como um procedimento armazenado, gatilho, fila ou função definida pelo usuário, pode ser implicitamente alterado especificando um nome de logon ou usuário em uma cláusula EXECUTE AS na definição do módulo.

Especificando o contexto no qual o módulo é executado, você pode controlar qual conta de usuário do SQL Server usar para validar permissões em qualquer objeto referenciado pelo módulo. Isso fornece flexibilidade adicional e controle no gerenciamento de permissões na cadeia de objetos que existe entre os módulos definidos pelo usuário e os objetos referenciados por esses módulos. As permissões só podem ser concedidas a usuários no próprio módulo, sem precisar conceder permissões explícitas nos objetos referenciados. Somente o usuário que o módulo está representando precisa ter permissões nos objetos acessados pelo módulo.

O nível de representação é determinado pelo tipo de módulo no qual a representação está definida.

A representação de nível de servidor pode ser definida como:

  • Gatilhos DDL

O escopo de representação de nível de servidor é o mesmo que o previamente definido em "Alternância de contexto explícita de nível de servidor".

A representação de nível de banco de dados pode ser definida como:

  • Gatilhos DML

  • Filas

  • Procedimentos armazenados

  • Funções definidas pelo usuário

  • O escopo de representação de nível de banco de dados é o mesmo que o previamente definido em "Alternância de contexto explícita de nível de banco de dados".

  • Para obter mais informações sobre alternância de contexto implícita, consulte Usando EXECUTE AS em módulos.

Exemplo

No exemplo a seguir, Mary é a proprietária da tabela MyTable. Ela quer que o usuário Scott possa truncar a tabela, mas Scott não tem permissões diretas na tabela. Portanto, ela cria o procedimento armazenado dbo.usp_TruncateMyTable e concede permissões EXECUTE no procedimento para Scott. Quando Scott executa o procedimento armazenado, o Mecanismo de Banco de Dados verifica as permissões para truncar a tabela como se Mary estivesse ela própria executando o procedimento armazenado. Como ela é a proprietária da tabela, a instrução tem êxito, embora Scott não tenha permissão direta na tabela.

CREATE PROCEDURE dbo.usp_TruncateMyTable
WITH EXECUTE AS SELF
AS TRUNCATE TABLE MyDB..MyTable;