Crashplan + TrueCrypt - Overkill?

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

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

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

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

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

9 голосов | спросил Mrchief 25 PMpThu, 25 Apr 2013 19:58:51 +040058Thursday 2013, 19:58:51

6 ответов


12

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

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

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

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

ответил Matthew Dornquast 30 PMpTue, 30 Apr 2013 18:35:03 +040035Tuesday 2013, 18:35:03
4

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

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

... да, это, наверное, перебор.

ответил Austin ''Danger'' Powers 4 Mayam13 2013, 06:47:35
3

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

Наверное, да, если вы не являетесь высокопрофильной целью.

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

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

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

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

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

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

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

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

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

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

ответил Austin ''Danger'' Powers 4 Mayam13 2013, 06:47:35
2

Интересной альтернативой может быть использование 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 были включены файлы с зашифрованными файлами, чтобы вы могли создать автономный архив резервных копий)

ответил jonmatifa 28 +03002014-10-28T21:40:37+03:00312014bEurope/MoscowTue, 28 Oct 2014 21:40:37 +0300 2014, 21:40:37
0

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

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

ответил cybernard 27 PMpSat, 27 Apr 2013 20:40:15 +040040Saturday 2013, 20:40:15
0

Проблема, как я вижу, - это скорость /эффективность и безопасность. Сначала зашифровав Truqurypt, обновления, вероятно, будут медленными и неэффективными, как упоминалось ранее. Тем не менее, post-Snowden, другая проблема заключается в том, что даже если вы создадите свой собственный пользовательский ключ из сложного пароля, вы должны верить, что это никогда не будет пропущено. Случайно или потому, что NSA заставил американскую компанию, которая владеет Crashplan, вставить механизм для этого. Шифрование на локальном клиенте - это плюс, но если вы (или, скорее, сообщество в целом) не видите код клиента, тогда нет способа убедиться, что ваш ключ и, следовательно, ваши данные безопасны.

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

ответил Mark 10 FebruaryEurope/MoscowbTue, 10 Feb 2015 04:12:56 +0300000000amTue, 10 Feb 2015 04:12:56 +030015 2015, 04:12:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132