Les certificats et Service Broker
Cette rubrique décrit la façon dont SQL Server utilise les certificats pour la sécurité distante de Service Broker. Ce type de sécurité Service Broker fait référence à des opérations impliquant plusieurs instances SQL Server, lorsque ces opérations utilisent soit la sécurité du dialogue soit la sécurité du transport.
Vue d'ensemble
La sécurité distante de Service Broker établit une correspondance entre une opération située en dehors d'une instance et une entité de sécurité de base de données SQL Server. L'opération se poursuit ensuite par des vérifications d'autorisations SQL Server classiques dans le contexte de sécurité de cette entité de sécurité. Ainsi, lorsqu'un message arrive pour une conversation utilisant la sécurité du dialogue, Service Broker exploite les informations contenues dans le message pour identifier une entité de sécurité de base de données servant à la partie distante impliquée dans la conversation. SQL Server vérifie ensuite que cette entité de sécurité dispose des autorisations qui lui permettent de se connecter à la base de données hébergeant le service de destination et d'envoyer un message à ce service.
SQL Server utilise des certificats pour vérifier l'identité d'une base de données distante et identifier l'entité de sécurité de la base de données locale pour l'opération. Ainsi, l'installation d'un certificat dans SQL Server constitue une déclaration d'approbation dans la base de données qui conserve la clé privée pour le certificat. Gérez avec précaution les certificats que vous installez et les liaisons de service distant que vous créez.
.gif "Remarque relative à la sécurité") Remarque relative à la sécurité |
|---|
Installez uniquement des certificats provenant de sources fiables. Ne distribuez pas les clés privées. |
Pour vérifier l'identité d'un serveur distant, SQL Server doit recevoir des informations déchiffrables à l'aide de la clé publique contenue dans un certificat appartenant à une entité de sécurité de base de données locale. Si SQL Server réussit à déchiffrer les informations, la base de données distante contient bien la clé privée correspondant à la clé publique du certificat local. Une fois son identité vérifiée par SQL Server, la base de données distante peut agir en utilisant les autorisations de l'entité de sécurité de la base de données locale.
Concernant la sécurité du transport, les bases de données doivent instaurer des relations d'approbation entre elles. La sécurité du transport peut utiliser au choix des certificats ou l'authentification Windows. Pour plus d'informations sur la sécurité du transport, consultez Sécurité du transport Service Broker.
Concernant la sécurité du dialogue, l'initiateur du dialogue doit faire confiance à la cible, mais aussi être en mesure de vérifier son identité. Toutefois, la cible peut éventuellement autoriser des connexions d'initiateurs ne fournissant aucune information d'identification. Dans ce cas, ces initiateurs utilisent le rôle public dans la base de données hébergeant le service cible. La sécurité du dialogue utilise toujours des certificats. Pour plus d'informations sur la sécurité du dialogue, consultez Sécurité du dialogue Service Broker.
SQL Server ne fournit aucune méthode automatisée pour configurer la sécurité Service Broker à l'aide de certificats.
Conditions requises des certificats
Un certificat doit remplir les conditions suivantes pour intégrer la sécurité Service Broker :
le module clé doit être inférieur à 2048 ;
la longueur totale du certificat doit être inférieure à 32 kilo-octets (Ko) ;
un nom d'objet doit être spécifié ;
des dates de validité doivent être spécifiées ;
la longueur de la clé doit être un multiple de 64 octets.
Un certificat auto-signé créé à l'aide de l'instruction Transact-SQL CREATE CERTIFICATE satisfait aux conditions précédemment énoncées, ce qui n'est pas forcément le cas des certificats chargés à partir d'un fichier.
Lorsque le certificat est stocké dans SQL Server, il doit être chiffré à l'aide de la clé principale de la base de données. Service Broker ne peut pas utiliser les certificats uniquement chiffrés à l'aide d'un mot de passe. De même, la clé principale de la base de données doit être chiffrée au moyen de la clé du service pour l'instance sinon Service Broker ne peut pas ouvrir la clé principale.
Pour que SQL Server puisse engager une conversation à l'aide d'un certificat, ce certificat doit être marqué comme ACTIVE FOR BEGIN_DIALOG. C'est le cas par défaut. Toutefois, vous pouvez choisir de désactiver temporairement un certificat tandis que vous mettez à jour la configuration de la sécurité pour un service. Pour plus d'informations, consultez CREATE CERTIFICATE (Transact-SQL) et ALTER CERTIFICATE (Transact-SQL).