Share via


Ruoli applicazione

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 funzionano con entrambe le modalità di autenticazione e vengono attivati eseguendo 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à a livello di server. Per eliminare questa limitazione e consentire quindi ai ruoli applicazione di accedere ai metadati a livello di server, impostare il flag globale 4616. Per ulteriori informazioni, vedere Flag di traccia (Transact-SQL) e DBCC TRACEON (Transact-SQL).

Connessione attraverso un ruolo applicazione

Il passaggio da un contesto di protezione 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 attivato.

  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 disconnetersi e riconnettersi a SQL Server. A partire da SQL Server 2005, sp_setapprole dispone di un'opzione che crea un cookie. Il cookie contiene informazioni di contesto precedenti all'attivazione del ruolo. Questo cookie può essere utilizzato da sp_unsetapprole per riportare la sessione al contesto originale. Per informazioni su questa nuova opzione e un esempio, vedere sp_setapprole (Transact-SQL).

Nota sulla protezioneNota sulla protezione

L'opzione ODBC encrypt non è supportata da SqlClient. Per trasmettere informazioni riservate su una rete, utilizzare 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 e versioni successive, il parametro password è archiviato come un hash unidirezionale.