Знакомство с интеграцией CLR в SQL Server
Среда CLR является сердцем платформа .NET Framework и предоставляет среду выполнения для всего кода платформа .NET Framework. Код, выполняемый в среде CLR, называется управляемым кодом. Среда CLR предоставляет различные функции и услуги, требуемые для выполнения программы, включая JIT-компиляцию, распределение и управление памятью, соблюдение безопасности типов, обработку исключений, управление потоками и безопасность.
Если среда CLR размещается в Microsoft SQL Server (что принято называть интеграцией со средой CLR), то появляется возможность разрабатывать в управляемом коде хранимые процедуры, триггеры, определяемые пользователем функции, определяемые пользователем типы и определяемые пользователем статистические функции. Из-за того, что управляемый код перед выполнением производит компиляцию в машинный код, можно достичь значительного увеличения производительности в некоторых сценариях.
Управляемый код, выполняющийся в платформа .NET Framework, использует код access Security (CAS), ссылки кода и домены приложений, чтобы предотвратить выполнение сборок определенных операций. В SQL Server используется CAS для обеспечения безопасности управляемого кода и предотвращения нарушений безопасности операционной системы или сервера баз данных.
Безопасность доступа к коду (CAS) не рекомендуется использовать во всех версиях платформа .NET Framework и .NET. В последних версиях .NET заметки CAS не учитываются и при использовании API, связанных с CAS, возникают ошибки. Разработчикам следует искать альтернативные средства для выполнения задач безопасности.
Этот раздел предназначен для предоставления лишь такого количества сведений, с которого можно приступать к программированию в рамках интеграции SQL Server со средой CLR, и не рассчитан на всестороннее изложение. Дополнительные сведения см. в статье Общие сведения об интеграции со средой CLR.
Включение интеграции со средой CLR
Возможность интеграции со средой CLR отключена в Microsoft SQL Server по умолчанию, поэтому ее нужно включить, чтобы использовать объекты, использующие интеграцию со средой CLR. Чтобы включить интеграцию со средой CLR с помощью Transact-SQL, воспользуйтесь параметром clr enabled хранимой процедуры sp_configure , как показано ниже.
sp_configure 'clr enabled', 1 GO RECONFIGURE GO Интеграцию со средой CLR можно отключить, присвоив параметру clr enabled значение 0. При этом SQL Server прекращает выполнять все процедуры CLR и выгружает все домены приложений.
Дополнительные сведения см. в разделе Включение интеграции со средой CLR.
Развертывание сборки среды CLR
После тестирования и проверки методов CLR на тестовом сервере их можно распространить на рабочих серверах с помощью скрипта развертывания. Скриптов развертывания можно создать вручную или с помощью SQL Server Management Studio. Дополнительные сведения см. в документации по версии SQL Server для используемой версии SQL Server.
Документация по SQL Server
Безопасность интеграции со средой CLR
Интеграция модели безопасности Microsoft SQL Server со средой Microsoft .NET Framework CLR позволяет поддерживать доступ для различных типов объектов (как CLR, так и не CLR), выполняемых в SQL Server, а также обеспечивать безопасность этого доступа. Для вызова этих объектов может применяться инструкция Transact-SQL или другой объект CLR, выполняемый на сервере.
Отладка сборки CLR
В Microsoft SQL Server предоставляется поддержка для отладки кода Transact-SQL и объектов среды CLR в базе данных. Процесс отладки работает с кодом на всех используемых языках: пользователи могут беспрепятственно переходить к коду объектов среды CLR из кода Transact-SQL и наоборот.
Дополнительные сведения см. в разделе Отладка объектов базы данных CLR.
См. также раздел
- Управление доступом для кода и ADO.NET
- Общие сведения об ADO.NET
Пользовательские типы CLR
SQL Server позволяет создавать объекты базы данных, программируемые для сборки, созданной в среде CLR платформа .NET Framework. Объекты базы данных, которые способны пользоваться преимуществами многофункциональной модели программирования, предоставляемыми средой CLR, содержат триггеры, хранимые процедуры, функции, агрегатные функции и типы.
Возможность выполнения кода CLR по умолчанию имеет значение OFF в SQL Server. Среду CLR можно включить с помощью системной хранимой процедуры sp_configure .
Начиная с SQL Server 2005 (9.x), вы можете использовать определяемые пользователем типы (UT) для расширения системы скалярных типов сервера, обеспечивая хранение объектов CLR в базе данных SQL Server. Определяемые пользователем типы могут содержать несколько элементов, и их поведение может отличаться от традиционных псевдонимов типов данных, состоящих из одного системного типа данных SQL Server.
Система обращается к определяемым пользователем типам как к единым объектам, поэтому их использование для сложных типов данных может негативно отразиться на производительности. Для моделирования сложных данных лучше подходят обычные строки и таблицы. Определяемые пользователем функции в SQL Server хорошо подходят для следующих задач:
- Значения даты, времени, валюты и расширенные числовые типы
- Данные геопространственных приложений
- Закодированные или зашифрованные данные
Процесс разработки определяемых пользователем типов в SQL Server состоит из следующих этапов:
- Кодирование и построение сборки, определяющей определяемый пользователем тип. Определяемые пользователем типы определяются с помощью любого языка, поддерживаемого средой CLR платформы .NET Framework и создающего проверяемый код. Среди таких языков Visual C# и Visual Basic .NET. Доступ к данным предоставляется как к полям и свойствам класса или структуры платформы .NET Framework, а поведение определяется методами класса или структуры.
- Регистрирует сборку. Определяемые пользователем функции можно развернуть с помощью пользовательского интерфейса Visual Studio в проекте базы данных или с помощью инструкции Transact-SQL CREATE ASSEMBLY, которая копирует сборку, содержащую класс или структуру, в базу данных.
- Создание определяемого пользователем типа в SQL Server. После загрузки сборки в базу данных узла используйте инструкцию Transact-SQL CREATE TYPE для создания определяемого пользователем типа и предоставления членов класса или структуры в качестве членов определяемого пользователем типа. Определяемые пользователем типы существуют только в контексте одной базы данных, а после регистрации они не имеют зависимостей от внешних файлов, из которых были созданы.
Примечание До SQL Server 2005 (9.x) определяемые пользователем функции, созданные из платформа .NET Framework сборок, не поддерживались. Однако вы по-прежнему можете использовать SQL Server псевдонимы типов данных с помощью sp_addtype. Синтаксис CREATE TYPE можно использовать для создания собственных SQL Server определяемых пользователем типов данных и определяемых пользователем типов данных.
В этом разделе
Создание типа User-Defined
Описывает способ создания определяемых пользователем типов.
Регистрация определяемых пользователем типов в SQL Server
Описывается регистрация определяемых пользователем типов и управление ими в SQL Server.
Работа с определяемыми пользователем типами в SQL Server
Описывает способ создания запросов при помощи определяемых пользователем типов.
Доступ к определяемым пользователем типам в ADO.NET
Описывается работа с определяемых пользователем типов с помощью поставщика данных платформа .NET Framework для SQL Server в ADO.NET.
Интеграция с общеязыковой средой выполнения
Microsoft SQL Server и Управляемый экземпляр SQL Azure позволяют реализовать некоторые функции с языками .NET с помощью интеграции среды CLR в качестве SQL Server серверных модулей (процедур, функций и триггеров). Среда CLR предоставляет управляемому коду такие услуги, как межъязыковая интеграция, управление доступом для кода, управление временем существования объекта, а также поддержку отладки и профилирования. Для SQL Server пользователей и разработчиков приложений интеграция со средой CLR означает, что теперь вы можете писать хранимые процедуры, триггеры, определяемые пользователем типы, определяемые пользователем функции (скалярные и табличные значения) и определяемые пользователем агрегатные функции с помощью любого языка платформа .NET Framework, включая Microsoft Visual Basic .NET и Microsoft Visual C#. SQL Server включает предварительно установленную платформа .NET Framework версии 4.
Среда CLR использует управление доступом для кода (CAS) в .NET Framework, которое больше не поддерживается в качестве границы безопасности. Сборки среды CLR, созданные с помощью PERMISSION_SET = SAFE , могут получать доступ к внешним системным ресурсам, вызывать неуправляемый код и получать права системного администратора. Начиная с SQL Server 2017 (14.x);, появился параметр sp_configure , называемый clr strict security , для повышения безопасности сборок среды CLR. clr strict security включен по умолчанию и рассматривает сборки SAFE и EXTERNAL_ACCESS , как если бы они были помечены UNSAFE . Параметр clr strict security можно отключить для обеспечения обратной совместимости, но это делать не рекомендуется. Корпорация Майкрософт рекомендует подписывать все сборки с помощью сертификата или асимметричного ключа с соответствующим именем входа, которому предоставлено разрешение UNSAFE ASSEMBLY в базе данных master. Дополнительные сведения см. в статье о параметре clr strict security. Администраторы SQL Server также могут добавлять сборки в список сборок, которым должно доверять ядро СУБД. Дополнительные сведения см. в разделе sys.sp_add_trusted_assembly.
В этом 6-минутном видео показано, как использовать среду CLR в Управляемый экземпляр SQL Azure:
Когда следует использовать модули CLR
Интеграция со средой CLR позволяет реализовать сложные функции, доступные в платформа .NET Framework таких как регулярные выражения, код для доступа к внешним ресурсам (серверам, веб-службам, базам данных), пользовательское шифрование и т. д. Ниже приведены некоторые преимущества интеграции со средой CLR на стороне сервера.
- Улучшенная модель программирования. Языки платформа .NET Framework во многих отношениях богаче, чем Transact-SQL, предлагая конструкции и возможности, ранее недоступные разработчикам SQL Server. Разработчики могут также использовать всю мощь библиотеки платформы .NET Framework (.NET Framework Library), предоставляющей обширный набор классов, которые позволяют быстро и эффективно решать возникающие при разработке проблемы.
- Улучшенная надежность и безопасность. Управляемый код выполняется в среде CLR, размещаемой в компоненте Database Engine. SQL Server использует это для обеспечения более безопасной и безопасной альтернативы расширенным хранимым процедурам, доступным в более ранних версиях SQL Server.
- Возможность определять типы данных и агрегатные функции. Определяемые пользователем типы и определяемые пользователем агрегаты — это два новых управляемых объекта базы данных, расширяющие возможности хранения и запросов SQL Server.
- Упрощение процесса разработки в результате стандартизации среды. Разработка баз данных интегрирована в будущие выпуски среды разработки Microsoft Visual Studio .NET. Для разработки и отладки объектов и скриптов баз данных разработчики используют те же инструментальные средства, что и для разработки компонентов и служб платформы .NET Framework клиентского и среднего уровня.
- Возможность повышения производительности и масштабируемости. Во многих случаях средства компиляции и модели выполнения платформы .NET Framework предоставляют выигрыш в производительности по сравнению с Transact-SQL.
SQL Server расширения языка предоставляют альтернативную среду выполнения для сред выполнения, близких к ядру СУБД. Обсуждение различий между SQL CLR и расширениями языка SQL см. в разделе Сравнение расширений языка SQL Server и SQL CLR.
В следующей таблице приводится список подразделов данного раздела.
Общие сведения об интеграции со средой CLR
Описывает типы объектов, которые можно создать с помощью интеграции со средой CLR. Также проверяет требования к созданию объектов базы данных с помощью интеграции со средой CLR.
Архитектура интеграции со средой CLR
Описание целей разработки интеграции со средой CLR.
Включение интеграции со средой CLR
Описание включения интеграции со средой CLR.
Управление доступом для кода на основе интеграции со средой CLR
Среда CLR поддерживает модель безопасности, называемую управлением доступом для кода. В этой модели разрешения предоставляются сборкам на основе идентификатора кода. Дополнительные сведения см. в разделе «Управление доступом для кода» справочной документации пакета средств разработки программного обеспечения .NET Framework.
Политика безопасности, которая регламентирует разрешения, предоставляемые сборкам, определяется в трех разных местах.
- Политика компьютера: это политика, которая действует для всего управляемого кода, работающего на компьютере, на котором установлен SQL Server.
- Политика пользователя: это политика, действимая для управляемого кода, размещенного процессом. Для SQL Server политика пользователя зависит от учетной записи Windows, в которой выполняется служба SQL Server.
- Политика узла: это политика, настроенная узлом среды CLR (в данном случае SQL Server), которая действует для управляемого кода, работающего в этом узле.
Механизм управления доступом к коду, поддерживаемый средой CLR, основан на предположении, что в среде времени выполнения может размещаться код, доверенный полностью или частично. Ресурсы, защищенные безопасностью доступа к коду CLR, обычно упаковываются в интерфейсы программирования управляемых приложений, которые требуют соответствующего разрешения, прежде чем разрешать доступ к ресурсу. Требование разрешения удовлетворяется только в том случае, если все вызывающие элементы (на уровне сборки) в стеке вызовов обладают соответствующими ресурсными разрешениями.
Набор разрешений безопасности доступа к коду, предоставляемых управляемому коду при выполнении внутри SQL Server, является пересечением набора разрешений, предоставленных указанным выше тремя уровнями политики. Даже если SQL Server предоставляет набор разрешений для сборки, загруженной в SQL Server, конечный набор разрешений, предоставленных пользовательскому коду, может быть ограничен политиками уровня пользователя и компьютера.
Наборы разрешений на уровне политики узла SQL Server
Набор разрешений безопасности доступа к коду, предоставленных сборкам уровня политики узла SQL Server, определяется набором разрешений, указанным при создании сборки. Существует три набора разрешений: SAFE, EXTERNAL_ACCESS и UNSAFE (указанные с помощью PERMISSION_SET параметра CREATE ASSEMBLY (Transact-SQL)).
SQL Server предоставляет уровень политики безопасности уровня узла среде CLR при его размещении; Эта политика является дополнительным уровнем политики ниже двух уровней политики, которые всегда применяются. Эта политика устанавливается для каждого домена приложения, созданного SQL Server. Эта политика не предназначена для домена приложения по умолчанию, который будет применяться при создании экземпляра СРЕДЫ CLR SQL Server.
Политика уровня узла SQL Server — это сочетание фиксированной политики SQL Server для системных сборок и пользовательской политики для пользовательских сборок.
Исправленная политика для сборок СРЕДЫ CLR и системных сборок SQL Server предоставляет им полное доверие.
Указанная пользователем часть политики узла SQL Server основана на владельце сборки, указывающей один из трех контейнеров разрешений для каждой сборки. Дополнительные сведения о правах доступа, перечисленных ниже, см. в документации пакета SDK для платформы .NET Framework.
SAFE
Разрешаются только внутренние вычисления и локальный доступ к данным. SAFE является самым строгим набором разрешений. Код, выполняемый сборкой с разрешениями SAFE , не может получить доступ к ресурсам внешней системы, таким как файлы, сети, переменные среды или реестр.
Сборки SAFE имеют следующие разрешения и значения:
| Разрешение | Значения и описание |
|---|---|
| SecurityPermission | Выполнение: разрешение на выполнение управляемого кода. |
| SqlClientPermission | Контекстное подключение = true, контекстное подключение = да: можно использовать только контекст-соединение, а строка подключения может указывать только значение «context connection=true» или «context connection=yes». |
EXTERNAL_ACCESS
EXTERNAL_ACCESS сборки имеют те же разрешения , что и сборки SAFE , с дополнительной возможностью доступа к ресурсам внешней системы, таким как файлы, сети, переменные среды и реестр.
EXTERNAL_ACCESS сборки также имеют следующие разрешения и значения:
| Разрешение | Значения и описание |
|---|---|
| DistributedTransactionPermission | Неограниченные: разрешены распределенные транзакции. |
| DNSPermission | Неограниченный : разрешение на запрос сведений с серверов доменных имен. |
| EnvironmentPermission | Неограниченный доступ: разрешен полный доступ к переменным системы и пользовательской среды. |
| EventLogPermission | Администрирование: разрешены следующие действия: создание источника событий, чтение существующих журналов, удаление источников событий или журналов, реагирование на записи, очистка журнала событий, прослушивание событий и доступ к коллекции всех журналов событий. |
| FileIOPermission | Неограниченный доступ: разрешен полный доступ к файлам и папкам. |
| KeyContainerPermission | Неограниченный доступ: разрешен полный доступ к контейнерам ключей. |
| NetworkInformationPermission | Доступ: разрешено pinging. |
| RegistryPermission | Позволяет HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIG и HKEY_USERS. |
| SecurityPermission | Утверждение: возможность утверждать, что все вызывающие данные этого кода имеют необходимое разрешение для операции. |
ControlPrincipal: возможность управления основным объектом.
Выполнение: разрешение на выполнение управляемого кода.
UNSAFE
UNSAFE позволяет сборкам неограниченный доступ к ресурсам как внутри, так и за пределами SQL Server. Код, выполняемый из сборки UNSAFE, также может вызывать неуправляемый код.
Сборки UNSAFE предоставляются FullTrust.
Рекомендуемые параметры разрешений
SAFE — это рекомендуемый параметр разрешения для сборок, выполняющих задачи вычисления и управления данными без доступа к ресурсам за пределами SQL Server.
EXTERNAL_ACCESS рекомендуется для сборок, обращаюющихся к ресурсам за пределами SQL Server. EXTERNAL_ACCESS сборки по умолчанию выполняются как учетная запись службы SQL Server. Для EXTERNAL_ACCESS кода можно явно олицетворить контекст безопасности проверки подлинности Windows вызывающей стороны. Так как по умолчанию используется учетная запись службы SQL Server, разрешение на выполнение EXTERNAL_ACCESS должно быть предоставлено только именам входа, доверенным для запуска от имени учетной записи службы.
С точки зрения безопасности сборки EXTERNAL_ACCESS и UNSAFE идентичны. Однако EXTERNAL_ACCESS сборки обеспечивают различные защиты надежности и надежности, которые не находятся в сборках UNSAFE.
Указание UNSAFE позволяет коду в сборке выполнять незаконные операции с пространством процессов SQL Server, поэтому может компрометировать надежность и масштабируемость SQL Server. Дополнительные сведения о создании сборок СРЕДЫ CLR в SQL Server см. в разделе «Управление сборками интеграции CLR».
SQL Server содержит сборки CLR, которые ядро СУБД использует для предоставления определенных функций. Сборка Microsoft.SQLServer.Types , включенная в установку SQL Server, отображается в метаданных как сборка UNSAFE . Это сделано намеренно. Эти сборки считаются доверенными & по умолчанию безопасными.
Доступ к внешним ресурсам
Если определяемый пользователем тип (UDT), хранимая процедура или другая сборка конструктора зарегистрирована в наборе разрешений SAFE , то управляемый код, выполняемый в конструкции, не может получить доступ к внешним ресурсам. Однако если заданы наборы разрешений EXTERNAL_ACCESS или UNSAFE , а управляемый код пытается получить доступ к внешним ресурсам, SQL Server применяет следующие правила:
| If | Следующее действие |
|---|---|
| Контекст выполнения соответствует имени входа SQL Server. | Попытки получить доступ к внешним ресурсам отклоняются, и активизируется исключение безопасности. |
| Контекст выполнения соответствует имени входа Windows, и контекстом выполнения является первоначальный вызывающий объект. | Доступ к внешнему ресурсу осуществляется в контексте безопасности учетной записи службы SQL Server. |
| Вызывающий объект не является первоначальным вызывающим объектом. | Доступ запрещается, и активизируется исключение безопасности. |
| Контекст выполнения соответствует имени входа Windows, контекст выполнения является исходным вызывающим объектом, а к вызывающему объекту применяется олицетворение. | При доступе используется контекст безопасности вызывающего объекта, а не учетная запись службы. |
Сводные данные о наборе разрешений
На следующей диаграмме приведены ограничения и разрешения, предоставленные наборам разрешений SAFE, EXTERNAL_ACCESS и UNSAFE .
| Функциональность | БЕЗОПАСНОГО | EXTERNAL_ACCESS | НЕБЕЗОПАСНЫХ |
|---|---|---|---|
| Разрешения безопасности доступа к коду | Только выполнение | Выполнение и доступ к внешним ресурсам | Неограниченное (включая P/Invoke) |
| Ограничения модели программирования | Да | Да | Без ограничений |
| Требование к проверяемости | Да | Да | No |
| Локальный доступ к данным | Да | Да | Да |
| Возможность вызова машинного кода | No | Нет | Да |