Backup externo criptografado usando GPG com chave privada nunca no servidor de backup?

9

Eu tenho um servidor de backup, que cria xz compacted tar archives das árvores de diretório para backup. Esses arquivos tar podem ficar enormes (vários TBs), são split em partes (2.5TB) e cada parte é gravada em uma fita LTO-6 e as fitas vão para fora do local.

Agora quero adicionar criptografia. Eu posso GPG criptografar o arquivo tar antes de dividir, usando criptografia de chave pública-privada e com um ou mais destinatários (chaves públicas de admin).

No entanto, em caso de recuperação, pelo menos um administrador precisa colocar sua chave privada no servidor de backup, já que os arquivos são muito grandes para serem descompactados em qualquer outro lugar.

O GPG usa um esquema de criptografia híbrido sob a capa, com uma cifra simétrica como AES com uma chave de sessão, e somente essa chave de sessão obtém a chave pública-privada criptografada para os destinatários.

Existe uma maneira de permitir que um administrador forneça a chave de sessão para que a descriptografia do arquivo seja recuperada sem colocar a chave privada no servidor de backup ?

Eu poderia reinventar a roda, é claro:

  • crie uma chave de sessão aleatória no servidor de backup para cada arquivo a ser salvo em backup
  • use criptografia simétrica de GPG para criptografar o arquivo
  • use criptografia assimétrica de GPG para criptografar a chave de sessão de cada destinatário

Mas existe uma maneira "padrão" ou integrada ou de prática recomendada acima?

    
por oberstet 25.01.2016 / 14:06

3 respostas

14

Isso é definitivamente possível com as opções --show-session-key e --override-session-key .

Primeiro, você precisa do início do seu arquivo criptografado. É aqui que a chave de sessão criptografada é armazenada.

root@qwerty:~/gpg# head -c 1024k bigfile.gpg > head.gpg

Copie-o para sua estação de trabalho e recupere a chave da sessão

PS C:\Users\redacted\Downloads> gpg --show-session-key .\head.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <[email protected]>"
gpg: session key: '9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D'

Agora você pode descriptografar o arquivo usando sua chave de sessão

root@qwerty:~/gpg# gpg -d -o bigfile --override-session-key 9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D bigfile.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <[email protected]>"
    
por 01.02.2016 / 16:40
2

Parece que a maior parte da sua pergunta foi respondida, no entanto, se a equipe do administrador desconfiar de que as chaves privadas acabam saindo do controle local, considere sshfs montar os backups remotos em uma sessão ssh .

Instale via apt no sistema de cada administrador remoto

sudo apt-get install sshfs

Assumindo que a configuração ssh dos administradores se parece com algo abaixo

# configuration for ssh login to remote server
Host Remote
    Hostname Remote.web.domain
    User admin
    IdentityFile ~/.ssh/private.key

Então seus administradores podem usar algo como abaixo para montar

# make a mount point
mkdir -p /mnt/remote
# mount remote directory to local file system
sshfs Remote:/path/to/encrypted/dir /mnt/remote

Para desmontar após a inspeção, o administrador remoto pode usar o seguinte

fusermount -u /mnt/remote

O doce sobre o uso do sshfs é que apenas as chaves públicas para o GnuPG e o ssh são necessárias no servidor remoto, as chaves privadas relacionadas permanecem nos sistemas que o possuem. Segundo nice bit é que até ler ou acessar a maioria das informações do arquivo permanece em seu sistema de arquivos relacionado.

Se você ainda está procurando ferramentas para facilitar a criptografia automática de logs ou diretórios, pode querer verificar o prof da ferramenta conceitual que eu enviei para GitHub (especificamente Cenário Quatro escrito para sshsf usage) que com um pouco de personalização irá criptografar quase todos os dados via GnuPG. Mas esteja avisado que é experimental e alguns de seus recursos podem causar corrupção de dados, se utilizados de forma inadequada. O código fonte é menor que ~ 1600 ~ linhas, então é muito possível fazer auditoria em menos de um final de semana.

É possível obter segurança adicional configurando a configuração ssh do servidor remoto para que os usuários chroot permitam apenas o acesso ao diretório criptografado e desativem o shell interativo para as chaves de administrador usadas dessa maneira.

    
por 31.10.2016 / 18:27
1

Se você quiser que a chave secreta permaneça fora dos discos rígidos, você pode criar um disco virtual (lembre-se disso?) e carregar as chaves secretas do seu local seguro que não está no servidor, conforme necessário. Use-o para descriptografar e, quando feito, substituí-lo por / dev / random. O segredo tem que ir para a RAM para ser usado pelo GPG de qualquer forma, então por que não duas vezes?

Se você não pode deixar uma chave secreta estar no servidor, mesmo na RAM, então você tem uma impossibilidade técnica. O GPG deve ter a chave secreta em algum lugar para descriptografar qualquer coisa.

Informações sobre o Ramdisk: link

    
por 01.02.2016 / 06:14

Tags