Cláusula EXECUTE AS (Transact-SQL)
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_queues
ALTER 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\NetworkService
ou 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_modules
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 às instruções DML:
SELECT
, ,UPDATE
INSERT
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 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_principals
alterar 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 aoSales
banco de dados.CompanyDomain\SqlUser1
é membro da 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 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
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários