Udostępnij za pomocą

Ograniczenia modelu programowania integracji środowiska CLR

Applies to:SQL ServerAzure SQL Managed Instance

Podczas tworzenia zarządzanej procedury składowanej lub innego zarządzanego obiektu bazy danych program SQL Server wykonuje pewne kontrole kodu, które należy wziąć pod uwagę. Te testy są wykonywane w zestawie kodu zarządzanego po pierwszym zarejestrowaniu w bazie danych przy użyciu instrukcji CREATE ASSEMBLY, a także w czasie wykonywania. Kod zarządzany jest również sprawdzany w czasie wykonywania, ponieważ w zestawie mogą istnieć ścieżki kodu, które nigdy nie mogą być osiągane w czasie wykonywania.

These code checks provide flexibility for registering third-party assemblies especially, so that an assembly isn't blocked where there's unsafe code designed to run in a client environment, but would never be executed in the hosted common language runtime (CLR). Wymagania, które musi spełniać kod zarządzany, zależą od tego, czy zestaw jest zarejestrowany jako SAFE, EXTERNAL_ACCESSlub UNSAFE. SAFE jest najbardziej rygorystycznym poziomem zabezpieczeń.

Oprócz ograniczeń w zestawach kodu zarządzanego istnieją również przyznane uprawnienia zabezpieczeń kodu. ClR obsługuje model zabezpieczeń nazywany zabezpieczeniami kodu (CAS) dla kodu zarządzanego. W tym modelu uprawnienia są przyznawane zestawom na podstawie tożsamości kodu. zestawy SAFE, EXTERNAL_ACCESSi UNSAFE mają różne uprawnienia cas. Aby uzyskać więcej informacji, zobacz Zabezpieczenia dostępu kodu integracji środowiska CLR.

If the publisher policy is set, CREATE ASSEMBLY fails.

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.

SPRAWDZANIE TWORZENIA ZESTAWU

Po uruchomieniu instrukcji CREATE ASSEMBLY następujące testy są wykonywane dla każdego poziomu zabezpieczeń. Jeśli sprawdzanie nie powiedzie się, CREATE ASSEMBLY zakończy się niepowodzeniem z komunikatem o błędzie.

Globalny (dowolny poziom zabezpieczeń)

Wszystkie zestawy, do których odwołuje się odwołanie, muszą spełniać co najmniej jedno z następujących kryteriów:

  • Zestaw jest już zarejestrowany w bazie danych.

  • Zestaw jest jednym z obsługiwanych zestawów. Aby uzyskać więcej informacji, zobacz Obsługiwane biblioteki programu .NET Framework.

  • Używasz CREATE ASSEMBLY FROM <location>, a wszystkie przywołyne zestawy i ich zależności są dostępne w <location>.

  • Używasz CREATE ASSEMBLY FROM <bytes ...>, a wszystkie odwołania są określane za pośrednictwem spacji oddzielonych bajtami.

EXTERNAL_ACCESS

Wszystkie zestawy EXTERNAL_ACCESS muszą spełniać następujące kryteria:

  • Pola statyczne nie są używane do przechowywania informacji. Pola statyczne tylko do odczytu są dozwolone.

  • Test PEVerify jest przekazywany. Narzędzie PEVerify (peverify.exe), które sprawdza, czy kod wspólnego języka pośredniego (CIL) i skojarzone metadane spełniają wymagania bezpieczeństwa typu, jest dostarczany z zestawem .NET Framework SDK.

  • Synchronizacja, na przykład z klasą SynchronizationAttribute, nie jest używana.

  • Metody finalizatora nie są używane.

Następujące atrybuty niestandardowe są niedozwolone w zestawach 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.Security.SuppressUnmanagedCodeSecurityAttribute
  • System.Security.UnverifiableCodeAttribute
  • System.STAThreadAttribute
  • System.ThreadStaticAttribute

SAFE

  • Wszystkie EXTERNAL_ACCESS warunki zestawu są sprawdzane.

Runtime checks

W czasie wykonywania zestaw kodu jest sprawdzany pod kątem następujących warunków. Jeśli którykolwiek z tych warunków zostanie znaleziony, zarządzany kod nie może zostać uruchomiony i zostanie zgłoszony wyjątek.

UNSAFE

Zestaw nie może być ładowany jawnie przez wywołanie metody System.Reflection.Assembly.Load() z tablicy bajtów lub niejawnie przy użyciu przestrzeni nazw Reflection.Emit.

EXTERNAL_ACCESS

Wszystkie warunki UNSAFE są sprawdzane.

Wszystkie typy i metody oznaczone następującymi wartościami atrybutu ochrony hosta (HPA) na obsługiwanej liście zestawów są niedozwolone.

  • SelfAffectingProcessMgmt
  • SelfAffectingThreading
  • Synchronization
  • SharedState
  • ExternalProcessMgmt
  • ExternalThreading
  • SecurityInfrastructure
  • MayLeakOnAbort
  • UI

Aby uzyskać więcej informacji na temat obliczeń HPA i listy niedozwolonych typów i elementów członkowskich w obsługiwanych zestawach, zobacz Atrybuty ochrony hosta i Programowanie integracji CLR.

SAFE

Wszystkie warunki EXTERNAL_ACCESS są sprawdzane.

Related content

  • Last updated on