Le trafic réseau est-il chiffré lors de l'écriture de sauvegardes à distance à l'aide de SQL Server TDE?

Ils disent qu'il n'y a pas de «question stupide», alors voici:

Je comprends que SQL Server Transparent Data Encryption (TDE) crypte les données au repos, de sorte que vos fichiers de base de données (.mdf) et vos fichiers de sauvegarde (.bak) sont cryptés si quelqu'un s'introduit dans votre stockage et vole ces fichiers. Je comprends également que les données sont déchiffrées lors de la lecture à partir du disque afin qu'elles ne soient pas chiffrées en mémoire (en mouvement). Par conséquent, les données demandées par un utilisateur exécutant une requête à distance (sélectionnez * dans SensitiveData) ne seront pas chiffrées lors de leur déplacement sur le réseau et seront donc vulnérables à l'interception.

Donc, en supposant que tout ce qui précède est correct, voici ma question stupide: si mon instance SQL Server se trouve sur l'ordinateur A et que mes sauvegardes de base de données TDE sont écrites sur le stockage sur l'ordinateur distant B, les données de l'opération de sauvegarde sont-elles cryptées lors de leur déplacement depuis l'ordinateur A doit être écrit sur le disque de l'ordinateur B? Je suppose que cela doit l'être (car je suppose que l'opération de chiffrement se produit d'abord sur l'ordinateur A), mais je ne trouve aucune confirmation de cela dans la documentation Microsoft ou sur les blogs. Et de même, lors d'une opération de restauration - quelqu'un devait-il intercepter les données transférées du disque sur l'ordinateur B pour restaurer la base de données sur l'ordinateur A - trouverait-il ces données en mouvement cryptées?

Oui, les sauvegardes sont chiffrées lors du déplacement sur le réseau car les données TDE sont chiffrées sur le disque et l'opération de sauvegarde ne les déchiffre jamais .

Mythes de sauvegarde de Paul Randal :

Mythe 30-09) les sauvegardes lisent les données via le pool de tampons

Non. Le sous-système de sauvegarde ouvre ses propres canaux aux fichiers de base de données pour éviter que les performances ne soient obligées de tout lire dans la mémoire de SQL Server et de revenir sur le périphérique de sauvegarde (et aussi de vider efficacement le pool de tampons dans le processus). Si vous demandez la vérification de la somme de contrôle des pages, il utilise sa propre petite portion de mémoire.

Si les pages étaient chargées dans le pool de mémoire tampon (l'espace mémoire "normal" utilisé par SQL pour mettre en cache la table de base de données et les données d'index), elles devraient être déchiffrées. Mais les sauvegardes ne font pas cela, elles déchargent juste des "extensions" chiffrées brutes (morceaux contigus de 8 pages) vers votre destination de sauvegarde.

J'ai pu obtenir la confirmation de Paul Randal que son commentaire ci-dessus est toujours pertinent pour TDE :

Cela fonctionne exactement de la même manière. Le pool de tampons effectue le chiffrement, puis ajoute une somme de contrôle de page avant d'écrire une page sur le disque. Les sauvegardes ne lisent jamais le pool de tampons. Alors oui, une sauvegarde de la base de données TDE a toujours le cryptage. Les sommes de contrôle de page sont validées, mais par code de sauvegarde, pas par code de pool de mémoire tampon.

En d'autres termes, si vous avez activé les CHECKSUM sur une base de données, ceux-ci sont ajoutés (pendant les opérations d'écriture SQL normales) après le chiffrement. Cela signifie que le processus de sauvegarde peut lire l'étendue brute (chiffrée), valider la somme de contrôle et écrire la sauvegarde, le tout sans déchiffrer les données.

C'est presque certainement la raison pour laquelle (avant SQL 2016), l'activation de la compression de sauvegarde sur la base de données avec TDE n'a rien fait, car les données chiffrées ne sont pas très compressibles :

En effet, lorsque des sauvegardes d'une base de données chiffrée TDE sont effectuées, les pages de la base de données ne sont pas déchiffrées lors de la sauvegarde. Ils sont sauvegardés dans le même état chiffré qu'ils sont normalement, puis compressés . De par sa nature, les données chiffrées sont très uniques, de sorte que la compression des données ne fait pas grand chose contre les données chiffrées.

Pour une opération de restauration, le même principe s'applique. La sauvegarde chiffrée reste chiffrée sur le réseau et est écrite sur le disque du serveur de restauration dans leur état encore chiffré. Ils ne sont décryptés que lorsque la base de données est chargée en mémoire une fois la restauration terminée.

... les données de l'opération de sauvegarde sont-elles chiffrées lorsqu'elles transitent de l'ordinateur A pour être écrites sur le disque de l'ordinateur B?

Oui, il est déchiffré quand il entre dans le pool de tampons et chiffré quand il sort. Dans cette situation, puisque nous écrivons sur le disque, il est d'abord chiffré, puis écrit. Étant donné que les écritures transitent sur le réseau, les données elles-mêmes sont cryptées, mais aucune autre partie du trafic réseau ne l'est.

... pendant une opération de restauration ... trouveraient-ils ces données en mouvement cryptées?

Oui, car la même chose que ci-dessus s'applique mais dans l'ordre inverse. Les données ont été chiffrées sur le disque, sont lues et transférées à l'état chiffré. Ensuite, il arrive à l'instance et est chargé dans le pool de tampons où il n'est pas chiffré comme étape sur le chemin.