Partage via

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

  • Article

S’applique à : SQL Server Azure SQL Managed Instance

Important

Dans Azure SQL Managed Instance, la plupart, mais pas toutes les fonctionnalités SQL Server Agent sont actuellement prises en charge. Pour plus d’informations, consultez Différences T-SQL entre Azure SQL Managed Instance et SQL Server.

SQL Server Agent permet à l’administrateur de la base de données d’exécuter chaque étape de travail dans un contexte de sécurité qui a uniquement les autorisations requises pour effectuer cette étape, ce qui est déterminé par un proxy SQL Server Agent. Pour définir des autorisations pour une étape de travail particulière, créez un proxy possédant les autorisations requises, puis assignez ce proxy à l'étape de travail. Un proxy peut être spécifié pour plusieurs étapes de travail. Pour les étapes de travail qui requièrent 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 pour qu'ils puissent créer ou exécuter des travaux à l'aide de SQL Server Agent.

Octroi de l'autorisation d'accéder à SQL Server Agent

Pour utiliser SQL Server Agent, les utilisateurs doivent être membres de l'un ou de tous les 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 qui sont membres du rôle serveur fixe administrateur système ont un accès complet à SQL Server Agent et ne doivent pas nécessairement ê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 ces rôles de base de données ou du rôle administrateur système, le nœud de SQL Server Agent ne leur est pas accessible quand ils se connectent à SQL Server avec SQL Server Management Studio.

Les membres de ces rôles de base de données peuvent afficher et exécuter les travaux dont ils sont propriétaires, et créer des étapes de travail qui s'exécutent comme un compte proxy existant. Pour en savoir plus 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 sont habilités à créer, à modifier et à supprimer des comptes proxy. Les membres du rôle sysadmin sont habilités à créer des étapes de travail qui ne spécifient pas un proxy, mais s’exécutent plutôt comme le compte de service SQL Server Agent, qui est le compte utilisé pour démarrer SQL Server Agent.

Consignes

Pour améliorer la sécurité de votre implémentation de SQL Server Agent, suivez les instructions suivantes :

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

  • Octroyez exclusivement les autorisations nécessaires aux comptes utilisateur proxy. Octroyez exclusivement les autorisations requises pour exécuter les étapes de travail qui sont assignées à un compte proxy donné.

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

  • Les proxys sont aussi sécurisés que la banque d'informations d'identification de SQL Server.

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

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

  • SQL Server et SQL Server Agent ont chacun accès aux ressources de l’autre. Les deux services partagent un espace de processus unique et SQL Server Agent est un sysadmin sur le service SQL Server.

  • Lorsqu'un TSX (serveur cible) s'associe à un MSX (serveur maître), les administrateurs du MSX ont 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 connu sous le nom de Microsoft.SqlServer.Chainer.Setup.exe) peut invoquer ACE. D'autres processus hôtes peuvent également invoquer 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

    • Cluster - 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 une tâche SQL Agent qui exécute une requête Transact-SQL (T-SQL) sur un serveur distant via un serveur lié, vous devez mapper un login local à un login sur le serveur distant.

Utilisez sp_addlinkedsrvlogin pour créer une correspondance entre un login sur le serveur local et un login sur le serveur distant qui dispose des autorisations nécessaires 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 session à distance.

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

Propriétaire du projet du SQL Agent Comment cartographier la connexion
Utilisateur qui n’est pas administrateur système Mappez l’utilisateur local propriétaire du travail SQL Agent à la connexion à distance.
sysadmin Mettez tous les utilisateurs locaux en correspondance avec la session à distance en définissant le paramètre @locallogin sur NULL.

Remarque

La création de logins sur le serveur distant pour les tâches du SQL Agent est nécessaire lorsque le serveur local est Azure SQL Managed Instance. Si le mappage des utilisateurs n'est pas effectué correctement, des erreurs peuvent se produire, comme dans les exemples suivants :

  • Windows logins are not supported in this version of SQL Server
  • Linked servers cannot be used under impersonation without a mapping for the impersonated login

Contenu connexe