Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL ServerAzure SQL Managed Instance
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 ein Dialogfeld
Der Dienstbroker sucht zuerst eine Remotedienstbindung für die Unterhaltung 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.
Um ein Zertifikat auszuwählen, findet der Dienstbroker das Zertifikat mit dem neuesten Ablaufdatum, das dem benutzer gehört, der in der Remotedienstbindung angegeben ist. Der Dienstbroker berücksichtigt keine Zertifikate, die noch nicht gültig sind, die abgelaufen sind oder für das Startdialogfeld nicht als verfügbar gekennzeichnet sind. Weitere Informationen zu Zertifikaten finden Sie unter CREATE CERTIFICATE.
Wenn keine Remotedienstbindung vorhanden ist oder der Benutzer für die Remotedienstbindung kein gültiges Zertifikat besitzt, das für das Dialogfeld "Start" verfügbar ist, kann der Dienstbroker keine Nachrichten für die Unterhaltung verschlüsseln. Wenn keine Bindung vorhanden ist und die Datenbank einen Broker-Konfigurationsdienst enthält, fordert Service Broker eine Bindung über diesen Dienst an. Wenn in der Datenbank kein Broker-Konfigurationsdienst vorhanden ist oder der Broker-Konfigurationsdienst keine Remotedienstbindung bereitstellt, wird die Unterhaltung verzögert, wenn die Verschlüsselung erfolgt ONoder ohne Verschlüsselung fortgesetzt wird OFF. Weitere Informationen finden Sie unter Ermitteln des Dialogfeldsicherheitstyps.
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 Nachrichtenempfänger die Nachricht erfolgreich entschlüsseln kann, bedeutet dies, dass der Empfänger über die entsprechenden Schlüssel verfügt, und dies bestätigt die Identität jedes Teilnehmers in der Unterhaltung. 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 für den lokalen Benutzer stellt sich die Frage: „Vertraut die Remotedatenbank der lokalen Datenbank?“ Die Remotedatenbank kann den Header nur entschlüsseln, wenn die Datenbank den entsprechenden öffentlichen Schlüssel enthält. Bei der Verschlüsselung eines Headers mit dem öffentlichen Schlüssel für einen Benutzer in der Remotedatenbank stellt sich die Frage: „Vertraut die lokale Datenbank der Remotedatenbank?“ 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 von vertrauenswürdigen Quellen. Verteilen Sie keine privaten Schlüssel.
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. Bei anonymer Dialogsicherheit überprüft die Zieldatenbank jedoch nicht die Identität des Initiators. Stattdessen muss die Datenbank, in der der Zieldienst gehostet wird, die öffentliche Feste Datenbankrolle zum Senden von Nachrichten an den Dienst zulassen.
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 Rückgabenachricht keinen Schlüsselaustauschschlüssel, Dienstpaar-Sicherheitsheader oder einen 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.