Crashplan + TrueCrypt - Overkill?

Crashplan hat bereits eine Option zum Verschlüsseln der Daten. Wenn diese Option ausgewählt ist, wird die verschlüsselte Datei auf dem Server gespeichert.

Truecrypt bietet sicherlich viel mehr Optionen, aber würde die Verschlüsselung von CrashPlan für die grundlegende Verwendung nicht ausreichen?

Update : Nachdem ich CrashPlan ausprobiert habe, bin ich mir nicht sicher, ob die besagte Verschlüsselung echt ist. Sicher, es wird eine Containerdatei erstellt, die Sie nicht öffnen und einsehen können. Wenn Sie jedoch auf die CrashPlan-Website gehen, können Sie:

• Sehen Sie sich Ihre gesamte Ordnerstruktur an
• siehe einzelne Dateien
• Stellen Sie einzelne Dateien oder Gruppen von Dateien nach Ihren Wünschen wieder her.

Verschlüsselung soll Einwegverkehr sein. Wenn die Daten in Sichtweite verfügbar sind, bin ich mir nicht sicher, ob es sich um Verschlüsselung handelt. Möglicherweise verschlüsselt, aber nicht verschlüsselt. Vermisse ich hier etwas?

Offenlegung: Ich bin der CEO und Gründungspartner von Code42

Es ist übertrieben. Um die Sache noch schlimmer zu machen, werden Ihre Backups verlangsamt und der Datenschutz verzögert, da die Echtzeitüberwachung nicht funktioniert und verschlüsselte Daten nicht komprimierbar sind.

