• Article

Chiffrement des connexions à SQL Server

SQL Server prend en charge le protocole SSL (Secure Sockets Layer) et est compatible avec la sécurité du protocole Internet (IPSec, Internet Protocol Security).

SSL (Secure Sockets Layer)

Microsoft SQL Server peut utiliser le protocole SSL (Secure Sockets Layer) pour chiffrer les données échangées sur un réseau entre une instance de SQL Server et une application cliente. Le chiffrement SSL est effectué au sein de la couche de protocole et il est disponible pour tous les clients SQL Server à l'exception des clients de la bibliothèque DB et MDAC 2.53.

SSL peut être utilisé pour la validation de serveur lorsqu'une connexion cliente demande un chiffrement. Si l'instance de SQL Server s'exécute sur un ordinateur auquel un certificat a été attribué à partir d'une autorité de certification publique, son identité et l'instance de SQL Server sont garanties par la chaîne des certificats menant jusqu'à l'autorité racine approuvée. Une telle validation de serveur requiert que l'ordinateur sur lequel l'application cliente s'exécute soit configuré de manière à approuver l'autorité racine du certificat utilisé par le serveur. Le chiffrement avec un certificat autosigné est possible (voir section suivante), mais ce type de certificat n'offre qu'une protection limitée.

Le niveau de chiffrement utilisé par SSL, sur 40 ou 128 bits, dépend de la version du système d'exploitation Microsoft Windows utilisée sur les ordinateurs d'application et de base de données.

L'activation du chiffrement SSL améliore la sécurité des données transmises sur des réseaux entre des instances de SQL Server et des applications. Cependant, l'activation du chiffrement ralentit toutefois les performances. Lorsque tout le trafic entre SQL Server et une application cliente est chiffré au moyen de SSL, le traitement supplémentaire suivant est nécessaire :

  • Un aller-retour réseau supplémentaire est requis au moment de la connexion.

  • Les paquets envoyés de l'application à l'instance de SQL Server doivent être chiffrés par la Net-Library du client et déchiffrés par la Net-Library du serveur.

  • Les paquets envoyés de l'instance SQL Server à l'application doivent être chiffrés par la Net-Library du serveur et déchiffrés par la Net-Library du client.

Configuration de SSL pour SQL Server

La procédure suivante montre comment configurer SSL dans SQL Server.

Pour configurer SSL

  1. Installez un certificat dans le magasin de certificats Windows de l'ordinateur serveur.

  2. Cliquez sur Démarrer, dans le groupe de programmes Microsoft SQL Server, pointez sur Outils de configuration, puis cliquez sur Gestionnaire de configuration SQL Server.

  3. Développez Configuration du réseau SQL Server, cliquez avec le bouton droit sur les protocoles du serveur de votre choix, puis sélectionnez Propriétés.

    Notes

    Il s'agit de la section Protocoles pour<instance_name> du volet gauche de l'outil, et non d'un protocole spécifique du volet droit.

  4. Sous l'onglet Certificat, configurez le Moteur de base de données pour utiliser le certificat.

  5. Sous l'onglet Indicateurs, affichez ou spécifiez l'option de chiffrement du protocole. Le paquet de connexion sera toujours chiffré.

    • Lorsque l'option ForceEncryption pour le Moteur de base de données a la valeur Oui, toutes les communications client/serveur sont chiffrées et les clients ne pouvant pas prendre en charge le chiffrement se voient refuser tout accès.

    • Lorsque l'option ForceEncryption pour le Moteur de base de données a la valeur Non, un chiffrement peut être demandé par l'application cliente mais n'est pas obligatoire.

    • SQL Server doit être redémarré après modification du paramètre ForceEncryption.

    Les informations d'identification (dans le paquet de connexion) qui sont transmises lorsqu'une application cliente se connecte à SQL Server sont toujours chiffrées. SQL Server utilise, le cas échéant, un certificat signé par une autorité de certification approuvée. Si un certificat signé n'est pas installé, SQL Server génère un certificat autosigné lors du démarrage de l'instance, et utilise le certificat autosigné pour chiffrer les informations d'identification. Ce certificat auto-signé permet d'améliorer la sécurité mais il ne fournit pas de protection contre une usurpation d'identité par le serveur. Si le certificat autosigné est utilisé, et si la valeur de l'option ForceEncryption est Oui, toutes les données transmises sur un réseau entre SQL Server et l'application cliente seront chiffrées au moyen d'un certificat autosigné.

    AttentionAttention

    Les connexions SSL chiffrées à l'aide d'un certificat autosigné n'offrent pas de sécurité renforcée. Elles sont vulnérables à des attaques humaines. Ne faites jamais confiance à une connexion SSL utilisant des certificats autosignés dans un environnement de production ou sur des serveurs connectés à Internet.

