Crashplan + TrueCrypt - Overkill?

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.

EDIT - Не забудьте зберегти ваші .encfs5 або encfs6.xml файли, вони будуть розташовані в оригінальній директорії прямого тексту, а не в резервній папці, тому вам потрібно бути впевненим, щоб схопити ті, як ви не зможете відновити ваш зашифровані файли без них. (Було б непогано, якби в encfs були включені ті із зашифрованими файлами, щоб ви могли зробити самостійний резервний архів)

Якщо ви не володієте інформацією на своєму ПК, що стосується багатомільйонного патенту, документів, пов’язаних із судовим позовом (наприклад, судовим позовом) або класифікованою інформацією про шифрування плану зриву вашого ПК, має бути достатньо.

Якщо ставки досить високі, хакери можуть бути найняті, щоб змусити ваш пароль.

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

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