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


Design assemblies

Applies to:SQL Server

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

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

Package assemblies

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

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

  • Определяемые пользователем типы данных CLR и индексы, зависящие от определяемых пользователем функций среды CLR, могут вызвать появление в базе данных материализованных данных, зависящих от сборки. Изменение кода сборки часто сложнее при наличии сохраненных данных, которые зависят от сборки в базе данных. Поэтому лучше отделять код, от которого зависят сохраненные зависимости данных (например, определяемые пользователем типы и индексы с помощью определяемых пользователем функций) от кода, который не имеет этих сохраненных зависимостей данных. For more information, see Implement assemblies and 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 также могут добавлять сборки в список сборок, которым должен доверять ядро СУБД. For more information, see sys.sp_add_trusted_assembly.

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

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

SAFE permission

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

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

EXTERNAL_ACCESS permission

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

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

UNSAFE permission

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

Кроме того, указание UNSAFE позволяет коду в сборке выполнять операции, которые считаются небезопасными для средства проверки CLR. Эти операции могут получить доступ к буферам памяти в пространстве обработки SQL Server неконтролируемым образом. UNSAFE Сборки также могут привести к отложению системы безопасности SQL Server или среды CLR. UNSAFE разрешения должны предоставляться только высоконадежным сборкам опытным разработчикам или администраторам. Only members of the sysadmin fixed server role can create UNSAFE assemblies.

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

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