Devo criptografar dados no banco de dados?

16

Eu tenho um cliente, para o qual vou fazer um aplicativo da Web sobre atendimento ao paciente, gerenciamento de pacientes, consultas, histórico, calendários, tudo sobre isso basicamente.

O problema é que são dados confidenciais, histórico do paciente e outros.

O cliente insiste em criptografar os dados no nível do banco de dados, mas acho que isso vai deteriorar o desempenho do aplicativo Web. (Mas talvez eu não devesse me preocupar com isso)

Eu li as leis sobre proteção de dados em questões de saúde (Portugal), mas não é muito específico sobre isso (apenas as questionei sobre isso, estou aguardando a resposta delas).

Eu li o link a seguir , mas minha pergunta é diferente, devo criptografar os dados no banco de dados ou não.

Um problema que eu prevejo na criptografia de dados é que vou precisar de uma chave, essa pode ser a senha do usuário, mas todos sabemos como são as senhas do usuário (12345 etc.) e gerar uma chave que eu precisaria armazenar em algum lugar, isso significa que o programador, dba, o que poderia ter acesso a ele, alguma opinião sobre isso?

Mesmo adicionar um sal aleatório à senha do usuário não resolverá o problema, pois eu sempre posso acessá-lo e, portanto, descriptografar os dados.

Tio
fonte
1
Sou mais um desenvolvedor do lado do cliente, mas suspeito que criptografar tudo na verdade tornaria os dados menos, não mais seguros se você estiver usando a mesma chave.
precisa
4
você pode colocar o banco de dados inteiro em um volume criptografado e chamá-lo por dia. Claro lê / escreve será mais lento, mas você manter todo vantagem de RDMS (ou o que você está usando), enquanto os dados no disco é criptografado
DXM
2
Isso também significa que você não poderá ver dados no mysql workbench? Tudo de bom para depuração.
Dilsh R
4
Medical é uma indústria altamente regulamentada. Os profissionais que trabalham lá costumam pedir que alguém lhes diga quais são as regras. Essa mentalidade se espalha para projetos de TI. Não é realmente um problema de segurança. É uma questão cultural. O custo de fazer negócios na área médica.
Reactgular
1
Um hospital na Grã-Bretanha foi multado em mais de 300.000 libras porque as unidades de disco se perderam, contendo bancos de dados não criptografados. Informações de saúde são muito sensíveis.
MarkJ

Respostas:

9

Eu pessoalmente verificaria as leis sobre isso. Se os dados precisam ser criptografados, eles precisam ser criptografados.

Se você não receber nenhuma orientação, pretendo proteger o vínculo entre o paciente e seus dados. Ou seja, você provavelmente tem um PatientIDque é usado em tabelas em todo o banco de dados. PatientIDnão identifica um paciente, apenas o histórico médico do paciente etc ... No entanto, para identificar o PatientIDJoe Bloggs morando na Rua de São Bernardo em Lisboa, eu o manteria em um banco de dados separado, se puder. Use o TDE para obter detalhes pessoais do paciente e considere criptografá-lo usando chaves no seu aplicativo da Web.

Embora o roubo desses dados médicos sem os meios para identificar os pacientes seja extremamente embaraçoso, é improvável que haja algo além disso. Existem literalmente competições online que usam esses dados médicos anonimizados.

Com a separação dos dados médicos dos detalhes pessoais do paciente. Use um conjunto robusto de funções para limitar a equipe apenas ao que eles precisam. Com exceção da equipe médica que exige lidar diretamente com o paciente (enfermeiros e médicos da linha de frente), ninguém deve ter acesso a ambos. Os recepcionistas precisam apenas dos dados pessoais do paciente, a equipe do laboratório precisa apenas do prontuário médico e da identificação do paciente, as enfermeiras cirúrgicas atualmente só têm condição médica e nome.

Quando você identificar cada conjunto de funções, tente não apenas implementá-las em seu aplicativo da Web, mas também no banco de dados, além de uma camada extra de segurança.

M Afifi
fonte
1
IANAL, mas os leigos da OMI não devem "verificar as leis" quando a possível responsabilidade for grande. Eles devem consultar um advogado.
kevin Cline
eu uso essa abordagem como uma resposta verdadeira. registros médicos que não estão vinculados a pacientes ou médicos não têm sentido e são inutilizáveis, mesmo para análises estatísticas, pois não têm referência nem provam que não são inventados.
Zalaboza
13

Sim, você deve criptografar o banco de dados.

A criptografia básica para dados armazenados ("dados em repouso") é um Princípio de Segurança Geralmente Aceito e provavelmente é obrigatório por lei se o seu país tiver leis que protegem informações pessoais ou de saúde.

