Condividi tramite

CREATE ASSEMBLY (Transact-SQL)

  • Articolo

Si applica a: SQL Server Istanza gestita di SQL di Azure

Crea un modulo di applicazione gestita contenente metadati di classe e codice gestito come un oggetto in un'istanza di SQL Server. Facendo riferimento a questo modulo, è possibile creare nel database funzioni CLR (Common Language Runtime), stored procedure, trigger, funzioni di aggregazione definite dall'utente e tipi definiti dall'utente.

Convenzioni relative alla sintassi Transact-SQL

Sintassi

CREATE ASSEMBLY assembly_name
[ AUTHORIZATION owner_name ]
FROM { <client_assembly_specifier> | <assembly_bits> [ , ...n ] }
[ WITH PERMISSION_SET = { SAFE | EXTERNAL_ACCESS | UNSAFE } ]
[ ; ]
<client_assembly_specifier> ::=
    '[ \\computer_name\ ] share_name\ [ path\ ] manifest_file_name'
    | '[ local_path\ ] manifest_file_name'

<assembly_bits> ::=
{ varbinary_literal | varbinary_expression }

Argomenti

assembly_name

Nome dell'assembly. Il nome deve essere univoco all'interno del database e un identificatore valido.

AUTHORIZATION owner_name

Viene specificato il nome di un utente o un ruolo come proprietario dell'assembly. owner_name deve essere il nome di un ruolo di cui l'utente corrente è membro oppure l'utente corrente deve disporre IMPERSONATE dell'autorizzazione per owner_name. Se viene omesso, la proprietà viene assegnata all'utente corrente.

<client_assembly_specifier>

Viene specificato il percorso locale o di rete in cui viene posizionato l'assembly caricato e il nome del file di manifesto che corrisponde all'assembly. <client_assembly_specifier> può essere espresso come stringa fissa o espressione tramite la quale viene restituita una stringa fissa, con variabili. CREATE ASSEMBLY non supporta il caricamento di assembly multimodulo. Tramite SQL Server vengono cercati anche tutti gli assembly dipendenti di questo assembly nello stesso percorso e tali assembly vengono caricati con lo stesso proprietario dell'assembly a livello di radice. Se questi assembly dipendenti non vengono trovati e non sono già caricati nel database corrente, CREATE ASSEMBLY ha esito negativo. Se gli assembly dipendenti sono già caricati nel database corrente, il proprietario degli assembly deve corrispondere al proprietario dell'assembly appena creato.

Importante

database SQL di Azure e Istanza gestita di SQL di Azure non supportano la creazione di un assembly da un file.

<client_assembly_specifier> non può essere specificato se l'utente connesso viene rappresentato.

<assembly_bits>

Elenco di valori binari che costituiscono l'assembly e i relativi assembly dipendenti. Il primo valore dell'elenco viene considerato l'assembly a livello di radice. I valori corrispondenti agli assembly dipendenti possono essere specificati in qualsiasi ordine. Tutti i valori che non corrispondono alle dipendenze dell'assembly radice vengono ignorati.

Nota

Questa opzione non è disponibile in un database indipendente.

varbinary_literal

Valore letterale varbinary .

varbinary_expression

Espressione di tipo varbinary.

PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }

Specifica un set di autorizzazioni di accesso al codice concesse all'assembly quando si accede da SQL Server. Se non specificato, SAFE viene applicato come valore predefinito.

L'opzione PERMISSION_SET è interessata dalla configurazione del server: opzione di sicurezza clr strict. Quando l'opzione clr strict security è abilitata, tutti gli assembly vengono considerati come UNSAFE.

Ti consigliamo di usare SAFE. SAFE è il set di autorizzazioni 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.

EXTERNAL_ACCESS consente agli assembly di accedere a determinate risorse di sistema esterne, ad esempio file, reti, variabili di ambiente e registro.

UNSAFE consente agli assembly di accedere senza restrizioni alle risorse, sia all'interno che all'esterno di un'istanza di SQL Server. Il codice in esecuzione da un UNSAFE assembly può chiamare codice non gestito.

SAFE è l'impostazione di autorizzazione consigliata per gli assembly che eseguono attività di calcolo e gestione dei dati senza accedere alle risorse all'esterno di un'istanza di SQL Server.

Nota

Le EXTERNAL_ACCESS opzioni e UNSAFE non sono disponibili in un database indipendente.

