Como adicionar usuários a uma tabela de mapeamento?

5

Na resposta aceita a "Criptografar dados armazenados para vários usuários únicos acessarem informações" , @ lserni descreve uma tabela de mapeamento para usuários. Mas entre as operações para a tabela, eles não mencionaram a adição de um usuário, nem as solicitações de redefinição de "esqueci minha senha", que são necessárias para o meu ambiente (crescente / variável). Como posso fazer isso?

A única solução que consigo imaginar é forçar alguém como root a efetuar login, descriptografar sua própria chave e, em seguida, fornecê-la ao novo usuário para criptografar novamente. Mas isso é ineficiente e eu gostaria de automatizar o processo - ou seja, eu gostaria de permitir que um usuário crie um novo usuário sem forçar alguém a fazer o login.

Em suma, minhas especificações são:

  1. Eu tenho um banco de dados que armazena dados para vários grupos.
  2. Os dados de cada grupo devem ser privados. Ou seja criptografia para diferentes grupos usam chaves diferentes.
  3. Cada grupo tem vários usuários. Os usuários podem pertencer a vários grupos. Ou seja cada usuário precisa ser capaz de ler / gravar (e, assim, criptografar / descriptografar) todos os dados de cada grupo a que pertencem.
  4. Eu quero poder adicionar, remover e atualizar: os usuários (especialmente suas senhas / chaves de criptografia de chave), os grupos, as chaves de criptografia de dados e os dados.

Além do problema que estou perguntando, a solução da Iserni parece ideal (reconhecendo, é claro, que uma senha deve ser executada através do PBKDF2 ou um algoritmo de alongamento de chave similar antes de ser usado como uma chave de criptografia).

    
por Miryafa 30.06.2016 / 16:53
fonte

2 respostas

2

I want to be able to add, remove, and update: the users (especially their passwords/key-encrypting-keys), the groups, the data-encrypting keys, and the data.

Acho que você pode obter a independência necessária entre entidades usando uma mistura de criptografia assimétrica e simétrica. Os requisitos de armazenamento de dados são bastante altos, mas apenas poucos dados precisam ser protegidos.

Você pode ter:

User        Public Key      Private Key
lserni      PUB             XXXXXXX

Group       Group Encryption Key
poponi      ZZZZZZZ symmetrically encrypted with YYYY

ZZZZZZ é a chave criptográfica usada para criptografar simetricamente os dados do grupo poponi; esse valor é simetricamente criptografado com a chave criptográfica YYYY, que é a "senha do grupo".

Mapping     
lserni      poponi     YYYY encrypted with lserni's public key

Quando você cria um grupo e atribui um administrador a ele, uma chave de criptografia simétrica aleatória ZZZZZZ é gerada e usada para criptografar os dados desse grupo. Este valor não é armazenado de forma clara, mas criptografado com outra senha aleatória YYYY, que será associada aos usuários.

Esta dissociação de YYYY e ZZZZZZ permite tornar os dados inacessíveis apenas mudando YYYY (o que afeta apenas uma coluna) em vez de ter que alterar ZZZZZZ (o que requer descriptografia e nova criptografia de quaisquer dados que o grupo tenha). Claro, se os dados criptografados não são muito mais do que uma única coluna do banco de dados, há pouco a ser ganho por este segundo nível de indireção, e um pode se livrar de YYYY completamente e armazenar a criptografia de ZZZZZZZ no mapeamento do usuário tabela em vez da criptografia de YYYY.

Cada usuário também tem um par de chaves pública / privada atribuído, com a chave privada sendo simetricamente criptografada com a senha do usuário.

Isso permite que terceiros (administradores de grupo, etc.) forneçam a qualquer usuário uma informação, YYYY, que somente ele poderá ler de volta.

Quando o usuário efetua login, ele descriptografa sua chave privada usando sua própria senha, usa a chave privada para acessar o valor YYYY para a senha do grupo e recupera ZZZZZZZ. Ele agora pode ler e escrever o grupo (e esquecer YYYY por completo).

A exclusão de usuários e grupos é direta. Exceto que um grupo sem usuários é perdido para sempre e também pode ser excluído. Por esse motivo, a exclusão do usuário deve garantir que pelo menos um usuário administrativo esteja sempre presente.

O simples acréscimo de usuário também é simples (geramos o par de chaves e o armazenamos, a chave privada criptografada com a senha temporária usada no primeiro login). Neste ponto, o usuário é atribuído a nenhum grupo, então nada mais é necessário.

