Início / dba / Perguntas / 339376
Accepted
Bad_sa_18456
Asked: 2024-05-10 03:08:36 +0800 CST

Funções de trabalho SQL: como conceder permissão a um grupo para acessar trabalhos SQL com mapeamento exclusivo?

  • 772

Emitir

Os desenvolvedores da mesma equipe são membros de um Windows_Group. Esses desenvolvedores criam empregos que cada um possui. Somente o proprietário pode editar o trabalho, portanto não podem trabalhar juntos no mesmo trabalho. Por causa disso, acabamos com muitas versões do mesmo trabalho.

Ideia

Posso mapear [Domain\Windows_Group]para [Domain\Windows_User]que os trabalhos precisem ser executados e pertencentes à conta [Domínio\Windows_User]?

Código de amostra

O que eu estaria perdendo ou arriscando?

USE [master]
GO
CREATE LOGIN [DOMAIN\Windows_Group] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
USE [msdb]
GO
CREATE USER [Domain\Windows_User] FOR LOGIN [DOMAIN\Windows_Group]
ALTER ROLE [SQLAgentUserRole] ADD MEMBER [Domain\Windows_User]
GO

Eu só faria isso em nosso ambiente de desenvolvimento. Os desenvolvedores não têm db_owner nem acesso a nenhuma função de segurança.

Teste

Isso será usado em um novo servidor e é apenas uma teoria no momento, então ainda não tenho desenvolvedores para testar.

sql-server

1 respostas

  1. Best Answer

    Quando você adiciona um usuário para o login (que é um grupo no AD/Windows) e alguém nesse grupo do AD cria um trabalho, o SQL extrairá o SID do usuário do AD que criou esse trabalho e registrará esse sid como o proprietário do trabalho.

    Ou seja, quando alguém nesse grupo do AD tenta modificar o trabalho, ele falha porque outra pessoa é proprietária desse trabalho.

    Você provavelmente já sabe o que foi dito acima, mas só para ter certeza de que estamos na mesma página. Agora, para sua pergunta:

    "Posso mapear [Domínio\Windows_Group] para um [Domínio\Windows_User] para que os trabalhos precisem ser executados e pertencerem à conta [Domínio\Windows_User]?"

    O que você está perguntando não faz sentido, mais ou menos. Se você reler minhas frases acima, entenderá o porquê. O SID individual que criou o trabalho ainda será o proprietário do trabalho.

    O que fiz foi criar um procedimento armazenado para meu pessoal de BI que lhes permite alterar o proprietário de um trabalho. Ou seja, temos a configuração que listo acima. Portanto, quando alguém desse grupo do AD precisar modificar um trabalho, essa pessoa deverá primeiro assumir a propriedade do trabalho.

    Recentemente, lancei esta solução para que o tempo dirá se houver algum problema imprevisto.

    Você precisa entender a segurança no Agent e no SQL Server para que isso funcione. Ou seja, para etapas de trabalho não TSQL, seus usuários usarão proxies Credenciais/Agente. E para etapas de trabalho T-SQL, todas as partes envolvidas precisam entender que o SQL executa um EXECUTE AS LOGIN quando executa o SQL solicitado (ou seja, esteja atento às diferenças de identidade/permissões para etapas de trabalho T-SQL).

    Ah, e o proc que você desenvolve para eles usarem deve usar o atributo EXECUTE AS 'dbo' ou usar a assinatura do módulo - portanto, é permitido alterar o proprietário de um trabalho. E, finalmente, adicione salvaguardas apropriadas nesse processo. Por exemplo, não permito que eles mudem o proprietário de um trabalho para alguém que seja administrador de sistemas.

    • 1

relate perguntas