4 problemas y 1 tema sencillo del data masking

El objetivo del data masking es eliminar aquellas características que permiten identificar datos sensibles logrando que se conviertan en anónimos pero que sigan pudiéndose utilizar. De esta forma se elimina el riesgo de robo de información sensible para la organización.

La idea es que con el data masking proporcionamos a los desarrolladores acceso a datos de calidad. Los necesitan en los procesos de producción con propósitos de testeo, pero como hemos visto en otros artículos, no podemos trabajar allí con los datos reales. De esta forma nos aseguramos que nuestros datos sensibles están a salvo.

Aunque esto parece sencillo nos podemos encontrar con algunos problemas. Veamos un tema sencillo y cuatro problemas que podemos encontrarnos cuando utilizamos técnicas de data masking.

Un tema sencillo: la ofuscación de datos

A los desarrolladores les encanta trabajar con datos de producción. Pero hoy en día, por temas relacionados con privacidad, las empresas no están demasiado interesadas en dar a los desarrolladores un acceso completo a sus datos. Incluso para aquellos sacados 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, direcciones, nombres, etc. y que luego puedan vender esos datos a la competencia.

Las empresas quieren utilizar técnicas de data masking para ofuscar rápidamente todos los datos de producción. Quieren restaurar las bases de datos de producción en desarrollo, ejecutar algún proceso, y dejar que los desarrolladores prueben sus aplicaciones sin ver los datos reales de producción.

No quieren ofuscar todos los campos. Por ejemplo, las transacciones financieras deberían preservar datos monetarios similares a los reales para hacer fácil la comprobación de informes. No podemos tener porcentajes de impuestos como el IVA aleatorios, por ejemplo, porque necesitamos que se comporten de una manera predecible cuando miramos una factura.

Pero como decimos, esta es la parte sencilla del data masking. Ofuscar los datos es algo que se puede hacer con facilidad. Pero tiene implicaciones más complicados. Vamos a verlas.

Problema 1: Mantenimiento del perfil de almacenamiento con datos codificados

La manera más fácil de ofuscar datos es encriptarlos. Sin embargo, encriptar datos tiende a producir un tamaño totalmente diferente de datos. Si quieres ver un ejemplo en acción, puedes visitar esta página de demostración de encriptación. Haz clic en random para generar una clave, escribe algo de texto plano y haz clic en Encrypt.

Como ves, de repente los datos son muchos más grandes. Esto puede no ser un problema para algunos tipos de datos, pero es un gran problema para campos con enteros, fechas y tarjetas de crédito, por ejemplo. La encriptación de los nombres de clientes hace que de repente, cada registro sea mucho más grande, y que cambie la forma en que se realizan las consultas. De forma ideal, los datos ofuscados necesitan ser del mismo tamaño que el de los datos originales.

Problema 2:  Distribución de estadísticas con seguridad

En una típica guía telefónica hay mucha gente con el apellido García. Si nos fijamos en un histograma típico de los datos de apellidos, algunos apellidos van a tener un montón de registros y otros no tendrán muchos.

Un sistema de gestión de base de datos como SQL Server genera estadísticas que tienen histogramas que muestran la distribución de datos en cada columna y a continuación utiliza esas estadísticas para crear planes de ejecución. Cuando  probamos consultas de SQL en desarrollo, queremos obtener variaciones similares.

Es fácil ofuscar datos mediante data masking, simplemente haciéndolo al azar. Si tenemos un campo de fecha solo usamos un generador de números aleatorios, pero eso no tendrá la misma distribución que nuestros datos originales.

Idealmente, los datos ofuscados necesitan tener una distribución similar que los datos originales. Si tenemos gente en una tabla de 1000 registros, todos los que tienen el apellido García deberían ser ofuscados de la misma forma 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 necesitan tener 501 únicos apellidos diferentes también, uno de los cuales tendrá 500 registros en la tabla.

Problema 3: mantener la integridad referencial mientras hacemos data masking

Algunas veces los datos privados forman parte de la clave principal de la tabla. Si dejamos de lado las ideas de diseño de la base de datos, la realidad es que algunas personas tienen cosas como el número de la seguridad social como parte de una clave primaria. O aún peor, algunas personas no ponen relaciones de clave ajena en las bases de datos, por lo que terminan con dos campos de número de seguridad social en dos tablas diferentes que necesitan unirse.

No podemos confiar en las claves ajenas porque muchas personas no utilizan la integridad referencial en las bases de datos.

También pueden estar involucradas varias base de datos. A veces los clientes tienen datos de cliente en una base de datos, información sobre ventas en otra y datos de configuración en otra, y todas ellas necesitan vincularse.

Idealmente la solución sería determinar uniones dónde pudieras mantener los datos iguales en ambas tablas, además de permitir que los usuarios especifiquen campos que son unidos incluso si las claves ajenas no están especificadas en la base de datos. Esta configuración debería ser construida una vez y guardada, para que los usuarios no tengan que repetirla cada vez que actualizan producción.

Problema 4: velocidad de las herramientas de data masking

Estas situaciones a menudo implican grandes cantidades de datos, y la gente quiere refrescar el desarrollo con una copia ofuscada de producción durante la noche. Esto significa que por lo general no es práctico exportar todos los datos algún tipo de servidor de aplicaciones y a continuación probar de nuevo. Tampoco es práctico actualizar la misma tabla de forma repetida, una vez por cada columna que necesita ser ofuscada.

Los usuarios quieren actualizaciones de estado para saber aproximadamente cuánto de la base de datos se ha ofuscado, saber cuánto queda por hacer y saber si  falla a mitad de proceso para poder arreglar las cosas y volver desde donde se quedó la herramienta de data masking.