Partager via

Utilisation du chiffrement sans validation dans SQL Server Native Client

  • Article

S’applique à : SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

Important

SQL Server Native Client (SNAC) n’est pas fourni avec :

  • SQL Server 2022 (16.x) et version ultérieure
  • SQL Server Management Studio 19 et versions ultérieures

SQL Server Native Client (SQLNCLI ou SQLNCLI11) et le fournisseur Microsoft OLE DB pour SQL Server (SQLOLEDB) hérité ne sont pas recommandés dans les nouveaux développements.

Pour les nouveaux projets, utilisez l'un des pilotes suivants :

Pour SQLNCLI qui est fourni en tant que composant du moteur de base de données SQL Server (versions 2012 à 2019), consultez cette exception du cycle de vie du support.

SQL Server chiffre toujours les paquets réseau associés à l’ouverture de session. Si aucun certificat n’a été approvisionné sur le serveur à son démarrage, SQL Server génère un certificat auto-signé qui est utilisé pour chiffrer les paquets d’ouverture de session.

Les certificats auto-signés ne garantissent pas la sécurité. La négociation chiffrée est basée sur NT LAN Manager (NTLM). Il est fortement recommandé de configurer un certificat vérifiable sur SQL Server pour une connectivité sécurisée. Le protocole Transport Security Layer (TLS) peut être sécurisé uniquement avec la validation de certificat.

Les applications peuvent également demander le chiffrement de tout le trafic réseau en utilisant des mots clés de chaîne de connexion ou des propriétés de connexion. Les mots clés sont « Encrypt » pour ODBC et OLE DB lors de l’utilisation d’une chaîne de fournisseur avec IDbInitialize ::Initialize ou « Use Encryption for Data » pour ADO et OLE DB lors de l’utilisation d’une chaîne d’initialisation avec IDataInitialize. Cela peut également être configuré par Gestionnaire de configuration SQL Server à l’aide de l’option Forcer le chiffrement du protocole et en configurant le client pour demander des connexions chiffrées. Par défaut, le chiffrement de tout le trafic réseau pour une connexion requiert la fourniture d'un certificat sur le serveur. En définissant votre client pour qu’il approuve le certificat sur le serveur, vous risquez d’être vulnérable aux attaques de l’intercepteur. Si vous déployez un certificat vérifiable sur le serveur, veillez à définir sur FALSE les paramètres client relatifs à l’approbation du certificat.

Pour plus d’informations sur les mots clés chaîne de connexion, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.

Pour permettre l’utilisation du chiffrement lorsqu’un certificat n’a pas été provisionné sur le serveur, Gestionnaire de configuration SQL Server pouvez être utilisé pour définir à la fois le chiffrement de protocole forcé et les options de certificat de serveur d’approbation. Dans ce cas, le chiffrement utilise un certificat de serveur auto-signé sans validation si aucun certificat vérifiable n'a été fourni sur le serveur.

Les applications peuvent également utiliser le mot clé « TrustServerCertificat » ou son attribut de connexion associé pour garantir que le chiffrement est réalisé. Les paramètres d’application ne réduisent jamais le niveau de sécurité défini par le Gestionnaire de configuration du client SQL Server, mais peuvent le renforcer. Par exemple, si l’option Forcer le chiffrement du protocole n’est pas définie pour le client, une application peut demander elle-même le chiffrement. Pour garantir le chiffrement même si aucun certificat de serveur n'a été fourni, une application peut demander le chiffrement et « TrustServerCertificate ». Toutefois, si« TrustServerCertificate » n'est pas activé dans la configuration client, un certificat de serveur fourni est toujours requis. Le tableau ci-dessous décrit l'ensembles des scénarios :

Paramètre client Forcer le chiffrement du protocole Paramètre client Faire confiance au certificat de serveur Chaîne de connexion/attribut de connexion Encrypt/Use Encryption for Data Chaîne de connexion/attribut de connexion Trust Server Certificate Résultats
Non N/A Non (par défaut) Ignoré Aucun chiffrement ne se produit.
Non N/A Oui Non (par défaut) Le chiffrement se produit uniquement s'il existe un certificat de serveur vérifiable ; sinon, la tentative de connexion échoue.
Non N/A Oui Oui Le chiffrement se produit toujours, mais peut utiliser un certificat de serveur auto-signé.
Oui Non Ignoré Ignoré Le chiffrement se produit uniquement s'il existe un certificat de serveur vérifiable ; sinon, la tentative de connexion échoue.
Oui Oui Non (par défaut) Ignoré Le chiffrement se produit toujours, mais peut utiliser un certificat de serveur auto-signé.
Oui Oui Oui Non (par défaut) Le chiffrement se produit uniquement s'il existe un certificat de serveur vérifiable ; sinon, la tentative de connexion échoue.
Oui Oui Oui Oui Le chiffrement se produit toujours, mais peut utiliser un certificat de serveur auto-signé.

Attention

Le tableau précédent fournit uniquement un guide sur le comportement du système dans différentes configurations. Pour une connectivité sécurisée, assurez-vous que le client et le serveur nécessitent tous les deux un chiffrement. Assurez-vous également que le serveur dispose d’un certificat vérifiable et que le paramètre TrustServerCertificate sur le client est défini sur FALSE.

Fournisseur OLE DB SQL Server Native Client

Le fournisseur OLE DB SQL Server Native Client prend en charge le chiffrement sans validation via l’ajout de la propriété d’initialisation de source de données SSPROP_INIT_TRUST_SERVER_CERTIFICATE, qui est implémentée dans le jeu de propriétés DBPROPSET_SQLSERVERDBINIT. De plus, un nouveau mot clé de chaîne de connexion, « TrustServerCertificate» , a été ajouté. Il accepte les valeurs « oui » ou « non », « non » étant la valeur par défaut. Lors de l'utilisation de composants du service, il accepte les valeurs true ou false ; false étant la valeur par défaut.

Pour plus d'informations sur les améliorations apportées au jeu de propriétés DBPROPSET_SQLSERVERDBINIT, consultez Propriétés d'initialisation et d'autorisation.

Pilote ODBC SQL Server Native Client

Le pilote ODBC SQL Server Native Client prend en charge le chiffrement sans validation via des ajouts aux fonctions SQLSetConnectAttr et SQLGetConnectAttr . SQL_COPT_SS_TRUST_SERVER_CERTIFICATE a été ajouté pour accepter SQL_TRUST_SERVER_CERTIFICATE_YES ou SQL_TRUST_SERVER_CERTIFICATE_NO ; SQL_TRUST_SERVER_CERTIFICATE_NO étant la valeur par défaut. De plus, un nouveau mot clé de chaîne de connexion, « TrustServerCertificate », a été ajouté. Il accepte les valeurs « yes » ou « no » ; «no » étant la valeur par défaut.

Voir aussi

Fonctionnalités de SQL Server Native Client