Artikel
09/24/2010

Zertifikate für die Dialogsicherheit

Wenn eine Konversation beginnt, verwendet Service Broker Remotedienstbindungen, um das für die Konversation zu verwendende Zertifikat zu suchen. In diesem Thema wird beschrieben, wie Service Broker das für eine Konversation zu verwendende Zertifikat ermittelt.

Suchen des Zertifikats für einen Dialog

Service Broker sucht zuerst eine Remotedienstbindung für die Konversation und wählt dann ein Zertifikat aus, das dem in der Bindung angegebenen Benutzer gehört.

Zum Suchen einer Bindung überprüft Service Broker die Datenbank auf eine Bindung, in der der Zieldienstname für die Konversation angegeben ist.

Zum Auswählen eines Zertifikats sucht Service Broker das Zertifikat mit dem spätesten Ablaufdatum, dessen Besitzer der in der Remotedienstbindung angegebene Benutzer ist. Service Broker berücksichtigt keine Zertifikate, die noch nicht gültig oder abgelaufen oder nicht als für den Dialogbeginn verfügbar gekennzeichnet sind. Weitere Informationen zu Zertifikaten finden Sie unter CREATE CERTIFICATE (Transact-SQL).

Wenn keine Remotedienstbindung vorhanden ist oder der Benutzer für die Remotedienstbindung kein gültiges Zertifikat besitzt, das für den Dialogbeginn verfügbar ist, kann Service Broker keine Nachrichten für die Konversation verschlüsseln. Wenn keine Bindung vorhanden ist und die Datenbank einen Brokerkonfigurationsdienst enthält, fordert Service Broker eine Bindung durch diesen Dienst an. Wenn kein Brokerkonfigurationsdienst in der Datenbank vorhanden ist oder dieser keine Remotedienstbindung bereitstellt, wird die Konversation verzögert, wenn die Verschlüsselung aktiviert (ON) ist, oder sie wird ohne Verschlüsselung fortgesetzt, wenn die Verschlüsselung nicht aktiviert (OFF) ist. Weitere Informationen finden Sie unter Festlegen des Dialogsicherheitstyps.

Remoteautorisierung und Dialogsicherheit

Bei der Service Broker-Dialogsicherheit werden Zertifikate für die Remoteautorisierung verwendet. Wenn ein Dialog die Dialogsicherheit verwendet, enthält die erste von jedem Teilnehmer der Konversation gesendete Nachricht Headerinformationen, die mit dem privaten Schlüssel des Absenders verschlüsselt sind, und Headerinformationen, die mit dem öffentlichen Schlüssel des Empfängers verschlüsselt sind. Der Inhalt der Nachricht ist mit einem Sitzungsschlüssel verschlüsselt. Der Sitzungsschlüssel selbst ist verschlüsselt und kann nur mithilfe des privaten Schlüssels des Empfängers wiederhergestellt werden.

Wenn der Empfänger der Nachricht die Nachricht erfolgreich entschlüsseln kann, besitzt der Empfänger die entsprechenden Schlüssel. Dies bestätigt die Identität jedes Teilnehmers der Konversation. Beim Installieren eines Zertifikats in einer Datenbank wird eine Vertrauensbeziehung zu der Datenbank erstellt, die den privaten Schlüssel enthält.

Bei der Verschlüsselung eines Headers mit dem privaten Schlüssel des lokalen Benutzers wird die Frage gestellt, ob die Remotedatenbank der lokalen Datenbank vertraut. Die Remotedatenbank kann den Header nur entschlüsseln, wenn die Datenbank den entsprechenden öffentlichen Schlüssel enthält. Beim Verschlüsseln eines Headers mit dem öffentlichen Schlüssel eines Benutzers in der Remotedatenbank wird die Frage gestellt, ob die lokale Datenbank der Remotedatenbank vertraut. Die Remotedatenbank kann den Header nur entschlüsseln, wenn die Datenbank den entsprechenden privaten Schlüssel enthält. Aus Sicherheits- und Effizienzgründen stellt Service Broker beide Fragen gleichzeitig. Allerdings ist die Nachricht so strukturiert, dass ein Empfänger in der Lage sein muss, beide Fragen zu bestätigen, um auf die Nachricht richtig zu antworten.

