Crashplan + TrueCrypt - Overkill?

Crashplan a déjà une option pour crypter les données. Et si sélectionné, cela stocke le fichier crypté sur le serveur.

Truecrypt a certainement beaucoup plus d'options, mais pour une utilisation de base, le cryptage de CrashPlan ne suffirait-il pas?

Mise à jour : Après avoir essayé CrashPlan, je ne sais pas si ledit cryptage est réel. Bien sûr, il crée un fichier conteneur que vous ne pouvez pas ouvrir et regarder, mais si vous allez sur le site Web de CrashPlan, vous pouvez:

• voir toute la structure de vos dossiers
• voir les fichiers individuels
• restaurer des fichiers individuels ou un groupe de fichiers comme vous le souhaitez.

Le chiffrement est censé être un trafic à sens unique, si les données sont disponibles à la vue, alors je ne suis pas sûr qu'il s'agisse d'un chiffrement. Peut-être encodé mais pas crypté. Est-ce que j'ai râté quelque chose?

Divulgation: je suis le PDG et un partenaire fondateur de Code42

C'est exagéré. Pour aggraver les choses, cela ralentira vos sauvegardes et retardera la protection des données car la surveillance en temps réel ne fonctionnera pas et les données chiffrées ne sont pas compressibles.

En utilisant un mot de passe de données privées (recommandé) ou en générant votre propre clé, vous êtes assuré de la confidentialité. (Oui, vous devez nous faire confiance en disant cela, mais à moins que vous ne soyez un expert en logiciels / sécurité qui étudie / audite personnellement le code Truecrypt, vous devez faire confiance à quelque chose / quelqu'un.

Si vous avez des données si précieuses que vous ne pouvez faire confiance à personne, doubler le chiffrement est raisonnable. Cependant, je ne ferais cela que pour cet ensemble de données spécifique - laissez CrashPlan gérer le reste.

Je suis un utilisateur TrueCrypt, mais si j'utilisais CrashPlan, j'éviterais certainement de crypter mes données avec un autre produit avant de les alimenter vers CrashPlan pour les gérer, puis pousser sur Internet (car les performances passeraient très probablement de bonnes -> douloureuses). Si vous cryptez un dossier de 1 Go, qui contient de nombreux minuscules documents Word, tout ce que vous avez soudainement est une goutte de données homogène de 1 Go qui ne peut pas être gérée efficacement par votre logiciel de sauvegarde. Donc, si vous ajoutez une seule période supplémentaire à l'un de ces documents Word, puis ré-enregistrez, votre fichier d'archive TrueCrypt est maintenant ENTIÈREMENT différent, et la chose entière doit être sauvegardée à nouveau. Je serais enclin à faire confiance au cryptage de CrashPlan (vous devez faire confiance au cryptage de ces services ou en trouver un auquel vous faites confiance). Si vous disposiez d'un petit fichier texte avec des mots de passe d'administrateur de domaine et que vous pouvez " t dormir la nuit sans le chiffrer deux fois, c'est bien, mais vous voudriez éviter tout fichier chiffré massif (TrueCrypt ou autre) car l'impact sur les performances sera une augmentation de la bande passante du réseau et des sauvegardes beaucoup plus lentes - le tout pour un augmentation de la sécurité dont vous (sans doute) n'avez pas besoin. Si vous êtes avocat ou que vous avez des informations médicales, vous pourriez avoir une obligation légale de double-chiffrer, ou peut-être pouvez-vous obtenir une sorte d'assurance juridique du Code 42 que le chiffrement peut être approuvé pour ce type de données ( vous auriez peut-être le devoir de le faire dans une telle situation, je ne suis pas sûr - je n'ai pas encore rencontré personnellement ce type de données au travail). Si vous utilisiez Dropbox (une entreprise qui admet que 5% de ses employés ont accès aux données stockées par les utilisateurs afin de maintenir et de dépanner!

Ou la réponse courte:

... ouais, c'est probablement exagéré.

Réponse courte

Probablement oui, sauf si vous êtes une cible de haut niveau.

Longue réponse

CrashPlan crypte les données à l'aide de certificats protégés par mot de passe, ou aucun cryptage du tout. Dans ce résumé, vous pouvez considérer un certificat comme fondamentalement un énorme mot de passe frigorifique stocké dans un fichier avec votre nom attaché. Ce fichier de certificat est généralement crypté, juste pour garantir qu'une copie rapide du fichier ne suffit pas pour accéder aux données - vous avez également besoin du mot de passe du fichier de certificat.

La plupart des utilisateurs de CrashPlan utilisent probablement ce qu'on appelle le stockage de certificats d'entiercement, où Code42 stocke les fichiers de certificats pour vous sous forme cryptée. Lorsque vous fournissez votre mot de passe, ces fichiers de certificats sont eux-mêmes déchiffrés, puis sont utilisés pour déchiffrer vos données brutes. C'est pourquoi l'interface Web CrashPlan peut vous permettre de parcourir vos données - après avoir fourni le mot de passe du certificat, leur logiciel peut accéder aux données à l'aide du certificat. Les principaux trous de sécurité avec ceci:

• Vous faites confiance aux employés de Code42 + pour stocker votre certificat en toute sécurité
• Vous faites confiance aux employés de Code42 + pour ne jamais stocker votre mot de passe de certificat de manière non sécurisée
• Vous faites confiance aux employés de Code42 + pour ne pas donner votre fichier de certificat ou votre mot de passe à une agence (comme un gouvernement) qui en fait la demande (par exemple une assignation)
• Comme je l'ai mentionné ci-dessus, votre certificat est un très gros mot de passe. Si quelqu'un met la main sur ce fichier, la seule chose qui les empêche de l'utiliser est votre mot de passe de certificat, donc si vous l'avez fait, hunter42vous êtes plutôt foutu. Fondamentalement, la rupture de votre mot de passe de certificat est probablement assez facile si quelqu'un est vraiment motivé et que vous n'avez pas choisi un bon mot de passe.

Vous pouvez également utiliser une "clé personnalisée" (par exemple lorsque vous fournissez le fichier de certificat). Cela signifie que Code42 ne stocke pas leur certificat sur leurs serveurs. Ils stockent toujours des données cryptées sur leurs serveurs, mais si vous souhaitez les voir dans l'interface Web, vous devez fournir à leur logiciel à la fois le fichier de certificat et le mot de passe du certificat. Maintenant, voici la partie étrange: cela n'offre presque aucune sécurité supplémentaire réaliste par rapport à l'option ci-dessus, c'est surtout utile pour un système avec de nombreux comptes d'utilisateurs que vous souhaitez garder séparés. Vous:

• Faites confiance à l'application CrashPlan pour ne pas stocker ou transmettre votre fichier de certificat ou votre mot de passe de certificat
• Faites confiance à Code42 pour ne pas tenter de stocker ces données

Le principal avantage ici est que Code42 ne peut pas répondre à une demande externe pour votre certificat aussi facilement qu'ils le pourraient si vous utilisez des certificats d'entiercement, ils devraient volontairement demander à leur application CrashPlan locale de récupérer votre clé de certificat de votre ordinateur et de la leur livrer. . Ce serait naturellement un risque énorme pour eux en raison des retombées commerciales si une telle décision devenait un jour de notoriété publique.

Un autre point pertinent: ils stockent apparemment toujours votre fichier de certificat sous forme non cryptée sur votre ordinateur local. Donc, si vous êtes une cible de haut niveau, il est possible que quelqu'un puisse acquérir vos données chiffrées de CrashPlan, puis exécuter une simple attaque sur votre ordinateur personnel pour récupérer le fichier de certificat non chiffré.

La réponse à votre question se résume donc à "faites-vous confiance à Code42 pour protéger vos données contre les menaces internes et externes?" Si la réponse est non, le cryptage de vos données en utilisant quelque chose comme TrueCrypt comme deuxième couche de protection est une excellente idée.

PS - Pour ce que ça vaut, j'aime que CrashPlan crypte assez lourdement par défaut, alors n'interprétez pas cela comme un post CrashPlan bashing - je veux juste aider les utilisateurs à comprendre en qui ils ont confiance :-)

