Cláusula EXECUTE AS (Transact-SQL)
Aplica-se a: SQL Server
Banco de Dados
SQL do Azure Instâ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 embutidas com valor de tabela), 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 EXECUTE AS <user_name>
, onde o usuário especificado é a pessoa que cria ou altera o módulo. O ID de usuário real da pessoa que está criando ou modificando os módulos é armazenado na execute_as_principal_id
coluna na visualização ou sys.sql_modules
sys.service_queues
catálogo.
SELF
é o padrão para filas.
Observação
Para alterar o ID do usuário da execute_as_principal_id
coluna na visualização do sys.service_queues
catálogo, você deve especificar explicitamente a EXECUTE AS
ALTER QUEUE
configuração na 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 podem ser especificados 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\NetworkService
, ou NT AUTHORITY\LocalSystem
.
O ID do usuário do contexto de execução é armazenado em metadados e pode ser visualizado execute_as_principal_id
na coluna na sys.sql_modules
visualização ou sys.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\NetworkService
, ou 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 a instruções DML:
SELECT
,INSERT
,UPDATE
eDELETE
. - 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 sobre o 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 de CALLER
, a permissão do usuário para executar o módulo é verificada, mas as verificações de permissões adicionais em objetos acessados pelo módulo são executadas na 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 usuário de banco de dados ou logon de servidor 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 logon especificado na EXECUTE AS
cláusula deve existir como uma entidade de segurança em sys.database_principals
ou sys.server_principals
, respectivamente, ou então a operação de criação ou alteração do módulo 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 houver 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 em execução 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
tem acesso aoSales
banco de dados.CompanyDomain\SqlUser1
é membro e, portanto, tem acesso aoSales
banco deSQLUsers
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 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 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
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. Ao incorporar a instrução em um módulo e especificar que o TRUNCATE TABLE
módulo seja 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 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 do 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