Les sauvegardes chiffrées sont-elles une bonne idée?


23

Je suis en charge d'un petit ensemble d'ordinateurs portables et je voulais obtenir une sorte de sauvegardes automatisées à distance (via WAN); les sauvegardes iraient sur un disque RAID. Parce que nous n'avons pas vraiment de coffre-fort sécurisé pour contenir tous nos disques (si quelqu'un le voulait, il pourrait briser les fenêtres et prendre nos disques), j'envisageais d' utiliser le cryptage, peut-être quelque chose comme la duplicité ( http: //duplicity.nongnu .org / ). J'en ai discuté avec quelques-uns des développeurs, mais ils semblent convaincus que le chiffrement est une mauvaise idée car un seul mauvais bit pourrait ruiner tout le bloc. Cependant, je n'ai pas entendu parler d'histoires d'horreur où cela s'est produit. Quelle est votre opinion? Les avantages l'emportent-ils sur les risques du chiffrement?


3
En tant que personne qui vient de perdre un tas de données en raison d'une sauvegarde cryptée où j'étais sûr de me souvenir du mot de passe, je vais m'abstenir de répondre. Les clés de cryptage ne sont pas une blague, la mémoire à long terme est une chose amusante.
Joris

5
@Joris - C'est pourquoi il ne faut jamais faire confiance à la mémoire. Document! J'aime penser (enfin, pas vraiment, mais vous comprendrez) à ce qui se passerait si j'étais heurté par un bus (ou promu, ou arraché pour la raison que vous souhaitez).
Jason Berg

Poser des questions raisonnables est une bonne idée.
poige

1
aussi, ne sous-estimez jamais la durée de mémoire d'un coffre-fort physique :-)
Sirex

Réponses:


22

Je fais cela, et cela fonctionne pour moi (comme dans, les sauvegardes fonctionnent bien, et j'ai fait plusieurs restaurations). J'utilise du bacula, qui le supporte. Pour mon argent, les conseils pour bien faire les choses comprennent:

1) La clé de déchiffrement est conservée (non chiffrée) sur un CD-R, pas dans ma tête. Il existe plusieurs exemplaires du CD-R, et aucun d'entre eux n'est avec moi. Je n'ai besoin de faire des restaurations qu'une fois tous les quelques mois, et franchement, j'oublierais probablement un mot de passe que j'utilisais rarement. Cela signifie également que ma sécurité n'est pas limitée par la longueur d'une phrase secrète mémorable.

2) Le logiciel de sauvegarde doit déjà le prendre en charge; ne commencez pas à pirater cela dans votre outil préféré, car vous pouvez vous tromper et vous ne le saurez pas avant qu'il ne soit vital que cela fonctionne (c'est-à-dire, le temps de restauration).

3) Vous avez un point sur les bit-flips, mais ceux-ci peuvent ruiner toute sauvegarde. Je nettoie mes têtes de bande chaque fois que le lecteur le demande, je fais tourner les bandes toutes les quelques années et, surtout, je garde beaucoup d'incréments. Si un bit-flip a vraiment ruiné l'incrémental d'hier, je peux toujours revenir à la veille, ce qui sauvera la plupart de mes fesses.

4) Documentez la procédure de restauration . Le chiffrement complique toujours les choses, plus s'il est bien fait, et vous ne voulez pas avoir à redécouvrir la roue lorsque vous êtes sous pression pour récupérer la base de données des comptes. J'ai écrit un README court avec beaucoup de détails très spécifiques à ma configuration (un vrai guide étape par étape, tous les noms de chemin explicitement répertoriés, ce genre de chose) et il est gravé sur les mêmes CD que les clés de déchiffrement.

5) Avant tout, testez-le beaucoup . Vous devriez quand même tester vos restaurations régulièrement, mais une fois que vous avez fait quelque chose d'intelligent comme celui-ci, il devient absolument essentiel que vous ayez confiance que les choses fonctionnent comme elles le devraient.

Les avantages découlant de cette pratique incluent le fait de ne pas avoir à se soucier lorsque le stockage hors site perd une bande ou deux, comme - étant uniquement humain - ils le font de temps en temps; il est facile de détruire les anciennes bandes en toute sécurité (jeter dans la poubelle); et le fait que tous mes systèmes de fichiers soient chiffrés sur disque n'est plus miné par la présence d'une pile de bandes de sauvegarde non chiffrées dans le coffre-fort à côté.


