web-dev-qa-db-fra.com

Chiffrement de quelques TB de données

Je prévois de crypter une grande bibliothèque multimédia. J'ai examiné différentes solutions, mais j'ai pensé que je devrais demander à la communauté ce que vous en pensez.

  • Je ne veux pas crypter chaque fichier individuellement, je voudrais créer un conteneur que je décrypte une fois lors du montage.
  • J'ai 1,4 TB de données constituées principalement de fichiers de 2 à 4 Go, bien que certains fichiers dépassent 4 Go (ce qui signifie que la fermeture éclair n'est pas une option).
  • Idéalement, j'aimerais que la solution soit multiplateforme (même si cela signifie uniquement la ligne de commande).

Ma meilleure solution actuelle consiste à utiliser GPG. Je créerais un tarball de mon répertoire 1.4 TB puis chiffrer ce fichier avec ma clé GPG. Bien que je n'ai pas beaucoup d'expertise en compression, je pense que ce n'est pas idéal pour tar 1.4 TB. Ce qui signifie également que la navigation dans les fichiers sera fastidieuse, à moins que je décompose ce qui doublerait le stockage nécessaire ainsi que de nombreux autres inconvénients.

Avez-vous des suggestions d'autres façons de procéder? Je n'ai pas besoin de solution pour être incroyablement sécurisé, en privilégiant la commodité pour ce cas d'utilisation.

Plus d'infos: J'utilise actuellement la méthode de cryptage intégrée d'OSX pour créer un .dmg et le monter pour accéder au contenu. En espérant une version multiplateforme de cela.

28
Huckleberry Finn

Pourquoi ne pas utiliser une application couramment utilisée pour le faire? VeraCrypt est un bon choix car il a remplacé l'application respectée TrueCrypt et vous permet de créer un conteneur de chiffrement que vous montez en tant que lecteur.

60
ISMSDEV

Je trouve certains de vos commentaires curieux. Particulièrement,

J'essaie de m'éloigner des méthodes qui dépendent d'une application et de le faire manuellement - car je me sentirais plus en "contrôle".

et

Je n'ai pas besoin de solution pour être incroyablement sécurisé, en privilégiant la commodité pour ce cas d'utilisation.

semblent quelque peu en désaccord les uns avec les autres.

Tout d'abord, vous devriez vraiment consacrer du temps à réfléchir à votre modèle de menace. Êtes-vous principalement préoccupé par le vol de l'appareil physique, ou êtes-vous préoccupé par les attaques via un réseau pendant que votre système est opérationnel, ou êtes-vous préoccupé par les attaques d'un adversaire motivé qui vise vous = spécifiquement et avoir la possibilité d'obtenir à plusieurs reprises un accès physique à vos systèmes, ou quoi?

Pour la plupart personnes, les deux plus grandes menaces à considérer sont généralement:

  • perte de données, due à des erreurs de support et à des conditions similaires ("plantages du disque dur"), et
  • perte de contrôle des données, par ex. en raison du vol d'un système qui a été arrêté

Le premier point est facilement géré en effectuant des sauvegardes régulières et en vérifiant qu'elles sont restaurables. Le chiffrement peut ajouter une couche supplémentaire de complexité à cela, mais ne changez pas fondamentalement beaucoup de rien; par exemple, avec le chiffrement dans l'image, vous devez réfléchir à la façon dont vous géreriez le cas où vous perdriez la clé de déchiffrement et/ou la phrase secrète.

Le deuxième point est essentiellement ce que le chiffrement complet du disque est conçu pour résoudre.

Vous devriez donc probablement envisager des solutions de chiffrement intégral du disque (FDE). Je m'abstiendrai spécifiquement de recommander des produits spécifiques, mais il existe des choix disponibles pour tous les principaux systèmes d'exploitation. systèmes.

