En un mundo dominado por datos y con amenazas acechando por todas partes, mantener la seguridad de los datos es casi imposible. Sin embargo, este desafío se agrava al copiar los datos para pruebas, desarrollo, capacitación, etc. Si proteger los datos en producción es difícil, proteger estas copias fuera del entorno de producción seguro es imposible. Entonces, ¿qué podemos hacer?

La solución es eliminar la parte sensible de los datos de todas las copias que realizamos. Esto se denomina enmascaramiento estático de datos. Sin embargo, existen muchos términos y técnicas que se combinan. Desde la anonimización hasta la ofuscación, entre otras, las definiciones no siempre son coherentes y a menudo se solapan. Sin embargo, el objetivo es el mismo: permitirnos usar datos sensibles fuera de producción sin riesgos de seguridad.

Aquí es donde surge el desafío: garantizar que los datos sigan siendo valiosos después del enmascaramiento. Los datos enmascarados deben permitir un desarrollo, pruebas, capacitación, etc. de alta calidad. Si los datos enmascarados no conservan sus cualidades únicas, los equipos que los utilizan exigirán acceso a los datos sensibles originales para poder realizar su trabajo.

Este artículo lo guía a través de varios ejemplos comunes para explicar cómo se puede desensibilizar cada tipo de datos y qué puede esperar en términos de calidad de datos y riesgo de seguridad.

Nombres

Nombres, apellidos, nombres de empresas y más son las solicitudes más comunes al enmascarar datos, y existen múltiples estrategias que puedes emplear.

Original Data	Masked Data
John	James
Paul	Mark
George	Luke
Ringo	Peter

La más popular es la generación de datos. Se trata de crear nombres aleatorios a partir de un diccionario de nombres. Se puede usar un diccionario proporcionado por la solución de enmascaramiento o uno personalizado. El motor de generación de datos puede usar una lista de patrones ponderados para que los datos parezcan más realistas. Por ejemplo, algunos nombres deben ser una sola palabra en minúscula (p. ej., John). Otros deben estar en mayúscula (p. ej., James) y otros en mayúsculas (p. ej., JAKE). Algunas entradas deben contener dos o tres nombres (p. ej., Smith-Jones) o letras (p. ej., J.J.), etc. Al crear una combinación ponderada de patrones como esta, los datos generados se verán más realistas.

La ventaja de la generación de datos es que estos están completamente disociados de los datos originales. No pueden revelar ninguna información sobre estos. Sin embargo, esta también es su debilidad: no conserva ninguna característica de los datos originales. Si los datos se utilizan, por ejemplo, para probar algo relacionado con nombres, la prueba no simulará los resultados originales. Por ejemplo, puede que falten nombres en caracteres chinos. También puede que falten nombres muy largos o muy cortos. Puede sonar más occidental que latino o asiático. Al analizar los datos sintéticos, descubrirá más diferencias con los datos reales.

Original Data	Masked Data
John	Dhox
Paul	Pxje
George	Ehksor
Ringo	Najre

Otro enfoque es el reemplazo de caracteres. Este método conserva algunos aspectos de los datos, como los conjuntos de caracteres y la longitud, pero el resultado será ininteligible y completamente incomprensible. Si bien puede ser útil en ciertos tipos de pruebas, no será legible y, por lo general, no será de su agrado.

Desde una perspectiva de seguridad, el reemplazo de caracteres puede divulgar información sobre los valores originales. Por ejemplo, el conjunto de caracteres y la longitud de la palabra. Tenga en cuenta que estas son las características exactas que buscamos preservar para mejorar ciertos tipos de pruebas.

Original Data	Masked Data
John	Paul
Paul	Ringo
George	John
Ringo	George

Otras estrategias, como la aleatorización de filas, pueden funcionar bien con nombres o apellidos. Revelan los nombres existentes en la base de datos, pero no las filas a las que están asociados. También se puede preservar el género asociado al nombre mediante la aleatorización de una combinación de nombre y género (más información sobre las combinaciones más adelante).

Existen estrategias más complejas que pueden ser beneficiosas para casos de uso específicos, por lo que todo depende de los datos disponibles y las propiedades que se deben preservar.

Género

Original Data	Masked Data
Male	Male
Female	Female
Male	Female
Female	Male
Male	Male

