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

Question

Como administradores responsáveis, conhecemos pontos fracos comuns, como

• CWE-260: Senha no arquivo de configuraçãohttp://cwe.mitre.org/data/definitions/260.html
• CWE-522: Credenciais insuficientemente protegidashttp://cwe.mitre.org/data/definitions/522.html
• CWE-257: Armazenando senhas em formato recuperávelhttp://cwe.mitre.org/data/definitions/557.html

Mas como lidamos com isso na prática?

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

Mas assim que você sair do sistema operacional e instalar aplicativos, há grandes chances de você se deparar com o problema de onde armazenar as senhas com segurança.

Por exemplo, se você instalar um servidor de banco de dados, provavelmente precisará salvar a senha em texto não criptografado em um arquivo de configuração do 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, por exemplo, com a conta administrativa principal do banco de dados? Pelo menos seu dbas deve saber disso (então você precisa do texto não criptografado em algum lugar) e como administrador do sistema operacional você devenãoconheça as credenciais. Ou a implantação é feita por devops e eles não deveriam saberqualquerdas credenciais em servidores de produção.

Soluções possíveis

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

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

2. Aceite senhas em texto não criptografado e credenciais padrão durante a implantação e adicione um postscript que mudequalquer e todossenhas. 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 um terceiro confiável. Quando a senha é solicitada, eladevemos sermudou depois.

O que você acha? Você vê alguma prática recomendada aqui?

Answer 1

1. Você deve ter um banco de dados seguro e criptografado com todas as suas credenciais
2. Um servidor deve ser totalmente inacessível externamente em virtude de firewalls durante a implantação
3. Não há problema em fazer com que um script gere um passe aleatório e o envie por e-mail para você
4. Também não há problema em alterar essa senha depois que o servidor for provisionado, ANTES de permitir o acesso ao público
5. Enviar a senha para você mesmo por e-mail é aceitável, desde que esteja usando seu servidor de e-mail interno e não seja roteado via público por SMTP (SMTPS é uma história diferente)

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

Acho que isso é suficiente.