Crashplan + TrueCrypt - Overkill?

Crashplan ma już opcję szyfrowania danych. Po wybraniu zapisuje zaszyfrowany plik na serwerze.

Truecrypt z pewnością ma o wiele więcej opcji, ale czy do podstawowego użytku nie wystarczy szyfrowanie CrashPlan?

Aktualizacja : po wypróbowaniu CrashPlan nie jestem pewien, czy wspomniane szyfrowanie jest czymś realnym. Oczywiście tworzy plik kontenera, którego nie można otworzyć i przejrzeć, ale jeśli przejdziesz na stronę CrashPlan, możesz:

• zobacz całą strukturę folderów
• zobacz poszczególne pliki
• przywracaj pojedyncze pliki lub grupy plików w dowolny sposób.

Szyfrowanie ma być ruchem jednokierunkowym, jeśli dane są dostępne na widoku, nie jestem pewien, czy jest to szyfrowanie. Może zakodowane, ale nie zaszyfrowane. Czy coś mi umyka?

Ujawnienie: Jestem CEO i partnerem założycielem Code42

To przesada. Co gorsza, spowalnia tworzenie kopii zapasowych i opóźnia ochronę danych, ponieważ monitorowanie w czasie rzeczywistym nie działa, a zaszyfrowane dane nie są kompresowalne.

Używając hasła do prywatnych danych (zalecane) lub generując własny klucz, masz zapewnioną prywatność. (Tak, powierz nam to, ale jeśli nie jesteś ekspertem od oprogramowania / bezpieczeństwa osobiście studiującym / kontrolującym kod truecrypt, musisz zaufać komuś / komuś).

Jeśli masz tak cenne dane, że nikomu nie możesz ufać, podwojenie szyfrowania jest uzasadnione. Zrobiłbym to jednak tylko dla tego konkretnego zestawu danych - niech CrashPlan zajmie się resztą.

Jestem użytkownikiem TrueCrypt, ale gdybym korzystał z CrashPlan, zdecydowanie unikałbym szyfrowania moich danych innym produktem przed podaniem ich do CrashPlan do obsługi, a następnie przesyłania przez Internet (ponieważ wydajność najprawdopodobniej zmieniłaby się z dobrej -> bolesnej). Jeśli zaszyfrujesz folder 1 GB, który zawiera wiele drobnych dokumentów Worda, nagle wszystko, co masz, to jednobarwna kropla danych 1 GB, której oprogramowanie do tworzenia kopii zapasowych nie może skutecznie obsłużyć. Tak więc, jeśli dodasz jeden dodatkowy okres do jednego z tych dokumentów Worda, a następnie ponownie zapiszesz, plik archiwum TrueCrypt jest teraz CAŁKOWICIE inny, a CAŁA rzecz musi zostać ponownie wykonana. Byłbym skłonny zaufać szyfrowaniu CrashPlan (musisz zaufać szyfrowaniu tych usług lub znaleźć taki, któremu ufasz). Jeśli masz mały plik tekstowy z hasłami administratora domeny i możesz „ spać w nocy bez podwójnego szyfrowania, to dobrze, ale chcesz uniknąć masywnych zaszyfrowanych plików (TrueCrypt lub w inny sposób), ponieważ wpływ na wydajność będzie zwiększenie przepustowości sieci i znacznie wolniejsze kopie zapasowe - wszystko dla jednego zwiększenie bezpieczeństwa, którego (prawdopodobnie) nie potrzebujesz. Jeśli jesteś prawnikiem lub posiadasz informacje związane z medycyną, możesz mieć prawny obowiązek podwójnego szyfrowania, a może możesz uzyskać prawne potwierdzenie z Kodeksu 42, że szyfrowanie może być zaufane dla tego rodzaju danych ( być może miałbyś obowiązek to zrobić w takiej sytuacji, nie jestem pewien - osobiście jeszcze nie spotkałem tego rodzaju danych w pracy). Jeśli korzystasz z Dropbox (firma, która przyznaje, że 5% ich pracowników ma dostęp do danych przechowywanych przez użytkowników w celu konserwacji i rozwiązywania problemów!

Lub krótka odpowiedź:

... tak, to chyba przesada.

Krótka odpowiedź

Prawdopodobnie tak, chyba że jesteś głośnym celem.

Długa odpowiedź

CrashPlan albo szyfruje dane przy użyciu certyfikatów chronionych hasłem, albo w ogóle nie szyfruje. W tym podsumowaniu możesz myśleć o certyfikacie jako po prostu cholernym, ogromnym haśle przechowywanym w pliku z dołączonym do niego Twoim nazwiskiem. Ten plik certyfikatu jest zwykle szyfrowany, aby zapewnić, że szybka kopia pliku nie wystarczy, aby uzyskać dostęp do danych - potrzebne jest również hasło do pliku certyfikatu.

Większość użytkowników CrashPlan prawdopodobnie korzysta z tak zwanego magazynu certyfikatów depozytowych, w którym Code42 przechowuje pliki certyfikatów zaszyfrowane. Po podaniu hasła te pliki certyfikatów są odszyfrowywane, a następnie wykorzystywane do odszyfrowania surowych danych. Dlatego interfejs sieciowy CrashPlan umożliwia przeglądanie danych - po podaniu hasła certyfikatu ich oprogramowanie może uzyskać dostęp do danych przy użyciu certyfikatu. Główne dziury w zabezpieczeniach:

• Ufasz pracownikom Code42 +, że bezpiecznie przechowują twój certyfikat
• Ufasz pracownikom Code42 +, że nigdy nie przechowują hasła certyfikatu w sposób niezabezpieczony
• Ufasz pracownikom Code42 +, że nie przekażą pliku certyfikatu ani hasła żadnej agencji (takiej jak rząd), która o to poprosi (np. Wezwanie sądowe)
• Jak wspomniałem powyżej, twój certyfikat jest bardzo dużym hasłem. Jeśli ktoś dostanie ten plik, jedyną rzeczą, która powstrzyma go przed użyciem go, jest hasło do certyfikatu, więc jeśli go utworzyłeś, to hunter42nieźle. Zasadniczo złamanie hasła do certyfikatu jest prawdopodobnie dość łatwe, jeśli ktoś jest naprawdę zmotywowany i nie wybrałeś dobrego hasła.

Możesz także użyć „klucza niestandardowego” (np. Po dostarczeniu pliku certyfikatu). Oznacza to, że Code42 nie przechowuje swojego certyfikatu na swoich serwerach. Nadal przechowują zaszyfrowane dane na swoich serwerach, ale jeśli chcesz je zobaczyć w interfejsie internetowym, musisz dostarczyć ich oprogramowaniu zarówno plik certyfikatu, jak i hasło certyfikatu. Oto dziwna część: nie zapewnia prawie żadnych realistycznych dodatkowych zabezpieczeń w stosunku do powyższej opcji, jest to szczególnie przydatne w systemie z wieloma kontami użytkowników, które chcesz oddzielić. Ty wciąż:

• Ufaj aplikacji CrashPlan, że nie przechowuje ani nie przesyła pliku certyfikatu lub hasła certyfikatu
• Zaufaj Code42, aby nie podejmować żadnych prób przechowywania tych danych

Główną zaletą jest to, że Code42 nie może odpowiedzieć na zewnętrzne żądanie twojego certyfikatu tak łatwo, jak to możliwe, jeśli używasz certyfikatów depozytowych, musieliby umyślnie poinstruować lokalną aplikację CrashPlan, aby odzyskała twój klucz certyfikatu z komputera i dostarczyła go do nich . Byłoby to oczywiście dla nich ogromne ryzyko z powodu upadku biznesu, gdyby taka decyzja kiedykolwiek stała się znana opinii publicznej.

Jeszcze jeden istotny punkt: najwyraźniej zawsze przechowują plik certyfikatu w formie niezaszyfrowanej na komputerze lokalnym. Więc jeśli jesteś głośnym celem, możliwe jest, że ktoś może uzyskać zaszyfrowane dane z CrashPlan, a następnie wykonać prosty atak na komputerze osobistym w celu odzyskania niezaszyfrowanego pliku certyfikatu.

Zatem odpowiedź na twoje pytanie sprowadza się do „czy ufasz Code42 w ochronie twoich danych przed zagrożeniami zarówno wewnętrznymi, jak i zewnętrznymi?” Jeśli odpowiedź brzmi „nie”, szyfrowanie danych przy użyciu czegoś takiego jak TrueCrypt jako drugiej warstwy ochrony to świetny pomysł.

PS - Za co warto, uwielbiam, że CrashPlan domyślnie dość mocno szyfruje, więc nie interpretuj tego jako zawstydzającego postu CrashPlan - chcę tylko pomóc użytkownikom zrozumieć, komu ufają :-)

