¿Cuál es el propósito del 'propietario' de la base de datos?

Hoy, mientras solucionaba un problema de agente de servicio, descubrí que el propietario de la base de datos era el inicio de sesión de Windows de un empleado que había abandonado la empresa. Su inicio de sesión se había eliminado y, por lo tanto, las notificaciones de consulta fallaban.

Supuestamente, la mejor práctica para lidiar con esto es hacer que 'sa' sea el propietario de la base de datos. Lo cambiamos y eso despejó la cola.

Mi pregunta (muy elemental): ¿cuál es el propietario de la base de datos y cuál es su propósito?

Existe cierta confusión entre los conceptos de base de datos de 'dbo' (un usuario) y 'db_owner' (una función fija) en un lado y el concepto de instancia de 'propietario de la base de datos' en el otro lado. El 'dbo' y 'db_owner' a menudo se llaman 'propietario de la base de datos'. En lo que está preguntando, está hablando del propietario de la base de datos como el principal del servidor que posee la base de datos.

La teoría es la siguiente: todo lo que se puede otorgar permisos es un "asegurable" . Todos los objetos asegurables tienen un propietario. El propietario de un asegurable tiene control absoluto sobre el asegurable y no se le puede negar ningún privilegio. Los asegurables de nivel de instancia son propiedad de los principales del servidor (inicios de sesión). Los asegurables de nivel de base de datos son propiedad de los directores de bases de datos (usuarios). El principal viene en dos sabores: primario (identidad) y secundario (membresía). Los asegurables a nivel de servidor son propiedad predeterminada del principal del servidor primario actualmente registrado. Los asegurables de nivel de base de datos son propiedad por defecto del principal de la base de datos actual, excepto por los objetos vinculados al esquema que por defecto son propiedad del propietario del esquema. Todos los elementos de seguridad admiten la cláusula de AUTORIZACIÓN en el momento de la creación para imponer un propietario diferente.ALTER AUTHORIZATION luego se puede usar para cambiar el propietario de cualquier asegurable.

Dado que la base de datos es un nivel de servidor asegurable, se deduce que, de forma predeterminada, será propiedad del principal primario que emitió la instrucción CREATE DATABASE. Es decir. El inicio de sesión NT del empleado fallecido.

Entonces su pregunta es realmente " ¿Por qué los asegurables necesitan un propietario? ". Porque el dueño es la raíz de la confianza. Es el propietario quien otorga, niega y revoca el permiso sobre el objeto. ¿Se puede diseñar un sistema de seguridad sin los propietarios de bienes asegurables? Probablemente sí, pero tendría que haber algún mecanismo para reemplazar el papel que juegan los propietarios en el modelo actual. Por ejemplo, considere que los objetos de seguridad de papá no tienen un propietario (por ejemplo, en lugar de ser propietario de un seguro, al creador original solo se le otorga CONTROL sobre él) sería posible crear un seguro y revocar el acceso a él para todos , incluido él mismo. El requisito de un propietario evita este problema ya que un propietario no puede encerrarse.

El efecto secundario poco conocido de CREATE DATABASE de crear una base de datos asegurable (la base de datos) propiedad del inicio de sesión NT original ha quemado muchos antes. Las reglas son las mismas para cada asegurable, pero algunos factores agravan los problemas del propietario de la BASE DE DATOS:

• los otros asegurables de nivel de servidor (punto final, rol de servidor, inicio de sesión) rara vez se usan, se mueven, etc.
• los asegurables de nivel de base de datos generalmente terminan siendo propiedad de dbo(el principal de la base de datos), o algún otro principal de la base de datos, y por lo tanto el propietario está contenido en la base de datos
• Tener la propiedad de la base de datos predeterminada para el principal primario de NT crea un problema de contención (el propietario es un SID de NT administrado por AD y no viaja con los archivos de la base de datos, la cuenta de NT puede ser extraviada, etc., etc.)
• Lo más importante: el propietario de la base de datos tiene efectos secundarios importantes, específicamente EXECUTE AS context. Este problema posterior es lo que quema a la mayoría de los usuarios. Dado que Service Broker hace un uso extensivo de EXECUTE AS (la entrega del mensaje tiene un contexto implícito EXECUTE AS, así como la activación de cola que tiene uno explícito), generalmente los usuarios de Service Broker descubren primero este problema.

Por cierto, felicitaciones por investigar y solucionar su problema original :)

La base de datos owneres un retroceso a un tiempo antes de que se introdujeran los esquemas (correctos) en SQL Sever 2005.

Básicamente, el propietario de una base de datos es el predeterminado dbo(propietario de la base de datos) de la base de datos, siendo la base de datos en sí misma un objeto de base de datos .

De los documentos de SQL Server 2000 ...

El dboes un usuario que tiene permisos implícitos para realizar todas las actividades en la base de datos.

En versiones anteriores de SQL Server, cuando un esquema no podía "poseer" un objeto ( o más bien debería decirse que todos los objetos, tablas, vistas, etc. eran propiedad de dboy no había otros esquemas ) era necesario para un "usuario" para poseerlo ... debería ser evidente por qué algo necesita ser dueño de la base de datos (de lo contrario, los permisos en general serían bastante difíciles).

Entonces, técnicamente en versiones anteriores de SQL Server (o bases de datos actualizadas) no era la tabla "Foo" sino la tabla "dbo.Foo" ... dbosiendo el propietario.

Con el advenimiento de SQL Server 2005, podría tener objetos de base de datos de propiedad de esquemas como, por ejemplo, un esquema llamado "bar" y una tabla llamada "Foo" ... esto se convierte bar.Fooen ...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

La parte difícil viene con el hecho de que el usuario que crea la base de datos se configura automáticamente como el propietario, lo que genera problemas con la rotación de empleados, etc.

Por lo tanto, es una buena práctica cambiar esto a la sacuenta o quizás (en mi experiencia) a una cuenta de dominio que pueda ser administrada por el equipo de operaciones / TI de una organización.

Este artículo ofrece un desglose de la diferencia entre la forma más antigua de "hacer" las cosas del propietario y el nuevo sistema de propiedad basado en "esquemas".

Para comprender la diferencia entre propietarios y esquema, dediquemos un tiempo a revisar la propiedad del objeto. Cuando se crea un objeto en SQL Server 2000 o anterior, el objeto debe tener un propietario. La mayoría de las veces, el propietario es "dbo", también conocido como el propietario de la base de datos.