Vorgehensweise: Konfigurieren von initiierenden Diensten für eine vollständige Dialogsicherheit (Transact-SQL)

SQL Server verwendet die Dialogsicherheit für jede Konversation mit einem Dienst, für den eine Remotedienstbindung in der Datenbank vorhanden ist, die als Host für den initiierenden Dienst fungiert. Wenn die Datenbank, die als Host des Zieldienstes fungiert, einen Benutzer enthält, der dem Benutzer entspricht, der den Dialog erstellte, und die Remotedienstbindung keine anonyme Sicherheit angibt, dann verwendet der Dialog die vollständige Sicherheit.

Um sicherzustellen, dass ein initiierender Dienst die Dialogsicherheit verwendet, erstellen Sie eine Remotedienstbindung für den Dienst. Damit SQL Server die vollständige Sicherheit verwendet, darf die Remotedienstbindung keine anonyme Sicherheit angeben, und die Zieldatenbank muss für die Verwendung der volleständigen Sicherheit für diesen Dienst konfiguriert sein.

So konfigurieren Sie einen initiierenden Dienst für vollständige Dialogsicherheit

  1. Rufen Sie von einer vertrauenswürdigen Quelle ein Zertifikat für den Besitzer des Zieldienstes in der Remotedatenbank ab. In der Regel bedeutet dies, das Zertifikat mithilfe einer verschlüsselten E-Mail zu versenden oder das Zertifikat auf einem physikalischen Medium, z. B. einer Diskette, zu übertragen.

    SicherheitshinweisSicherheitshinweis

    Installieren Sie nur Zertifikate von vertrauenswürdigen Quellen.

    HinweisHinweis

    Das Zertifikat muss mit dem Hauptschlüssel für die Datenbank verschlüsselt sein. Weitere Informationen finden Sie unter CREATE MASTER KEY (Transact-SQL).

  2. Erstellen Sie einen Benutzer ohne Anmeldenamen für den Remotedienst.

  3. Installieren Sie das Zertifikat für den Remotedienstbenutzer. Der im vorherigen Schritt erstellte Benutzer besitzt das Zertifikat.

  4. Erstellen Sie eine Remotedienstbindung, die den Remotedienstbenutzer und den Dienst angibt.

  5. Erstellen Sie einen Benutzer ohne Anmeldenamen, um den lokalen Dienst zu besitzen.

  6. Erstellen Sie ein Zertifikat für den lokalen Dienst. Der im vorherigen Schritt erstellte Benutzer besitzt das Zertifikat.

    HinweisHinweis

    Das Zertifikat muss mit dem Hauptschlüssel für die Datenbank verschlüsselt sein. Weitere Informationen finden Sie unter CREATE MASTER KEY (Transact-SQL).

  7. Sichern Sie das Zertifikat.

    SicherheitshinweisSicherheitshinweis

    Sichern Sie lediglich das Zertifikat für diesen Benutzer. Sichern oder verteilen Sie keinesfalls den privaten Schlüssel, der dem Zertifikat zugeordnet ist.

  8. Übergeben Sie das Zertifikat und den Namen des initiierenden Dienstes an den Datenbankadministrator für die Remotedatenbank. Sie können das Zertifikat z. B. über physikalische Medien, wie eine Diskette oder eine CD-ROM, austauschen, es auf einer Dateifreigabe ablegen oder über eine gesicherte E-Mail versenden.

    HinweisHinweis

    Damit SQL Server die vollständige Dialogsicherheit verwendet, muss das Zertifikat in der Remotedatenbank installiert sein, und der in Schritt 7 erstellte Benutzer muss der Benutzer sein, der die Konversation beginnt.

Beispiel

USE AdventureWorks2008R2 ;
GO

--------------------------------------------------------------------
-- The first part of the script configures security to allow the
-- remote service to send messages in this database. The script creates
-- a user in this database, loads the certificate for the remote service,
-- grants permission to the user, and creates a remote service binding.

-- Given a certificate for the owner of the remote target service
-- SupplierOrders, create a remote service binding for
-- the service.  The remote user will be granted permission
-- to send messages to the local service OrderParts. 
-- This example assumes that the certificate for the service 
-- is saved in the file'C:\Certificates\SupplierOrders.cer' and that
-- the initiating service already exists.


-- Create a user without a login.  For convenience,
-- the name of the user is based on the name of the
-- the remote service.

CREATE USER [SupplierOrdersUser]
    WITHOUT LOGIN ;
GO

-- Install a certificate for a user
-- in the remote database. The certificate is
-- provided by the owner of the remote service. The
-- user for the remote service owns the certificate.

CREATE CERTIFICATE [SupplierOrdersCertificate]
    AUTHORIZATION [SupplierOrdersUser]
    FROM FILE='C:\Certificates\SupplierOrders.cer' ;
GO

-- Create the remote service binding. Notice
-- that the user specified in the binding
-- does not own the binding itself.

-- Creating this binding specifies that messages from
-- this database are secured using the certificate for
-- the [SupplierOrdersUser] user.

-- When the anonymous option is omitted, anonymous is OFF.
-- Therefore, the credentials for the user that begins
-- are used in the remote database.

CREATE REMOTE SERVICE BINDING [SupplierOrdersBinding]
    TO SERVICE 'SupplierOrders'
    WITH USER = [SupplierOrdersUser] ;
GO

--------------------------------------------------------------------
-- The second part of the script creates a local user that will begin
-- conversations to the remote service. The certificate for this
-- user must be provided to the owner of the remote service.


-- Create a user without a login for the local service.

CREATE USER [OrderPartsUser]
    WITHOUT LOGIN ;
GO

-- Create a certificate for the local service.
CREATE CERTIFICATE [OrderPartsCertificate]
    AUTHORIZATION [OrderPartsUser]
    WITH SUBJECT = 'Certificate for the order service user.';
GO

-- Make this user the owner of the initiator service.

ALTER AUTHORIZATION ON SERVICE::OrderParts TO OrderPartsUser 

-- Backup the certificate for the user that initiates the
-- conversation. This example assumes that the certificate
-- is named OrderServiceCertificate.
BACKUP CERTIFICATE [OrderPartsCertificate]
    TO FILE = 'C:\Certificates\OrderParts.cer' ;
GO

-- Grant RECEIVE permissions on the queue for the service.
-- This allows the local user to begin conversations from
-- services that use the queue.

GRANT RECEIVE ON [OrderPartsQueue] TO [OrderPartsUser] ;
GO