De cette façon, vous (bien que la terminologie ait tendance à varier légèrement) "ouvrir" un "conteneur" (qui vous oblige à fournir la phrase secrète correspondante ou similaire), utiliser vos données comme vous le souhaitez, puis "fermer" le conteneur qui rend les données inaccessibles sans la phrase secrète associée au conteneur.

Chaque fois que vous stockez quelque chose sur un ordinateur, même si vous le supprimez par la suite, à moins que des mesures spéciales ne soient prises, certaines ou toutes les données restent réellement. est rémanence des données , et c'est un grand catalyseur de criminalistique numérique . Si tout ce que vous faites est de cliquer sur "supprimer" dans l'interface utilisateur et peut-être de vider la corbeille, alors les données resteront très probablement trivialement récupérables en utilisant des outils standard que n'importe qui peut télécharger et utiliser , ou achetez pour quelques dizaines de dollars.

Si vous utilisez correctement le cryptage complet du disque (par exemple, si vous ne copiez pas les données vers un emplacement non crypté), alors que les données seront toujours sur le disque, elles le seront sous la forme - cryptée. De cette façon, même si quelqu'un est capable d'analyser ce qui est écrit sur le support de stockage, à moins qu'il ne connaisse la phrase secrète, il ne pourra pas comprendre le ce qui signifie des données.

L'avantage, c'est que pendant que vous utilisez les données, vous n'aurez pas vraiment à penser au fait qu'elles sont cryptées; c'est juste.

Vous pouvez toujours faire quelque chose comme votre schéma de cryptage/décryptage GnuPG local si vous le souhaitez, et pour certains fichiers, il peut même être judicieux de le faire pour vous protéger contre une attaque en ligne. (Une attaque "en ligne", dans ce contexte, est par exemple quelqu'un qui est capable de vous inciter à exécuter le code de son choix qui copie les fichiers de votre système pendant que le conteneur chiffré est ouvert ainsi activation de l'accès en texte brut.)

41
a CVn

J'utilise LUKS pour cela, qui est extrêmement bien intégré dans ma distribution Linux de choix. Le déchiffrement est possible lors du démarrage ou à l'aide de cryptsetup luksOpen [...] si le système est déjà en cours d'exécution. Vous pouvez ajouter une couche de chiffrement autour des disques physiques (/dev/sda), partitions (/dev/sda1), RAID (/dev/md0), LVM-LV (/dev/mapper/vg-lv).

Je ne sais pas comment/si cela est pris en charge sur les plates-formes non Linux, cependant.

5
C-Otto

Comme d'autres l'ont souligné, vous devez utiliser un schéma de chiffrement complet du disque.

GPG crypte les fichiers en créant un autre fichier avec le contenu crypté (en | de). Ainsi, comme vous l'avez souligné, vous devez traiter l'intégralité du répertoire 1,4 To, pour le chiffrement, et le traiter à nouveau pour le déchiffrement Même si vous décompressiez à la volée afin d'éviter les besoins d'espace (par exemple. < store.tar.gpg gpg -d | tar -x specific-file), il vous faudrait en moyenne parcourir la moitié du conteneur pour chaque extraction.

D'un autre côté, les solutions pour celles-ci sont basées sur une clé donnée, puis chaque bloc est basé sur celle-ci (comme l'utilisation de mode CTR ). La clé de disque est stockée dans un bloc de métadonnées, protégée par un mot de passe, etc. mais dans l'ensemble, il y a une clé de disque en mémoire qui permet un accès aléatoire au disque. Ce qui résout le problème de navigation dans la collection, laissant des traces des fichiers temporaires non compressés et devant doubler l'espace de stockage nécessaire.

2
Ángel

GPG pour les grandes archives tar sera extrêmement lent. Ce n'est certainement pas le meilleur moyen si vous avez des cas d'utilisation quotidiens.

Comme d'autres l'ont dit, FDE est un choix. Si vous avez besoin d'une solution de type conteneur, jetez un œil à Tomb:

0
f1nn