Design assemblies

Applies to:SQL Server

Questo articolo descrive i fattori seguenti da considerare quando si progettano assembly:

• Packaging assemblies
• Gestione della sicurezza degli assembly
• Limitazioni relative agli assembly

Package assemblies

Un assembly può contenere funzionalità per più routine o tipo di SQL Server nelle relative classi e metodi. Nella maggior parte dei casi è opportuno assemblare le funzionalità delle routine che eseguono funzioni correlate all'interno dello stesso assembly, in particolare se le routine condividono classi i cui metodi si chiamano a vicenda. Ad esempio, le classi che eseguono attività di gestione dell'immissione di dati per trigger CLR (Common Language Runtime) e stored procedure CLR possono essere assemblate nello stesso assembly. Ciò è dovuto al fatto che i metodi per queste classi sono più probabili chiamarsi tra loro rispetto ai metodi di attività meno correlate.

Quando si crea il pacchetto di codice nell'assembly, prendere in considerazione:

• I tipi CLR definiti dall'utente e gli indici che dipendono da funzioni CLR definite dall'utente possono provocare la presenza di dati persistenti nel database che dipende dall'assembly. La modifica del codice di un assembly è spesso più complessa quando sono presenti dati persistenti che dipendono dall'assembly nel database. È quindi preferibile separare il codice in base al quale le dipendenze dei dati persistenti si basano (ad esempio tipi e indici definiti dall'utente usando funzioni definite dall'utente) dal codice che non ha queste dipendenze dei dati persistenti. For more information, see Implement assemblies and ALTER ASSEMBLY.

• Se una parte di codice gestito richiede un'autorizzazione superiore, è preferibile separare il codice in un assembly separato dal codice che non richiede autorizzazioni più elevate.

La sicurezza dall’accesso di codice non è più supportata

CLR usa la Sicurezza dall'accesso di codice (CAS, Code Access Security) in .NET Framework, non più supportata come limite di sicurezza. Un assembly CLR creato con PERMISSION_SET = SAFE potrebbe essere in grado di accedere alle risorse di sistema esterne, chiamare codice non gestito e acquisire privilegi sysadmin. In SQL Server 2017 (14.x) e versioni successive, l'opzione sp_configure clr strict security migliora la sicurezza degli assembly CLR. clr strict security è abilitata per impostazione predefinita e considera gli assembly CLR SAFE e EXTERNAL_ACCESS come se fossero contrassegnati UNSAFE. È possibile disabilitare l'opzione clr strict security per la compatibilità con le versioni precedenti, ma questa operazione è sconsigliata.

Si consiglia di firmare tutti gli assembly con un certificato o una chiave asimmetrica tramite un account di accesso corrispondente che disponga dell'autorizzazione UNSAFE ASSEMBLY nel database master. Gli amministratori di SQL Server possono anche aggiungere assembly a un elenco di assembly che il motore di database dovrebbe considerare attendibile. For more information, see sys.sp_add_trusted_assembly.

Gestire la sicurezza degli assembly

È possibile controllare l'accesso di un assembly alle risorse protette dalla sicurezza dall'accesso di codice .NET quando esegue codice gestito. A tale scopo, specificare uno dei tre set di autorizzazioni quando si crea o si modifica un assembly: SAFE, EXTERNAL_ACCESSo UNSAFE.

SAFE permission

SAFE è il set di autorizzazioni predefinito ed è il più restrittivo. Il codice eseguito da un assembly con SAFE autorizzazioni non può accedere a risorse di sistema esterne, ad esempio file, rete, variabili di ambiente o registro. SAFE il codice può accedere ai dati dai database di SQL Server locali o eseguire calcoli e logica di business che non implicano l'accesso alle risorse all'esterno dei database locali.

La maggior parte degli assembly esegue attività di calcolo e gestione dei dati senza dover accedere alle risorse all'esterno di SQL Server. Pertanto, è consigliabile SAFE usare come set di autorizzazioni per l'assembly.

EXTERNAL_ACCESS permission

EXTERNAL_ACCESS consente agli assembly di accedere a determinate risorse di sistema esterne, ad esempio file, reti, servizi Web, variabili di ambiente e registro. Solo gli account di accesso di SQL Server con EXTERNAL ACCESS autorizzazioni possono creare EXTERNAL_ACCESS assembly.

SAFE gli assembly e EXTERNAL_ACCESS possono contenere solo codice verificabile indipendente dai tipi. Ciò significa che questi assembly possono accedere alle classi solo tramite punti di accesso ben definiti, validi per la definizione del tipo. Pertanto, non possono accedere arbitrariamente ai buffer di memoria non di proprietà del codice. Inoltre, non possono eseguire operazioni che potrebbero avere un effetto negativo sull'affidabilità del processo di SQL Server.

UNSAFE permission

UNSAFE fornisce agli assembly l'accesso senza restrizioni alle risorse, sia all'interno che all'esterno di SQL Server. Il codice in esecuzione dall'interno di un UNSAFE assembly può chiamare codice non gestito.

Inoltre, la specifica UNSAFE consente al codice nell'assembly di eseguire operazioni considerate non sicure dal verificatore CLR. Queste operazioni possono potenzialmente accedere ai buffer di memoria nello spazio di elaborazione di SQL Server in modo non controllato. UNSAFE gli assembly possono anche potenzialmente sottrarre il sistema di sicurezza di SQL Server o Common Language Runtime. UNSAFE autorizzazioni devono essere concesse solo agli assembly altamente attendibili da sviluppatori esperti o amministratori. Only members of the sysadmin fixed server role can create UNSAFE assemblies.

Limitazioni relative agli assembly

SQL Server applica determinate restrizioni al codice gestito negli assembly per assicurarsi che possano essere eseguite in modo affidabile e scalabile. Ciò significa che alcune operazioni che possono compromettere l'affidabilità del server non sono consentite negli assembly SAFE e EXTERNAL_ACCESS.

Attributi personalizzati non consentiti

Gli assembly non possono essere annotati con gli attributi personalizzati seguenti:

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

Inoltre, SAFE gli EXTERNAL_ACCESS assembly non possono essere annotati con gli attributi personalizzati seguenti:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

API .NET Framework non consentite

Qualsiasi API .NET Framework annotata con una delle HostProtectionAttributes non consentite non può essere chiamata da SAFE e EXTERNAL_ACCESS assembly.

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

Assembly .NET Framework supportati

Qualsiasi assembly a cui fa riferimento l'assembly personalizzato deve essere caricato in SQL Server tramite CREATE ASSEMBLY. Gli assembly .NET Framework seguenti sono già caricati in SQL Server e pertanto è possibile fare riferimento agli assembly personalizzati senza dover usare 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

• Assembly (motore di database)
• di sicurezza dell'integrazione con CLR