Sécurité du dialogue Service Broker
La sécurité du dialogue assure le chiffrement ainsi que l'autorisation et l'authentification distantes d'une conversation particulière. Lorsqu'une conversation utilise la sécurité du dialogue, Service Broker chiffre tous les messages envoyés hors d'une instance SQL Server. Les conversations Service Broker utilisent la sécurité du dialogue par défaut.
Concepts de base de la sécurité du dialogue
La sécurité du dialogue Service Broker permet à votre application d'utiliser l'authentification, l'autorisation ou le chiffrement pour une conversation individuelle entre deux participants (appelée dialogue). Toutes les conversations de dialogues utilisent la sécurité du dialogue par défaut. Lorsque vous entamez un dialogue, vous pouvez l'autoriser explicitement à se poursuivre sans bénéficier de la sécurité du dialogue par l'insertion de la clause ENCRYPTION = OFF dans l'instruction BEGIN DIALOG CONVERSATION. Toutefois, si des liaisons de service distant existent pour le service que la conversation cible, le dialogue utilise alors cette sécurité en dépit de l'utilisation de la clause ENCRYPTION = OFF.
Service Broker chiffre tous les messages envoyés hors d'une instance SQL Server pour tout dialogue utilisant la fonction de sécurité. Les messages qui demeurent dans une instance SQL Server ne sont jamais chiffrés. Dans la sécurité du dialogue, seules la base de données hébergeant le service à l'origine de la conversation et la base de données hébergeant le service cible ont besoin d'un accès aux certificats utilisés pour la sécurité. En d'autres termes, une instance qui transfère des messages n'a pas besoin de la capacité de déchiffrement des messages que l'instance expédie.
Service Broker propose deux types de sécurité du dialogue, la sécurité totale et la sécurité anonyme. Pour les conversations utilisant la sécurité du dialogue, Service Broker fournit l'autorisation distante de mapper la partie distante impliquée dans la conversation à un utilisateur local.
Les messages sont chiffrés sur le réseau lorsque la conversation utilise la sécurité totale ou la sécurité anonyme. Toutefois, les droits en vigueur dans la base de données cible et la stratégie utilisée pour le chiffrement des messages diffèrent légèrement entre les deux méthodes.
Que la conversation utilise la sécurité totale ou la sécurité anonyme importe peu, le corps du message est toujours chiffré à l'aide d'une clé de session symétrique créée automatiquement pour la conversation donnée. Seules les clés sont chiffrées au moyen d'un chiffrement de clé privée utilisant le certificat fourni pour la sécurité du dialogue. Service Broker procède également à une vérification de l'intégrité des messages pour permettre la détection des messages endommagés ou falsifiés.
SQL Server crée une clé de session pour une conversation qui utilise la sécurité du dialogue. Pour protéger la clé de session tandis qu'elle est stockée dans la base de données, Service Broker chiffre cette clé au moyen de la clé principale de la base de données. Si une clé principale de la base de données n'est pas disponible, les messages de la conversation restent dans la file d'attente transmission_status avec une erreur, jusqu'à ce qu'une clé principale de la base de données soit créée, ou jusqu'à l'expiration de la conversation. Ainsi, les deux bases de données engagées dans la conversation doivent contenir des clés principales, même si elles sont hébergées dans une seule et même instance. Si la base de données à l'origine de la conversation ne comporte aucune clé principale, le dialogue est voué à l'échec. Si la base de données cible ne comporte pas de clé principale, les messages demeurent dans la file d'attente de transmission de la base de données qui a engagé la conversation. La dernière erreur de transmission de ces messages indique la raison pour laquelle la remise des messages est impossible. Utilisez le paramètre ENCRYPTION = OFF pour créer un dialogue non chiffré ou recourez à la commande suivante pour créer une clé principale de base de données :
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'
Par souci de commodité, Service Broker autorise les conversations sécurisées demeurant dans une base de données unique à se poursuivre sans tenir compte de la présence ou de l'absence d'une clé principale dans la base de données. Alors que deux bases de données différentes peuvent, au cours d'une conversation, être déplacées sur différentes instances SQL Server, une conversation placée dans une base de données unique demeure toujours dans la même base de données. La conversation peut donc se poursuivre sans problème.
Sécurité totale
La sécurité totale permet d'éviter que le service initiateur n'envoie des messages à une base de données non approuvée et que le service cible ne reçoive des messages provenant d'une base de données également peu fiable. Service Broker chiffre les messages transmis sur le réseau lorsque la conversation bénéficie de la sécurité totale.
La sécurité totale fournit l'identification du service initiateur et du service cible. Ce type de sécurité implique que le service à l'origine de la conversation approuve le service cible et inversement. Ainsi, le service qui commande des pièces auprès d'un fournisseur peut demander à ce que l'application passant la commande approuve le service du fournisseur, et vice-versa que le service du fournisseur approuve l'application chargée de passer la commande.
Les administrateurs de base de données établissent une relation de confiance grâce à l'échange de certificats contenant des clés publiques. Pour bénéficier d'une sécurité du dialogue totale, chaque partie impliquée dans la conversation détient une clé privée pour un utilisateur local et une clé publique pour un utilisateur distant. La base de données qui héberge le service initiateur contient des liaisons de service distant. Ces liaisons définissent l'utilisateur local détenteur du certificat qui correspond à la clé privée dans la base de données distante. Ainsi, les opérations effectuées pour le compte du service initiateur s'exécutent en tant qu'utilisateur désigné dans la base de données cible.
La base de données cible contient un utilisateur détenteur d'un certificat qui correspond à une clé privée appartenant à l'utilisateur propriétaire du service initiateur. Les opérations effectuées pour le compte du service cible s'exécutent donc dans la base de données à l'origine de la conversation, en tant qu'utilisateur propriétaire du service initiateur.
Pour les dialogues bénéficiant de la sécurité totale, chaque partie impliquée dans la conversation crée automatiquement une clé de session. Le premier message envoyé dans chaque sens contient la clé de session chiffrée à l'aide de la clé d'échange de clés, comme décrit dans la rubrique Les certificats et Service Broker.
Sécurité anonyme
La sécurité anonyme permet de protéger le service initiateur contre l'envoi de messages à une base de données non approuvée. Service Broker chiffre les messages transmis sur le réseau lorsque la conversation bénéficie de la sécurité anonyme.
La sécurité anonyme identifie le service cible sur le service initiateur, mais elle ne reconnaît pas le service initiateur sur le service cible.
De fait, une application qui soumet des bons de commande peut vouloir s'assurer que le destinataire d'un bon de commande est bien la cible escomptée, mais la base de données cible peut ne pas vouloir doter de privilèges spéciaux un service fournisseur de bons de commande. Dans ce cas, la base de données hébergeant le service initiateur doit contenir des liaisons de service distant pour ce service cible.
Dans la mesure où le service cible est incapable de vérifier l'identité du service initiateur, les opérations effectuées pour le compte de ce service s'exécutent en tant que membre du rôle de base de données fixe public dans la base de données cible. La base de données cible ne reçoit aucune information concernant l'utilisateur à l'origine de la conversation. Il est par conséquent inutile que cette base de données cible contienne un certificat pour l'utilisateur qui entame la conversation.
Pour les dialogues utilisant la sécurité anonyme, les deux parties impliquées dans la conversation se servent de la clé de session créée automatiquement par la base de données à l'origine de la conversation. La base de données cible ne retourne aucune clé de session à cette base de données.
Contextes de sécurité pour la sécurité du dialogue
L'autorisation distante Service Broker contrôle l'accès à distance sur un service individuel. Elle détermine le contexte de sécurité dans lequel les messages entrants sur une instance SQL Server sont envoyés vers un service.
Service Broker utilise toujours l'autorisation distante pour une conversation sécurisée qui ne se tient pas complètement dans une instance SQL Server. La sécurité du dialogue qui est configurée pour la conversation définit le contexte de sécurité que Service Broker utilise pour l'autorisation distante.
Service Broker n'utilise pas l'autorisation distante lorsque la conversation demeure dans une instance SQL Server, peu importe si cette autorisation distante est configurée ou non. Les entités de sécurité SQL Server sont déjà disponibles sur SQL Server pour une conversation ayant lieu dans une instance, il est donc inutile d'utiliser l'autorisation distante en vue de déterminer le contexte de sécurité approprié pour les opérations de Service Broker. Toutefois, comme décrit plus haut dans cette rubrique, Service Broker crée une clé de session pour que la conversation puisse se poursuivre si jamais une des bases de données est déplacée sur une autre instance au cours de la conversation.
Pour une conversation utilisant la sécurité anonyme, la connexion s'exécute en tant que membre du rôle de base de données fixe public dans la base de données cible, sachant que ce rôle doit disposer de l'autorisation d'envoyer un message au service et qu'aucune autre autorisation dans la base de données ne lui est nécessaire.
Pour une conversation utilisant la sécurité totale, la connexion de chaque partie impliquée dans la conversation agit selon les autorisations de l'utilisateur qui est spécifié dans les liaisons de service distant. Prenons l'exemple de liaisons d'un service distant qui associent le nom de service InventoryService à l'utilisateur InventoryServiceRemoteUser, SQL Server utilise le contexte de sécurité de InventoryServiceRemoteUser afin de placer les messages pour l'application InventoryService dans la file d'attente du service de destination.
Pour une plus grande sécurité, l'utilisateur propriétaire de la clé privée pour un service est généralement un utilisateur différent de celui qui est défini pour l'activation. Un utilisateur détenteur d'une clé privée a uniquement besoin de l'autorisation lui permettant d'ajouter un message à la file d'attente, autrement dit de l'autorisation SEND pour le service qui utilise la file d'attente. En revanche, l'utilisateur spécifié pour l'activation détient les autorisations nécessaires qui lui permettent d'accomplir le travail demandé et d'envoyer une réponse. Dans l'exemple précédent, InventoryServiceRemoteUser n'a besoin d'aucune autorisation pour interroger la table inventory ou pour envoyer un message de retour. L'utilisateur a uniquement besoin de l'autorisation lui permettant d'envoyer un message à la file d'attente utilisée par InventoryService. L'activation de la procédure stockée survient dans une session différente, par le biais des informations d'identification que la file d'attente précise. Il est parfaitement inutile de partager des informations d'identification entre la session qui intègre le message dans la file d'attente et la session qui traite le message.
Création d'un dialogue sécurisé
Lorsque Service Broker établit un dialogue entre deux bases de données, le service initiateur doit établir un contexte utilisateur dans la base de données cible de façon à pouvoir placer les messages dans la file d'attente cible. Ce contexte utilisateur détermine si le service initiateur est autorisé à ouvrir un dialogue avec la cible.
La méthode la plus souple consiste à créer un certificat et des liaisons de service distant. Pour plus d'informations sur la création d'un certificat, consultez CREATE CERTIFICATE (Transact-SQL). Pour plus d'informations sur la création de liaisons de service distant, consultez CREATE REMOTE SERVICE BINDING (Transact-SQL).
Une alternative à la création d'un certificat et de liaisons de service distant consiste à utiliser la sécurité SQL Server pour établir une relation d'approbation entre les deux bases de données. Le propriétaire du service initiateur emprunte l'identité d'un utilisateur du service cible. Ceci peut nécessiter de définir la propriété TRUSTWORTHY de la base de données initiatrice à ON et d'accorder l'autorisation d'authentification à un utilisateur de la base de données cible. Pour plus d'informations, consultez Prolongement de l'emprunt d'identité au niveau de la base de données à l'aide de EXECUTE AS.
[!REMARQUE]
Si le contexte de sécurité n'est pas défini correctement, les messages envoyés sur le dialogue resteront dans la file d'attente sys.transmission_queue sur le service initiateur avec le message d'erreur suivant dans la colonne transmission_status : L'entité de sécurité de serveur '%.*ls' ne peut pas accéder à la base de données '%.*ls' dans le contexte de sécurité actuel.