👵🏽 🧑🏽‍🤝‍🧑🏽 🙀 Deserte *** *** não é apenas randomização 🗼 🤪 🧘🏼

Há um problema no banco: desenvolvedores e testadores precisam ter acesso ao banco de dados. Existem muitos dados de clientes que não podem ser usados para divulgação aos departamentos de desenvolvimento e teste, de acordo com os requisitos do PCI DSS do Banco Central e as leis de dados pessoais.

Parece que apenas mudar tudo para alguns hashes assimétricos é suficiente e tudo ficará bem.

Então, não vai.

O fato é que o banco de dados do banco é um conjunto de tabelas interconectadas. Em algum lugar, eles são conectados por nome e número da conta do cliente. Em algum lugar por seu identificador único. Em algum lugar (aqui começa a dor) através de um procedimento armazenado que calcula um identificador de passagem com base nessa e na tabela vizinha. Etc.

A situação usual é que o desenvolvedor da primeira versão do sistema já morreu ou foi embora há dez anos e os sistemas do kernel em execução no hipervisor antigo dentro do novo hipervisor (para garantir a compatibilidade) ainda estão no prod.

Ou seja, antes de anonimizar tudo isso, primeiro você precisa entender o banco de dados.

Quem faz a despersonalização e por quê?

Eles se envolvem em despersonalização ou mascaramento porque existem leis e padrões. Sim, é muito melhor testar um "instantâneo de venda", mas os reguladores podem revogar uma licença para esse voo. Ou seja, para encobrir o negócio como tal.

Qualquer despersonalização é uma camada bastante cara e desajeitada entre sistemas produtivos e testes de desenvolvimento.

O objetivo dos projetos de anonimização (mascaramento) é quase sempre preparar dados de teste o mais semelhante possível aos reais armazenados em bancos de dados produtivos. Ou seja, se os dados contiverem erros - em vez de um e-mail, o telefone está entupido, em vez do alfabeto cirílico no sobrenome ser latino etc. O segundo objetivo é reduzir o volume de bancos de dados usados em testes e desenvolvimento. O volume completo é deixado apenas para teste de carga e, para o restante das tarefas, uma determinada fatia de dados geralmente é feita de acordo com regras predefinidas - truncamento do banco de dados. O terceiro objetivo é obter dados relacionados em diferentes bancos de dados disfarçados e truncados. Isso significa que os dados em sistemas diferentes, em momentos diferentes, devem ser anonimizados de maneira uniforme.

Em termos de complexidade computacional, a despersonalização é quase o mesmo que alguns arquivos de banco de dados com extrema compressão. O algoritmo é aproximadamente semelhante. A diferença é que os algoritmos de arquivamento foram aprimorados ao longo dos anos e atingiram eficiência quase máxima. E algoritmos de despersonalização são escritos para que eles, pelo menos, trabalhem na base atual e sejam bastante universais. E o software após despersonalização geralmente funcionava. Esse é um excelente resultado - triturar 40 TB por noite. Acontece que é mais barato para o cliente levar o banco de dados à despersonalização uma vez a cada seis meses durante uma semana em um servidor fraco - também uma abordagem.

Como os dados são substituídos?

Cada tipo de dados é alterado de acordo com as regras que podem ser usadas no código. Por exemplo, se substituirmos o nome por um hash aleatório por caracteres e números especiais, a primeira validação de dados produzirá imediatamente um erro no teste real.

Portanto, primeiro o sistema de despersonalização deve determinar que tipo de dados são armazenados no campo. Dependendo do fornecedor, diferentes abordagens são usadas, da marcação manual às tentativas de descobrir o banco de dados e detectar automaticamente o que está armazenado lá. Temos a prática de apresentar todas as principais soluções do mercado. Analisaremos uma das opções quando houver um assistente que tente encontrar dados e "adivinhar" que tipo de dados é armazenado lá.

Naturalmente, para trabalhar com este software, você precisa acessar dados reais (geralmente, esta é uma cópia de um backup recente do banco de dados). De acordo com a experiência bancária, primeiro assinamos uma tonelada de papéis por dois meses e, depois, chegamos ao banco, nos despimos, revistamos e nos vestimos, depois vamos para uma sala separada, enjaulada com uma gaiola de Faraday, na qual existem dois guardas de segurança e respiramos calorosamente atrás de nossas cabeças.

