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

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

В этой статье описывается архитектура безопасности, используемая для интеграции ядра СУБД SQL Server и связанных компонентов с платформой расширяемости в Службах машинного обучения SQL Server. Рассматриваются защищаемые объекты, службы, идентификаторы процессов и разрешения. Ключевые темы, рассматриваемые в этой статье, включают назначение Launchpad, 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 Машинное обучение Services (Предоставление пользователям разрешения в службах машинного обучения SQL Server).

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Ядро СУБД использует службу панели запуска SQL Server для создания экземпляра сеанса внешнего скрипта в виде отдельного процесса. Процесс выполняется под учетной записью пользователя launchpad, но с дополнительным ограничением: он помещен в контейнер AppContainer. Запуск скрипта в отдельном процессе в 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.

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

Дополнительные сведения см. в разделе Архитектура расширяемости в Службах машинного обучения 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 нет имени входа в базу данных или разрешений на доступ к данным. В некоторых случаях может потребоваться создать учетную запись для входа, чтобы разрешить loopback-подключения, особенно если вызов выполняется от имени доверенной учетной записи Windows. Эта возможность называется неявной проверкой подлинности. Дополнительные сведения см. в статье Добавление SQLRUserGroup в качестве пользователя базы данных.

Сопоставление идентификаторов

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

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

Изоляция AppContainer

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

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

Сопоставление идентификаторов

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

Примечание.

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

Сопоставление идентификаторов

Демон Launchpadd (с двумя "D" — mssql-launchpadd) сопоставляет удостоверение личности вызывающего пользователя отдельному процессу launchpad (с одной буквой "D"), имеющему папку "launchpad GUID" и вспомогательный сертификат. Эти папки "launchpad GUID" создаются в /var/opt/mssql-extensibility/data/. Процесс launchpad использует этот сертификат для обратной аутентификации в SQL Server, после чего создает временные папки для каждого GUID сеанса в папке GUID launchpad. Вспомогательный процесс (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'

Подразумеваемая аутентификация (loopback-запросы)

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

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

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

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

Как работает неявная аутентификация для сеансов внешних сценариев

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

Подразумеваемая аутентификация в Windows

Неявная аутентификация (loopback-запросы)

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

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

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

Как работает неявная аутентификация для сеансов внешних сценариев

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

Подразумеваемая аутентификация в Windows

Неявная аутентификация (loopback-запросы)

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

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

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

Как работает неявная аутентификация для сеансов внешних сценариев

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

Неявная аутентификация в Linux

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

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

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

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

Связанные материалы

  • Last updated on