Estratégia de backup para o eCryptfs

Question

Nós temos uma pequena rede com um servidor Ubuntu no meio e notebooks do Ubuntu por perto. Todos os notebooks usam o eCryptfs para criptografar todo o diretório de usuários. Normalmente, existem dois ou mais usuários por notebook. O procedimento de backup permanece dentro da rede, portanto, estamos bem com a transferência dos arquivos não criptografados para o servidor. Gostaríamos de ir com uma solução baseada em rsync , mas estão bem com os outros também.

Tivemos dificuldades ao tentar fazer o backup dos diretórios home dos notebooks, o que nos trouxe grandes dores de cabeça. Tudo se resume a isto:

1. Se o usuário A estiver conectado, o diretório pessoal será descriptografado e os arquivos criptografados em /home/.ecryptfs/A serão bloqueados contra a leitura de outros processos (o que é bom)

2. Se o usuário B estiver não logado, seu diretório pessoal não será descriptografado, haverá apenas os arquivos criptografados em /home/.ecryptfs/B .

3. Precisamos ter um script de backup, que possa ser executado, enquanto o usuário A estiver logado (porque ela o inicia manualmente no nosso caso) e o usuário B pode ou não estar logado (geralmente não). / p>

Agora a pergunta é: O que devemos fazer backup? Se formos para os dados criptografados, não é possível fazer o backup do material do usuário A. Dados descriptografados significam, por outro lado, que o usuário B deve estar logado também. E misturar os dois leva a um tempo divertido, quando se trata de restaurar algo.

Há talvez outras soluções para esse problema que sentimos falta?

    

Answer 1

Tem certeza de que /home/.ecryptfs/A está bloqueado para leitura? Eu uso ecryptfs e enquanto estou logado e posso navegar e ler os arquivos em /home/.ecryptfs/myusername/.Private . Eu apenas tentei entrar nesse diretório (e subdiretórios) e abrir arquivos (usando vim -b ) e consegui lê-los bem. Eu certamente os quero trancados para escrever, mas não vejo por que eles estariam trancados para ler. Qual versão do sistema operacional você está usando? (Eu estou no Ubuntu Lucid 10.04). Talvez faça uma pergunta separada sobre erros que você está recebendo, porque talvez algo esteja causando o problema.

Para responder diretamente à sua pergunta, faça o backup do conteúdo de /home/.ecryptfs/ . Isso fará backup (cópias criptografadas) de todos os arquivos para todos os usuários.

Além disso, você deve ser capaz de descriptografar os arquivos, se necessário. Então você deve armazenar a senha não-embrulhada em algum lugar seguro, caso o usuário esqueça sua senha, saia ... Para obtê-la, execute o usuário

ecryptfs-unwrap-passphrase

enquanto estiver logado e armazene o resultado em algum lugar. É pequeno o suficiente para que você possa escrevê-lo ( double triplo) e armazená-lo em um cofre, ou fazer com que duas pessoas mantenham metade de cada uma ou de algumas, dependendo da quantidade de segurança necessária. / p>

Caso contrário, você precisaria de /home/.ecryptfs/*/.ecryptfs/wrapped-passphrase e as senhas dos usuários.

Você também deve observar que o rsync não poderá acelerar transferências de arquivos ao sincronizar dados criptografados. Qualquer alteração no arquivo não criptografado alterará completamente o arquivo criptografado. E a compactação não funcionará realmente com dados criptografados. Isso não deve ser um grande problema para o seu caso, onde a sincronização é através de uma LAN, mas pode ser importante para outras pessoas que estão lendo esta questão. Embora o rsync ainda possa verificar se um arquivo criptografado não foi alterado, não será necessário transferir novamente os arquivos inalterados.

Os leitores desta questão também podem estar interessados em este guia para fazer o backup pelo mantenedor do ecryptfs .

    

Answer 2

Presumivelmente, a senha do usuário não presente é absolutamente necessária para a descriptografia. Portanto, sua única opção é procurar uma solução que faça backup de arquivos criptografados e use isso para ambos os usuários. Isso tem a vantagem de que as informações aparentemente confidenciais também são criptografadas na mídia de backup - o que pode ser importante se você estiver transferindo-a pelo local (para externo).

Não estou familiarizado com o ecryptfs, mas parece que os arquivos são arquivos padrão quando visualizados pelo sistema de arquivos subjacente (supondo ext3).

Então, 1) É o diretório 'original' que contém os dados criptografados em outro lugar, e então montado para que a versão não criptografada apareça no local que você forneceu - nesse caso, você poderia simplesmente obter os dados criptografados de a localização original. Algumas das documentações do ubuntu sugerem que os arquivos privados não criptografados são o que você vê em /home/.ecryptfs/A/Private e suas contrapartes criptografadas estão realmente presentes em /home/.ecryptfs/A/.Private. Se assim for, e você usar o rsync, você terá o diretório .Private criptografado para ambos os usuários, e para maior clareza você pode usar as opções de exclusão do rsync para impedir o backup do diretório privado não criptografado.

2) Alternativamente, você pergunta um pouco como a pasta inteira A (ou B) é criptografada, e possivelmente as versões não criptografadas e criptografadas são montadas no mesmo local. Em caso afirmativo, você poderia tentar algo como mount -o ro --bind /home/.ecryptfs/A / mnt / encryptedA que forneceria outro ponto de acesso ao diretório de A via / mnt / encryptedA. Se isso foi feito antes do login do usuário, possivelmente você manteria o acesso à versão criptografada via / mnt / encryptedA mesmo enquanto /home/.ecryptda/A dá acesso à versão não criptografada. Eu não sei se isso vai funcionar - você só tem que tentar e ver.

    

Answer 3

Por que não "apenas" sincronizar seus arquivos no logout para um compartilhamento. desta forma, em vez de ter que iniciar manualmente o seu trabalho, ele "autorun" (cron, action event ...) copia os arquivos não criptografados para o compartilhamento (que pode ou não ser criptografado) e criptografa seu próprio FS novamente antes de registrar. fora.

Eu posso ver isso não sendo a solução final, mas isso significa que o usuário sempre terá um backup atualizado, já que seus arquivos são sincronizados no servidor. E se o usuário B não estiver logado por um tempo, então não há mal nenhum em não apoiá-lo porque seus arquivos não serão alterados para começar.

Isso é algo como o que você está procurando, ou você está buscando uma solução mais ... simplificada, tudo em um?

Idealmente, jogar o lote em uma transferência ENCRYPTED para backup seria melhor, pois agora você deixa seus dados valiosos abertos para o homem no meio e / ou tentativas de cheirar.