Sécurité du transport de la mise en miroir de bases de données et des groupes de disponibilité AlwaysOn (SQL Server)

Article
06/25/2013

Dans SQL Server 2005 et les versions ultérieures, 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 Groupes de disponibilité AlwaysOn, l'authentification et le chiffrement sont configurés sur le point de terminaison de la mise en miroir. Pour une présentation des points de terminaison de mise en miroir, consultez Point de terminaison de mise en miroir de bases de données (SQL Server).

Dans cette rubrique :

Authentification
Chiffrement des données
Tâches associées

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é pour la mise en miroir de bases de données ou Groupes de disponibilité AlwaysOn par une instance de serveur est une propriété du point de terminaison de la mise en miroir. 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 fonctionnent comme des services sous le même compte de domaine, aucune configuration supplémentaire n'est nécessaire.
Si les instances de SQL Server fonctionnent comme des services sous des comptes de domaine (dans les mêmes domaines ou dans des domaines approuvés), la connexion de chaque compte doit être créée dans master sur chacune des autres instances de serveur, et cette connexion doit avoir des autorisations CONNECTENT sur le point de terminaison.
Si les instances de SQL Server fonctionnent comme un compte de service réseau, la connexion de chaque compte d'ordinateur hôte (DomainName \ ComputerName$) doit être créée dans master sur chacun des autres serveurs, et cette connexion doit avoir des autorisations CONNECTENT 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 un exemple de configuration d'une session de mise en miroir de bases de données utilisant l'authentification Windows, consultez Exemple : configurer la mise en miroir de bases de données à l'aide de l'authentification Windows (Transact-SQL).

Certificats

Dans certaines situations, par exemple lorsque les instances de serveur ne se trouvent pas dans des domaines approuvés ou que SQL Server est en cours d'exécution en tant que service local, l'authentification Windows 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 Autoriser un point de terminaison de mise en miroir de bases de données à utiliser des certificats pour les connexions sortantes (Transact-SQL). 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érons deux instances de serveur, en l'occurrence Serveur_A et Serveur_B. Serveur_A utilise sa clé privée pour chiffrer l'en-tête de connexion avant d'envoyer une demande de connexion à Serveur_B. Serveur_B utilise la clé publique du certificat de Serveur_A pour déchiffrer l'en-tête de connexion. Si l'en-tête déchiffré est correct, Serveur_B sait que l'en-tête a été chiffré par Serveur_A et la connexion est authentifiée. Si l'en-tête déchiffré est incorrect, Serveur_B sait que la demande de connexion n'est pas authentique 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 qui requiert le 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]

Sur les points de terminaison de mise en miroir créés par SQL Server Management Studio, le chiffrement est requis ou désactivé. Pour attribuer au paramètre de chiffrement la valeur SUPPORTED, utilisez l'instruction Transact-SQL ALTER ENDPOINT. Pour plus d'informations, consultez ALTER ENDPOINT (Transact-SQL).

Vous pouvez également contrôler les algorithmes de chiffrement qui peuvent être utilisés par un point de terminaison, en spécifiant une des valeurs ci-dessous pour l'option ALGORITHM dans une instruction CREATE ENDPOINT ou ALTER ENDPOINT :

valeur ALGORITHM	Description
RC4	Indique que le point de terminaison doit utiliser l'algorithme RC4. Il s'agit du paramètre par défaut. [!REMARQUE] L'algorithme RC4 est déconseillé. Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et modifiez dès que possible les applications qui utilisent actuellement cette fonctionnalité. Nous vous recommandons d'utiliser AES.
AES	Indique que le point de terminaison doit utiliser l'algorithme AES.
AES RC4	Indique que les deux points de terminaison négocieront un algorithme de chiffrement avec ce point de terminaison, en donnant la préférence à l'algorithme AES.
RC4 AES	Indique que les deux points de terminaison négocieront un algorithme de chiffrement avec ce point de terminaison, en 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.

[!REMARQUE]

L'algorithme RC4 est uniquement pris en charge pour des raisons de compatibilité descendante. Le nouveau matériel ne peut être chiffré à l'aide de RC4 ou de RC4_128 que lorsque la base de données se trouve dans le 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, le matériel chiffré à l'aide de RC4 ou de RC4_128 peut être déchiffré dans n'importe quel niveau de compatibilité.

Bien que sensiblement plus rapide que AES, RC4 est un algorithme relativement faible, tandis que AES est relativement fort. Par conséquent, nous vous recommandons d'utiliser l'algorithme AES.

Pour plus d'informations sur la syntaxe Transact-SQL permettant de définir le chiffrement, consultez CREATE ENDPOINT (Transact-SQL).