Partilhar via

Cláusula EXECUTE AS (Transact-SQL)

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure

No SQL Server, você pode definir o contexto de execução dos seguintes módulos definidos pelo usuário: funções (exceto funções com valor de tabela embutidas), procedimentos, filas e gatilhos.

Especificando o contexto no qual o módulo é executado, você pode controlar qual conta de usuário o Mecanismo de Banco de Dados usa para validar permissões em objetos referenciados pelo módulo. Isso fornece flexibilidade e controle adicionais no gerenciamento de permissões em toda a cadeia de objetos que existe entre os módulos definidos pelo usuário e os objetos referenciados por esses módulos. As permissões devem ser concedidas aos usuários somente no próprio módulo, sem ter que conceder-lhes permissões explícitas nos objetos referenciados. Somente o usuário que o módulo está executando como deve ter permissões sobre os objetos acessados pelo módulo.

Transact-SQL convenções de sintaxe

Sintaxe

Esta seção descreve a sintaxe do SQL Server para EXECUTE AS.

Funções (exceto funções com valor de tabela embutido), procedimentos armazenados e gatilhos DML:

{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | 'user_name' }

Gatilhos DDL com escopo de banco de dados:

{ EXEC | EXECUTE } AS { CALLER | SELF | 'user_name' }

Gatilhos DDL com escopo do servidor e gatilhos de logon:

{ EXEC | EXECUTE } AS { CALLER | SELF | 'login_name' }

Filas:

{ EXEC | EXECUTE } AS { SELF | OWNER | 'user_name' }

Arguments

CHAMADOR

Especifica as instruções dentro do módulo são executadas no contexto do chamador do módulo. O usuário que executa o módulo deve ter permissões apropriadas não apenas no módulo em si, mas também em quaisquer objetos de banco de dados referenciados pelo módulo.

CALLER é o padrão para todos os módulos, exceto filas, e é o mesmo que o comportamento do SQL Server 2005 (9.x).

CALLER não pode ser especificado em uma CREATE QUEUE instrução or ALTER QUEUE .

SELF

EXECUTE AS SELF é equivalente a EXECUTE AS <user_name>, em que o utilizador especificado é a pessoa que cria ou altera o módulo. O ID de usuário real da pessoa que cria ou modifica os módulos é armazenado na execute_as_principal_id coluna na visualização ou sys.sql_modulessys.service_queues catálogo.

SELF é o padrão para filas.

Observação

Para alterar o execute_as_principal_id ID de usuário da coluna na exibição de sys.service_queues catálogo, você deve especificar explicitamente a EXECUTE ASALTER QUEUE configuração na instrução.

PROPRIETÁRIO

Especifica que as instruções dentro do módulo são executadas no contexto do proprietário atual do módulo. Se o módulo não tiver um proprietário especificado, o proprietário do esquema do módulo será usado. OWNER não pode ser especificado para DDL ou gatilhos de logon.

Importante

OWNER deve ser mapeado para uma conta singleton e não pode ser uma função ou grupo.

'user_name'

Especifica as instruções dentro do módulo executar no contexto do usuário especificado em user_name. As permissões para quaisquer objetos dentro do módulo são verificadas em relação a user_name. user_name não pode ser especificado para gatilhos DDL com escopo de servidor ou gatilhos de logon. Use login_name em vez disso.

user_name deve existir no banco de dados atual e deve ser uma conta singleton. user_name não pode ser um grupo, função, certificado, chave ou conta interna, como NT AUTHORITY\LocalService, NT AUTHORITY\NetworkServiceou NT AUTHORITY\LocalSystem.

O ID de usuário do contexto de execução é armazenado em metadados e pode ser visualizado execute_as_principal_id na coluna na visualização ou sys.sql_modulessys.assembly_modules catálogo.

'login_name'

Especifica as instruções dentro do módulo executado no contexto do logon do SQL Server especificado em login_name. As permissões para quaisquer objetos dentro do módulo são verificadas em relação a login_name. login_name pode ser especificado apenas para gatilhos DDL com escopo de servidor ou gatilhos de logon.

login_name não pode ser um grupo, função, certificado, chave ou conta interna, como NT AUTHORITY\LocalService, NT AUTHORITY\NetworkServiceou NT AUTHORITY\LocalSystem.

Observações

A forma como o Mecanismo de Banco de Dados avalia as permissões nos objetos referenciados no módulo depende da cadeia de propriedade que existe entre os objetos de chamada e os objetos referenciados. Em versões anteriores do SQL Server, o encadeamento de propriedade era o único método disponível para evitar a necessidade de conceder ao usuário chamador acesso a todos os objetos referenciados.

O encadeamento de propriedade tem as seguintes limitações:

  • Aplica-se apenas às instruções DML: SELECT, INSERT, UPDATE, e DELETE.
  • Os proprietários da chamada e dos objetos chamados devem ser os mesmos.
  • Não se aplica a consultas dinâmicas dentro do módulo.

Independentemente do contexto de execução especificado no módulo, as seguintes ações sempre se aplicam:

  • Quando o módulo é executado, o Mecanismo de Banco de Dados primeiro verifica se o usuário que executa o módulo tem EXECUTE permissão no módulo.

  • Continuam a aplicar-se as regras de encadeamento da propriedade. Isso significa que, se os proprietários dos objetos chamados e de chamada forem os mesmos, nenhuma permissão será verificada nos objetos subjacentes.

