Implémenter la sécurité de SQL Server Agent

s’applique à :SQL ServerAzure SQL Managed Instance

SQL Server Agent permet à l’administrateur de base de données d’exécuter chaque étape de travail dans un contexte de sécurité qui dispose uniquement des autorisations nécessaires pour effectuer cette étape de travail, qui est déterminée par un proxy SQL Server Agent. Pour définir les autorisations d’une étape de travail particulière, vous créez un proxy disposant des autorisations requises, puis affectez ce proxy à l’étape de travail. Un proxy peut être spécifié pour plusieurs étapes de travail. Pour les étapes de travail qui nécessitent les mêmes autorisations, vous utilisez le même proxy.

La section suivante explique quel rôle de base de données vous devez accorder aux utilisateurs afin qu’ils puissent créer ou exécuter des travaux à l’aide de SQL Server Agent.

Octroi de l’accès à SQL Server Agent

Pour utiliser SQL Server Agent, les utilisateurs doivent être membres d’un ou plusieurs des rôles de base de données fixes suivants :

• sqlAgentUserRole

• SQLAgentReaderRole

• SQLAgentOperatorRole

Ces rôles sont stockés dans la base de données msdb. Par défaut, aucun utilisateur n’est membre de ces rôles de base de données. L’appartenance à ces rôles doit être accordée explicitement. Les utilisateurs membres du rôle serveur fixe sysadmin disposent d’un accès complet à SQL Server Agent et n’ont pas besoin d’être membres de ces rôles de base de données fixes pour utiliser SQL Server Agent. Si un utilisateur n’est pas membre de l’un de ces rôles de base de données ou du rôle sysadmin, le nœud SQL Server Agent n’est pas disponible lorsqu’il se connecte à SQL Server à l’aide de SQL Server Management Studio.

Les membres de ces rôles de base de données peuvent afficher et exécuter des travaux qu’ils possèdent et créer des étapes de travail qui s’exécutent en tant que compte proxy existant. Pour plus d’informations sur les autorisations spécifiques associées à chacun de ces rôles, consultez rôles de base de données fixes de SQL Server Agent.

Les membres du rôle serveur fixe sysadmin ont l’autorisation de créer, de modifier et de supprimer des comptes proxy. Les membres du rôle sysadmin ont l’autorisation de créer des étapes de travail qui ne spécifient pas de proxy, mais qui s’exécutent plutôt en tant que compte de service SQL Server Agent, qui est le compte utilisé pour démarrer SQL Server Agent.

Lignes directrices

Suivez ces instructions pour améliorer la sécurité de votre implémentation de SQL Server Agent :

• Créez des comptes d’utilisateur dédiés spécifiquement pour les proxys et utilisez uniquement ces comptes d’utilisateur proxy pour exécuter des étapes de travail.

• Accordez uniquement les autorisations nécessaires aux comptes d’utilisateur proxy. Accordez uniquement ces autorisations requises pour exécuter les étapes de travail affectées à un compte proxy donné.

• N’exécutez pas le service SQL Server Agent sous un compte Microsoft Windows membre du groupe Administrateurs Windows.

• Les proxys sont uniquement aussi sécurisés que le magasin d’informations d’identification SQL Server.

• Si les opérations d’écriture utilisateur peuvent écrire dans le journal des événements NT, elles peuvent déclencher des alertes via SQL Server Agent.

• Ne spécifiez pas le compte d’administrateur NT en tant que compte de service ou compte proxy.

• SQL Server et SQL Server Agent ont accès aux ressources des uns des autres. Les deux services partagent un espace de processus unique et SQL Server Agent est un administrateur système sur le service SQL Server.

• Lorsqu’un TSX (serveur cible) s’inscrit auprès d’un serveur MSX (serveur maître), les administrateurs système MSX obtiennent un contrôle total sur l’instance TSX de SQL Server.

• ACE est une extension et ne peut pas s’appeler elle-même. Chainer ScenarioEngine.exe (également appelé Microsoft.SqlServer.Chainer.Setup.exe) peut invoquer ACE. D’autres processus hôtes peuvent également appeler ACE.

• ACE dépend des DLL de configuration suivantes appartenant à SSDP, car ces API de DLL sont appelées par ACE :

  • SCO - Microsoft.SqlServer.Configuration.Sco.dll, y compris les nouvelles validations SCO pour les comptes virtuels

  • Groupe - Microsoft.SqlServer.Configuration.Cluster.dll

  • SFC - Microsoft.SqlServer.Configuration.SqlConfigBase.dll

  • Extension - Microsoft.SqlServer.Configuration.ConfigExtension.dll

Serveurs liés

Dans certains scénarios, comme avec Azure SQL Managed Instance, pour exécuter un travail SQL Agent qui exécute une requête Transact-SQL (T-SQL) sur un serveur distant via un serveur lié, vous devez mapper une connexion locale à une connexion sur le serveur distant.

Utilisez sp_addlinkedsrvlogin pour créer un mappage entre une connexion sur le serveur local et une connexion sur le serveur distant disposant de l’autorisation nécessaire pour exécuter la requête T-SQL. Lorsque le travail SQL Agent se connecte au serveur distant via le serveur lié, il exécute la requête T-SQL dans le contexte de la connexion à distance.

Le tableau suivant décrit comment mapper la connexion en fonction du propriétaire du travail SQL Agent dans Azure SQL Managed Instance :

Contenu connexe

• Utilisation des rôles prédéfinis
• sp_addrolemember (Transact-SQL)
• sp_droprolemember (Transact-SQL)
• Sécurité et Protection