Condividi tramite

  • Articolo

Protezione del dialogo di Service Broker

La protezione del dialogo offre funzionalità di crittografia, autenticazione remota e autorizzazione remota per una conversazione specifica. Quando in una conversazione viene utilizzata la protezione del dialogo, Service Broker crittografa tutti i messaggi inviati all'esterno di un'istanza di SQL Server. Per impostazione predefinita, tutte le conversazioni di Service Broker utilizzano la protezione del dialogo.

La protezione del dialogo di Service Broker consente alle applicazioni l'utilizzo dell'autenticazione, dell'autorizzazione o della crittografia per ogni singola conversazione o dialogo. Per impostazione predefinita, tutte le conversazioni di dialogo utilizzano la protezione del dialogo. All'avvio di un dialogo per disattivare esplicitamente la protezione del dialogo è possibile includere la clausola ENCRYPTION = OFF nell'istruzione BEGIN DIALOG CONVERSATION. Se tuttavia esiste un'associazione al servizio remoto per il servizio a cui è destinata la conversazione, il dialogo utilizza la protezione anche se è specificata la clausola ENCRYPTION = OFF.

Per un dialogo che utilizza la protezione, Service Broker crittografa tutti i messaggi inviati all'esterno di un'istanza di SQL Server. I messaggi che rimangono all'interno di un'istanza di SQL Server non vengono mai crittografati. Nella protezione del dialogo, solo il database che ospita il servizio di origine e il database che ospita il servizio di destinazione devono necessariamente disporre di accesso ai certificati utilizzati per la protezione. In altre parole, non è necessario che un'istanza che esegue l'inoltro dei messaggi sia in grado di decrittografare i messaggi inoltrati dall'istanza stessa.

In Service Broker sono disponibili due tipi di protezione del dialogo, la protezione avanzata e la protezione anonima. Per le conversazioni che utilizzano la protezione del dialogo, Service Broker offre funzionalità di autorizzazione remota per eseguire il mapping tra il lato remoto della conversazione e un utente locale.

Quando la conversazione utilizza la protezione avanzata o la protezione anonima i messaggi vengono crittografati nella rete. I due approcci, tuttavia, presentano lievi differenze in termini di diritti effettivi sul database di destinazione e di strategia impiegata per la crittografia dei messaggi.

Indipendentemente dal tipo di protezione, avanzata o anonima, in uso per la conversazione, il corpo del messaggio viene crittografato con una chiave simmetrica della sessione generata appositamente per la conversazione. Solo le chiavi vengono crittografate con la crittografia a chiave privata utilizzando il certificato fornito per la protezione del dialogo. Service Broker esegue inoltre un controllo dell'integrità dei messaggi per agevolare l'individuazione di danneggiamenti o manomissioni.

SQL Server crea una chiave della sessione per ogni conversazione che utilizza la protezione del dialogo. Per proteggere la chiave della sessione quando è archiviata nel database, Service Broker la crittografa con la chiave master del database. Se la chiave master del database non è disponibile, i messaggi della conversazione rimarranno in transmission_status con un errore, finché non verrà creata una chiave master per il database o finché non si verificherà il timeout della conversazione. Entrambi i database che partecipano alla conversazione devono pertanto contenere chiavi master, anche se sono ospitati nella stessa istanza. Se il database di origine non contiene una chiave master, il dialogo non è possibile. Se il database di destinazione non contiene una chiave master, i messaggi rimangono nella coda di trasmissione del database di origine. Nell'ultimo errore di trasmissione relativo a questi messaggi è indicato il motivo del mancato recapito. Utilizzare il parametro ENCRYPTION = OFF per creare un dialogo non crittografato oppure utilizzare il comando seguente per creare una chiave master per il database:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'

Per comodità, Service Broker consente la prosecuzione delle conversazioni protette che rimangono all'interno di un unico database, anche se il database non contiene una chiave master. È possibile spostare due database diversi in istanze diverse di SQL Server per la durata di una conversazione ma una conversazione all'interno di un unico database rimane sempre all'interno di tale database. La conversazione può pertanto proseguire.