Die Überlegung hinter dieser Strategie ist einfach. Wenn die Remotedatenbank einen mit einem privaten Schlüssel in der lokalen Datenbank verschlüsselten Header entschlüsseln kann, enthält die Remotedatenbank den entsprechenden öffentlichen Schlüssel, und die Remotedatenbank vertraut der lokalen Datenbank. Wenn die Remotedatenbank einen mit einem öffentlichen Schlüssel in der lokalen Datenbank verschlüsselten Header entschlüsseln kann, enthält die Remotedatenbank den entsprechenden privaten Schlüssel, und die lokale Datenbank vertraut der Remotedatenbank. Solange die privaten Schlüssel geheim bleiben, können nur die zwei an der Konversation beteiligten Datenbanken erfolgreich Nachrichten in der Konversation austauschen.

Hinweis
Installieren Sie nur Zertifikate aus vertrauenswürdigen Quellen. Geben Sie private Schlüssel nicht weiter.

Bei voller Dialogsicherheit wird die Identität während des ersten Nachrichtenaustauschs in beiden Richtungen überprüft. Bei Konversationen, die anonyme Dialogsicherheit verwenden, stellt der Initiator sicher, dass die Zieldatenbank den erwarteten privaten Schlüssel enthält. Allerdings überprüft die Zieldatenbank bei anonymer Dialogsicherheit die Identität des Initiators nicht. Stattdessen muss die Datenbank, die als Host für den Zieldienst dient, der festen public-Datenbankrolle das Senden von Nachrichten an den Dienst ermöglichen.

Nachrichten müssen in beiden Richtungen ausgetauscht werden, bevor die lokale Datenbank die Identität der Remotedatenbank als bestätigt einstuft. Eine Überprüfung ist nur möglich, wenn die lokale Datenbank den richtigen öffentlichen Schlüssel für das Zertifikat in der Remotedatenbank enthält.

In die erste von jeder Seite der Konversation gesendete Nachricht schließt Service Broker die folgenden Header ein:

Einen Dienstpaar-Sicherheitsheader, der Informationen zu für die Nachricht verwendeten Zertifikaten enthält. Der Dienstpaar-Sicherheitsheader ist mit dem privaten Schlüssel des Benutzers signiert, der Besitzer des Diensts ist.
Einen Schlüsselaustauschschlüssel, mit dem der 128-Bit-Sitzungsschlüssel verschlüsselt wird, der zum Verschlüsseln des Nachrichtentexts verwendet wird. Der Schlüsselaustauschschlüssel ist mit dem öffentlichen Schlüssel des Remotebenutzers verschlüsselt.

Bei Dialogen mit anonymer Sicherheit bleibt der Dienstpaar-Sicherheitsheader unverschlüsselt. Die Nachricht selbst wird verschlüsselt, und der Schlüsselaustauschschlüssel wird mit dem öffentlichen Schlüssel des Sicherheitsprinzipals in der Zieldatenbank verschlüsselt. In diesem Fall enthält die erste Antwortnachricht keinen Schlüsselaustauschschlüssel, Dienstpaar-Sicherheitsheader oder verschlüsselten Sitzungsschlüssel.

Wenn Service Broker selbst eine Nachricht als Antwort auf eine eingehende Nachricht (z. B. einen Fehler oder eine Bestätigung) generiert, wird in dieser Nachricht der Sitzungsschlüssel der eingehenden Nachricht verwendet, unabhängig davon, ob im Dialog volle Sicherheit oder anonyme Sicherheit verwendet wird.