La forma más sencilla de enmascarar el género es aleatorizando la columna. Este tipo de enmascaramiento utiliza los valores actuales de la columna, pero los asocia a filas diferentes. Esto gestionará automáticamente el caso en que la columna de género contenga más de dos valores distintos (más que Masculino y Femenino). También funcionará independientemente del idioma utilizado en la columna o de si esta contiene una representación numérica (por ejemplo, 1 para masculino y 2 para femenino).

Añadir ponderaciones a la aleatorización garantizará que la proporción de población entre los diferentes géneros se mantenga constante. Variaciones más complejas pueden conservar la proporción de población por género dentro de cada estado, ciudad, etc. La pregunta siempre gira en torno a cómo se utilizan los datos y qué cualidades se deben preservar.

Fechas (ej. cumpleaños)

Original Data	Masked Data
1971-06-14	1971-09-26
2013-02-23	2012-07-16
2007-10-19	2007-03-07
1983-08-03	1984-01-30

Las fechas y horas suelen enmascararse con infusión de ruido. Añadir ruido a las fechas significa cambiar el valor dentro de un rango determinado. Por ejemplo, adelantar o retrasar la fecha no más de un año. Esto garantiza que se desconozca la fecha de nacimiento real, pero que la fecha siga teniendo sentido. Por ejemplo, evita situaciones como la de una persona de 70 años que se convierte en un recién nacido, la de padres más jóvenes que sus hijos, la de caducidad de los artículos antes de su producción o emisión, etc.

Las fechas que quizás necesites ocultar incluyen cumpleaños, fechas de emisión y vencimiento de un pasaporte o documento de identidad, fechas de transacciones y más.

Original Data	Masked Data
06/14/1971	09/26/1971
2013-FEB-23	2012-JUL-16
20071019	20070307
August 3, 1983	January 1, 1984

Un aspecto importante del enmascaramiento de fechas es cómo se almacenan en la base de datos. Todas las bases de datos contienen un tipo de fecha especial, y enmascararlo es más sencillo. Sin embargo, muchas bases de datos almacenan las fechas en formato de texto. En ese caso, el proceso de enmascaramiento debe comprender la fecha, enmascararla y volver a almacenarla en el mismo formato de texto. Las fechas almacenadas como texto pueden formatearse de diversas maneras (p. ej., 31/12/2025, 31/12/2025, 31/12/2025, 31/12/2025, etc.), y el proceso de enmascaramiento debe ser lo suficientemente flexible como para adaptarse a los formatos utilizados en la base de datos.

Emails

El enfoque más común para enmascarar correos electrónicos es la generación de datos, creando nuevos correos electrónicos ficticios. Sin embargo, si es importante conservar los nombres de dominio o algún formato especial, el reemplazo de caracteres es una buena opción. Por ejemplo, podría reemplazar todos los caracteres alfanuméricos antes de la @.

Tenga cuidado con las columnas de correo electrónico que contienen varios correos electrónicos (por ejemplo, separados por comas, espacios o punto y coma). El reemplazo de caracteres puede ser una buena opción para enmascarar correos electrónicos cuando se desconoce el formato y se desea conservarlo.

Tenga en cuenta que para conservar los nombres de dominio, debe enmascarar hasta la última @ y no la primera (para conservar el TLD, hasta el último punto). El enmascaramiento hasta la última ocurrencia tiene como objetivo gestionar los campos que contienen varios correos electrónicos.

Números de Teléfono

Los números de teléfono son un tipo de dato que sigue patrones. El análisis de patrones es un método eficaz para enmascarar teléfonos, preservar los patrones y ocultar eficazmente toda la información.

Sin embargo, si desea conservar partes del número de teléfono, como el código de país y el código de área, la sustitución de caracteres es probablemente la mejor opción. Enmascarar los últimos 7 dígitos es una opción popular.

No obstante, tenga en cuenta que si un número de teléfono contiene una extensión, los últimos 7 dígitos pueden incluir parte de ella.

Además, tenga en cuenta que si la columna contiene varios números de teléfono, el enmascaramiento parcial de campos probablemente revelará parte de la información. Una buena alternativa es enmascarar todo excepto los primeros dígitos. Otra opción es aplicar diferentes políticas de enmascaramiento según la longitud del campo.

Esto nos lleva a otra situación común: cuando el dígito 0 indica que no hay teléfono. Existen números de teléfono «falsos» similares que sugieren que la persona no tiene teléfono o no desea revelarlo. El enmascaramiento de dichos datos debe incluir una condición para evitar enmascarar esas entradas especiales.

