Crashplan + TrueCrypt-やり過ぎ？
Crashplanには、データを暗号化するオプションがすでにあります。選択すると、暗号化されたファイルがサーバーに保存されます。
Truecryptには確かにもっと多くのオプションがありますが、基本的な使用法では、CrashPlanの暗号化で十分ではないでしょうか？
更新：CrashPlanを試した後、上記の暗号化が実際のものかどうかわかりません。確かに、それはあなたが開いて調べることができないコンテナファイルを作成します、しかしあなたがCrashPlanのウェブサイトに行くならば、あなたはすることができます：
- フォルダ構造全体を見る
- 個々のファイルを見る
- 個々のファイルまたはファイルのグループを任意の方法で復元します。
暗号化は一方通行であると想定されており、データが一目で利用できる場合、それが暗号化であるかどうかはわかりません。暗号化されているかもしれませんが、暗号化されていません。ここで何かが足りませんか？
開示：私はCode42のCEO兼創設パートナーです
それはやり過ぎです。さらに悪いことに、リアルタイムモニタリングが機能せず、暗号化されたデータが圧縮できないため、バックアップが遅くなり、データ保護が遅れます。
プライベートデータパスワード（推奨）を使用するか、独自のキーを生成することで、プライバシーが確保されます。 （はい、あなたはこれを言うことで私たちを信頼する必要があります、しかしあなたがtruecryptコードを個人的に研究/監査するソフトウェア/セキュリティの専門家でない限り、あなたは何か/誰かを信頼しなければなりません。
誰も信用できないほど貴重なデータがある場合は、暗号化を2倍にするのが妥当です。ただし、それはその特定のデータセットに対してのみ行います。残りはCrashPlanに処理させます。
私はTrueCryptユーザーですが、CrashPlanを使用している場合は、データをCrashPlanにフィードして処理し、インターネット経由でプッシュする前に、別の製品でデータを暗号化することは絶対に避けます（パフォーマンスはおそらく良好から苦痛になるため）。多数の小さなWord文書を含む1GBのフォルダーを暗号化すると、突然、バックアップソフトウェアで効率的に処理できない1GBの均質なデータの塊しかなくなります。したがって、これらのWordドキュメントの1つにピリオドを1つ追加してから再保存すると、TrueCryptアーカイブファイルは完全に異なり、全体を再度バックアップする必要があります。私はCrashPlanの暗号化を信頼する傾向があります（これらのサービスの暗号化を信頼するか、信頼できるものを見つける必要があります）。ドメイン管理者のパスワードが記載された小さなテキストファイルがあり、それを二重に暗号化せずに夜間に眠ることができない場合は問題ありませんが、パフォーマンスへの影響があるため、大量の暗号化ファイル（TrueCryptなど）は避けたいと考えています。ネットワーク帯域幅の増加、およびはるかに遅いバックアップ-すべてあなたが（おそらく）必要としないセキュリティの増加のために。あなたが弁護士であるか、医療関連の情報を持っている場合は、二重暗号化する法的義務があるかもしれません。あるいは、暗号化がその種のデータに対して信頼できるというコード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のバッシング投稿として解釈しないでください-ユーザーが誰を信頼しているかを理解できるようにしたいだけです:-)
興味深い代替手段は、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に暗号化されたファイルが含まれていると便利です）
私が見ている問題は、速度/効率とセキュリティです。最初にTruecryptで暗号化することにより、前述のように更新が遅く非効率になる可能性があります。ただし、Snowden後のもう1つの問題は、複雑なパスワードから独自のカスタムキーを作成した場合でも、これが漏洩しないことを信頼する必要があることです。偶然であろうと、NSAが、Crashplanを所有するアメリカの会社に、そうするためのメカニズムを挿入することを強制したためであろうと。ローカルクライアントでの暗号化はプラスのポイントですが、あなた（またはコミュニティ全体）を除いては）クライアントコードを見ることができる場合、キー、つまりデータが安全であることを確認する方法はありません。
厳密な3-2-1バックアップ理論には従いませんが、rsnapshotを使用して入力され、他のコピーと定期的にローテーションされるオフサイトの暗号化されたHDDを使用します。私は他のすべてのクラウドオプションよりもCrashplanを検討しましたが、クライアントの検証不可能な性質が私を先延ばしにしました。彼らがAPIを持っていて、EFFまたは他のFOSSソースがクライアントを提供していたら、私は再考したいと思います。
数百万ドルの特許に関連する情報をPCに保持していない限り、訴訟（訴訟など）に関連するドキュメント、またはPCに機密情報を持っている場合を除きますクラッシュプランの暗号化で十分です。
賭け金が十分に高い場合は、ハッカーを雇ってパスワードを総当たり攻撃する可能性があります。