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
Cet article explique comment SQL Server utilise des certificats pour la sécurité à distance 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 un principal 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 ce principal de base de données. Par exemple, lorsqu’un message arrive sur une conversation qui utilise la sécurité du dialogue, Service Broker utilise les informations contenues dans le message pour identifier le principal de base de données pour le côté distant de la conversation. SQL Server vérifie ensuite que le principal a l’autorisation de se connecter à la base de données qui héberge le service de destination et d’envoyer un message au service de destination.
SQL Server utilise des certificats pour vérifier l’identité d’une base de données distante et identifier le principal de base de données local 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.
Notes
Installez uniquement des certificats provenant de sources fiables. Ne distribuez pas de clés privées.
Pour vérifier l’identité d’un serveur distant, SQL Server doit recevoir des informations qui peuvent être déchiffrées avec la clé publique dans un certificat appartenant à un principal de base de données local. 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 que SQL Server vérifie l’identité d’une base de données distante, la base de données distante peut agir avec les autorisations du principal 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 Service Broker Transport Security.
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 autoriser les connexions des initiateurs qui ne fournissent pas d’informations 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é des boîtes de dialogue, consultez sécurité de boîte de dialogue Service Broker.
SQL Server ne fournit pas de méthodes automatisées pour la configuration de la sécurité service Broker par le biais de certificats.
Conditions requises pour les certificats
Un certificat doit respecter les conditions suivantes à utiliser pour 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éé avec l’instruction CREATE CERTIFICATE Transact-SQL répond aux exigences de la liste précédente. Les certificats chargés à partir d’un fichier peuvent ne pas répondre à ces exigences.
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 de certificats chiffrés uniquement avec 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 utilise un certificat pour commencer une conversation, le certificat doit être marqué 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 et ALTER CERTIFICATE.