Não sou um DBA, mas me pediram para ver se podemos criptografar os dados no sql server de forma que o administrador, apesar de ter acesso ao SQL Server, não consiga ver os dados, mas o aplicativo ainda poderá consulte-o e leia os dados.
Meu conhecimento limitado de criptografia me diz que, se o aplicativo criptografar os dados, o db não poderá consultá-los. Se db criptografar os dados, o DBA pode definitivamente lê-los.
Então, existe uma maneira de impedir que o DBA espie os dados, mas ainda seja capaz de gerenciar o banco de dados?
Você precisará criptografar os dados no aplicativo e armazenar os valores criptografados no banco de dados. Coisas como TDE e criptografia de nível de armazenamento não atenderão aos seus requisitos.
Acho que você está se referindo à criptografia em nível de célula , mas o uso desse recurso requer a alteração do aplicativo. TDE (criptografia de banco de dados transparente) é outra opção, isso criptografa os arquivos no disco, mas eles são descriptografados na memória, para que qualquer pessoa com acesso direto à máquina e privilégios suficientes para examinar diretamente o cache do buffer de bloco possa acessar os dados.
Uma abordagem alternativa é simplesmente usar a função db_backupoperator para que a conta que o DBA usa possa fazer backup do banco de dados, mas não tenha direitos de examinar os dados. Nesse cenário, você gostaria de ter a
sasenha anotada e trancada em um cofre, caso realmente precise dela.Mas, como um aparte, se você está preocupado com o roubo de seus dados pelo DBA, seus problemas são organizacionais, não técnicos. Eu mesmo trabalho em um setor regulamentado e os DBAs e SAs são cuidadosamente verificados (por exemplo, verificações anuais de antecedentes) e armazenamos dados no banco de dados em BLOBs criptografados para os quais o aplicativo possui as chaves (e ninguém possui logins na máquina com o dados e a máquina com as chaves). No entanto, é possível levar essa estratégia longe demais . Em um dos meus projetos atuais, preciso usar o LDAP para autenticação. Há algum problema, mas não há ninguém que tenha permissão para fazer login na caixa DB e na caixa LDAP, portanto, diagnosticar o problema é muito difícil - o que, para os negócios, significa caro.
Como desenvolvedor, já usei um método de criptografia direcional antes. Onde o aplicativo criptografa e armazena os dados no banco de dados ex: senha. Isso foi feito de forma que mesmo uma pessoa com acesso aos dados não consiga ler a senha. O aplicativo nunca precisou descriptografar a senha, apenas criptografar a entrada do usuário e passá-la ao banco de dados para verificação. Portanto, neste caso, mesmo que "confiemos" no DBA, nunca deve haver uma razão para eles (ou qualquer outra pessoa) saberem dessa informação.
Mas, mais uma vez, isso vai para o nível do aplicativo e o banco de dados permanece como está.