Cláusula EXECUTE AS (Transact-SQL)

  • Artigo

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

No SQL Server, é possível definir o contexto de execução dos seguintes módulos definidos pelo usuário: funções (exceto com valor de tabela embutida), 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 dá mais flexibilidade e controle no gerenciamento de permissões na cadeia de objetos existente entre os módulos definidos pelo usuário e os objetos referenciados por esses módulos. A permissões devem ser concedidas a usuários somente no próprio módulo, sem necessitar conceder permissões explícitas nos objetos referenciados. Somente o usuário que o módulo está representando tem permissões nos objetos acessados pelo módulo.

Convenções de sintaxe de Transact-SQL

Sintaxe

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

Funções (exceto funções com valor de tabela embutida), 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 de servidor e gatilhos de logon:

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

Filas:

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

Observação

Para exibir a sintaxe do Transact-SQL para o SQL Server 2014 (12.x) e versões anteriores, confira a Documentação das versões anteriores.

Argumentos

CALLER

Especifica que as instruções do módulo são executadas no contexto do chamador do módulo. O usuário executando o módulo deve ter permissões apropriadas não apenas no módulo em si, mas também em qualquer objeto que seja referenciado 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 , onde o usuário especificado é a EXECUTE AS <user_name>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 exibição de sys.sql_modules catálogo ou sys.service_queues .

SELF é o padrão para filas.

Observação

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

OWNER

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 gatilhos DDL ou de logon.

Importante

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

'user_name'

Especifica que as instruções dentro do módulo sejam executadas no contexto do usuário especificado em user_name. As permissões de qualquer objeto 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.

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 do usuário do contexto de execução é armazenado em metadados e pode ser exibido na execute_as_principal_id coluna na exibição ou sys.sql_modulessys.assembly_modules catálogo.

'login_name'

Especifica que as instruções do módulo sejam executadas no contexto do logon do SQL Server especificado em login_name. As permissões de qualquer objeto 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.

Comentários

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

A cadeia de propriedade tem as seguintes limitações:

  • Aplica-se somente às instruções DML: SELECT, , UPDATEINSERTe DELETE.
  • Os proprietários da chamada e os 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.

  • As regras de cadeia de propriedade continuam aplicáveis. Isso significa que, se os proprietários dos objetos chamadores e chamados são os mesmos, nenhuma permissão é 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 que são 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, representando 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 ao chamador quando a execução de módulo é concluída.

Especificar um nome de usuário ou login

Um logon 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 uma entidade de segurança em sys.database_principals ou , respectivamente, ou então a operação do módulo criar ou sys.server_principalsalterar falhará. Além disso, o usuário que cria ou altera o módulo deve ter as permissões IMPERSONATE no principal.

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 logon especificado é um membro da função de servidor fixa sysadmin.
  • O usuário que está criando o módulo tem permissão para criar os principais.

Quando nenhum desses requisitos é atendido, a operação de criar o módulo 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á a execução do módulo falhar.

Por exemplo, considere as seguintes condições:

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

  • CompanyDomain\SqlUser1é membro da e, portanto, tem acesso ao Sales banco de SQLUsers dados.

  • O usuário que está criando ou está alterando o módulo tem permissões para criar os principais.

Quando a seguinte instrução CREATE PROCEDURE é executada, o CompanyDomain\SqlUser1 é implicitamente criado como um principal de banco de dados no banco de dados Sales.

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

Usar 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 de 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

Usar 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 ter permissões concedidas. Incorporando a instrução em um módulo e especificando que o 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 TRUNCATE TABLE usuário ao qual 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 do catálogo sys.sql_modules (Transact-SQL).

Melhor prática

Especifica um logon ou usuário com os privilégios mínimos exigidos para executar as operações definidos 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.

Permissões

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 que 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 representar. 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.

Exemplos

O exemplo a seguir cria um procedimento armazenado no banco de dados AdventureWorks2022 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