Articolo
09/28/2010

Estensione della rappresentazione di database tramite EXECUTE AS

In SQL Server è possibile rappresentare un'entità diversa sia in modo esplicito, tramite l'istruzione autonoma EXECUTE AS, sia in modo implicito, tramite l'utilizzo della clausola EXECUTE AS nei moduli. L'istruzione autonoma EXECUTE AS consente di rappresentare le entità a livello del server (account di accesso), tramite l'istruzione EXECUTE AS LOGIN e inoltre di rappresentare le entità a livello del database (utenti), tramite l'istruzione EXECUTE AS USER.

Le rappresentazioni implicite eseguite tramite la clausola EXECUTE AS nei moduli consentono di rappresentare l'utente o l'account di accesso specificato a livello del database o del server. La rappresentazione varia a seconda che il modulo sia un modulo a livello del database, ad esempio una stored procedure o una funzione, o un modulo a livello del server, ad esempio un trigger a livello del server.

Informazioni sull'ambito di rappresentazione

Se un'entità viene rappresentata tramite un'istruzione EXECUTE AS LOGIN o in un modulo con ambito server tramite la clausola EXECUTE AS, l'ambito della rappresentazione è a livello del server. Ciò significa che, dopo il cambio di contesto, è possibile accedere a tutte le risorse del server per le quali l'account di accesso rappresentato dispone di autorizzazioni.

Se invece l'entità viene rappresentata tramite un'istruzione EXECUTE AS USER o in un modulo con ambito database tramite la clausola EXECUTE AS, l'ambito della rappresentazione è limitato per impostazione predefinita al database. Ciò significa che se si fa riferimento a oggetti all'esterno dell'ambito del database, verrà restituito un errore. I motivi di questo funzionamento predefinito sono illustrati nello scenario seguente.

È possibile che il proprietario di un database disponga di autorizzazioni complete all'interno del database ma di nessuna autorizzazione all'esterno dell'ambito del database. In SQL Server non è pertanto consentito al proprietario del database di rappresentare o di concedere ad altri di rappresentare un altro utente per poter accedere alle risorse esterne all'ambito delle autorizzazioni correnti di cui dispone.

Ad esempio, si considerino due database in un ambiente di hosting, appartenenti a proprietari diversi. Il proprietario di Database1 è Bob , mentre quello di Database2 è Fred. Sia Bob che Fred non desiderano che l'altro possa accedere alle risorse del proprio database. Come proprietario di Database1, Bob può creare un utente per Fred nel proprio database e dato che dispone di autorizzazioni complete per Database 1, Bob può inoltre rappresentare l'utente Fred. A causa delle restrizioni di protezione imposte da SQL Server, Bob non può accedere al database di Fred nel contesto rappresentato. Senza tali restrizioni predefinite, Bob potrebbe accedere ai dati di Fred senza che questi ne sia a conoscenza. Per questo motivo, l'ambito delle rappresentazioni a livello del database è limitato al database per impostazione predefinita.

In alcuni scenari, può tuttavia essere utile estendere in modo selettivo l'ambito della rappresentazione all'esterno del database, ad esempio nel caso di un'applicazione che utilizza due database e che deve accedere a uno dei database dall'altro.

Si consideri il caso di un'applicazione per il marketing che richiama una stored procedure denominata GetSalesProjections nel database Marketing e nella stored procedure è stato definito un cambio di contesto. La stored procedure esegue una chiamata al database Sales per recuperare informazioni sulle vendite dalla tabella SalesStats. Per impostazione predefinita, questo scenario non funzionerà perché un contesto di esecuzione definito all'interno di un database non è valido all'esterno di esso. Gli sviluppatori dell'applicazione per il marketing vogliono tuttavia evitare che gli utenti dell'applicazione possano accedere direttamente al database Sales o che dispongano di autorizzazioni per gli oggetti contenuti nel database. La soluzione ideale consiste nell'utilizzare la clausola EXECUTE AS nella stored procedure per rappresentare un utente che dispone delle autorizzazioni necessarie nel database Sales. Le restrizioni predefinite correnti non consentono tuttavia di adottare questa soluzione e pertanto il problema dovrà essere risolto dagli sviluppatori.

