Crashplan + TrueCrypt - перебор?

Crashplan уже имеет возможность шифровать данные. И если этот параметр выбран, он сохраняет зашифрованный файл на сервере.

Truecrypt, конечно, имеет гораздо больше возможностей, но для базового использования не будет достаточно шифрования CrashPlan?

Обновление : после попытки CrashPlan я не уверен, является ли указанное шифрование чем-то реальным. Конечно, он создает контейнерный файл, который вы не можете открыть и просмотреть, но если вы зайдете на сайт CrashPlan, вы можете:

• увидеть всю структуру папок
• смотреть отдельные файлы
• восстановить отдельные файлы или группы файлов любым способом, который вам нравится.

Предполагается, что шифрование является односторонним трафиком, если данные доступны на виду, то я не уверен, является ли это шифрованием. Может быть закодировано, но не зашифровано. Я что-то здесь упускаю?

Раскрытие информации: я генеральный директор и основатель Code42

Это излишне. Что еще хуже, это замедлит ваши резервные копии и отложит защиту данных, так как мониторинг в реальном времени не будет работать, а зашифрованные данные не сжимаются.

Используя личный пароль (рекомендуется) или создав собственный ключ, вы гарантируете конфиденциальность. (Да, вы должны доверять нам, говоря это, но если вы не являетесь экспертом по программному обеспечению / безопасности, лично изучающим / проверяющим код truecrypt, вы должны доверять чему-то / кому-то.

Если у вас есть такие ценные данные, что вы никому не можете доверять, разумно удвоить шифрование. Однако я бы сделал это только для этого конкретного набора данных - пусть CrashPlan обрабатывает все остальное.

Я - пользователь TrueCrypt, но если бы я использовал CrashPlan, я бы определенно избегал шифрования своих данных другим продуктом, прежде чем передавать их в CrashPlan для обработки, а затем передавать через Интернет (так как производительность, скорее всего, пошла бы на пользу -> болезненная). Если вы зашифруете папку объемом 1 ГБ, которая содержит множество крошечных документов Word, внезапно все, что у вас есть, - это однородный блок данных объемом 1 ГБ, который не может быть эффективно обработан программой резервного копирования. Таким образом, если вы добавляете один дополнительный период к одному из этих документов Word, а затем повторно сохраняете, ваш архивный файл TrueCrypt теперь ПОЛНОСТЬЮ отличается, и ВЕСЬ объект должен быть снова скопирован. Я был бы склонен доверять шифрованию CrashPlan (вы должны доверять шифрованию этих сервисов или найти тот, которому доверяете). Если у вас был небольшой текстовый файл с паролями администратора домена и вы можете не спать ночью без двойного шифрования, это нормально, но вы бы хотели избежать массивных зашифрованных файлов (TrueCrypt или других), так как влияние на производительность будет иметь увеличение пропускной способности сети и гораздо более медленное резервное копирование - и все это для повышение безопасности вам (возможно) не нужно. Если вы юрист или имеете медицинскую информацию, то у вас может быть юридическое обязательство двойного шифрования, или, возможно, вы можете получить какое-то юридическое заверение из Кодекса 42, что шифрование можно доверять для такого рода данных ( возможно, у вас будет обязанность сделать это в такой ситуации, я не уверен - лично я еще не сталкивался с такими данными на работе). Если вы использовали Dropbox (компания, которая признает, что 5% их сотрудников имеют доступ к данным, хранящимся пользователям, для обслуживания и устранения неполадок!

Или краткий ответ:

... да, это, вероятно, излишне.

Короткий ответ

Скорее всего, да, если только вы не высококлассная цель.

Длинный ответ

CrashPlan либо шифрует данные, используя защищенные паролем сертификаты, либо вообще не шифрует. В этом обзоре вы можете думать о сертификате как об огромном пароле, хранящемся в файле с вашим именем. Этот файл сертификата обычно зашифрован, просто для того, чтобы обеспечить быструю копию файла для доступа к данным - вам также нужен пароль файла сертификата.

Большинство пользователей CrashPlan, вероятно, используют так называемое хранилище сертификатов условного депонирования, где Code42 хранит файлы сертификатов для вас в зашифрованном виде. Когда вы предоставляете свой пароль, эти файлы сертификатов сами дешифруются, а затем используются для расшифровки ваших необработанных данных. Вот почему веб-интерфейс CrashPlan позволяет просматривать ваши данные - после того, как вы предоставите пароль сертификата, их программное обеспечение сможет получить доступ к данным с помощью сертификата. Основные дыры в безопасности с этим:

• Вы доверяете сотрудникам Code42 + надежно хранить ваш сертификат
• Вы доверяете сотрудникам Code42 + никогда не хранить небезопасно пароль сертификата
• Вы доверяете сотрудникам Code42 + не передавать ваш файл сертификата или пароль любому агентству (например, правительству), которое запрашивает (например, повестку в суд),
• Как я уже упоминал выше, ваш сертификат является очень большим паролем. Если кто-то завладеет этим файлом, единственное, что мешает ему использовать его, - это пароль вашего сертификата, поэтому, если вы его сделали, hunter42вы довольно испорчены. В принципе, взломать пароль сертификата, скорее всего, довольно просто, если кто-то действительно мотивирован, а вы не выбрали хороший пароль.

Вы также можете использовать «пользовательский ключ» (например, когда вы предоставляете файл сертификата). Это означает, что Code42 не хранит свой сертификат на своих серверах. Они по-прежнему хранят зашифрованные данные на своих серверах, но если вы хотите увидеть их в веб-интерфейсе, вам необходимо предоставить их программному обеспечению как файл сертификата, так и пароль сертификата. Теперь вот странная часть: это практически не дает реалистичной дополнительной защиты по сравнению с вышеупомянутой опцией, это в основном полезно для системы со многими учетными записями пользователей, которые вы хотите хранить отдельно. Ты все еще:

• Доверяйте приложению CrashPlan не хранить и не передавать файл сертификата или пароль сертификата
• Доверьтесь Code42, чтобы не пытаться сохранить эти данные

Основным преимуществом здесь является то, что Code42 не может ответить на внешний запрос вашего сертификата так же легко, как если бы вы использовали сертификаты условного депонирования, им пришлось бы преднамеренно дать указание своему локальному приложению CrashPlan получить ваш ключ сертификата с вашего компьютера и доставить его им. , Естественно, это было бы для них огромным риском из-за последствий для бизнеса, если бы такое решение стало общеизвестным.

Еще один важный момент: они, очевидно, всегда хранят ваш файл сертификата в незашифрованном виде на вашем локальном компьютере. Так что, если вы являетесь целью высокого уровня, вполне возможно, что кто-то может получить ваши зашифрованные данные из CrashPlan, а затем выполнить простую атаку на ваш персональный компьютер, чтобы восстановить незашифрованный файл сертификата.

Таким образом, ответ на ваш вопрос сводится к следующему: «Доверяете ли вы Code42 защите ваших данных от внутренних и внешних угроз?» Если ответ отрицательный, то шифрование ваших данных с использованием чего-то вроде TrueCrypt в качестве второго уровня защиты - отличная идея.

PS - Что бы это ни стоило, мне нравится, что CrashPlan по умолчанию довольно сильно шифрует, так что не воспринимайте это как громкий пост CrashPlan - я просто хочу помочь пользователям понять, кому они доверяют :-)

Интересной альтернативой может быть использование EncFS , особенно с флагом --reverse . Очевидно, есть порт для Windows, так что вы можете сделать то же самое там.

   --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.

РЕДАКТИРОВАТЬ - Обязательно сохраните свои файлы .encfs5 или encfs6.xml, они будут расположены в исходном каталоге открытого текста, а не в каталоге резервных копий, поэтому вам нужно обязательно взять их, так как вы не сможете восстановить ваши зашифрованные файлы без них. (было бы неплохо, если бы в encfs были файлы с зашифрованными файлами, чтобы вы могли сделать автономный резервный архив)

Если на вашем ПК не хранится информация о многомиллионном патенте, документов, связанных с судебным разбирательством (например, судебного разбирательства), или секретной информации о шифровании аварийного плана вашего ПК должно быть достаточно.

Если ставки достаточно высоки, можно нанять хакеров для взлома вашего пароля.

Проблема, как я вижу, это скорость / эффективность против безопасности. Зашифровывая сначала с помощью Truecrypt, обновления, скорее всего, будут медленными и неэффективными, как упоминалось ранее. Однако после Сноудена другая проблема заключается в том, что даже если вы создадите свой собственный ключ на основе сложного пароля, вы должны верить, что он никогда не будет пропущен. Случайно или потому, что АНБ вынудило американскую компанию, владеющую Crashplan, ввести механизм для этого. Шифрование на локальном клиенте является плюсом, но если вы (или, скорее, сообщество в целом) не сможете увидеть клиентский код, то невозможно будет гарантировать, что ваш ключ и, следовательно, ваши данные в безопасности.

Хотя это не соответствует строгой теории резервного копирования 3-2-1, я собираюсь использовать внешний зашифрованный жесткий диск, заполненный с помощью rsnapshot и регулярно меняющийся с другими копиями. Я рассматривал Crashplan над всеми другими облачными вариантами, но непроверяемая природа клиента оттолкнула меня. Если бы у них был API, а EFF или другой источник FOSS предоставил клиенту, я бы пересмотрел.