Udostępnij przez


Design assemblies

Applies to:SQL Server

W tym artykule opisano następujące czynniki, które należy wziąć pod uwagę podczas projektowania zestawów:

  • Packaging assemblies
  • Zarządzanie zabezpieczeniami zestawów
  • Ograniczenia dotyczące zestawów

Package assemblies

Zestaw może zawierać funkcje dla więcej niż jednej procedury lub typu programu SQL Server w klasach i metodach. W większości przypadków warto spakować funkcjonalność procedur, które wykonują powiązane funkcje w ramach tego samego zestawu, zwłaszcza jeśli te procedury współdzielą klasy, których metody nazywają siebie nawzajem. Na przykład klasy wykonujące zadania zarządzania wpisami danych dla wyzwalaczy środowiska uruchomieniowego języka wspólnego (CLR) i procedury składowane CLR można spakować w tym samym zestawie. Wynika to z faktu, że metody dla tych klas są bardziej prawdopodobne, aby wywoływać siebie nawzajem niż metody mniej powiązanych zadań.

Podczas pakowania kodu do zestawu należy wziąć pod uwagę następujące kwestie:

  • Zdefiniowane przez użytkownika typy i indeksy środowiska CLR zależne od funkcji zdefiniowanych przez użytkownika środowiska CLR mogą spowodować, że utrwalone dane będą znajdować się w bazie danych, która zależy od zestawu. Modyfikowanie kodu zestawu jest często bardziej złożone w przypadku utrwalania danych, które zależą od zestawu w bazie danych. Dlatego lepiej jest oddzielić kod, na którym polegają utrwalone zależności danych (takie jak typy zdefiniowane przez użytkownika i indeksy przy użyciu funkcji zdefiniowanych przez użytkownika) z kodu, który nie ma tych trwałych zależności danych. For more information, see Implement assemblies and ALTER ASSEMBLY.

  • Jeśli kawałek kodu zarządzanego wymaga większego uprawnienia, lepiej jest oddzielić ten kod do oddzielnego zestawu od kodu, który nie wymaga wyższych uprawnień.

Zabezpieczenia dostępu kodu nie są już obsługiwane

CLR używa zabezpieczeń dostępu kodu (CAS) w programie .NET Framework, który nie jest już obsługiwany jako granica bezpieczeństwa. Zestaw CLR utworzony za pomocą PERMISSION_SET = SAFE może mieć dostęp do zasobów systemu zewnętrznego, wywołać kod niezarządzany i uzyskać uprawnienia administratora systemu. W programie SQL Server 2017 (14.x) i nowszych wersjach opcja sp_configure, clr strict security, zwiększa bezpieczeństwo zestawów CLR. clr strict security jest domyślnie włączona i traktuje zestawy SAFE i EXTERNAL_ACCESS tak, jakby zostały oznaczone UNSAFE. Opcja clr strict security może być wyłączona w celu zapewnienia zgodności z poprzednimi wersjami, ale nie jest zalecana.

Zalecamy podpisanie wszystkich zestawów certyfikatem lub kluczem asymetrycznym, z odpowiadającym loginem, któremu udzielono uprawnienia UNSAFE ASSEMBLY w bazie danych master. Administratorzy programu SQL Server mogą również dodawać zestawy do listy zestawów, którym aparat bazy danych powinien ufać. For more information, see sys.sp_add_trusted_assembly.

Zarządzanie zabezpieczeniami zestawów

Możesz kontrolować, ile zestaw może uzyskać dostęp do zasobów chronionych przez zabezpieczenia dostępu kodu platformy .NET podczas uruchamiania kodu zarządzanego. W tym celu należy określić jeden z trzech zestawów uprawnień podczas tworzenia lub modyfikowania zestawu: SAFE, EXTERNAL_ACCESSlub UNSAFE.

SAFE permission

