Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
SQL ServerAzure SQL Managed Instance
La sécurité du dialogue assure le chiffrement ainsi que l'autorisation et l'authentification distantes d'une conversation particulière. Quand une conversation utilise la sécurité du dialogue, Service Broker chiffre tous les messages envoyés en dehors d’une instance SQL Server. Les conversations Service Broker utilisent la sécurité du dialogue par défaut.
Principes de base de la sécurité des boîtes de dialogue
La sécurité du dialogue Service Broker permet à votre application d’utiliser l’authentification, l’autorisation ou le chiffrement pour une conversation de dialogue individuelle (appelée « dialogue »). Toutes les conversations de dialogues utilisent la sécurité du dialogue par défaut. Lorsque vous commencez un dialogue, vous pouvez autoriser explicitement un dialogue à continuer sans sécurité de dialogue en incluant la ENCRYPTION = OFF clause sur l’instruction BEGIN DIALOG CONVERSATION . Toutefois, si une liaison de service distant existe pour le service cible par la conversation, la boîte de dialogue utilise la sécurité même quand ENCRYPTION = OFF.
Pour qu’un dialogue utilise la sécurité, Service Broker chiffre tous les messages envoyés en dehors d’une instance SQL Server. Les messages qui restent 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é. Autrement dit, une instance qui effectue le transfert de messages n’est pas nécessaire pour avoir la possibilité de déchiffrer les messages transférés par l’instance.
Service Broker fournit deux types de sécurité du dialogue : sécurité totale et sécurité anonyme. Pour les conversations utilisant la sécurité du dialogue, Service Broker fournit l’autorisation distante de mapper la partie distante de 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 à 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 lorsqu’elle est stockée dans la base de données, Service Broker chiffre la clé de session avec la clé principale de la base de données. Si une clé principale de base de données n’est pas disponible, les messages de la conversation restent dans l’erreur transmission_status jusqu’à ce qu’une clé principale de base de données soit créée ou jusqu’à ce que la conversation expire. Par conséquent, les deux bases de données qui participent à la conversation doivent contenir des clés principales, même lorsque les bases de données sont hébergées dans la même instance. Si la base de données de lancement ne contient pas de clé principale, la boîte de dialogue échoue. Si la base de données cible ne contient pas de clé principale, les messages restent dans la file d’attente de transmission de la base de données de lancement. La dernière erreur de transmission de ces messages indique la raison pour laquelle les messages ne peuvent pas être remis. Utilisez le ENCRYPTION = OFF paramètre pour créer une boîte de dialogue non chiffrée ou utilisez la commande suivante pour créer une clé principale de base de données :
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>';
Pour des raisons pratiques, Service Broker autorise les conversations sécurisées qui restent dans une même base de données à 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é complète
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 non approuvée. Service Broker chiffre les messages transmis sur le réseau quand la conversation utilise 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. Par exemple, un service qui commande des pièces d’un fournisseur peut exiger que l’application de commande fasse confiance au service du fournisseur et que le service du fournisseur fasse confiance à l’application de 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 Cet utilisateur possède un certificat qui correspond à une clé privée appartenant à l’utilisateur propriétaire du service de lancement. 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 avec une clé d’échange de clés, comme décrit dans 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 quand la conversation utilise la sécurité anonyme.
La sécurité anonyme identifie le service cible au service de lancement, mais n’identifie pas le service de lancement au service cible.
Par exemple, une application qui envoie des commandes de travail peut avoir besoin de garantir que le destinataire de l’ordre de travail est la cible prévue, mais la base de données cible n’a peut-être pas besoin de fournir des privilèges spéciaux pour un service qui envoie des commandes de travail. Dans ce cas, la base de données hébergeant le service initiateur doit contenir des liaisons de service distant pour ce service cible.
Étant donné que le service cible ne peut pas vérifier l’identité du service de lancement, les opérations au nom du service de lancement 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. La base de données cible n’a pas besoin de contenir un certificat pour l’utilisateur qui lance 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 pas de clé de session à la base de données de lancement.
Contextes de sécurité pour la sécurité de boîte de dialogue
L’autorisation distante de Service Broker contrôle l’accès à distance à un service individuel. Elle détermine le contexte de sécurité dans lequel les messages entrants sur une instance SQL Server sont envoyés à un service.
Service Broker utilise toujours l’autorisation à distance pour une conversation sécurisée qui n’a pas lieu entièrement au sein d’une instance SQL Server. La sécurité de boîte de dialogue configurée pour la conversation détermine le contexte de sécurité que Service Broker utilise pour l’autorisation à distance.
Service Broker n’utilise pas l’autorisation à distance lorsque la conversation reste dans une instance SQL Server, même si l’autorisation à distance est configurée. Pour une conversation au sein d’une instance, les principaux de sécurité SQL Server sont déjà disponibles pour SQL Server. Il n’est donc pas nécessaire d’utiliser l’autorisation à distance pour déterminer le contexte de sécurité approprié pour les opérations Service Broker. Cependant, comme décrit plus haut dans cette rubrique, Service Broker crée une clé de session pour que la conversation puisse se poursuivre si 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. Dans ce cas, le rôle de base de données fixe public 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. Par exemple, si une liaison de service distant associe le nom InventoryService du service à l’utilisateur InventoryServiceRemoteUser, SQL Server utilise le contexte de sécurité pour placer les messages de InventoryServiceRemoteUser 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 propriétaire d’une clé privée doit uniquement avoir l’autorisation d’ajouter un message à la file d’attente, c’est-à-dire SEND une autorisation 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 ne nécessite pas d’autorisations pour interroger la table d’inventaire ou envoyer un message de retour. L’utilisateur a uniquement besoin d’autorisations pour envoyer un message à la file d’attente qui InventoryService utilise. 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 empile le message et la session qui traite le message.
Créer une boîte de dialogue sécurisée
Quand 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. Pour plus d’informations sur la création d’une liaison de service distant, consultez CREATE REMOTE SERVICE BINDING.
Notes
Si le contexte de sécurité n’est pas configuré correctement, les messages envoyés dans la boîte de dialogue restent dans le sys.transmission_queue service de lancement avec le message d’erreur suivant dans la transmission_status colonne : The server principal '%.*ls' is not able to access the database '%.*ls' under the current security context.