Tengo problemas para permitir que mis usuarios ejecuten paquetes SSIS de manera razonable debido a los diferentes niveles de privilegio requeridos.
El escenario : hemos creado un almacén de datos, con dos paquetes SSIS diferentes responsables de cargarlo con datos, uno debe ejecutarse automáticamente (a través de un trabajo del Agente SQL y funciona correctamente), y otro que debe ejecutarse en demanda de los usuarios una vez que se finalizan y limpian los datos aguas arriba, etc.
Este paquete realiza operaciones muy privilegiadas, incluida la copia de seguridad de la base de datos al comienzo de la ejecución (para estar seguro, estar seguro), soltar y recrear tablas calculadas, etc.
He escrito un procedimiento almacenado para ejecutar este trabajo a través de [SSISDB]. [Catalog]. [Create_execution] y [SSISDB]. [Catalog]. [Start_execution] procedimientos almacenados ... esto funciona bien cuando se ejecuta en mi cuenta (Soy un administrador de sistemas).
El procedimiento almacenado fallaba cuando lo ejecutaba un usuario normal debido al mayor nivel de permisos requeridos en SSISDB y MSDB para poner en cola la ejecución, y el paquete en sí mismo fallaba porque se estaba ejecutando en su contexto de seguridad (poco).
Lo que he intentado :
Intenté resolver el problema usando 'Ejecutar como' en el procedimiento almacenado, sin embargo, esto falló debido a los problemas de encadenamiento entre bases de datos, el indicador de confianza, etc.
También intenté resolver el problema haciendo que los trabajos de Agente ejecutaran el paquete, y simplemente ejecuté el trabajo de agente desde el procedimiento almacenado, sin embargo, rápidamente entré en un mundo de dolor que involucra:
- La incapacidad de establecer permisos de ejecución por trabajo
- La esperanza de configurar este acceso a través de un rol de servidor central para atender el cambio de personal con el tiempo, y los trabajos solo pueden tener un solo usuario como propietario
- El mundo oscuro de las cuentas Proxy, Credenciales en combinación con inicios de sesión sql-auth, etc.
Planes C y D
Las únicas opciones que se me ocurren son crear un inicio de sesión de SQL Server dedicado con permisos elevados y confiar en que los usuarios no pasarán las credenciales ni perderán la auditabilidad de quién programó la importación (cómo se resuelve este problema en otras áreas de la organización), o crear una interfaz web personalizada únicamente para permitir que los usuarios se autentiquen como su cuenta de 'Rol de servidor', y luego dejar que la aplicación web ejecute el procedimiento almacenado bajo una segunda conexión (privilegiada).
Entonces....
¿Hay algún consejo sobre cómo:
- hacer que un paquete SSIS realice operaciones privilegiadas
- ejecutado por un usuario con pocos privilegios (usando una cuenta de Windows AD)
- preferiblemente donde el acceso para ejecutar el trabajo se gestiona a través de un rol de servidor central (no tengo la capacidad fácil de crear un nuevo grupo de ventanas para ellos)
- y donde cualquier cuenta nueva, intermedia / proxy son cuentas de autenticación de SQL Server (de nuevo, capacidad muy limitada para realizar cambios en el AD)
Entiendo que hay muchas partes móviles aquí (y algunas se sienten como cuchillas giratorias), así que avíseme si hay alguna otra información que sienta que me he perdido.
Saludos, Tim
Editar....
Así que hoy creé un inicio de sesión dedicado de SQL Server con permisos ssis_admin, creé tres trabajos del Agente SQL Server propiedad de ese usuario y actualicé el procedimiento almacenado que mis usuarios finales llaman a execute asese usuario. Esto falló debido a la imposibilidad de llamar create executioncomo un inicio de sesión de SQL Server, requiere una cuenta de Windows.
Actualicé el procedimiento almacenado de los usuarios a execute asla cuenta de Windows que SQL Server está ejecutando como (una cuenta de servicio de AD), lo concedí ssis_adminy falla con el error
El contexto de seguridad actual no se puede revertir. Cambie a la base de datos original donde se llamó 'Ejecutar como' e inténtelo de nuevo.
Esto no va a ninguna parte rápido :(
create_executionporque necesito pasar un parámetro (uno de los tres valores) de la sproc al trabajo. Estoy feliz de tener tres sprocs / jobs, etc., si eso lo resuelve. 2) Si ssis_admin es el rol de privilegio más bajo que me lleva allí, estoy abierto a él ... es mejor que sysadmin al menos y los resuelve accidentalmente dejando caer / destruyendo las tablas del almacén en uso general.
ssis_adminrol les permitiría ejecutar los paquetes SSIS (los procs verifican la membresía en los roles sysadmin o ssis_admin) pero creo que se ejecutará como ellos y, por lo tanto, no podrán realizar copias de seguridad y demás. (Tendría que probar eso con seguridad, nunca puedo recordar si se ejecuta como ellos o la cuenta de servicio de SQL Server). Sin embargo, ser miembro de ssis_admin les permite implementar paquetes y confundirse con configuraciones que pueden o no ser buenas. El 2016 nos da roles más granulares, pero obviamente no es muy útil aquí
EXECUTE ASpara permitirles ejecutar los trabajos específicos a través de sp_start_job. Dice el tipo de internet al azar que es terrible en seguridad
create_executiones decir , necesitan especificar parámetros en la ejecución para su "escenario de datos listos"? 2) ¿Es seguro asumir que no está interesado en ponerlos en el rol ssis_admin?