Compartilhar via

Implementar a segurança do SQL Server Agent

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

Importante

Na Instância Gerenciada de SQL do Azure, a maioria, mas não todos os recursos do SQL Server Agent estão atualmente suportados. Consulte diferenças de T-SQL entre a Instância Gerenciada de SQL do Azure e o SQL Server ou limitações de tarefas do SQL Agent na Instância Gerenciada de SQL 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 tenha apenas as permissões necessárias para executar essa etapa de trabalho, que é determinada por um proxy do SQL Server Agent. Para definir as permissões para uma etapa de trabalho específica, crie um proxy que tenha as permissões necessárias e, em seguida, atribua esse proxy à etapa de trabalho. Um proxy pode ser especificado para mais de uma etapa de trabalho. Para etapas de trabalho que exigem as mesmas permissões, use o mesmo proxy.

A seção a seguir explica qual função de banco de dados você deve conceder 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 concedida explicitamente. Os usuários que são membros da função de servidor fixa sysadmin têm acesso total 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 de uma dessas funções de banco de dados ou da função sysadmin , o nó do SQL Server Agent não estará disponível para ele quando se conectar ao SQL Server usando o SQL Server Management Studio.

Os membros dessas funções de banco de dados podem exibir e executar trabalhos que possuem e criar etapas de trabalho que são executadas como uma conta proxy existente. Para obter mais informações sobre as permissões específicas associadas a cada uma dessas funções, consulte as funções de banco de dados fixas do SQL Server Agent.

Os membros da função de servidor fixa sysadmin têm permissão para criar, modificar e excluir contas proxy. Os membros da função sysadmin têm permissão para criar etapas de trabalho que não especificam um proxy, mas são executados 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 da implementação do SQL Server Agent:

  • Crie contas de usuário dedicadas especificamente para proxies e use apenas essas contas de usuário proxy para executar etapas de trabalho.

  • Conceda apenas as permissões necessárias para contas de usuário 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 SQL Server Agent em uma conta do Microsoft Windows que 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 do usuário puderem gravar no log de eventos do NT, essas operações poderão gerar alertas por meio do SQL Server Agent.

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

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

  • Quando um TSX (servidor de destino) se registra em um MSX (servidor mestre), os administradores de sistema do MSX obtêm controle total sobre a instância TSX do SQL Server.

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

  • O ACE depende das seguintes DLLs de configuração pertencentes ao SSDP, pois essas APIs de DLLs são chamadas pela 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 logon 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 logon remoto.
sysadmin Mapeie todos os usuários locais para o logon remoto definindo o @locallogin parâmetro 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. A falha ao mapear os usuários corretamente pode resultar em erros, como os seguintes exemplos:

  • 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