Implementación de la seguridad del Agente SQL Server
se aplica a:
SQL Serverazure SQL Managed Instance
Importante
En Instancia administrada de Azure SQL, la mayoría de las características del Agente SQL Server, pero no todas, están actualmente admitidas. Consulte diferencias de T-SQL de Azure SQL Managed Instance con respecto a SQL Server para más información.
El Agente SQL Server permite al administrador de bases de datos ejecutar cada paso de trabajo en un contexto de seguridad que solo tiene los permisos necesarios para realizar ese paso de trabajo, que viene determinado por un proxy del Agente SQL Server. Para establecer los permisos de un paso de trabajo determinado, cree un proxy que tenga los permisos necesarios y, a continuación, asigne ese proxy al paso de trabajo. Se puede especificar un proxy para más de un paso de trabajo. Para los pasos de trabajo que requieren los mismos permisos, use el mismo proxy.
En la sección siguiente se explica qué rol de base de datos debe conceder a los usuarios para que puedan crear o ejecutar trabajos mediante el Agente SQL Server.
Conceder acceso al Agente SQL Server
Para usar el Agente SQL Server, los usuarios deben ser miembros de uno o varios de los siguientes roles fijos de base de datos:
SQLAgentUserRole
SQLAgentReaderRole
SQLAgentOperatorRole
Estos roles se almacenan en la base de datos de msdb. De forma predeterminada, ningún usuario es miembro de estos roles de base de datos. La pertenencia a estos roles debe concederse explícitamente. Los usuarios que son 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 usar el Agente SQL Server. Si un usuario no es miembro de uno de estos roles de base de datos o del rol de administrador del sistema, el nodo agente SQL Server no está disponible para ellos cuando se conecta a SQL Server mediante SQL Server Management Studio.
Los miembros de estos roles de base de datos pueden ver y ejecutar trabajos que poseen y crear pasos de trabajo que se ejecutan utilizando una cuenta de proxy existente. Para obtener más información sobre los permisos específicos asociados a cada uno de estos roles, consulte Roles de base de datos fijos del Agente de SQL Server.
Los miembros del sysadmin rol fijo de servidor tienen permiso para crear, modificar y eliminar cuentas de proxy. Los miembros del rol sysadmin tienen permiso para crear pasos de trabajo que no especifican un proxy, sino que se ejecutan bajo la cuenta de servicio del Agente SQL Server, la cuenta utilizada para iniciar el Agente SQL Server.
Directrices
Siga estas instrucciones para mejorar la seguridad de la implementación del Agente SQL Server:
Cree cuentas de usuario dedicadas específicamente para servidores proxy y use solo estas cuentas de usuario proxy para ejecutar los pasos de trabajo.
Conceda solo los permisos necesarios para las cuentas de usuario proxy. Conceda solo los permisos necesarios para ejecutar los pasos de trabajo asignados a una cuenta de proxy determinada.
No ejecute el servicio Agente SQL Server en una cuenta de Microsoft Windows que sea miembro del grupo administradores de Windows .
Los servidores proxy solo son tan seguros como el almacén de credenciales de SQL Server.
Si los usuarios pueden realizar operaciones de escritura en el registro de eventos de NT, pueden generar alertas a través del Agente de SQL Server.
No especifique la cuenta de administrador de NT como una cuenta de servicio o una cuenta de proxy.
SQL Server y el Agente SQL Server tienen acceso a los recursos entre sí. Los dos servicios comparten un único espacio de proceso y el Agente SQL Server es un administrador del sistema en el servicio SQL Server.
Cuando un TSX (servidor de destino) se inscribe con un MSX (servidor maestro), los administradores del sistema MSX obtienen el control total sobre la instancia de TSX de SQL Server.
ACE es una extensión y no se puede invocar a sí misma. Chainer ScenarioEngine.exe (también conocido como Microsoft.SqlServer.Chainer.Setup.exe) puede invocar ACE. Otros procesos host también pueden invocar ACE.
ACE depende de los siguientes DLLs de configuración propiedad de SSDP, porque ACE llama a esas API de DLL.
SCO - Microsoft.SqlServer.Configuration.Sco.dll, incluidas las nuevas validaciones SCO para 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 Instancia administrada de Azure SQL, para ejecutar un trabajo del Agente SQL que realiza una consulta de Transact-SQL (T-SQL) en un servidor remoto mediante un servidor vinculado, es necesario mapear un inicio de sesión local a uno en el servidor remoto.
Utilice sp_addlinkedsrvlogin para crear un mapeo 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 de SQL Agent | Cómo mapear el inicio de sesión |
|---|---|
| Usuario que no es sysadmin | Asigne el usuario local que posee la tarea del Agente SQL al inicio de sesión remoto. |
| administrador de sistemas | Asigne todos los usuarios locales para 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 mapea correctamente a los usuarios, se pueden producir errores como los siguientes ejemplos:
Windows logins are not supported in this version of SQL ServerLinked servers cannot be used under impersonation without a mapping for the impersonated login