Ciekawą alternatywą może być użycie EncFS , szczególnie z flagą --reverse . Najwyraźniej jest port do systemu Windows, więc możesz zrobić to samo.

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

EDYCJA - pamiętaj o zapisaniu plików .encfs5 lub encfs6.xml, będą one znajdować się w oryginalnym katalogu w postaci zwykłego tekstu, a nie w katalogu kopii zapasowej, więc pamiętaj, aby je pobrać, ponieważ nie będzie można odzyskać zaszyfrowane pliki bez nich. (byłoby miło, gdyby pliki szyfrowane dołączały te do zaszyfrowanych plików, aby można było utworzyć samodzielne archiwum kopii zapasowej)

O ile nie posiadasz na swoim komputerze informacji związanych z patentem wartym wiele milionów dolarów, dokumenty związane z postępowaniem sądowym (takim jak sprawa sądowa ) lub informacje poufne dotyczące szyfrowania twojego planu awaryjnego komputera powinny wystarczyć.

Jeśli stawki są wysokie, hakerzy mogą zostać zatrudnieni, aby brutalnie wymusić twoje hasło.

Problem, jaki widzę, to szybkość / wydajność vs. bezpieczeństwo. Najpierw szyfrowanie za pomocą Truecrypt będzie prawdopodobnie wolne i nieefektywne, jak wspomniano wcześniej. Jednak po Snowden drugi problem polega na tym, że nawet jeśli utworzysz własny klucz niestandardowy na podstawie złożonego hasła, musisz ufać, że nigdy nie zostanie ono ujawnione. Czy to przez przypadek, czy dlatego, że NSA zmusiła amerykańską firmę, która jest właścicielem Crashplan, do wprowadzenia takiego mechanizmu. Szyfrowanie na kliencie lokalnym jest zaletą, ale jeśli ty (a raczej cała społeczność) nie widzisz kodu klienta, nie ma możliwości upewnienia się, że klucz, a tym samym dane, są bezpieczne.

Chociaż nie jest zgodny z ścisłą teorią tworzenia kopii zapasowych 3-2-1, będę używać zewnętrznego szyfrowanego dysku twardego wypełnionego rsnapshot i regularnie obracanego z innymi kopiami. Zastanawiałem się nad Crashplanem nad wszystkimi innymi opcjami chmurowymi, ale zniechęcająca mnie natura klienta. Gdyby mieli interfejs API, a EFF lub inne źródło FOSS zapewniały klienta, to ponownie bym się zastanowił.