Direcciones

Las direcciones suelen incluir números y nombres en varios formatos. El método más común de enmascaramiento consiste en generar datos con una lista de patrones ponderados que emula los principales formatos de dirección.

Si estas direcciones son una parte importante de la prueba, también puede considerar la sustitución de caracteres alfanuméricos. Esto conservará el patrón y la longitud, pero generará direcciones con un aspecto ininteligible.

Ciudad, Estado, Código Postal y País

Enmascarar cada columna de forma independiente es sencillo, y el enfoque habitual consiste en aleatorizar los valores entre las filas.

Sin embargo, a menudo es deseable conservar la relación entre estas columnas. Esto significa garantizar que el estado exista dentro del país, la ciudad dentro del estado y que el código postal coincida con el resto. El enmascaramiento compuesto es la solución, ya que puede operar simultáneamente con múltiples valores. La opción más común es una aleatorización compuesta que intercambia todo el conjunto de valores entre las filas.

Añadir ponderaciones también conservará las propiedades estadísticas, garantizando que el mismo número de personas permanezca en cada ciudad, estado, código postal y país.

Otra opción es garantizar que las personas permanezcan dentro del mismo país o estado. Una restricción invariante puede ayudar a lograrlo, lo que, por ejemplo, garantizará que el prefijo telefónico del país coincida con el país.

Los compuestos con ponderaciones e invariantes son un método eficaz que ayuda a mantener la privacidad individual a la vez que se obtienen datos altamente realistas. Datos realistas que conservan las propiedades estadísticas y garantizan que los valores de las columnas coincidan con el resto de la información.

Identificación Nacional

El reemplazo de caracteres es una buena solución general para enmascarar identificaciones nacionales. En ocasiones, los primeros caracteres indican atributos como el tipo de identificación o la edad de una persona. En tales casos, puede ser conveniente conservar esos primeros caracteres.

En ocasiones, será necesario aplicar una función personalizada para calcular una suma de comprobación para la identificación. Si la suma de comprobación se basa en el algoritmo de Luhn, esta opción se puede habilitar en la política de enmascaramiento. De lo contrario, una base de datos o una función de Python pueden realizar los ajustes necesarios.

Sin embargo, hay dos aspectos importantes a considerar al enmascarar estas identificaciones:

Primero, las identificaciones deben ser únicas. Enmascarar caracteres aleatoriamente probablemente generará duplicados incluso con conjuntos de datos relativamente pequeños. La paradoja del cumpleaños es un buen ejemplo de cómo una pequeña cantidad de valores aleatorios puede crear una colisión. Para dar una mejor idea, un ID de 9 dígitos tiene un 99 % de probabilidad de generar un duplicado con 96 000 filas, y un ID de 10 dígitos probablemente tendrá duplicados con 310 000 filas.

La solución correcta al problema de unicidad es usar un diccionario de enmascaramiento. Este diccionario registra todos los valores y garantiza que los nuevos valores sean únicos.

El segundo desafío al enmascarar los ID nacionales es que suelen aparecer en múltiples ubicaciones en la base de datos y, a menudo, también en otras bases de datos. Para garantizar la coherencia, el mismo ID debe enmascararse de la misma manera en todas partes.

La solución es, nuevamente, un diccionario de enmascaramiento que registra los valores y puede ofrecer un enmascaramiento coherente en una o más bases de datos.

Salarios

Los salarios se diferencian del resto de la información que analizamos porque son cantidades numéricas. Las cantidades numéricas son cantidades en dólares, inventario o cualquier número que represente una cantidad de algo.

Las cantidades numéricas se pueden enmascarar de dos maneras principales: generación de números o infusión de ruido.

La generación de números crea valores aleatorios dentro de un rango específico utilizando la distribución elegida. Es muy seguro, ya que los datos enmascarados no están relacionados con los originales. Sin embargo, tampoco tienen relación con los datos originales. Por ejemplo, el rango salarial, el salario promedio y todos los demás atributos estadísticos no se conservarán.

La infusión de ruido es un método para modificar el valor original sumando o restando números aleatorios. Añadir ruido puede enmascarar el valor original, pero conserva el orden de magnitud. Por lo general, mantendrá aproximadamente propiedades estadísticas como el rango, el promedio, etc.