Então, suponha que, depois de tudo isso, vemos uma tabela na qual existe um campo "Nome". O assistente já o marcou como um nome e só podemos confirmar e escolher o tipo de despersonalização. O Assistente oferece uma substituição aleatória para nomes eslavos (existem bases para diferentes regiões). Nós concordamos e obtemos substituições como Ivan Ivanov Petrenko - Joseph Albertovich Chingachguk. Se isso é importante, o gênero é preservado; caso contrário, as substituições passam pelo banco de dados de nomes.

Exemplos de substituições:

. ->
->
->
->
-> -

O próximo campo é a data no Unixtime. O Assistente determinou isso também, mas precisamos escolher a função de despersonalização. Normalmente, as datas são usadas para controlar a sequência de eventos e a situação em que um cliente fez uma transferência pela primeira vez em um banco e depois abriu uma conta, ninguém realmente precisa testar. Portanto, definimos um pequeno delta - por padrão, dentro de 30 dias. Ainda haverá erros, mas se isso for crítico, você poderá configurar regras mais complexas adicionando seu script ao processamento de anonimização.

O endereço deve ser validado, para que o banco de dados de endereços russos seja usado. O número do cartão deve corresponder aos números reais e ser validado por eles. Às vezes, a tarefa é "tornar todos os vistos aleatórios Mastercards" - isso também é possível em alguns cliques.
Sob o capô do assistente está o perfil. A criação de perfil é uma pesquisa de dados em um banco de dados de acordo com regras predefinidas (atributos, domínios). De fato, lemos cada célula do banco de dados do cliente, aplicamos um conjunto de expressões regulares a cada célula, comparamos os valores nessa célula com dicionários etc. Como resultado, temos um conjunto de regras acionadas nas colunas das tabelas do banco de dados. Podemos configurar a criação de perfil, não podemos ler todas as tabelas no banco de dados, podemos obter apenas um certo número de linhas da tabela ou uma certa porcentagem de linhas.

O que está acontecendo lá dentro?

Para cada entrada no banco de dados, as regras de despersonalização que escolhemos se aplicam. Nesse caso, tabelas temporárias são criadas para a duração do processo, onde as substituições são gravadas. Cada registro subsequente no banco de dados é executado de acordo com essas tabelas de correspondência de substituição e, se houver uma correspondência lá, ele será substituído da mesma maneira que antes. Na verdade, tudo é um pouco mais complicado, dependendo dos scripts e das regras de correspondência de padrões (pode haver uma substituição imprecisa, por exemplo, do parto ou da substituição de datas armazenadas em um formato diferente), mas a idéia geral é essa.

Se houver correspondências marcadas “o nome é cirílico - o nome é latino”, elas deverão ser claramente indicadas no estágio de desenvolvimento e, em seguida, na tabela de substituição, elas corresponderão uma à outra. Ou seja, o nome será anonimizado em cirílico e, em seguida, essa entrada anonimizada será convertida para o alfabeto latino, por exemplo. Neste ponto, estamos nos afastando da abordagem “não melhore a qualidade dos dados no sistema”, mas esse é um dos compromissos que você precisa fazer para obter algum tipo de desempenho do sistema. A prática mostra que, se o teste funcional e estressante não perceber um comprometimento em seu trabalho, não haverá nada. E aqui chega o ponto importante de que a despersonalização como um todo não é criptografia. Se você tem alguns metros de entradas na tabela e em dez deles o TIN não mudou, então o que? Nada, esses dez registros não podem ser encontrados.

Após o término do processo, as tabelas de conversão permanecem no banco de dados protegido do servidor de despersonalização. A base é cortada (truncada) e passada para testes sem tabelas de conversão, portanto, para o testador, a despersonalização se torna irreversível.

O banco de dados anônimo completo é passado aos testadores para teste de estresse.

Isso significa que, ao trabalhar com o banco de dados, a tabela de conversão aumenta (a quantidade exata depende da escolha das substituições e do tipo), mas a base de trabalho permanece com o tamanho original.

Como é o processo na interface do operador?

Visualização geral do IDE usando um dos fornecedores como exemplo:

Depurador:

Iniciando uma transformação a partir do IDE:

Configurando uma expressão para procurar dados confidenciais no criador de perfil:

Página com um conjunto de regras para o criador de perfil:

O resultado do criador de perfil, página da web com pesquisa de dados:

