Ter um sistema que expira chaves SSH a cada 90 dias

Question

Eu tenho um cliente que agora exige que nós alteremos todas as senhas a cada 90 dias devido à sua interpretação do GDPR. Isso é bom para o sistema baseado na web que desenvolvemos para eles, porque podemos simplesmente implementar essas regras. Mas eles também exigem que nós alteremos as senhas em nossas chaves SSH usadas para acessar os servidores, o que não é bom.

1. É possível alterar a senha em uma chave SSH existente?

2. Se não, existem ferramentas que podemos usar para lidar com isso? Estou pensando:

   a. Crie novas chaves.
   b. Distribuir todas as chaves públicas para servidores existentes.
   c. Remover chaves públicas existentes.
   d. Arquivar chaves privadas antigas.

   Eu li alguns posts aqui sobre o Puppet, mas pelo que entendi eles visam apenas resolver o problema de distribuir as chaves públicas entre os servidores e não criar novas chaves a cada dia? Devo ir mais longe com a minha pesquisa em Marionete?

3. Qual é o padrão da comunidade quando se trata de retenção de senhas e chaves ssh? Como você faz isso?

Answer 1

O cliente está errado aqui e não entende o que está falando. Alterar a senha em uma chave privada é uma idéia muito ruim , porque ela tem propriedades de segurança muito intuitivas.

Normalmente, os usuários pensam em senhas que foram alteradas como "não mais secretas". Eles podem se tornar senhas descartáveis para sites de baixo valor, identificadores / apelidos on-line, piadas para piadas, etc., e qualquer papel no qual eles estejam escritos pode se tornar um fragmento exposto.

Para uma frase secreta usada para criptografar uma chave privada, não é assim que funciona ! A frase secreta deve ser mantida em segredo para sempre , a menos que todos os privilégios associados à chave tenham sido revogados (e o seguinte não se aplique a chaves ssh, mas se a senha for de uma chave usada não apenas para assinatura, mas para receber mensagens privadas, sempre significa realmente para sempre ). Isso ocorre devido à possibilidade de o arquivo de chave privada criptografada ter sido obtido por um invasor ou armazenado em algum lugar (como em um backup), onde pode ser obtido por um invasor no futuro. Se a frase secreta for revelada, ela será comprometida.

Em algum sentido, uma chave privada que passou por N passphrases durante sua vida útil é 1 / N como segura, já que o conhecimento de qualquer um dos passphrases passados é suficiente para comprometer a chave se O invasor teve acesso ao arquivo de chave privada criptografado.

Agora, voltemos ao seu problema.

Se o cliente não tivesse capturado esse conceito errado de "senhas ssh" e descoberto, a melhor coisa a fazer seria simplesmente nunca abordá-lo e seguir as práticas recomendadas para o manuseio das chaves. Mas agora que eles têm, você provavelmente tem que fazer algo para satisfazê-los. Você poderia tentar explicar como as senhas que criptografam chaves privadas têm propriedades de segurança diferentes das senhas, mas, considerando o quão errado o cliente está sobre muitas coisas aqui (a expiração da senha é uma má ideia em geral), duvido que funcione.

Isso deixa você com a tarefa de automatizar um sistema para distribuir novas chaves. Eu iria desencorajar strongmente você de automatizar um sistema de gerar as novas chaves de forma centralizada, uma vez que chaves privadas nunca devem ser movidas entre máquinas . Em vez disso, você deve ter processos / lembretes / scripts para tornar mais fácil para os funcionários / contratados do seu lado que precisam de acesso para gerar novas chaves privadas e publicar as chaves públicas correspondentes, e ter o sistema de distribuição de chaves públicas você usa isso para os sistemas que eles precisam acessar.

Além disso: Uma coisa que pode convencer o cliente a abandonar isso é mencionar que fundamentalmente não há como impor que a nova chave privada tenha uma frase-senha diferente da antiga, ou mesmo que tem uma senha em tudo.

    

Answer 2

A resposta para sua primeira pergunta: "É possível alterar a senha em uma chave SSH existente?" é sim. Com o openssh é tão simples quanto ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

O problema é que a senha está no / no arquivo de chave privada, que é um formato simples que não tem suporte para uma data de expiração. Também uma grande parte do conceito de autenticação baseada em chave no ssh é que a chave privada não é gerenciada centralmente, ela deve existir apenas na estação de trabalho do usuário, o que torna quase impossível impor uma política de expiração de senha na chave privada.

Em vez disso: em todos os ambientes em que estive antes que a política de senha estivesse no objeto da conta do usuário, não no método usado para acessar a conta. Quando uma senha expirou ou uma conta foi bloqueada, todos os métodos de acesso foram bloqueados, incluindo a chave ssh.

Adicione a autenticação multifator quando precisar de mais segurança em uma conta.

Mas estou curioso sobre o que outras pessoas fizeram para resolver suas preocupações válidas.

    

Answer 3

Usando AuthorizedKeysCommand , alguns mecanismos de expiração podem ser implementados no lado do servidor. Desde a simples verificação do registro de data e hora do arquivo até algo mais complicado.

    

Answer 4

Uma possibilidade que pode ou não ser suficiente é usar uma CA do usuário SSH, que permite definir uma vida útil na chave assinada. Qualquer que seja a automação que você fizer em torno da assinatura das chaves, você pode se recusar a assinar por mais de 90 dias. Em seguida, adicione a chave pública para sua CA de usuário a TrustedUserCAKeys em / etc / ssh / sshd_config e defina AuthorizedKeysFile como none.

    

Answer 5

Você pode usar uma ferramenta como Hashicorp's Vault para criar chaves SSH assinadas de curta duração . Cada usuário receberia uma nova chave todos os dias (ou assim). Você autenticaria no Vault para obter o certificado usando o que você usa hoje, como um servidor LDAP.

O esforço de configurar isso não é imenso, mas na minha experiência é maior do que o @Mark referiu em seu comentário. Você está basicamente substituindo um problema (requisitos clueless do cliente) por outro ( gerenciamento de fragmentos ).

Mas ele permite alguns outros cenários, como gerar facilmente certificados X509 internos e gerenciar senhas de bancos de dados, segredos de aplicativos em arquivos de texto. Você julga o esforço e o ROI.

Observe também que a versão de código aberto não tem recursos de DR (tem tudo mais).

    

Answer 6

Você pode usar um agente de chave que incorpore senhas de tempo único baseadas em tempo (TOTP). Agora sua "senha" muda a cada minuto.

_{Todos os outros aqui estão certos, no entanto: Isso é bobagem.}