Implementar la seguridad del Agente SQL Server
Se aplica a: 
SQL Server Azure SQL Managed Instance
Importante
En Azure SQL Managed Instance, actualmente son compatibles la mayoría de las características del Agente SQL Server. Consulte Diferencias entre T-SQL de Azure SQL Managed Instance y SQL Server para más información.
El Agente SQL Server permite que el administrador de la base de datos ejecute cada paso de trabajo en un contexto seguro que solo tiene los permisos necesarios para realizar ese paso de trabajo, algo que está determinado por un servidor proxy del Agente SQL Server. Para establecer los permisos para un paso de trabajo concreto, cree un proxy que disponga de los permisos necesarios y, a continuación, asigne ese proxy al paso de trabajo. Se puede especificar un servidor proxy en más de un paso de trabajo. Para los pasos de trabajo que necesitan los mismos permisos se utiliza el mismo proxy.
En las secciones siguientes, se explica el rol de base de datos que debe conceder a los usuarios para que puedan crear o ejecutar trabajos mediante el Agente SQL Server.
Conceder acceso al Agente SQL Server
Para utilizar el Agente SQL Server, los usuarios deben ser miembros de uno o varios de los roles fijos de base de datos siguientes:
SQLAgentUserRole
SQLAgentReaderRole
SQLAgentOperatorRole
Estos roles se almacenan en la base de datos msdb . De manera predeterminada, ningún usuario es miembro de estos roles de base de datos. La pertenencia a estos roles se debe conceder explícitamente. Los usuarios que sean miembros del rol fijo de servidor sysadmin tienen acceso total al Agente SQL Server, y no necesitan ser miembros de estos roles fijos de base de datos para utilizar el Agente SQL Server. Si un usuario no es miembro de uno de estos roles de base de datos ni del rol sysadmin, el nodo del Agente SQL Server no estará disponible para ellos cuando se conecten a SQL Server mediante SQL Server Management Studio.
Los miembros de estos roles de base de datos pueden ver y ejecutar trabajos que les pertenecen, así como crear pasos de trabajos que se ejecuten como una cuenta de proxy existente. Para información sobre los permisos específicos asociados a cada uno de estos roles, consulte Roles fijos de base de datos del Agente SQL Server.
Los miembros del rol fijo de servidor sysadmin tienen permiso para crear, modificar o eliminar cuentas de proxy. Los miembros del rol sysadmin tienen permiso para crear pasos de trabajo que no especifiquen un proxy, sino que se ejecuten como la cuenta de servicio del Agente SQL Server, que es la cuenta que se utiliza para iniciar el Agente SQL Server.
Directrices
Siga estas instrucciones para mejorar la seguridad de la implementación del Agente SQL Server:
Crear cuentas de usuario dedicadas especialmente para servidores proxy y utilizarlas únicamente para ejecutar pasos de trabajos.
Conceder solo los permisos necesarios a las cuentas de usuarios de proxy. Conceder únicamente los permisos necesarios para ejecutar los pasos de trabajo que están asignados a una cuenta de proxy determinada.
No ejecutar el servicio del Agente SQL Server en una cuenta de Microsoft Windows que sea miembro del grupo Administradores de Windows.
Los servidores proxy son tan seguros como el almacén de credenciales de SQL Server.
Si las operaciones de escritura de usuario pueden escribir en el registro de eventos de NT, pueden generar alertas mediante el Agente SQL Server.
No especifique la cuenta de administración de NT como una cuenta de servicio o una cuenta de proxy.
SQL Server y el Agente SQL Server tienen acceso a recursos entre sí. Los dos servicios comparten un único espacio del proceso y el Agente SQL Server es un administrador del sistema en el servicio SQL Server.
Cuando un TSX (servidor de destino) se registra con un MSX (servidor principal), los administradores del sistema del servidor principal obtienen el control total en la instancia del servidor de destino de SQL Server.
ACE es una extensión y no se puede invocar a sí misma. El Chainer ScenarioEngine.exe (también conocido como Microsoft.SqlServer.Chainer.Setup.exe) puede invocar ACE. Otros procesos de host también pueden invocar ACE.
ACE depende de las DLL de configuración siguientes pertenecientes a SSDP, ya que ACE llama a las siguientes API de DLL:
SCO: Microsoft.SqlServer.Configuration.Sco.dll, incluidas las nuevas validaciones de SCO para las cuentas virtuales
Clúster: Microsoft.SqlServer.Configuration.Cluster.dll
SFC: Microsoft.SqlServer.Configuration.SqlConfigBase.dll
Extensión: Microsoft.SqlServer.Configuration.ConfigExtension.dll
Servidores vinculados
En algunos escenarios, como con Azure SQL Managed Instance, para ejecutar un trabajo del Agente SQL que ejecuta una consulta de Transact-SQL (T-SQL) en un servidor remoto a través de un servidor vinculado, debe asignar un inicio de sesión local a un inicio de sesión en el servidor remoto.
Use sp_addlinkedsrvlogin para crear una correspondencia entre un inicio de sesión en el servidor local y un inicio de sesión en el servidor remoto que tenga el permiso necesario para ejecutar la consulta T-SQL. Cuando el trabajo del Agente SQL se conecta al servidor remoto a través del servidor vinculado, ejecuta la consulta T-SQL en el contexto del inicio de sesión remoto.
En la tabla siguiente se describe cómo asignar el inicio de sesión en función del propietario del trabajo del Agente SQL en Azure SQL Managed Instance:
| Propietario del trabajo del Agente SQL | Cómo establecer una correspondencia entre inicios de sesión |
|---|---|
| Usuario que no es administrador del sistema | Establezca una correspondencia entre el usuario local propietario del trabajo del Agente SQL con el inicio de sesión remoto. |
| sysadmin | Establezca una correspondencia entre todos los usuarios locales y el inicio de sesión remoto estableciendo el parámetro @locallogin en NULL. |
Nota:
La creación de inicios de sesión en el servidor remoto para trabajos del Agente SQL es necesaria cuando el servidor local es Azure SQL Managed Instance. Si no se asignan correctamente los usuarios, se pueden producir errores como los siguientes:
Windows logins are not supported in this version of SQL ServerLinked servers cannot be used under impersonation without a mapping for the impersonated login