Ayer hice esta pregunta sobre cambiar el dbo de múltiples bases de datos que tengo. El cambio tiene sentido, pero quiero ser claro.
¿Hay alguna buena razón o circunstancia por la que no debería establecer el dbo de una base de datos en [sa]?
Ayer hice esta pregunta sobre cambiar el dbo de múltiples bases de datos que tengo. El cambio tiene sentido, pero quiero ser claro.
¿Hay alguna buena razón o circunstancia por la que no debería establecer el dbo de una base de datos en [sa]?
Respuestas:
Hacer que SA sea el propietario de una base de datos en realidad simplifica y / o resuelve varias cosas, pero puede tener algunas implicaciones de seguridad.
En particular, recuerde que si SA es el propietario de una base de datos, entonces dbo = 'SA'
. Esto significa que, entre otras cosas, cualquier procedimiento en el esquema [dbo] (que es el predeterminado) que tiene "EJECUTAR como propietario" en ellos, en realidad se está ejecutando como SA. Eso no es tan malo como parece, porque a menos que haya marcado la base de datos como CONFIABLE, SQL Server no permitirá que una sesión o tarea salga de la base de datos con un principal de nivel de servidor suplantado como ese.
Lo cual nos lleva a la siguiente cuestión: nunca se marcan dichas bases de datos como digno de confianza, a menos que seas muy , muy seguro de que es seguro. Porque cualquiera que tenga la capacidad de crear procedimientos en el esquema [dbo] puede ejecutar como SA, en todo el servidor, si así lo desea.
Puede surgir otro problema porque muchos productos y aplicaciones que tienen su propia base de datos de SQL Server, a menudo especifican que el inicio de sesión de su aplicación debe ser el DBO de la base de datos. Obviamente, podría resolver eso haciendo que su inicio de sesión de la aplicación sea 'SA'. Con suerte, también es obvio que nunca debe hacer eso, a menos que esa instancia de SQL Server no se use para otra cosa (incluso entonces, recomendaría no hacerlo).