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

Архитектура безопасности для платформы расширяемости в Службах машинного обучения SQL Server

  • Статья

Область применения: SQL Server 2016 (13.x) и более поздних версий

В этой статье описывается архитектура безопасности, используемая для интеграции ядра СУБД SQL Server и связанных компонентов с платформой расширяемости в Службах машинного обучения SQL Server. Здесь рассматриваются защищаемые объекты, службы, удостоверения процессов и разрешения. В этой статье рассматривались такие ключевые аспекты, как назначение панели запуска, SQLRUserGroup и рабочих учетных записей, изоляция процессов внешних скриптов и сопоставление удостоверений пользователей с рабочими учетными записями.

Дополнительные сведения о ключевых понятиях и компонентах расширяемости в SQL Server см. в статье Архитектура расширяемости в службах машинного обучения SQL Server .

Защищаемые объекты для внешнего скрипта

Внешний скрипт передается в качестве входного параметра в созданную для этой цели системную хранимую процедуру или помещается в определяемую пользователем хранимую процедуру. Скрипт может быть написан на языке R, Python или на внешних языках, таких как Java или .NET. Кроме того, можно использовать модели, которые предварительно обучены и сохранены в двоичном формате в таблице базы данных и вызываются с помощью функции T-SQL PREDICT.

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

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

Разрешения

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

Имя входа или учетная запись пользователя определяет субъект безопасности, которому в зависимости от требований внешнего скрипта может потребоваться несколько уровней доступа:

  • разрешение на доступ к базе данных, в которой включены внешние скрипты;
  • разрешения на чтение данных из защищенных объектов, таких как таблицы;
  • возможность записи новых данных в таблицу, такую как модель, или результатов оценки;
  • возможность создания новых объектов, например таблиц, хранимых процедур, использующих внешний скрипт, или пользовательских функций, использующих задания внешнего скрипта;
  • право на установку новых пакетов на компьютере SQL Server или использование пакетов, предоставленных группе пользователей.

Каждый пользователь, запускающий внешний скрипт в контексте выполнения SQL Server, должен быть сопоставлен с пользователем в базе данных. Рекомендуется не задавать разрешения каждому пользователю базы данных отдельно, а создавать роли для управления наборами разрешений и назначать их пользователям.

Дополнительные сведения см. в статье Give users permission to SQL Server Machine Learning Services (Предоставление пользователям разрешения в службах машинного обучения SQL Server).

Разрешения при использовании внешнего клиентского средства

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

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

  • База данных должна разрешать удаленные подключения.
  • Имя входа SQL или учетная запись Windows, используемая для доступа к базе данных, была добавлена в SQL Server на уровне экземпляра.
  • Имени входа SQL или пользователю Windows должно быть предоставлено разрешение на выполнение внешних скриптов. Обычно это разрешение может добавить только администратор базы данных.
  • Пользователь sql login или Window должен быть добавлен в качестве пользователя с соответствующими разрешениями в каждой базе данных, где внешний скрипт выполняет любые из этих операций:
    • извлечение данных;
    • запись или обновление данных;
    • создание новых объектов, например таблиц или хранимых процедур.

После подготовки имени входа или учетной записи пользователя Windows и предоставления необходимых разрешений можно выполнить внешний скрипт на SQL Server с помощью объекта источника данных в R или библиотеки revoscalepy в Python либо с помощью вызова хранимой процедуры, содержащей внешний скрипт.

При каждом запуске внешнего скрипта из система безопасности ядра СУБД получает контекст безопасности пользователя, который запустил задание R, а также управляет сопоставлением пользователя или имени входа с защищаемыми объектами.

Таким образом, все внешние скрипты, запущенные из удаленного клиента, должны определять имя входа или сведения о пользователе в качестве компонентов строки подключения.

Службы, используемые во внешней обработке (панель запуска)

Платформа расширяемости добавляет одну новую службу NT в список служб в установке SQL Server: панель запуска SQL Server (MSSSQLSERVER).

Ядро СУБД использует службу панели запуска SQL Server для создания экземпляра сеанса внешнего скрипта в виде отдельного процесса. Процесс выполняется в учетной записи с низким уровнем привилегий. Эта учетная запись отличается от SQL Server, самой панели запуска и удостоверения пользователя, под которым выполнялась хранимая процедура или запрос узла. Запуск скрипта в отдельном процессе в учетной записи с низким уровнем привилегий лежит в основе модели безопасности и изоляции для внешних скриптов в SQL Server.

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

Примечание.

