Compartilhar via

Implementar a segurança do SQL Server Agent

  • Artigo

Aplica-se a: SQL Server Instância Gerenciada de SQL do Azure

Importante

Atualmente, na Instância Gerenciada de SQL do Azure, a maioria dos recursos do SQL Server Agent é compatível, mas não todos. Confira Diferenças entre o T-SQL da Instância Gerenciada de SQL do Azure e o SQL Server para obter detalhes.

O SQL Server Agent permite que o administrador do banco de dados execute cada etapa de trabalho em um contexto de segurança que tem apenas as permissões necessárias para executá-la, o que é determinado por um proxy do SQL Server Agent. Para definir as permissões para uma etapa de trabalho em particular, crie um proxy com as permissões necessárias e atribua-o à etapa de trabalho. Um proxy pode ser especificado para mais de uma etapa de trabalho. Para etapas de trabalho que requerem as mesmas permissões, use o mesmo proxy.

A seção a seguir explica qual função de banco de dados deve ser concedida aos usuários para que eles possam criar ou executar trabalhos usando o SQL Server Agent.

Concedendo acesso ao SQL Server Agent

Para usar o SQL Server Agent, os usuários devem ser membros de uma ou mais das seguintes funções de banco de dados fixas:

  • SQLAgentUserRole

  • SQLAgentReaderRole

  • SQLAgentOperatorRole

Essas funções são armazenadas no banco de dados msdb . Por padrão, nenhum usuário é membro dessas funções de banco de dados. A associação a essas funções deve ser explicitamente concedida. Usuários que são membros da função de servidor fixa sysadmin têm acesso completo ao SQL Server Agent e não precisam ser membros dessas funções de banco de dados fixas para usar o SQL Server Agent. Se um usuário não for membro dessas funções de banco de dados fixas ou da função sysadmin, o nó do SQL Server Agent não estará disponível quando ele se conectar ao SQL Server usando o SQL Server Management Studio.

Os membros dessas funções de banco de dados podem visualizar e executar tarefas de sua propriedade, bem como criar etapas de trabalho executadas como uma conta proxy existente. Para obter mais informações sobre as permissões específicas associadas a cada uma dessas funções de banco de dados fixas do Agent, consulte Funções de banco de dados fixas do SQL Server Agent.

Membros da função de servidor fixa sysadmin têm permissão para criar, modificar e excluir contas proxy. Membros da função sysadmin têm permissão para criar etapas de trabalho que não especificam um proxy, mas são executadas como a conta de serviço do SQL Server Agent, que é a conta usada para iniciar o SQL Server Agent.

Diretrizes

Siga estas diretrizes para melhorar a segurança de sua implementação do SQL Server Agent:

  • Crie contas de usuário dedicadas especificamente para proxies e utilize somente essas para executar etapas de trabalho.

  • Conceda as permissões necessárias apenas a contas de usuário de proxy. Conceda apenas as permissões necessárias para executar as etapas de trabalho atribuídas a uma determinada conta proxy.

  • Não execute o serviço do SQL Server Agent sob uma conta do Microsoft Windows que não seja membro do grupo Administradores do Windows.

  • Os proxies são tão seguros quanto o repositório de credenciais do SQL Server.

  • Se as operações de gravação de usuário puderem gravar no log de eventos NT, eles poderão gerar alertas via SQL Server Agent.

  • Não especifique a conta de administração NT como uma conta de serviço ou conta proxy.

  • O SQL Server e o SQL Server Agent têm acesso aos ativos um do outro. Os dois serviços compartilham um único espaço de processamento e o SQL Server Agent é um sysadmin no serviço do SQL Server.

  • Quando um TSX (servidor de destino) se inscrever com um MSX (servidor mestre), o sysadmins do MSX obtém controle total sobre a instância de TSX do SQL Server.

  • ACE é uma extensão e não pode se chamar. O Chainer ScenarioEngine.exe (também conhecido como Microsoft.SqlServer.Chainer.Setup.exe) pode chamar o ACE. Outros processos de hospedagem também podem chamar o ACE.

  • ACE depende das seguintes DLLs de configuração de propriedade do SSDP, porque essas APIs de DLLs são chamadas pelo ACE:

    • SCO – Microsoft.SqlServer.Configuration.Sco.dll, incluindo novas validações de SCO para contas virtuais

    • Cluster – Microsoft.SqlServer.Configuration.Cluster.dll

    • SFC – Microsoft.SqlServer.Configuration.SqlConfigBase.dll

    • Extensão – Microsoft.SqlServer.Configuration.ConfigExtension.dll

Servidores vinculados

Em alguns cenários, como com a Instância Gerenciada de SQL do Azure, para executar um trabalho do SQL Agent que executa uma consulta T-SQL (Transact-SQL) em um servidor remoto por meio de um servidor vinculado, você precisa mapear um logon local para um logon no servidor remoto.

Use sp_addlinkedsrvlogin para criar um mapeamento entre um logon no servidor local para um logon no servidor remoto que tenha a permissão necessária para executar a consulta T-SQL. Quando o trabalho do SQL Agent se conecta ao servidor remoto por meio do servidor vinculado, ele executa a consulta T-SQL no contexto do acesso remoto.

A tabela a seguir descreve como mapear o logon com base no proprietário do trabalho do SQL Agent na Instância Gerenciada de SQL do Azure:

Proprietário do trabalho do SQL Agent Como mapear o logon
Usuário que não é sysadmin Mapeie o usuário local que possui o trabalho do SQL Agent para o acesso remoto.
sysadmin Mapeie todos os usuários locais para o acesso remoto definindo o parâmetro @locallogin como NULL.

Observação

A criação de logons no servidor remoto para trabalhos do SQL Agent é necessária quando o servidor local é a Instância Gerenciada de SQL do Azure. Deixar de mapear os usuários corretamente pode resultar em erros como os exemplos a seguir:

  • Windows logins are not supported in this version of SQL Server
  • Linked servers cannot be used under impersonation without a mapping for the impersonated login

Conteúdo relacionado