Continuamos con el tema del pasado lunes donde hablábamos de la configuración trustworthy de SQL Server. Una configuración de seguridad con unos riesgos de seguridad añadidos que es muy importante que conozcamos. Como os decía antes de irme por las ramas, hoy continuamos con ese tema y es el turno de la opción de configuración db_chaining, una configuración también de seguridad que nos va a permitir simplificar mucho los permisos, no sin riesgos claro. Quédate hasta el final que te voy a contar todos los secretos.
¿Qué es DB_Chaining?
DB_Chaining es una opción de configuración en SQL Server que, cuando está habilitada, permite a los objetos de una base de datos acceder a los objetos de otra base de datos que tienen el mismo propietario. Esto puede ser útil en situaciones donde las bases de datos necesitan compartir información, pero también plantea ciertos riesgos de seguridad que deben ser considerados cuidadosamente.
Normalmente, si un usuario tiene permiso para ejecutar un procedimiento almacenado, y ese procedimiento tiene referencias a otros objetos en la base de datos, el usuario necesita tener permisos para esos objetos también. Esto es el comportamiento por defecto de SQL Server y las bases de datos de Azure SQL ya que db_chaining por defecto está deshabilitado. Sin embargo, cuando DB_Chaining está habilitado, SQL Server trata las cadenas de propiedad de los objetos de la base de datos de manera diferente.Si el procedimiento almacenado y el objeto al que hace referencia tienen el mismo propietario, SQL Server permite que el procedimiento acceda al objeto sin comprobar los permisos del usuario para ese objeto.

Esto que acabamos de ver puede ser útil en situaciones donde se desea simplificar la administración de permisos. Por ejemplo, si tienes varias bases de datos que necesitan compartir información, puedes tener procedimientos almacenados en una base de datos que leen o escriben en tablas en otra base de datos. Sin DB_Chaining, tendrías que dar a los usuarios permisos para las tablas en ambas bases de datos. Con DB_Chaining, puedes dar a los usuarios permisos para ejecutar los procedimientos almacenados, y los procedimientos pueden acceder a las tablas sin que los usuarios tengan permisos directos para ellas.
Consideraciones de Seguridad
Aunque DB_Chaining puede ser útil, también plantea riesgos de seguridad. Cuando DB_Chaining está habilitado, un usuario que tiene permiso para ejecutar un procedimiento almacenado puede potencialmente acceder a cualquier objeto en la base de datos que tenga el mismo propietario que el procedimiento. Si no se gestiona correctamente, esto podría permitir a los usuarios acceder a información a la que no deberían tener acceso.
Por lo tanto, antes de habilitar DB_Chaining, es importante entender completamente sus implicaciones de seguridad y asegurarse de que todas las bases de datos y objetos estén correctamente asegurados. Además, y esto es recomendación personal más que buenas prácticas, no os recomiendo habilitarlo para bases de datos donde los usuarios tengan permisos de control (para crear modificar los objetos) ya que podrían crear una vista para leer datos que no deberían o, peor aún, un procedimiento almacenado para editar los datos.
Conclusión
La configuración de DB_Chaining en SQL Server es una herramienta poderosa que puede simplificar la administración de permisos y facilitar el intercambio de información entre bases de datos. Sin embargo, también plantea riesgos de seguridad que deben ser cuidadosamente considerados y gestionados. Como siempre, la clave para usar DB_Chaining de manera efectiva y segura es entender completamente cómo funciona y seguir las mejores prácticas de seguridad de la información.
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!


[…] 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, […]