Ao instalar o SQL Server, você especifica os administradores do SQL Server , ou seja, a lista de usuários inicialmente na função sysadmin. Por padrão, esta lista contém o usuário atual.
(Imagem citada em https://msdn.microsoft.com/en-us/library/dd578652.aspx .)
Esse valor padrão me parece estranho. Não BUILTIN\Administratorsseria uma escolha mais sensata do que o usuário atual? Afinal, o objetivo da autenticação do Windows não é não ter que gerenciar dois diretórios de usuários/grupos separados? E os administradores locais podem obter direitos de administrador de sistema de qualquer maneira, se quiserem, portanto, também não é realmente um recurso de segurança.
Por outro lado, o SQL Server foi escrito por pessoas muito mais inteligentes do que eu, portanto, pode haver uma boa razão para esse valor padrão. O que é isso?
Você está certo: os administradores do sistema podem obter acesso de administrador do sistema, mas você encontrará entradas no rastreamento padrão para essa ação. Além disso, requer reiniciar o serviço pelo menos duas vezes, o que dificilmente passaria despercebido.
Não conceder privilégios de administrador de sistema a BUILTIN\Administradores é uma alteração introduzida no SQL Server 2008. Na minha opinião é uma boa ideia: permite a separação de funções entre administradores de servidor e administradores de SQL Server.
O principal efeito indesejado de ter BUILTIN\Administrators em sua função de administrador de sistema é a perda de controle, que pode se manifestar com uma ou mais das seguintes coisas irritantes:
Para encurtar a história, os administradores do Windows têm um conjunto de habilidades diferente e uma mentalidade diferente, sem mencionar responsabilidades diferentes: deixá-los gerenciar suas instâncias do SQL Server não é uma boa ideia.
Minha sugestão é criar um grupo do Windows para seus DBAs e adicionar esse grupo à função sysadmin a cada nova instalação do SQL Server.
Usar o grupo de administradores locais tem sido o padrão por muito tempo. Mas, principalmente em grandes ambientes corporativos, você tem uma equipe de operações para Windows e uma equipe de operações separada para SQL Server. Permitir que todos tenham acesso facilmente (!) pode ser considerado um problema de segurança. Permitir apenas o usuário atual pode ser explicado com "seguro por padrão".
Como você disse, os administradores locais podem obter direitos de administrador de sistema. Mas na maioria dos casos eles deixarão vestígios de fazer isso.
Só para acrescentar, a remoção de
BUILTIN\AdministratorseNT AUTHORITY\SYSTEMde ser administrador de sistema padrão foi para a mudança na segurança dos produtos da Microsoft; indo para asecure by defaultmetodologia. Tenho certeza de que parte da conformidade teve influência na escolha da equipe da Microsoft e do SQL Server por fazer isso também.Na verdade, o principal que permitiu um backdoor em sua instância foi o uso da
SYSTEMconta como conta de serviço. Esse backdoor era possível sem a reinicialização do serviço do SQL Server e passaria despercebido, a menos que o monitoramento estivesse envolvido no servidor. Que no SQL Server 2005 não era suportado se você removesse esta conta dasysadminfunção.Avanço rápido agora para o Windows Server 2012, uma etapa adicional para segurança que também removeu o backdoor foi com contas virtuais por padrão para cada serviço ou configuração de contas de serviço gerenciadas. É difícil, se não impossível, usar
psexecpara "representar" uma conta virtual ou MSA que eu conheço agora.