Condividi tramite


Sicurezza da accesso di codice dell'integrazione con CLR

Si applica a: SQL Server

Common Language Runtime (CLR) supporta un modello di sicurezza definito sicurezza dall'accesso di codice per il codice gestito che prevede che le autorizzazioni vengano concesse agli assembly in base all'identità del codice. Per ulteriori informazioni, vedere la sezione relativa alla sicurezza da accesso di codice in .NET Framework SDK (Software Development Kit).

I criteri di sicurezza che determinano le autorizzazioni concesse agli assembly vengono definiti in tre punti diversi:

  • Criteri computer: si tratta dei criteri applicati per tutto il codice gestito in esecuzione nel computer in cui è installato SQL Server.

  • Criteri utente: criteri attivi per il codice gestito ospitato da un processo. Per SQL Server, i criteri utente sono specifici dell'account Di Windows in cui è in esecuzione il servizio SQL Server.

  • Criteri host: si tratta dei criteri configurati dall'host di CLR (in questo caso SQL Server) in vigore per il codice gestito in esecuzione in tale host.

Il meccanismo di sicurezza da accesso di codice supportato da CLR si basa sul presupposto che il runtime possa ospitare codice completamente o parzialmente attendibile. Le risorse protette dalla sicurezza dall'accesso al codice CLR vengono in genere incapsulate da interfacce di programmazione dell'applicazione gestite che richiedono l'autorizzazione corrispondente prima di consentire l'accesso alla risorsa. La richiesta di autorizzazione viene soddisfatta solo se tutti i chiamanti a livello di assembly nello stack di chiamate dispongono dell'autorizzazione corrispondente per la risorsa.

Il set di autorizzazioni di sicurezza di accesso al codice concesse al codice gestito durante l'esecuzione all'interno di SQL Server è l'intersezione del set di autorizzazioni concesse dai tre livelli di criteri precedenti. Anche se SQL Server concede un set di autorizzazioni a un assembly caricato in SQL Server, il set finale di autorizzazioni concesse al codice utente può essere limitato ulteriormente dai criteri a livello di utente e computer.

Set di autorizzazioni a livello di criteri host di SQL Server

