Concedendo privilégios de SA para desenvolvedores na caixa de desenvolvimento

8

Apesar de nossos protestos veementes, nossa gerência decidiu que a equipe de desenvolvimento deve receber direitos 'sa' no servidor de desenvolvimento. O problema é que nós, o grupo de suporte do banco de dados, ainda somos responsáveis ​​por manter essa caixa.

Agora nos foi confiada a tarefa de apresentar uma lista de prós e contras para as equipes de desenvolvimento com esses privilégios aprimorados.

Por favor, adicione a esta lista:

DO - confinar atividades ao DB em desenvolvimento

NÃO --

  • alterar as configurações da instância SQL
  • sp_configure (incluindo cmdshell)
  • adicionar / alterar / excluir quaisquer configurações de segurança
  • adicionar / alterar / excluir objetos de banco de dados
  • adicionar / alterar / excluir objetos do servidor, como dispositivos de backup e servidores vinculados
  • adicionar / alterar / excluir replicação
  • adicionar / alterar / excluir planos de manutenção
  • toque em qualquer banco de dados que não pertença à sua equipe

Qualquer indicação de ferramentas disponíveis para rastrear as atividades desses usuários será muito apreciada.

sql-server sql-server-2005 permissions Raj
fonte
11
Quais tarefas eles precisam executar que exigem privilégios de nível superior da SA?
Gostaria de pensar que db_owner seria tudo que eles precisam ...
5
OK, se eles estão sendo aconselhados a NÃO "adicionar / alterar / excluir objetos de banco de dados", o que eles devem fazer? O objetivo de ter uma caixa de desenvolvimento não é que eles possam quebrá-la?
Stuart Ainsworth
Estes são desenvolvedores de aplicativos. Eles precisam de privilégios 'sa' para poder depurar procedimentos armazenados no Dev Studio. A decisão já foi tomada pela gerência e eles não estão dispostos a ceder. Estamos tentando minimizar a dor de cabeça potencial
2
+1 para a pergunta, já que encontrei esse problema algumas vezes. Outra solução: dê aos desenvolvedores uma VM em área restrita com SQL, da qual eles são 100% chefes. Eles também são 100% responsáveis por mantê-la viva :) -> é incrível o quão rápido os DEVs aprender a não quebrar o seu próprio sistema de :)
Martin S. Stoller

Respostas:

8

Se não for tarde demais, uma opção de compromisso que eu vi que funcionou bem é em vez de atualizar as permissões ou substituir as contas existentes dos desenvolvedores, crie uma conta separada que é usada apenas quando eles precisam de permissões elevadas.

Portanto, normalmente eles funcionam em contas "restritas" individuais (que eu uso livremente porque essas contas restritas ainda precisam de algumas permissões pesadas - por exemplo, criar, soltar, alterar para tabelas). Porém, nas raras ocasiões em que eles acham que precisam sa, eles podem fazer login usando esta conta. Em seguida, você pode sinalizar a conta em seus logs e fazer um monitoramento extra nela. Você deu aos desenvolvedores o acesso que eles pediram, mas de uma maneira um pouco mais controlável.

Eventualmente, se houver abuso, os logs desta conta poderão ser usados ​​como evidência para removê-la.

Joel Coehoorn
fonte
6

Diz aqui (MSDN) que você precisa do sysadmin (sa) para depurar no SQL Server 2005.

No entanto, essa pergunta SO mostra outro caminho sem sa, que é o que eu pensava inicialmente. Simplesmente permita que eles funcionemsp_sidedebug

Eu também sugiro dar a eles o SQL Express local, que também resolve outros problemas ...

(editado com mais informações)

Editar, após a resposta de W. Craig Trader

Outros problemas com os direitos "sa", na pior das hipóteses:

  • desenvolvedores criarão assemblies CLR não confiáveis
  • eles usarão xp_cmdshell
  • todas as ações estão no contexto da conta de serviço do servidor sql
  • eles assumirão um direito para a conexão do cliente
  • etc etc

por exemplo xp_cmdshell 'scm -Action 6 -Server PRODSERVER'

gbn
fonte
11
A resposta para os desenvolvedores que codificam fora das linhas é fazer a integração contínua com o bloqueado ', como será executado pelas permissões dos usuários, e falhará na construção de acordo. Faça com que o servidor de criação recrie o banco de dados do zero e preencha-o com dados de teste (todos do SCM, é claro). (No meu caso, eu usei exatamente o mesmo código que o instalador do aplicativo usaria para criar um novo banco de dados, testando assim o instalador, bem como a aplicação.)
11
@Craig trader: não vai funcionar. Para reformular minha resposta antiga, os desenvolvedores não são confiáveis ​​e as integrações integradas não detectam todos os casos. Sou desenvolvedor dba: um macaco de código cliente é meu inimigo. Na minha empresa, eu ganhar .... sua minha composição e eu lidar com menor denominador comum ...
GBN
Aparentemente, sua milhagem pode variar. Na minha experiência, geralmente tive que fazer um pouco de treinamento / orientação para explicar como e por que as coisas são feitas, mas depois disso as coisas geralmente correm razoavelmente bem. Obviamente, eu sempre insisto em dizer que as únicas compilações que vão além do desenvolvimento são aquelas que provêm do servidor de compilação rigidamente controlado - se o código não for compilado lá, é um problema com o seu código (ou com seus testes) e não com o configuração. Fiz isso com pequenas equipes e grandes projetos, em muitas empresas, e sempre com sucesso.
4