Todos os dados no banco de dados estão mascarados?

Não. Normalmente, a lista de dados para despersonalização é regulada por leis e padrões da esfera, além do cliente ter sugestões para campos específicos que ninguém deve conhecer.

A lógica é que, se mascaramos o nome do paciente no hospital, você pode mascarar ou não o diagnóstico - ainda assim ninguém saberá de quem ele é. Tivemos um caso em que as notas de uma transação em um banco eram simplesmente mascaradas em letras aleatórias. Havia notas do nível: "O empréstimo foi recusado, porque o cliente ficou bêbado e vomitou no bar". Do ponto de vista da depuração, é apenas uma sequência de caracteres. Bem, deixe-a ficar.

Estratégias de exemplo:

Uma tabela de semente dinâmica é uma tabela de transcodificação na qual adicionamos a recodificação que já aconteceu. O hash pode ser muito diferente e, no caso do mesmo TIN, mais frequentemente um novo TIN aleatório é gerado com os primeiros caracteres armazenados, com dígitos de verificação.

É possível alterar dados usando o próprio DBMS?

Sim. Ao despersonalizar dados, existem duas abordagens principais - alterar os dados no banco de dados usando o próprio banco de dados ou organizar um processo ETL e alterar dados usando software de terceiros.

A principal vantagem da primeira abordagem é que você não precisa retirar os dados do banco de dados em nenhum lugar, não há custos de rede e são utilizadas ferramentas de banco de dados rápidas e otimizadas. A chave menos é um desenvolvimento separado para cada sistema, a falta de tabelas de conversão comuns para diferentes sistemas. As tabelas de conversão são necessárias para a reprodutibilidade da despersonalização e maior integração de dados entre os sistemas.

A principal vantagem da segunda abordagem - não importa qual banco de dados, sistema, arquivo ou interface da web você tenha - depois de implementar uma regra, você poderá usá-la em qualquer lugar. A chave negativa é que você precisa ler dados do banco de dados, processá-los com um aplicativo separado e gravá-los no banco de dados.

A prática mostra que, se o cliente tiver um conjunto de vários sistemas que exijam maior integração, somente a segunda abordagem poderá ser implementada para o custo final em dinheiro, bem como para tempos de desenvolvimento aceitáveis.

Ou seja, podemos fazer o que quisermos, mas a abordagem ETL se provou muito bem no setor bancário.

E por que os dados simplesmente não estragam manualmente?

Isso pode ser feito uma vez. Alguém ficará sentado por três dias, despersonalizar um monte de dados e preparar um banco de dados de 500 a 1000 registros. A dificuldade é que o processo deve ser repetido regularmente (com cada alteração na estrutura do banco de dados e na aparência de novos campos e tabelas) e em grandes volumes (para diferentes tipos de teste). Uma solicitação comum é despersonalizar os primeiros 10-50 GB do banco de dados para que esse valor caia uniformemente em cada tabela.

O que fazer se as digitalizações de documentos estiverem armazenadas no banco de dados?

Se um documento puder ser reduzido para XML e convertido novamente (por exemplo, documentos de escritório), você também poderá despersonalizá-los. Às vezes, porém, existem binários como digitalizações de passaporte em PDF / JPG / TIFF / BMP. Nesse caso, a prática geralmente aceita é fornecer documentos semelhantes com um script de terceiros e substituir os reais por amostras da base dos gerados aleatoriamente. O mais difícil é com as fotografias, mas existem serviços como esse que resolvem o problema aproximadamente da mesma maneira.

Quem é responsável pelo que?

Ao atualizar após alterar o software ou "atualizar", os processos são mais simples.

Mas e se algo der errado nos testes?

Isso geralmente acontece. Primeiro, os testadores, após a primeira execução de despersonalização, formulam com mais precisão os requisitos para o banco de dados. Podemos mudar as regras de despersonalização ou rejeitar registros como "aqui as ações devem ser executadas em ordem cronológica, e não caóticas". Em segundo lugar, dependendo da implementação, apoiamos a despersonalização à medida que o banco de dados muda ou deixamos toda a documentação, descrições da estrutura e tipos de processamento do banco de dados, transferimos todo o código de processamento (regras em xml / sql) e treinamos especialistas do cliente.

Como assistir a uma demonstração?

A maneira mais fácil é me enviar um e-mail para PSemenov@technoserv.com.

Deserte * * não é apenas randomização