Protezione avanzata

La protezione avanzata consente di impedire l'invio di messaggi da parte di un servizio di origine e la ricezione di messaggi da parte di un servizio di destinazione da un database non attendibile. Quando la conversazione utilizza la protezione avanzata, Service Broker crittografa i messaggi trasmessi in rete.

La protezione avanzata garantisce l'identificazione per il servizio di origine e il servizio di destinazione e richiede che il servizio di origine consideri affidabile il servizio di destinazione e viceversa. Un servizio per l'ordine di parti presso un fornitore, ad esempio, può richiedere che l'applicazione per gli ordini consideri affidabile il servizio del fornitore e viceversa.

L'affidabilità è determinata dagli amministratori dei database mediante lo scambio di certificati che contengono chiavi pubbliche. Per la protezione avanzata del dialogo, ogni lato della conversazione contiene una chiave privata per un utente locale e una chiave pubblica per un utente remoto. Il database che ospita il servizio di origine contiene un'associazione al servizio remoto. Questa associazione specifica l'utente locale a cui appartiene il certificato corrispondente alla chiave privata nel database remoto. Pertanto, le operazioni per conto del servizio di origine vengono eseguite come se il servizio di origine fosse l'utente designato nel database di destinazione.

Il database di destinazione contiene un utente. Questo utente è il proprietario di un certificato che corrisponde alla chiave privata di proprietà dell'utente a cui appartiene il servizio di origine. Pertanto, le operazioni per conto del servizio di destinazione vengono eseguite nel database di origine in quanto quest'ultimo è proprietario del servizio di origine.

Per i dialoghi che utilizzano la protezione avanzata, ogni lato della conversazione genera una chiave della sessione. Il primo messaggio in ogni direzione contiene la chiave della sessione, crittografata con una chiave per lo scambio delle chiavi, come descritto in Certificati e Service Broker.

Protezione anonima

La protezione anonima consente di impedire l'invio di messaggi a un database non attendibile da parte del servizio di origine. Quando la conversazione utilizza la protezione anonima, Service Broker crittografa i messaggi trasmessi in rete.

La protezione anonima identifica il servizio di destinazione per il servizio di origine, ma non viceversa.

Un'applicazione che invia ordini di lavoro, ad esempio, può avere la necessità di garantire la correttezza del destinatario dell'ordine di lavoro, mentre il database di destinazione può non avere l'esigenza di fornire privilegi speciali per un servizio che invia ordini di lavoro. In questo caso, il database contenente il servizio di origine deve includere un'associazione al servizio remoto per il servizio di destinazione.

Il servizio di destinazione non è in grado di verificare l'identità del servizio di origine. Le operazioni per conto di quest'ultimo vengono quindi eseguite in quanto membro del ruolo predefinito del database public nel database di destinazione. Il database di destinazione non riceve informazioni sull'utente che ha avviato la conversazione e non deve necessariamente contenere un certificato per l'utente che avvia la conversazione.

Per i dialoghi che utilizzano la protezione anonima, entrambi i lati della conversazione utilizzano la chiave della sessione generata dal database di origine. Il database di destinazione non restituisce una chiave della sessione al database di origine.

L'autorizzazione remota di Service Broker controlla l'accesso remoto a un singolo servizio. L'autorizzazione remota determina il contesto di protezione nel quale i messaggi in arrivo in un'istanza di SQL Server vengono inviati a un servizio.

Service Broker utilizza sempre l'autorizzazione remota per una conversazione protetta che non si svolge interamente all'interno di un'istanza di SQL Server. Il contesto di protezione utilizzato da Service Broker per l'autorizzazione remota è determinato dalla protezione del dialogo configurata per la conversazione.

