Início / dba / Perguntas / 63657
Accepted
Dave Mason
Asked: 2014-04-23 08:01:30 +0800 CST

Função de servidor SysAdmin e grupos do Active Directory

  • 772

Tenho lutado para encontrar informações sobre práticas recomendadas ou qualquer conselho sobre grupos do Active Directory que forneçam aos membros do grupo a função de servidor SysAdmin. Estou em um novo emprego onde sou o único SQL Server DBA para 50 a 100 instâncias de SQL. Há um outro administrador de sistema (rede) que terá a função de servidor SysAdmin. Pode haver outros no futuro também (podem ser DBA's ou não).

Estou imaginando duas opções:

Opção 1 : criar um grupo no Active Directory, adicionar a mim e a qualquer outra pessoa ao grupo conforme necessário, criar logins do SQL Server em cada instância do SQL Server para o grupo AD e atribuir aos logins a função de servidor SysAdmin.

Isso é conveniente e permite alguma flexibilidade. Mas parece um grande risco de segurança. Como DBA, não tenho controle total sobre quem está dentro (ou fora) do grupo AD. Atualmente, cada instância do SQL Server possui alguns logins com a função SysAdmin. Quero tirar o SysAdmin de todos eles, exceto de mim, o administrador do sistema de rede e sa. Se eu realizar essa tarefa e implementar a Opção 1, não terminarei melhor do que onde comecei.

Opção 2 : use logins individuais de autenticação do Windows (conta AD) em cada SQL Server e dê a cada um a função de servidor SysAdmin.

Isso não é tão conveniente, mas apenas duas pessoas/logins do AD têm privilégios de SysAdmin. Contanto que nenhum de nós conceda associação de função SysAdmin a outros, deve haver um certo nível de ordem.

Qual opção é preferida? Existem outras opções que eu esqueci?

sql-server sql-server-2008-r2

2 respostas

  1. As contas individuais serão muito mais difíceis de administrar. Eles oferecem um controle mais granular sobre o acesso, mas você não pode impedir a entrada dos administradores do Active Directory. Qualquer pessoa que tenha direitos de administrador local em seu servidor pode obter acesso de administrador de sistema à instância . E, como um DBA muito bom me disse uma vez, se você não pode confiar em seus administradores de domínio, você tem problemas maiores em suas mãos.

    Ao abstrair seu acesso aos grupos do AD, você obtém dois benefícios:

    1. Mais fácil de gerenciar grupos de acesso e direitos com base em funções, combinado com controle de acesso estratificado para outros ativos usando esses grupos AD.
    2. Forneça uma auditoria mais consistente, pois você só precisará mostrar o acesso por grupo de AD e, em seguida, quem está contido nesse grupo.
    • 3
  2. Best Answer

    Eu odeio responder minha própria pergunta, mas decidi que a Opção 2 é o caminho a seguir para mim. Finalmente encontrei algumas informações de "práticas recomendadas", embora estejam relacionadas à conformidade com o PCI DSS . Foi uma ótima leitura com ótimas recomendações. Não posso implementar todos eles e talvez nunca seja aprovado em uma auditoria PCI, mas definitivamente melhorarei a segurança. Por que vale a pena, aqui estão as recomendações relacionadas ao SYSADMINpapel:

    Uma etapa crítica para restringir o acesso aos dados do titular do cartão é limitar o número de usuários privilegiados atribuídos à função de servidor sysadmin. Por padrão, o grupo BUILTIN/Administradores não é membro da função sysadmin no SQL Server 2008 R2. O PCI DSS suporta diretamente o conceito de melhor prática do modelo de acesso de “menor privilégio”; portanto, recomendamos o seguinte:

    • Os membros da função sysadmin só devem fazer login usando logins individuais do Windows
    • O número de usuários atribuídos à função sysadmin deve ser mínimo
    • A função sysadmin deve ser atribuída com base na função de trabalho
    • Os membros dos logins do Windows da função sysadmin devem ter acesso individual ao SQL Server em vez de um grupo AD mapeado
    • Os membros da função sysadmin não devem ser administradores locais do Windows
    • Os membros da função sysadmin não devem ter acesso a nenhuma pasta ou compartilhamento de arquivo no servidor ao qual o serviço do SQL Server tem acesso, como as pastas que contêm os dados e arquivos de log e diretórios nos quais os bancos de dados ou as chaves de criptografia podem ser copiados
    • Um administrador local ou de domínio do Windows não deve ter acesso de administrador de sistema ao SQL Server
    • 0

relate perguntas