É seguro armazenar senhas críticas em variáveis ​​de ambiente do servidor?

Eu tenho um cluster de servidores, cada um com arquivos de configuração que atualmente contêm senhas em texto sem formatação para sistemas sensíveis e críticos à missão (filas de mensagens, armazenamentos de dados e outros serviços).

Algumas pessoas movem senhas críticas dos arquivos de configuração para uma variável de ambiente das contas de usuário sob as quais os processos do servidor são executados. Dessa maneira, os arquivos de configuração podem ser confirmados no controle de versão, e o administrador do sistema precisa criar apenas uma variável de ambiente apropriada quando o sistema do servidor estiver configurado. Naturalmente, o acesso às contas que executam esses serviços é muito restrito.

Essa é realmente a melhor maneira de evitar senhas em arquivos de configuração de texto sem formatação ou existe uma maneira melhor?

Se você estiver em um sistema Linux, consulte / proc / * / environ e decida se as variáveis ​​de ambiente são um bom local para armazenar informações confidenciais ou não. / proc / self é o processo atual:

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

Não importa que a coisa que define a variável de ambiente provavelmente esteja lendo um arquivo em algum lugar.

É importante lembrar que o uso de uma senha significa que a senha está disponível para o programa. Se essa senha não for fornecida por um usuário digitando-a toda vez que um programa precisar, essa senha deverá ser acessível com base apenas no acesso ao programa. Você pode criptografar a senha localmente e fazer com que o programa decodifique usando uma chave, mas tudo o que faz é ocultar a senha contra divulgação acidental; alguém que tenha o mesmo acesso que o programa pode fazer as mesmas coisas que o programa, incluindo a leitura da chave de criptografia.

A maneira correta de fazer isso é executar o aplicativo como uma conta restrita e armazenar a senha em um arquivo protegido com permissões no nível do sistema de arquivos. Espero que você possa "incluir" um arquivo ou similar para manter a senha fora de um sistema de controle de versão (assumindo que o VCS não possua controles de segurança). Para se proteger contra a divulgação inadvertida, oculte a senha da maneira que desejar - codifique-a base64, use pgp para criptografar, o que fizer sentido no conjunto de opções do programa do servidor. Se você estiver escrevendo um programa para fazer isso, o melhor que você pode fazer é solicitar a senha do usuário apenas quando necessário e, em seguida, limpar essa senha da memória assim que for usada.

Por fim, se você tiver algum dado que precise ser lido e gravado , você acabará protegendo algo com uma senha (ou se for realmente paranóico, com um cartão físico de hardware e um PIN), não importa quantas camadas de criptografia você possui.

Isso se resume à questão básica de segurança do sistema versus conveniência. Você pode adicionar "defesa em profundidade", com várias camadas de controles de segurança que um ator mal-intencionado precisaria violar para acessar as "mercadorias", mas quando um ator legítimo quiser ler ou alterar alguns dados, eles têm que passar por um monte de aros. A alternativa são senhas de texto sem formatação em arquivos de texto.

O que eu faria se realmente quisesse proteger algumas informações em um sistema de missão crítica:

1. Use a Criptografia de disco completa, para que o conteúdo de todo o armazenamento persistente seja criptografado.

2. Restrinja o acesso físico às máquinas. Bloqueie o chassi da máquina com um mecanismo de travamento seguro e controle o acesso físico às chaves. Contrate músculos (guardas armados) para serem guardiões do acesso.

3. Imponha o controle de acesso obrigatório (MAC) de baixa granularidade no sistema operacional do dispositivo. Você pode começar com algo como o SELinux no GNU / Linux e defini-lo como Imforcing, e depois adaptar a política às necessidades exatas do software de produção, permitindo a essas contas exatamente (e somente) as permissões necessárias para os arquivos de que precisam.

4. Se você deseja ter senhas específicas do sistema e controle de versão para arquivos de configuração, você realmente deseja evitar o possível erro de ter uma senha de texto sem formatação comprometida por engano no controle de versão, pois pode ser difícil remover uma senha vazada de um Cache do VCS. As variáveis ​​de ambiente são uma das várias opções viáveis ​​para isso. O outro é um prompt de senha quando o programa é iniciado, mas, em seguida, reiniciar a máquina e restaurar o status operacional é um esforço manual e não pode ser feito de forma autônoma; portanto, há essa conveniência versus segurança novamente.

5. Certifique-se de ter especialistas em rede disponíveis para cuidar das permissões de firewall, para minimizar sua exposição a um ataque na rede. Audite (teste de penetração e teste de código da caixa branca) qualquer software que faça interface com sistemas externos, especialmente a Internet pública. "Interfaces" inclui não apenas conexões diretas de rede, mas também a leitura ou gravação de dados "não confiáveis" (dados cujos bytes se originaram fora da RAM / disco / CPU do servidor seguro).

Esta não é uma lista completa, mas especialmente o ponto 4 provavelmente é relevante para você, embora se você não executar pelo menos as etapas de 1 a 3, a consideração dos pontos 4 e 5 não ajudará muito, porque seu sistema não é seguro em um nível bastante fundamental.

Passar uma senha em uma variável de ambiente é tão seguro quanto fazer com que o programa a leia de um arquivo. Somente processos em execução como o mesmo usuário podem ler o ambiente de um processo , e esses processos podem ler os mesmos arquivos de qualquer maneira.

Observe que isso é diferente de passar uma senha na linha de comando. Os argumentos da linha de comando são legíveis por todos os processos em execução na mesma máquina (exceto medidas de proteção), não apenas pelos processos em execução como o mesmo usuário.

Se você passar uma variável pelo ambiente, tome cuidado se o programa iniciar outros programas. Esses outros programas herdarão o ambiente de seus pais. Portanto, não faça isso se estiver com medo de que outros programas possam vazar acidentalmente o conteúdo de seu ambiente.

A falha no seu cenário é "criar uma variável de ambiente apropriada quando o sistema do servidor estiver configurado". Uma variável de ambiente é uma propriedade dinâmica de um processo. Você não pode criá-lo ao configurar um sistema, não se, ao configurar, significa algo que sobrevive a uma reinicialização. O que você quer dizer é, presumivelmente, que o administrador arranjado para esta variável para estar presente no ambiente quando um determinado usuário efetuar login. Isso é feito através de um arquivo de configuração (normalmente ~/.pam_environmentou ~/.profileou um arquivo lido a partir ~/.profile). Portanto, essa solução não move a senha dos arquivos de configuração.

Configurar as coisas para que as senhas estejam no ambiente de tempo de login do usuário não é uma boa ideia. Isso significa que todo processo executado como esse usuário terá o segredo, por isso é vulnerável a um vazamento em qualquer lugar.

Uma senha deve ser colocada em um arquivo além dos arquivos de configuração que estão sob controle de versão e dos mecanismos normais de implantação. Não há problema em colocar a senha no ambiente em algum momento, se for conveniente, mas isso deve ser feito no menor conjunto de programas possível.