Digamos que tenhamos um sistema de produção com vários bancos de dados criptografados usando TDE e um certificado autogerado.
Precisamos regularmente pegar esse banco de dados e atualizar nossos sistemas de não produção. Esse processo envolve fazer backup do banco de dados de origem, restaurá-lo para pré-produção, ofuscar dados pessoais e vários outros itens.
O fato chave aqui é que o sistema de pré-produção tem uma cópia do certificado de criptografia da produção
Estou procurando maneiras de tornar esse processo mais seguro - não estou satisfeito com o certificado no ambiente de pré-produção. Existe outra maneira que irá:
- Nunca tenha um backup não criptografado salvo em qualquer lugar
- Não permitir a propagação de dados pessoais da produção para sistemas de não produção?
Em um mundo perfeito, se você estiver armazenando dados de identificação pessoal em produção, nunca restaurará o banco de dados para um ambiente de desenvolvimento.
Você não pode confiar apenas na ofuscação. Por exemplo, mais cedo ou mais tarde, alguém fará uma cópia de backup de uma tabela em produção. Eles vão selecionar a tabela dbo.Customers em uma nova tabela por segurança antes de fazer uma alteração nela, e vão esquecer de soltá-la. Seu código de ofuscação não estará esperando novas tabelas aleatórias com dados de identificação pessoal e, portanto, após o processo de ofuscação, os dados ainda estarão lá.
Em vez disso, quando precisar de dados de desenvolvimento, gere-os do zero.
(Lembre-se: você pediu a melhor prática, não um compromisso. Se sua resposta for “mas queremos dados de produção em desenvolvimento”, então você já está perdendo a melhor prática.)
Como Brent aponta: dados reais (se mesmo a menor parte deles for sensível) não devem estar em sistemas dev/test [1] , mesmo que temporariamente.
Se você despersonalizar dados reais para uso em ambientes de teste, existem algumas precauções que tomamos ao fazer isso:
Novamente: dados reais não devem estar em sistemas de desenvolvimento/teste, mesmo que temporariamente . Restaure a cópia e despersonalize em ambientes de produção desconectados com as medidas de segurança completas que isso implica, então mova os dados munged para seus outros ambientes. Você pode não querer essa carga extra em sua configuração de produção principal [2] nesse caso tenha um servidor de banco de dados separado nesse ambiente apenas para esta tarefa [3] .
Certifique-se de que seu processo falhe com segurança e falhe com força, mesmo que isso signifique que ele falhe com frequência . Faça-o cair se quaisquer novas tabelas ou colunas estiverem presentes, até que você forneça uma nova lista do que esperar, para mitigar o problema que Brent discute com alterações temporárias de esquema. Certifique-se também de que qualquer etapa com falha interrompa todo o processo para que qualquer erro que altere os dados bloqueie a saída da produção.
A melhor prática [4] é gerar dados de teste com base em padrões vistos na produção, em vez de pegar a produção e tentar torná-la não identificável sem alterar nenhum padrão nos dados. Além de eliminar o risco de uso acidental de dados reais devido a um erro de processo, você pode incluir em seus dados de teste casos de borda que não ocorreram na produção (ainda que você conheça).
Mesmo que sua despersonalização funcione, você pode descobrir que qualquer pessoa com um pouco de determinação pode desfazê-la parcialmente se souber um pouco sobre a organização de seus clientes.
Esta é a sua bandeira vermelha. Acene para qualquer pessoa acima de você que questione a despesa extra e/ou o incômodo de manter os dados de produção longe de ambientes de não produção. Cópias desnecessárias de chaves podem aumentar muito sua área de superfície de ataque.
[1] Alguns podem sugerir uma exceção com serviços UAT, mas eu consideraria essa produção de qualquer maneira.
[2] A menos que você veicule um conjunto bastante específico de fusos horários, por exemplo, todos os seus clientes e a grande maioria de seus usuários estão nos EUA, portanto, tenha uma grande janela durante a noite durante a qual um impacto no desempenho não importa
[3] Não precisa necessariamente ser um kit caro de "grau de produção" (drives de alto desempenho, SQL e SO licenciados para empresas, ...), apenas o suficiente para que esse processo seja rápido o suficiente, pois você não verá atividade do usuário final, mas é claro que ainda haverá um custo envolvido
[4] Para o qual mudamos para todos os desenvolvimentos recentes e futuros - usamos apenas o processamento de dados de produção como esse em certos serviços legados que estão se aposentando em breve e não vale a pena reequipar antes que estejam totalmente obsoletos.