È consigliabile usare EXTERNAL_ACCESS per gli assembly che accedono alle risorse all'esterno di un'istanza di SQL Server. EXTERNAL_ACCESS Gli assembly includono la protezione dell'affidabilità e della scalabilità degli assembly, ma dal punto di vista della SAFE sicurezza sono simili agli UNSAFE assembly. Il codice negli EXTERNAL_ACCESS assembly viene eseguito per impostazione predefinita nell'account del servizio SQL Server e accede a risorse esterne con tale account, a meno che il codice non rappresenta esplicitamente il chiamante. Pertanto, l'autorizzazione per creare EXTERNAL_ACCESS assembly deve essere concessa solo agli account di accesso attendibili per eseguire il codice nell'account del servizio SQL Server. Per altre informazioni sulla rappresentazione, vedere Sicurezza per l'integrazione con CLR.

UNSAFE Se si specifica, il codice nell'assembly è completamente libero di eseguire operazioni nello spazio di elaborazione di SQL Server che può compromettere l'affidabilità di SQL Server. UNSAFE gli assembly possono anche potenzialmente sottrarre il sistema di sicurezza di SQL Server o Common Language Runtime. UNSAFE Le autorizzazioni devono essere concesse solo agli assembly altamente attendibili. Solo i membri del ruolo predefinito del server sysadmin possono creare e modificare UNSAFE assembly.

Per altre informazioni sui set di autorizzazioni di assembly, vedere Progettazione di assembly.

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 UNSAFE come se fossero contrassegnati EXTERNAL_ACCESS. È 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, considerato attendibile dal motore di database. Per altre, vedere sys.sp_add_trusted_assembly.

Osservazioni:

CREATE ASSEMBLY carica un assembly compilato in precedenza come file .dll dal codice gestito da usare all'interno di un'istanza di SQL Server.

Quando abilitata, l'opzione PERMISSION_SET nelle istruzioni CREATE ASSEMBLY e ALTER ASSEMBLY viene ignorata durante l'esecuzione, ma le opzioni PERMISSION_SET vengono mantenute nei metadati. L'esclusione dell'opzione riduce al minimo le istruzioni di codice esistenti che causano interruzioni.

SQL Server non consente la registrazione di versioni diverse di un assembly con lo stesso nome, impostazioni cultura e chiave pubblica.

Quando si tenta di accedere all'assembly specificato in <client_assembly_specifier>, SQL Server rappresenta il contesto di sicurezza dell'account di accesso di Windows corrente. Se <client_assembly_specifier> specifica un percorso di rete (percorso UNC), la rappresentazione dell'account di accesso corrente non viene inoltrata al percorso di rete a causa delle limitazioni della delega. In questo caso, l'accesso viene eseguito tramite il contesto di sicurezza dell'account del servizio SQL Server. Per altre informazioni, vedere Credenziali (motore di database).

Oltre all'assembly radice specificato da assembly_name, SQL Server tenta di caricare tutti gli assembly a cui fa riferimento l'assembly radice che viene caricato. Se un assembly a cui si fa riferimento è già stato caricato nel database a causa di un'istruzione precedente CREATE ASSEMBLY , questo assembly non viene caricato ma è disponibile per l'assembly radice. Se un assembly dipendente non è stato caricato in precedenza, ma SQL Server non riesce a individuare il file manifesto nella directory di origine, CREATE ASSEMBLY restituisce un errore.

Se gli assembly dipendenti a cui fa riferimento l'assembly radice non sono già presenti nel database e vengono caricati in modo implicito insieme all'assembly radice, hanno lo stesso set di autorizzazioni dell'assembly a livello radice. Se gli assembly dipendenti devono essere creati tramite un set di autorizzazioni diverso rispetto all'assembly a livello di radice, essi devono essere caricati esplicitamente prima dell'assembly a livello di radice con il set di autorizzazioni appropriato.

Convalida di assembly

