Vue d’ensemble de la sécurité (Service Broker)

S’applique à :SQL ServerAzure SQL Managed Instance

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 aux services hébergés par différentes instances SQL Server de communiquer en toute sécurité, même si les instances se trouvent sur différents ordinateurs qui n’ont aucune autre relation d’approbation ou où 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. L’approche générale consiste à utiliser des certificats pour établir les informations d’identification d’une base de données distante, puis pour mapper les opérations de la 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 fournit deux types distincts de sécurité : la sécurité de dialogue et la sécurité du transport. Comprendre ces deux types de sécurité et comment ils fonctionnent ensemble vous aide à concevoir, déployer et administrer des applications Service Broker.

• Sécurité du dialogue : chiffre les messages dans une conversation de dialogue individuelle et vérifie les identités des participants dans le dialogue. La sécurité du dialogue fournit également l'authentification à distance et la vérification de l'intégrité des messages. Elle établit une communication authentifiée et chiffrée entre deux services.

• Sécurité du transport : empêche les bases de données non autorisées d’envoyer des messages Service Broker à des bases de données dans l’instance locale. La sécurité du transport établit une connexion réseau authentifiée entre deux bases de données.

Le protocole de dialogue et le protocole broker adjacent sont conçus pour transmettre des messages entre des bases de données, plutôt que d’exécuter des commandes sur une base de données distante. Ce style de communication permet à Service Broker de fournir des services sans avoir besoin que les bases de données partagent des comptes de connexion SQL Server ou des informations d’identification de sécurité Windows.

Pour plus d’informations sur les certificats, consultez CREATE CERTIFICATE.

Scénario de sécurité 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, pour empêcher les tiers de les lire. Pour garantir le niveau de sécurité le plus élevé possible, seuls les fournisseurs qualifiés peuvent 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 :

1. Pour configurer la sécurité du dialogue, l’administrateur d’AdventureWorks2008R2 crée un utilisateur local nommé VendorOutgoing, pour lequel il crée une paire de clés.

2. L'administrateur distribue aux fournisseurs nécessitant un accès au service le certificat contenant la clé publique de la paire de clés.

3. 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.

4. Le fournisseur crée ensuite une paire de clés et envoie des informations sur le nom du service fournisseur et un certificat avec la clé publique de cette paire de clés à l’administrateur AdventureWorks2008R2.

5. L’administrateur d’AdventureWorks2008R2 crée un utilisateur pour chaque fournisseur et associe le certificat du fournisseur à l’utilisateur.

6. L'administrateur crée également une liaison de service distant pour chaque fournisseur, associant le nom du service fournisseur à l'utilisateur créé pour le fournisseur.

Pour remplir l’exigence d’une connexion exclusive des fournisseurs habilités sur la base de données AdventureWorks2008R2, l’administrateur utilise la sécurité du transport Service Broker :

1. Pour configurer la sécurité du transport, l’administrateur AdventureWorks2008R2 crée un certificat dans la master base de données de l’instance SQL Server qui envoie des messages.

2. L’administrateur d’AdventureWorks2008R2 envoie le certificat à chaque fournisseur.

3. Chaque administrateur fournisseur crée un utilisateur dans la master base de données pour posséder le certificat, puis installe le certificat dans l’instance SQL Server qui recevra des messages.

4. L’administrateur du fournisseur crée ensuite un certificat dans la master base de données de l’instance et envoie la clé publique pour cet utilisateur à l’administrateur AdventureWorks2008R2.

5. Enfin, l’administrateur AdventureWorks2008R2 crée un utilisateur dans la master base de données pour posséder chaque certificat de clé publique fournisseur et installe chaque certificat de fournisseur dans la base de données.

En combinant la sécurité du transport et la sécurité du dialogue, l’administrateur d’AdventureWorks2008R2 peut remplir les exigences de sécurité de cette application. Dans ce scénario, les fournisseurs ne peuvent pas se connecter à la base de données AdventureWorks2008R2, et l’administrateur Adventure Works ne peut pas se connecter aux bases de données du fournisseur. Seuls les messages Service Broker peuvent être échangés entre les bases de données.

Contenu connexe

• CRÉER CERTIFICAT (Transact-SQL)
• Protocoles de communication Service Broker