Quando o usuário altera sua senha, sua chave privada é descriptografada com a senha antiga e criptografada novamente com a nova senha.

Para atribuir um usuário a um grupo, a senha do grupo deve ser conhecida pelo aplicativo, o que exige que alguém com acesso de grupo esteja conectado. Essa pessoa pode criar uma linha de mapeamento, pois a chave pública do atribuído está desimpedida. .

Quando a senha do grupo é alterada, todos os usuários desse grupo obtêm seus dados atualizados, e isso pode ser feito sem saber a senha do usuário. A operação é feita por alguém que tenha acesso de grupo, então ele tem a senha do grupo.

 user     group   pwd_of_group_encrypted_with_user_privkey
 lserni   poponi  *****

Para criptografar novamente os dados do grupo, todos os dados precisam ser descriptografados com a chave antiga e criptografados novamente com a nova chave, e a linha de informações do grupo precisa ser atualizada. A senha do grupo, com a qual a chave antiga foi criptografada, é usada para criptografar a nova chave e armazená-la na linha de informações do grupo.

Esta operação nunca deve ser necessária, pois a chave de criptografia do grupo ZZZZZZZ nunca é perdida (nem a senha do grupo YYYY).

Essa arquitetura também garante que alguém sem acesso a um grupo nunca possa adicionar mais ninguém (ou a si mesmo) ao grupo. Se um usuário conseguir roubar todo o banco de dados, ele ainda poderá obter apenas os dados a que tinha direito.

Quem atribui um usuário a um grupo?

Para atribuir um usuário a um grupo, é preciso ter acesso ao grupo, o que significa conhecer a senha. Se houver um administrador de grupo decidindo quem pertence a qual grupo, tudo bem.

Mas e se um usuário tiver que ser atribuído ao grupo committers automaticamente ? Em seguida, o aplicativo precisa ter acesso à senha, o que significa que o sistema não pode ser autônomo e seguro.

Nós podemos tê-lo como não auto-suficiente, armazenando a senha em um sistema diferente com acesso restrito e uma superfície de ataque muito pequena. Mesmo que alguém roubasse o banco de dados, a senha do grupo não estaria lá.

Eu não acho que o problema possa ser resolvido, porque quem pode conceder acesso a um grupo pode fazê-lo em todas as circunstâncias; se o "quem" reside no sistema, porque é o próprio aplicativo, a captura do sistema implicará na obtenção de acesso aos dados de todos os grupos.

    
por 30.06.2016 / 21:08
fonte
1

O problema que tenho com a resposta para a pergunta que você postou é que, se você visualizar os requisitos do OP para segurança, em lugar algum ele realmente menciona que cada usuário deve fornecer suas próprias chaves de descriptografia. De fato, a questão chega a ponto de sugerir que eles explicitamente não querem que a senha do usuário seja uma determinação na criptografia de dados no banco de dados.

Não concordo com a resposta fornecida aqui.

A maneira apropriada de lidar com isso é a seguinte:

  • Autentique o usuário independentemente de dados criptografados
  • Autorize adequadamente os usuários a visualizar apenas os dados que eles têm o privilégio de ver.
  • Persista as informações confidenciais em um formulário Criptografado com um algoritmo criptográfico strong
  • Use uma chave específica do aplicativo geral ou um conjunto de chaves para criptografar todos os dados
  • Assegure-se de que comprometer o servidor de banco de dados não protege o acesso à chave de criptografia / descriptografia (execute todas as operações criptográficas fora do banco de dados, por exemplo, no servidor de aplicativos, em um HSM etc.)

Os dados ainda são criptografados e com um algoritmo strong como o AES, não há ataques possíveis ao texto criptografado sem ter a chave. Qualquer pessoa que esteja apenas espiando no banco de dados não verá informações confidenciais.

Isso eleva a barra, no entanto, na sua lógica de autorização no aplicativo. Ele deve ser strongmente testado em unidade e testado para garantir que apenas usuários autorizados possam visualizar os dados que devem ser visualizados.

A resposta que você faz referência é muito mais complicada do que o que o OP sugere por meio de requisitos e, na verdade, é potencialmente menos segura no processo. A chave deve sempre ser mantida em segredo e privada e nunca compartilhada. Além disso, é super-engenharia no seu melhor.

    
por 30.06.2016 / 17:15
fonte