Condividi tramite

Progettazione di assembly

  • Articolo

Si applica a: SQL Server

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

  • Assemblaggio di assembly
  • Gestione della sicurezza degli assembly
  • Limitazioni relative agli assembly

Assembly del pacchetto

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. Per altre informazioni, vedere Implementazione di assembly e ALTER ASSEMBLY (Transact-SQL).

  • 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.

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.

Autorizzazione SAFE

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.

autorizzazione EXTERNAL_ACCESS

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.

Gli assembly SAFE 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.

Autorizzazione UNSAFE

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. 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 UNSAFE assembly.

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 di Microsoft .NET Framework annotata con uno degli assembly non consentiti HostProtectionAttributes non può essere chiamata da SAFE e EXTERNAL_ACCESS assembly.

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.

  • CustomMarshalers.dll
  • Microsoft.VisualBasic.dll
  • Microsoft.VisualC.dll
  • mscorlib.dll
  • System.dll
  • System.Configuration.dll
  • System.Core.dll
  • System.Data.dll
  • System.Data.OracleClient.dll
  • System.Data.SqlXml.dll
  • System.Deployment.dll
  • System.Security.dll
  • System.Transactions.dll
  • System.Web.Services.dll
  • system.Xml.dll
  • System.Xml.Linq.dll

Contenuto correlato