Partager via


Procédure : configurer les services initiateurs pour une sécurité du dialogue totale (Transact-SQL)

SQL Server utilise la sécurité du dialogue sur toute conversation engagée vers un service pour lequel il existe des liaisons de service distant dans la base de données hébergeant le service à l'origine de la conversation. Le dialogue utilise la sécurité totale lorsque la base de données qui accueille le service cible contient un utilisateur correspondant à l'utilisateur qui a pris l'initiative du dialogue, tandis que les liaisons de service distant ne mentionnent aucune sécurité anonyme.

Pour vous assurer qu'un service initiateur utilise la sécurité du dialogue, créez des liaisons de service distant pour ce service. SQL Server utilise la sécurité totale lorsque ces liaisons de service distant ne spécifient aucune sécurité anonyme et que la base de données cible est configurée pour utiliser la sécurité totale sur ce service.

Configuration d'un service à l'origine d'une conversation pour une sécurité du dialogue totale

  1. Obtenez, auprès d'une source autorisée, un certificat pour le propriétaire du service cible dans la base de données distante. Cette opération implique généralement l'envoi du certificat au moyen d'un courrier électronique chiffré ou son transfert via un support physique tel qu'une disquette.

    Remarque relative à la sécuritéRemarque relative à la sécurité

    Installez uniquement des certificats provenant de sources fiables.

    [!REMARQUE]

    Le certificat doit être chiffré à l'aide de la clé principale de la base de données. Pour plus d'informations, consultez CREATE MASTER KEY (Transact-SQL).

  2. Créez un utilisateur sans connexion pour le service distant.

  3. Installez le certificat pour l'utilisateur du service distant. L'utilisateur créé à l'étape précédente est propriétaire du certificat.

  4. Créez des liaisons de service distant qui spécifient l'utilisateur du service distant et le service.

  5. Créez un utilisateur sans connexion qui soit propriétaire du service local.

  6. Créez un certificat pour le service local. L'utilisateur créé à l'étape précédente est propriétaire du certificat.

    [!REMARQUE]

    Le certificat doit être chiffré à l'aide de la clé principale de la base de données. Pour plus d'informations, consultez CREATE MASTER KEY (Transact-SQL).

  7. Sauvegardez le certificat.

    Remarque relative à la sécuritéRemarque relative à la sécurité

    Procédez uniquement à la sauvegarde du certificat pour cet utilisateur. N'effectuez ni sauvegarde, ni distribution de la clé privée associée au certificat.

  8. Fournissez le certificat et le nom du service initiateur à l'administrateur de la base de données distante. Utilisez, par exemple, un support physique (disquette ou CD-ROM), placez le certificat sur un partage de fichier ou envoyez-le par courrier électronique sécurisé.

    [!REMARQUE]

    Le certificat doit être installé dans la base de données distante et l'utilisateur créé à l'étape 7 doit être l'utilisateur qui engage la conversation pour que SQL Server utilise la sécurité du dialogue totale.

Exemple

USE AdventureWorks ;
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