Melhores práticas para manter senhas em scripts Shell/Perl?

Question

Recentemente tive que tirar o pó das minhas habilidades em Perl e shell script para ajudar alguns colegas.Os colegas em questão foram encarregados de fornecer alguns relatórios de um aplicativo interno com um grande back-end de banco de dados Oracle e eles simplesmente não têm as habilidades necessárias para fazer isso.Embora alguns possam questionar se eu também tenho essas habilidades (sorriso), aparentemente um número suficiente de pessoas pensa que tenho, o que significa que não posso fugir disso.

Então, para minha pergunta - para extrair os relatórios do banco de dados, meu script obviamente precisa conectar e executar consultas.Até agora, não consegui encontrar uma boa solução sobre onde armazenar o nome de usuário e a senha do banco de dados, portanto, ele está sendo armazenado como texto simples no script.

Existe uma boa solução para isso que alguém já escreveu, talvez como um módulo CPAN?Ou há algo melhor a fazer - como manter a combinação usuário/senha em um arquivo completamente separado, escondido em algum outro lugar do sistema de arquivos?Ou devo mantê-los criptografados trivialmente para evitar que sejam retirados dos meus scripts com um grep em todo o sistema?

Editar:O banco de dados Oracle fica em um servidor HP-UX.
O servidor de aplicativos (executando os scripts de shell) é o Solaris.
Definir os scripts como propriedade exclusiva de mim é impossível, eles devem pertencer a uma conta de serviço à qual vários funcionários de suporte tenham acesso.
Os scripts devem ser executados como tarefas cron.
Eu adoraria usar a autenticação de chave pública, mas não conheço métodos para fazer isso funcionar com o Oracle - se existir tal método - me esclareça!

Answer 1

A melhor prática, IMHO, seria NÃO manter nenhuma senha em um script Shell/Perl.É para isso que serve a autenticação de chave pública.

Answer 2

Se o script estiver sendo executado remotamente no servidor.

1. Faça suas visualizações de relatórios
2. Dê ao usuário no qual você está fazendo login APENAS acesso para selecionar as visualizações de relatório
3. Basta armazenar a senha.

Dessa forma, tudo o que o usuário pode fazer é selecionar os dados para seu relatório.Mesmo que alguém conseguisse a senha, estaria limitado quanto ao que poderia fazer com ela.

Answer 3

Pessoalmente, mantenho senhas em arquivos de configuração que são distribuídos independentemente do aplicativo e podem ser alterados para a máquina/ambiente específico.Em scripts de shell, você pode obtê-los no script principal.

No entanto, em Perl há uma variedade de abordagens.Você pode querer investigar Obteropt::Longo para opções de linha de comando (e adicionalmente Getopt::ArgvFile para armazená-los em um arquivo de configuração simples) ou veja algo como Configuração::IniFiles por algo com um pouco mais de poder por trás disso.Esses são os dois tipos que geralmente uso, mas existem outros módulos de arquivo de configuração disponíveis.

Answer 4

Não existe uma boa solução.Você pode ofuscar um pouco as senhas, mas não pode protegê-las.

Se você tiver controle sobre a configuração do seu banco de dados, você pode tentar conectar-se por um canal nomeado (pelo menos o MySQL suporta isso) sem uma senha e deixar o sistema operacional lidar com as permissões.

Você também pode armazenar as credenciais em um arquivo com permissões restritivas.

Answer 5

Já que você marcou ksh & bash, assumirei o Linux.

A maior parte do problema é que, se o usuário puder ler o script e localizar o método usado para ocultar/criptografar o arquivo, ele também poderá fazer a mesma coisa manualmente.

Uma maneira melhor pode ser fazer o seguinte:

1. Faça seu script de forma que só possa ser visto/lido/aberto por você.chmod 700 isso.Codifique as senhas.
2. Tenha um script "launcher" que seja executável pelo usuário e faça um sudo .

Dessa forma, o usuário pode ver o script do seu inicializador, examiná-lo para ver se ele possui apenas uma única linha de comando.Eles podem executá-lo e funcionar, mas não têm permissão para ler a fonte do script sudo.

Answer 6

Não tenho certeza de qual versão do Oracle você está executando.Na versão mais antiga do Oracle (pré-9i Advanced Security), alguns DBAs CREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLY E definir REMOTE_OS_AUTHENT para verdadeiro.

Isso significaria que sua máquina solar remota poderia autenticá-lo como SCOTT e então seu banco de dados Oracle aceitaria essa autenticação.

Esta é uma má ideia.

Como você pode imaginar, qualquer Windows XP com um usuário local da SCOTT poderá fazer login no seu banco de dados sem uma senha.

Infelizmente, é a única opção que conheço dos bancos de dados Oracle 9i para não armazenar nomes de usuário/senhas em seu script ou em algum outro lugar acessível pela máquina cliente.

Qualquer que seja a sua solução, vale a pena dar uma olhada no Oracle Bloqueio do projeto antes de cometer.

Answer 7

Para armazenar senhas, você pode executar uma rotina de criptografia em duas etapas, primeiro com uma chave codificada no próprio script e, opcionalmente, uma segunda vez com uma chave armazenada em um arquivo (que é definida usando permissões de arquivo para ter acesso restrito).

Em uma determinada situação, você pode usar um arquivo de chave (+ chave do script) ou, se os requisitos da situação não forem tão bons, ele pode simplesmente usar a criptografia usando a chave codificada no script.Em ambos os casos, a senha seria criptografada no arquivo de configuração.

