Sistema multiusuário com banco de dados criptografado

5

Atualmente, estou desenvolvendo uma solução hospedada no ASP.NET usando o MVC3 e o Entity Framework. Este produto será disponibilizado para vários clientes como uma solução hospedada.

Como os dados armazenados por cada cliente serão críticos para seus negócios, prevemos que muitos deles insistirão em que os dados sejam armazenados de forma criptografada no banco de dados. Estamos, portanto, projetando o sistema com isso em mente.

Existe algum procedimento recomendado para fazer isso? Como alguém poderia fazer para criptografar os dados dos clientes de tal forma que até mesmo nós, com acesso root ao banco de dados, não conseguiríamos acessar seus dados?

Eu acredito que não há suporte embutido no EF para dados criptografados, isso é verdade? E se sim, como criptografar / descriptografar os dados?

    
por Gavin Coates 10.11.2011 / 14:24
fonte

4 respostas

2

Eu recomendaria pegar algo como o driver jTDS e adicionar criptografia a ele. Você teria que ter algum método de mapeamento de nomes de clientes para chaves de criptografia, mas isso não deveria ser difícil. E assim, você não precisa fazer nada em seu próprio aplicativo - toda a criptografia e descriptografia são tratadas pelo driver. Fazê-lo desta maneira também significa que você pode usar ferramentas de gerenciamento de banco de dados de terceiros para examinar o banco de dados - apenas certifique-se de que eles se conectem ao banco de dados usando o driver. É uma tarefa não trivial, mas acho que oferece uma solução limpa e agradável. Você pode fazer o seu desenvolvimento usando um driver padrão, assim você ainda pode olhar para os dados uma vez que estão no banco de dados, e então mudar para usar o driver de criptografia em produção.

    
por 10.11.2011 / 15:53
fonte
1

.Net tem bibliotecas de criptografia

Dê a cada cliente sua própria chave de criptografia, que é armazenada em seus servidores. O cliente criptografa os dados e envia para você para inserção. O banco de dados retorna dados criptografados que o cliente precisa descriptografar.

O problema é ... Você não pode ajudar o cliente se ele perder a chave, NOBODY CAN.

Mas esse parece ser o caso comercial (pelo que estou lendo), então ...

(Você também pode criptografar os dados novamente depois que o cliente envia os dados para que haja essencialmente um bloqueio "2 Key" nos dados.)

    
por 10.11.2011 / 15:16
fonte
1

No que diz respeito à prevenção do acesso, os esquemas de banco de dados podem ser úteis. Os esquemas podem ser criados e o acesso pode ser concedido a usuários específicos do banco de dados, que excluem contas de nível superior, como SA e assim por diante. Quando o banco de dados é criado, os scripts de criação podem ser dinâmicos para permitir isso.

Example:  Database1.ClientX.Table1
          Database2.ClientY.Table1

Se um usuário do banco de dados não tivesse acesso ao esquema ClientX, ele não conseguiria ver nenhum banco de dados, independentemente do nível de privilégio do sistema DBMS. É claro que um usuário com alto privilégio poderia ter acesso a esse esquema, mas suponho que haja alguma confiança dada aos poucos DBAs que realmente possuem essas permissões.

No que diz respeito à criptografia, provavelmente algum tipo de camada segura de middleware seria a melhor. Cada camada intermediária de mercadorias poderia ter uma chave privada diferente, portanto, não poderiam descriptografar os dados uns dos outros. Dessa forma, você não teria que armazenar chaves em cada cliente, mas na camada intermediária, talvez em um arquivo de configuração ou algo assim.

As chaves para criptografar os dados provavelmente também foram criptografadas, então, se alguém tiver acesso ao servidor, elas poderão simplesmente capturá-las e conectá-las à camada intermediária e ver tudo. Quem tem acesso a essas chaves, alguém que é de confiança.

Client X Data- MiddleWare Layer X Encrypt/Decrypt- Database X
Client Y Data- MiddleWare Layer Y Encrypt/Decrypt - Database Y

Uma instância de banco de dados separada seria a mais segura.

    
por 10.11.2011 / 22:18
fonte
0

Em um sentido puramente técnico, criptografar o banco de dados de tal forma que os administradores não podem ler os dados é bastante complicado - em algum lugar algo tem que descriptografar algo para mostrá-lo aos usuários, então a chave tende a viver em algum lugar do sistema com acesso root poderia sempre descriptografar os dados.

Na medida em que criptografar os dados, se você pode balançar uma licença Sql Enterprise, o Sql Server poderá fazer isso por você. Mas isso não significa muito, a menos que seu servidor de banco de dados esteja em uma rede não confiável. Concentraria meus esforços no design do aplicativo para que cada cliente tivesse um banco de dados separado, além de construir uma trilha de auditoria strong para desencorajar comportamentos nefastos.

    
por 10.11.2011 / 15:14
fonte