O objetivo de mascaramento de dados é apagar aquelas características que permitam identificar dados sensíveis, tornando-os anônimos, mas ainda utilizáveis. Desta forma, elimina-se o risco de roubo de informação sensível para a organização.
A ideia é que com o mascaramento de dados Oferecemos aos desenvolvedores acesso a dados de qualidade. Eles precisam deles nos processos de produção para fins de teste, mas como vimos noutros posts, não podemos trabalhar aí com os dados reais. Desta forma garantimos que os nossos dados sensíveis estão seguros.
Mesmo que isto pareça simples, podemos deparar-nos com alguns problemas. Vejamos um tema simples e quatro problemas que podemos encontrar ao usar técnicas de mascaramento de dados.
Um tema simples: a ofuscação de dados
Os desenvolvedores adoram trabalhar com dados de produção. Pero hoy, debido a problemas de privacidad, las compañías no están muy interesadas en dar a los desarrolladores acceso completo a sus datos. Inclusive para aquellos tomados de una copia de seguridad de producción. Les preocupa mucho que los desarrolladores trabajen con listas de clientes, números de tarjetas de crédito, fechas de cumpleaños, direções, Nomes, etc. y que posteriormente puedan comercializar esos datos a la competencia.
Las compañías quieren usar técnicas de enmascaramiento de datos para ofuscar rápidamente todos los datos de producción. Quieren restaurar las bases de datos de producción en desarrollo, ejecutar algún procedimiento y dejar que los desarrolladores prueben sus aplicaciones sin ver los datos de producción reales.
No quieren ofuscar todos los campos. Como um exemplo, as transações financeiras devem conservar dados monetários semelhantes aos reais para ajudar na verificação de relatórios. Não podemos ter percentagens de impostos aleatórias como o IVA, como um exemplo, porque precisamos que se comportem de forma previsível ao olhar para uma fatura.
Mas como dizemos, esta é a parte fácil da anonimização de dados. Ofuscar os dados é algo que se pode fazer com facilidade. Mas tem implicações mais complicadas. Vejamo-las.
Problema 1: manutenção do perfil de armazenamento com dados encriptados
A forma mais simples de esconder os dados é encriptá-los. Apesar disto, a encriptação de dados tende a produzir um tamanho de dados totalmente diferente. Se pretende ver um exemplo em ação, pode visitar Esta página demonstração de encriptação. Clique aleatoriamente para gerar uma chave, escriba un texto sin formato y haga clic en Cifrar.
Como você pode ver, los datos de repente son mucho más grandes. Esto puede no ser un obstáculo para algunos tipos de datos, pero es un gran problema para campos con números enteros, fechas y tarjetas de crédito, como um exemplo. Cifrar los nombres de los clientes de repente hace que cada registo sea mucho más grande y muda la forma en que se realizan las consultas. Idealmente, los datos ofuscados deben ter o mesmo tamanho que los datos originales.
Problema 2: repartir estatísticas de forma segura
En una guía telefónica típica hay muchas personas con el apellido García. Si observa un histograma típico de datos de apellidos, algunos apellidos tendrán muchos registos y outros no muchos.
Un sistema de administración de bases de datos como SQL Server genera estatísticas que disponen histogramas que muestran la distribución de datos en cada columna y posteriormente utiliza esas estadísticas para crear planes de ejecución. Cuando probamos consultas SQL en desarrollo, queremos obtener variaciones similares.
Es fácil ofuscar datos a través de el enmascaramiento de datos, simplesmente haciéndolo de forma aleatória. Si tenemos un campo de fecha, solo usamos un generador de números aleatórios, pero no terá la mesma distribuição que os nossos dados originais.
Idealmente, los dados ofuscados devem ter uma distribuição semejante a la de los datos originales. Si tenemos personas en una tabla de 1000 registros, todos los que disponen el apellido García deben ofuscarse de la misma manera para que tengan el mismo apellido. Si mi tabla de personas tiene 500 personas llamadas García y otras 500 personas con apellidos únicos, mis datos ofuscados además deben tener 501 apellidos diferentes únicos, uno de los cuales tendrá 500 registos na tabla.
Problema 3: manter a integridade referencial a lo largo del enmascaramiento de datos
As vezes, los datos privados forman parte de la clave principal de la tabla. Dejando a un lado las ideas de design de bases de datos, la realidad es que algunas personas disponen cosas como su número de seguro social como parte de una clave primaria. O peor aún, algunas personas no colocan relaciones de clave externa en las bases de datos, por lo que terminan con dos campos de número de seguro social en dos tablas diferentes que deben unirse.
No podemos confiar en las claves externas debido a que muchas personas no usan la integridad referencial en las bases de datos.
Además pueden estar involucradas varias bases de datos. As vezes, los clientes disponen datos de clientes en una base de datos, información de ventas en otra y datos de configuración en otra, y todos deben estar vinculados.
Idealmente, la respuesta sería determinar uniones donde podría mantener los mismos dados en ambas tablas, al mismo tiempo de permitir a los utilizadores especificar campos que se unen inclusive si las claves externas no están especificadas en la base de datos. Esta configuração deve crearse una vez y guardarse, de forma que os utilizadores não tenham de a repetir cada vez que atualizam a produção.
Problema 4: velocidade das ferramentas de mascaramento de dados
Estas situações muitas vezes envolvem grandes quantidades de dados e as pessoas querem atualizar o desenvolvimento com uma cópia ofuscada da produção de um dia para o outro. Isso significa que, em geral, não é prático exportar todos os seus dados para algum tipo de servidor de aplicações e depois tentar novamente. Também não é prático atualizar a mesma tabela repetidamente, uma vez por cada coluna que deva ser ofuscada.
Os utilizadores querem atualizações de estado para saber aproximadamente quanto da base de dados foi ofuscada, cuánto queda por realizar y si falla a la mitad para poder arreglar las cosas y volver desde donde lo dejó la herramienta de escaneo. mascaramento de dados.