SQL Server analizza i file binari dell'assembly caricati dall'istruzione CREATE ASSEMBLY per garantire i controlli seguenti:

  • Il file binario di assembly è ben formato con metadati e segmenti di codice validi e i segmenti di codice contengono istruzioni MSIL (Microsoft Intermediate Language) valide.

  • Il set di assembly di sistema a cui fa riferimento è uno degli assembly supportati seguenti in SQL Server: Microsoft.VisualBasic.dll, System.Data.dllSystem.Xml.dllSystem.Security.dllMicrosoft.VisualC.dllSystem.dllmscorlib.dllSystem.Web.Services.dllSystem.Data.SqlXml.dllCustomMarshallers.dll, System.Core.dlle .System.Xml.Linq.dll Può fare riferimento anche ad altri assembly di sistema, ma è necessario che questi siano registrati nel database in modo esplicito.

  • Per gli assembly creati tramite SAFE o EXTERNAL ACCESS set di autorizzazioni:

    • Il codice di assembly deve essere indipendente dai tipi. L'indipendenza dai tipi viene stabilita eseguendo CLR Verifier sull'assembly.

    • L'assembly non deve contenere membri dati statici nelle relative classi, a meno che non siano contrassegnati come di sola lettura.

    • Le classi nell'assembly non possono contenere metodi finalizzatori.

    • Le classi o i metodi dell'assembly devono essere annotati solo con gli attributi del codice consentiti. Per altre informazioni, vedere Integrazione con CLR: attributi personalizzati per routine CLR.

Oltre ai controlli precedenti eseguiti durante CREATE ASSEMBLY l'esecuzione, sono disponibili controlli aggiuntivi eseguiti al momento dell'esecuzione del codice nell'assembly:

  • La chiamata di determinate API .NET Framework che richiedono un'autorizzazione di accesso al codice specifica potrebbe non riuscire se il set di autorizzazioni dell'assembly non include tale autorizzazione.

  • Per SAFE gli assembly e EXTERNAL_ACCESS , qualsiasi tentativo di chiamare le API .NET Framework annotate con determinati hostProtectionAttribute non riesce.

Per altre informazioni, vedere Progettazione di assembly.

Autorizzazioni

È richiesta l'autorizzazione CREATE ASSEMBLY.

Se PERMISSION_SET = EXTERNAL_ACCESS è specificato, è necessaria EXTERNAL ACCESS ASSEMBLY l'autorizzazione per il server. Se PERMISSION_SET = UNSAFE è specificato, è necessaria UNSAFE ASSEMBLY l'autorizzazione per il server.

L'utente deve essere il proprietario degli assembly cui viene fatto riferimento dall'assembly che sta per essere caricato se gli assembly esistono già nel database. Per caricare un assembly usando un percorso di file, l'utente corrente deve avere un account di accesso autenticato in Windows o essere un membro del ruolo predefinito del server sysadmin. L'account di accesso di Windows dell'utente che esegue CREATE ASSEMBLY deve disporre dell'autorizzazione di lettura per la condivisione e i file caricati nell'istruzione .

Autorizzazioni con CLR strict security

Sono necessarie le autorizzazioni seguenti per creare un assembly CLR con CLR strict security abilitata:

  • L'utente deve disporre dell'autorizzazione CREATE ASSEMBLY
  • Inoltre, una delle condizioni seguenti deve essere rispettata:
    • L'assembly è firmato con un certificato o una chiave asimmetrica con un account di accesso corrispondente con l'autorizzazione UNSAFE ASSEMBLY nel server. È consigliabile firmare l'assembly.
    • La proprietà TRUSTWORTHY del database è impostata su ON e il database è di proprietà di un accesso che dispone dell'autorizzazione UNSAFE ASSEMBLY nel server. Questa opzione non è consigliata.

Per altre informazioni sui set di autorizzazioni di assembly, vedere Progettazione di assembly.

Esempi

R. Creare un assembly da una DLL

Nell'esempio seguente si presuppone che gli esempi di SQL Server motore di database siano installati nel percorso predefinito del computer locale e che l'applicazione HelloWorld.csproj di esempio sia compilata. Per altre informazioni, vedere Esempio Hello World.

CREATE ASSEMBLY HelloWorld
FROM '<system_drive>:\Program Files\Microsoft SQL Server\100\Samples\HelloWorld\CS\HelloWorld\bin\debug\HelloWorld.dll'
WITH PERMISSION_SET = SAFE;

Importante

database SQL di Azure non supporta la creazione di un assembly da un file.

B. Creare un assembly dai bit di assembly

Sostituire i bit di esempio (che non sono completi o validi) con i bit dell'assembly.

CREATE ASSEMBLY HelloWorld
    FROM 0x4D5A900000000000
WITH PERMISSION_SET = SAFE;

Contenuto correlato