Como sugestão, tenho que configurar o Gerenciamento Baseado em Políticas e impor todo o seu 'fazer' e 'não' como regras de política. Isso ajudaria muito a proteger a instância.

Eu também implantaria a auditoria de alterações DDL, consulte Auditoria no SQL Server 2008 , não apenas como um impedimento, mas principalmente como um sistema de rastreamento de alterações. Quando algo é ferrado, pelo menos você saberá o que mudou.

Remus Rusanu
fonte
3

Se for o servidor DEVELOPMENT, qual é o problema dos desenvolvedores poderem ter acesso total? Dizer aos desenvolvedores que você não pode adicionar / remover / alterar objetos do banco de dados (por exemplo: tabelas, colunas, índices) é como dizer a eles "Você pode ter um compilador, mas não tem permissão para executá-lo". Parece-me que os desenvolvedores desejam / precisam acessar sua própria instância de banco de dados especificamente para permitir que testem diferentes métodos de solução de problemas SEM ter que mexer com os bancos de dados PRODUCTION ou TEST. Você deve incentivar esse tipo de comportamento, não desencorajá-lo.

Alguns podem sugerir que os desenvolvedores trabalhem com instâncias locais do SQL Express, mas, embora o SQL Express para cada desenvolvedor possa resolver certos problemas, ele tem limitações e características de desempenho diferentes das do SQL Server completo em um servidor separado.

O que você DEVE fazer é instituir um agendamento de backup regular (pelo menos noturno) e trabalhar com os desenvolvedores para garantir que eles saibam como iniciar backups não agendados e restaurar a partir de backups, para que o tempo de inatividade seja minimizado em caso de problemas.

Craig Trader
fonte
Sua analogia está completamente errada. O que acontece é que eles se esquivam e depois choram quando não conseguem migrar para outros servidores bloqueados. Sou desenvolvedor DBA, é claro :-)
gbn 23/10/09
Então, um pouco de educação está em ordem. Sou um desenvolvedor que tem sido um DBA com muita frequência. Com um pé nos dois mundos, geralmente tem sido meu trabalho ensinar os dois lados a coexistir. Afinal de contas, são os usuários que são o inimigo, não o DBAs ou desenvolvedores ...
Também existem coisas como planos de manutenção a que eles não deveriam ter acesso.
Joel Coehoorn
11
O problema é que temos vários grupos de desenvolvedores e este servidor hospeda todos os seus bancos de dados. Esse grupo que exige direitos 'sa' possui apenas 33% dos DBS. A preocupação é que eles possam se esquivar e derrubar o servidor, impactando também outros grupos. A empresa não deseja obter hardware separado para eles, a menos que possamos provar que eles estragaram tudo.
2
Isso é ridículo. Cada grupo de desenvolvimento deve ter seu próprio servidor, para que ninguém pise nos outros. Hoje em dia, o hardware é praticamente gratuito e o software quase tão barato quanto o hardware. E se sua organização é grande o suficiente para ter vários grupos de desenvolvimento, deve usar a virtualização de servidores, o que tornaria tudo isso ainda mais fácil.
3

É o dev servidor, não o servidor grupo de apoio DB, ou o servidor de produção. Mantenha um bom backup / imagem e deixe os desenvolvedores saírem. Deixar o DBA controlar o devbox é como deixar o rabo abanar o cachorro. Está aí para os desenvolvedores fazerem o trabalho do desenvolvedor. Às vezes, isso envolve quebrar as coisas, soltar tabelas e colocá-las de volta com configurações diferentes. As caixas de desenvolvimento sempre estarão em mau estado de conservação após algum tempo, é isso que fazemos. Se não sabemos onde um problema está ocorrendo, tentamos coisas diferentes. Alguns deles são fáceis de desfazer, outros nem tanto.


fonte
O problema aqui é que é fácil para os desenvolvedores esquecerem que os aplicativos criados não terão os mesmos direitos o tempo todo. Sim, dê a eles sa, mas faça com que não sejam sa por padrão, para que eles saibam quando estão fazendo algo que precisará de um pouco de trabalho extra para implantar corretamente.
Joel Coehoorn
1

Eu não acho que eles precisam de privilégios de SA na caixa Desenvolvimento. Em quase todos os casos, eles podem ficar sem.

Eu acho que uma boa opção é ter a edição dev local instalada.

questão:

Você não deseja que os desenvolvedores adicionem / alterem / excluam objetos de banco de dados? !! Como eles vão se desenvolver?

Raj More
fonte
Desculpe a confusão. O que eu quis dizer com esse item foi que os desenvolvedores não devem alterar as configurações do banco de dados nem descartá-los.
1

Exigimos que todas as alterações na estrutura do banco de dados sejam feitas com scripts (mesmo no dev) e salvas no subversion. Em um cronograma definido, atualizamos o dev do prod e eles precisam executar novamente seus scripts para voltar ao local onde estavam no ciclo de desenvolvimento. Isso ajuda a garantir que tudo seja feito por meio de scripts e que eles tenham scripts prontos na hora da implantação.

Eu sei que em 2008 você pode configurar DDL Triggers para rastrear alterações estruturais do banco de dados. Você pode fazer isso em 2005? Dessa forma, pelo menos você pode descobrir quando alguém altera uma configuração que fez isso e descobrir o porquê.

HLGEM
fonte
0

A auditoria do SQL Server é o que você deseja, mas, se você fará toda a criação de objetos de banco de dados para eles, por que os desenvolvedores precisam de sa?

http://msdn.microsoft.com/en-us/library/cc280526.aspx

Vinko Vrsalovic
fonte