Si bien la infusión de ruido es una excelente manera de enmascarar salarios en un rango similar, crea un posible problema de seguridad cuando algunos salarios de ejecutivos son significativamente más altos y resaltan después del enmascaramiento. La solución es el enmascaramiento condicional, que aplica diferentes políticas de enmascaramiento a distintos rangos salariales.

Tenga en cuenta que también puede haber valores como cero para indicar becarios, contratistas y otras personas sin salario. Estos valores normalmente también deben gestionarse mediante enmascaramiento condicional.

Datos Financieros

Algunas bases de datos contienen datos financieros importantes que son difíciles de enmascarar. Por ejemplo, transacciones bancarias, cargos a tarjetas de crédito, etc. Si bien es fácil enmascarar cada valor, enmascarar muchas columnas que contienen dichos valores y que guardan una relación entre sí puede ser un desafío. Por ejemplo, enmascarar las transacciones con tarjetas de crédito también debería recalcular el saldo adeudado, el pago mínimo, etc.

Una solución más sencilla para preservar la privacidad es enmascarar la identidad de la persona en lugar de los detalles de sus datos financieros. Si bien puede no ser apropiado o estar permitido en todos los casos, es una solución común que simplifica el enmascaramiento.

Sin embargo, enmascarar solo la información personal identificable requiere un trabajo diligente para garantizar que ningún elemento de los datos pueda comprometer la identidad de una persona. También requerirá enmascarar el número de cuenta, lo cual, como se mencionó anteriormente en el análisis sobre la identificación nacional, requiere un manejo de la unicidad y la consistencia.

Además del requisito básico de un número de cuenta único y un enmascaramiento consistente en todas las tablas (y potencialmente en todas las bases de datos), es probable que los números de cuenta también tengan una restricción de relación de clave principal/clave externa. Estos problemas generalmente se solucionan con una solución de enmascaramiento, pero tenlos en cuenta para estar atento a los problemas.

Tarjetas de Crédito

Las tarjetas de crédito suelen enmascararse mediante el reemplazo de caracteres o el perfilado de patrones.

El reemplazo de caracteres es muy eficaz y permite enmascarar una parte del número de tarjeta, dejando intactos los primeros dígitos. Esto puede ser valioso, ya que los primeros dígitos suelen indicar el tipo de tarjeta e información similar.

El perfilado de patrones es un método más avanzado en el que la solución aprende los patrones utilizados para almacenar tarjetas y los imita. Se trata de una potente estrategia de enmascaramiento similar a la generación de datos, pero basada en la información original.

La única otra complejidad relacionada con las tarjetas de crédito es que el último dígito es una suma de comprobación. Esta suma de comprobación utiliza el algoritmo de Luhn, pero puede habilitar fácilmente esta opción en la política de enmascaramiento.

LOBs, BLOBs, etc.

Las bases de datos tienen tipos de columnas que pueden almacenar información no estructurada y diversos archivos. Por ejemplo, pueden almacenar documentos, imágenes, JSON, etc. Los distintos proveedores de bases de datos nombran estas columnas de forma diferente, pero a veces se conocen como LOB (Objeto Grande) o BLOB (Objeto Binario Grande), Imagen o Binario.

Estas columnas almacenan ciertos tipos de información confidencial. Por ejemplo:

• Imágenes
• Escaneos de documentos, como documentos firmados
• Datos biométricos
• Historiales médicos y resultados de pruebas
• Información genética

Enmascarar este tipo de información es crucial, pero no trivial. Hay varias razones para ello:

• El formato del contenido de un LOB o BLOB es desconocido para el software de enmascaramiento y puede requerir software especializado para abrirlo y modificarlo.
• La información debe guardarse en el formato correcto para que el software de la aplicación la lea y procese correctamente.
• Leer y escribir en estas columnas requiere código especializado. No es algo que se pueda hacer normalmente con herramientas SQL convencionales como Management Studio o SQL*Plus.

La solución para enmascarar este tipo de columnas es proporcionar una lista de documentos de reemplazo falsos. La solución de enmascaramiento usará estos documentos ficticios aleatoriamente y los cargará en lugar de los valores LOB existentes.

Más tipos de datos

