Haz todo lo posible por entender el código correctamente previamente a usarlo a tu trabajo y si ttienes algo que aportar puedes decirlo en los comentarios.
Solución:
Existe cierta confusión entre los conceptos de base de datos de ‘dbo’ (un usuario) y ‘db_owner’ (un rol fijo) 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 denominan ‘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: cualquier cosa a la que se le puedan otorgar permisos es un “asegurable”. Todos los asegurables tienen dueño. El propietario de un asegurable tiene control absoluto sobre lo asegurable y no se le puede negar ningún privilegio. Los elementos protegibles de nivel de instancia son propiedad de los principales del servidor (inicios de sesión). Los elementos protegibles de nivel de base de datos son propiedad de los directores de la base de datos (usuarios). Principal viene en dos tipos: primario (identidad) y secundario (membresía). Los elementos protegibles a nivel de servidor pertenecen de forma predeterminada a la entidad de seguridad del servidor principal actualmente registrada. Los elementos protegibles de nivel de base de datos pertenecen de forma predeterminada al principal de la base de datos actual, excepto para los objetos enlazados al esquema que, de forma predeterminada, son propiedad del propietario del esquema. Todos los elementos protegibles admiten la cláusula AUTORIZACIÓN en el momento de la creación para hacer cumplir un propietario diferente. ALTER AUTHORIZATION se puede utilizar posteriormente para cambiar el propietario de cualquier asegurable.
Dado que la base de datos es un nivel de servidor que se puede proteger, se deduce que, de forma predeterminada, será propiedad del principal principal que emitió la instrucción CREATE DATABASE. Es decir. el inicio de sesión NT del empleado fallecido.
Entonces tu pregunta es realmente “¿Por qué los asegurables necesitan un propietario?“. Porque el propietario es la raíz de la confianza. Es el propietario el que otorga, deniega y revoca el permiso sobre el objeto. ¿Se puede diseñar un sistema de seguridad sin propietarios de elementos protegibles? Probablemente sí, pero tendría que haber algún mecanismo establecido para reemplazar la función que desempeñan los propietarios en el modelo actual. Por ejemplo, considere que los elementos protegibles de papá no tienen propietario (p. ej., en lugar de poseer un elemento asegurable, el creador original solo tiene CONTROL sobre él), sería posible crear un elemento asegurable y revocar el acceso en es a todos, incluido él mismo. El requisito de un propietario evita este problema, ya que un propietario no puede bloquearse a sí mismo.
El efecto secundario poco conocido de CREATE DATABASE de crear un asegurable (la base de datos) propiedad del inicio de sesión original de NT ha quemado muchos antes. Las reglas son las mismas para todos los asegurables, pero algunos factores agravan los problemas del propietario de la BASE DE DATOS:
- los otros elementos protegibles a nivel de servidor (punto final, función del servidor, inicio de sesión) rara vez se usan, se mueven, etc.
- Los elementos protegibles a 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á incluido 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 modificada, etc., etc.)
- lo más importante: el propietario de la base de datos tiene efectos secundarios importantes, específicamente
EXECUTE AS context. Este último problema es lo que quema a la mayoría de los usuarios. Dado que Service Broker hace un uso extensivo de EJECUTAR COMO (la entrega del mensaje tiene un contexto EJECUTAR COMO implícito, así como la activación de la cola que tiene uno explícito) suelen ser los usuarios de Service Broker los que primero descubren este problema.
Por cierto, felicitaciones por investigar y solucionar su problema original 🙂
La base de datos owner es un retroceso a una época anterior a la introducción de los esquemas (adecuados) en SQL Sever 2005.
Básicamente una base de datos dueño es el predeterminado dbo (propietario de la base de datos) de la base de datos, siendo la base de datos objeto de base de datos.
De los documentos de SQL Server 2000 …
los
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 dbo y no hubo otros esquemas) era necesario que un “usuario” lo poseyera … no hace falta decir por qué alguna cosa necesita poseer la base de datos (o 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”, era la tabla “dbo.Foo” … con la dbo siendo el dueño.
Con la llegada de SQL Server 2005, podría tener objetos de base de datos propiedad del esquema, como por ejemplo, tiene un esquema llamado “barra” y una tabla llamada “Foo” … esto se convierte en bar.Foo como en …
SELECT * FROM bar.Foo WHERE etc = 'blah`;
La parte complicada viene con el hecho de que el usuario creando la base de datos se establece automáticamente como dueño lo que conduce a problemas con la rotación de los empleados, etc.
Por lo tanto, es una buena práctica cambiar esto a la sa cuenta, o quizás (en mi experiencia) a una cuenta de dominio que puede ser administrada por el equipo de operaciones / TI de una organización.
Este artículo detalla la diferencia entre la forma 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 una versión anterior, el objeto debe tener un propietario. La mayoría de las veces, el propietario es “dbo”, también conocido como propietario de la base de datos.
Eres capaz de añadir valor a nuestro contenido participando con tu veteranía en las observaciones.