Chiffrement et validation de certificat dans Microsoft.Data.SqlClient
SQL Server chiffre toujours les paquets réseau associés à l’ouverture de session. Si aucun certificat n’a été provisionné sur le serveur au démarrage, SQL Server génère un certificat auto-signé qui est utilisé pour chiffrer les paquets de la connexion.
De manière générale, le chiffrement entre un client et un serveur garantit que les données sont uniquement lisibles par le client et le serveur. Une partie importante du processus de chiffrement est la validation du certificat de serveur. La validation du certificat de serveur permet au client de vérifier que le serveur est bien celui qu’il dit être. Le certificat est vérifié pour valider des choses comme l’expiration, la chaîne d’approbation et que le nom dans le certificat correspond à celui du serveur auquel le client se connecte. Pour plus d’informations, consultez Protocole TLS et certificats numériques.
Nous vous recommandons fortement de provisionner un certificat vérifiable sur SQL Server pour sécuriser la connectivité. Le protocole Transport Security Layer (TLS) peut être sécurisé uniquement avec la validation de certificat.
Les applications peuvent demander le chiffrement de tout le trafic réseau en utilisant le mot clé de chaîne de connexion ou la propriété de connexion Encrypt. Par défaut, pour chiffrer tout le trafic réseau d’une connexion, vous devez provisionner 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, vérifiez que les paramètres Encrypt du client sont True et que les paramètres Trust Server Certificate sont False.
Pour activer le chiffrement quand aucun certificat n’a été provisionné sur le serveur, les paramètres de client Encrypt et Trust Server Certificate peuvent être utilisés. Dans ce cas, le chiffrement utilise un certificat de serveur auto-signé sans validation par le client. Cette configuration chiffre la connexion, mais n’empêche pas les appareils entre le client et le serveur d’intercepter la connexion et de proxyser le chiffrement.
Changement de comportement du chiffrement et de la validation de certificat
La version 4.0 de Microsoft.Data.SqlClient introduit des changements cassants dans les paramètres de chiffrement. Encrypt a maintenant True comme valeur par défaut.
La version 2.0 de Microsoft.Data.SqlClient introduit des changements cassants dans le comportement du paramètre Trust Server Certificate. Auparavant, si Encrypt était défini sur False, le certificat de serveur n’était pas validé, quel que soit le paramètre Trust Server Certificate. À présent, le certificat de serveur est validé en fonction du paramètre Trust Server Certificate si le serveur force le chiffrement, même si Encrypt est défini sur False.
Version 4.0
Le tableau suivant décrit le résultat du chiffrement et de la validation pour les paramètres de chiffrement et de certificat :
Paramètre client Encrypt |
Paramètre client Trust Server Certificate |
Paramètre serveur Force encryption |
Résultats |
|---|---|---|---|
| False | False (valeur par défaut) | Non | Seuls les paquets de connexion (LOGIN) sont chiffrés. Le certificat n’est pas validé. |
| False | False (valeur par défaut) | Oui | (Changement de comportement entre la version 1.0 et 2.0) Tout le trafic réseau est chiffré seulement s’il y a un certificat de serveur vérifiable, sinon la tentative de connexion échoue. |
| False | True | Oui | Tout le trafic réseau est chiffré et le certificat n’est pas validé. |
| True (nouvelle valeur par défaut) | False (valeur par défaut) | N/A | La totalité du trafic est chiffré uniquement s’il existe un certificat de serveur vérifiable, sinon la tentative de connexion échoue. |
| True (nouvelle valeur par défaut) | Vrai | N/A | Tout le trafic réseau est chiffré, mais le certificat n’est pas validé. |
| Strict (ajouté dans la version 5.0) | N/A | N/A | Tout le trafic réseau est chiffré avec TDS 8 uniquement s’il y a un certificat de serveur vérifiable, sinon la tentative de connexion échoue. |
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. Vérifiez également que le serveur a un certificat vérifiable et que le paramètre TrustServerCertificate sur le client est défini sur False.
À compter de la version 5.0 de Microsoft.Data.SqlClient, HostNameInCertificate est une nouvelle option de connexion. La validation du certificat de serveur garantit que le nom commun (CN) ou l’autre nom du sujet (SAN) dans le certificat correspond au nom du serveur auquel il est connecté. Dans certains cas, comme les alias DNS, le nom du serveur peut ne pas correspondre au nom CN ou SAN. La valeur de HostNameInCertificate peut être utilisée pour spécifier un CN ou SAN différent dans le certificat de serveur.
Version 2.0
À compter de la version 2.0, quand le serveur force le chiffrement, le client valide le certificat de serveur en fonction du paramètre Trust Server Certificate, quel que soit le paramètre Encrypt.
Le tableau suivant décrit le résultat du chiffrement et de la validation pour les paramètres de chiffrement et de certificat :
Paramètre client Encrypt |
Paramètre client Trust Server Certificate |
Paramètre serveur Force encryption |
Résultats |
|---|---|---|---|
| False (valeur par défaut) | False (valeur par défaut) | Non | Seuls les paquets de connexion (LOGIN) sont chiffrés. Le certificat n’est pas validé. |
| False (valeur par défaut) | False (valeur par défaut) | Oui | (Changement de comportement) Tout le trafic réseau est chiffré seulement s’il y a un certificat de serveur vérifiable, sinon la tentative de connexion échoue. |
| False (valeur par défaut) | True | Oui | Tout le trafic réseau est chiffré et le certificat n’est pas validé. |
| True | False (valeur par défaut) | N/A | La totalité du trafic est chiffré uniquement s’il existe un certificat de serveur vérifiable, sinon la tentative de connexion échoue. |
| True | Vrai | N/A | Tout le trafic réseau est chiffré, mais le certificat n’est pas validé. |
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. Vérifiez également que le serveur a un certificat vérifiable et que le paramètre TrustServerCertificate sur le client est défini sur False.
Version 1.0
Le tableau suivant décrit le résultat du chiffrement et de la validation pour les paramètres de chiffrement et de certificat :
Paramètre client Encrypt |
Paramètre client Trust Server Certificate |
Paramètre serveur Force encryption |
Résultats |
|---|---|---|---|
| False (valeur par défaut) | False (valeur par défaut) | Non | Seuls les paquets de connexion (LOGIN) sont chiffrés. Le certificat n’est pas validé. |
| False (valeur par défaut) | False (valeur par défaut) | Oui | Tout le trafic réseau est chiffré, mais le certificat n’est pas validé. |
| False (valeur par défaut) | True | Oui | Tout le trafic réseau est chiffré et le certificat n’est pas validé. |
| True | False (valeur par défaut) | N/A | La totalité du trafic est chiffré uniquement s’il existe un certificat de serveur vérifiable, sinon la tentative de connexion échoue. |
| True | Vrai | N/A | Tout le trafic réseau est chiffré, mais le certificat n’est pas validé. |
Voir aussi
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour