Ruoli dell'applicazione

Si applica a:SQL ServerDatabase SQL di AzureIstanza gestita di SQL di Azure

Un ruolo applicativo è un principal del database che consente a un'applicazione di eseguire operazioni con autorizzazioni proprie, simili a quelle di un utente. 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 disabilitare questa restrizione e consentire così ai ruoli dell'applicazione di accedere ai metadati a livello di server, imposta il flag globale trace flag 4616 usando -T4616 oppure DBCC TRACEON (4616, -1). Se preferisci non abilitare questo flag di traccia, puoi usare una stored procedure firmata con certificato per consentire ai ruoli dell'applicazione di visualizzare lo stato del server. Per il codice di esempio, vedi questo script di esempio in GitHub.

Connettersi con un ruolo dell'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à Tipo
Creare un ruolo dell'applicazione. Creare un ruolo dell'applicazione e CREATE APPLICATION ROLE (Transact-SQL)
Modificare un ruolo dell'applicazione. ALTER APPLICATION ROLE (Transact-SQL)
Elimina un ruolo dell'applicazione. DROP APPLICATION ROLE (Transact-SQL)
Utilizzo di un ruolo dell'applicazione. sp_setapprole (Transact-SQL)

Vedi anche

Sicurezza di SQL Server