Roberto Carrancio

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!

Como DBAs de SQL Server tenemos que ser verdaderos expertos en las configuraciones de las bases y datos y comprender a la perfección todas las implicaciones de cada una de estas opciones configurables. Una de las opciones con las que más cuidado hay que tener es la propiedad TRUSTWORTHY (confiable en nuestro idioma). Si lleváis tiempo en esto de la administración de bases de datos es probable que en varias ocasiones os hayáis visto envueltos en debates sobre el uso de esta opción. Trustworthy es una configuración de la base de datos que afecta directamente a la seguridad, sobre todo en lo que a ejecución de código se refiere. Su configuración es clave en el comportamiento de todos los objetos de base de datos que se ejecuten con “WITH EXECUTE AS” y en los componentes CLR marcados como EXTERNAL_ACCESS o UNSAFE.

¿Para qué sirve Trustworthy?

Ahora que ya sabemos que trustworthy es una configuración de base de datos vamos a ver qué es lo que hace. Cuando habilitamos esta configuración (por defecto está deshabilitada) lo que estamos haciendo es decirle a SQL Server que confíe en los objetos de esa base de datos en lo que a seguridad (autenticación y autorización) se refiere. Como hemos visto, esto afecta a los objetos (funciones y procedimientos) que usan EXECUTE AS y a los módulos CLR. Veamos uno a uno estos casos.

Objetos con EXECUTE AS

Cuando trustworthy está habilitado, los módulos T-SQL que usen la opción execute as podrán ejecutarse impersonándose con cualquier otro usuario. Si estos otros usuarios tienen asociado un login con permisos elevados o con usuarios con permisos sobre otras bases de datos vamos a poder acceder a todas las funcionalidades que tendría ese login.

Por ejemplo, imaginad que tenemos dos bases de datos: ventas y contabilidad. Tenemos tres usuarios: vendedor, contable y gerente. Supongamos que el usuario vendedor tiene sólo acceso a ventas, el usuario contable tiene sólo acceso a contabilidad y el usuario gerente tiene acceso a las dos bases de datos. Gracias a tener la propiedad trustworthy habilitada el usuario vendedor va a poder actuar bajo el contexto de seguridad del usuario Gerente y así acceder a datos de contabilidad con sus mismos permisos. Lo mismo para el usuario contable en la otra base de datos.

Módulos CLR

Para las integraciones de CLR (Common Language Runtime) la propiedad trustworthy va a permitir ejecutar ensamblados marcados como EXTERNAL ACCESS o UNSAFE y, gracias a ello, acceder a recursos externos del sistema o de la red que de otra manera no estarían permitidos en este contexto de seguridad.

El peligro de trustworthy

Ahora es cuando viene la historia de terror. Tener trustworthy habilitado en nuestra base de datos puede ser un vector para una escalada de privilegios. Os lo voy a demostrar. Para esta demo vamos a crear una base de datos llamada TrustyDB y vamos a habilitar la opción trustworthy. Vamos a crear un login llamado LoginTrusty. Después pondremos como propietario de nuestra base de datos al usuario “sa”, esto es una buena práctica. Por último vamos a crear un usuario UsurioTrusty para nuestro LoginTrusty y darle permisos de db_owner sobre la base de datos.

USE [master]
GO
CREATE DATABASE [TrustyDB]
GO
ALTER DATABASE TrustyDB SET TRUSTWORTHY ON
GO
CREATE LOGIN [LoginTrusty] WITH PASSWORD = 'EstoEsUnaContraseñaSegura'
GO

USE [TrustyDB]
GO
ALTER AUTHORIZATION ON DATABASE::[TrustyDB] TO [sa]
GO
CREATE USER [UsuarioTrusty] FROM LOGIN [LoginTrusty]
GO
ALTER ROLE db_owner ADD MEMBER UsuarioTrusty
GO

En este momento nuestro login tiene un usuario con permisos de db_owner sobre la base de datos pero no tiene permisos elevados a nivel de servidor. Tampoco es el propietario de la base de datos. Sin embargo, gracias a la propiedad trustworthy va a poder crear un procedimiento almacenado que se ejecute bajo el contexto de seguridad del propietario de la base de datos (recordad que es el sa) y añadirse al rol de servidor sysadmin.

EXECUTE AS USER = 'UsuarioTrusty'
GO
CREATE PROCEDURE PiratillaProc
WITH EXECUTE AS OWNER
AS
ALTER SERVER ROLE sysadmin ADD MEMBER UsuarioTrusty 
GO

EXECUTE PiratillaProc; 
DROP PROCEDURE PiratillaProc;

Acabamos de ver un ejemplo en el que un usuario ha logrado escalar privilegios hasta convertirse en sysadmin. Este es uno de los problemas de habilitar trustworthy junto con el que ya habíamos comentado antes de acceder a datos de otras bases de datos sobre las que no tienes permisos. Otros problemas están relacionados con el uso de CLR ya que va a permitir acceder a información contenida en el sistema operativo (fuera del servidor de base de datos) o incluso de la red, interacciones que no estarían permitidas sin esta propiedad. La propiedad de trustworthy está pensada para eludir medidas de seguridad como la forma de módulos CLR o el uso de certificados para la elevación de privilegios controlada sobre todo en entornos de prueba o desarrollo. 

Buenas prácticas con Trustworthy

Como has podido ver, habilitar trustworthy conlleva un riesgo alto de seguridad por lo que la primera recomendación sería habilitarlo con precaución y sólo cuando sea imprescindible. Revisa muy bien los requisitos de cada escenario y determina si es o no necesario habilitarlo. Intenta una alternativa siempre que sea posible, por ejemplo para el caso de CLR la firma de código y uso de certificados te permitirá una gestión más segura de los permisos. Si no te queda más remedio que habilitar trustworthy refuerza tus controles de acceso, sigue una política de permisos mínimos para los usuarios y habilita auditorías para detectar cambios en los permisos y así como acceso a datos críticos.

Como activar Trustworthy

Realmente ya lo hemos visto en el ejemplo de arriba, podemos activar la propiedad trustworthy en las bases de datos que necesitemos con el siguiente código:

ALTER DATABASE NombreBaseDeDatos SET TRUSTWORTHY ON

Una cosa importante que debemos tener muy en cuenta es que esta propiedad no solo está desactivada por defecto para todas las bases de datos sino que SQL Server no puede confiar en una base de datos nueva por defecto. Por este motivo, aunque tengamos la propiedad habilitada siempre que restauremos la base de datos desde un backup o separemos y adjuntemos (detach y attach) la base de datos con trustworthy habilitado esta propiedad va a estar deshabilitada y tendremos que ser nosotros quien la habilite manualmente. Esto va a pasar, sea el mismo servidor o uno distinto.

Conclusión

En resumen, habilitar la configuración de trustworthy puede ser indispensable para algunas funcionalidades de nuestro proyecto, pero si no es nuestro caso debemos evitar su uso para evitar riesgos de seguridad innecesarios. Ahora que ya comprendes su funcionamiento y los riesgos de habilitarlo seguro que te lo vas a pensar dos veces antes de concederles esa petición al usuario que te pide habilitarlo. Si no te queda más remedio recuerda las buenas prácticas y las precauciones que hemos visto en este artículo.

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!