Existen otros tipos de información confidencial que no abordaremos en este artículo. Por ejemplo, matrículas, datos GPS, información IP, etc. En definitiva, muchas organizaciones tienen datos únicos o requisitos especiales, pero estos se gestionan con los mismos algoritmos y principios que explicamos.

Siempre existe la posibilidad de que sus datos sean lo suficientemente únicos como para que queden fuera del alcance de los algoritmos de la solución. Este es otro caso en el que un proveedor y un socio sólido le garantizarán el éxito.

Consistencia e Integridad Referencial

En algunos casos, es necesario enmascarar datos en diferentes tablas o bases de datos de la misma manera. Un ejemplo sencillo es el ID de cuenta o el ID nacional mencionados anteriormente. Desde el punto de vista técnico, se pueden considerar claves primarias y externas.

Existen dos enfoques para gestionar esta situación en las soluciones de enmascaramiento de datos: el enmascaramiento determinista y los diccionarios de enmascaramiento. Si bien la terminología puede cambiar, los algoritmos y sus limitaciones permanecen.

El enmascaramiento determinista utiliza el valor (más precisamente, un hash del valor) para garantizar que cada valor experimente la misma transformación «aleatoria». Este algoritmo presenta fallas debido a un problema estadístico conocido como la paradoja del cumpleaños. Es un tema complejo en la teoría de la probabilidad, pero esencialmente significa que incluso números bastante grandes pueden presentar una colisión de valores (véase la explicación sobre el ID nacional). Una colisión significa que dos campos diferentes intentan enmascararse en el mismo valor y, por lo tanto, rompen la integridad referencial.

Los diccionarios de enmascaramiento son una solución adecuada para los problemas de consistencia. Este es el método utilizado en Core Masking y garantiza tanto la unicidad como la integridad referencial en múltiples tablas e incluso en distintas bases de datos de distintos proveedores.

Terminología

En los últimos años, el mundo del enmascaramiento de datos se ha visto inundado de diversos términos. Cada proveedor ha inventado su propia terminología y definición para diferenciarse de los demás. Como resultado, no todos interpretan estos términos de la misma manera. Por eso es mejor centrarse en algoritmos y métodos específicos en lugar de conceptos abstractos e imprecisos.

Sin embargo, para facilitar el debate, hemos creado un pequeño glosario con interpretaciones razonables:

• El enmascaramiento de datos se utiliza a menudo como el término principal para este tipo de soluciones. Como tal, se refiere a cualquier manipulación de datos que busque ocultar los valores originales. Sin embargo, este término también se refiere a la técnica de modificar parte del valor conservando una porción.
• La ofuscación a menudo significa precisamente eso: que los datos originales serán difíciles, si no imposibles, de recuperar. Sin embargo, a veces se refiere a técnicas específicas como la generación de datos (creación de nuevos datos no relacionados con los originales).
• La redacción es una técnica de enmascaramiento (igual que la técnica de enmascaramiento). Es el proceso de eliminar una parte del valor. No debe confundirse con la reducción, que consiste en reducir el tamaño del conjunto de datos (creando una base de datos más pequeña para realizar pruebas).
• La anonimización es el concepto de garantizar que los datos no puedan rastrearse hasta la persona a la que se refieren. Fuera de las bases de datos, se realiza eliminando las columnas que contienen información de identificación personal (PII). Sin embargo, en las bases de datos, es necesario conservar todas las columnas para garantizar el funcionamiento de la aplicación. Por lo tanto, la anonimización se realiza reemplazando la información personal con datos falsos en un proceso irreversible. En otras palabras, la anonimización generalmente implica la generación de datos PII.
• La seudonimización es similar a la anonimización, solo que el proceso de enmascaramiento debe ser reversible. Fuera de la base de datos, las columnas de PII se reemplazan con una sola columna que contiene un seudónimo. El seudónimo puede convertirse manualmente de nuevo a PII mediante una tabla de traducción. Dentro de la base de datos, la seudonimización reemplaza cada pieza de PII con un seudónimo (o token). Este seudónimo puede revertirse mediante la tabla de traducción. La seudonimización produce datos de baja calidad para las pruebas, ya que los seudónimos no ofrecen ningún valor de prueba. Por lo tanto, es poco común en el enmascaramiento de datos para pruebas y desarrollo.
• La tokenización es similar a la seudonimización, solo que va más allá de la PII y reemplaza cualquier dato sensible con tokens. Los tokens pueden resolverse posteriormente si es necesario. Al igual que la seudonimización, no es una buena solución en bases de datos, ya que los tokens no ofrecen ningún valor de prueba. El cifrado es una variante de la tokenización, donde, en lugar de tokens, los datos se reemplazan con su forma cifrada. Para recuperar los datos originales, se necesita acceder a la clave de descifrado. Además, es una solución deficiente para el enmascaramiento de bases de datos.

