Поделиться через

Реализация безопасности агента SQL Server

  • Статья

применимо к:SQL ServerУправляемому экземпляру SQL Azure

Это важно

В Azure SQL Managed Instanceв настоящее время поддерживается большинство функций агента SQL Server, но не все. Дополнительные сведения см. в статье «Различия T-SQL в управляемом экземпляре SQL Azure по сравнению с SQL Server».

Агент SQL Server позволяет администратору базы данных выполнять каждый шаг задания в контексте безопасности, который имеет только разрешения, необходимые для выполнения этого шага задания, который определяется прокси-сервером агента SQL Server. Чтобы задать разрешения для определенного шага задания, создайте прокси-сервер с необходимыми разрешениями, а затем назначьте этот прокси-сервер шагу задания. Прокси-сервер можно указать для нескольких шагов задания. Для шагов задания, требующих одинаковых разрешений, используется тот же прокси-сервер.

В следующем разделе объясняется, какую роль базы данных необходимо предоставить пользователям, чтобы они могли создавать или выполнять задания с помощью агента SQL Server.

Предоставление доступа к агенту SQL Server

Чтобы использовать агент SQL Server, пользователи должны быть членом одной или нескольких следующих предопределенных ролей базы данных:

  • SQLAgentUserRole

  • SQLAgentReaderRole

  • SQLAgentOperatorRole

Эти роли хранятся в базе данных msdb . По умолчанию пользователь не является членом этих ролей базы данных. Членство в этих ролях должно быть предоставлено явным образом. Пользователи, являющиеся членами предопределенных ролей сервера sysadmin , имеют полный доступ к агенту SQL Server и не должны быть членом этих предопределенных ролей базы данных для использования агента SQL Server. Если пользователь не является членом одной из этих ролей базы данных или роли sysadmin , узел агента SQL Server недоступен для них при подключении к SQL Server с помощью SQL Server Management Studio.

Члены этих ролей базы данных могут просматривать и выполнять задания, которыми они владеют, а также создавать шаги заданий, выполняемых от имени существующей учетной записи прокси. Дополнительные сведения о конкретных разрешениях, связанных с каждой из этих ролей, см. в разделе "Фиксированные роли базы данных агента SQL Server".

Члены предопределенной роли сервера sysadmin имеют разрешение на создание, изменение и удаление учетных записей прокси-сервера. Члены роли sysadmin имеют разрешение на создание шагов задания, которые не указывают прокси, но вместо этого выполняются от имени учетной записи службы SQL Server Agent, используемой для запуска SQL Server Agent.

Руководящие принципы

Выполните следующие рекомендации, чтобы повысить безопасность реализации агента SQL Server:

  • Создайте выделенные учетные записи пользователей специально для прокси-серверов и используйте только эти учетные записи пользователей-прокси для выполнения шагов задания.

  • Предоставьте только необходимые разрешения учетным записям пользователей-посредников. Предоставьте только те разрешения, которые необходимы для выполнения назначенных шагов задания, привязанных к данной прокси-учетной записи.

  • Не запускайте службу агента SQL Server в учетной записи Microsoft Windows, которая входит в группу администраторов Windows.

  • Прокси-серверы защищены только в хранилище учетных данных SQL Server.

  • Если операции записи пользователей могут записываться в журнал событий NT, они могут вызывать оповещения с помощью агента SQL Server.

  • Не указывайте учетную запись администратора NT в качестве учетной записи службы или учетной записи-посредника.

  • Агент SQL Server и SQL Server имеют доступ к ресурсам друг друга. Две службы используют одно пространство обработки, а агент SQL Server — системный администратор в службе SQL Server.

  • Когда TSX (целевой сервер) регистрируется на MSX (главном сервере), системный администратор MSX получает полный контроль над экземпляром SQL Server TSX.

  • ACE является расширением и не может вызывать себя. Цепочка ScenarioEngine.exe (также известная как Microsoft.SqlServer.Chainer.Setup.exe) может вызывать ACE. Другие хост-процессы также могут вызывать ACE.

  • ACE зависит от следующих библиотек DLL конфигурации, принадлежащих SSDP, так как эти API библиотек DLL вызываются ACE:

    • SCO — Microsoft.SqlServer.Configuration.Sco.dll, включая новые проверки SCO для виртуальных учетных записей

    • Кластер — Microsoft.SqlServer.Configuration.Cluster.dll

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

    • Расширение — Microsoft.SqlServer.Configuration.ConfigExtension.dll

Связанные серверы

В некоторых сценариях, таких как управляемый экземпляр SQL Azure, для запуска задания агента SQL, выполняющего запрос Transact-SQL (T-SQL) на удаленном сервере через связанный сервер, необходимо сопоставить локальное имя входа с именем входа на удаленном сервере.

Используйте sp_addlinkedsrvlogin для создания сопоставления между именем входа на локальном сервере с именем входа на удаленном сервере с необходимым разрешением для выполнения запроса T-SQL. Когда задание агента SQL подключается к удаленному серверу через связанный сервер, оно выполняет запрос T-SQL в контексте учетной записи удаленного пользователя.

В следующей таблице описывается сопоставление имени входа на основе владельца задания агента SQL в Управляемом экземпляре SQL Azure:

Владелец задания агента SQL Как сопоставить вход в систему
Пользователь, который не является sysadmin Сопоставить локального пользователя, которому принадлежит задание агента SQL, с удаленным логином.
sysadmin Сопоставьте всех локальных пользователей с удаленным именем входа, установив параметр @locallogin на NULL.

Примечание.

Создание имен входа на удаленном сервере для заданий агента SQL требуется, если локальный сервер — управляемый экземпляр SQL Azure. Неправильное сопоставление пользователей может привести к ошибкам, таким как следующие примеры:

  • 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

Связанный контент