Hoy quiero profundizar sobre un tema que ya comentamos de pasada cuando hablamos del Agente de SQL Server y es la gestión avanzada de los jobs. Cualquiera que haya trabajado con SQL Server y haya necesitado algo más que un simple almacén donde leer y escribir datos sabe que los jobs son un aliado indispensable para automatizar tareas repetitivas o programadas. Dentro de este contexto, los jobs juegan un papel crucial al permitirnos ejecutar de manera automática una variedad de tareas, desde copias de seguridad hasta la ejecución de scripts complejos. Sin embargo, más allá de crear y ejecutar jobs básicos, el manejo avanzado de estos, así como asignar bien permisos sobre el agente y el uso de proxys y credenciales, son aspectos que pueden marcar la diferencia en la administración eficiente y segura de nuestro entorno de bases de datos.
Jobs del Agente de SQL Server
Los jobs del Agente de SQL Server son estructuras flexibles y robustas que permiten ejecutar un conjunto de pasos de manera programada o bajo demanda. Cada job puede estar compuesto por uno o más pasos, que pueden ser scripts T-SQL, comandos de sistema operativo, paquetes SSIS, entre otros. La granularidad y flexibilidad que nos ofrecen los jobs nos permite orquestar tareas complejas, que en algunos casos serían difíciles de gestionar manualmente. La combinación de poder programar ejecuciones de script con un uso avanzado de procedimientos almacenados y otros objetos de sistema nos permite hacer cosas que de otra manera serían muy complejas.
Cuando creamos un job, lo primero que hacemos es asignar una serie de atributos esenciales, como son el nombre del job, el propietario, la categoría, y por supuesto, los pasos que se deben ejecutar. Es fundamental que definamos correctamente estos atributos, ya que una mala configuración puede llevar a errores en la ejecución o a problemas de seguridad. Por ejemplo, el propietario del job determina los permisos con los que se ejecutarán los pasos, lo que nos lleva al siguiente punto: la importancia de los permisos y las credenciales y los proxys.
La importancia de los permisos en los jobs
El Agente de SQL Server opera bajo un contexto de seguridad bien definido que se basa en los permisos de los usuarios y roles asignados dentro del servidor. Los permisos determinan qué acciones puede realizar un usuario sobre los jobs, incluyendo la creación, edición, eliminación y ejecución. Sin embargo, cuando quieras profundizar en la administración de permisos del agente vas a notar inmediatamente que están muy limitados.
Permisos del owner y del rol sysadmin
Cuando creamos un job, se asigna automáticamente un propietario (owner), que generalmente es el usuario que lo crea si no definimos otra cosa. Este owner tiene control total sobre el job, lo que incluye la capacidad de editar, pausar, detener, y eliminar el job sin restricciones. El problema es que solo este usuario será capaz de editar ese job (a excepción de los usuarios del rol sysadmin). Los miembros del rol sysadmin tienen privilegios sobre todos los jobs, lo que les permite editar, ejecutar o eliminar cualquier job, incluso si no fueron creados por ellos. Un usuario sysadmin tiene la capacidad de gestionar cualquier job en el servidor, sin importar quién sea el propietario, pero nadie más, no existe ningún permiso que podamos asignar a un usuario no sysadmin para administrar los jobs.
Usuarios no sysadmin
Los problemas, por tanto, comienzan a surgir cuando un usuario que no es miembro del rol sysadmin intenta gestionar un job del que no es propietario. En este escenario, el usuario se enfrenta a una serie de restricciones significativas. Por defecto, si no somos los propietarios de un job, no podemos editarlo ni cambiar su configuración, lo que incluye la modificación de los pasos del job, la programación, o incluso la habilitación o deshabilitación del mismo.
Esta limitación está diseñada para proteger la integridad y la seguridad de los jobs, evitando que usuarios sin permisos adecuados realicen cambios potencialmente dañinos o no autorizados. Sin embargo, también puede ser una barrera en entornos colaborativos, donde varios administradores de bases de datos necesitan trabajar en conjunto y gestionar los mismos jobs.
Estrategias ante las restricciones de permisos en la edición de jobs
Dado que la restricción de permisos es una medida de seguridad esencial y no parece que esté en la hoja de ruta de Microsoft cambiarla, es fundamental buscar soluciones que permitan la gestión colaborativa de jobs sin comprometer la seguridad del sistema. A continuación, os presento algunas estrategias para manejar estas limitaciones.
Uso del rol SQLAgentOperatorRole
La primera opción para otorgar permisos de gestión sobre jobs sin dar acceso completo como sysadmin es agregar al usuario al rol SQLAgentOperatorRole en la base de datos msdb. Este rol permite a los usuarios ejecutar, detener, iniciar y ver la historia de cualquier job, pero sigue sin permitir la creación ni edición de jobs de los cuales no son propietarios. Si un usuario necesita la capacidad de editar un job, deberá ser agregado como propietario del job o se le deben asignar permisos sysadmin.
Cambio de ownership de los jobs
Vista la limitación anterior del rol SQLAgentOperatorRole , una solución práctica sería cambiar el propietario del job al usuario que necesita gestionarlo. Esto se puede hacer fácilmente con una instrucción T-SQL, pero requiere permisos sysadmin o el propietario actual para ejecutar el cambio. Además desde ese mismo momento el propietario anterior dejará de tener permisos. En este punto es importante destacar que podemos definir como propietario de un job a un usuario que esté asociado a un login de SQL o de Windows pero en ningún caso a un rol o a un grupo de AD.
Este método, por tanto, aunque funciona, requiere de una gestión cuidadosa para evitar confusión sobre quién es responsable de cada job y para mantener un registro claro de la propiedad de los jobs en un entorno compartido. Además de requerir de intervención manual cuando el propietario del job no está disponible y otro compañero necesita editarlo.
Te recomiendo este video sobre como cambiar el propietario de varios jobs de manera masiva.
Usuario compartido como Owner
Los que me conocen saben que yo no soy partidario de compartir usuarios, me parece una mala práctica de seguridad. Sin embargo, vistas las limitaciones con la edición de jobs no hay otra alternativa factible. Un login de SQL compartido con un usuario asociado que actúe como propietario de los jobs permitirá a los usuarios loguearse con esa cuenta para la edición de los jobs. Dado que es un tema delicado de seguridad debemos mantener los permisos de este usuario lo más restringidos posibles y, en un escenario ideal, que solo tenga permisos sobre la base de datos MSDB. Para que esto sea posible, deberemos recurrir a un proxy para la ejecución de los pasos del job o nos encontraremos con problemas de permisos para acceder a los datos.
Credenciales y proxys
En entornos corporativos, es común que los jobs necesiten realizar tareas que requieren permisos elevados o acceder a recursos externos, como carpetas de red o servidores remotos. Como ya hemos visto, en las situaciones donde los jobs requieren permisos específicos para realizar tareas, pero no se desea otorgar permisos sysadmin, se pueden utilizar credenciales y proxys. Mediante la creación de proxys asociados a credenciales, los usuarios pueden ejecutar ciertos pasos del job con permisos elevados sin necesidad de ser sysadmin ni owner del job. Este enfoque garantiza que las tareas críticas se realicen de manera segura y controlada.
¿Qué son las Credenciales en SQL Server?
Una credencial en SQL Server es un objeto que almacena información de autenticación, como un nombre de usuario y una contraseña, que se utiliza para acceder a recursos externos al servidor SQL. Por ejemplo, si un job necesita copiar un archivo desde una ubicación de red, y esta acción requiere permisos específicos, podemos crear una credencial con las credenciales adecuadas y asignarla al job. Esto no solo centraliza la gestión de permisos, sino que también nos permite modificar las credenciales sin necesidad de cambiar los jobs que las utilizan.
¿Qué son los Proxys en SQL Server?
Un proxy en SQL Server es un mecanismo que permite a un job ejecutar pasos con los permisos asociados a una credencial específica. Esto es especialmente útil cuando queremos restringir los permisos del Agente de SQL Server para que solo realice determinadas tareas bajo un contexto de seguridad controlado.
Por ejemplo, supongamos que tenemos un job que ejecuta un paquete SSIS que necesita acceso a un servidor FTP para transferir archivos. Podríamos crear un proxy asociado a una credencial con los permisos necesarios para acceder al servidor FTP, y luego configurar el job para que utilice ese proxy al ejecutar el paso correspondiente. De esta manera, nos aseguramos de que el job solo pueda acceder a los recursos necesarios, minimizando el riesgo de comprometer la seguridad del sistema.
Configuración de Proxys y Credenciales: Mejores Prácticas
A la hora de configurar proxys y credenciales en SQL Server, es esencial seguir una serie de buenas prácticas para garantizar la seguridad y el correcto funcionamiento de los jobs.
En primer lugar, es recomendable que las credenciales se almacenen de forma segura y que su acceso esté restringido a los usuarios que realmente lo necesitan. Cuando estamos trabajando en entornos donde la seguridad es crítica, podríamos considerar el uso de un servicio de administración de secretos externo que permita gestionar las credenciales de manera centralizada.
En segundo lugar, al configurar proxys, es importante asignar sólo los permisos estrictamente necesarios. Esto se alinea con el principio de mínimo privilegio, del que ya hemos hablado y que dicta que un usuario o proceso solo debe tener los permisos necesarios para realizar su tarea y nada más. Además, es recomendable revisar y auditar periódicamente los proxys y las credenciales configuradas en el sistema para asegurarnos de que estén alineadas con las políticas de seguridad de la organización.
Finalmente, es importante documentar adecuadamente todos los proxys y credenciales configurados. En caso de que se produzcan cambios en el personal o en la estructura de permisos, tener una documentación clara puede ayudar a realizar los cambios sin interrumpir el funcionamiento de los jobs.
Conclusión
La gestión avanzada de jobs en SQL Server, junto con el uso correcto de proxys y credenciales, no solo nos permite automatizar tareas de manera eficiente, sino que también es clave para mantener la seguridad y el control en entornos complejos. Al utilizar credenciales y proxys, podemos asegurarnos de que los jobs se ejecuten con los permisos adecuados, minimizando el riesgo de accesos no autorizados o mal configurados.
Por otro lado, la gestión de permisos en el Agente de SQL Server es un aspecto crucial que impacta directamente en la capacidad de los usuarios para gestionar jobs y, sin embargo, muy complicado de gestionar correctamente.
Para sortear estas limitaciones, es fundamental implementar estrategias que permitan la colaboración segura, como el uso de roles específicos como SQLAgentOperatorRole, el cambio de ownership de jobs o la configuración de proxys y credenciales. Cada enfoque tiene sus pros y contras, pero con una gestión cuidadosa, es posible equilibrar la seguridad y la eficiencia en la administración de jobs en SQL Server
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!
No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo.