Como se mencionó anteriormente, cada persona y empresa puede usar y comprender estos términos de diferentes maneras. Nuestro mejor consejo es centrarse en funcionalidades específicas, algoritmos y el tipo de datos que generan. Es mucho mejor centrarse en evaluar la seguridad y la calidad de los datos para pruebas, desarrollo, etc.

Estático vs. Dinámico

Este artículo se refiere al enmascaramiento de datos estático, no dinámico. Sin embargo, es importante comprender las diferencias. Esta breve introducción al enmascaramiento dinámico explica las diferencias entre el enmascaramiento dinámico y el estático.

El enmascaramiento dinámico modifica los datos sobre la marcha. Esto significa que los datos almacenados en la base de datos son los datos confidenciales originales y se modifican sobre la marcha al realizar una consulta. El cambio generalmente se realiza modificando la consulta en lugar de los campos de datos del resultado.

Cambiar los datos dinámicamente durante la ejecución de la consulta tiene varias consecuencias directas:

• Los datos confidenciales siguen almacenados en la base de datos. Esto significa que aún debe proteger el servidor de la base de datos, supervisar el acceso del administrador, etc.
• Modificar datos es un desafío. Si el usuario o la aplicación consulta información enmascarada y luego se basa en ella para realizar un cambio, este se referirá a datos enmascarados que no existen en la base de datos.
• Los datos deben ser consistentes. Por ejemplo, al consultar el nombre de la persona número 123, los datos originales deben enmascararse sobre la marcha y siempre devolver el mismo nombre enmascarado.

Por estas razones, el enmascaramiento dinámico es:

• Solo para bases de datos de producción. No está diseñado para proteger entornos de prueba o desarrollo.
• Solo se aplica a un subconjunto de las conexiones y un subconjunto de los datos. Se aplica a los datos que deben ocultarse para esas conexiones específicas y que no se actualizan.
• Los algoritmos de enmascaramiento de datos suelen ser triviales, como eliminar parte o toda la información del campo. No pueden producir datos aleatorios ni generar información falsa, ya que estos datos serán diferentes cada vez que se consulten.
• Las conexiones enmascaradas suelen ser identificadas por el usuario y el programa que se conectaron a la base de datos, no por el usuario final de la aplicación.

El enmascaramiento dinámico es más complejo y costoso que el estático, y su uso es muy limitado. La mayoría de los enmascaramientos son estáticos.

Otros Desafíos

Este artículo se centra en cómo enmascarar datos. Esta es la principal preocupación para cualquiera que trabaje con enmascaramiento de datos: proporcionar datos de buena calidad. El objetivo es que quienes utilizan los datos enmascarados estén satisfechos con ellos y con los resultados que obtienen. Si los datos son de baja calidad, los usuarios suelen rechazarlos y exigir acceso a los datos sin enmascarar.

Sin embargo, al comenzar con el enmascaramiento de datos, las organizaciones suelen subestimar la calidad de los datos enmascarados y se preocupan por otros desafíos iniciales, como:

• Definición de requisitos. Uno de los desafíos iniciales son los requisitos. Muchos proyectos comienzan con objetivos poco claros y los buscan sin rumbo. En ocasiones, esta búsqueda deriva en los equipos de cumplimiento y legal, quienes suelen ser considerados responsables de estas definiciones. Sin embargo, la orientación que estos equipos finalmente brindan suele ser, en el mejor de los casos, parcial. Este es el tema de un artículo mucho más extenso, y en resumen, los requisitos adecuados suelen provenir de una combinación de equipos técnicos y de seguridad. Estos equipos están familiarizados con los datos de la base de datos y comprenden sus implicaciones de seguridad.
• Localización de datos sensibles. Como extensión de la definición de requisitos, surge el reto de localizar las tablas y columnas con los datos que queremos enmascarar. Esto puede ser especialmente complejo en aplicaciones grandes donde los equipos no están familiarizados con el modelo de datos de la base de datos. Si bien existen algunas características del producto y metodologías prácticas que pueden facilitar esta tarea, también requiere mucho tiempo. De nuevo, este tema será objeto de otro artículo extenso.
• Rendimiento. Uno de los desafíos prácticos que pueden enfrentar los clientes es que las tareas de enmascaramiento tardan demasiado en completarse. Este desafío está relacionado con la solución, su implementación y la base de datos. Por ejemplo, los disparadores de la base de datos son un problema común en los proyectos de enmascaramiento. Lea más en nuestro artículo sobre el rendimiento del enmascaramiento de datos.

