Certificats de la sécurité du dialogue
Lorsqu'une conversation s'engage, Service Broker utilise des liaisons de service distant afin de localiser le certificat qui sera utilisé pour la conversation. Cette rubrique décrit la détermination de ce certificat par Service Broker pour l'utiliser dans une conversation.
Recherche du certificat pour un dialogue
Service Broker repère tout d'abord les liaisons de service distant pour la conversation, puis il sélectionne un certificat dont le propriétaire est spécifié dans ces liaisons.
Pour trouver une liaison, Service Broker consulte la base de données à la recherche de liaisons spécifiant le nom du service cible pour la conversation.
Pour sélectionner un certificat, il cherche celui dont la date d'expiration est la plus récente et dont le propriétaire est spécifié dans les liaisons de service distant. Service Broker ignore les certificats qui ne sont pas encore valides, les certificats qui ont expiré ou qui ne sont pas marqués comme disponibles pour engager un dialogue (begin dialog). Pour plus d'informations sur les certificats, consultez CREATE CERTIFICATE (Transact-SQL).
S'il n'existe aucune liaison de service distant, ou si l'utilisateur des liaisons ne possède pas de certificat valide disponible pour engager le dialogue (begin dialog), Service Broker se trouve dans l'impossibilité de chiffrer les messages pour la conversation. Si, en l'absence de liaisons, la base de données contient un service de configuration du broker, Service Broker l'utilise pour déposer une demande de liaisons. Si ce service n'existe pas, ou s'il ne fournit aucune liaison de service distant, la conversation est retardée lorsque le chiffrement est activé (ON) ou se poursuit sans chiffrement si cette fonction est désactivée (OFF). Pour plus d'informations, consultez Sélection du type de sécurité du dialogue.
Autorisation distante et sécurité du dialogue
La sécurité du dialogue Service Broker utilise des certificats pour l'autorisation distante. Lorsqu'un dialogue est protégé par la sécurité du dialogue, le premier message envoyé par chaque participant d'une conversation contient des informations d'en-tête chiffrées à l'aide de la clé privée de l'utilisateur expéditeur, ainsi que des informations d'en-tête chiffrées à l'aide de la clé publique de l'utilisateur destinataire. Le contenu du message est chiffré au moyen d'une clé de session. Cette clé de session est elle-même chiffrée et ne peut être récupérée qu'à l'aide de la clé privée pour l'utilisateur destinataire.
Le fait que le destinataire du message puisse déchiffrer le message sans problème signifie qu'il possède les clés correspondantes et, ainsi, il confirme l'identité de chaque participant de la conversation. L'installation d'un certificat dans une base de données instaure une relation d'approbation avec la base de données qui conserve la clé privée.
De fait, chiffrer un en-tête au moyen de la clé privée pour l'utilisateur local pose la question suivante : « La base de données distante approuve-t-elle la base de données locale ? » La base de données distante peut déchiffrer l'en-tête uniquement si la base de données contient la clé publique correspondante. Chiffrer un en-tête au moyen de la clé publique pour un utilisateur de la base de données distante pose la question suivante : « La base de données locale approuve-t-elle la base de données distante ? » La base de données distante peut déchiffrer l'en-tête uniquement si la base de données contient la clé privée correspondante. Pour des raisons de sécurité et d'utilisation optimale des ressources, Service Broker pose ces deux questions en même temps. Le message est structuré de telle façon qu'un destinataire doit être en mesure de répondre par l'affirmative à ces deux questions pour répondre correctement au message.
Le raisonnement à la base de cette stratégie est simple. Si la base de données distante peut déchiffrer un en-tête chiffré à l'aide d'une clé privée dans la base de données locale, cette base de données distante contient la clé publique correspondante : elle approuve donc la base de données locale. Si la base de données distante peut déchiffrer un en-tête chiffré à l'aide d'une clé publique dans la base de données locale, cette base de données distante contient la clé privée correspondante : la base de données locale approuve donc la base de données distante. Tant que les clés privées demeurent secrètes, seules les deux bases de données impliquées dans la conversation peuvent sans problème échanger des messages pour cette conversation.
[!REMARQUE]
Installez uniquement des certificats provenant de sources fiables. Ne distribuez pas les clés privées.
La sécurité du dialogue totale contrôle l'identité dans les deux sens lors du premier échange de messages. Pour les conversations utilisant la sécurité du dialogue anonyme, la base de données à l'origine de la conversation vérifie que la base de données cible contient la clé privée prévue. Toutefois, la base de données cible ne vérifie pas l'identité de l'initiateur. À la place, la base de données qui héberge le service cible doit autoriser le rôle de base de données fixe public à envoyer des messages au service.
Des messages doivent être échangés de part et d'autre pour que la base de données locale puisse considérer l'identité de la base de données distante comme étant confirmée. La vérification ne peut survenir que si la base de données locale contient la clé publique appropriée pour le certificat dans la base de données distante.
Pour le premier message envoyé par chaque partie impliquée dans la conversation, Service Broker contient les en-têtes suivants :
Un en-tête de sécurité d'une paire de services contenant des informations sur les certificats utilisés pour le message. Cet en-tête est signé au moyen de la clé privée pour l'utilisateur propriétaire du service.
Une clé d'échange de clés qui chiffre la clé de session de 128 bits utilisée pour chiffrer le corps du message. Cette clé est chiffrée au moyen de la clé publique pour l'utilisateur distant.
Pour les dialogues utilisant la sécurité anonyme, l'en-tête de sécurité de la paire de services ne fait l'objet d'aucun chiffrement. Par contre, le message lui-même est toujours chiffré, comme l'est la clé d'échange de clés à l'aide de la clé publique pour l'entité de sécurité dans la base de données cible. Dans ce cas, le premier message retourné ne contient ni clé d'échange de clés, ni en-tête de sécurité de paire de services, ni clé de session chiffrée.
Lorsque Service Broker génère lui-même un message en réponse à un message entrant (par exemple, une erreur ou un accusé de réception), le message utilise la clé de session du message entrant sans se préoccuper si le dialogue utilise la sécurité totale ou la sécurité anonyme.
Voir aussi