4
Big +1 pour mettre l'accent sur la documentation et tester les restaurations.
andol

1
+1 ne peut pas mettre suffisamment l'accent sur la documentation et les tests. Quelqu'un m'a dit une fois que cela ne fonctionne pas tant que vous ne l'avez pas testé. Cela s'applique encore plus aux sauvegardes.
Nixphoe

De plus, dans la plupart des modes de chiffrement CTR, un retournement de bit n'affectera que ce seul bloc de données. Le reste de votre sauvegarde devrait être parfait.
Jeff Ferland

4

mais ils semblent convaincus que le cryptage est une mauvaise idée car un seul mauvais bit pourrait ruiner tout le bloc

Ce n'est pas une très bonne raison de ne pas utiliser de cryptage. Il en va de même pour la plupart des sauvegardes compressées. La meilleure façon de résoudre le problème serait d'utiliser un système de fichiers tolérant aux pannes (les formats de fichiers tolérants aux pannes sont très minces sur le terrain - principalement parce qu'ils ne traitent pas autant de scénarios de défaillance que les systèmes de fichiers tolérants aux pannes).

Comme pour toute sauvegarde, vous devez vous assurer que vous pouvez accéder aux ressources nécessaires pour restaurer les données et vérifier / exécuter périodiquement les restaurations de test.

Cependant, vous risquez beaucoup plus de perdre un ordinateur portable qu'un serveur de sauvegarde.Par conséquent, si vos données sont précieuses, votre premier port d'escale devrait être de déterminer comment sécuriser les données sur l'ordinateur portable. Cela aura probablement beaucoup d'impact sur votre choix de sécurisation de la sauvegarde.


3

Ils ont leurs avantages et leurs inconvénients, comme les autres. Le problème des bit-flips ruinant tout 1 peut être résolu en vérifiant correctement les sauvegardes et en ayant plus d'une copie (ce qui est toujours une bonne idée de toute façon - une sur site pour une restauration rapide et une hors site pour des fins de récupération d'urgence) ).

En ce qui concerne les avantages du cryptage lui-même, il s'agit vraiment de savoir à quel point ce serait mauvais si les sauvegardes étaient volées. De nos jours, la plupart des entreprises disposent de suffisamment de données sensibles pour qu'elles valent au moins la peine de faire un projet pilote (pour en savoir plus sur les problèmes pratiques de gestion de la chose) et de faire une analyse du retour sur investissement sur l'ensemble.


  1. Parlant Pactically, blocs meurent dans les disques, pas de bits, et si vous fait avoir un peu indétectable flip dans une sauvegarde non-chances sont cryptées , vous avez probablement silencieusement corrompu quelque chose d' important de toute façon.

2

J'utilise rsync sur ssh pour sauvegarder 100 Go de données de serveur Web distant chaque nuit - cela ne prend que quelques minutes pour transférer les différences et garder un miroir local synchronisé. Cependant, cela dépend du fait que la destination n'est pas chiffrée.

Une fois les données reçues, elles peuvent être archivées à l'aide de tar, compressées avec gzip, (éventuellement testées avec gzip -t) puis éventuellement cryptées et renommées avec la date et stockées sur un système de raid. (J'ai trouvé plus facile de stocker le tout que de jouer avec les incrémentaux).

Si le lecteur RAID utilise un système de fichiers crypté, il ne devrait pas être nécessaire de crypter davantage les sauvegardes. Si les disques sont volés, ils doivent rester illisibles, mais s'ils prennent tout le système et que la clé est disponible n'importe où, c'est un point discutable.

Vous pouvez crypter les fichiers individuellement, mais leur sécurité n'est aussi sûre que l'emplacement de la clé.

Vous pouvez servir la clé via https à partir d'un serveur Web distant en fonction de l'adresse IP source, de cette façon, si le système et les sauvegardes ont été volés, vous pouvez toujours avoir un certain contrôle sur la clé et la désactiver à temps.

Gardez toujours plusieurs copies, localement et à distance.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.