Conditions requises des certificats

Dans SQL Server, pour charger un certificat SSL, le certificat doit répondre aux conditions suivantes :

  • Le certificat doit figurer soit dans le magasin de certificats de l'ordinateur local, soit dans le magasin de certificats de l'utilisateur actuel.

  • L'heure actuelle du système doit être postérieure à la propriété Valid from du certificat et antérieure à la propriété Valid to du certificat.

  • Le certificat doit être destiné à une authentification serveur. La propriété Enhanced Key Usage du certificat doit spécifier Server Authentication (1.3.6.1.5.5.7.3.1).

  • Le certificat doit être créé à l'aide de l'option KeySpec de AT_KEYEXCHANGE. Habituellement, la propriété d'utilisation de la clé du certificat (KEY_USAGE) comprend aussi un chiffrement de clé (CERT_KEY_ENCIPHERMENT_KEY_USAGE).

  • La propriété Subject du certificat doit indiquer que le nom courant (CN) est le même que le nom d'hôte ou le nom de domaine complet (FQDN, Fully Qualified Domain Name) de l'ordinateur serveur. Si SQL Server s'exécute sur un cluster de basculement, le nom courant doit correspondre au nom d'hôte (ou FQDN) du serveur virtuel, et les certificats doivent être fournis sur tous les nœuds dans le cluster de basculement.

  • SQL Server 2008 R2 et SQL Server 2008 R2 Native Client prennent en charge les certificats de caractères génériques. D'autres clients ne prennent pas en charge les certificats de caractères génériques. Pour plus d'informations, consultez la documentation du client et KB258858.

Conditions requises relatives aux certificats de SQL Server Native Client

Les applications qui utilisent "SERVER=shortname; ENCRYPT=yes" avec un certificat dont les objets spécifient des noms de domaine complet (FQDN) se connectaient dans le passé en raison d'une validation souple. SQL Server 2008 R2 améliore la sécurité en appliquant une correspondance exacte des objets pour les certificats. Les applications qui reposent sur une validation souple doivent entreprendre l'une des actions suivantes :

  • Utiliser le nom de domaine complet dans la chaîne de connexion.

    • Cette option ne requiert pas la recompilation de l'application si le mot clé SERVER de la chaîne de connexion est configuré à l'extérieur de l'application.

    • Cette option ne fonctionne pas pour les applications dont les chaînes de connexion sont codées en dur.

    • Cette option ne fonctionne pas pour les applications qui utilisent la mise en miroir de bases de données puisque le serveur en miroir répond avec un nom ordinaire.

  • Ajouter un alias pour le nom court à mapper sur le nom de domaine complet.

    • Cette option fonctionne même pour les applications dont les chaînes de connexion sont codées en dur.

    • Cette option ne fonctionne pas pour les applications qui utilisent la mise en miroir de bases de données puisque les fournisseurs ne recherchent pas les alias pour les noms des serveurs partenaires de récupération reçus.

  • Faire en sorte qu'un certificat soit émis pour le nom court.

    • Cette option fonctionne pour toutes les applications.

Chiffrement sur un cluster

Si vous souhaitez utiliser le chiffrement avec un cluster de basculement, vous devez installer le certificat du serveur avec le nom DNS complet de l'instance en cluster de basculement sur tous les nœuds du cluster de basculement. Exemple : si vous avez un cluster avec deux nœuds, nommés test1.votre société.com et test2.votre société.com et une instance cluster de basculement de SQL Server intitulée fcisql, vous devez obtenir un certificat pour fcisql.votre société.com et l'installer sur les deux nœuds. Pour configurer le chiffrement du cluster de basculement, vous pouvez ensuite activer la case à cocher Forcer le chiffrement dans la zone de propriétés Protocoles pour <serveur> de Configuration du réseau SQL Server.

Internet Protocol Security (IPSec)

Les données de SQL Server peuvent être chiffrées pendant la transmission à l'aide du protocole IPSec. IPSec est fourni par les systèmes d'exploitation client et serveur et ne nécessite aucune configuration de SQL Server. Pour plus d'informations sur IPSec, consultez la documentation Windows ou de la mise en réseau.