Estamos usando o SQL Server 2008, então usamos o TDE da Microsoft; pode haver alguma solução de terceiros para o MySQL ou talvez apenas uma abordagem geral de criptografia de volume (como TrueCrypt) funcione (embora eu queira ter algo que foi certificado para uso em um banco de dados).

Se feito corretamente, o desempenho deve ser pequeno.

A propósito, o link que você mencionou (referente à separação de informações confidenciais) é algo que você deve considerar sobre a criptografia básica do banco de dados.

EDIT: A criptografia mencionada acima criptografaria o volume. Se alguém roubasse o disco rígido, eles encontrariam os dados criptografados. No entanto, se alguém executasse consultas no banco de dados, veria os dados não criptografados (foi por isso que mencionei a separação de informações, mesmo que o OP não quisesse discutir isso).

Observe que esta recomendação é o mínimo que você deve fazer. Se você deseja aconselhamento jurídico, é claro que precisará procurar em outro lugar. Se você quiser uma discussão mais aprofundada sobre como escrever código seguro, eu começaria com o livro Writing Secure Code .

jdigital
fonte
2
Não tenho certeza se é esse o caso. A questão não é sobre criptografar o banco de dados, mas sobre criptografar os dados no banco de dados. Isso significa que os dados nas consultas sql serão criptografados.
Dilsh R
1
O impacto no desempenho deve ser pequeno? A pesquisa de dados será LENTA. Todo o conceito de indexação não funciona quando os dados são criptografados. Isso exigirá uma verificação de tabela completa.
mike30
@ Mike A abordagem acima seria criptografar o volume e não teria impacto indexação etc.
jdigital
Na IMO, você precisa de mais experiência do que pode obter aqui. IANAL, mas acho que seu cliente tem uma exposição bastante alta se esses dados forem comprometidos.
Kevin cline
8

Antes de decidir sobre esses assuntos de segurança, você deve avaliar o modelo de ameaça. Sem uma ideia contra a qual você está se defendendo, qualquer medida que você tome provavelmente terá pouco valor.

Agora, há algumas coisas com as quais você pode se preocupar neste contexto:

  • Os invasores obtêm acesso físico aos seus dados (por exemplo, invadir o datacenter, roubar fitas de backup etc.)
  • Atacantes obtendo acesso de leitura ao seu banco de dados bruto
  • Os invasores comprometem sua aplicação, por exemplo, através de injeção de SQL, saturação de buffer, etc.

Para o primeiro cenário, armazenar o banco de dados e todos os backups em volumes criptografados deve funcionar, desde que o servidor esteja sem cabeça - roubar o servidor ou as fitas exigiriam a quebra da criptografia no nível do disco.

Para o segundo cenário, criptografar dados do banco de dados ajuda, mas apenas se você não armazenar as chaves ou senhas necessárias em qualquer lugar.

No terceiro cenário, tudo depende do contexto em que o ataque ocorre: se, por exemplo, é um ataque XSS ou CSRF, um invasor pode fazer o que o usuário legítimo puder e criptografar seus dados não ajuda em nada. .

O modelo de ameaça, portanto, é um invasor que obtém acesso de leitura ao banco de dados bruto, localizando as credenciais de logon e gerenciando o logon no servidor de banco de dados de fora ou obtendo acesso root ao servidor de banco de dados. Um caminho típico é obter primeiro acesso ao shell no servidor da web; a partir daí, um invasor pode ler as credenciais de acesso do arquivo de configuração e conectar-se ao banco de dados.

Uma consideração adicional é onde você mantém as chaves e as senhas, especialmente se estiver usando uma plataforma com um modelo de execução sem estado, como o PHP. Idealmente, você deve digitar a senha do cliente quando necessário e mantê-la apenas na memória, ou melhor ainda, descriptografar no lado do cliente (mas isso geralmente não é possível). Em uma plataforma sem estado, o estado geralmente é transportado usando sessões, memcache, bancos de dados ou arquivos simples; mas tudo isso é muito mais vulnerável do que manter o estado na própria memória de um aplicativo da Web estável. Evitar isso é um problema de galinha e ovo, porque se você criptografar o estado antes de persistir, acabou de criar outro segredo do qual precisa se lembrar com segurança. Lembrar a senha no cliente e enviá-la juntamente com cada solicitação que precisar pode ser a solução menos horrível;

tdammers
fonte
2
+1: sem um modelo de ameaça, provavelmente você está trancando a porta da frente, mas deixando a porta dos fundos aberta.
kevin Cline
8