Durch die Verwendung eines Kennworts für private Daten (empfohlen) oder die Erstellung eines eigenen Schlüssels wird die Privatsphäre gewährleistet. (Ja, Sie müssen uns vertrauen, wenn Sie dies sagen, aber wenn Sie kein Software- / Sicherheitsexperte sind, der den TrueCrypt-Code persönlich studiert / prüft, müssen Sie etwas / jemandem vertrauen.

Wenn Sie Daten haben, die so wertvoll sind, dass Sie niemandem vertrauen können, ist es sinnvoll, die Verschlüsselung zu verdoppeln. Ich würde das jedoch nur für diesen bestimmten Datensatz tun - lassen Sie CrashPlan den Rest erledigen.

Ich bin ein TrueCrypt-Benutzer, aber wenn ich CrashPlan verwenden würde, würde ich definitiv vermeiden, meine Daten mit einem anderen Produkt zu verschlüsseln, bevor ich sie an CrashPlan weitergebe, um sie zu verarbeiten und dann über das Internet zu übertragen (da die Leistung höchstwahrscheinlich von gut -> schmerzhaft) würde. Wenn Sie einen 1-GB-Ordner verschlüsseln, der zahlreiche winzige Word-Dokumente enthält, haben Sie plötzlich nur noch einen homogenen 1-GB-Datenblock, der von Ihrer Sicherungssoftware nicht effizient verarbeitet werden kann. Wenn Sie also einem dieser Word-Dokumente einen einzelnen zusätzlichen Punkt hinzufügen und dann erneut speichern, ist Ihre TrueCrypt-Archivdatei jetzt VOLLSTÄNDIG anders, und das GANZE Ding muss erneut gesichert werden. Ich würde gerne der Verschlüsselung von CrashPlan vertrauen (Sie müssen der Verschlüsselung dieser Dienste vertrauen oder einen finden, dem Sie vertrauen). Wenn Sie eine kleine Textdatei mit Domänenadministratorkennwörtern hatten und können ' Wenn Sie nachts nicht schlafen, ohne es doppelt zu verschlüsseln, ist das in Ordnung, aber Sie sollten massive verschlüsselte Dateien (TrueCrypt oder andere) vermeiden, da die Auswirkungen auf die Leistung eine Erhöhung der Netzwerkbandbreite und viel langsamere Sicherungen sind Erhöhung der Sicherheit, die Sie (wohl) nicht brauchen. Wenn Sie Anwalt sind oder über medizinische Informationen verfügen, besteht möglicherweise eine gesetzliche Verpflichtung zur Doppelverschlüsselung, oder Sie können aus Code 42 eine rechtliche Bestätigung erhalten, dass die Verschlüsselung für diese Art von Daten vertrauenswürdig ist ( Vielleicht hätten Sie die Pflicht, dies in einer solchen Situation zu tun. Ich bin mir nicht sicher, ob ich persönlich noch nicht auf diese Art von Daten bei der Arbeit gestoßen bin. Wenn Sie Dropbox verwendet haben (ein Unternehmen, das zugibt, dass 5% seiner Mitarbeiter Zugriff auf die von Benutzern gespeicherten Daten haben, um diese zu pflegen und Fehler zu beheben!

Oder die kurze Antwort:

... ja, es ist wahrscheinlich übertrieben.

Kurze Antwort

Wahrscheinlich ja, es sei denn, Sie sind ein hochkarätiges Ziel.

Lange Antwort

CrashPlan verschlüsselt Daten entweder mit passwortgeschützten Zertifikaten oder überhaupt nicht. In dieser Zusammenfassung können Sie sich ein Zertifikat als ein verdammt großes Passwort vorstellen, das in einer Datei gespeichert ist, an die Ihr Name angehängt ist. Diese Zertifikatdatei wird normalerweise verschlüsselt, um sicherzustellen, dass eine schnelle Kopie der Datei nicht ausreicht, um auf die Daten zuzugreifen. Sie benötigen auch das Kennwort für die Zertifikatdatei.

Die meisten CrashPlan-Benutzer verwenden wahrscheinlich den sogenannten Escrow-Zertifikatspeicher, in dem Code42 die Zertifikatdateien für Sie in verschlüsselter Form speichert. Wenn Sie Ihr Kennwort angeben, werden diese Zertifikatdateien selbst entschlüsselt und dann zum Entschlüsseln Ihrer Rohdaten verwendet. Aus diesem Grund können Sie über die CrashPlan-Weboberfläche Ihre Daten durchsuchen. Nachdem Sie das Zertifikatkennwort angegeben haben, kann die Software mithilfe des Zertifikats auf die Daten zugreifen. Die wichtigsten Sicherheitslücken dabei:

• Sie vertrauen darauf, dass Mitarbeiter von Code42 + Ihr Zertifikat sicher aufbewahren
• Sie vertrauen darauf, dass Mitarbeiter von Code42 + Ihr Zertifikatspasswort niemals unsicher speichern
• Sie vertrauen darauf, dass Mitarbeiter von Code42 + Ihre Zertifikatsdatei oder Ihr Passwort keiner Behörde (z. B. einer Regierung) geben, die dies anfordert (z. B. vorladen)
• Wie oben erwähnt, ist Ihr Zertifikat ein sehr großes Passwort. Wenn jemand diese Datei in die Hände bekommt, ist das einzige, was ihn davon abhält, sie zu verwenden, Ihr Zertifikatspasswort. Wenn Sie sie also erstellt haben, sind hunter42Sie ziemlich durcheinander. Grundsätzlich ist es wahrscheinlich ziemlich einfach, Ihr Zertifikat-Passwort zu brechen, wenn jemand wirklich motiviert ist und Sie kein gutes Passwort gewählt haben.

Sie können auch einen "benutzerdefinierten Schlüssel" verwenden (z. B. wenn Sie die Zertifikatdatei bereitstellen). Dies bedeutet, dass Code42 sein Zertifikat nicht auf ihren Servern speichert. Sie speichern weiterhin verschlüsselte Daten auf ihren Servern. Wenn Sie diese jedoch in der Weboberfläche anzeigen möchten, müssen Sie ihrer Software sowohl die Zertifikatdatei als auch das Zertifikatkennwort bereitstellen. Hier ist der seltsame Teil: Dies bietet fast keine realistische zusätzliche Sicherheit gegenüber der oben genannten Option. Es ist meistens nützlich für ein System mit vielen Benutzerkonten, die Sie getrennt halten möchten. Sie immer noch:

• Vertrauen Sie der CrashPlan-Anwendung, dass sie Ihre Zertifikatdatei oder Ihr Zertifikatkennwort nicht speichert oder überträgt
• Vertrauen Sie Code42, um nicht zu versuchen, diese Daten zu speichern

Der Hauptvorteil hierbei ist, dass Code42 nicht so einfach auf eine externe Anfrage für Ihr Zertifikat antworten kann, wie dies bei Verwendung von Treuhandzertifikaten der Fall wäre. Sie müssten ihre lokale CrashPlan-Anwendung absichtlich anweisen, Ihren Zertifikatschlüssel von Ihrem Computer abzurufen und an sie zu senden . Dies wäre natürlich ein großes Risiko für sie aufgrund der geschäftlichen Auswirkungen, falls eine solche Entscheidung jemals öffentlich bekannt werden sollte.

Ein weiterer relevanter Punkt: Sie speichern Ihre Zertifikatdatei anscheinend immer unverschlüsselt auf Ihrem lokalen Computer. Wenn Sie also ein hochkarätiges Ziel sind, ist es möglich, dass jemand Ihre verschlüsselten Daten von CrashPlan abruft und dann einen einfachen Angriff auf Ihren PC ausführt, um die unverschlüsselte Zertifikatdatei wiederherzustellen.

Die Antwort auf Ihre Frage lautet also: "Vertrauen Sie Code42 beim Schutz Ihrer Daten vor internen und externen Bedrohungen?" Wenn die Antwort Nein lautet, ist es eine gute Idee, Ihre Daten mit TrueCrypt als zweite Schutzschicht zu verschlüsseln.

PS: Für das, was es wert ist, finde ich es toll, dass CrashPlan standardmäßig ziemlich stark verschlüsselt. Interpretieren Sie dies also nicht als verprügelten CrashPlan-Beitrag. Ich möchte den Benutzern nur helfen, zu verstehen, wem sie vertrauen :-)

