Na minha organização, há escolas de pensamentos conflitantes em torno de contas de serviço. Isso surgiu porque eles desejam implantar o SQL Server com o único propósito de executar bancos de dados do SharePoint.
Um grupo acredita que uma conta de serviço diferente deve ser usada para cada aplicação de servidor e para cada ambiente (por exemplo, produção, UAT / teste, desenvolvimento). Portanto, neste exemplo, cada instalação do SQL Server para SharePoint teria sua própria conta de serviço para prod, UAT e dev. Suas razões são segurança e prevenção de interferências entre ambientes.
Outra pessoa acredita que as contas de serviço devem ser compartilhadas entre ambientes de produção e teste. Portanto, para o exemplo, haveria uma conta de serviço do SQL Server em prod, UAT e dev. (Não tenho certeza sobre o compartilhamento dessa conta entre diferentes aplicativos de servidor.) Seus motivos são a segurança novamente, pois há menos senhas para alterar e reduzir a complexidade.
Considerando segurança, disponibilidade e confiabilidade, proteção contra erros, gerenciamento de risco, etc ... qual deve ser a abordagem recomendada?
Obrigado!
Seguimos o primeiro grupo, que tem uma conta de serviço separada para cada ambiente & aplicação do servidor.
A principal razão é a segurança, mas outra boa razão é que, se algum trabalho está sendo feito em teste ou desenvolvimento, o que exige mudança de segurança, você sabe que isso não está afetando o ambiente de produção de forma alguma.
Por todos os meios, deixe seus ambientes de desenvolvimento e teste / UAT compartilharem as mesmas contas de serviço. Mas mantenha a produção separada. Além dos problemas de gerenciamento de mudanças já destacados em outras respostas, as pessoas de desenvolvimento e teste não devem ter nenhum negócio acessando sistemas de produção no curso normal dos eventos.
Certamente, as preocupações de segurança tendem a levar você a uma conta por aplicativo / serviço. No entanto, eu não acho que você precisa ir para o nível de ter contas diferentes para prod, UAT & dev embora. Isso significaria que a configuração teria que ser alterada quando você implantasse o aplicativo e isso poderia ser uma fonte de erro.
EDIT: Acabei de ver a resposta de Bravax e ele levanta um ponto válido sobre as alterações nas contas dev não afetando o sistema live.