Ruoli applicazione

  • Articolo

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

Un ruolo applicazione è un'entità di database che consente a un'applicazione di funzionare con proprie autorizzazioni simili a quelle per utenti. I ruoli applicazione possono essere utilizzati per consentire l'accesso a dati specifici solo agli utenti che si collegano attraverso un'applicazione particolare. A differenza dei ruoli di database, i ruoli applicazione non contengono membri e sono inattivi per impostazione predefinita. I ruoli applicazione vengono abilitati usando sp_setapprole, che richiede una password. Poiché si tratta di entità a livello di database, i ruoli applicazione possono accedere ad altri database solo tramite le autorizzazioni concesse in questi database all'account utente guest. Ogni database in cui l'account utente guest è stato disattivato non sarà quindi accessibile ai ruoli applicazione di altri database.

In SQL Server, i ruoli applicazione non possono accedere ai metadati a livello di server perché non sono associati a un'entità di livello server. Per disattivare questa restrizione e consentire quindi ai ruoli applicazione di accedere ai metadati a livello di server, imposta il flag di traccia 4616 globale usando -T4616 or DBCC TRACEON (4616, -1). Se preferisceinon abilitare questo flag di traccia, puoie usare una stored procedure firmata dal certificato per consentire ai ruoli applicazione di visualizzare lo stato del server. Per il codice di esempio, vedi questo script di esempio in GitHub.

Connessione attraverso un ruolo applicazione

Il passaggio da un contesto di sicurezza all'altro da parte di un ruolo applicazione si svolge nel modo seguente:

  1. Un utente esegue un'applicazione client.

  2. L'applicazione client si collega a un'istanza di SQL Server come utente.

  3. L'applicazione esegue quindi la stored procedure sp_setapprole con una password nota solo all'applicazione.

  4. Se il nome del ruolo applicazione e la password sono validi, il ruolo applicazione viene abilitato.

  5. A questo punto, la connessione perde le autorizzazioni dell'utente e assume le autorizzazioni del ruolo applicazione.

Le autorizzazioni acquisite attraverso il ruolo applicazione rimangono valide per tutta la durata della connessione.

Nelle versioni precedenti di SQL Server, l'unico modo per un utente di ritornare al contesto di protezione originale dopo l'avvio di un ruolo applicazione consiste nel disconnettersi e riconnettersi a SQL Server. A partire da SQL Server 2005 (9.x), sp_setapprole ha un'opzione che crea un cookie. Il cookie contiene informazioni di contesto precedenti all'abilitazione del ruolo applicazione. La stored procedure sp_unsetapprole usa quindi il cookie per ripristinare il contesto originale della sessione. Per informazioni su questa nuova opzione e per vedere un esempio, consulta sp_setapprole (Transact-SQL) e sp_unsetapprole (Transaction-SQL).

Importante

L'opzione ODBC encrypt non è supportata da SqlClient. Per trasmettere informazioni riservate su una rete, usare TLS (Transport Layer Security), noto in precedenza come SSL (Secure Sockets Layer) o IPSec per crittografare il canale. Se è necessario mantenere le credenziali nell'applicazione client, crittografarle utilizzando le funzioni Crypto API. In SQL Server 2005 (9.x) e versioni successive, il parametro password è archiviato come hash unidirezionale.

Attività Type
Creare un ruolo applicazione. Creare un ruolo applicazione e CREATE APPLICATION ROLE (Transact-SQL)
Modificare un ruolo applicazione. ALTER APPLICATION ROLE (Transact-SQL)
Eliminare un ruolo applicazione. DROP APPLICATION ROLE (Transact-SQL)
Utilizzo di un ruolo applicazione. sp_setapprole (Transact-SQL)

Vedi anche

Sicurezza di SQL Server