Quando la conversazione rimane all'interno di un'istanza di SQL Server, Service Broker non utilizza l'autorizzazione remota, anche se è configurata. Per una conversazione all'interno di un'istanza, le entità di protezione di SQL Server sono già disponibili per SQL Server. Non è quindi necessario utilizzare l'autorizzazione remota per determinare il contesto di protezione corretto per le operazioni di Service Broker. Come descritto più indietro in questo argomento tuttavia, Service Broker crea una chiave della sessione per consentire la prosecuzione della conversazione nel caso in cui uno dei database venga spostato in un'altra istanza nel corso della conversazione.

Per una conversazione che utilizza la protezione anonima, la connessione viene eseguita dal membro del ruolo predefinito del database public nel database di destinazione. In questo caso, il ruolo predefinito del database public deve essere autorizzato all'invio di un messaggio al servizio ma non necessita di altre autorizzazioni nel database.

Per una conversazione che utilizza la protezione avanzata, la connessione su ogni lato della conversazione utilizza le autorizzazioni dell'utente specificato nell'associazione al servizio remoto. Se ad esempio un'associazione al servizio remoto associa il nome di servizio InventoryService all'utente InventoryServiceRemoteUser, SQL Server utilizza il contesto di protezione per InventoryServiceRemoteUser per inserire i messaggi per l'applicazione InventoryService nella coda per il servizio di destinazione.

Per una protezione più efficace, l'utente proprietario della chiave privata per un servizio è in genere diverso dall'utente specificato per l'attivazione. Per il proprietario di una chiave privata è necessaria solo l'autorizzazione per l'aggiunta di un messaggio nella coda, ovvero l'autorizzazione SEND per il servizio che utilizza la coda. L'utente specificato per l'attivazione, al contrario, è dotato delle autorizzazioni necessarie per eseguire l'operazione richiesta e inviare una risposta. Nell'esempio citato in precedenza, per InventoryServiceRemoteUser non è necessaria l'autorizzazione per l'esecuzione di una query sulla tabella di inventario o per l'invio di un messaggio ma è necessaria solo l'autorizzazione per l'invio di un messaggio alla coda utilizzata da InventoryService. L'attivazione della stored procedure si verifica in un'altra sessione con le credenziali specificate dalla coda. Non è necessaria la condivisione di credenziali tra la sessione che accoda il messaggio e la sessione che lo elabora.

Creazione di un dialogo protetto

Quando Service Broker stabilisce un dialogo tra due database, il servizio di origine deve stabilire un contesto utente nel database di destinazione per fare in modo che i messaggi vengano inseriti nella coda di destinazione. Il contesto utente determina se il servizio di origine ha o meno l'autorizzazione per poter aprire un dialogo verso la destinazione.

Il modo più flessibile per fare ciò è creare un certificato e un'associazione al servizio remoto. Per ulteriori informazioni sulla creazione di un certificato, vedere CREATE CERTIFICATE (Transact-SQL). Per ulteriori informazioni sulla creazione di un'associazione a un servizio remoto, vedere CREATE REMOTE SERVICE BINDING (Transact-SQL).

Un'alternativa alla creazione di un certificato e all'associazione a un servizio remoto è costituita dall'utilizzo della protezione di SQL Server per stabilire una relazione di trust tra i due database. Il proprietario del servizio di origine rappresenta un utente nel servizio di destinazione. A questo scopo potrebbe essere necessario impostare su ON la proprietà del database TRUSTWORTHY sul database di origine e concedere l'autorizzazione di autenticazione a un utente nel database di destinazione. Per ulteriori informazioni, vedere Estensione della rappresentazione di database tramite EXECUTE AS.

[!NOTA]

Se il contesto di protezione non è impostato correttamente, i messaggi inviati durante il dialogo resteranno nella vista sys.transmission_queue sul servizio di origine, con il seguente messaggio di errore nella colonna transmission_status: L'entità server '%.*ls' non è in grado di accedere al database '%.*ls' nel contesto di protezione corrente.