Aunque sean transitorios, no superar estos desafíos probablemente resultará en un proyecto fallido. Esta es una razón más para elegir proveedores y socios comprometidos que le ayuden a superar los obstáculos que encuentre.

Desafíos Avanzados

Algunos profesionales de seguridad plantean una pregunta clave: «¿Cómo puedo saber si los datos enmascarados están correctamente enmascarados y son seguros de usar?».

Un método común para validar el enmascaramiento consiste en seleccionar algunas filas al azar y comparar los datos antes y después del enmascaramiento. Sin embargo, esta prueba superficial no significa que todo el conjunto de datos estuviera correctamente enmascarado. A continuación, se muestran algunos ejemplos de cómo unas políticas de enmascaramiento razonables pueden dar lugar a datos mal enmascarados.

Una política de enmascaramiento que deja intactos los primeros dígitos de un número de teléfono puede dejar un número corto prácticamente sin enmascarar. Por otro lado, una política de enmascaramiento que solo enmascara los últimos dígitos puede proporcionar un enmascaramiento insuficiente cuando el teléfono va seguido de una extensión o cuando el campo contiene dos o más números.

Una política de enmascaramiento que preserva el estado en el que reside una persona puede preservar involuntariamente la ciudad. Esto puede ocurrir si todos los residentes del estado viven en la misma ciudad (por ejemplo, una ciudad importante del estado) o si hay pocas entradas en el estado que provengan de la misma ciudad. Sin mencionar que una sola persona en el estado será fácilmente identificada.

Como último ejemplo, añadir un porcentaje de ruido a un salario o a una cantidad en dólares añadirá muy poco ruido a números pequeños y preservará el valor cuando la cantidad sea cero.

En definitiva, el problema radica en que el enmascaramiento implica aleatoriedad que interactúa con los datos. Por lo tanto, ciertos datos inesperados producirán resultados que no se consideraron. Igualmente desafiante es que la aleatoriedad introducida puede dejar los datos con cambios pequeños o nulos (lo cual es normal).

La única manera de garantizar que todos los datos estén bien enmascarados es aplicar la política de enmascaramiento a todos los datos varias veces. Al analizar estas numerosas ejecuciones de enmascaramiento, el cambio promedio debe ser suficiente para todos los valores. Esa es la tarea de una función de evaluación de enmascaramiento en una solución de enmascaramiento de datos.

Reflexiones Finales

Quizás una de las principales conclusiones de este artículo es que no existe una forma correcta de enmascarar datos. El enmascaramiento es un equilibrio entre las necesidades de datos y los requisitos de seguridad. Un componente vital de este equilibrio son los requisitos de calidad de los datos, que cambian entre proyectos y evolucionan con el tiempo.

En otras palabras, un proyecto de enmascaramiento consiste en encontrar la forma correcta de enmascarar sus datos para que se ajusten a las necesidades actuales de su cliente. Las soluciones que ofrecen múltiples opciones de enmascaramiento para cada tipo de datos le ofrecen la flexibilidad de encontrar el equilibrio entre la seguridad y la calidad de los datos.

Si bien este artículo no se centra en desafíos ajenos a la calidad y seguridad de los datos, es fundamental recordar que los proyectos de enmascaramiento fracasan independientemente de su capacidad para producir datos enmascarados de calidad. Por ejemplo, los desencadenadores en las tablas son una causa común de un rendimiento de enmascaramiento insoportable y, consecuentemente, del fracaso del proyecto.

Por esa y muchas otras razones, contar con socios y proveedores experimentados y comprometidos es la clave entre el éxito y el fracaso del proyecto.

Por encima de todo, recuerde siempre enmascarar sus datos. Mantener datos confidenciales fuera del entorno de producción seguro es irresponsable y, sin duda, conducirá a consecuencias catastróficas.