Protegendo os envasos do processo da exposição

Question

De que li sobre as práticas recomendadas atuais para o desenvolvimento de aplicativos da web (como o Guia do Doze Fator ), a abordagem recomendada para armazenar a configuração os dados estão dentro das variáveis de ambiente . Isso é especificamente comparado a mantê-los dentro dos arquivos de configuração, pois eles são acidentalmente verificados no repositório do projeto, quebrando a separação "code / config" e potencialmente expondo segredos (como chaves de API, sais, etc.).

No entanto, o que eu não vi abordado é a defesa contra a exposição acidental. Ao usar arquivos de configuração, pode-se configurar permissões de arquivo de acordo, impedindo que qualquer pessoa, exceto usuários específicos, leia a configuração secreta. Mas os sistemas Unix não parecem oferecer tal proteção para as variáveis de ambiente de um processo - mesmo se o processo for iniciado por um usuário diferente:

$ sudo -u root x=5 sleep 30
$ ps au -E | grep sleep  # in different terminal
root 53814 s003  S+     0:00.01 sudo -u root x=5 sleep 30

Se a variável x contiver dados confidenciais, seria possível lê-la apenas com acesso de login à máquina, como qualquer usuário (não necessariamente como raiz ou o usuário que iniciou o processo que queremos espionar ). Portanto, essa abordagem para configuração parece menos segura (do PoV de defesa em profundidade; obviamente, a máquina deve ser protegida contra acesso não autorizado) do que arquivos de configuração - a menos que possamos de alguma forma proteger as variáveis de ambiente.

Minha pergunta é: existe uma maneira de impedir que outros usuários no mesmo sistema Unix vejam as variáveis de ambiente de um processo (através de ps a -E e qualquer outro meio possível)?

    

Answer 1

Em primeiro lugar, ótima pergunta!

A opção -E mostra apenas o ambiente no momento em que o processo é iniciado, portanto, quaisquer alterações seriam invisíveis para esse método. Portanto, se os dados forem carregados no ambiente após o lançamento do processo, eles não poderão ser descobertos por esse método. No entanto, esta provavelmente não é uma estratégia viável, IMHO, pelas razões discutidas abaixo.

Concordo com o Doze Fator de que o truque da variável de ambiente é o caminho a percorrer. No entanto, existem algumas ressalvas importantes que não estão claras no Guia dos Doze Fator, bem como algumas considerações e técnicas práticas para chegar lá.

Primeiramente, as variáveis de ambiente são voláteis (não persistentes). Todos os dados são perdidos na reinicialização. Isso significa que se a configuração não for persistida em algum lugar, ela não será recuperada no caso de reinicialização do servidor, a menos que esteja na memória em /dev/brain0 do sys-admin (não é um jogo que eu faria com chaves de 128 bits). Se essa é a (s) chave (s) privada (s) do servidor, você tem, na melhor das hipóteses, um problema grave e, na pior, catastrófico em suas mãos (sua CA pode precisar reemitir as chaves). Isto faz um bom caso que a configuração deve ser escrita em algum lugar, e eu não acho que muitas pessoas contestariam isso. Onde / como armazená-lo, no entanto, é o que é importante.

O Twelve Factor App trata disso, embora não de maneira direta. "Um teste decisivo para determinar se um aplicativo possui todas as configurações corretamente consideradas fora do código é se a base de código pode ser feita de código aberto a qualquer momento, sem comprometer nenhuma credencial." Então, sabemos que temos que escrevê-lo em algum lugar , e que não podemos colocar a configuração na base de código. "Outra abordagem para a configuração é o uso de arquivos de configuração que não são verificados no controle de revisão." Isso é o que eu faria.

A App do Twelve Factor diz: "É fácil verificar, por engano, um arquivo de configuração no repositório". Para combater isso, a configuração de produção (como chaves privadas) deve ser diferente do desenvolvimento e da configuração de teste. Eles também devem ser estritamente controlados. Alguns sistemas de controle de versão como git têm listas negras (como um arquivo .gitignore ) que impedem a verificação em determinados arquivos. Estes também devem ser usados. "Há uma tendência de os arquivos de configuração serem espalhados em diferentes lugares e diferentes formatos, dificultando a visualização e o gerenciamento de todas as configurações em um único lugar. Além disso, esses formatos tendem a ser específicos de linguagem ou framework." Isto é combatido simplesmente definindo as "variáveis de ambiente" no arquivo de configuração. Isso pode ser carregado no ambiente na inicialização pelo servidor.

O que eu faria:

1. Armazenar as informações de configuração do servidor de produção (como as chaves privadas do servidor) em um repositório separado que seja diferente e distinto do repo principal
2. Proteja muito bem o (s) arquivo (s) de configuração de produção. Apenas algumas pessoas precisam acessá-lo, não todos os desenvolvedores da equipe. QA / DevOps / Sys-admins / etc por exemplo. Trate esse arquivo como as chaves para o servidor, porque eles provavelmente estão nele. Ambientes de desenvolvimento e teste devem ter credenciais e chaves diferentes da produção. Estes podem então ser armazenados de forma mais frouxa
3. A rotina de inicialização do servidor carrega as informações do arquivo de configuração nas variáveis do ambiente ativo
4. O aplicativo deve carregar as informações de configuração necessárias das variáveis de ambiente no tempo de execução