Quando um usuário executa um módulo que foi especificado para ser executado em um contexto diferente do CALLER, a permissão do usuário para executar o módulo é verificada, mas verificações de permissões adicionais em objetos acessados pelo módulo são executadas em relação à conta de usuário especificada na EXECUTE AS cláusula. O usuário que executa o módulo está, na verdade, personificando o usuário especificado.

O contexto especificado na EXECUTE AS cláusula do módulo é válido apenas durante a execução do módulo. O contexto é revertido para o chamador quando a execução do módulo é concluída.

Especificar um nome de utilizador ou início de sessão

Um login de usuário ou servidor de banco de dados especificado na EXECUTE AS cláusula de um módulo não pode ser descartado até que o módulo seja modificado para ser executado em outro contexto.

O nome de usuário ou login especificado na EXECUTE AS cláusula deve existir como um principal em sys.database_principals ou sys.server_principals, respectivamente, ou então a operação de criar ou alterar módulo falhará. Além disso, o usuário que cria ou altera o módulo deve ter permissões IMPERSONATE na entidade de segurança.

Se o usuário tiver acesso implícito ao banco de dados ou instância do SQL Server por meio de uma associação de grupo do Windows, o EXECUTE AS usuário especificado na cláusula será criado implicitamente quando o módulo for criado quando existir um dos seguintes requisitos:

  • O usuário ou login especificado é um membro da função de servidor fixa sysadmin .
  • O usuário que está criando o módulo tem permissão para criar entidades de segurança.

Quando nenhum desses requisitos é atendido, a operação do módulo de criação falha.

Importante

Se o serviço SQL Server (MSSQLSERVER) estiver sendo executado como uma conta local (serviço local ou conta de usuário local), ele não terá privilégios para obter as associações de grupo de uma conta de domínio do Windows especificada na EXECUTE AS cláusula. Isso fará com que a execução do módulo falhe.

Por exemplo, suponha as seguintes condições:

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

  • CompanyDomain\SqlUser1é membro e, portanto, tem acesso à SQLUsers base de Sales dados.

  • O usuário que está criando ou alterando o módulo tem permissões para criar entidades de segurança.

Quando a instrução a seguir CREATE PROCEDURE é executada, a CompanyDomain\SqlUser1 é implicitamente criada como uma entidade de banco de dados no Sales banco de dados.

USE Sales;
GO

CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT USER_NAME();
GO

Use a instrução autônoma EXECUTE AS CALLER

Use a EXECUTE AS CALLER instrução autônoma dentro de um módulo para definir o contexto de execução para o chamador do módulo.

Suponha que o procedimento armazenado a seguir seja chamado por SqlUser2.

CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'SqlUser1'
AS
SELECT USER_NAME(); -- Shows execution context is set to SqlUser1.
EXECUTE AS CALLER;

SELECT USER_NAME(); -- Shows execution context is set to SqlUser2, the caller of the module.
REVERT;

SELECT USER_NAME(); -- Shows execution context is set to SqlUser1.
GO

Use EXECUTE AS para definir conjuntos de permissões personalizados

Especificar um contexto de execução para um módulo pode ser útil quando você deseja definir conjuntos de permissões personalizados. Por exemplo, algumas ações, como TRUNCATE TABLE não têm permissões concedidas. Incorporando a instrução dentro de um módulo e especificando que o TRUNCATE TABLE módulo é executado como um usuário que tem permissões para alterar a tabela, você pode estender as permissões para truncar a tabela para o usuário a quem você concede EXECUTE permissões no módulo.

Para exibir a definição do módulo com o contexto de execução especificado, use a exibição de catálogo do sys.sql_modules .

Melhor prática

Especifique um login ou usuário que tenha os privilégios mínimos necessários para executar as operações definidas no módulo. Por exemplo, não especifique uma conta de proprietário de banco de dados, a menos que essas permissões sejam necessárias.

Permissions

Para executar um módulo especificado com EXECUTE AS, o chamador deve ter EXECUTE permissões no módulo.

Para executar um módulo CLR especificado com EXECUTE AS o qual acessa recursos em outro banco de dados ou servidor, o banco de dados ou servidor de destino deve confiar no autenticador do banco de dados do qual o módulo se origina (o banco de dados de origem).

Para especificar a EXECUTE AS cláusula ao criar ou modificar um módulo, você deve ter IMPERSONATE permissões na entidade de segurança especificada e também permissões para criar o módulo. Você sempre pode se passar por si mesmo. Quando nenhum contexto de execução é especificado ou EXECUTE AS CALLER especificado, IMPERSONATE as permissões não são necessárias.

Para especificar um login_name ou user_name que tenha acesso implícito ao banco de dados por meio de uma associação de grupo do Windows, você deve ter CONTROL permissões no banco de dados.

Examples

O exemplo seguinte cria um procedimento armazenado na base de dados AdventureWorks2025 e atribui o contexto de execução a OWNER.

CREATE PROCEDURE HumanResources.uspEmployeesInDepartment
@DeptValue INT
WITH EXECUTE AS OWNER
AS
SET NOCOUNT ON;
SELECT e.BusinessEntityID,
       c.LastName,
       c.FirstName,
       e.JobTitle
FROM Person.Person AS c
     INNER JOIN HumanResources.Employee AS e
         ON c.BusinessEntityID = e.BusinessEntityID
     INNER JOIN HumanResources.EmployeeDepartmentHistory AS edh
         ON e.BusinessEntityID = edh.BusinessEntityID
WHERE edh.DepartmentID = @DeptValue
ORDER BY c.LastName, c.FirstName;
GO

-- Execute the stored procedure by specifying department 5.
EXECUTE HumanResources.uspEmployeesInDepartment 5;
GO

Conteúdo relacionado

  • Last updated on