In SQL Server, per estendere in modo selettivo l'ambito della rappresentazione del database definito all'interno di un database è possibile definire un modello di trust tra i due database. Prima di descrivere il modello di trust e l'estensione selettiva dell'ambito della rappresentazione, è tuttavia consigliabile acquisire familiarità con l'autenticazione e con il ruolo degli autenticatori in SQL Server.

Informazioni sugli autenticatori

L'autenticazione è il processo tramite il quale un'entità specifica definisce e prova la propria identità a un sistema. Un autenticatore è un'entità che autentica o garantisce l'autenticità di un'entità specifica. Ad esempio, quando si stabilisce una connessione a SQL Server, l'account di accesso definito per la connessione viene autenticato dall'istanza di SQL Server.

Si consideri il caso in cui un utente cambia in modo esplicito il contesto a livello del server utilizzando l'istruzione EXECUTE AS LOGIN. Per questa operazione sono necessarie autorizzazioni di rappresentazione a livello del server, che consentono al chiamante dell'istruzione EXECUTE AS LOGIN di rappresentare l'account di accesso specificato all'interno dell'istanza di SQL Server. L'istruzione consente in effetti al chiamante di simulare l'accesso da parte dell'account di accesso rappresentato. Il proprietario dell'ambito di autorizzazioni a livello del server è il ruolo sysadmin proprietario dell'istanza di SQL Server. In questo caso di rappresentazione a livello del server, l'autenticatore è il ruolo sysadmin o l'istanza di SQL Server.

Si consideri invece il caso in cui il contesto è definito tramite un'istruzione EXECUTE AS USER o una clausola EXECUTE AS eseguita in un modulo con ambito database. In questi casi, le autorizzazioni di rappresentazione nell'ambito del database vengono controllate. L'ambito predefinito delle autorizzazioni IMPERSONATE per gli utenti è il database stesso, il cui proprietario è dbo e l'autenticatore di queste rappresentazioni è il proprietario del database. Inoltre, è il proprietario del database a definire l'identità dell'utente rappresentato e a garantirne l'autenticità. Poiché l'intero database appartiene al proprietario del database, il contesto rappresentato è considerato autentico all'interno del database, ma non è tuttavia valido all'esterno di esso.

Utilizzo degli autenticatori

Gli autenticatori consentono di determinare se un contesto definito è valido in un ambito specifico. L'autenticatore è spesso l'amministratore di sistema o l'istanza di SQL Server oppure, nel caso dei database, dbo. L'autenticatore è in effetti il proprietario dell'ambito all'interno del quale viene stabilito il contesto per un utente o un account di accesso specifico. Le informazioni sull'autenticatore vengono acquisite dalle informazioni relative al token disponibili per l'account di accesso e l'utente e possono essere visualizzate tramite le viste sys.user_token e sys.login_token. Per ulteriori informazioni, vedere Informazioni sul contesto di esecuzione.

[!NOTA]

Se nella vista del token non vengono restituite informazioni sull'autenticatore, l'autenticatore è l'istanza di SQL Server. Questa osservazione è valida se non viene eseguito alcun cambio di contesto o se la rappresentazione è a livello del server.

Se l'autenticatore di un contesto di esecuzione è il proprietario di un ambito, tale contesto di esecuzione sarà valido nell'intero ambito. Ciò dipende dal fatto che il proprietario di un ambito, ad esempio di un database, è considerato trusted in modo implicito da tutte le entità all'interno di tale ambito. Il contesto è inoltre valido negli altri ambiti all'interno dei quali l'autenticatore è considerato trusted, ad esempio in altri database o nell'istanza stessa di SQL Server. La validità del contesto dell'utente rappresentato all'esterno dell'ambito del database dipende pertanto dal fatto che l'autenticatore del contesto sia considerato o meno trusted all'interno dell'ambito di destinazione. Per stabilire questa relazione di trust, all'autenticatore viene concessa l'autorizzazione AUTHENTICATE se l'ambito di destinazione è un altro database o l'autorizzazione AUTHENTICATE SERVER se tale ambito è un'istanza di SQL Server.

Estensione dell'ambito di rappresentazione

Per estendere l'ambito di una rappresentazione da un ambito interno a un database a un ambito di destinazione, ad esempio un altro database o l'istanza di SQL Server, devono essere rispettate le condizioni seguenti.