Não existe uma solução perfeita porque, de alguma forma, você precisa ser capaz de descriptografar e obter a senha em texto não criptografado... e se você puder fazer isso, outra pessoa também poderá, se tiver as informações corretas.

Especialmente na situação em que lhes damos um script perl (vs.um exe) eles podem ver facilmente como você faz a criptografia (e a chave codificada) ... e é por isso que você também deve permitir a opção de usar um arquivo-chave (que pode ser protegido pelas permissões do sistema de arquivos).

Alguns exemplos práticos de como implementar são aqui

Answer 8

No UNIX, eu sempre faço esses scripts setuid e armazeno as informações de usuário e senha em um arquivo altamente protegido (toda a árvore de diretórios não pode ser lida/pesquisada por usuários comuns e o arquivo em si pode ser lido apenas pelo proprietário do script) .

Answer 9

Mantenha-os em um arquivo separado, criptografado trivialmente, e crie um usuário separado no banco de dados com acesso somente leitura às tabelas necessárias.Se você acha que o arquivo foi lido, você pode desativar o acesso apenas a esse usuário.

Se você quiser se divertir, um programa SUID pode verificar o /proc//exe e o cmdline (no Linux) e só então liberar o nome de usuário.

Answer 10

Eu tive/tive um problema semelhante com desenvolvedores implantando código SQL em MSSQL (na verdade, em qualquer banco de dados nesse servidor MSSQL, então a função tinha que ser SysAdmin) usando ANT de um servidor Solaris.Novamente eu não queria armazenar o nome de usuário e senha nos arquivos ANT build.xml então minha solução, que sei que não é a ideal, é a seguinte:

1. Armazene pares nome/valor para nome de usuário e senha em um arquivo de texto simples
2. Criptografe o arquivo (no Solaris) e use uma frase secreta conhecida apenas por determinados administradores
3. Deixe apenas o arquivo criptografado no sistema Solaris
4. ANT build.xml executa uma descriptografia sudo e solicita uma frase secreta, que é inserida pelo administrador
5. Fontes ANT arquivo descriptografado carregando nome de usuário e senha como variáveis ​​para a string SQL
6. ANT excluiu imediatamente o arquivo de texto simples
7. ANT implanta código e sai

Tudo isso acontece em questão de segundos, e o nome de usuário e a senha do SQL nunca ficam visivelmente acessíveis no servidor.Como o código é implantado por administradores autorizados na produção, os desenvolvedores nunca precisam incluí-lo em seu código.

Tenho certeza que poderia ser melhor, mas...

JB

Answer 11

É uma pena nunca ter visto esse tópico antes, parece muito interessante.Acrescentarei meus dois centavos para qualquer um que encontrar o tópico no futuro.

Eu recomendo usar a autenticação do sistema operacional no próprio servidor db - REMOTE_OS_AUTHENT ainda é FALSE.

Se você estiver invocando o script de outra máquina, configure uma chave SSH sem frase e use SSH para chegar lá.Você pode então enviar de volta os resultados SQL para a máquina chamadora e ela pode processar essas informações ainda mais.

Isso evita a necessidade de codificar uma senha em qualquer lugar.É claro que, se um administrador mal-intencionado sequestrasse a chave sem frase e a usasse, ele também poderia acessar a conta do usuário no host do banco de dados e executar qualquer operação que o usuário do banco de dados autenticado pelo sistema operacional pudesse fazer.Para atenuar isso, você pode reduzir ao mínimo as permissões do banco de dados desse usuário do sistema operacional - digamos "somente leitura".

Ingo

Answer 12

No Windows, crie uma pasta e um arquivo dentro dela contendo as senhas em texto não criptografado.Defina o usuário que executaria o trabalho agendado (script ou lote) como a única pessoa com acesso de leitura/gravação a esta pasta e arquivo.(remover até mesmo administrador).Para todos os outros scripts, adicione código para ler a senha em texto não criptografado deste arquivo restrito.

Isso deve ser suficiente para poucos.

Palavras-chave:Codificação de senha

Answer 13

Existem soluções comerciais ou mais avançadas, como o cyberark AIM, que podem fazer isso melhor, mas fazendo isso de graça e pronto para uso, peguei carona na chave pública/privada SSH porque, por um lado, os pares de chaves SSH provavelmente já criados estão em conformidade com o política de segurança;em segundo lugar, os pares de chaves SSH já possuem um conjunto de protocolos padrão para proteger as chaves pela permissão de arquivo, proteção contínua do sistema (como tripwire) ou rotação de chaves.

Foi assim que eu fiz:

1. Gere os pares de chaves ssh, se ainda não.Os pares de chaves e o diretório serão protegidos pelo protocolo/permissão padrão do sistema.ssh-keygen –t rsa –b 2048

2. Use a chave pública SSH para criptografar a cadeia de caracteres e armazenada no mesmo diretório .ssh $ echo "palavra secreta" | openssl rsautl -encrypt -inkey ~/.ssh/id_rsa.pub -pubin -out ~/.ssh/secret.dat

3. use a chave privada ssh para descriptografar a chave e passe os parâmetros para scripts/AP em tempo real.O script/programa para incluir a linha para descriptografar em tempo real:sequência =openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in ~/.ssh/secret.dat

PS - Tenho experimentado a solução sem agente CYBERARK AIM.é uma espécie de dor que requer mudanças significativas/mudanças de API para a API/script.irá mantê-lo informado sobre como isso acontece.