Конструкторские сборки

Применимо к:SQL Server

В этой статье описаны следующие факторы, которые следует учитывать при разработке сборок:

  • Упаковочные сборки
  • управление безопасностью сборок;
  • ограничения на сборки.

Сборки упаковки

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

При упаковке кода в сборку рассмотрите следующее:

  • Определяемые пользователем типы данных CLR и индексы, зависящие от определяемых пользователем функций среды CLR, могут вызвать появление в базе данных материализованных данных, зависящих от сборки. Изменение кода сборки часто сложнее при наличии сохраненных данных, которые зависят от сборки в базе данных. Поэтому лучше отделять код, от которого зависят сохраненные зависимости данных (например, определяемые пользователем типы и индексы с помощью определяемых пользователем функций) от кода, который не имеет этих сохраненных зависимостей данных. Для получения дополнительной информации см. Реализовать сборки и ALTER ASSEMBLY.

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

Безопасность доступа к коду больше не поддерживается

Среда CLR использует управление доступом для кода (CAS) в .NET Framework, которое больше не поддерживается в качестве границы безопасности. Сборка СРЕДЫ CLR, созданная с PERMISSION_SET = SAFE возможностью доступа к ресурсам внешней системы, вызову неуправляемого кода и получению привилегий sysadmin. В SQL Server 2017 (14.x) и более поздних версиях sp_configure параметр, clr strict security, повышает безопасность сборок СРЕДЫ CLR. clr strict security включен по умолчанию и рассматривает сборки SAFE и EXTERNAL_ACCESS, как если бы они были помечены UNSAFE. Параметр clr strict security можно отключить для обратной совместимости, но не рекомендуется.

Рекомендуется подписать все сборки сертификатом или асимметричным ключом с соответствующим именем входа, предоставленным UNSAFE ASSEMBLY в master базе данных. Администраторы SQL Server также могут добавлять сборки в список сборок, которым должен доверять ядро СУБД. Дополнительные сведения см. в разделе sys.sp_add_trusted_assembly.

Управление безопасностью сборки

Можно управлять доступом сборки к ресурсам, защищенным системой безопасности доступа к коду платформы .NET, когда она выполняет управляемый код. Для этого необходимо указать один из трех наборов разрешений при создании или изменении сборки: SAFE, EXTERNAL_ACCESSили UNSAFE.

Разрешение SAFE

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

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

EXTERNAL_ACCESS разрешения

EXTERNAL_ACCESS позволяет сборкам получать доступ к определенным ресурсам внешней системы, таким как файлы, сети, веб-службы, переменные среды и реестр. Только имена входа SQL Server с EXTERNAL ACCESS разрешениями могут создавать EXTERNAL_ACCESS сборки.

SAFE и EXTERNAL_ACCESS сборки могут содержать только код, который является проверяемо типобезопасной. Это означает, что данные сборки могут получать доступ к классам только через правильно определенные точки входа, доступные для определения типа. Таким образом, они не могут произвольно получить доступ к буферам памяти, не принадлежащим коду. Кроме того, они не могут выполнять операции, которые могут негативно повлиять на надежность процесса SQL Server.

НЕБЕЗОПАСНОЕ разрешение

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

Кроме того, указание UNSAFE позволяет коду в сборке выполнять операции, которые считаются небезопасными для средства проверки CLR. Эти операции могут получить доступ к буферам памяти в пространстве обработки SQL Server неконтролируемым образом. UNSAFE Сборки также могут привести к отложению системы безопасности SQL Server или среды CLR. UNSAFE разрешения должны предоставляться только высоконадежным сборкам опытным разработчикам или администраторам. Только члены роли системного администратора с фиксированным сервером могут создавать UNSAFE сборки.

ограничения на сборки.

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

Запрещенные настраиваемые атрибуты

Сборки не могут быть помечены следующими настраиваемыми атрибутами:

System.ContextStaticAttribute
System.MTAThreadAttribute
System.Runtime.CompilerServices.MethodImplAttribute
System.Runtime.CompilerServices.CompilationRelaxationsAttribute
System.Runtime.Remoting.Contexts.ContextAttribute
System.Runtime.Remoting.Contexts.SynchronizationAttribute
System.Runtime.InteropServices.DllImportAttribute
System.Security.Permissions.CodeAccessSecurityAttribute
System.STAThreadAttribute
System.ThreadStaticAttribute

Кроме того, SAFE и EXTERNAL_ACCESS сборки не могут быть помечены следующими настраиваемыми атрибутами:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

Неразрешенные API-интерфейсы платформы .NET Framework

Любой API .NET Framework, помеченный одним из запрещенных HostProtectionAttributes, не может вызываться из SAFE и EXTERNAL_ACCESS сборок.

HostProtectionAttribute.SelfAffectingProcessMgmt
HostProtectionAttribute.SelfAffectingThreading
HostProtectionAttribute.Synchronization
HostProtectionAttribute.SharedState
HostProtectionAttribute.ExternalProcessMgmt
HostProtectionAttribute.ExternalThreading
HostProtectionAttribute.SecurityInfrastructure
HostProtectionAttribute.MayLeakOnAbort
HostProtectionAttribute.UI

Поддерживаемые сборки платформа .NET Framework

Любая сборка, на которую ссылается пользовательская сборка, должна быть загружена в SQL Server с помощью CREATE ASSEMBLY. Следующие платформа .NET Framework сборки уже загружаются в SQL Server и, следовательно, могут ссылаться на пользовательские сборки без необходимости использованияCREATE ASSEMBLY.

  • mscorlib.dll
  • CustomMarshalers.dll
  • Microsoft.VisualBasic.dll
  • Microsoft.VisualC.dll
  • System.Configuration.dll
  • System.Core.dll
  • System.Data.OracleClient.dll
  • System.Data.SqlXml.dll
  • System.Data.dll
  • System.Deployment.dll
  • System.Security.dll
  • System.Transactions.dll
  • System.Web.Services.dll
  • System.Xml.Linq.dll
  • system.Xml.dll
  • System.dll

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

  • Last updated on