//, Como faço para proteger o token de acesso, no Linux, a armazenamentos de segredos automáticos e remotos como o Hashicorp Vault?

Question

//, Parece haver um problema de "galinha e ovo" com as senhas para os gerenciadores de senhas como o Hashicorp Vault para Linux.

Enquanto pesquisava isso para alguns servidores Linux, alguém esperto perguntou: "Se estamos armazenando todos os nossos segredos em um serviço de armazenamento de segredos, onde armazenamos o segredo de acesso a esse serviço de armazenamento de segredos? Em nosso serviço de armazenamento de segredos? " ‡

Fiquei surpreso, já que não adianta usar um serviço separado de armazenamento de segredos, se todos os servidores Linux nos quais eu armazenasse os segredos tivessem seu token de acesso.

Por exemplo, se eu mover meus segredos para o Vault, ainda não preciso armazenar os segredos para acessar o Hashicorp Vault em algum lugar no servidor Linux?

Fala-se em resolver isso de maneiras criativas e, pelo menos, tornar as coisas melhores do que são agora. Podemos fazer coisas inteligentes como a autenticação baseada em CIDR ou mashups de senha. Mas ainda há esse trade-off de segurança Por exemplo, se um hacker conseguir acesso à minha máquina, ele poderá acessar o cofre se o acesso for baseado no CIDR.

Essa pergunta pode não ter uma resposta, nesse caso, a resposta é "Não, isso não tem solução comumente aceita, seja criativo, encontre suas compensações bla bla bla"

Eu quero uma resposta para a seguinte pergunta específica:

Existe uma forma comumente aceita de proteger a senha para uma loja de segredos automatizada remota, como o Hashicorp Vault, em servidores Linux modernos?

Obviamente, o texto simples está fora de questão.

Existe uma resposta canônica para isso? Eu estou mesmo perguntando isso no lugar certo? Eu também considerava security.stackexchange.com, mas isso parecia específico para um modo de armazenar segredos para servidores Linux. Estou ciente de que isso pode parecer muito genérico ou baseado em opiniões, então saúdo qualquer sugestão de edição que você possa ter para evitar isso.

Nós rimos, mas a resposta que recebo aqui pode muito bem ser "em cofre". : / Por exemplo, um servidor Jenkins ou outra coisa tem uma senha revogável de 6 meses que é usada para gerar tokens de uso único, que eles então use para obter sua própria pequena senha efêmera (sessão limitada) gerada a partir do Vault, que obtém um segmento de informações .

Algo parecido com isso parece estar na mesma linha, embora seja apenas parte da solução: Gerenciando senhas de serviço com o Puppet

    

Answer 1

//, Primeiro de tudo, o problema discutido aqui vai além da mera entrega do segredo 0 ou o que eles chamam de "introdução segura" no jargão operacional.

Em vez disso, trata-se de garantir o segredo, uma vez recebido.

Eu não tenho uma solução de bala de prata para isso. Mas existem algumas opções de defesa em profundidade:

1. Use quebra automática de respostas para a entrega do segredo.
2. Coloque restrições CIDR em torno do token para a Loja secreta, de modo que o token seja utilizável apenas em um conjunto específico de endereços IP e use protocolos confiáveis como PROXY (NÃO X-Forwarding) para passar os endereços IP para o armazenamento secreto ( Por exemplo, defina token_bound_cidrs de uma forma que apenas uma sub-rede possa usar o token. / li>
3. Armazene o segredo apenas na memória e bloqueie a memória com o mlock.
4. Se possível, coloque limites de tempo no próprio segredo, ou até mesmo permita que o segredo seja usado apenas uma vez
5. Monitorar o uso incomum do segredo, por exemplo o cliente regular deve alertar se o seu segredo de uso único não funciona (porque já foi usado) e o servidor deve alertar se alguém está tentando usar o segredo de fora do intervalo de CIDR permitido
6. Isso é um pouco difícil, mas você pode permitir que exista um segredo de "honeypot" no servidor junto com o segredo regular, se possível, que dá "acesso" a um conjunto de credenciais a um sistema que apenas grava acessos e alertas.
7. Exigem nova autenticação para cada uso do segredo armazenado localmente, o que significaria que fatores de autenticação adicionais, além dos segredos armazenados localmente, precisam ser aplicados em cada uso, por exemplo, metadados assinados exclusivos para a instância de computação ou carga de trabalho ou, no Vault, um Approle
8. Desative qualquer tipo de cache de disco, para evitar que o segredo toque em qualquer armazenamento potencialmente persistente