По умолчанию панель запуска SQL Server настроена для работы под учетной записью NT Service\MSSQLLaunchpad, имеющей все необходимые разрешения на выполнение внешних скриптов. Дополнительные сведения о настраиваемых параметрах см. в статье Конфигурация службы панели запуска SQL Server.

Службы, используемые во внешней обработке (панель запуска)

Платформа расширяемости добавляет одну новую службу NT в список служб в установке SQL Server: панель запуска SQL Server (MSSSQLSERVER).

Ядро СУБД использует службу панели запуска SQL Server для создания экземпляра сеанса внешнего скрипта в виде отдельного процесса. Процесс выполняется под удостоверением пользователя панели запуска, но с дополнительным ограничением, содержащимся внутри AppContainer. Такой подход лежит в основе модели безопасности и изоляции для внешних скриптов в SQL Server.

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

Примечание.

По умолчанию панель запуска SQL Server настроена для работы под учетной записью NT Service\MSSQLLaunchpad, имеющей все необходимые разрешения на выполнение внешних скриптов. Дополнительные сведения о настраиваемых параметрах см. в статье Конфигурация службы панели запуска SQL Server.

Службы, используемые во внешней обработке

Платформа расширяемости добавляет одну новую управляющую программу в установку SQL Server: mssql-launchpadd. Mssql-launchpadd запускается с учетной записью с низким уровнем прав mssql_launchpadd, которая создается при установке пакета mssql-server-extensibility.

Поддерживается только один экземпляр ядра СУБД, и к нему привязана одна служба с заданной панелью запуска. При выполнении сценария служба панели запуска запускает отдельный процесс панели запуска с учетной записью пользователя с низким уровнем прав mssql_satellite с ее собственным новым PID, IPC, подключением и пространством имен сети. Каждый вспомогательный процесс наследует учетную запись пользователя панели запуска и использует эту учетную запись в течение времени выполнения сценария.

Дополнительные сведения см. в разделе Архитектура расширяемости в Службах машинного обучения SQL Server.

Удостоверения, используемые при обработке (SQLRUserGroup)

SQLRUserGroup (группа пользователей с ограниченным доступом к SQL) создается с помощью программы установки SQL Server и содержит пул локальных учетных записей пользователей Windows с минимальными правами доступа. Когда требуется внешний процесс, панель запуска выбирает доступную рабочую учетную запись и использует ее для выполнения процесса. В частности, панель запуска активирует доступную рабочую учетную запись, сопоставляет ее с удостоверением вызывающего пользователя и выполняет скрипт под этой учетной записью.

  • Группа SQLRUserGroup связана с определенным экземпляром. Для каждого экземпляра, на котором включено машинное обучение, требуется отдельный пул рабочих учетных записей. Учетные записи не могут совместно использоваться разными экземплярами.

  • Размер пула учетных записей пользователей является статическим со значением по умолчанию, равным 20 (поддерживает 20 одновременных сеансов). Число сеансов среды внешней среды выполнения, которые могут запускаться одновременно, ограничено размером пула учетных записей пользователей.

  • Имена рабочих учетных записей в пуле имеют формат SQLInstanceNamenn. Например, в экземпляре по умолчанию группа SQLRUserGroup содержит учетные записи с именами MSSQLSERVER01, MSSQLSERVER02 и т. д. до MSSQLSERVER20.

Параллельные задачи не используют дополнительные учетные записи. Например, если пользователь выполняет задачу оценки, которая использует параллельную обработку, для всех потоков многократно применяется одна и та же рабочая учетная запись. Если вы планируете активно использовать машинное обучение, можно увеличить число учетных записей, используемых для выполнения внешних скриптов. Дополнительные сведения см. в разделе Масштабирование параллельного выполнения внешних сценариев в SQL Server службы машинного обучения.

Разрешения, предоставляемые группе SQLRUserGroup

По умолчанию члены группы SQLRUserGroup имеют разрешения на чтение и выполнение файлов в каталогах SQL Server Binn, R_SERVICES и PYTHON_SERVICES. Сюда входит доступ к исполняемым файлам, библиотекам и встроенным наборам данных в дистрибутивах R и Python, установленных с помощью SQL Server.

Для защиты важных ресурсов в SQL Server можно определить список управления доступом (ACL), который запрещает доступ группе SQLRUserGroup. И наоборот, можно также предоставить разрешения на доступ к локальным ресурсам данных, которые находятся на главном компьютере помимо самого SQL Server.

