Crashplan + TrueCrypt - Excesso de habilidade?

O Crashplan já tem uma opção para criptografar os dados. E, se selecionado, isso armazena o arquivo criptografado no servidor.

O Truecrypt certamente tem muito mais opções, mas para uso básico, a criptografia do CrashPlan não seria suficiente?

Atualização : Depois de experimentar o CrashPlan, não tenho certeza se a criptografia mencionada é real. Claro, ele cria um arquivo de contêiner que você não pode abrir e examinar, mas se você for ao site do CrashPlan, poderá:

• veja toda a sua estrutura de pastas
• ver arquivos individuais
• restaure arquivos individuais ou grupo de arquivos da maneira que desejar.

A criptografia deve ser tráfego unidirecional, se os dados estiverem disponíveis à vista, então não tenho certeza se é criptografia. Talvez codificado, mas não criptografado. Estou faltando alguma coisa aqui?

Divulgação: Sou o CEO e um dos sócios fundadores da Code42

É um exagero. Para piorar a situação, isso desacelerará seus backups e atrasará a proteção de dados, pois o monitoramento em tempo real não funcionará e os dados criptografados não são compactáveis.

Ao usar a senha de dados privados (recomendado) ou gerar sua própria chave, você garante a privacidade. (Sim, você deve confiar em nós para dizer isso, mas, a menos que você seja um especialista em software / segurança que estuda / audita pessoalmente o código do truecrypt, precisa confiar em algo / em alguém.

Se você tem dados tão preciosos que não pode confiar em ninguém, dobrar a criptografia é razoável. No entanto, eu faria isso apenas para esse conjunto específico de dados - deixe o CrashPlan lidar com o resto.

Eu sou um usuário TrueCrypt, mas se estivesse usando o CrashPlan, definitivamente evitaria criptografar meus dados com outro produto antes de enviá-los ao CrashPlan para manipular e enviar pela Internet (pois o desempenho provavelmente seria bom -> doloroso). Se você criptografar uma pasta de 1 GB, que contém vários documentos minúsculos do Word, de repente tudo o que você tem é um blob homogêneo de dados de 1 GB que não pode ser tratado com eficiência pelo seu software de backup. Portanto, se você adicionar um único período extra a um desses documentos do Word e salvar novamente, seu arquivo TrueCrypt agora é INTEIRAMENTE diferente e é necessário fazer backup de TODO o COMPLETO. Eu estaria inclinado a confiar na criptografia do CrashPlan (você precisa confiar na criptografia desses serviços ou encontrar um em que confie). Se você tinha um pequeno arquivo de texto com senhas de administrador de domínio e pode " não durma à noite sem criptografar duas vezes, tudo bem, mas você deseja evitar arquivos criptografados em massa (TrueCrypt ou outros), pois o impacto no desempenho será um aumento na largura de banda da rede e backups muito mais lentos - tudo por um aumento da segurança que você (sem dúvida) não precisa. Se você é um advogado ou possui informações médicas, pode ter uma obrigação legal de criptografar duas vezes ou talvez possa obter algum tipo de garantia legal do Código 42 de que a criptografia pode ser confiável para esse tipo de dados ( talvez você tenha o dever de fazer isso em tal situação, não tenho certeza - ainda não me deparei com esse tipo de dados no trabalho). Se você estava usando o Dropbox (uma empresa que admite que 5% de seus funcionários têm acesso aos dados armazenados pelos usuários para manter e solucionar problemas!)

Ou a resposta curta:

... Sim, provavelmente é um exagero.

Resposta curta

Provavelmente sim, a menos que você seja um alvo de alto perfil.

Resposta longa

O CrashPlan criptografa dados usando certificados protegidos por senha ou nenhuma criptografia. Neste resumo, você pode pensar em um certificado como basicamente uma senha enorme armazenada em um arquivo com seu nome anexado. Esse arquivo de certificado geralmente é criptografado, apenas para garantir que uma cópia rápida do arquivo não seja suficiente para acessar os dados - você também precisa da senha do arquivo de certificado.

A maioria dos usuários do CrashPlan provavelmente usa o que é chamado armazenamento de certificado de garantia, em que o Code42 armazena os arquivos de certificado para você em forma criptografada. Quando você fornece sua senha, esses arquivos de certificado são descriptografados e são usados ​​para descriptografar seus dados brutos. É por isso que a interface da web do CrashPlan pode permitir que você navegue nos seus dados - depois de fornecer a senha do certificado, o software deles pode acessar os dados usando o certificado. As principais falhas de segurança com isso:

• Você confia nos funcionários do Code42 + para armazenar seu certificado com segurança
• Você confia que os funcionários do Code42 + nunca armazenarão sua senha de certificado de maneira insegura
• Você confia que os funcionários do Code42 + não fornecerão seu arquivo ou senha de certificado a qualquer agência (como um governo) que solicite (por exemplo, intimação)
• Como mencionei acima, seu certificado é uma senha muito grande . Se alguém colocar as mãos nesse arquivo, a única coisa que os impedirá de usá-lo é a senha do seu certificado; portanto, se você o criou, hunter42está muito ferrado. Basicamente, é provável que quebrar a senha do certificado seja bastante fácil se alguém estiver realmente motivado e você não escolher uma boa senha.

Você também pode usar uma "chave personalizada" (por exemplo, quando você fornece o arquivo de certificado). Isso significa que o Code42 não armazena seu certificado em seus servidores. Eles ainda armazenam dados criptografados em seus servidores, mas se você quiser vê-los na interface da web, precisará fornecer ao software os arquivos de certificado e a senha do certificado. Agora, aqui está a parte estranha: isso oferece quase nenhuma segurança adicional realista sobre a opção acima, é principalmente útil para um sistema com muitas contas de usuário que você deseja manter separadas. Você ainda:

• Confie no aplicativo CrashPlan para não armazenar ou transmitir seu arquivo ou senha de certificado
• Confie no Code42 para não tentar armazenar esses dados

O principal benefício aqui é que o Code42 não pode responder a uma solicitação externa de seu certificado tão facilmente quanto possível se você usar certificados de garantia, eles terão que instruir voluntariamente o aplicativo CrashPlan local para recuperar sua chave de certificado do computador e entregá-la a eles . Naturalmente, isso seria um grande risco para eles, devido às consequências dos negócios, se essa decisão se tornar pública.

Mais um ponto relevante: aparentemente eles sempre armazenam seu arquivo de certificado em formato não criptografado no computador local. Portanto, se você é um alvo de alto perfil, é possível que alguém possa adquirir seus dados criptografados do CrashPlan e executar um ataque simples no seu computador pessoal para recuperar o arquivo de certificado não criptografado.

Portanto, a resposta para sua pergunta se resume a "você confia no Code42 para proteger seus dados contra ameaças internas e externas?" Se a resposta for não, é uma ótima idéia criptografar seus dados usando algo como TrueCrypt como uma segunda camada de proteção.

PS - Pelo que vale a pena, eu amo o CrashPlan criptografar bastante por padrão, por isso não o interprete como uma postagem contundente do CrashPlan - eu só quero ajudar os usuários a entender em quem eles estão confiando :-)

