Sécurité du transport dans les groupes de disponibilité et la mise en miroir de bases de données

S'applique à :SQL Server

La sécurité du transport implique l'authentification et, éventuellement, le chiffrement des messages échangés entre les bases de données. Pour la mise en miroir de bases de données et les groupes de disponibilité Always On, l’authentification et le chiffrement sont configurés sur le point de terminaison de mise en miroir de bases de données. Pour une présentation des points de terminaison de mise en miroir de bases de données, consultez le point de terminaison de mise en miroir de bases de données (SQL Server).

Authentification

L'authentification est le processus qui permet de vérifier qu'un utilisateur est la personne qu'il prétend être. Les connexions entre les points de terminaison de mise en miroir de bases de données requièrent une authentification. Les demandes de connexion éventuellement formulées par un partenaire ou un témoin doivent être authentifiées.

Le type d’authentification utilisé par une instance de serveur pour la mise en miroir de bases de données ou les groupes de disponibilité Always On est une propriété du point de terminaison de mise en miroir de bases de données. Deux types de sécurité de transport sont disponibles pour les points de terminaison de mise en miroir de bases de données : l’authentification Windows (SSPI, Security Support Provider Interface) et l’authentification basée sur les certificats.

Authentification Windows

Avec l'authentification Windows, chaque instance de serveur se connecte à l'autre partie à l'aide des informations d'identification Windows du compte d'utilisateur Windows sous lequel le processus est en cours d'exécution. L'authentification Windows peut nécessiter une configuration manuelle des comptes de connexion, comme suit :

  • Si les instances de SQL Server s’exécutent comme des services sous le même compte de domaine, aucune configuration supplémentaire n’est nécessaire.

  • Si les instances de SQL Server s’exécutent en tant que services sous différents comptes de domaine (dans les mêmes domaines ou approuvés), la connexion de chaque compte doit être créée master sur chacune des autres instances de serveur, et cette connexion doit recevoir CONNECT des autorisations sur le point de terminaison.

  • Si les instances de SQL Server s’exécutent en tant que compte de service réseau, la connexion de chaque compte d’ordinateur hôte (<domain-name>\<computer-name>$) doit être créée master sur chacun des autres serveurs, et cette connexion doit recevoir CONNECT des autorisations sur le point de terminaison. En effet, une instance de serveur s'exécutant sous le compte de service réseau s'authentifie à l'aide du compte de domaine de l'ordinateur hôte.

Remarque

Pour obtenir un exemple de configuration d’une session de mise en miroir de bases de données à l’aide de Windows Authentication, consultez l’exemple : Configurer la mise en miroir de bases de données à l’aide de Authentification Windows.

Certificats

Dans certains cas, par exemple lorsque les instances de serveur ne sont pas dans des domaines approuvés ou lorsque SQL Server s'exécute en tant que service local, Windows l'authentification n'est pas disponible. Dans ces cas, ce ne sont pas des informations d'identification utilisateur, mais des certificats, qui sont nécessaires pour authentifier les demandes de connexion. Le point de terminaison de mise en miroir de chaque instance de serveur doit être configuré avec son propre certificat créé localement.

La méthode de chiffrement est établie lorsque le certificat est créé. Pour plus d’informations, consultez La mise en miroir de bases de données - Utiliser des certificats pour les connexions sortantes. Gérez avec précaution les certificats que vous utilisez.

Une instance de serveur utilise la clé privée de son propre certificat pour établir son identité lors de la configuration d'une connexion. L'instance de serveur qui reçoit la demande de connexion utilise la clé publique du certificat de l'émetteur pour authentifier l'identité de celui-ci. Par exemple, considérez deux instances de serveur, Server_A et Server_B. Server_A utilise sa clé privée pour chiffrer l’en-tête de connexion avant d’envoyer une demande de connexion à Server_B. Server_B utilise la clé publique du certificat de Server_A's pour déchiffrer l’en-tête de connexion. Si l’en-tête déchiffré est correct, Server_B sait que l’en-tête a été chiffré par Server_A, et que la connexion est authentifiée. Si l’en-tête déchiffré est incorrect, Server_B sait que la demande de connexion est inauthentique et refuse la connexion.

Chiffrement des données

Par défaut, un point de terminaison de mise en miroir de bases de données requiert le chiffrement des données envoyées via les connexions de mise en miroir. Dans ce cas, le point de terminaison ne peut se connecter qu'aux points de terminaison utilisant également le chiffrement. Sauf si vous pouvez garantir que votre réseau est sécurisé, il est recommandé d'imposer le chiffrement des connexions de mise en miroir de bases de données. Toutefois, vous pouvez désactiver le chiffrement ou le rendre disponible sans qu'il soit nécessaire. Si le chiffrement est désactivé, les données ne sont jamais chiffrées et le point de terminaison ne peut pas se connecter à un point de terminaison nécessitant un chiffrement. Si le chiffrement est pris en charge, les données ne sont chiffrées que si le point de terminaison opposé prend en charge ou requiert le chiffrement.

Remarque

Les points de terminaison de mise en miroir créés par SQL Server Management Studio sont créés avec un chiffrement obligatoire ou désactivé. Pour modifier le paramètre SUPPORTEDde chiffrement, utilisez l’instruction ALTER ENDPOINT Transact-SQL. Pour plus d’informations, consultez ALTER ENDPOINT.

Si vous le souhaitez, vous pouvez contrôler les algorithmes de chiffrement qui peuvent être utilisés par un point de terminaison, en spécifiant l’une des valeurs suivantes pour l’option ALGORITHM dans une instruction ou CREATE ENDPOINT une ALTER ENDPOINT instruction :

ALGORITHM Valeur Descriptif
RC4 (valeur par défaut) Indique que le point de terminaison doit utiliser l'algorithme RC4.

Avertissement : L’algorithme RC4 est déconseillé. Cette fonctionnalité sera supprimée dans une version future de SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Nous vous recommandons d'utiliser AES.
AES (recommandé) Indique que le point de terminaison doit utiliser l'algorithme AES.
AES RC4 Spécifie que les deux points de terminaison négocient pour un algorithme de chiffrement avec ce point de terminaison donnant la préférence à l’algorithme AES.
RC4 AES Spécifie que les deux points de terminaison négocient pour un algorithme de chiffrement avec ce point de terminaison donnant la préférence à l’algorithme RC4.

Si les points de terminaison se connectant spécifient les deux algorithmes mais dans des ordres différents, le point de terminaison acceptant la connexion a le dernier mot.

Caution

Bien que sensiblement plus rapide que AES, RC4 est un algorithme relativement faible, tandis que AES est relativement fort. Par conséquent, vous devez utiliser l’algorithme AES.

L'algorithme RC4 est uniquement pris en charge pour des raisons de compatibilité descendante. Les données ne peuvent être chiffrées qu’à l’aide de RC4 ou RC4_128 lorsque la base de données est au niveau de compatibilité 90 ou 100 (non recommandé). Utilisez à la place un algorithme plus récent, tel qu'un des algorithmes AES. Dans SQL Server 2012 (11.x) et versions ultérieures, les données chiffrées à l’aide de RC4 ou RC4_128 peuvent être déchiffrées dans n’importe quel niveau de compatibilité.

Pour plus d’informations sur la syntaxe Transact-SQL pour spécifier le chiffrement, consultez CREATE ENDPOINT.

Configurer la sécurité du transport pour les points de terminaison de mise en miroir de bases de données

Contenu connexe

  • Last updated on