Eine interessante Alternative könnte die Verwendung von EncFS sein , insbesondere mit dem Flag --reverse . Es gibt anscheinend einen Port für Windows, sodass Sie dort möglicherweise dasselbe tun können.

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

BEARBEITEN - Stellen Sie sicher, dass Sie Ihre .encfs5- oder encfs6.xml-Dateien speichern. Sie befinden sich im ursprünglichen Klartextverzeichnis und nicht im Sicherungsverzeichnis. Sie müssen also sicherstellen, dass Sie diese abrufen, da Sie Ihre nicht wiederherstellen können verschlüsselte Dateien ohne sie. (Es wäre schön, wenn encfs diejenigen mit den verschlüsselten Dateien enthalten würde, damit Sie ein eigenständiges Backup-Archiv erstellen können.)

Sofern Sie auf Ihrem PC keine Informationen zu einem Patent im Wert von mehreren Millionen Dollar haben, sollten Dokumente im Zusammenhang mit rechtlichen Schritten (z. B. einer Klage) oder Verschlusssachen zur Verschlüsselung Ihres PC- Absturzplans ausreichen.

Wenn der Einsatz hoch genug ist, können Hacker eingestellt werden, um Ihr Passwort brutal zu erzwingen.

Das Problem, wie ich es sehe, ist Geschwindigkeit / Effizienz gegen Sicherheit. Wenn Sie zuerst mit Truecrypt verschlüsseln, sind die Aktualisierungen wahrscheinlich langsam und ineffizient, wie bereits erwähnt. Nach Snowden besteht das andere Problem darin, dass Sie darauf vertrauen müssen, dass dieser niemals durchgesickert ist, selbst wenn Sie Ihren eigenen benutzerdefinierten Schlüssel aus einem komplexen Kennwort erstellen. Ob aus Versehen oder weil die NSA die amerikanische Firma, der Crashplan gehört, gezwungen hat, einen Mechanismus dafür einzufügen. Die Verschlüsselung auf dem lokalen Client ist ein Pluspunkt. Wenn Sie (oder vielmehr die Community insgesamt) den Clientcode nicht sehen können, können Sie nicht sicher sein, ob Ihr Schlüssel und damit Ihre Daten sicher sind.

Obwohl es nicht der strengen 3-2-1-Sicherungstheorie folgt, werde ich eine mit rsnapshot bestückte und regelmäßig mit anderen Kopien gedrehte Offsite-verschlüsselte Festplatte verwenden. Ich habe Crashplan über alle anderen Cloud-Optionen hinweg betrachtet, aber die nicht überprüfbare Natur des Clients hat mich abgeschreckt. Sollten sie eine API haben und der EFF oder eine andere FOSS-Quelle den Client bereitstellen, würde ich es mir noch einmal überlegen.