Service Broker-Dialogsicherheit
Die Dialogsicherheit bietet Verschlüsselung, Remoteauthentifizierung und Remoteautorisierung für eine bestimmte Konversation. Wenn eine Konversation die Dialogsicherheit verwendet, werden von Service Broker alle Nachrichten verschlüsselt, die außerhalb einer SQL Server-Instanz gesendet wurden. Service Broker-Konversationen verwenden standardmäßig die Dialogsicherheit.
Grundlagen zur Dialogsicherheit
Mit der Service Broker-Dialogsicherheit kann Ihre Anwendung die Authentifizierung, Autorisierung oder Verschlüsselung für eine einzelne Dialogkonversation (oder einen Dialog) verwenden. Standardmäßig verwenden alle Dialogkonversationen die Dialogsicherheit. Wenn Sie mit einem Dialog beginnen, können Sie einem Dialog ausdrücklich ermöglichen, ohne Dialogsicherheit fortzufahren, indem Sie die ENCRYPTION = OFF-Klausel in die BEGIN DIALOG CONVERSATION-Anweisung aufnehmen. Wenn jedoch für den Dienst, auf den die Konversation abzielt, eine Remotedienstbindung besteht, verwendet der Dialog die Sicherheit, selbst wenn ENCRYPTION = OFF ist.
Für einen Dialog, der die Dialogsicherheit verwendet, werden von Service Broker alle Nachrichten verschlüsselt, die außerhalb einer SQL Server-Instanz gesendet werden. Nachrichten, die innerhalb einer SQL Server-Instanz verbleiben, werden nie verschlüsselt. Bei der Dialogsicherheit benötigen lediglich die Datenbank, die den initiierenden Dienst hostet, und die Datenbank, die den Zieldienst hostet, Zugriff auf die für die Sicherheit verwendeten Zertifikate. Das heißt, eine Instanz, die die Nachrichtenweiterleitung ausführt, benötigt nicht die Möglichkeit zum Entschlüsseln von Nachrichten, die von der Instanz weitergeleitet werden.
Service Broker bietet zwei Arten von Dialogsicherheit, vollständige Sicherheit und anonyme Sicherheit. Für Konversationen, die die Dialogsicherheit verwenden, wird von Service Broker die Remoteautorisierung zum Zuordnen der Remoteseite der Konversation zu einem lokalen Benutzer bereitgestellt.
Nachrichten werden im Netzwerk verschlüsselt, wenn die Konversation entweder vollständige oder anonyme Sicherheit verwendet. Die effektiven Rechte in der Zieldatenbank und die für die Nachrichtenverschlüsselung verwendete Strategie weichen leicht zwischen den beiden Ansätzen ab.
Ob die Konversation nun vollständige oder anonyme Sicherheit verwendet, der Nachrichtentext wird mit einem symmetrischen Sitzungsschlüssel verschlüsselt, der für die spezielle Konversation generiert wird. Es werden nur die Schlüssel mit privaten Schlüsseln verschlüsselt, die das für die Dialogsicherheit bereitgestellte Zertifikat verwenden.Von Service Broker wird auch eine Nachrichtenintegritätsprüfung ausgeführt, mit der eine Nachrichtenbeschädigung oder -manipulation entdeckt werden kann.
Von SQL Server wird ein Sitzungsschlüssel für eine Konversation erstellt, die die Dialogsicherheit verwendet. Um den Sitzungsschlüssel zu schützen, während er in der Datenbank gespeichert wird, verschlüsselt Service Broker den Sitzungsschlüssel mit dem Hauptschlüssel der Datenbank. Falls kein Datenbank-Hauptschlüssel verfügbar ist, verbleiben Nachrichten für die Konversation in der Übertragungswarteschlange transmission_status, bis ein Datenbank-Hauptschlüssel erstellt wird oder ein Timeout für die Konversation eintritt. Deshalb müssen beide Datenbanken, die an der Konversation teilnehmen, Hauptschlüssel enthalten, selbst wenn die Datenbanken in derselben Instanz gehostet werden. Wenn die initiierende Datenbank keinen Hauptschlüssel enthält, erzeugt der Dialog einen Fehler. Wenn die Zieldatenbank keinen Hauptschlüssel enthält, verbleiben die Nachrichten in der Übertragungswarteschlange der initiierenden Datenbank. Der letzte Übertragungsfehler für diese Nachrichten gibt den Grund dafür an, dass die Nachrichten nicht zugestellt werden können. Verwenden Sie den Parameter ENCRYPTION = OFF zum Erstellen eines unverschlüsselten Dialogs, oder erstellen Sie mithilfe des folgenden Befehls einen Datenbank-Hauptschlüssel:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'
Aus praktischen Gründen lässt Service Broker zu, dass sichere Konversationen, die innerhalb einer einzelnen Datenbank verbleiben, fortgesetzt werden, unabhängig davon, ob die Datenbank einen Hauptschlüssel enthält oder nicht. Während zwei verschiedene Datenbanken während der Lebensdauer einer Konversation an andere SQL Server-Instanzen verschoben werden können, verbleibt eine Konversation innerhalb einer Datenbank immer in dieser Datenbank. Deshalb kann die Konversation fortgesetzt werden.
Vollständige Sicherheit
Die vollständige Sicherheit schützt den initiierenden Dienst davor, Nachrichten an eine nicht vertrauenswürdige Datenbank zu senden, und schützt den Zieldienst davor, Nachrichten von einer nicht vertrauenswürdigen Datenbank zu empfangen. Die über das Netzwerk übertragenen Nachrichten werden von Service Broker verschlüsselt, wenn die Konversation die vollständige Sicherheit verwendet.
Die vollständige Sicherheit bietet eine Identifikation sowohl für den initiierenden Dienst als auch den Zieldienst. Die vollständige Sicherheit setzt voraus, dass der initiierende Dienst dem Zieldienst vertraut und dass der Zieldienst dem initiierenden Dienst vertraut. Ein Dienst, der z. B. Teile von einem Lieferanten bestellt, benötigt eine Bestellanwendung, die dem Lieferantendienst vertraut, und einen Lieferantendienst, der der Bestellanwendung vertraut.
Datenbankadministratoren stellen Vertrauen her, indem Zertifikate ausgetauscht werden, die öffentliche Schlüssel enthalten. Für eine vollständige Dialogsicherheit hat jede Seite der Konversation einen privaten Schlüssel für einen lokalen Benutzer und einen öffentlichen Schlüssel für einen Remotebenutzer. Die Datenbank, die den initiierenden Dienst hostet, hat eine Remotedienstbindung. Diese Remotedienstbindung gibt den lokalen Benutzer an, der das Zertifikat besitzt, das dem privaten Schlüssel in der Remotedatenbank entspricht. Vorgänge vonseiten des initiierenden Dienstes werden deshalb in der Zieldatenbank als bestimmter Benutzer ausgeführt.
Die Zieldatenbank enthält einen Benutzer. Dieser Benutzer besitzt ein Zertifikat, das einem privaten Schlüssel entspricht, dessen Besitzer der Benutzer ist, der Besitzer des initiierenden Dienstes ist. Deshalb werden die Vorgänge vonseiten des Zieldienstes in der initiierenden Datenbank als der Benutzer ausgeführt, der Besitzer des initiierenden Dienstes ist.
Für Dialoge, die die vollständige Sicherheit verwenden, generiert jede Seite der Konversation einen Sitzungsschlüssel. Die erste Nachricht in jede Richtung enthält den Sitzungsschlüssel, der mit einem Schlüsselaustauschschlüssel verschlüsselt ist, wie unter Zertifikate und Service Broker beschrieben.
Anonyme Sicherheit
Die anonyme Sicherheit schützt den initiierenden Dienst vor dem Senden von Nachrichten an eine nicht vertrauenswürdige Datenbank. Die über das Netzwerk übertragenen Nachrichten werden von Service Broker verschlüsselt, wenn die Konversation die anonyme Sicherheit verwendet.
Die anonyme Sicherheit identifiziert den Zieldienst für den initiierenden Dienst, jedoch nicht den initiierenden Dienst für den Zieldienst.
Eine Anwendung, die z. B. Arbeitsaufträge übermittelt, sollte ggf. garantieren, dass der Empfänger des Arbeitsauftrags das beabsichtigte Ziel ist, die Zieldatenbank stellt jedoch eventuell keine speziellen Privilegien für einen Dienst bereit, der die Arbeitsaufträge übermittelt. In diesem Fall muss die Datenbank, die den initiierenden Dienst enthält, eine Remotedienstbindung für den Zieldienst enthalten.
Da der Zieldienst die Identität des initiierenden Dienstes nicht prüfen kann, werden die Vorgänge vonseiten des initiierenden Dienstes in der Zieldatenbank als Mitglied der festen Datenbankrolle öffentlich ausgeführt. Die Zieldatenbank erhält keine Informationen über den Benutzer, der die Konversation initiiert hat. Die Zieldatenbank muss kein Zertifikat für den Benutzer enthalten, der die Konversation initiiert.
Für Dialoge, die die anonyme Sicherheit verwenden, verwenden beide Seiten der Konversation den von der initiierenden Datenbank generierten Sitzungsschlüssel. Die Zieldatenbank gibt keinen Sitzungsschlüssel an die initiierende Datenbank zurück.
Sicherheitskontexte für die Dialogsicherheit
Die Remoteautorisierung von Service Broker steuert den Remotezugriff auf einen einzelnen Dienst. Die Remoteautorisierung legt den Sicherheitskontext fest, innerhalb dessen die bei einer SQL Server-Instanz eingehenden Nachrichten an einen Dienst gesendet werden.
Service Broker verwendet immer die Remoteautorisierung für eine sichere Konversation, die nicht ganz innerhalb einer SQL Server-Instanz stattfindet. Die für die Konversation konfigurierte Dialogsicherheit bestimmt den von Service Broker für die Remoteautorisierung verwendeten Sicherheitskontext.
Von Service Broker wird keine Remoteautorisierung verwendet, wenn die Konversation innerhalb einer SQL Server-Instanz verbleibt, selbst wenn die Remoteautorisierung konfiguriert ist. Für eine Konversation innerhalb einer Instanz stehen die SQL Server-Sicherheitsprinzipale bereits für SQL Server zur Verfügung, sodass keine Remoteautorisierung verwendet werden muss, um den richtigen Sicherheitskontext für Service Broker-Vorgänge zu bestimmen. Wie jedoch weiter oben in diesem Thema beschrieben, wird von Service Broker ein Sitzungsschlüssel erstellt, sodass die Konversation fortgesetzt werden kann, wenn eine der Datenbanken während der Konversation an eine andere Instanz verschoben wird.
Für eine Konversation, die die anonyme Sicherheit verwendet, wird die Verbindung in der Zieldatenbank als Mitglied der festen Datenbankrolle public ausgeführt. In diesem Fall muss die feste Datenbankrolle public die Berechtigung zum Senden einer Nachricht an den Dienst haben. Die Rolle benötigt jedoch keine weiteren Berechtigungen in der Datenbank.
Für eine Konversation, die die vollständige Sicherheit verwendet, wird die Verbindung auf jeder Seite mit den Berechtigungen des Benutzers ausgeführt, der in der Remotedienstbindung angegeben ist. Wenn eine Remotedienstbindung z. B. den Dienstnamen InventoryService dem Benutzer InventoryServiceRemoteUser zuordnet, verwendet SQL Server den Sicherheitskontext für InventoryServiceRemoteUser, um Nachrichten für die InventoryService-Anwendung in die Warteschlange für den Zieldienst zu stellen.
Zum Zwecke einer verbesserten Sicherheit ist der Benutzer, der Besitzer des privaten Schlüssels ist, in der Regel ein anderer Benutzer als der für die Aktivierung angegebene Benutzer. Ein Benutzer, der Besitzer eines privaten Schlüssels ist, benötigt lediglich die Berechtigung zum Hinzufügen einer Nachricht zur Warteschlange, d. h. die SEND-Berechtigung für den Dienst, der die Warteschlange verwendet. Im Gegensatz dazu hat der für die Aktivierung angegebene Benutzer die Berechtigungen, die zum Durchführen der angeforderten Arbeiten und zum Senden einer Antwort benötigt werden. Im vorherigen Beispiel benötigt InventoryServiceRemoteUser keine Berechtigungen zum Abfragen der Lagerbestandstabelle oder zum Senden einer Antwortnachricht. Der Benutzer benötigt lediglich Berechtigungen zum Senden einer Nachricht an die Warteschlange, die von InventoryService verwendet wird. Die Aktivierung der gespeicherten Prozedur findet in einer anderen Sitzung mit den Anmeldeinformationen statt, die von der Warteschlange angegeben werden. Es müssen keine Anmeldeinformationen von der Sitzung, die die Nachricht in die Warteschlange einreiht, und der Sitzung, die die Nachricht verarbeitet, gemeinsam genutzt werden.
Erstellen eines sicheren Dialogs
Wenn von Service Broker ein Dialog zwischen zwei Datenbanken hergestellt wird, muss der initiierende Dienst einen Benutzerkontext in der Zieldatenbank herstellen, damit Nachrichten in die Zielwarteschlange gestellt werden können. Der Benutzerkontext bestimmt, ob der initialisierende Dienst die Berechtigung besitzt, einen Dialog im Ziel zu öffnen.
Der flexibelste Weg ist, ein Zertifikat und eine Remotedienstbindung zu erstellen. Weitere Informationen zum Erstellen von Zertifikaten finden Sie unter CREATE CERTIFICATE (Transact-SQL). Weitere Informationen zum Erstellen einer Remotedienstbindung finden Sie unter CREATE REMOTE SERVICE BINDING (Transact-SQL).
Eine Alternative zum Erstellen eines Zertifikats und einer Remotedienstbindung ist die Verwendung der SQL-Sicherheit, um eine vertrauenswürdige Beziehung zwischen den beiden Datenbanken einzurichten. Der Besitzer des initialisierenden Dienstes nimmt die Identität des Benutzers im Zieldienst an. Dies erfordert möglicherweise die Einstellung ON der TRUSTWORTHY-Datenbankeigenschaft auf der initialisierenden Datenbank und gewährt einem Benutzer authentifizierte Berechtigungen auf der Zieldatenbank. Weitere Informationen finden Sie unter Erweitern des Identitätswechsels bei Datenbanken durch Verwenden von EXECUTE AS.
.gif "Hinweis") Hinweis |
|---|
Wenn der Sicherheitskontext nicht richtig eingerichtet wurde, beinhalten die gesendeten Nachrichten des Dialogs in der sys.transmission_queue auf dem initialisierenden Dienst in der transmission_status-Spalte folgende Fehlernachricht: Der Serverprinzipal "%1!s!" kann unter dem aktuellen Sicherheitskontext nicht auf die "%2!s!"-Datenbank zugreifen. |