Estou tendo problemas para permitir que meus usuários executem pacotes SSIS de uma maneira razoável devido aos vários níveis de privilégios necessários.
O cenário : criamos um armazém de dados, com dois pacotes SSIS diferentes responsáveis por carregá-lo com dados, um deve ser executado automaticamente (por meio de um trabalho do SQL Agent e está funcionando bem) e outro que deve ser executado on- demanda dos usuários quando os dados upstream forem finalizados e limpos etc.
Este pacote executa operações muito privilegiadas, incluindo o backup do banco de dados no início da execução (com certeza, com certeza), eliminando e recriando tabelas calculadas, etc.
Eu escrevi um procedimento armazenado para executar esse trabalho através dos procedimentos armazenados [SSISDB]. [Catalog]. [Create_execution] e [SSISDB]. [Catalog]. [Start_execution] .... isso funciona bem quando executado sob minha conta (Eu sou um administrador de sistemas).
O procedimento armazenado falhou quando executado por um usuário normal, devido ao nível mais alto de permissões necessárias no SSISDB e no MSDB para enfileirar a execução, e o próprio pacote falhou porque está sendo executado no contexto de segurança (baixo).
O que eu tentei :
Tentei resolver o problema usando 'Executar como' no procedimento armazenado, mas isso falhou devido a problemas de encadeamento entre bancos de dados, sinalizador confiável etc.
Também tentei resolver o problema com tarefas do Agente para executar o pacote e apenas executando a tarefa do agente a partir do procedimento armazenado, no entanto, rapidamente entrei em um mundo de dificuldades envolvendo:
- A incapacidade de definir permissões de execução por trabalho
- A esperança de configurar esse acesso por meio de uma Função de servidor central para atender à mudança de equipe ao longo do tempo, e os trabalhos podem ter apenas um único usuário como proprietário
- O mundo sombrio das contas de proxy, credenciais em combinação com logins de autenticação sql etc.
Planos C e D
As únicas opções que posso pensar para mim são criar um logon dedicado do SQL Server com permissões elevadas e confiar nos usuários para não passarem as credenciais / perderem a capacidade de auditoria de quem agendou a importação (como esse problema é resolvido em outras áreas da a organização) ou criar um front-end da Web puramente para permitir que os usuários se autentiquem como sua conta de 'Função de servidor' e, em seguida, deixe o aplicativo Web executar o procedimento armazenado em uma segunda conexão (privilegiada).
Então....
Existe algum conselho sobre como:
- ter um pacote SSIS executar operações privilegiadas
- executado por um usuário com pouco privilégio (usando uma conta do Windows AD)
- de preferência onde o acesso para executar o trabalho seja gerenciado por meio de uma função de servidor central (não tenho a capacidade de criar um novo grupo de janelas para eles)
- e onde quaisquer novas contas intermediárias / proxy são contas de autenticação do SQL Server (novamente, capacidade muito limitada de fazer alterações no AD)
Entendo que há muitas partes móveis aqui (e algumas parecem lâminas giratórias), então deixe-me saber se há alguma outra informação que você sente que perdi.
Felicidades, Tim
Editar....
Hoje, criei um logon dedicado do SQL Server com permissões ssis_admin, criei três tarefas do SQL Server Agent pertencentes a esse usuário e atualizei o procedimento armazenado que meus usuários finais chamam para execute asesse usuário. Isso falhou devido à incapacidade de chamar create executioncomo um logon do SQL Server, requer uma conta do Windows.
Atualizei o procedimento armazenado dos usuários para execute asa conta do Windows que o SQL Server está executando como (uma conta de serviço do AD), concedeu-o ssis_admine falha com o erro
O contexto de segurança atual não pode ser revertido. Alterne para o banco de dados original onde 'Executar como' foi chamado e tente novamente.
Isso não vai a lugar nenhum rápido :(
create_executionporque preciso passar um parâmetro (um dos três valores) do sproc para o trabalho. Estou feliz por ter três sprocs / empregos, etc., se isso resolver. 2) Se ssis_admin é a menor função de privilégio que me leva até lá, eu estou aberto a isso ... é melhor que o sysadmin pelo menos e os resolva acidentalmente eliminando / desativando as tabelas do armazém em uso geral.
ssis_adminfunção permitiria que eles executassem os pacotes SSIS (os procs verificam a associação nas funções sysadmin ou ssis_admin), mas acho que ele será executado como eles e, portanto, não poderá fazer backups e tal. (Eu precisaria testar isso com certeza, nunca me lembro se ele é executado como eles ou a conta de serviço do SQL Server). No entanto, ser um membro do ssis_admin permite implantar pacotes e confusão com configurações que podem ou não ser boas. 2016 dá-nos papéis mais granulares, mas obviamente não muito uso aqui
EXECUTE ASpara permitir que eles executassem tarefas específicas por meio de sp_start_job. Diz o cara internet aleatório que é terrível para a segurança
create_executionou seja , precisam especificar parâmetros de execução para o "cenário pronto para os dados?" 2) É seguro assumir que você não está interessado em colocá-los na função ssis_admin?