Cadenas de propiedad

Cuando varios objetos de base de datos obtienen acceso unos a otros de forma secuencial, la secuencia se denomina cadena. Aunque estas cadenas no existen de manera independiente, cuando SQL Server recorre los eslabones de una cadena, SQL Server evalúa los permisos de los objetos que la componen de manera distinta a si se estuviese obteniendo acceso a los objetos por separado. Estas diferencias tienen implicaciones importantes en lo que se refiere a administrar la seguridad.

Las cadenas de propiedad permiten administrar el acceso a varios objetos, por ejemplo, a varias tablas, estableciendo permisos en un objeto, como una vista. El encadenamiento de propiedad también ofrece una pequeña mejora en el rendimiento en los escenarios que permiten la omisión de comprobaciones de permisos.

Cómo se comprueban los permisos en una cadena

Cuando se obtiene acceso a un objeto mediante una cadena, SQL Server primero compara al propietario del objeto con el propietario del objeto de llamada. Este es el eslabón anterior de la cadena. Si ambos objetos tienen el mismo propietario, los permisos del objeto de referencia no se evalúan.

Ejemplo de encadenamiento de propiedad

En la siguiente ilustración, la vista July2003 es propiedad de Mary. Ella le ha concedido a Alex permisos para la vista. Él no tiene ningún otro permiso en los objetos de base de datos de esta instancia. ¿Qué ocurre cuando Alex selecciona la vista?

Diagrama de encadenamiento de propiedad

  1. Alex ejecuta SELECT * en la vista July2003. SQL Server comprueba los permisos de la vista y confirma que Alex tiene permiso para seleccionarla.

  2. La vista July2003 requiere información de la vista SalesXZ. SQL Server comprueba la propiedad de la vista SalesXZ. Debido a que esta vista tiene el mismo propietario (Mary) que la vista que la llama, los permisos de la vista SalesXZ no se comprueban. Se devuelve la información requerida.

  3. La vista SalesXZ requiere información de la vista InvoicesXZ. SQL Server comprueba la propiedad de la vista InvoicesXZ. Debido a que esta vista tiene el mismo propietario que el objeto anterior, los permisos de la vista InvoicesXZ no se comprueban. Se devuelve la información requerida. Hasta este momento, todos los elementos de la secuencia tienen un único propietario (Mary). Esto se denomina cadena de propiedad continua.

  4. La vista InvoicesXZ requiere información de la vista AcctAgeXZ. SQL Server comprueba la propiedad de la vista AcctAgeXZ. Como el propietario de esta vista es diferente del propietario del objeto anterior (Sam, y no Mary), se recupera toda la información sobre permisos de esta vista. Si la vista AcctAgeXZ tiene permisos que permiten que Alex tenga acceso, se devolverá información.

  5. La vista AcctAgeXZ requiere información de la tabla ExpenseXZ. SQL Server comprueba la propiedad de la tabla ExpenseXZ. Como el propietario de esta tabla es diferente del propietario del objeto anterior (Joe, y no Sam), se recupera toda la información sobre permisos de esta tabla. Si la tabla ExpenseXZ tiene permisos que permiten que Alex tenga acceso, se devuelve información.

  6. Cuando la vista July2003 intenta recuperar información de la tabla ProjectionsXZ, el servidor primero hace comprobaciones para ver si está habilitado el encadenamiento entre las bases de datos Database 1 y Database 2. Si el encadenamiento entre bases de datos está habilitado, el servidor comprobará la propiedad de la tabla ProjectionsXZ. Debido a que esta vista tiene el mismo propietario que la vista de llamada (Mary), los permisos de esta tabla no se comprueban. Se devuelve la información solicitada.

Encadenamiento de propiedad entre bases de datos

SQL Server se puede configurar para permitir el encadenamiento de propiedad entre bases de datos específicas o entre todas las bases de datos de una única instancia de SQL Server. De manera predeterminada, el encadenamiento de propiedad entre bases de datos está deshabilitado y no se debe habilitar a menos que sea específicamente necesario.

Posibles amenazas

Las cadenas de propiedad resultan muy útiles a la hora de administrar los permisos para una base de datos, pero asumen que los propietarios de objetos preverán todas las consecuencias de las decisiones que tomen para conceder permisos para un elemento protegible. En la ilustración anterior, Mary es la propietaria de la mayoría de los objetos subyacentes de la vista July 2003. Debido a que Mary tiene el derecho de hacer que los objetos de los que es propietaria se encuentren accesibles para otros usuarios, SQL Server asume que, si Mary concede el acceso a la primera vista de una cadena, ha tomado la decisión consciente de compartir las vistas y las tablas a las que hace referencia. En la vida real, es posible que esto no sea una suposición válida. Las bases de datos de producción son mucho más complejas que la de la ilustración, y los permisos que regulan el acceso a las mismas en muy pocas ocasiones se asignan correctamente a las estructuras administrativas de las organizaciones que las utilizan.

Es importante comprender que los miembros de roles de la base de datos con amplios privilegios pueden utilizar el encadenamiento de propiedad entre bases de datos para obtener acceso a objetos de bases de datos externas a las suyas. Por ejemplo, si el encadenamiento de propiedad entre bases de datos se habilita entre la base de datos A y la B, un miembro del rol fijo de base de datos db_owner de cualquiera de las dos bases de datos puede suplantar su identidad y entrar en la otra. El proceso es simple: Diane (un miembro de db_owner en la base de datos A) crea un usuario Stuart en la base de datos A. Stuart ya existe como usuario en la base de datos B. A continuación, Diane crea un objeto (propiedad de Stuart) en la base de datos A que llama a cualquier objeto propiedad de Stuart de la base de datos B. Como ambos objetos (el que llama y al que llama) pertenecen al mismo usuario, los permisos del objeto de la base de datos B no se comprobarán cuando Diane obtenga acceso a la misma mediante el objeto que ella ha creado.

Vea también

Conceptos