Certificati per la sicurezza della finestra di dialogo

Si applica a:SQL ServerIstanza gestita di SQL di Azure

Quando comincia una conversazione, Service Broker usa un'associazione al servizio remoto per individuare il certificato da usare. In questo argomento viene descritto in che modo Service Broker determina il certificato da usare per una conversazione.

Individuare il certificato per una finestra di dialogo

Service Broker individua innanzitutto un'associazione al servizio remoto per la conversazione, quindi seleziona un certificato di proprietà dell'utente specificato nell'associazione.

Per trovare un'associazione, Service Broker controlla il database in cerca di un'associazione che specifichi il nome del servizio di destinazione della conversazione.

Per selezionare un certificato, Service Broker trova il certificato con la data di scadenza più recente di proprietà dell'utente specificato nell'associazione al servizio remoto. Service Broker non considera i certificati non ancora validi, scaduti o non contrassegnati come disponibili per la finestra di dialogo di inizio. Per altre informazioni sui certificati, vedere CREATE CERTIFICATE.

Se non esiste alcuna associazione al servizio remoto o l'utente per l'associazione al servizio remoto non possiede un certificato valido disponibile per la finestra di dialogo di inizio, Service Broker non può crittografare i messaggi per la conversazione. Se non è presente alcuna associazione e il database contiene un servizio di configurazione broker, Service Broker richiede un'associazione tramite tale servizio. Se non è presente alcun servizio di configurazione Broker nel database o il servizio di configurazione broker non fornisce un'associazione al servizio remoto, la conversazione viene ritardata se la crittografia è ONo continua senza crittografia se la crittografia è OFF. Per altre informazioni, vedere Determinare il tipo di sicurezza della finestra di dialogo.

Sicurezza delle finestre di dialogo e autorizzazione remota

La sicurezza del dialogo di Service Broker usa i certificati per l'autorizzazione remota. Quando una finestra di dialogo usa la sicurezza del dialogo, il primo messaggio inviato da ogni partecipante della conversazione contiene informazioni di intestazione crittografate con la chiave privata dell'utente mittente e le informazioni di intestazione crittografate con la chiave pubblica dell'utente ricevente. Il contenuto del messaggio viene crittografato con una chiave della sessione. La chiave della sessione è anch'essa crittografata e può essere recuperata soltanto usando la chiave privata dell'utente ricevente.

Se il destinatario del messaggio può decrittografare correttamente il messaggio, significa che il destinatario possiede le chiavi corrispondenti e conferma l'identità di ogni partecipante della conversazione. L'installazione di un certificato in un database crea una relazione di trust con il database che contiene la chiave privata.

Di fatto, la crittografia di un'intestazione con la chiave privata per l'utente locale pone la domanda se il database remoto consideri attendibile il database locale. Il database remoto può decrittografare l'intestazione solo se il database contiene la chiave pubblica corrispondente. La crittografia di un'intestazione con la chiave pubblica per un utente nel database remoto pone la domanda se il database locale consideri attendibile il database remoto. Il database remoto può decrittografare l'intestazione solo se il database contiene la chiave privata corrispondente. Per motivi di sicurezza ed efficienza, Service Broker pone entrambe le domande in contemporanea. Tuttavia, il messaggio è strutturato in modo che un destinatario sia in grado di rispondere affermativamente a entrambe le domande per rispondere correttamente al messaggio.

Il ragionamento alla base di questa strategia è semplice. Se il database remoto è in grado di decifrare un'intestazione crittografata con una chiave privata nel database locale, il database remoto contiene la chiave pubblica corrispondente e il database remoto si fida del database locale. Se il database remoto è in grado di decifrare un'intestazione crittografata con una chiave pubblica nel database locale, il database remoto contiene la chiave privata corrispondente e il database locale si fida del database remoto. Finché le chiavi private rimangono segrete, solo i due database coinvolti nella conversazione possono scambiare correttamente messaggi nella conversazione.

Nota

Installare solo i certificati da fonti attendibili. Non distribuire chiavi private.

La sicurezza completa di dialogo verifica l'identità in entrambe le direzioni durante il primo scambio di messaggi. Per le conversazioni che usano la sicurezza anonima di dialogo, l'iniziatore verifica che il database di destinazione contenga la chiave privata prevista. Tuttavia, con la sicurezza anonima dei dialoghi, il database di destinazione non verifica l'identità dell'iniziatore; Al contrario, il database che ospita il servizio di destinazione deve consentire al ruolo predefinito del database pubblico di inviare messaggi al servizio.

I messaggi devono essere scambiati in entrambi i modi, prima che il database locale consideri l'identità del database remoto da confermare. La verifica può avvenire solo se il database locale contiene la chiave pubblica corretta per il certificato nel database remoto.

Per il primo messaggio inviato da ogni lato della conversazione, Service Broker include le seguenti intestazioni:

  • Intestazione di sicurezza della coppia di servizi contenente informazioni sui certificati usati per il messaggio. L'intestazione di sicurezza della coppia di servizi è firmata con la chiave privata dell'utente proprietario del servizio.

  • Una chiave abilitata per lo scambio di chiavi che crittografa la chiave della sessione a 128 bit usata per crittografare il corpo del messaggio. La chiave abilitata per lo scambio di chiavi viene crittografata con la chiave pubblica dell'utente remoto.

Nei dialoghi che usano la sicurezza anonima, l'intestazione di sicurezza della coppia di servizi rimane non crittografata. Comunque, i messaggi restano crittografati e la chiave abilitata per lo scambio di chiavi viene crittografata con la chiave pubblica per l'entità di sicurezza nel database di destinazione. In questo caso, il primo messaggio restituito non contiene una chiave di scambio di chiavi, un'intestazione di sicurezza della coppia di servizi o una chiave di sessione crittografata.

Quando Service Broker genera un messaggio in risposta a un messaggio in arrivo, ad esempio un errore o un acknowledgement, usa la chiave della sessione del messaggio in arrivo, indipendentemente dall'uso della sicurezza avanzata o anonima del dialogo.

Contenuti correlati

  • Last updated on