Как запланировано при разработке, у группы SQLRUserGroup нет имени входа в базу данных или разрешений на доступ к данным. В определенных случаях может потребоваться создать имя входа, чтобы разрешить подключения с замыканием на себя, особенно когда доверенным удостоверением Windows является вызывающий пользователь. Эта возможность называется неявной проверкой подлинности. Дополнительные сведения см. в статье Добавление SQLRUserGroup в качестве пользователя базы данных.

Сопоставление удостоверений

При запуске сеанса панель запуска сопоставляет удостоверение вызывающего пользователя с рабочей учетной записью. Это сопоставление внешнего пользователя Windows или допустимого имени входа SQL с рабочей учетной записью является действительным только в течение срока действия хранимой процедуры SQL, выполняющей внешний скрипт R. Параллельные запросы, выполняемые с тем же именем входа, сопоставляются с той же рабочей учетной записью пользователя.

Во время выполнения панель запуска создает временные папки для хранения данных сеанса. По завершении сеанса папки удаляются. Для каталогов действует ограниченный доступ. Для R эту задачу выполняет RLauncher. Для Python эту задачу выполняет PythonLauncher. Каждая отдельная рабочая учетная запись ограничена своей папкой и не может обращаться к файлам в папках на уровне выше ее собственного. Однако рабочая учетная запись может считывать, записывать или удалять дочерние элементы в созданной рабочей папке сеанса. Если вы являетесь администратором компьютера, вы можете просмотреть каталоги, созданные для каждого процесса. Каждый каталог определяется собственным идентификатором GUID сеанса.

Изоляция AppContainer

Изоляция реализуется с помощью AppContainers. Во время выполнения при обнаружении внешнего скрипта в хранимой процедуре или запросе SQL Server вызывает панель запуска с запросом на средство запуска, зависящее от расширения. Панель запуска вызывает соответствующую среду выполнения в процессе со своим удостоверением и создает для нее контейнер AppContainer. Это изменение выгодно, поскольку управлять локальными учетными записями и паролями больше не нужно. Кроме того, в установках, где запрещены учетные записи локальных пользователей, устранение зависимости от учетной записи локального пользователя позволяет использовать эту функцию.

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

Сопоставление удостоверений

При запуске сеанса панель запуска сопоставляет удостоверение вызывающего пользователя с AppContainer.

Примечание.

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

Сопоставление удостоверений

Управляющая программа Launchpadd (с двумя "D" — mssql-launchpadd) сопоставляет удостоверение вызывающего пользователя с отдельным процессом launchpad (с одной буквой "D") с помощью папки "launchpad GUID" и вспомогательного сертификата. Эти папки "launchpad GUID" создаются в /var/opt/mssql-extensibility/data/. Процесс launchpad использует этот сертификат для обратной проверки подлинности в SQL, а затем создает временные папки для каждого идентификатора GUID сеанса в папке "launchpad GUID". Вспомогательный процесс (R, Python или ExtHost) может получить доступ к папке "launchpad GUID", сертификату в ней и папке "session GUID".

Следующий скрипт SQL выводит содержимое папок панели запуска.

EXECUTE sp_execute_external_script @language = N'R'
    ,@script = N'
print("Contents of /var/opt/mssql-extensibility/data :");
print(system("ls -al /var/opt/mssql-extensibility/data"));
print("Contents of Launchpad GUID folder:");
print(system("ls -al /var/opt/mssql-extensibility/data/*"));
print(system("ls -al /var/opt/mssql-extensibility/data/*/*"))
'
    ,@input_data_1 = N'SELECT 1 AS hello'

Неявная проверка подлинности (запросы с зацикливанием)

Неявная проверка подлинности описывает поведение запроса на подключение, при котором внешние процессы, выполняющиеся в качестве рабочих учетных записей с минимальными правами доступа, представлены в SQL Server в запросах с зацикливанием в виде доверенных удостоверений пользователей. В концептуальном плане неявная проверка подлинности уникальна для проверки подлинности Windows, в строках подключения SQL Server, указывающих доверенное соединение, в запросах, исходящих из внешних процессов, таких как скрипты R или Python. Иногда ее также называют зацикливанием.

Доверенные соединения поддерживаются во внешних скриптах только после дополнительной настройки. В архитектуре расширяемости внешние процессы выполняются под рабочими учетными записями, наследуя разрешения от родительской группы SQLRUserGroup. Если в строке подключения указывается Trusted_Connection=True, в запросе на подключение приводится удостоверение рабочей учетной записи, которое по умолчанию неизвестно SQL Server.

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

