Como automatizar a descriptografia de gpg que usa uma senha e a mantém em segredo?


13

Tenho a tarefa de automatizar uma descriptografia de gpg usando cron (ou qualquer ferramenta de agendamento de trabalhos compatível com o Ubuntu Server). Como ele tem que ser automatizado, usei, --passphrasemas ele acaba no histórico do shell, para que fique visível na lista de processos.

Como automatizar a descriptografia, mantendo bons (de preferência ótimos) padrões de segurança?

Um exemplo será muito apreciado.


Argumentos como este são visíveis em psetc, a menos que você esteja hidepidusando /proc, mas um shell executando um script (do cron ou de outro modo) não é interativo e não deve escrever histórico, a menos que esteja configurado incorretamente.
David_thompson_085

Respostas:


23

Armazene a senha em um arquivo que seja legível apenas pelo usuário da tarefa cron e use a --passphrase-fileopção para dizer gpgpara ler a senha lá.

Isso garantirá que a senha não seja visível nas informações do processo na memória. O nível de segurança será determinado pelo nível de acesso ao arquivo que armazena a senha (bem como pelo nível de acesso ao arquivo que contém a chave), incluindo em qualquer lugar em que seu conteúdo seja copiado (portanto, tenha cuidado com os backups), e acessibilidade off-line (puxando o disco para fora do servidor). Se esse nível de segurança é suficiente, dependerá dos controles de acesso ao servidor que contém o arquivo, fisicamente e no software, e dos cenários que você está tentando mitigar.

Se você deseja ótimos padrões de segurança, precisa usar um módulo de segurança de hardware em vez de armazenar sua chave (e senha) localmente. Isso não impedirá que a chave seja usada in situ , mas evitará que seja copiada e usada em outro lugar.


+1 por mencionar o módulo de segurança de hardware, a única solução, realmente, para esse enigma.
MariusMatutiae

Stephen, obrigado pela menção do módulo de segurança de hardware, vou fazer algumas pesquisas. Obrigado por me apontar na direção certa.
Zakk Coetzee

As teclas de hardware @StephenKitt são ótimas quando o trabalho. Quando não, bem ...
Satō Katsura 27/10

@ SatōKatsura é verdade, embora eu indique que o Yubikey não é um HSM. (Que não HSMs médios não são vulneráveis, claro .)
Stephen Kitt

"Se você deseja ótimos padrões de segurança", não pode ter um trabalho automatizado descriptografar ou assinar nada.
JimmyB

5

Automatizar a descriptografia significa que você deve armazenar a senha em algum lugar ou não usar uma senha (a menos que use opções adicionais, conforme indicado na outra resposta enviada por Stephen enquanto eu estava digitando a minha)! Nenhum deles corresponde à sua exigência de bons ou excelentes padrões de segurança.

ou seja, sua exigência não é compatível com a segurança.

Você pode confiar em coisas como: você tem que ser root, forneci um nome muito confuso ao arquivo no qual minha frase secreta está armazenada, criptografei os sistemas de arquivos subjacentes, etc., etc., mas todas elas são camadas que são triviais para contornar uma vez que você é raiz em primeiro lugar.

A opção que impede que a frase secreta apareça na lista de processos é --passphrase-file <file-name>.

No entanto, isso não é mais seguro do que apenas remover a frase secreta em primeiro lugar.


Obrigado por explicar o Tony, você deu uma melhor visão sobre o assunto. Um módulo de segurança de hardware, como mencionado por Stephen, será o principal objetivo.
Zakk Coetzee

@ZakkCoetzee: Como eu disse na outra resposta, o que impede o invasor de usar o HSM se ele é root?
Martin Bonner apoia Monica

@MartinBonner Como dito acima por Stephen Kitt, ele impede que eles obtenham a chave, o que é definitivamente melhor do que obtê-la.
Zakk Coetzee

É, mas não muito melhor. Pergunte ao Diginotar (que tinha a chave em um HSM, mas deixou o HSM conectado e com o cartão inteligente relevante no slot - para que um invasor pudesse assinar vários certificados do invasor.)
Martin Bonner apoia Monica
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.