Créer des clés symétriques identiques sur deux serveurs
S’applique à : SQL Server Azure SQL Database Azure SQL Managed Instance
Cette rubrique décrit comment créer des clés symétriques identiques sur deux serveurs différents dans SQL Server en utilisant Transact-SQL. Pour pouvoir déchiffrer du texte chiffré, vous devez posséder la clé qui a été utilisée pour le chiffrer. Quand le chiffrement et le déchiffrement interviennent dans une base de données unique, la clé est stockée dans la base de données et demeure disponible, en fonction des autorisations, pour le chiffrement et le déchiffrement. Cependant, lorsque le chiffrement et le déchiffrement se produisent dans des bases de données distinctes ou sur des serveurs séparés, la clé stockée dans l’une des bases de données ne peut pas être utilisée dans l’autre base de données.
Avant de commencer
Limitations et restrictions
Lorsqu'une clé symétrique est créée, elle doit être chiffrée à l'aide de l'un des éléments suivants au moins : certificat, mot de passe, clé symétrique, clé asymétrique ou PROVIDER. La clé peut être soumise à plusieurs chiffrements de chaque type. En d'autres termes, une clé symétrique unique peut être chiffrée à l'aide de plusieurs certificats, mots de passe, clés symétriques et clés asymétriques à la fois.
Lorsqu'une clé symétrique est chiffrée à l'aide d'un mot de passe à la place de la clé publique de la clé principale de base de données, l'algorithme de chiffrement TRIPLE_DES est utilisé. Pour cette raison, les clés créées à l'aide d'un algorithme de chiffrement renforcé, tel qu'AES, sont elles-mêmes sécurisées par un algorithme plus faible.
Sécurité
autorisations
Requiert l'autorisation ALTER ANY SYMMETRIC KEY sur la base de données. Si la clause AUTHORIZATION est spécifiée, l'autorisation IMPERSONATE sur l'utilisateur de base de données ou l'autorisation ALTER sur le rôle d'application est requise. Si le chiffrement s'effectue par certificat ou clé asymétrique, l'autorisation VIEW DEFINITION est requise sur le certificat ou la clé asymétrique. Les connexions Windows, les connexions SQL Server et les rôles d'application sont les seuls à pouvoir posséder des clés symétriques. Les groupes et les rôles ne peuvent pas posséder de clés symétriques.
Utilisation de Transact-SQL
Pour créer des clés symétriques identiques sur deux serveurs différents
Dans l' Explorateur d'objets, connectez-vous à une instance du Moteur de base de données.
Dans la barre d'outils standard, cliquez sur Nouvelle requête.
Créez une clé en exécutant les instructions CREATE MASTER KEY, CREATE CERTIFICATE et CREATE SYMMETRIC KEY suivantes.
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'My p@55w0Rd'; GO CREATE CERTIFICATE [cert_keyProtection] WITH SUBJECT = 'Key Protection'; GO CREATE SYMMETRIC KEY [key_DataShare] WITH KEY_SOURCE = 'My key generation bits. This is a shared secret!', ALGORITHM = AES_256, IDENTITY_VALUE = 'Key Identity generation bits. Also a shared secret' ENCRYPTION BY CERTIFICATE [cert_keyProtection]; GO
Connectez-vous à une instance de serveur distincte, ouvrez une fenêtre de requête différente et exécutez les instructions SQL ci-dessus pour créer la même clé sur le deuxième serveur.
Testez les clés en exécutant d'abord les instructions OPEN SYMMETRIC KEY et SELECT ci-dessous sur le premier serveur.
OPEN SYMMETRIC KEY [key_DataShare] DECRYPTION BY CERTIFICATE cert_keyProtection; GO SELECT encryptbykey(key_guid('key_DataShare'), 'MyData' ) GO -- For example, the output might look like this: 0x2152F8DA8A500A9EDC2FAE26D15C302DA70D25563DAE7D5D1102E3056CE9EF95CA3E7289F7F4D0523ED0376B155FE9C3
Sur le second serveur, collez le résultat de l'instruction SELECT précédente dans le code suivant comme valeur de
@blob
et exécutez le code suivant pour vérifier que la clé dupliquée peut déchiffrer le texte chiffré.OPEN SYMMETRIC KEY [key_DataShare] DECRYPTION BY CERTIFICATE cert_keyProtection; GO DECLARE @blob varbinary(8000); SELECT CONVERT(varchar(8000), decryptbykey(@blob)); GO
Fermez les clés symétriques sur les deux serveurs.
CLOSE SYMMETRIC KEY [key_DataShare]; GO
Modification du chiffrement dans SQL Server 2017 CU2
SQL Server 2016 utilise l’algorithme de hachage SHA1 pour son travail de chiffrement. À compter de SQL Server 2017, SHA2 est utilisé à la place. Cela signifie que des étapes supplémentaires peuvent être nécessaires pour que votre installation de SQL Server 2017 puisse déchiffrer les éléments qui ont été chiffrées par SQL Server 2016. Voici les étapes supplémentaires :
- Vérifiez que votre ordinateur SQL Server 2017 dispose au minimum de la Mise à jour cumulative 2 (CU2).
- Pour obtenir des informations importantes, consultez Mise à jour cumulative 2 (CU2) pour SQL Server 2017.
- Après avoir installé CU2, activez l’indicateur de trace 4631 dans SQL Server 2017 :
DBCC TRACEON(4631, -1);
- L’indicateur de trace 4631 est une nouveauté dans SQL Server 2017. L’indicateur de trace 4631 doit être
ON
globalement avant que vous créiez la clé principale, le certificat ou la clé symétrique dans SQL Server 2017. Ainsi, ces éléments créés peuvent interopérer avec SQL Server 2016 et versions antérieures. Cet indicateur de trace ne doit être activé que temporairement pour rechiffrer des données avec des clés dérivées de SHA2.
- L’indicateur de trace 4631 est une nouveauté dans SQL Server 2017. L’indicateur de trace 4631 doit être
Pour plus d’informations, consultez l’article suivant :