Temos alguns aplicativos em nossa rede (antes do meu tempo) que usam a conta SA em sua string de conexão do SQL Server. Está codificado no código-fonte e, por qualquer motivo, não podemos alterá-lo - minha pergunta não é sobre por que devemos alterá-lo, mas sobre como contornar isso.
Estou pensando em renomear a conta SA para outra coisa (como "SysAccount" ou algo parecido, e dar a ela uma nova senha) e, em seguida, criar uma nova conta chamada "SA" com a senha antiga e conceder a ela os direitos apropriados para o aplicativo (obviamente não é membro da função sysadmin). Existem armadilhas para fazer isso? Existem problemas conhecidos que o SQL Server terá se a conta chamada SA não for realmente um administrador de sistema?
Presumo que, como estou apenas renomeando a conta, estou seguro - ainda terá um uid de 0x01 e testei isso e é fisicamente possível e parece funcionar corretamente nos testes, mas quero ter certeza Não estou negligenciando nada que claramente quebrará como resultado. Se ele quebrar as coisas, sempre posso excluir o novo SA e renomear o antigo de volta para desfazer o dano, mas esperando evitar tentar e falhar.
Estou usando o SQL Server 2012, embora suspeite que a mesma resposta se aplique a qualquer versão moderna. Eu vi o bug em que a atualização de 2005 para 2008 pode quebrar se você fizer isso , mas imagino que isso esteja resolvido há muito tempo.
Ele pode ser renomeado. Muitas vezes, é considerada uma prática recomendada para segurança, mas pode haver falhas do SQL Agent se você não abandonar o serviço do agente ou alterar os proprietários do trabalho, e também posso encontrar relatórios sobre atualizações do Server 2008 .
Isso é o suficiente para me fazer não querer renomeá-lo. Eu digo que atribuir uma senha complexa e desabilitar o login é suficiente, e geralmente é uma opção melhor, pois na verdade fecha a vulnerabilidade em vez de apenas ofuscar. Ofuscação lhe dá muito pouca segurança. No futuro, se você realmente precisar de um administrador de sistema de autorização SQL, crie uma nova conta para ele. Isso não é particularmente difícil. Você tem a mesma superfície de ataque que renomear sem ter que lembrar que o SID 0x01 não é mais sa (mesmo que ainda seja sa). E, claro, como o SID nunca realmente muda, não é difícil descobrir qual conta é o SID 0x01 (ou um membro da função sysadmin, nesse caso). Claro, se possível, nem use o modo misto.
Sim, o problema de 2005 a 2008 foi corrigido. Agora você pode desabilitar a conta SA, pode renomeá-la para SomethingElse, pode fornecer uma senha chinesa ou pode misturar e combinar.
Consulte: http://www.mssqltips.com/sqlservertip/2221/different-ways-to-secure-the-sql-server-sa-login/
Observe que, como o SID de SA (seja qual for o nome que você renomear) ainda permanece, o novo nome pode ser descoberto por:
Você não pode se livrar do login de administrador integrado, é claro. Portanto, você só precisa decidir se os efeitos colaterais menores são um problema para você.
Eu nunca uso "SA" para o meu trabalho, mas uso minha própria conta de domínio especial com permissões de administrador de sistema.
Posso pensar em uma coisa que pode causar problemas - a chamada do aplicativo
IS_SRVROLEMEMBER('sysadmin')para verificar se a conta é membro da função de servidor fixa 'sysadmin'? Nesse caso, isso não funcionará se 'sa' se tornar uma conta diferente.