Qual é uma boa prática de segurança para armazenar um banco de dados crítico nos laptops dos desenvolvedores?

Temos alguns dados:

1. Os desenvolvedores precisam de uma réplica do banco de dados de produção em suas máquinas.
2. Os desenvolvedores têm a senha do referido banco de dados nos arquivos App.config.
3. Não queremos que os dados no referido banco de dados sejam comprometidos.

Algumas soluções sugeridas e suas desvantagens:

1. Criptografia de disco completo. Isso resolve todos os problemas, mas diminui o desempenho do laptop, e somos uma start-up, portanto, não temos dinheiro para cavalos de força.
2. Criando uma VM com disco rígido criptografado e armazene o banco de dados nela. Funciona bem, mas não ajuda muito, pois há uma senha no Web.Config.
3. Solução número 2 + que exige que o desenvolvedor digite a senha do banco de dados toda vez que executa alguma coisa. Ele resolve todos os problemas, mas é realmente complicado para os desenvolvedores que às vezes iniciam o aplicativo várias vezes por minuto. Além disso, temos vários aplicativos que se conectam ao mesmo banco de dados, e a implementação de uma tela de senha precisará diferir em cada um.

Portanto, minha pergunta é: se existe alguma solução comum para esse problema ou alguma sugestão sobre como tornar viável alguma das soluções acima?

Não apenas você não deseja uma cópia do banco de dados de produção, como também pode ser ilegal. Por exemplo, nos EUA, você não pode mover dados de produção para fora do ambiente de produção se eles contiverem informações regulamentadas, como dados pessoais de saúde, dados financeiros ou mesmo dados que possam ser usados ​​em roubo de identidade. Se o fizer, poderá ser multado, perder a conformidade e, portanto, estar sujeito a auditorias mais agressivas ou até mesmo ser nomeado em uma ação judicial.

Se você precisar de dados em escala de produção para teste, terá algumas opções:

1. Gere todos os dados fictícios. Isso é mais complicado do que parece. É surpreendentemente difícil e trabalhoso gerar dados imaginários sensíveis.
2. Anonimize seus dados de produção. Isso pode ser mais fácil, mas continue com cuidado.

Para a opção 2

• No ambiente de produção, um administrador de banco de dados autorizado faz uma cópia dos dados de produção.
• Ainda no ambiente de produção, o mesmo administrador autorizado executa uma rotina que anonimamente todos os dados confidenciais. Em caso de dúvida, anonimize.
• Somente então os dados devem ser movidos para outro ambiente.

Você pode, pelo menos, fornecer aos VMs dos desenvolvedores em seu datacenter os quais eles podem obter RD para este trabalho? Embora eles realmente devam trabalhar com dados que não são de produção, isso seria mais seguro até você chegar lá, pois os dados não seriam armazenados em laptops roubados com facilidade.

Mude sua maneira de trabalhar, se possível.

Como outros já apontaram:

• Usar dados de produção para desenvolvimento não é uma boa prática.
• Ter uma senha armazenada em texto sem formatação não é uma boa prática.

Ambos os expõem a riscos significativos e devem ser alterados, se possível. Você deve pelo menos avaliar seriamente qual seria o custo de fazer essas alterações. Se essa é uma dependência externa que você não tem poder de mudar, considere elevar isso como uma preocupação para quem tem esse poder.

No mundo real, porém, pode não ser realmente possível mudar isso. Supondo que o que você está fazendo é legal, você pode ter que conviver com esse acordo (pelo menos temporariamente).

Se isso for realmente necessário, você só precisará fazer a criptografia de disco completo.

Dados os riscos, você precisa usar a melhor opção de segurança disponível, e é isso. Se houver um impacto no desempenho, viva com ele. É um custo de trabalhar com dados confidenciais.

Se eu fosse seu cliente, não ficaria impressionado com o fato de você ter decidido não usar a melhor opção de segurança disponível com meus dados, porque isso tornava seus laptops um pouco mais lentos.

A resposta de Corbin March é muito boa, acrescentarei apenas um detalhe adicional: geralmente você tem duas classes de dados no banco de dados de produção: metadados de sistema / aplicativo; e dados do usuário do cliente / dados transacionais. Este último nunca deve ser usado em um ambiente de desenvolvimento "como está".

É muito raro, de fato, que você precise de informações reais do cliente de produção para fazer o desenvolvimento.

No entanto, se o problema que o OP está descrevendo aqui envolve dados de segredos comerciais ou dados de sistema altamente proprietários que não envolvem dados de clientes, isso é exigido pelos desenvolvedores ... a abordagem de segurança deve envolver um esquema que não possui a senha db mantida em texto não criptografado em um arquivo de recurso em algum lugar. É necessário haver um mecanismo para, por exemplo, gerar novamente uma senha diária, que não esteja armazenada no disco.

Você não indica qual banco de dados e qual ambiente.

Se você puder usar a segurança integrada, o banco de dados não poderá ser acessado sem estar conectado como usuário. Sim, se os dados estiverem no disco rígido, eles podem ser invadidos, mas essa é uma defesa de primeiro nível.

App.config faz pensar que isso pode ser um .NET. Coloque o config em um pen drive e leia-o no pen drive. Se a unidade não estiver presente, faça o usuário digitar a senha.

Existe uma maneira de armazenar a senha na memória na primeira vez em que é digitada e lida por todos. Novamente, você não indica o ambiente. Arquivos mapeados na memória

Com alguns TDE, você pode armazenar a chave em um dispositivo separado, para que eles apenas forneçam a chave quando o servidor do banco de dados for iniciado.

Uma opção possível é fazer uma cópia do banco de dados e limpá-la com um script, para que você tenha dados diferentes dos que estão realmente em produção. Você não terá os mesmos dados que a produção, mas terá a mesma escala.