Como posso proteger dados em tabelas SQL?

Sep 30 2020

Inspirado pelos muitos vazamentos de dados em que bancos de dados / tabelas inteiros com informações pessoais do usuário foram vazados, quais são as melhores práticas para proteger esses ativos? Estou especialmente preocupado se alguém foi capaz de obter acesso ao código de back-end (o que definitivamente não deveria ser o caso) e, portanto, adquirir as credenciais SQL.

Estou armazenando dados de contas pessoais que precisam ser acessados apenas pelo usuário correspondente.

Minha ideia é criptografar os dados da tabela simetricamente com o nome de usuário e a senha do usuário. Isso torna muito difícil, no entanto, ao lidar com redefinições de senha ...

Existem outras idéias ou implementações comuns para este cenário?

Respostas

3 Sjoerd Sep 30 2020 at 15:33

Estou especialmente preocupado se alguém conseguiu acessar o código de back-end e, portanto, adquirir as credenciais SQL.

O sistema de banco de dados deve ser acessível a partir de um número limitado de sistemas. Especificamente, não deve ser acessível pela Internet. Se alguém tiver as credenciais SQL, ainda não terá acesso ao servidor.

Fontes comuns de vazamentos são:

injeção SQL
Servidor não autenticado exposto, como MongoDB, ElasticSearch
Exporte CSV ou documento exposto, por exemplo, através do Google Drive
Abra o bucket do Amazon S3
Exfiltração de dados após hack

Minha ideia é criptografar os dados da tabela simetricamente com o nome de usuário e a senha do usuário.

A maioria dos aplicativos da web tem seu texto simples de dados no banco de dados e simplesmente verifica com a lógica de negócios no aplicativo se um usuário pode acessar um determinado objeto. O que você propõe daria melhor segurança, mas também introduziria mais complexidade. Pense se vale a pena.

Isso torna muito difícil, no entanto, ao lidar com redefinições de senha ...

Ao criptografar dados com a senha do usuário, esses dados são perdidos quando o usuário esquece sua senha. Em alguns casos, isso é aceitável e o usuário deve apenas criar uma nova conta. Caso contrário, isso às vezes é resolvido fornecendo ao usuário uma chave de descriptografia ao configurar sua conta, que ele deve imprimir e salvar. Esta é uma chave "backdoor" que pode descriptografar a conta quando a senha é esquecida.

Max Oct 01 2020 at 03:49

Você quer proteger os dados. Mas de quê? De quem?
Você precisa definir um cenário possível e, em seguida, tentar encontrar uma maneira de se proteger de um perigo específico, de uma maneira específica que um invasor possa tentar roubar seus dados.

E quanto ao hacking físico ? Alguém pode entrar e roubar seu servidor? Alguém pode fazer uma cópia dos dados ativos? Alguém pode acessar os backups? ( porque você tem uma cópia de backup , no local, fora do local, e todos esses backups são protegidos por senha , certo?)

Se você deseja criptografar os dados, você precisa definir em que nível deseja criptografar os dados .
Em certos RDBMS, você pode criptografar todo o banco de dados no disco e armazenar a chave no servidor de banco de dados. Isso pode protegê-lo se alguém roubar uma cópia dos arquivos do seu banco de dados. Mas não o protegerá se alguém roubar as credenciais do banco de dados.
Ou você pode passar a chave de criptografia com a string de conexão, mas esses tipos de coisas podem variar muito entre os diferentes RDBMS.

Você pode modificar seu aplicativo / site para criptografar todos os dados em cada linha / coluna do banco de dados .
Agora você tem muita segurança e muitos problemas :

Como você classifica uma tabela de dados criptografados? você não.
Índices de coluna ? sem utilidade.
Você pode fazer um SELECT ... WHERE Encrypted_Name_Column como '% Fox%' ? não, você não pode.
Como você criptografa uma coluna de data / hora ? Você converte a data em string e, em seguida, criptografa a string? Boa sorte com a descriptografia quando o horário de verão começar ...
Como você gerencia IV ( vetor de inicialização ) do algoritmo de criptografia? Se você criptografar os mesmos dados, com as mesmas chaves e o mesmo IV, obterá a mesma saída criptografada. Portanto, um invasor pode não ser capaz de descriptografar os dados, mas pode detectar que certos valores são os mesmos , porque os valores criptografados são os mesmos.

Você pode fazer tudo isso, mas realmente vale a pena?

Como você gerencia as chaves de criptografia?
Normalmente, você não usa a senha diretamente para criptografar os dados . Normalmente, você gera uma chave segura aleatória para criptografar os dados e, em seguida, usa a senha para derivar uma chave para criptografar a chave usada para os dados.
Desta forma, você pode alterar a senha sem a necessidade de criptografar novamente todos os dados.
Agora, se você perder a senha, precisará de um plano alternativo ... como uma cópia da chave de criptografia de dados, criptografada com uma senha mestra, usada apenas para redefinir a senha. (mas agora, você tem uma senha mestra, que pode descriptografar todos os dados de todos os usuários ... onde você os armazena? em um servidor air-gap?)

Seria melhor dividir os serviços e tentar reduzir a superfície de ataque?
Por que seu aplicativo / site precisa das credenciais DB? Você pode criar um aplicativo / site que nunca acesse diretamente o banco de dados, mas apenas acesse os dados por meio de um serviço da web. O serviço da Web para acessar os dados pode estar em um segundo servidor não acessível pela Internet. As credenciais do banco de dados, usadas pelo segundo servidor, podem ser armazenadas em um terceiro servidor e acessadas pela rede com uma conta específica ...
Você pode construir a segurança camada por camada.