Como lidar com senhas durante a implantação automatizada? [fechadas]

Question

Como administradores responsáveis, sabemos de fraquezas comuns como

• CWE-260: Senha no link do arquivo de configuração
• CWE-522: Credenciais insuficientemente protegidas link
• CWE-257: Armazenando senhas em um link de formato recuperável

Mas como lidamos com isso na prática?

Claro, com tecnologias como autenticação sem senha via SSH e ferramentas como o sudo, é possível se livrar de credenciais de login armazenadas em lugares importantes e isso realmente ajuda durante a implantação automatizada de servidores Linux.

Mas assim que você sai do sistema operacional e instala os aplicativos, há grandes chances de você ser confrontado com o problema de armazenar as senhas com segurança.

Por exemplo, se você instalar um servidor de banco de dados, provavelmente precisará salvar a senha de texto não criptografado em um arquivo de configuração de seu aplicativo da Web.

Em seguida, você deve proteger o arquivo de configuração para que apenas o administrador possa visualizar as credenciais e limitar as permissões de acesso do usuário do banco de dados para limitar o possível impacto na segurança.

Mas como lidar com, e. a principal conta do banco de dados administrativo? Pelo menos o seu dbas deve saber disso (então você precisa de algum lugar no texto claro) e como administrador do sistema operacional você deve não conhecer as credenciais. Ou a implantação é feita por devops e eles não devem saber qualquer das credenciais nos servidores de produção.

Soluções possíveis

Depois de pensar nisso por um longo período de tempo, chego a três soluções possíveis, mas elas têm pontos fracos próprios:

1. Gere credenciais aleatórias durante a implantação e armazene-as em um banco de dados de maneira única. E, e. O dbas tem outro usuário que pode ler apenas as credenciais do banco de dados. Mas como lidar com senhas de texto puro em arquivos de configuração de, e. webapps? Um usuário root poderia lê-los. Além disso, o usuário root do banco de dados de senhas possivelmente lê as todas credenciais de senha.

2. Aceite senhas de texto simples e credenciais padrão durante a implantação e adicione um postscript que altere todas e quaisquer senhas. Talvez até interativo, onde pessoas autorizadas precisam inserir as credenciais durante o tempo de execução do script.

3. Criptografe a senha assimetricamente com a chave de uma terceira parte confiável. Quando a senha é solicitada, ela deve ser alterada posteriormente.

O que você acha? Você vê alguma das melhores práticas aqui?

    

Answer 1

1. Você deve ter um banco de dados seguro e criptografado com todas as suas credenciais
2. Um servidor deve estar totalmente inacessível do lado de fora pela virtude de firewalls durante a implantação
3. É bom que um script gere um passe aleatório e envie por e-mail para você
4. Também é bom alterar essa senha depois que o servidor tiver sido provisionado, ANTES de você ter permitido acesso ao público
5. Enviar por e-mail a senha está correto, contanto que esteja usando seu servidor de e-mail interno e não seja roteado pelo público via SMTP (SMTPS é uma história diferente)

Você pode substituir o email por praticamente qualquer protocolo. Você poderia inserir a senha em algum lugar, criar uma mensagem única usando a API onetimesecret, enviá-la para uma essência privada usando https ou qualquer outra coisa que você possa imaginar.

Eu acho que isso cobre isso.