Crashplan + TrueCrypt-やり過ぎ？

Crashplanにはすでにデータを暗号化するオプションがあります。選択すると、暗号化されたファイルがサーバーに保存されます。

Truecryptには確かにもっと多くのオプションがありますが、基本的な使い方としては、CrashPlanの暗号化で十分ではないでしょうか？

更新：CrashPlanを試した後、上記の暗号化が本物かどうかはわかりません。もちろん、それを開いて参照することはできないコンテナファイルが作成されますが、CrashPlanのWebサイトにアクセスすると、次のことができます。

• フォルダー構造全体を確認する
• 個々のファイルを見る
• 個々のファイルまたはファイルのグループを好きなように復元します。

暗号化は一方向のトラフィックであると想定されています。データが簡単に見える場合、暗号化であるかどうかはわかりません。暗号化されていない可能性があります。ここで何か不足していますか？

開示：私はCode42のCEOおよび創設パートナーです

やりすぎです。さらに悪いことに、リアルタイムの監視が機能せず、暗号化されたデータが圧縮できないため、バックアップが遅くなり、データ保護が遅延します。

プライベートデータパスワード（推奨）を使用するか、独自のキーを生成することにより、プライバシーが保証されます。（はい、あなたは私たちにこれを言うことを信頼する必要がありますが、あなたが個人的に真の暗号コードを研究/監査するソフトウェア/セキュリティの専門家でない限り、あなたは何か/誰かを信頼する必要があります。

非常に貴重なデータがあり、誰も信頼できない場合は、暗号化を2倍にするのが妥当です。ただし、その特定のデータセットに対してのみそれを行います。残りはCrashPlanに処理させてください。

私はTrueCryptユーザーですが、CrashPlanを使用している場合は、データをCrashPlanに送って処理する前に別の製品で暗号化することを絶対に避け、インターネット経由でプッシュします（パフォーマンスが低下する可能性が高いため、パフォーマンスが低下します）。多数の小さなWord文書が含まれている1GBのフォルダーを暗号化すると、突然、バックアップソフトウェアでは効率的に処理できない1GBの同種のデータの塊しかなくなります。そのため、これらのWordドキュメントの1つにピリオドを1つ追加し、再度保存すると、TrueCryptアーカイブファイルは完全に異なり、全体を再びバックアップする必要があります。私はCrashPlanの暗号化を信頼する傾向があります（これらのサービスの暗号化を信頼するか、信頼できるものを見つける必要があります）。ドメイン管理者のパスワードが記載された小さなテキストファイルがあり、二重に暗号化せずに夜眠るのは問題ありませんが、パフォーマンスへの影響はネットワーク帯域幅の増加とはるかに遅いバックアップになるため、大規模な暗号化ファイル（TrueCryptなど）は避けたいです。あなたが（おそらく）必要としないセキュリティの向上。あなたが弁護士である場合、または医療関連情報を持っている場合は、二重暗号化する法的義務を負っている可能性があります。あるいは、そのようなデータに対して暗号化が信頼できることをCode 42から何らかの法的保証を得ることができます（おそらくあなたはそのような状況でそれをする義務があるだろう、私は確信がない-仕事でこの種のデータに個人的にまだ出会っていない）。Dropbox（従業員の5％がメンテナンスとトラブルシューティングのためにユーザーが保存したデータにアクセスできることを認めている会社）を使用していた場合！

または短い答え：

...ええ、それはおそらくやり過ぎです。

簡潔な答え

注目すべきターゲットでない限り、おそらくそうです。

長い答え

CrashPlanは、パスワードで保護された証明書を使用してデータを暗号化するか、まったく暗号化しません。この要約では、証明書は、基本的には、名前が添付されたファイルに保存された紛らわしい巨大なパスワードと考えることができます。この証明書ファイルは一般的に暗号化されています。ファイルのクイックコピーではデータにアクセスするのに十分ではないことを確認するためです。証明書ファイルのパスワードも必要です。

ほとんどのCrashPlanユーザーは、いわゆるエスクロー証明書ストレージを使用している可能性が高く、Code42は証明書ファイルを暗号化された形式で保存します。パスワードを入力すると、これらの証明書ファイル自体が復号化され、生データの復号化に使用されます。これが、CrashPlan Webインターフェイスでデータを閲覧できる理由です。証明書のパスワードを入力すると、ソフトウェアは証明書を使用してデータにアクセスできます。これの主なセキュリティホール：

