Notes
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.
Cet article décrit des détails sur le protocole TLS (Transport Layer Security) et les certificats numériques.
TLS (Transport Layer Security)
Les protocoles TLS et SSL se trouvent entre la couche de protocole d’application et la couche TCP/IP, où ils peuvent sécuriser et envoyer des données d’application à la couche de transport. Les protocoles TLS/SSL utilisent des algorithmes d’une suite de chiffrement pour créer des clés et chiffrer des informations. Le client et le serveur négocient la version du protocole et la suite de chiffrement à utiliser pour le chiffrement pendant la phase initiale de connexion (pré-connexion) de l’établissement de la connexion. La version de TLS la plus élevée prise en charge est toujours choisie dans la négociation TLS. Pour vérifier les versions des protocoles TLS prises en charge par différentes versions des systèmes d’exploitation Windows, consultez Protocoles dans TLS/SSL (SSP Schannel) . Plusieurs vulnérabilités connues ont été signalées par rapport au protocole SSL et aux versions antérieures de TLS. Nous vous recommandons de procéder à la mise à niveau vers TLS 1.2 pour une communication sécurisée.
SQL Server peut utiliser TLS pour chiffrer des données transmises sur un réseau entre une instance de SQL Server et une application cliente. TLS utilise un certificat pour implémenter le chiffrement.
L’activation du chiffrement TLS améliore la sécurité des données transmises sur des réseaux entre des instances de SQL Server et des applications. Toutefois, lorsque tout le trafic entre SQL Server et une application cliente est chiffré à l’aide de TLS, le traitement supplémentaire suivant est nécessaire :
- Un aller-retour réseau supplémentaire est nécessaire au moment de la connexion.
- Les paquets envoyés de l’application à l’instance de SQL Server doivent être chiffrés par la pile TLS cliente et déchiffrés par la pile TLS du serveur.
- Les paquets envoyés de l’instance de SQL Server à l’application doivent être chiffrés par la pile TLS du serveur et déchiffrés par la pile TLS cliente.
Important
À compter de SQL Server 2016 (13.x), ssl (Secure Sockets Layer) a été supprimé. Utilisez TLS (TLS 1.2 est recommandé) à la place. Pour plus d’informations, consultez la prise en charge de TLS 1.2 pour Microsoft SQL Server. SQL Server 2022 introduit la prise en charge de TLS 1.3. Pour plus d’informations, consultez Prise en charge de TLS 1.3. Si aucun protocole correspondant n’existe entre le client et l’ordinateur serveur, vous pouvez exécuter l’erreur décrite dans Une connexion existante a été fermée de force par l’hôte distant.
Vue d’ensemble du certificat numérique
Les certificats numériques sont des fichiers électroniques fonctionnant comme les mots de passe en ligne permettant de vérifier l'identité d'un utilisateur ou d'un ordinateur. Ils sont utilisés pour créer le canal chiffré utilisé pour les communications clientes. Un certificat est une déclaration numérique émise par une autorité de certification qui garantit l’identité du titulaire du certificat et permet aux parties de communiquer en toute sécurité à l’aide du chiffrement.
Les certificats numériques fournissent les services suivants :
- Chiffrement : ils aident à protéger les données échangées contre le vol ou la falsification.
- Authentification : Ils vérifient que leurs titulaires (personnes, sites web, et même périphériques réseau tels que les routeurs) sont vraiment qui ou ce qu’ils prétendent être. En règle générale, l'authentification est à sens unique, où la source vérifie l'identité de la cible, mais l'authentification Mutual TLS est également possible.
Un certificat contient une clé publique qu'il attache à l'identité de la personne, de l'ordinateur ou du service contenant la clé privée correspondante. Les clés publiques et privées permettent au client et au serveur de chiffrer les données avant de les transmettre. Pour les utilisateurs de Windows et les ordinateurs et services utilisant ce programme, l'approbation d'une autorité de certification est établie lorsque le certificat racine est défini dans le magasin de certificats racines approuvés et que le certificat contient un chemin d'accès de certification valide. Un certificat est considéré comme valide s’il n’a pas été révoqué (il n’est pas dans la liste de révocation de l’autorité de certification ou CRL) ni expiré.
Les trois principaux types de certificats numériques sont décrits dans le tableau suivant :
| Catégorie | Descriptif | Avantages | Inconvénients |
|---|---|---|---|
| Certificat auto-signé | Le certificat est signé par l’application qui l’a créée ou créée à l’aide de New-SelfSignedCertificate. | Coût (gratuit) | - Le certificat n’est pas automatiquement approuvé par les ordinateurs clients et les appareils mobiles. Le certificat doit être ajoutée manuellement au magasin de certificats racine approuvés sur tous les ordinateurs client et appareils, mais certains appareils mobiles ne permettent pas de modifier le magasin de certificats racine approuvés. - Tous les services ne fonctionnent pas avec des certificats auto-signés. - Difficile d’établir une infrastructure pour la gestion du cycle de vie des certificats. Par exemple, les certificats auto-signés ne peuvent pas être révoqués. |
| Certificat émis par une autorité de certification interne | Le certificat est délivré par une infrastructure à clé publique dans votre organisation. Les services de certificat (AD SC) Active Directory constituent un exemple. Pour plus d'informations, reportez-vous à la rubrique Vue d'ensemble des services de certificats Active Directory. | - Permet aux organisations d’émettre leurs propres certificats. - Moins coûteux que les certificats d’une autorité de certification commerciale. |
- Complexité accrue du déploiement et de la maintenance de l’infrastructure à clé publique. - Le certificat n’est pas automatiquement approuvé par les ordinateurs clients et les appareils mobiles. Le certificat doit être ajoutée manuellement au magasin de certificats racine approuvés sur tous les ordinateurs client et appareils, mais certains appareils mobiles ne permettent pas de modifier le magasin de certificats racine approuvés. |
| Certificat émis par une autorité de certification commerciale | Le certificat est acheté auprès d'une autorité de certification commerciale approuvée. | Le déploiement de certificats est simplifié, car tous les clients, appareils et serveurs approuvent automatiquement les certificats. | Coût. Vous devez réaliser une planification afin de réduire le nombre de certificats requis. |
Pour prouver l'identité d'un détenteur de certificat, le certificat doit identifier précisément le titulaire du certificat sur d'autres clients, appareils ou serveurs. Les trois méthodes de base à suivre sont décrites dans le tableau suivant :
| Méthode | Descriptif | Avantages | Inconvénients |
|---|---|---|---|
| Correspondance d'objet de certificat | Le champ Subject du certificat contient le nom commun de l'hôte. Par exemple, le certificat qui est émis à www.contoso.com peut être utilisé pour le site web https://www.contoso.com. |
- Compatible avec tous les clients, appareils et services. -Cloisonnement. La révocation du certificat pour un hôte n'a pas d'incidence sur les autres hôtes. |
- Nombre de certificats requis. Vous pouvez uniquement utiliser le certificat de l'hôte spécifié. Par exemple, vous ne pouvez pas utiliser le www.contoso.com certificat pour ftp.contoso.com, même lorsque les services sont installés sur le même serveur.-Complexité. Sur un serveur web, chaque certificat requiert sa propre liaison d'adresse IP. |
| Correspondance d'autre nom de l'objet (SAN) de certificat | En plus du champ Subject, le champ Subject Alternative Name du certificat contient une liste de plusieurs noms d'hôte. Par exemple:www.contoso.comftp.contoso.comftp.eu.fabrikam.net |
-Commodité. Vous pouvez utiliser le même certificat pour plusieurs hôtes dans différents domaines distincts. - La plupart des clients, des appareils et des services prennent en charge les certificats SAN. - Audit et sécurité. Vous savez exactement quels hôtes sont en mesure d'utiliser le certificat SAN. |
- Plus de planification requise. Vous devez fournir la liste des hôtes lorsque vous créez le certificat. - Manque de compartimentation. Vous ne pouvez pas révoquer de manière sélective des certificats pour certains des hôtes spécifiés sans avoir une incidence sur l'ensemble des hôtes du certificat. |
| Correspondance de certificat générique | Le champ Subject du certificat contient le nom commun comme caractère générique (*) ainsi qu’un domaine unique ou un sous-domaine. Par exemple, *.contoso.com ou *.eu.contoso.com. Le *.contoso.com certificat générique peut être utilisé pour :www.contoso.comftp.contoso.commail.contoso.com |
Flexibilité. Vous n’avez pas besoin de fournir une liste d’hôtes lorsque vous demandez le certificat, et vous pouvez utiliser le certificat sur n’importe quel nombre d’hôtes dont vous pourriez avoir besoin à l’avenir. | - Vous ne pouvez pas utiliser de certificats génériques avec d’autres domaines de niveau supérieur (TLD). Par exemple, vous ne pouvez pas utiliser le certificat générique *.contoso.com pour les hôtes *.contoso.net.- Vous pouvez uniquement utiliser des certificats génériques pour les noms d’hôtes au niveau où s’applique le caractère générique. Par exemple, vous ne pouvez pas utiliser le *.contoso.com certificat pour www.eu.contoso.com. Vous ne pouvez pas utiliser le certificat *.eu.contoso.com pour www.uk.eu.contoso.com.- Les anciens clients, appareils, applications ou services peuvent ne pas prendre en charge les certificats génériques. - Les wildcards ne sont pas disponibles avec les certificats de validation étendue (EV). - L’audit et le contrôle prudents sont requis. Si le certificat générique n'est pas fiable, cela affecte tous les hôtes du domaine spécifié. |