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
GOEn 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!
