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

Executando o SQL Server 2005 e 2008 no Windows 2008 R2.

Vamos reduzir os privilégios de produção para desenvolvedores - e eu gostaria de fazer o mesmo por mim como um DBA , limitando os direitos de produção e aumentando quando necessário .

Meu principal objetivo seria eliminar erros estúpidos - cometidos por DBAs , os devotos terão acesso de leitura na produção, no máximo. Gostamos de agir como super-heróis que não podem cometer erros, mas não ter direitos de produção o tempo todo faz sentido e é uma prática recomendada, recomendada por alguns.

Qual é a melhor abordagem? O que será menos doloroso para usar no dia a dia e durante as instalações?

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

Eu também estaria interessado em reduzir as permissões de login do sistema operacional / remoto - mas estou mais preocupado com os direitos do banco de dados.

Suponho que precisaríamos de privs elevados para executar rastreamentos como sa, e possivelmente para alguma limpeza de propriedade antes de removermos os direitos de SA do nosso antigo login. Que outros problemas podemos esperar?

Obrigado pelo seu conselho e por compartilhar suas experiências!

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. Esse tipo de coisa é uma das primeiras coisas que você terá que fazer para conformidade com SOX .

Para o tipo de direitos que IDs executado sob, os únicos direitos que realmente deve ter são db_datareader, db_datawritere explícito GRANT EXECUTE ON x TO y(para cada proc armazenados e função definida pelo usuário xpara o ID do usuário y).

Se você precisar executar rastreamentos na 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 bloqueado como a produção e, se for necessário executar rastreamentos, restaure um backup do db do prod no controle de qualidade e execute os rastreamentos lá. Novamente, se você tiver requisitos SOX, HIPAA ou PCI-DSS , será melhor limpar os dados do produto antes de restaurá-los no controle de qualidade.

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

Dê a eles o logon e visualize os direitos de dados; no entanto, para executar tarefas do 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 aos danos que poderiam causar inadvertidamente. Restaura e a execução da DML exigida para execução com o login de autenticação SQL separado.

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

A agência governamental atual com a qual estou trabalhando tem cada administrador de servidor / banco de dados com privilégios elevados acima do usuário padrão, mas não como 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 o controle de qualidade restaurado no servidor de produção) e isso não será resolvido por direitos restritos ou vários logins. Fazer coisas potencialmente destrutivas em pares é uma maneira de minimizar os riscos.

Eu estou supondo que precisaríamos de privs elevados para executar traços como sa

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

No começo, sugiro que você execute todos os privilégios em um ambiente de desenvolvimento ou controle de qualidade em que não há problema se o acesso for removido por algum tempo. Você precisará verificar se os aplicativos não terão problemas com a segurança.

Vou lhe contar nossa abordagem interna:

• todos os aplicativos usam um usuário de domínio único 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 para desenvolvedores no cluster de banco de dados principal. Para qualquer outra idéia que eles tenham, eles usarão os bancos de dados do servidor de relatório que são cópias (feitas usando o Log Shipping) dos principais bancos de dados do servidor 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 do DBA, temos um grupo de domínio com todos os privilégios na máquina e no servidor (administrador na máquina Windows e sysadmin no servidor sql)

• para instalações, temos um usuário SQL 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ções separadas

• existem algumas exceções ocasionais para desenvolvedores experientes, mas após a necessidade deles ser removida, removemos o acesso - eles recebem permissões com base no logon do domínio, para que possamos monitorar as conexões nas exibições de rastreios / ddl e quaisquer alterações possíveis com os gatilhos ddl.

Quanto à maneira de fazer tudo isso funcionar com os logins e usuários - no Management Studio, na pasta de segurança do servidor, você cria todos os logons 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 um script da ação, verá que, inicialmente, será criado um logon do servidor, um usuário do banco de dados conectado a esse logon e, em seguida, designado uma função de banco de dados para esse usuário. Você pode manter o script em seu conjunto de scripts, para verificar sempre que usuários devem estar vivos e chutando e quais não devem estar.

No SQL server, você pode criar um usuário de banco de dados e atribuir a ele uma database rolepermissão de leitura / gravação / propriedade. Depois que o usuário é 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. Depois que o usuário stan é migrado para produção, você pode retirá-lo do 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.