SAFE jest domyślnym zestawem uprawnień i jest najbardziej restrykcyjny. Kod uruchamiany przez zestaw z uprawnieniami SAFE nie może uzyskać dostępu do zasobów systemu zewnętrznego, takich jak pliki, sieć, zmienne środowiskowe lub rejestr. SAFE kod może uzyskiwać dostęp do danych z lokalnych baz danych programu SQL Server lub wykonywać obliczenia i logikę biznesową, które nie obejmują uzyskiwania dostępu do zasobów spoza lokalnych baz danych.

Większość zestawów wykonuje zadania obliczeniowe i zarządzania danymi bez konieczności uzyskiwania dostępu do zasobów poza programem SQL Server. Dlatego zalecamy SAFE jako zestaw uprawnień zestawu.

EXTERNAL_ACCESS permission

EXTERNAL_ACCESS umożliwia zestawom dostęp do niektórych zasobów systemu zewnętrznego, takich jak pliki, sieci, usługi sieci Web, zmienne środowiskowe i rejestr. Tylko identyfikatory logowania programu SQL Server z uprawnieniami EXTERNAL ACCESS mogą tworzyć zestawy EXTERNAL_ACCESS.

SAFE zestawy mogą EXTERNAL_ACCESS zawierać tylko kod, który jest weryfikowalny. Oznacza to, że te zestawy mogą uzyskiwać dostęp tylko do klas za pośrednictwem dobrze zdefiniowanych punktów wejścia, które są prawidłowe dla definicji typu. W związku z tym nie mogą oni arbitralnie uzyskiwać dostępu do pamięci, które nie są własnością kodu. Ponadto nie mogą wykonywać operacji, które mogą mieć negatywny wpływ na niezawodność procesu programu SQL Server.

UNSAFE permission

UNSAFE zapewnia zestawom nieograniczony dostęp do zasobów zarówno w programie SQL Server, jak i poza nimi. Kod uruchomiony z poziomu zestawu UNSAFE może wywoływać kod niezarządzany.

Ponadto określenie UNSAFE umożliwia kodowi w zestawie wykonywanie operacji uważanych za niebezpieczne dla typu przez weryfikatora CLR. Te operacje mogą potencjalnie uzyskiwać dostęp do pamięci w przestrzeni procesowej programu SQL Server w sposób niekontrolowany. UNSAFE zestawy mogą również potencjalnie odwrócić system zabezpieczeń programu SQL Server lub środowiska uruchomieniowego języka wspólnego. UNSAFE uprawnienia powinny być przyznawane tylko do wysoce zaufanych zestawów przez doświadczonych deweloperów lub administratorów. Only members of the sysadmin fixed server role can create UNSAFE assemblies.

Ograniczenia dotyczące zestawów

Program SQL Server wprowadza pewne ograniczenia dotyczące kodu zarządzanego w zestawach, aby upewnić się, że mogą działać w niezawodny i skalowalny sposób. Oznacza to, że niektóre operacje, które mogą naruszyć niezawodność serwera, nie są dozwolone w SAFE i zestawach EXTERNAL_ACCESS.

Niedozwolone atrybuty niestandardowe

Zestawy nie mogą być adnotacjami z następującymi atrybutami niestandardowymi:

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

Ponadto zestawy SAFE i EXTERNAL_ACCESS nie mogą być oznaczone adnotacjami z następującymi atrybutami niestandardowymi:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

Niedozwolone interfejsy API programu .NET Framework

Nie można wywołać żadnego interfejsu API programu .NET Framework z adnotacją z jednym z niedozwolonych HostProtectionAttributes z SAFE i zestawów EXTERNAL_ACCESS.

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

Obsługiwane zestawy programu .NET Framework

Każdy zestaw, do którego odwołuje się zestaw niestandardowy, musi zostać załadowany do programu SQL Server przy użyciu CREATE ASSEMBLY. Następujące zestawy programu .NET Framework są już ładowane do programu SQL Server i dlatego mogą być przywoływane przez zestawy niestandardowe bez konieczności używania 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
  • zestawów (aparat bazy danych)
  • zabezpieczeń integracji środowiska CLR