Quand dois-je sauvegarder la clé principale du service?

Je lis de la documentation et un livre blanc sur le chiffrement transparent des données. Certains documents mentionnent également la sauvegarde de la clé principale du service (pour plus de précision, je ne parle pas de la clé principale de la base de données). Je ne comprends tout simplement pas pourquoi cela est nécessaire, car j'ai pu sauvegarder / restaurer une base de données avec cryptage TDE du serveur A (sauvegarde) vers le serveur B (restauration) sans utiliser de clé principale de service.

Dans quel scénario dois-je restaurer la clé principale du service?

sql-server encryption transparent-data-encryption

— gsharp
source

Êtes-vous sûr d'avoir activé le cryptage sur votre base de données? De plus, avez-vous créé la sauvegarde de la base de données après l'activation de TDE?

— Thomas Stringer

Oui je l'ai fait. J'avais besoin du certificat et de la clé pour le restaurer sur le serveur B. (J'ai fait une sauvegarde du certificat et de la clé). Cependant, sur BI a créé une nouvelle clé principale (pas restauré celui du serveur A) et a pu restaurer ma base de données.

— gsharp

Si vous avez restauré le certificat TDE et la clé privée sur le serveur B, il devrait pouvoir décrypter la base de données TDE. Pouvez-vous pointer vers le document où vous avez lu l'exigence de SMK? Peut-être est-ce quelque chose de plus nuancé ...

— Remus Rusanu

Je suis d'accord avec @RemusRusanu. Le certificat est ce qui motive le cryptage. En ce qui concerne la clé principale du service, il s'agit simplement de meilleures pratiques administratives générales pour sauvegarder cela (quelque chose qui aurait dû être fait initialement) pour DR, je crois.

— Thomas Stringer

@gsharp: qui documente comment sauvegarder le SMK. J'étais intéressé par une documentation qui explique pourquoi la sauvegarde SMK est requise lors du transfert d'une base de données cryptée TDE.

— Remus Rusanu

Réponses:

Si vous parlez de la clé principale du service SQL, il existe un cas rare où vous devez vraiment le restaurer.

Je pense à quelques scénarios où vous devez restaurer le SMK ...

D'une manière ou d'une autre, il a été corrompu.
Vous reconstruisez votre serveur SQL et prévoyez de restaurer chaque base de données, y compris les bases de données système à partir d'une sauvegarde. Généralement, dans ce cas, vous n'aurez peut-être pas besoin de restaurer le SMK si vous utilisez le même compte de service SQL et le même mot de passe.

Dans TDE, vous n'avez pas besoin de restaurer le SMK. Comme tout le monde l'a dit, vous avez juste besoin du certificat et de la clé privée. Vous n'avez pas besoin d'avoir la même clé principale de base de données, également lorsque vous créez le certificat à partir d'une sauvegarde, il est crypté par le DMK de la machine de destination.

— Arijit
source

Lorsque vous déplacez une base de données TDE vers une nouvelle instance, vous devez vous assurer que le certificat approprié (ou la clé asymétrique) se trouve également dans la masterbase de données de la destination . Si vous ne le faites pas, vous recevrez l'erreur suivante:

Msg 33111, niveau 16, état 3, ligne 2 Impossible de trouver le certificat de serveur avec l'empreinte numérique «0xA085414434DB4A36B29 ..................».

Ce n'est pas la clé principale du service qui doit se déplacer avec la sauvegarde de la base de données compatible TDE, mais ce serait le certificat. Par exemple, supposons que vous avez créé votre DEK (clé de cryptage de base de données) avec un certificat masternommé MyTDECert . Sans ce certificat sur votre instance de destination, vous ne pourrez pas restaurer votre base de données.

— Thomas Stringer
source

Oui c'est clair. Ma question est plus pourquoi est-il nécessaire (ou dans quel but) de sauvegarder la clé principale du service. Voir technet.microsoft.com/en-us/library/aa337561

— gsharp

-1

Un cas où vous devez sauvegarder et restaurer le SMK est lorsque vous mettez à niveau une topologie de réplication.

— JYatesDBA
source