Ignorando por um momento o que o cliente está pedindo e quaisquer que sejam as leis ...

Não, você provavelmente não deve criptografar os dados. Se o fizer, não poderá pesquisá-lo facilmente. Por exemplo, como você pesquisaria um sobrenome like 'Smith%'se todas as entradas de nomes fossem criptografadas? Como você representaria graficamente a pressão sanguínea de um paciente ao longo do tempo, se não puder select .... from.... where patient_id = N?

Obviamente, você deve garantir que o servidor esteja protegido corretamente, a conexão de rede e a interface do usuário esteja protegida adequadamente (incluindo tempos limite de sessão para que os usuários não possam sair deixando o acesso a quem usa o computador). Você também pode querer criptografar os backups do banco de dados. E proteja fisicamente a sala em que o servidor está localizado. Mas eu não criptografaria os dados ativos.

Esclarecimento: Isso pressupõe que o OP estava perguntando na verdade criptografando os dados no banco de dados. Não é o sistema de arquivos no qual o banco de dados reside.

GrandmasterB
fonte
concordo totalmente, no entanto, as LEIS não :(
Zalaboza
1
Bem, você pode AES_DESCRYPT('') LIKE 'Smith%'incrivelmente lento. Ou você pode ficar intenso e faça um índice invertido com hashes salgados
Foochow
1

Se você desenvolver o aplicativo Web cuidadosamente, usando uma estrutura MVC eficaz como o CakePHP. Zend ou Rails, você poderá habilitar / desabilitar a criptografia no nível Modal de dados.

O CakePHP, por exemplo, tem alguns exemplos de comportamentos para os modais que criptografam dados. Tornando o processo transparente para os Controladores e Exibições.

Ignorando problemas sobre indexação e outros problemas técnicos do banco de dados ao fazer isso. Deve ser possível ter isso como uma opção configurável.

Além disso, eu ativaria a criptografia posteriormente ou apenas no servidor de produção. É difícil depurar e trabalhar com dados criptografados durante o desenvolvimento e só pode ser feito em determinadas colunas.

Reactgular
fonte
1

Sim, você deve criptografar o banco de dados.

Como essas informações são pessoais e confidenciais, eu definitivamente acredito que deveria.

Da senha, você pode derivar uma chave de criptografia que você armazena apenas para a sessão. Dessa forma, ele não é armazenado em nenhum lugar e ninguém (incluindo DBAs) pode conhecê-lo, pois ninguém também pode saber a senha. Qualquer pessoa que tente visualizar o banco de dados diretamente estará olhando sem sentido. A única maneira de corromper isso é através do seqüestro de sessão, mas estou assumindo aqui que as sessões também são seguras.

dagnelies
fonte
As pessoas muitas vezes esquecem suas senhas ... e depois?
precisa
-1

Eu me pergunto por que o cliente pede para você criptografar o banco de dados? Se ele pedir para você proteger os dados, eu concordo, mas ele já tem uma implementação implícita em mente. Então, desde que ele não saiba exatamente do que está falando, está apenas lançando chavões do meu ponto de vista.

Também acho muito inútil criptografar o banco de dados, porque estou convencido de que literalmente todos os principais DBMS levam em conta a segurança de maneira apropriada e provavelmente melhor do que você poderia. Para acessar o banco de dados através do DBMS, você precisa de credenciais. No caso de um banco de dados criptografado, você também precisará dessas credenciais e, para descriptografar os dados, precisará das credenciais que já parece possuir.

Seguindo essa mentalidade, proponho que o DBMS lide com a segurança e faça esforços para proteger as credenciais desde a entrada do usuário até o acesso ao banco de dados, também pode impor senhas fortes e alterações periódicas.

sschrass
fonte
... todos os DBMS importantes levam segurança à conta ... exceto quando não o fazem .
Jay Elston
A primeira pergunta que eu teria que perguntar é como eles fizeram isso e como o dano poderia ser evitado pela criptografia do banco de dados. Acabei de ler rapidamente este artigo, mas tive a impressão de que eles possuíam credenciais.
Sschrass
Exatamente - as credenciais do banco de dados podem ser comprometidas. O desafio é projetar o sistema para que, mesmo quando usuários não autorizados tenham acesso às credenciais, eles ainda precisem de chaves de criptografia adicionais para poder acessar dados confidenciais. Para informações de saúde, isso é ainda mais complicado. Nem todo mundo com acesso às credenciais do banco de dados deve poder acessar dados confidenciais. Por exemplo, o DBA não deve ser capaz de ler os dados do paciente em texto não criptografado. As únicas pessoas que devem poder ler esses dados são os pacientes e seus fornecedores.
Jay Elston