Quaisquer dicas sobre como reduzir meus privilégios na produção, mas não tornar meu trabalho excessivamente difícil

A princípio, sugiro que você faça todo o jogo de privilégios em um ambiente de desenvolvimento ou controle de qualidade onde não haja problema se o acesso for removido por algum tempo. Você precisará verificar se os aplicativos não terão problemas de segurança.

Vou te contar nossa abordagem interna:

• todos os aplicativos usam um único usuário de domínio que recebe as permissões necessárias em um banco de dados (geralmente a função de banco de dados db_owner).

• para leitura ocasional de dados, usamos um login SQL. Para esse usuário, atribuímos a função de banco de dados - db_datareader. É aqui que termina o acesso dos desenvolvedores ao cluster de banco de dados principal. Para qualquer outra ideia que eles tenham, eles usarão os bancos de dados do servidor de relatórios, que são cópias (feitas usando Log Shipping) dos bancos de dados do servidor principal feitos à meia-noite. Para não matar o servidor de relatórios com consultas ad hoc matadoras, usamos as alocações de grupos de recursos para memória e CPU.

• para a equipe DBA temos um grupo de domínio que tem todos os privilégios na máquina e no servidor (admin na máquina windows e sysadmin no sql server)

• para instalações, temos um usuário SQL que é db_owner nos bancos de dados que usamos ao executar as atualizações - usamos gatilhos DDL para monitorar alterações de esquema e devemos ver quais alterações foram feitas durante a instalação ou como alteração separada

• existem algumas exceções ocasionais para desenvolvedores experientes, mas depois que sua necessidade é atendida, removemos seu acesso - eles recebem permissões com base em seu login de domínio, para que possamos monitorar conexões em visualizações de rastreamentos/ddl e quaisquer possíveis alterações com os gatilhos ddl.

Quanto à maneira de fazer todo o trabalho com os logins e usuários - no Management Studio, na pasta de segurança do servidor, você cria todos os logins necessários e, em seguida, associa-os aos seus bancos de dados e atribui a eles as funções de que precisam. Se você criar o script da ação, verá que inicialmente será criado um login de servidor, em seguida, um usuário de banco de dados conectado a esse login e, em seguida, atribuída uma função de banco de dados para esse usuário. Você pode manter o script em seu conjunto de scripts, para poder verificar todas as vezes quais usuários devem estar ativos e chutando e quais não devem.

Idealmente, para um banco de dados de produção operacional, você não deseja que os desenvolvedores tenham acesso ao servidor ou a qualquer banco de dados nele. Esse tipo de coisa é uma das primeiras coisas que você terá que fazer para estar em conformidade com a SOX .

Para o tipo de direitos sob os quais os userIDs são executados, os únicos direitos que eles realmente deveriam ter são db_datareader, db_datawritere explícitos GRANT EXECUTE ON x TO y(para cada procedimento armazenado e função definida pelo usuário xpara o userID y).

Se você precisar executar rastreamentos em produção, terá alguns problemas e será necessário um Great Wall of Text™ para explicar tudo. Minha primeira recomendação é ter um ambiente de controle de qualidade que seja bloqueado, assim como a produção e, se for necessário executar rastreamentos, restaure um backup do banco de dados prod para controle de qualidade e execute os rastreamentos lá. Novamente, se você tiver requisitos SOX, HIPAA ou PCI-DSS , é melhor limpar os dados de produção antes de restaurá-los para o controle de qualidade.

Atualmente, temos um grupo do Windows para DBAs que tem direitos sobre todos os nossos servidores e bancos de dados.

Dê a eles direitos de logon e visualização de dados; no entanto, para executar tarefas de DBAly, use um login separado com privilégios elevados. Conheço um cliente financeiro que faz isso - os logins regulares baseados na autenticação do Windows eram limitados no dano que poderiam causar inadvertidamente. Restaura e executa DML necessário executando com o login de autenticação SQL separado.

Uma agência governamental com a qual trabalhei usou 2 logins separados para cada administrador de servidor/db. Portanto, se Tangurenafosse o login do meu domínio (esse login teria Userprivilégios regulares), TangurenaAdminseria meu Administratorlogin separado. Você terá problemas se usar sua conta de administrador o tempo todo, mas ela não tiver permissões para outras coisas (como nenhum e-mail. Oh, você diz isso como se fosse uma coisa ruim... ).

A agência governamental atual com a qual estou trabalhando tem cada administrador de servidor/db com privilégios elevados acima do usuário padrão, mas não exatamente administrador (pense nisso como o PowerUsergrupo). As funções de administrador de domínio são executadas com uma conta de administrador de domínio compartilhada.

Um erro comum é restaurar o banco de dados errado (como QA restaurado no servidor de produção), e isso não será resolvido por meio de direitos restritos ou logins múltiplos. Fazer coisas potencialmente destrutivas em pares é uma forma de minimizar os riscos.

Acho que precisaríamos de privilégios elevados para executar rastreamentos como sa

Não. Você só precisa das permissões ALTER TRACE:
http://msdn.microsoft.com/en-us/library/ms187611.aspx

No servidor SQL, você pode criar um usuário de banco de dados e atribuir a ele uma database rolepermissão de leitura/gravação/propriedade. Assim que o usuário for migrado para a produção, você pode acessar o usuário do banco de dados que foi migrado e desmarcar as funções que não deseja que ele tenha. Por exemplo, digamos que o usuário stan seja membro de db_owner (propriedade do banco de dados) em teste. Uma vez que o usuário stan é migrado para produção, você pode tirá-lo de db_owner e atribuir apenas uma função de db_datareader (somente leitura) a ele.

No SQL 2005+, um controle mais granular pode ser feito com o schema. Verifique este link no esquema para obter mais detalhes.