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

Question

Eu tenho um cluster de servidores, cada um com arquivos de configuração que atualmente contêm senhas de texto sem formatação para sistemas sensíveis e de missão crítica (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 forma, os arquivos de configuração podem ser confirmados no controle de versão, e o administrador do sistema precisa apenas criar 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.

Esta é realmente a melhor maneira de evitar senhas em arquivos de configuração de texto simples ou existe uma maneira melhor?

    

Answer 1

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 '
$ tr '%pre%' '\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' < /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.

A coisa a 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 sempre que um programa precisar dela, essa senha deverá estar acessível com base apenas no acesso do programa. Você pode criptografar a senha localmente e fazer o programa descriptografar usando uma chave, mas tudo o que isso faz é obscurecer a senha contra divulgação acidental; alguém que tenha o mesmo acesso que o programa pode fazer as mesmas coisas que o programa pode fazer, incluindo a leitura da chave de criptografia.

A maneira correta de fazer isso é fazer com que o aplicativo seja executado 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, a fim de manter a senha fora de um sistema de controle de versão (supondo que o VCS não tem controles de segurança). Para proteger contra divulgação inadvertida, obscureça a senha como você quiser - base64 codifique-a, use o pgp para criptografar, o que fizer sentido no conjunto de opções do seu programa de servidor. Se você está escrevendo um programa para fazer isso, o melhor que você pode fazer é solicitar uma senha ao usuário somente quando necessário e, em seguida, limpar a senha da memória assim que for usada.

    

Answer 2

Por fim, se você tiver dados que precisem ser lidos e escritos , você acabará protegendo algo com uma senha (ou se é realmente paranóico, com um smart card de hardware físico e um PIN), não importa quantas camadas de criptografia você tenha.

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 teria que violar para obter os "bens", 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 simples 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 Cheio, para que o conteúdo de todo o armazenamento persistente seja criptografado.

2. Restringir o acesso físico às máquinas. Trave o chassi da máquina com um mecanismo de travamento seguro e controle o acesso físico às teclas. Contrate muscle (guardas armados) para ser gatekeepers de acesso.

3. Impor controle de acesso obrigatório (MAC) no sistema operacional do dispositivo. Você pode começar com algo parecido com o SELinux no GNU / Linux e configurá-lo como Enforcing, e adaptar a política às necessidades exatas do software de produção, permitindo exatamente essas permissões (e somente) as permissões necessárias aos arquivos que eles precisam. / p>

4. Se você tiver 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 com o controle de versão, pois pode ser difícil desalojar uma senha perdida do cache de um VCS. 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 é inicializado, mas a reinicialização da máquina e a restauração do status operacional é um esforço manual e não pode ser feito de forma autônoma, então há essa conveniência versus segurança novamente.

5. Verifique se você tem especialistas em rede à disposição para cuidar das permissões de firewall, para minimizar sua exposição a um ataque pela rede. Auditoria (teste de penetração, bem como whitebox testar o código) qualquer software que faz interface com sistemas externos, especialmente a Internet pública. "Interfaces" inclui não apenas conexões de rede diretas, mas também leitura ou gravação de dados "não confiáveis" (dados cujos bytes são originados de 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 1 a 3, a consideração do ponto 4 e do ponto 5 não irá ajudá-lo muito , porque o seu sistema não é seguro em um nível razoavelmente fundamental.

    

Answer 3

Passar uma senha em uma variável de ambiente é tão seguro quanto ter o programa lendo-a 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. Argumentos de 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 processos sendo executados como o mesmo usuário.

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

A falha em seu cenário é “criar uma variável de ambiente apropriada quando o sistema do servidor está 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 configurando você significa algo que sobrevive a uma reinicialização. O que você quer dizer é, presumivelmente, que o administrador tenha organizado essa variável no ambiente quando um determinado usuário fizer login. Isso é feito por meio de um arquivo de configuração (geralmente ~/.pam_environment ou ~/.profile ou um arquivo lido de ~/.profile ) . Portanto, essa solução não remove a senha dos arquivos de configuração.

Configurar as coisas de modo que as senhas estejam no ambiente de tempo de login de um 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 que está 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 para um conjunto de programas o menor possível.