Crashplan + TrueCrypt - Overkill?

9

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

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

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

  • veja toda a estrutura de pastas
  • veja arquivos individuais
  • restaure arquivos individuais ou grupos de arquivos de qualquer maneira que você goste.

A criptografia deve ser um 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?

    
por Mrchief 25.04.2013 / 17:58

6 respostas

12

Divulgação: Eu sou o CEO e um sócio fundador do Code42

É um exagero. Para piorar a situação, ele irá desacelerar seus backups e atrasar a proteção de dados, já que 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ê tem a privacidade garantida. (Sim, você tem que confiar em nós para dizer isso, mas a menos que você seja um especialista em software / segurança pessoalmente estudando / auditando o código TrueCrypt, você precisa confiar em algo / 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 só faria isso para esse conjunto específico de dados - deixe o CrashPlan lidar com o resto.

    
por 30.04.2013 / 16:35
4

Eu sou um usuário do TrueCrypt, mas se eu estivesse usando o CrashPlan, eu definitivamente evitaria criptografar meus dados com outro produto antes de alimentá-lo no CrashPlan para manipular a internet (como 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 que você tem é um bloco homogêneo de dados de 1 GB que não pode ser manipulado com eficiência pelo software de backup. Portanto, se você adicionar um único período extra a um desses documentos do Word, salve novamente, seu arquivo TrueCrypt agora é totalmente diferente, e todo o processo precisa ser feito novamente. Eu estaria inclinado a confiar na criptografia do CrashPlan (você precisa confiar na criptografia desses serviços ou encontrar um em que você confie). Se você tivesse um pequeno arquivo de texto com senhas de administrador de domínio e não pudesse dormir à noite sem criptografá-lo duplamente, tudo bem, mas você gostaria de evitar arquivos criptografados massivos (TrueCrypt ou outros), pois o impacto no desempenho seria um aumento na largura de banda da rede e backups muito mais lentos - tudo para um aumento na segurança que você (sem dúvida) não precisa. Se você é um advogado, ou tem informações relacionadas à medicina, então você pode ter a obrigação legal de criptografar duas vezes, ou talvez você 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 encontrei pessoalmente 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!), A criptografia é essencial para qualquer coisa além da sua lista de compras, mas eu seria inclinado a confiar em serviços que oferecem criptografia como parte do pacote).

Ou a resposta curta:

... sim, provavelmente é um exagero.

    
por 04.05.2013 / 04:47
3

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 o seu nome anexado a ele. Este arquivo de certificado é normalmente 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 de armazenamento de certificado de custódia, onde o Code42 armazena os arquivos de certificado para você de 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 web do CrashPlan pode permitir que você navegue pelos 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 nos funcionários do Code42 + para nunca armazenar sua senha de certificado de maneira insegura
  • Você confia nos funcionários do Code42 + para não fornecer seu arquivo de certificado ou senha 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, então se você fez isso hunter42 , você está muito enganado. Basicamente, quebrar sua senha de certificado é bem fácil se alguém está realmente motivado e você não escolheu 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 o arquivo de certificado e a senha do certificado. Ora aqui está a parte estranha: isso oferece quase nenhuma segurança adicional realista sobre a opção acima, é mais ú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 de certificado ou senha do certificado
  • Confie no Code42 para não tentar armazenar esses dados

O principal benefício aqui é que o Code42 não pode responder a um pedido externo do seu certificado tão facilmente quanto poderiam se você usasse certificados de custódia, eles teriam que instruir intencionalmente seu aplicativo CrashPlan local para recuperar sua chave de certificado do seu computador e entregar isso para eles. Isso naturalmente seria um grande risco para eles devido às conseqüências do negócio, caso tal decisão se tornasse de conhecimento público.

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

Assim, a resposta à 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, criptografar seus dados usando algo como TrueCrypt como uma segunda camada de proteção é uma ótima idéia.

PS - Por que vale a pena, eu amo que o CrashPlan criptografa bastante por padrão, então não interprete isso como um post do CrashPlan - eu só quero ajudar os usuários a entenderem quem eles estão confiando: -)

    
por 03.09.2014 / 06:21
2

Uma alternativa interessante pode estar usando o EncFS , especificamente com o sinalizador - reverse . Há aparentemente uma porta para o Windows, então você pode 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 - Certifique-se de salvar seus arquivos .encfs5 ou encfs6.xml, eles estarão localizados no diretório de texto original e não no diretório de backup, então você precisa ter certeza de pegar aqueles que você não será capaz para recuperar seus arquivos criptografados sem eles. (seria bom se os encfs incluíssem aqueles com os arquivos criptografados para que você pudesse criar um arquivo de backup independente)

    
por 28.10.2014 / 19:40
0

A menos que você tenha informações sobre seu PC relacionadas a uma patente multimilionária, documentos relacionados a ações legais (como uma ação judicial) ou que tenham informações classificadas no seu PC criptografia de planos de ação devem ser suficientes.

Se as apostas forem altas o suficiente, hackers poderão ser contratados para forçar a sua senha.

    
por 27.04.2013 / 18:40
0

A questão que vejo é velocidade / eficiência versus segurança. Ao criptografar com o Truecrypt primeiro, as atualizações provavelmente serão lentas e ineficientes, como mencionado anteriormente. No entanto, pós-Snowden, o outro problema é que, mesmo que você crie sua própria chave personalizada a partir de uma senha complexa, você deve confiar que isso nunca será perdido. 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 a comunidade em geral) consiga ver o código do cliente, não há como garantir que sua chave e 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 rsnapshot e rotacionado regularmente com outras cópias. Eu considerei Crashplan sobre todas as outras opções de nuvem, mas a natureza não verificável do cliente me colocou fora. Se eles tivessem uma API e a EFF ou outra fonte FOSS fornecesse o cliente, então eu reconsideraria.

    
por 10.02.2015 / 02:12