Condividi tramite

Progettazione di assembly

  • Articolo

In questo argomento vengono illustrati alcuni fattori da prendere in considerazione durante la progettazione degli assembly:

  • Assemblaggio di assembly

  • Gestione della sicurezza degli assembly

  • Limitazioni relative agli assembly

Assemblaggio di assembly

Un assembly può contenere funzionalità per più SQL Server routine o tipo 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. Il motivo di questa scelta è che è più probabile che i metodi di queste classi si chiamino l'un l'altro rispetto ai metodi di attività meno correlate.

Quando si assembla codice in assembly, è opportuno prendere in considerazione i fattori seguenti:

  • 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. Modificare il codice di un assembly risulta spesso più complesso quando nel database sono presenti dati persistenti che dipendono dall'assembly. È pertanto preferibile separare il codice sul quale si basano le dipendenze dei dati persistenti, ad esempio i tipi definiti dall'utente e gli indici che utilizzano funzioni definite dall'utente, dal codice che non contiene questo tipo di dipendenze. Per altre informazioni, vedere Implementazione di assembly e ALTER ASSEMBLY (Transact-SQL).

  • Se una parte di codice gestito richiede un'autorizzazione di livello superiore, è opportuno inserirla in un assembly separato.

Gestione della 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 questo scopo, quando si crea o modifica l'assembly è necessario specificare uno dei tre set di autorizzazioni disponibili: SAFE, EXTERNAL_ACCESS oppure UNSAFE.

SAFE

SAFE è il set di autorizzazioni predefinito ed è il più restrittivo. Il codice eseguito da un assembly con autorizzazioni SAFE non può accedere a risorse di sistema esterne, ad esempio file, la rete, variabili di ambiente o il Registro di sistema. Il codice SAFE può accedere ai dati dai database SQL Server locali o eseguire calcoli e logica di business che non comportano 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 esterne SQL Server. È pertanto consigliabile applicare agli assembly il set di autorizzazioni SAFE.

EXTERNAL_ACCESS

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

Gli assembly SAFE ed EXTERNAL_ACCESS possono contenere solo codice effettivamente 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. Non possono pertanto accedere arbitrariamente a 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

UNSAFE concede agli assembly l'accesso senza restrizioni alle risorse, sia all'interno che all'esterno SQL Server. Il codice eseguito da un assembly UNSAFE può chiamare codice non gestito.

Specificando UNSAFE si consente inoltre al codice dell'assembly di eseguire operazioni considerate non indipendenti dai tipi da CLR Verifier. Queste operazioni possono potenzialmente accedere ai buffer di memoria nello spazio di elaborazione SQL Server in modo non controllato. Gli assembly UNSAFE possono anche compromettere il sistema di sicurezza di SQL Server o del CLR. Si consiglia di concedere le autorizzazioni UNSAFE solo ad assembly assolutamente attendibili, creati da sviluppatori o amministratori esperti. Solo i membri del ruolo predefinito del server sysadmin possono creare assembly UNSAFE.

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. Alcune operazioni potenzialmente in grado di compromettere l'affidabilità del server non sono consentite negli assembly SAFE ed EXTERNAL_ACCESS.

Attributi personalizzati non consentiti

Non è possibile annotare gli assembly 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

Non è inoltre possibile annotare gli assembly SAFE ed EXTERNAL_ACCESS con gli attributi personalizzati seguenti:

System.Security.SuppressUnmanagedCodeSecurityAttribute  
System.Security.UnverifiableCodeAttribute

API .NET Framework non consentite

Qualsiasi API di Microsoft .NET Framework annotata con uno degli assembly HostProtectionAttribute non consentiti non può essere chiamata da assembly SAFE e EXTERNAL_ACCESS.

eSelfAffectingProcessMgmt  
eSelfAffectingThreading  
eSynchronization  
eSharedState   
eExternalProcessMgmt  
eExternalThreading  
eSecurityInfrastructure  
eMayLeakOnAbort  
eUI

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.

custommarshallers.dll  
Microsoft.visualbasic.dll  
Microsoft.visualc.dll  
mscorlib.dll  
system.data.dll  
System.Data.SqlXml.dll  
system.dll  
system.security.dll  
system.web.services.dll  
system.xml.dll  
System.Transactions  
System.Data.OracleClient  
System.Configuration

Vedere anche

Assembly (Motore di database)
Sicurezza per l'integrazione con CLR