Dela via

Design assemblies

Applies to:SQL Server

I den här artikeln beskrivs följande faktorer som du bör tänka på när du utformar sammansättningar:

  • Packaging assemblies
  • Hantera monteringssäkerhet
  • Begränsningar för sammansättningar

Package assemblies

En sammansättning kan innehålla funktioner för mer än en SQL Server-rutin eller skriva in dess klasser och metoder. För det mesta är det klokt att paketera funktionerna i rutiner som utför relaterade funktioner inom samma sammansättning, särskilt om dessa rutiner delar klasser vars metoder anropar varandra. Till exempel kan klasser som utför datainmatningshanteringsuppgifter för CLR-utlösare (Common Language Runtime) och CLR-lagrade procedurer paketeras i samma sammansättning. Det beror på att metoderna för dessa klasser är mer benägna att anropa varandra än metoder för mindre relaterade uppgifter.

När du paketerar kod i sammansättning bör du tänka på:

  • CLR-användardefinierade typer och index som är beroende av CLR-användardefinierade funktioner kan orsaka att bevarade data finns i databasen som är beroende av sammansättningen. Det är ofta mer komplext att ändra koden för en sammansättning när det finns beständiga data som är beroende av sammansättningen i databasen. Därför är det bättre att separera kod som bevarade databeroenden förlitar sig på (till exempel användardefinierade typer och index med hjälp av användardefinierade funktioner) från kod som inte har dessa bevarade databeroenden. For more information, see Implement assemblies and ALTER ASSEMBLY.

  • Om en del av den hanterade koden kräver högre behörighet är det bättre att separera koden i en separat sammansättning från kod som inte kräver högre behörighet.

Kodåtkomstsäkerhet stöds inte längre

CLR använder Code Access Security (CAS) i .NET Framework, som inte längre stöds som en säkerhetsgräns. En CLR-sammansättning som skapats med PERMISSION_SET = SAFE kan komma åt externa systemresurser, anropa ohanterad kod och hämta sysadmin-privilegier. I SQL Server 2017 (14.x) och senare versioner förbättrar alternativet sp_configure, strikt säkerhet, säkerheten för CLR-sammansättningar. clr strict security är aktiverat som standard och behandlar SAFE och EXTERNAL_ACCESS sammansättningar som om de hade markerats UNSAFE. Alternativet clr strict security kan inaktiveras för bakåtkompatibilitet, men rekommenderas inte.

Vi rekommenderar att du signerar alla sammansättningar med ett certifikat eller en asymmetrisk nyckel, med en motsvarande inloggning som har beviljats UNSAFE ASSEMBLY behörighet i master-databasen. SQL Server-administratörer kan också lägga till sammansättningar i en lista över sammansättningar som databasmotorn bör lita på. For more information, see sys.sp_add_trusted_assembly.

Hantera sammansättningssäkerhet

Du kan styra hur mycket en sammansättning kan komma åt resurser som skyddas av .NET Code Access Security när den kör hanterad kod. Du gör detta genom att ange en av tre behörighetsuppsättningar när du skapar eller ändrar en sammansättning: SAFE, EXTERNAL_ACCESSeller UNSAFE.

SAFE permission

SAFE är standardbehörighetsuppsättningen och är den mest restriktiva. Kod som körs av en sammansättning med SAFE behörigheter kan inte komma åt externa systemresurser som filer, nätverk, miljövariabler eller registret. SAFE kod kan komma åt data från de lokala SQL Server-databaserna eller utföra beräkningar och affärslogik som inte omfattar åtkomst till resurser utanför de lokala databaserna.

De flesta sammansättningar utför beräknings- och datahanteringsuppgifter utan att behöva komma åt resurser utanför SQL Server. Därför rekommenderar vi SAFE som sammansättningsbehörighetsuppsättning.

EXTERNAL_ACCESS permission

EXTERNAL_ACCESS gör det möjligt för sammansättningar att komma åt vissa externa systemresurser som filer, nätverk, webbtjänster, miljövariabler och registret. Endast SQL Server-inloggningar med EXTERNAL ACCESS behörigheter kan skapa EXTERNAL_ACCESS sammansättningar.

SAFE och EXTERNAL_ACCESS sammansättningar kan endast innehålla kod som är verifierbart typsäker. Det innebär att dessa sammansättningar endast kan komma åt klasser via väldefinierade startpunkter som är giltiga för typdefinitionen. Därför kan de inte godtyckligt komma åt minnesbuffertar som inte ägs av koden. Dessutom kan de inte utföra åtgärder som kan ha en negativ effekt på SQL Server-processens robusthet.

UNSAFE permission

UNSAFE ger sammansättningar obegränsad åtkomst till resurser, både inom och utanför SQL Server. Kod som körs inifrån en UNSAFE sammansättning kan anropa ohanterad kod.

Om du anger UNSAFE kan koden i sammansättningen utföra åtgärder som anses vara typsäkra av CLR-kontrollanten. Dessa åtgärder kan potentiellt komma åt minnesbuffertar i SQL Server-processutrymmet på ett okontrollerat sätt. UNSAFE sammansättningar kan också potentiellt undergräva säkerhetssystemet för antingen SQL Server eller den vanliga språkkörningen. UNSAFE behörigheter bör endast beviljas till mycket betrodda sammansättningar av erfarna utvecklare eller administratörer. Only members of the sysadmin fixed server role can create UNSAFE assemblies.

Begränsningar för sammansättningar

SQL Server använder vissa begränsningar för hanterad kod i sammansättningar för att se till att de kan köras på ett tillförlitligt och skalbart sätt. Det innebär att vissa åtgärder som kan äventyra serverns robusthet inte tillåts i SAFE och EXTERNAL_ACCESS sammansättningar.

Otillåtna anpassade attribut

Sammansättningar kan inte kommenteras med följande anpassade attribut:

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

Dessutom kan SAFE och EXTERNAL_ACCESS sammansättningar inte kommenteras med följande anpassade attribut:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

Otillåtna .NET Framework-API:er

Alla .NET Framework-API:er som kommenteras med något av de otillåtna HostProtectionAttributes kan inte anropas från SAFE och EXTERNAL_ACCESS sammansättningar.

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

.NET Framework-sammansättningar som stöds

Alla sammansättningar som refereras till av din anpassade sammansättning måste läsas in i SQL Server med hjälp av CREATE ASSEMBLY. Följande .NET Framework-sammansättningar har redan lästs in i SQL Server och kan därför refereras av anpassade sammansättningar utan att behöva använda 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

Related content