Freigeben über

  • Artikel

Sicherheitsübersicht (Service Broker)

Mit Service Broker können Sie hochgradig skalierbare Datenbankanwendungen schreiben, die auch sicher und zuverlässig sind. Durch die Service Broker-Sicherheit können Dienste, die durch verschiedene SQL Server-Instanzen gehostet werden, sicher kommunizieren, auch wenn die Instanzen auf unterschiedlichen Computern sind, die keine andere Vertrauensstellung haben oder bei denen die Quell- und Zielcomputer nicht gleichzeitig mit demselben Netzwerk verbunden sind.

Die Service Broker-Sicherheit stützt sich auf Zertifikate. Die allgemeine Vorgehensweise besteht darin, Zertifikate so zu verwenden, dass sie die Anmeldeinformationen zu einer Remotedatenbank bereitstellen, und dann die Vorgänge von der Remotedatenbank dem lokalen Benutzer zuzuordnen. Die Berechtigungen des lokalen Benutzers gelten für beliebige Vorgänge für den Remotedienst. Das Zertifikat wird von den Datenbanken gemeinsam verwendet. Keine anderen Benutzerinformationen werden gemeinsam verwendet.

Service Broker bietet zwei unterschiedliche Sicherheitstypen: die Dialogsicherheit und die Transportsicherheit. Das Verständnis der Funktionsweise dieser zwei Sicherheitstypen hilft Ihnen dabei, Service Broker-Anwendungen zu konzipieren, bereitzustellen und zu verwalten.

  • Dialogsicherheit: Verschlüsselt Nachrichten in einer einzelnen Dialogkonversation und überprüft die Identitäten der Dialogteilnehmer. Die Dialogsicherheit bietet außerdem Remoteautorisierung und Nachrichtenintegritätsüberprüfung. Die Dialogsicherheit stellt authentifizierte und verschlüsselte Kommunikation zwischen zwei Diensten her.

  • Transportsicherheit: Verhindert, dass nicht autorisierte Datenbanken Service Broker-Nachrichten an Datenbanken in der lokalen Instanz senden. Die Transportsicherheit stellt eine authentifizierte Netzwerkverbindung zwischen zwei Datenbanken her.

Beachten Sie, dass das Dialogprotokoll und das zugehörige Brokerprotokoll für das Weiterleiten von Nachrichten zwischen zwei Datenbanken konzipiert sind und nicht für das Ausführen von Befehlen in einer Remotedatenbank. Durch diese Kommunikationsweise kann Service Broker Dienste anbieten, ohne dass Datenbanken SQL Server-Anmeldenamen oder Windows-Sicherheitsanmeldeinformationen gemeinsam verwenden müssen.

Weitere Informationen zu Zertifikaten finden Sie unter CREATE CERTIFICATE (Transact-SQL).

Sicherheitsszenario bei Adventure Works Cycles

In einem beispielhaften Geschäftsszenario erstellt Adventure Works Cycles, eine fiktive Firma, einen Service Broker-Dienst zum Übermitteln von Bauteilbestellungen an Lieferanten. Dieser Dienst erfordert Sicherheit sowohl für Adventure Works als auch für die Lieferanten. Jeder Lieferant muss gewährleisten können, dass ausschließlich vorhandene Kunden Bestellungen absenden können. Adventure Works muss gewährleisten können, dass nur qualifizierte Lieferanten Bestellungen empfangen können. Nachrichten zwischen der AdventureWorks2008R2-Datenbank und einem Lieferanten müssen verschlüsselt werden, sodass keine Dritten eine Nachricht lesen können. Um die höchstmögliche Sicherheitsstufe sicherzustellen, dürfen nur qualifizierte Lieferanten eine Verbindung mit der AdventureWorks2008R2-Datenbank herstellen.

Um der Anforderung zu entsprechen, dass Nachrichten verschlüsselt werden müssen, verwenden Adventure Works und die Lieferanten die Service Broker-Dialogsicherheit:

  1. Zum Einrichten der Dialogsicherheit erstellt der AdventureWorks2008R2-Administrator einen lokalen Benutzer namens VendorOutgoing und ein Schlüsselpaar für diesen Benutzer.

  2. Der Administrator verteilt das Zertifikat, das den öffentlichen Schlüssel des Schlüsselpaars enthält, an die Lieferanten, die Zugriff auf den Dienst benötigen.

  3. Jeder Lieferant installiert das Zertifikat von Adventure Works Cycles in die Datenbank und erstellt einen Benutzer, der das Zertifikat besitzt.

  4. Der Lieferant erstellt daraufhin ein Schlüsselpaar und sendet die Informationen zum Dienstnamen für den Lieferantendienst und ein Zertifikat mit dem öffentlichen Schlüssel des Schlüsselpaars an den AdventureWorks2008R2-Administrator.

  5. Der AdventureWorks2008R2-Administrator erstellt für jeden Lieferanten einen Benutzer und ordnet das Zertifikat von diesem Lieferanten dem Benutzer zu.

  6. Der Administrator erstellt auch eine Remotedienstbindung für jeden Lieferanten, die den Namen des Lieferantendiensts dem für den Lieferanten erstellten Benutzer zuordnet.

Um der Anforderung zu entsprechen, dass nur qualifizierte Lieferanten eine Verbindung mit der AdventureWorks2008R2 herstellen können, verwendet der AdventureWorks2008R2-Administrator die Service Broker-Transportsicherheit:

  1. Zum Einrichten der Transportsicherheit erstellt der AdventureWorks2008R2-Administrator ein Zertifikat in der master-Datenbank der SQL Server-Instanz, die Nachrichten senden wird.

  2. Der AdventureWorks2008R2-Administrator sendet das Zertifikat jedem Lieferanten.

  3. Jeder Administrator auf Lieferantenseite erstellt einen Benutzer in der master-Datenbank, der Besitzer des Zertifikats ist, und installiert anschließend das Zertifikat in der SQL Server-Instanz, die Nachrichten empfangen wird.

  4. Der Administrator auf Lieferantenseite erstellt in der master-Datenbank der Instanz ein Zertifikat und sendet den öffentlichen Schlüssel für diesen Benutzer an den AdventureWorks2008R2-Administrator.

  5. Zum Schluss erstellt der AdventureWorks2008R2-Administrator in der master-Datenbank einen Benutzer, der jedes Zertifikat mit dem öffentlichen Schlüssel der Lieferanten besitzt, und installiert jedes Zertifikat von den Lieferanten in der Datenbank.

Die Kombination von Transport- und Dialogsicherheit ermöglicht es dem AdventureWorks2008R2-Administrator, den Sicherheitsanforderungen dieser Anwendung zu entsprechen. Beachten Sie in diesem Szenario, dass die Lieferanten sich nicht bei der AdventureWorks2008R2-Datenbank anmelden können. Auch der Adventure Works-Administrator kann sich nicht bei den Lieferantendatenbanken anmelden. Nur Service Broker-Nachrichten können zwischen den Datenbanken ausgetauscht werden.