Início / dba / Perguntas / 35296
Accepted
Chris Travers
Asked: 2013-02-23 20:39:32 +0800 CST

Criptografia de banco de dados e gerenciamento de chaves com pg_crypto

  • 772

Estou analisando a possibilidade de ter que armazenar senhas de root para máquinas virtuais em formato criptografado reversivelmente em um banco de dados. O motivo é que, às vezes, os logins locais serão necessários para as máquinas, tanto quanto são desencorajados e precisamos ser capazes de procurar senhas de root. O acesso, é claro, seria fortemente restrito a alguns administradores. Eles não seriam usados, exceto quando a vm estiver inacessível pela rede. A sincronização de usuários e senhas a esse respeito apresenta problemas semelhantes, ou seja, se a rede estiver inativa, como o sudoer faz login com a senha mais recente garantida?

Qual é a melhor maneira de planejar a rotação das chaves? Devo usar apenas uma frase secreta que todo administrador possui? Isso levanta algumas bandeiras vermelhas em minha mente. Existe uma maneira de gerenciar com segurança as chaves de forma que os administradores possam definir suas próprias senhas? Talvez use criptografia de chave pública e criptografe uma chave simétrica com a chave pública de cada administrador?

Aqui, estou procurando apenas esboços gerais de uma solução em relação ao gerenciamento de chaves de dados confidenciais criptografados. Se eu não conseguir descobrir como implementar a partir desse nível, posso fazer mais perguntas.

postgresql encryption

1 respostas

  1. Best Answer

    Observe que não sou especialista em sistemas de criptografia ou segurança. Isso é o que eu vi feito e faz sentido, mas não posso afirmar que não tenha problemas de segurança além do que descrevo abaixo. Como sempre, obtenha uma auditoria de segurança adequada se for importante.

    A seguir, "credencial" pode se referir a chaves ssh, senhas ou qualquer coisa que precise ser armazenada.

    O modelo típico é usar alguns níveis de criptografia.

    • Para cada usuário, gere e armazene um par de chaves público/privado

    • Armazene a parte pública da chave do usuário de forma clara no registro do usuário

    • Armazene a parte privada da chave do usuário criptografada para a senha do usuário no registro do usuário.

    • Criptografe cada credencial para uma chave simétrica exclusiva dessa credencial

    • Criptografe a chave simétrica de cada credencial para a chave pública de cada usuário que deve ter acesso a essa chave e armazene o material criptografado resultante em uma user_credentialstabela de mapeamento.

    Essencialmente, você mantém um chaveiro, muito parecido com o chaveiro gpg, em que a parte pública está em texto não criptografado e a parte privada é criptografada em uma frase secreta. Você deve certificar-se de que a senha selecionada por cada usuário é forte.

    Agora você pode gerar uma chave simétrica para cada credencial criptografada. Criptografe essa chave para a chave pública de cada usuário e armazene-a em uma tabela de associação de credenciais de usuário. Nunca armazene essa chave simétrica não criptografada e use uma chave simétrica diferente para cada credencial.

    Você pousa com algo assim

    [user]
user_id
username
login_password_salt
login_password_hash
public_key_text
private_key_sym_encrypted_to_passphrase

[user_credential]
user_id
credential_id
credential_key_encrypted_to_user_public_key

[credential]
credential_id
credential_data_encrypted_to_credential_key

    Existem algumas vantagens em fazer as coisas dessa maneira:

    • Se um despejo de seu banco de dados vazar, suas credenciais ainda estarão seguras ou tão seguras quanto suas senhas e chaves fortes.

    • Como você tem uma chave simétrica diferente para cada credencial, você pode controlar quais usuários têm acesso a quais credenciais

    • Qualquer usuário com acesso a uma determinada credencial pode conceder acesso a outro usuário; eles apenas descriptografam usando sua chave e criptografam com a chave pública do outro usuário. Você não precisa reunir todos para adicionar credenciais ou adicionar novos usuários.

    • Como você está criptografando cada credencial para uma chave simétrica e, em seguida, criptografando essa chave para a chave do usuário, você pode alterar a credencial armazenada sem precisar criptografá-la novamente para a chave de cada usuário. Isso apenas torna a atualização das credenciais armazenadas mais conveniente.

    No entanto, se o host do banco de dados estiver comprometido, um invasor pode facilmente extrair as senhas às quais qualquer usuário tem acesso assim que o usuário fizer login. Eles capturam a senha do usuário agrupando funções ou ativando o registro detalhado e pesquisando os registros. Em seguida, eles podem descriptografar senhas em um despejo roubado ou no banco de dados ativo. Um host de banco de dados comprometido não é perigoso até que um usuário faça login para usá-lo, mas tudo estará perdido.

    Isso significa que o host do banco de dados é crítico para a segurança. Vazar o despejo não é fatal para a segurança, mas alguém capaz de modificar o código em execução no banco de dados é uma violação de segurança fatal.

    Além de usar seu banco de dados de gerenciamento de credenciais para extrair material de chave ssh, senhas etc. usado. Por exemplo, seu aplicativo pode descriptografar uma chave ssh, adicioná-la a um agente ssh e usar a chave descriptografada para efetuar login em um servidor por meio do agente sem que o usuário consiga ver e acessar a chave diretamente.

    • 5

relate perguntas