Доверенные соединения редко используются в качестве формулировки запроса на подключение. Если во внешнем скрипте задается подключение, чаще всего используется вход SQL, а если это подключение к источнику данных ODB, применяется полное имя пользователя и пароль.

Работа неявной проверки подлинности для сеансов внешних скриптов

На следующей схеме показано взаимодействие компонентов SQL Server со средой выполнения языка и реализация неявной проверки подлинности в Windows.

Неявная проверка подлинности в Windows

Неявная проверка подлинности (запросы с зацикливанием)

Неявная проверка подлинности описывает поведение запроса на подключение, при котором внешние процессы, выполняющиеся в AppContainers, представлены в SQL Server в запросах с зацикливанием в виде доверенных удостоверений пользователей. В концептуальном плане неявная проверка подлинности больше не уникальна для проверки подлинности Windows, в строках подключения SQL Server, указывающих доверенное соединение, в запросах, исходящих из внешних процессов, таких как скрипты R или Python. Иногда ее также называют зацикливанием.

Управляя удостоверениями и учетными данными, AppContainer предотвращает использование учетных данных пользователя для получения доступа к ресурсам или входа в другие среды. Среда AppContainer создает идентификатор, использующий объединенные идентификаторы пользователя и приложения, поэтому учетные данные уникальны для каждого связывания пользователей и приложений и приложение не может олицетворять пользователя. Дополнительные сведения см. в разделе Изоляция AppContainer.

Дополнительные сведения о зацикливании подключений см. в разделе Подключение к SQL Server из скрипта Python или R с зацикливанием.

Работа неявной проверки подлинности для сеансов внешних скриптов

На следующей схеме показано взаимодействие компонентов SQL Server со средой выполнения языка и реализация неявной проверки подлинности в Windows.

Неявная проверка подлинности в Windows

Неявная проверка подлинности (запросы с зацикливанием)

Неявная проверка подлинности описывает поведение запроса на подключение, при котором внешние процессы, выполняющиеся в качестве пользователей mssql_satellite с минимальными правами доступа в их собственных пространствах имен, представлены в SQL Server в запросах с зацикливанием в виде доверенных удостоверений пользователей. Иногда ее также называют зацикливанием.

Зацикливание подключения достигается с помощью вспомогательного сертификата из папки "launchpad GUID" для проверки обратной подлинности SQL Server вспомогательным процессом. Удостоверение вызывающего пользователя сопоставляется с этим сертификатом, поэтому вспомогательный процесс, подключающийся к SQL Server с помощью сертификата, можно сопоставить с вызывающим пользователем.

Дополнительные сведения см. в разделе Подключение к SQL Server из скрипта Python или R с замыканием на себя.

Работа неявной проверки подлинности для сеансов внешних скриптов

На следующей схеме показано взаимодействие компонентов SQL Server со средой выполнения языка и реализация неявной проверки подлинности в Linux.

Неявная проверка подлинности в Linux

Отсутствие поддержки прозрачного шифрования неактивных данных

Прозрачное шифрование данных (TDE) не поддерживается для данных, отправленных или полученных из среды выполнения внешнего скрипта. Причина в том, что внешний процесс выполняется вне процесса SQL Server. Таким образом, данные, используемые внешней средой выполнения, не защищаются функциями шифрования ядра СУБД. Это поведение аналогично действию любого другого работающего на компьютере SQL Server клиента, который считывает данные из базы данных и создает копию.

В результате прозрачное шифрование данных не применяется к данным, используемым во внешних скриптах, сохраненным на диске, или к сохраненным промежуточным результатам. Однако по-прежнему действуют другие типы шифрования, такие как шифрование Windows BitLocker или решения шифрования сторонних производителей, применяемые на уровне файла или папки.

При использовании Always Encrypted у внешних сред выполнения отсутствует доступ к ключам шифрования. Поэтому отправить данные в скрипты невозможно.

Следующие шаги

В этой статье вы узнали о компонентах и модели взаимодействия архитектуры безопасности, встроенной в платформу расширяемости. В этой статье рассматривались такие ключевые аспекты, как назначение панели запуска, SQLRUserGroup и рабочих учетных записей, изоляция процессов внешних скриптов и сопоставление удостоверений пользователей с рабочими учетными записями.

Далее вы можете ознакомится с инструкциями по предоставлению разрешений. Для работы с серверами, использующими проверку подлинности Windows, следует прочесть статью о создании учетных данных для SQLRUserGroup, чтобы узнать, когда требуется дополнительная настройка.