Il set di autorizzazioni di sicurezza per l'accesso al codice concesso agli assembly dal livello di criteri host di SQL Server è determinato dal set di autorizzazioni specificato durante la creazione dell'assembly. Sono disponibili tre set di autorizzazioni: SAFE, EXTERNAL_ACCESS e UNSAFE (specificati usando l'opzione PERMISSION_SET di CREATE ASSEMBLY (Transact-SQL)).

SQL Server fornisce un livello di criteri di sicurezza a livello di host a CLR durante l'hosting; questo criterio è un livello di criteri aggiuntivo al di sotto dei due livelli di criteri sempre attivi. Questo criterio viene impostato per ogni dominio applicazione creato da SQL Server. Questo criterio non è destinato al dominio applicazione predefinito che sarebbe attivo quando SQL Server crea un'istanza di CLR.

I criteri a livello di host di SQL Server sono una combinazione di criteri fissi di SQL Server per gli assembly di sistema e i criteri specificati dall'utente per gli assembly utente.

I criteri fissi per gli assembly CLR e gli assembly di sistema di SQL Server concedono loro l'attendibilità totale.

La parte specificata dall'utente dei criteri host di SQL Server si basa sul proprietario dell'assembly che specifica uno dei tre bucket di autorizzazione per ogni assembly. Per ulteriori informazioni sulle autorizzazioni di sicurezza elencate in basso, vedere .NET Framework SDK.

SAFE

È consentito solo il calcolo interno e l'accesso locale ai dati. SAFE è il set di autorizzazioni più restrittivo. Il codice eseguito da un assembly con autorizzazioni SAFE non può accedere a risorse di sistema esterne, ad esempio file, rete, variabili di ambiente o registro.

Gli assembly SAFE hanno le autorizzazioni e i valori seguenti:

Autorizzazione Valori/Descrizione
SecurityPermission Esecuzione: autorizzazione per eseguire codice gestito.
SqlClientPermission Connessione di contesto = true, connessione di contesto = sì: è possibile usare solo la connessione di contesto e il stringa di connessione può specificare solo il valore "context connection=true" o "context connection=yes".

AllowBlankPassword = false: le password vuote non sono consentite.

EXTERNAL_ACCESS

EXTERNAL_ACCESS assembly hanno le stesse autorizzazioni degli assembly SAFE , con la possibilità aggiuntiva di accedere a risorse di sistema esterne, ad esempio file, reti, variabili di ambiente e registro.

EXTERNAL_ACCESS assembly hanno anche le autorizzazioni e i valori seguenti:

Autorizzazione Valori/Descrizione
DistributedTransactionPermission Senza restrizioni: le transazioni distribuite sono consentite.
DNSPermission Senza restrizioni: autorizzazione per richiedere informazioni dai server dei nomi di dominio.
EnvironmentPermission Senza restrizioni: è consentito l'accesso completo alle variabili di ambiente di sistema e utente.
EventLogPermission Amministrazione: sono consentite le azioni seguenti: creazione di un'origine evento, lettura di log esistenti, eliminazione di origini eventi o log, risposta alle voci, cancellazione di un registro eventi, ascolto degli eventi e accesso a una raccolta di tutti i log eventi.
FileIOPermission Senza restrizioni: è consentito l'accesso completo a file e cartelle.
KeyContainerPermission Senza restrizioni: è consentito l'accesso completo ai contenitori delle chiavi.
NetworkInformationPermission Accesso: il ping è consentito.
RegistryPermission Consente di HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIG e HKEY_USERS di lettura.
SecurityPermission Asserzione: possibilità di asserire che tutti i chiamanti di questo codice dispongono dell'autorizzazione necessaria per l'operazione.

ControlPrincipal: possibilità di modificare l'oggetto principale.

Esecuzione: autorizzazione per eseguire codice gestito.

SerializationFormatter: possibilità di fornire servizi di serializzazione.
SmtpPermission Accesso: sono consentite le connessioni in uscita alla porta host SMTP 25.
SocketPermission Connetti: sono consentite le connessioni in uscita (tutte le porte, tutti i protocolli) in un indirizzo di trasporto.
SqlClientPermission Senza restrizioni: è consentito l'accesso completo all'origine dati.
StorePermission Senza restrizioni: è consentito l'accesso completo agli archivi certificati X.509.
WebPermission Connetti: sono consentite le connessioni in uscita alle risorse Web.

UNSAFE

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

Agli assembly UNSAFE viene assegnato FullTrust.

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 SQL Server.

EXTERNAL_ACCESS è consigliabile per gli assembly che accedono alle risorse esterne a SQL Server. EXTERNAL_ACCESS assembly per impostazione predefinita viene eseguito come account del servizio SQL Server. È possibile EXTERNAL_ACCESS codice rappresentare in modo esplicito il contesto di sicurezza dell'autenticazione di Windows del chiamante. Poiché l'impostazione predefinita consiste nell'eseguire come account del servizio SQL Server, l'autorizzazione per eseguire EXTERNAL_ACCESS deve essere assegnata solo agli account di accesso attendibili per l'esecuzione come account del servizio.

Dal punto di vista della sicurezza, gli assembly EXTERNAL_ACCESS e UNSAFE sono identici. Tuttavia, EXTERNAL_ACCESS assembly offrono varie protezioni di affidabilità e affidabilità che non si trovano in assembly UNSAFE .

Se si specifica UNSAFE, il codice nell'assembly può eseguire operazioni non valide sullo spazio di elaborazione di SQL Server e pertanto può compromettere l'affidabilità e la scalabilità di SQL Server. Per altre informazioni sulla creazione di assembly CLR in SQL Server, vedere Gestione degli assembly di integrazione CLR.

Importante

SQL Server contiene assembly CLR usati dal motore di database per fornire determinate funzionalità. L'assembly Microsoft.SQLServer.Types incluso nell'installazione di SQL Server viene visualizzato nei metadati come assembly UNSAFE . Questo si verifica per motivi strutturali. Questi assembly sono considerati attendibili e sicuri per impostazione predefinita.

Accesso a risorse esterne

Se un tipo definito dall'utente (UDT), una stored procedure o un altro tipo di assembly costrutto viene registrato con il set di autorizzazioni SAFE , il codice gestito in esecuzione nel costrutto non è in grado di accedere alle risorse esterne. Tuttavia, se vengono specificati i set di autorizzazioni EXTERNAL_ACCESS o UNSAFE e il codice gestito tenta di accedere a risorse esterne, SQL Server applica le regole seguenti:

If Risultato
Il contesto di esecuzione corrisponde a un account di accesso di SQL Server. I tentativi di accesso a risorse esterne vengono negati e viene generata un'eccezione di sicurezza.
Il contesto di esecuzione corrisponde a un account di accesso di Windows e rappresenta il chiamante originale. L'accesso alla risorsa esterna viene eseguito nel contesto di sicurezza dell'account del servizio SQL Server.
Il chiamante non è il chiamante originale. L'accesso viene negato e viene generata un'eccezione di sicurezza.
Il contesto di esecuzione corrisponde a un account di accesso di Windows e rappresenta il chiamante originale, mentre il chiamante è stato rappresentato. L'accesso verrà effettuato nel contesto di sicurezza del chiamante e non in quello dell'account del servizio.

Riepilogo dei set di autorizzazioni

Il grafico seguente riepiloga le restrizioni e le autorizzazioni concesse ai set di autorizzazioni SAFE, EXTERNAL_ACCESS e UNSAFE.

Funzionalità SAFE EXTERNAL_ACCESS UNSAFE
Autorizzazioni di sicurezza per l'accesso al codice Sola esecuzione Esecuzione più accesso a risorse esterne Senza restrizioni (incluso P/Invoke)
Restrizioni del modello di programmazione Nessuna restrizione
Requisito di verificabilità No
Accesso ai dati locali
Possibilità di chiamare il codice nativo No No

Vedi anche

Sicurezza per l'integrazione con CLR
Attributi di protezione host e programmazione dell'integrazione con CLR
Restrizioni relative al modello di programmazione dell'integrazione con CLR
Ambiente CLR