Vue d'ensemble de la sécurité (Service Broker)
Service Broker vous permet d'écrire des applications de base de données sécurisées, fiables et extrêmement évolutives. La sécurité Service Broker permet à des services hébergés par différentes instances SQL Server de communiquer en toute sécurité, même lorsque ces instances se trouvent sur différents ordinateurs sans autre relation d'approbation, ou que les ordinateurs source et de destination ne sont pas connectés au même réseau en même temps.
La sécurité Service Broker repose sur les certificats. Le principe général consiste à utiliser des certificats pour établir les informations d'identification d'une base de données distante, puis de mapper les opérations de cette base de données distante à un utilisateur local. Les autorisations de l'utilisateur local s'appliquent à toutes les opérations effectuées pour le compte du service distant. Le certificat est partagé entre les bases de données. Aucune autre information relative à l'utilisateur n'est partagée.
Service Broker propose deux types de sécurité distincts : la sécurité du dialogue et la sécurité du transport. La compréhension de ces deux sécurités et la manière dont elles fonctionnent conjointement vous aide à concevoir, déployer et administrer des applications Service Broker.
Sécurité du dialogue — Elle chiffre les messages dans une conversation de dialogue individuelle et vérifie les identités des participants du dialogue. La sécurité du dialogue fournit également l'autorisation distante et le contrôle d'intégrité des messages. Elle établit une communication authentifiée et chiffrée entre deux services.
Sécurité du transport — Elle empêche les bases de données non autorisées d'envoyer des messages Service Broker aux bases de données de l'instance locale. La sécurité du transport établit une connexion réseau authentifiée entre deux bases de données.
Remarquez que le protocole de dialogue et le protocole de broker adjacent sont conçus sur la transmission de messages entre des bases de données plutôt que sur l'exécution de commandes dans une base de données distante. Ce style de communication permet à Service Broker de fournir des services qui n'obligent pas les bases de données à partager des connexions SQL Server ou des informations d'identification de sécurité Windows.
Pour plus d'informations sur les certificats, consultez CREATE CERTIFICATE (Transact-SQL).
Scénario de sécurité d'Adventure Works Cycles
Dans un scénario de simulation d'entreprise, une société fictive nommée Adventure Works Cycle crée un service Service Broker pour la remise des commandes de pièces aux fournisseurs. Ce service nécessite la mise en place d'une sécurité pour les deux parties en présence, Adventure Works et les fournisseurs. Chaque fournisseur doit pouvoir s'assurer que seuls les clients existants peuvent passer des commandes. Adventure Works, de son côté, doit être assurée que seuls les fournisseurs reconnus comme tels peuvent recevoir des commandes. Les messages échangés entre la base de données AdventureWorks2008R2 et un fournisseur doivent être chiffrés, afin qu'aucun tiers ne puisse en prendre connaissance. Pour garantir un niveau de sécurité maximale, seuls les fournisseurs habilités doivent pouvoir se connecter à la base de données AdventureWorks2008R2.
Pour satisfaire à l'obligation de chiffrement des messages, Adventure Works et les fournisseurs utilisent la sécurité du dialogue Service Broker :
Pour définir la sécurité du dialogue, l'administrateur AdventureWorks2008R2 crée un utilisateur local, appelé VendorOutgoing, pour lequel il crée une paire de clés.
L'administrateur distribue aux fournisseurs nécessitant un accès au service le certificat contenant la clé publique de la paire de clés.
Chaque fournisseur installe le certificat obtenu de Adventure Works Cycles dans sa base de données et crée un utilisateur propriétaire du certificat.
Le fournisseur crée ensuite une paire de clés et envoie à l'administrateur AdventureWorks2008R2 les informations sur le nom du service pour le service fournisseurs, ainsi qu'un certificat contenant la clé publique de cette paire de clés.
L'administrateur AdventureWorks2008R2 crée un utilisateur pour chaque fournisseur et associe le certificat du fournisseur à l'utilisateur.
L'administrateur crée également des liaisons de service distant pour chaque fournisseur qui associe le nom du service fournisseurs à l'utilisateur créé pour le fournisseur.
Pour satisfaire à l'obligation d'une connexion exclusive des fournisseurs habilités à la base de données AdventureWorks2008R2, l'administrateur AdventureWorks2008R2 utilise la sécurité du transport Service Broker :
Pour définir la sécurité du transport, l'administrateur AdventureWorks2008R2 crée un certificat dans la base de données master de l'instance SQL Server qui enverra les messages.
L'administrateur AdventureWorks2008R2 envoie le certificat à chaque fournisseur.
Chaque administrateur fournisseur crée un utilisateur dans la base de données master pour posséder le certificat, puis installe le certificat dans l'instance SQL Server qui recevra les messages.
L'administrateur fournisseur crée ensuite un certificat dans la base de données master de l'instance, puis envoie la clé publique pour cet utilisateur à l'administrateur AdventureWorks2008R2.
Enfin, l'administrateur AdventureWorks2008R2 crée un utilisateur dans la base de données master pour détenir tous les certificats de clés publiques fournisseurs et installer chaque certificat fournisseur dans la base de données.
En combinant la sécurité du transport à la sécurité du dialogue, l'administrateur AdventureWorks2008R2 peut répondre aux conditions de sécurité définies pour cette application. Vous remarquez dans ce scénario que les fournisseurs ne peuvent pas se connecter à la base de données AdventureWorks2008R2 et que l'administrateur Adventure Works ne se connecte pas non plus aux bases de données fournisseurs. Seuls les messages Service Broker peuvent être échangés entre les bases de données.
Voir aussi