• 証明書を安全に保管するためにCode42 +従業員を信頼している
• Code42 +の従業員が証明書のパスワードを安全に保管しないことを信頼している
• 証明書ファイルまたはパスワードを要求する（召喚状など）機関（政府など）に証明書ファイルまたはパスワードを提供しないことをCode42 +従業員に信頼している
• 上で述べたように、証明書は非常に大きなパスワードです。誰かがそのファイルを入手した場合、そのファイルの使用を妨げるのは証明書のパスワードだけなので、作成したhunter42場合はかなり面倒です。基本的に、誰かが本当にやる気があり、適切なパスワードを選択しなかった場合、証明書のパスワードを破ることはかなり簡単です。

「カスタムキー」を使用することもできます（証明書ファイルを提供する場合など）。つまり、Code42は証明書をサーバーに保存しません。暗号化されたデータは引き続きサーバーに保存されますが、Webインターフェイスで表示したい場合は、ソフトウェアに証明書ファイルと証明書パスワードの両方を提供する必要があります。これが奇妙な部分です。これは、上記のオプションに比べて現実的な追加のセキュリティをほとんど提供しません。これは、多くのユーザーアカウントを個別に保持したいシステムで主に役立ちます。あなたはまだ：

• CrashPlanアプリケーションを信頼して、証明書ファイルまたは証明書パスワードを保存または送信しない
• Code42を信頼して、このデータを保存しようとしない

ここでの主な利点は、エスクロー証明書を使用する場合と同じくらい簡単にCode42が証明書の外部リクエストに応答できないことです。ローカルのCrashPlanアプリケーションに、コンピュータから証明書キーを取得してそれらに配信するように意図的に指示する必要があります。 。これは当然のことながら、そのような決定が公の知識になった場合、ビジネスの影響により、彼らにとって大きなリスクになります。

さらにもう1つ重要な点として、証明書ファイルは常に ローカルコンピュータの暗号化されていない形式で保存されているようです。したがって、注目を集めているターゲットの場合、誰かがCrashPlanから暗号化されたデータを取得し、パーソナルコンピュータに簡単な攻撃を実行して、暗号化されていない証明書ファイルを回復する可能性があります。

つまり、質問に対する答えは、「内部および外部の脅威からデータを保護することでCode42を信頼していますか？」ということになります。答えが「いいえ」の場合、TrueCryptなどを使用してデータを暗号化し、2番目の保護層として使用することをお勧めします。

PS-それが価値があるのは、CrashPlanがデフォルトでかなり重く暗号化するのが好きなので、これをバッシングCrashPlan投稿と解釈しないでください-ユーザーが信頼しているユーザーを理解できるようにしたいだけです:-)

特に興味深いのは、特に--reverseフラグを指定してEncFSを使用することです。どうやら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に暗号化されたファイルが含まれていると、自己完結型のバックアップアーカイブを作成できるので便利です）

数百万ドルの特許に関連する情報をPCに保持していない限り、訴訟などの訴訟に関連する文書や、PCのクラッシュプラン暗号化に関する情報を分類したもので十分です。

賭け金が十分に高い場合、パスワードを総当たり攻撃するハッカーが雇われる可能性があります。

私が見るところの問題は、速度/効率対セキュリティです。最初にTruecryptで暗号化すると、前述のように更新が遅くなり、非効率になります。ただし、Snowden後のもう1つの問題は、複雑なパスワードから独自のカスタムキーを作成した場合でも、これが漏洩しないことを信頼する必要があることです。偶然か、NSAがCrashplanを所有するアメリカの会社にそうするためのメカニズムを挿入することを強制したためか。ローカルクライアントでの暗号化はプラスポイントですが、あなた（またはコミュニティ全体）がクライアントコードを見ることができない限り、キー、つまりデータが安全であることを確認する方法はありません。

厳密な3-2-1バックアップ理論には従いませんが、rsnapshotを使用して入力され、定期的に他のコピーとローテーションされるオフサイト暗号化HDDを使用します。他のすべてのクラウドオプションよりもCrashplanを検討しましたが、クライアントの検証不可能な性質が私を先延ばしにしました。彼らがAPIを持っていて、EFFまたは他のFOSSソースがクライアントに提供していたら、私は再考します。