Une alternative intéressante peut être d'utiliser EncFS , en particulier avec le drapeau --reverse . Il y a apparemment un port pour Windows, donc vous pourrez peut-être faire la même chose là-bas.

   --reverse
       Normally EncFS provides a plaintext view of data on demand.  Normally it stores enciphered
       data and displays plaintext data.  With --reverse it takes as source plaintext data and pro-
       duces enciphered data on-demand.  This can be useful for creating remote encrypted backups,
       where you do not wish to keep the local files unencrypted.

       For example, the following would create an encrypted view in /tmp/crypt-view.

           encfs --reverse /home/me /tmp/crypt-view

       You could then copy the /tmp/crypt-view directory in order to have a copy of the encrypted
       data.  You must also keep a copy of the file /home/me/.encfs5 which contains the filesystem
       information.  Together, the two can be used to reproduce the unencrypted data:

           ENCFS5_CONFIG=/home/me/.encfs5 encfs /tmp/crypt-view /tmp/plain-view

       Now /tmp/plain-view contains the same data as /home/me

       Note that --reverse mode only works with limited configuration options, so many settings may
       be disabled when used.

EDIT - Assurez-vous de sauvegarder vos fichiers .encfs5 ou encfs6.xml, ils seront situés dans le répertoire en texte brut d'origine et non dans le répertoire de sauvegarde, vous devrez donc être sûr de les saisir car vous ne pourrez pas récupérer votre fichiers cryptés sans eux. (ce serait bien si encfs incluait ceux avec les fichiers cryptés pour que vous puissiez créer une archive de sauvegarde autonome)

À moins que vous ne déteniez des informations sur votre PC concernant un brevet de plusieurs millions de dollars, les documents liés à une action en justice (comme une action en justice) ou des informations classifiées sur le chiffrement de votre plan de crash PC devraient suffire.

Si les enjeux sont suffisamment élevés, des pirates pourraient être embauchés pour forcer brutalement votre mot de passe.

Le problème tel que je le vois est la vitesse / efficacité par rapport à la sécurité. En chiffrant d'abord avec Truecrypt, les mises à jour seront probablement lentes et inefficaces comme mentionné précédemment. Cependant, après Snowden, l'autre problème est que même si vous créez votre propre clé personnalisée à partir d'un mot de passe complexe, vous devez vous assurer que cela ne sera jamais divulgué. Que ce soit par accident ou parce que la NSA a forcé la société américaine propriétaire de Crashplan à insérer un mécanisme pour le faire. Le cryptage sur le client local est un avantage mais à moins que vous (ou plutôt la communauté dans son ensemble) ne puissiez voir le code client, il n'y a aucun moyen d'être sûr que votre clé, et donc vos données, sont en sécurité.

Bien qu'il ne respecte pas la théorie stricte de la sauvegarde 3-2-1, je vais utiliser un disque dur chiffré hors site rempli à l'aide de rsnapshot et tourné régulièrement avec d'autres copies. J'ai considéré Crashplan par rapport à toutes les autres options de cloud, mais la nature invérifiable du client m'a découragé. S'ils devaient avoir une API et l'EFF ou une autre source FOSS fournir au client, je reconsidérerais.