Uma alternativa interessante pode ser usando encfs , especificamente com o --reverse bandeira. Aparentemente, existe uma porta para o Windows, então você poderá fazer a mesma coisa lá.

   --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 - Não se esqueça de salvar os arquivos .encfs5 ou encfs6.xml, eles estarão localizados no diretório de texto sem formatação original e não no diretório de backup; portanto, você precisará pegá-los, pois não conseguirá recuperar seu arquivo. arquivos criptografados sem eles. (seria bom se o encfs incluísse os arquivos criptografados para que você pudesse criar um arquivo de backup independente)

A menos que você tenha informações no seu PC relacionadas a uma patente de vários milhões de dólares, documentos relacionados a ações legais (como uma ação judicial) ou informações classificadas na criptografia do plano de colisão do seu PC devem ser suficientes.

Se as apostas forem altas, hackers podem ser contratados para fazer força bruta na sua senha.

A questão que eu vejo é velocidade / eficiência versus segurança. Ao criptografar com o Truecrypt primeiro, as atualizações provavelmente serão lentas e ineficientes conforme mencionado anteriormente. No entanto, após o Snowden, a outra questão é que, mesmo se você criar sua própria chave personalizada a partir de uma senha complexa, precisará confiar que isso nunca será vazado. Seja por acidente ou porque a NSA forçou a empresa americana proprietária da Crashplan a inserir um mecanismo para fazê-lo. Criptografar no cliente local é um ponto positivo, mas, a menos que você (ou melhor, a comunidade em geral) possa ver o código do cliente, não há como garantir que sua chave e, portanto, seus dados estejam seguros.

Embora não siga a estrita teoria de backup 3-2-1, vou usar um HDD criptografado fora do local preenchido com o rsnapshot e rotacionado regularmente com outras cópias. Eu considerei o Crashplan sobre todas as outras opções de nuvem, mas a natureza não verificável do cliente me afastou. Se eles tivessem uma API e o EFF ou outra fonte FOSS forneça ao cliente, então eu reconsideraria.