Ontem fiz essa pergunta sobre a alteração do dbo de vários bancos de dados que tenho. A mudança faz sentido, mas quero ser claro.
Existe alguma boa razão ou circunstância para eu não definir o dbo de um banco de dados como [sa]?
Ontem fiz essa pergunta sobre a alteração do dbo de vários bancos de dados que tenho. A mudança faz sentido, mas quero ser claro.
Existe alguma boa razão ou circunstância para eu não definir o dbo de um banco de dados como [sa]?
Respostas:
Tornar o SA o proprietário de um banco de dados na verdade simplifica e / ou resolve várias coisas, mas pode ter algumas implicações de segurança.
Em particular, lembre-se de que, se o SA for o proprietário de um banco de dados, então dbo = 'SA'
. Isso significa que, entre outras coisas, quaisquer procedimentos no esquema [dbo] (que é o padrão) que possuem "EXECUTE As Owner" neles, na verdade estão sendo executados como SA. Isso não é tão ruim quanto parece, porque, a menos que você tenha marcado o banco de dados como TRUSTWORTHY, o SQL Server não permitirá que uma sessão ou tarefa saia do banco de dados com uma entidade representada no nível do servidor como essa.
Que traz o próximo ponto: não marcar esses bancos de dados como confiável, a menos que você é realmente , realmente certeza de que é seguro. Porque qualquer pessoa com a capacidade de criar procedimentos no esquema [dbo] pode executar como SA, em todo o servidor, se desejar.
Outro problema pode surgir porque muitos produtos e aplicativos que possuem seu próprio banco de dados SQL Server, geralmente especificam que o logon do aplicativo deve ser o DBO do banco de dados. Obviamente, você pode resolver isso fazendo com que o login do aplicativo seja 'SA'. Felizmente, também é óbvio que você nunca deve fazer isso, a menos que a Instância do SQL Server não seja usada para mais nada (mesmo assim, eu recomendaria isso).