L'autenticatore deve essere considerato trusted nell'ambito di destinazione.
Il database di origine deve essere contrassegnato come attendibile.

Considerare l'autenticatore come trusted

Si consideri l'esempio precedente relativo ai database Sales e Marketing. Nella figura seguente viene illustrata la stored procedure GetSalesProjections del database Marketing che accede ai dati della tabella SalesStats del database Sales. La stored procedure contiene la clausola EXECUTE AS USER MarketingExec. Il proprietario del database Sales è SalesDBO e il proprietario del database Marketing è MarketingDBO.

EXECUTE AS cambia il contesto di esecuzione di un modulo

Quando un utente chiama la stored procedure GetSalesProjections, la clausola EXECUTE AS cambia in modo implicito il contesto di esecuzione della stored procedure dall'utente chiamante all'utente MarketingExec. L'autenticatore per questo contesto è MarketingDBO, ovvero il proprietario del database Marketing. Per impostazione predefinita, questa procedura può accedere a tutte le risorse del database Marketing alle quali può accedere l'utente MarketingExec. Per poter accedere a una tabella nel database Sales, è tuttavia necessario che il database Sales consideri come trusted l'autenticatore MarketingDBO.

A tale scopo, è possibile creare nel database Sales un utente MarketingDBO mappato all'account di accesso MarketingDBO e quindi concedere a tale utente l'autorizzazione AUTHENTICATE per il database Sales. All'interno del database sarà pertanto considerato valido qualsiasi contesto di esecuzione il cui autenticatore dispone di questa autorizzazione. Poiché all'autenticatore MarketingDBO è stata concessa l'autorizzazione AUTHENTICATE nel database Sales, il contesto dell'utente MarketingExec definito dalla clausola EXECUTE AS nella stored procedure GetSalesProjections del database Marketing viene considerato trusted nel database Sales.

Oltre a estendere l'ambito della rappresentazione in modo da consentire l'accesso a un oggetto di un database esterno, è inoltre possibile estenderlo all'istanza di SQL Server. Ad esempio, nel caso di una procedura che prevede la creazione di un account di accesso, ovvero un'operazione che richiede un'autorizzazione a livello dell'intero server, sarebbe necessario concedere l'autorizzazione AUTHENTICATE SERVER all'autenticatore del contesto. Dal punto di vista semantico, ciò significa che qualsiasi contesto il cui autenticatore dispone dell'autorizzazione AUTHENTICATE SERVER è considerato trusted nell'intera istanza di SQL Server**,** come se il contesto eseguisse direttamente l'accesso all'istanza di SQL Server.

Considerare il database come attendibile

In SQL Server, il modello di trust offre inoltre un livello aggiuntivo di protezione e granularità per l'estensione dell'ambito della rappresentazione a livello del database. L'autorizzazione AUTHENTICATE consente all'ambito di destinazione di considerare trusted l'autenticatore di un contesto, ma è inoltre possibile stabilire se l'istanza di SQL Server considera trusted il database di origine e il relativo contenuto.

Per comprendere questo concetto, si supponga che l'entità MarketingDBO sia il proprietario di un altro database denominato Conference. Si supponga inoltre che per l'entità MarketingDBO i contesti di esecuzione specificati nel database Marketing devono poter accedere alle risorse del database Sales, mentre invece i contesti definiti nel database Conference non devono poter accedere al database Sales.

Per rispettare questo requisito, il database contenente il modulo nel quale viene utilizzato un contesto di rappresentazione per accedere a risorse esterne al database deve essere contrassegnato come attendibile. La proprietà TRUSTWORTHY indica se l'istanza di SQL Server considera attendibile il database e il relativo contenuto e svolge due funzioni:

Riduce le minacce potenziali provenienti dai database collegati all'istanza di SQL Server e che potrebbero contenere moduli dannosi per i quali è stata definita l'esecuzione nel contesto di un utente con livelli alti di privilegi.

A tale scopo, è possibile fare in modo che i database collegati non vengano contrassegnati come attendibili per impostazione predefinita. È inoltre possibile fare in modo che per poter accedere a risorse esterne al database tramite moduli potenzialmente dannosi sia necessario contrassegnare il database come attendibile. L'impostazione della proprietà TRUSTWORTHY per un database è limitata ai membri del ruolo predefinito del server sysadmin.
Consente all'amministratore dell'istanza di SQL Server di distinguere tra i database ai quali deve essere consentito di accedere alle risorse esterne e i database ai quali invece ciò non deve essere consentito quando il proprietario dei database è lo stesso ed esiste un ambito in cui è considerato trusted come autenticatore.

