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 Server
La protection étendue permet d’empêcher les attaques de relais d’authentification en s’assurant que le client connaît le service auquel il se connecte.
La protection étendue est une fonctionnalité des composants réseau implémentés par le système d’exploitation. La protection étendue est prise en charge dans Windows.
SQL Server est plus sécurisé lorsque les connexions sont établies à l’aide de la protection étendue.
Liste de contrôle des exigences
Pour que la protection étendue soit effective, toutes les conditions suivantes doivent être remplies :
- Utilisez un pilote client qui prend en charge la liaison de canal.
- Activez le chiffrement TLS sur la connexion afin que le client puisse produire un jeton de liaison de canal (CBT).
- Connectez-vous avec le nom de principal de service approprié (SPN) correspondant à l’instance de SQL Server.
- Utilisez Authentification Windows (NTLM ou Kerberos). La protection étendue ne s’applique pas à l’authentification SQL.
- Activez la protection étendue sur l’instance SQL Server (définie sur Autorisé ou Obligatoire).
Note
Pour obtenir un exemple de chaîne de connexion en C# qui prend en charge la protection étendue, consultez l’exemple chaîne de connexion.
Description de la protection étendue
La protection étendue utilise la liaison de service et la liaison de canal pour empêcher une attaque de relais d’authentification. Dans une attaque de relais d’authentification, un client capable d’effectuer une authentification NTLM (par exemple, Windows Explorer, Outlook, une application SqlClient .NET et d’autres), se connecte à un attaquant (par exemple, un serveur de fichiers CIFS malveillant). L’attaquant utilise les informations d’identification du client pour masquer le client et s’authentifier auprès d’un service (par exemple, une instance du moteur de base de données).
Deux variantes de cette attaque existent :
Lors d’une attaque par leurre, le client se connecte volontairement à l’attaquant.
Dans une attaque d’usurpation d’identité, le client a l’intention de se connecter à un service valide, mais ignore qu’un ou les deux routages DNS et IP sont empoisonnés pour rediriger la connexion vers l’attaquant à la place.
SQL Server prend en charge la liaison de canal et la liaison de service pour réduire ces attaques sur les instances SQL Server.
Liaison de service
La liaison de service permet de contrer les attaques par leurre en exigeant qu’un client envoie un nom principal du service (SPN) signé du service SQL Server auquel il a l’intention de se connecter. Dans le cadre de la réponse d'authentification, le service valide que le SPN reçu dans le paquet correspond à son propre SPN. Si un client est luré pour se connecter à un attaquant, le client inclut le SPN signé de l’attaquant. L’attaquant ne peut pas relayer le paquet pour s’authentifier auprès du service SQL Server réel en tant que client, car il inclurait le SPN de l’attaquant. La liaison de service entraîne un coût unique et négligeable, mais ne traite pas les attaques d’usurpation d’identité. La liaison de service se produit lorsqu'une application cliente n'utilise pas le chiffrement pour se connecter au SQL Server.
Liaison de canal
La liaison de canal établit un canal sécurisé (Schannel) entre un client et une instance du service SQL Server. Le service vérifie l’authenticité du client en comparant le jeton de liaison de canal (CBT) du client spécifique à ce canal avec son propre CBT. L'association de canal protège à la fois contre les attaques de leurre et d'usurpation. Toutefois, il entraîne un coût d’exécution plus important, car il nécessite le chiffrement TLS (Transport Layer Security) de tout le trafic de session. La liaison de canal se produit lorsqu’une application cliente utilise le chiffrement pour se connecter au SQL Server, que le chiffrement soit appliqué par le client ou par le serveur.
Avertissement
SQL Server et Microsoft fournisseurs de données pour SQL Server prennent en charge les protocoles plus anciens, notamment TLS 1.0 et SSL 3.0. Si vous appliquez un autre protocole (tel que TLS 1.2 ou TLS 1.3) en modifiant la couche SChannel du système d’exploitation, vos connexions à SQL Server peuvent échouer. Vérifiez que vous disposez de la dernière version de SQL Server pour prendre en charge TLS 1.2 ou TLS 1.3. Pour plus d’informations, consultez TLS 1.2 et TLS 1.3.
Prise en charge du système d’exploitation
Les liens suivants fournissent plus d’informations sur la façon dont Windows prend en charge la protection étendue :
- Integrated Windows Authentication with Extended Protection (en anglais)
- Sécurité Microsoft Advisory (973811), Extended Protection for Authentication (en anglais)
Support des pilotes
Les seuls pilotes qui prennent en charge la protection étendue sont basés sur Windows :
- Microsoft ODBC Driver pour SQL Server (sur Windows uniquement)
- Microsoft OLE DB Driver pour SQL Server
- System.Data.SqlClient (dans .NET Framework sur Windows)
- Microsoft.Data.SqlClient (sur Windows)
Paramètres
Trois SQL Server paramètres de connexion affectent la liaison de service et la liaison de canal. Vous pouvez configurer ces paramètres à l’aide des Gestionnaire de configuration SQL Server ou WMI. Affichez ces paramètres à l’aide de la facette Paramètres du protocole serveur de la gestion basée sur des stratégies.
Forcer le chiffrement
Les valeurs possibles sont Yes et No. Pour utiliser la liaison de canal, définissez Forcer le chiffrement sur Oui, et tous les clients doivent chiffrer. S’il s’agit de Non, seule la liaison au service est garantie. Forcer le chiffrement est dans les Propriétés de Protocoles pour MSSQLSERVER (onglet Indicateurs) dans le Gestionnaire de configuration SQL Server. À compter de SQL Server 2022 (16.x), vous pouvez également définir Force Strict Encryption sur Oui pour une protection plus forte à l’aide de TDS 8.0. Pour plus d’informations, consultez Configurer le moteur de base de données SQL Server pour le chiffrement des connexions.
Définissez Forcer le chiffrement sur Oui lorsqu’il est utilisé avec la protection étendue.
Protection étendue
Les valeurs possibles sont Off, Autoriséeet Requis. Utilisez la variable Protection étendue pour définir le niveau de protection étendue pour chaque instance SQL Server. Vous trouverez Protection étendue dans Protocoles pour MSSQLSERVER - Propriétés (onglet Avancé) dans Gestionnaire de configuration SQL Server.
Définissez sur Désactivé pour désactiver la protection étendue. L’instance de SQL Server accepte les connexions de n’importe quel client, que le client soit protégé ou non. Off est compatible avec les systèmes d’exploitation plus anciens et non corrigés, mais est moins sécurisé. Utilisez ce paramètre lorsque les systèmes d’exploitation clients ne prennent pas en charge la protection étendue.
Définissez la valeur Autorisée pour exiger une protection étendue pour les connexions à partir de systèmes d’exploitation qui prennent en charge la protection étendue. La protection étendue est ignorée pour les connexions des systèmes d’exploitation qui ne prennent pas en charge la protection étendue. Les connexions provenant d’applications clientes non protégées s’exécutant sur des systèmes d’exploitation clients protégés sont rejetées. Ce paramètre est plus sécurisé que Désactivé, mais ce n’est pas le plus sécurisé. Utilisez ce paramètre dans des environnements mixtes. Certains systèmes d’exploitation prennent en charge la protection étendue, et d’autres ne le font pas.
Définissez la valeur Obligatoire pour accepter uniquement les connexions à partir d’applications protégées sur des systèmes d’exploitation protégés. Ce paramètre est le plus sécurisé, mais les connexions à partir de systèmes d'exploitation ou d'applications qui ne prennent pas en charge la protection étendue ne peuvent pas se connecter à SQL Server.
Pour plus d’informations sur les paramètres recommandés, consultez Activer le chiffrement avec la protection étendue.
SPN NTLM acceptés
Spécifiez la variable SPN NTLM acceptée lorsque plusieurs SPN connaissent un serveur. Lorsqu’un client tente de se connecter au serveur à l’aide d’un SPN valide que le serveur ne connaît pas, la liaison de service échoue. Pour éviter ce problème, spécifiez plusieurs SPN représentant le serveur à l’aide des SPN NTLM acceptés. SPNs NTLM acceptés sont une série de SPN séparés par des points-virgules. Par exemple, pour autoriser les SPN MSSQLSvc/ NomHôte1.Contoso.com et MSSQLSvc/ NomHôte2.Contoso.com, tapez MSSQLSvc/NomHôte1.Contoso.com;MSSQLSvc/NomHôte2.Contoso.com dans la zone SPN NTLM acceptés . La variable a une longueur maximale de 2 048 caractères. Vous trouverez les SPN NTLM acceptés dans les Propriétés de Protocoles pour MSSQLSERVER (onglet Avancé) dans Gestionnaire de configuration SQL Server.
Activer la protection étendue pour le moteur de base de données
Pour utiliser la protection étendue, le serveur et le client doivent disposer d’un système d’exploitation prenant en charge la protection étendue et doivent être activés sur le système d’exploitation. Pour plus d’informations sur l’activation de la protection étendue pour le système d’exploitation, consultez Protection étendue pour l’authentification.
Bien que la protection étendue et NTLMv2 soient activées par défaut dans toutes les versions prises en charge de Windows, la protection étendue n'est pas activée par défaut pour les connexions SQL Server. Vous devez l’activer manuellement dans Gestionnaire de configuration SQL Server.
Pour activer la protection étendue pour les connexions SQL Server, les administrateurs doivent configurer les paramètres dans Gestionnaire de configuration SQL Server. Cette configuration inclut des options pour la liaison de service et la liaison de canal afin d’atténuer différents types d’attaques de relais d’authentification. Pour obtenir des instructions détaillées, reportez-vous à la documentation SQL Server sur la configuration de la protection étendue.
Activer le chiffrement avec la protection étendue
S'applique à : SQL Server
Pour améliorer la sécurité lorsque vous utilisez Authentification Windows, définissez la protection étendue sur Obligatoire et Forcez le chiffrement sur Oui dans Gestionnaire de configuration SQL Server.
Ces paramètres fournissent la configuration la plus sécurisée pour SQL Server.
Note
Dans SQL Server 2022 (16.x) et versions ultérieures, utilisez Force Strict Encryption au lieu de Forcer le chiffrement pour renforcer la sécurité via TDS 8.0.
Mettez à jour vos chaînes de connexion pour prendre en charge ces modifications.
Pour en savoir plus, consultez :
- Se connecter au moteur de base de données avec la protection étendue
- Configurer le moteur de base de données SQL Server pour le chiffrement des connexions
- TDS 8.0
- Se connecter à SQL Server avec le chiffrement strict
Après avoir activé la protection étendue
Après avoir activé la protection étendue sur l’ordinateur serveur, procédez comme suit pour activer la protection étendue :
Accédez à Gestionnaire de configuration SQL Server dans le menu Démarrer Windows.
Développez Configuration réseau SQL Server, puis cliquez avec le bouton droit sur Protocoles pour<InstanceName>. Sélectionnez Propriétés.
Sous l’onglet Avancé , définissez La protection étendue sur le paramètre approprié pour la liaison de canal et la liaison de service.
Si vous le souhaitez, lorsque plusieurs SPN connaissent un serveur, configurez le champ SPN NTLM accepté sous l’onglet Avancé , comme décrit dans la section Paramètres .
Pour la liaison de canal, sous l’onglet Indicateurs, définissez Forcer le chiffrement sur Oui. Ce paramètre est recommandé.
Redémarrez le service de moteur de base de données.
Configurer d’autres composants SQL Server
Pour plus d’informations sur la configuration de Reporting Services, consultez Protection étendue pour l’authentification avec Reporting Services.
Lorsque vous utilisez IIS pour accéder aux données Analysis Services avec une connexion HTTP ou HTTPS, Analysis Services peut tirer parti de la protection étendue fournie par IIS. Pour plus d'informations sur la configuration d'IIS pour utiliser la protection étendue, consultez Configure Extended Protection in IIS 7.5(en anglais).
Exemple de chaîne de connexion
Dans l’exemple C# suivant, le chaîne de connexion utilise Authentification Windows (Integrated Security=true). Le jeton de liaison de canal est activé via le chiffrement TLS (Encrypt=true). La validation de certificat est appliquée avec TrustServerCertificate=false. Bien qu’il ne soit pas obligatoire, HostNameInCertificate il est recommandé et inclus dans cet exemple.
using (var conn = new SqlConnection(
"Server=sql01.contoso.com;" +
"Database=AdventureWorks2025;" +
"Integrated Security=true;" +
"Encrypt=true;" +
"TrustServerCertificate=false;" +
"HostNameInCertificate=sql01.contoso.com;"))
{
conn.Open();
}