En su día publicamos un artículo donde analizábamos en profundidad los riesgos de activar la propiedad db_chainig en nuestras bases de datos: db_chainig: una configuración de seguridad peligrosa. Allí abordamos su impacto en la superficie de ataque de una instancia de SQL Server, especialmente cuando se activa de forma global o sin tener un control estricto de propietarios y permisos.
Hoy retomamos el tema con un enfoque diferente. Vamos a mostrar una demo práctica que responde a una duda concreta planteada por un integrante de la comunidad de Telegram “SQL Server Español”, y que nos permite ver de forma clara cómo se comporta esta propiedad cuando varios objetos en distintas bases de datos se relacionan entre sí. Aprovecharé además para precisar algunos matices técnicos que suelen pasar desapercibidos, sobre todo cuando intentamos aplicar el modelo de encapsulación de acceso sin otorgar permisos directos.
Recordatorio: qué es db_chainig y por qué nos debe importar
Como ya explicamos en el artículo de hace meses, db_chainig es una propiedad que habilita el encadenamiento de propietarios entre bases de datos distintas. Cuando está desactivada (valor por defecto), SQL Server impide que un objeto de una base de datos acceda a otro en una base diferente, aunque ambos compartan el mismo propietario y aunque el encadenamiento funcionase sin problema dentro de una única base de datos.
Este comportamiento se introdujo por motivos de seguridad, y su activación requiere un análisis muy cuidadoso. No obstante, existen escenarios legítimos donde permitir este acceso cruzado puede simplificar la arquitectura, como cuando separamos lógica de negocio y almacenamiento físico en distintas bases de datos bajo el mismo control.
La demo: ejemplo de acceso cruzado encapsulado entre bases de datos
Para mostrar cómo se comporta realmente esta propiedad en un escenario típico, he preparado una demo que tenéis disponible aquí.
El entorno consiste en dos bases de datos una con una vista de una tabla de la otra base de datos (podríamos llevarlo al mundo real como una base de datos donde residen los procedimientos que encapsulan la lógica de acceso) y otra base de datos con una tabla (que sería la base de datos donde se encuentran las tablas con los datos reales)
Creamos un usuario solo con privilegios explícitos sobre la base de datos con la vista e intentamos seleccionar la vista que, recordad, lee una tabla de la otra base de datos.
En un primer lugar obtenemos un error porque el usuario no existe en la otra base de datos pero si lo creamos, sin permisos, claro, nos encontramos con otro error porque el usuario no puede acceder a la tabla.
Hay que recordar que la vista filtra los datos de la tabla por lo que en ningún caso queremos dar al usuario permisos explícitos sobre la tabla, solo debe consultar la información a través de la vista.
Con db_chainig desactivado, la ejecución falla con un error de permisos, incluso si ambos objetos tienen el mismo propietario (dbo). Al activar la propiedad en ambas bases de datos el procedimiento funciona sin que el usuario tenga permisos directos sobre la tabla. Esto demuestra cómo SQL Server evalúa las cadenas de confianza solo si dicha propiedad está activa.
Consideraciones clave sobre propietarios y contexto de ejecución
Uno de los matices más importantes que se observa en la demo es que el encadenamiento entre bases de datos solo se permite si los objetos involucrados tienen el mismo propietario y si la propiedad db_chainig está activa en ambas bases de datos.
Otro detalle importante es que el contexto de ejecución no ha cambiado mediante EXECUTE AS o similar, lo que invalidaría la cadena de confianza.
Esto significa que no basta con activar la propiedad en una sola base de datos. Además, hay que evitar que el procedimiento se ejecute en un contexto que no sea el del usuario propietario de ambos objetos. Este tipo de situaciones no siempre son evidentes y pueden complicar el diagnóstico cuando un procedimiento aparentemente correcto lanza un error de acceso denegado.
Seguridad frente a conveniencia: ¿cuándo tiene sentido usar db_chainig?
Tal y como ya señalamos en el artículo anterior, activar db_chainig a nivel de instancia es algo que deberíamos evitar en la mayoría de escenarios, sobre todo si trabajamos en un entorno multi-tenant o con bases de datos de aplicaciones distintas.
Sin embargo, si tenemos un entorno controlado, donde todas las bases de datos son desplegadas por nosotros, los objetos comparten propietario y los accesos están bien encapsulados, db_chainig puede ser una herramienta útil para simplificar la gestión de permisos y mantener el modelo de mínima exposición.
En ese contexto, lo importante es no relajarse: hay que documentar cada caso en el que se activa, asegurarse de que no hay EXECUTE AS, revisar periódicamente los propietarios de los objetos y evitar cualquier modificación que pueda romper la cadena de confianza sin darnos cuenta.
Alternativas a db_chaining: firma con certificados
Para aquellos entornos donde la seguridad es prioritaria, pero aún así necesitamos encapsular accesos entre bases de datos, lo más recomendable es firmar los procedimientos almacenados con certificados. Esta técnica, algo más compleja de implementar, permite simular una elevación de permisos perfectamente controlada y auditable, sin necesidad de alterar propiedades globales ni confiar en la coherencia del dbo.
Si todavía no has trabajado con este enfoque, te recomiendo investigar cómo funciona la creación de certificados, usuarios basados en certificado y firma de procedimientos. Puedes consultar el artículo que publiqué sobre el tema la semana pasada.
Conclusión
Con esta demo he querido complementar el análisis previo sobre db_chainig, esta vez desde un enfoque más práctico. El comportamiento por defecto protege nuestras bases de datos, pero hay casos reales donde su activación puede facilitar una arquitectura limpia y modular.
Eso sí, hay que entender muy bien sus implicaciones, probarlo a fondo y asegurarnos de que el entorno cumple con los requisitos de seguridad y propiedad para que el encadenamiento funcione sin sorpresas. Y si no queremos depender de esta propiedad, las firmas con certificados siguen siendo la alternativa más elegante y segura.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
[…] el artículo anterior vimos cómo la propiedad db_chainig permite que el encadenamiento de propietarios funcione entre objetos ubicados en bases de datos […]
[…] de analizar cómo funciona la propiedad db_chainig y los riesgos de activar cross db ownership chaining a nivel de instancia, nos queda un tema que […]