Questo comportamento può essere controllato tramite la proprietà TRUSTWORTHY. Si supponga, ad esempio, il caso in cui i contesti rappresentati di un database, Database 1, devono essere considerati trusted, mentre i contesti di un altro database, Database 2, non devono esserlo. Entrambi i database hanno lo stesso proprietario che è considerato trusted come autenticatore nell'ambito di destinazione. Per fare in modo che i moduli di Database 2 non possano accedere alle risorse esterne a tale database, è possibile impostare la proprietà TRUSTWORTHY su ON per database1 e su OFF per database2.

Nella figura seguente viene illustrato l'utilizzo della proprietà del database TRUSTWORTHY per controllare l'accesso alle risorse esterne all'ambito del database di origine. MarketingDBO dispone delle autorizzazioni AUTHENTICATE nel database Sales ed è il proprietario di entrambi i database Marketing e Conference. La stored procedure GetSalesProjections del database Marketing può accedere al database Sales perché rispetta i due requisiti di protezione, ovvero l'autenticatore MarketingDBO e considerato trusted nell'ambito di destinazione e il database di origine Marketing è attendibile. I tentativi di accesso al database Sales dal database Conference vengono rifiutati perché viene rispettato un solo requisito, ovvero l'autenticatore MarketingDBO, è considerato trusted nell'ambito di destinazione.

Controllo dell'accesso al database per risorse esterne

Ogni volta che viene eseguito un tentativo di accesso a una risorsa esterna all'ambito del database tramite un contesto rappresentato, l'istanza di SQL Server verifica che il database dal quale è stata originata la richiesta sia attendibile e che l'autenticatore sia considerato trusted.

Utilizzo di certificati e di chiavi asimmetriche come autenticatori

È possibile estendere un contesto di rappresentazione definito in un database in modo da poter accedere a risorse esterne all'ambito del database utilizzando il proprietario del database come autenticatore. A tale scopo, è necessario che il proprietario del database sia considerato trusted dalla risorsa esterna e inoltre che il database stesso sia attendibile. In base a questo approccio, tuttavia, se un proprietario di database considerato trusted dispone delle autorizzazioni AUTHENTICATE o AUTHENTICATE SERVER nell'ambito di destinazione e il database chiamante è attendibile, qualsiasi contesto di rappresentazione definito in tale database è valido nell'ambito di destinazione che considera trusted il proprietario del database.

Potrebbe essere necessario un livello di granularità superiore per la relazione di trust. Si supponga che in base ai requisiti aziendali sia necessario considerare attendibili solo alcuni moduli del database di origine utilizzando la clausola EXECUTE AS per accedere alla risorsa di destinazione, ma non sia consigliabile considerare attendibile l'intero database di origine. Ad esempio, si supponga che SalesDBO desideri fare in modo che solo la stored procedure GetSalesProjections possa accedere alla tabella SalesStats come l'utente MarketingExec, ma che nessun utente del database Marketing che dispone delle autorizzazioni di rappresentazione per MarketingExec possa accedere alle risorse del database Sales. Per ottenere questo scopo, non è sufficiente considerare trusted MarketingDBO e impostare il database Marketing come attendibile. Il modello di trust offre un livello di granularità aggiuntivo per rispettare il requisito, poiché consente di utilizzare come autenticatori i certificati o le chiavi asimmetriche. A tale scopo viene utilizzata una tecnica denominata firma. Per ulteriori informazioni sulle firme, vedere ADD SIGNATURE (Transact-SQL).

Utilizzo delle firme

La firma per un modulo verifica che il codice all'interno del modulo possa essere modificato solo da un utente in grado di accedere alla chiave privata tramite la quale è stata creata la firma. Le garanzie offerte dal processo di firma consentono di considerare trusted la chiave asimmetrica o il certificato specificato nella firma. In particolare, si può considerare trusted il proprietario del certificato o della chiave asimmetrica, anziché solo il proprietario del database.

