Nenhum banco de dados central

Eu tenho um cliente que deseja obter um site / aplicativos móveis / aplicativos de desktop criados para lidar com dados muito sensíveis (mais sensíveis que os detalhes do banco / cartão). Devido à natureza sensível dos dados, eles não desejam salvá-los em um banco de dados central, mas ainda desejam que seus aplicativos sejam sincronizados (digamos que eu adicione alguns dados ao meu aplicativo móvel, desejo poder ir ao meu aplicativo de desktop e veja os mesmos dados).

Não consigo pensar em uma maneira agradável e confiável de fazer isso e não tenho certeza de que exista alguma. É por isso que estou aqui. Alguém sabe como eu poderia lidar com esses dados?

Uma solução em que eu estava pensando era ter um banco de dados do lado do cliente em cada aplicativo que, de alguma forma, fosse sincronizado entre os aplicativos; posso ver isso sendo pouco confiável e ficando confuso.

Muitas informações confidenciais são armazenadas nos bancos de dados. De fato, um banco de dados central é provavelmente a maneira mais segura de armazenar esses dados. Os bancos de dados corporativos grandes têm toneladas de funcionalidade para realizar tarefas como criptografar informações confidenciais, auditar quem as acessa, limitar ou impedir que pessoas, incluindo DBAs, visualizem os dados, etc. Você pode ter especialistas em segurança profissionais monitorando o ambiente e DBAs profissionais supervisionando backups para que você não perde dados. Certamente seria muito mais fácil comprometer os dados armazenados no dispositivo móvel ou laptop de um usuário aleatório do que penetrar em uma infraestrutura de segurança bem projetada e comprometer um banco de dados central adequado.

Você pode projetar o sistema com um banco de dados central que armazena apenas dados criptografados e armazena a chave privada do usuário no dispositivo do usuário. Dessa forma, mesmo se o banco de dados central estiver completamente comprometido, os dados serão utilizáveis ​​apenas pelo usuário. Obviamente, isso significa que você não poderá restaurar os dados do usuário se eles perderem a chave (digamos que a única cópia estava no telefone e o telefone estava danificado). E se alguém comprometer a chave e, presumivelmente, suas credenciais de logon, poderá ver os dados.

Você precisa fazer backup de algumas etapas e, em consulta com seu cliente, elaborar um modelo de ameaça . (Sim, é um link para um livro de 600 páginas; sim, recomendo seriamente que você leia a coisa toda.)

Um modelo de ameaça começa com perguntas como

• Por que o aplicativo precisa armazenar esses dados confidenciais em primeiro lugar?
  • Você pode evitar armazená-lo?
  • Pode ser jogado fora depois de um curto período de tempo?
  • Ele realmente precisa estar acessível a mais de um dispositivo?
  • Se ele deve estar acessível em mais de um dispositivo, ele precisa ser armazenado em mais de um dispositivo?
• Quem são as pessoas que têm permissão para ver os dados confidenciais de cada usuário?
  • Esta lista pode ser reduzida?
• Quem são as pessoas que podem entrar em contato com os dados confidenciais de cada usuário enquanto tentam fazer seu trabalho, mas não precisam saber disso?
  • Esta lista pode ser reduzida?
  • Os dados podem ficar inacessíveis para eles sem prejudicar sua capacidade de realizar seu trabalho?
  • Se não puder ser inacessível, pode pelo menos tornar-se incompreensível? (É isso que a criptografia faz, em resumo: torna os dados incompreensíveis.)
• Quem são as pessoas que desejam ver os dados confidenciais, mas não são permitidos?
  • Que oportunidades eles têm para obter os dados?
  • O que eles querem fazer com os dados depois de os terem?
  • Quão bravos eles ficarão se não conseguirem o que querem?
  • Quanto dinheiro, tempo, ciclos de CPU e esforço humano estão dispostos a gastar?
  • Eles se importam se alguém souber que viram os dados?
  • Eles querem acessar dados confidenciais de usuários específicos ou alguém o fará?
  • O que eles já sabem?
  • O que eles já têm acesso?

Depois de saber as respostas para essas perguntas, você estará em um lugar muito melhor para descobrir o que fazer.

Lembre-se de que pode haver mais de uma resposta para cada conjunto de perguntas, especialmente as que lidam com os invasores (as pessoas que desejam os dados confidenciais, mas não têm permissão para obtê-los). Se você não consegue pensar em pelo menos meia dúzia de atacantes arquetípicos diferentes , com diferentes motivações, objetivos e recursos, provavelmente perdeu alguma coisa.

Lembre-se também de que os atacantes que causam mais problemas a você (e / ou ao cliente) têm maior probabilidade de causar um impacto gigantesco na mídia se o ataque for bem-sucedido ou que causam a maior quantidade de dano agregado , provavelmente são não os atacantes que podem causar o maior dano a usuários individuais se o ataque for bem-sucedido. A empresa do seu cliente se preocupa mais com danos agregados, mas os usuários se preocupam mais com danos a si mesmos.

Uma opção para fazer a sincronização seria fazê-lo ponto a ponto. Isso ainda exigirá um servidor central, mas esse servidor não manipulará nenhum dado.

Quando um dispositivo fica on-line, um servidor central recebe uma notificação com o ID do usuário. Quando um segundo dispositivo do mesmo usuário fica on-line, o servidor envia aos dois dispositivos os endereços IP do outro. Os dispositivos podem trocar dados diretamente. Advertência: um dispositivo precisa atuar como servidor, portanto, pelo menos um não pode estar atrás de um roteador NAT.

Não esqueça que você precisará de autenticação e criptografia fortes para o mecanismo de notificação e para a troca ponto a ponto.

Faça disso o problema de outra pessoa.

Armazene os dados localmente em cada aplicativo e, em seguida, dê aos usuários a opção de ativar a sincronização usando sua própria conta com um serviço de terceiros (Dropbox, Google Drive, etc.). Além disso, pense em criptografar os dados enviados para o serviço de terceiros (há prós e contras em fazer isso).

Isso dá a aparência de que os usuários possuem seus próprios dados, pois precisam aceitar a sincronização de dados. Torna os aplicativos úteis para pessoas que não desejam que nenhum compartilhamento ocorra. E torna outra pessoa responsável (técnica e potencialmente, legalmente) pelas dores de cabeça contínuas de manter seguros os dados compartilhados.

A preocupação do seu cliente parece ser sobre a visibilidade desses dados. a primeira pergunta a fazer ao seu cliente é se os dados foram criptografados, onde podem ser armazenados? Em seguida, pergunte ao seu cliente que tipos de controles de acesso eles desejam antes que os dados possam ser descriptografados e processados ​​- onde a chave de descriptografia pode ser armazenada? é uma chave separada por usuário? etc ...

Se o seu cliente não deseja que os dados sejam armazenados em qualquer lugar, eles desejam que o usuário digite minha mão toda vez?