Partilhar via

Implementar a segurança do SQL Server Agent

Aplica-se a:SQL ServerAzure SQL Managed Instance

Importante

No Azure SQL Managed Instance, a maioria dos recursos do SQL Server Agent, mas não todos, são suportados no momento. Consulte Diferenças de T-SQL da Instância Gerenciada do Azure SQL em relação ao SQL Server ou as limitações de trabalho do SQL Agent na Instância Gerenciada do SQL para obter detalhes.

O SQL Server Agent permite que o administrador de 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.

Conceder 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 msdb banco de dados. Por padrão, nenhum usuário é membro dessas funções de banco de dados. A participação nessas 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 ele se conectar ao SQL Server usando o SQL Server Management Studio.

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

Os membros da função de servidor fixo sysadmin têm permissão para criar, modificar e eliminar 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 executadas como a conta de serviço do SQL Server Agent, que é a conta usada para iniciar o SQL Server Agent.

Orientações

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 essas contas de usuário proxy apenas 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 Windows Server, elas poderão gerar alertas por meio do SQL Server Agent.

  • Não especifique a conta de Administrador do Windows Server como uma conta de serviço ou uma 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 processo e o SQL Server Agent é um sysadmin no serviço SQL Server.

  • Quando um ambiente Criar um multisservidor se alista com um MSX (servidor mestre), os administradores de sistemas MSX obtém controle total sobre a instância TSX do SQL Server.

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

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

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

    • Aglomeração - 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 O que é a Instância Gerenciada SQL do Azure?, para executar um trabalho do SQL Agent que executa uma consulta Transact-SQL (T-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 SQL do Azure:

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

A criação de logons no servidor remoto para trabalhos do SQL Agent é necessária quando o servidor local é a Instância Gerenciada 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

  • Last updated on