Per considerare trusted il modulo con la firma, è possibile concedere l'autorizzazione AUTHENTICATE o AUTHENTICATE SERVER all'utente dell'ambito di destinazione associato al certificato o alla chiave asimmetrica.

In questo modo, un contesto di esecuzione definito in un modulo firmato con un certificato trusted è valido nell'ambito di destinazione in cui il certificato è considerato trusted.

Ad esempio, si supponga che la procedura GetSalesProjections sia stata firmata con il certificato C1. Il certificato C1 deve essere presente nel database Sales e un utente, ad esempio CertUser1, deve essere associato al certificato C1. A CertUser1 vengono quindi concesse le autorizzazioni AUTHENTICATE nel database Sales.

Quando viene chiamata la procedura, la relativa firma viene controllata per verificare che non sia stata alterata al momento della creazione. Se la verifica della firma è positiva, il contesto definito dalla clausola EXECUTE AS nel modulo avrà come autenticatore il certificato C1. Se la verifica della firma non è positiva, l'autenticatore non viene aggiunto nel token e il tentativo di accesso alla risorsa esterna avrà esito negativo.

Nella figura seguente è illustrato l'utilizzo di un modulo firmato per controllare l'accesso a risorse esterne all'ambito del database di origine. La procedura GetSalesProjections del database Marketing viene firmata utilizzando il certificato C1. Il certificato C1 è presente nel database Sales e al certificato è associato l'utente CertUser. A CertUser1 vengono concesse le autorizzazioni AUTHENTICATE nel database Sales.

Certificato utilizzato per limitare l'accesso al database

La relazione di trust con l'autenticatore viene verificata nello stesso modo utilizzato quando l'autenticatore è il proprietario del database, ovvero viene controllata l'autorizzazione AUTHENTICATE SERVER o AUTHENTICATE. Poiché tuttavia tale relazione è definita a un livello di granularità superiore e non è possibile modificare il modulo senza modificare la firma, non è necessario verificare la proprietà TRUSTWORTHY per il database.

In questo modo si riducono le minacce provenienti da database collegati che contengono codice dannoso. Chi effettua l'attacco dovrebbe firmare il modulo con la chiave privata corrispondente al certificato trusted. Non è tuttavia necessario che chi effettua l'attacco debba accedere a questa chiave. Inoltre, il modulo trusted che viene modificato oppure un nuovo modulo non dispone di una firma trusted valida.

Per ulteriori informazioni, vedere Firma del modulo (Motore di database).

Regole per l'estensione dell'ambito di rappresentazione del database

Per riepilogare, l'ambito di rappresentazione di un contesto definito in un database può essere esteso ad altri ambiti solo se sono valide le condizioni seguenti:

L'autenticatore, ovvero il proprietario del database oppure una chiave asimmetrica o un certificato utilizzato per firmare il modulo, deve essere considerato trusted nell'ambito di destinazione. A tale scopo, è possibile concedere la autorizzazioni AUTHENTICATE o AUTHENTICATE SERVER all'entità associata al proprietario del database, al certificato o alla chiave asimmetrica.
Se l'autenticatore è il proprietario del database, il database di origine deve essere contrassegnato come attendibile. A tale scopo, è possibile impostare la proprietà del database TRUSTWORTHY su ON.

Selezione del meccanismo di trust per esigenze specifiche

Sia l'approccio basato sul proprietario del database che quello basato sulla firma offrono vantaggi e svantaggi. La scelta del meccanismo ottimale dipende dall'ambiente e dai requisiti aziendali.

Approccio basato sul proprietario del database

Questo tipo di approccio per la definizione del trust offre i vantaggi e gli svantaggi seguenti:

Non richiede una conoscenza approfondita dei concetti correlati alla crittografia, ad esempio i certificati o le firme.
Non offre un livello di granularità simile a quello offerto dall'approccio basato sulla firma.
Il collegamento di un database a un'istanza di SQL Server comporta l'impostazione della proprietà del database TRUSTWORTHY su OFF. I moduli considerati come attendibili dal proprietario del database non saranno validi fino a quando l'amministratore di sistema non imposta in modo implicito la proprietà TRUSTWORTHY su ON. Ciò implica che per poter far funzionare il database collegato nel modo desiderato e per poter accedere ad altri database è potenzialmente necessario un intervento da parte dell'amministratore di sistema.

Approccio basato sulla firma