Enmascaramiento de datos

El enmascaramiento de datos o la ofuscación de datos es el proceso de modificar datos confidenciales de tal manera que no tengan valor o tengan poco valor para intrusos no autorizados, pero que puedan seguir siendo utilizados por software o personal autorizado. El enmascaramiento de datos también se puede denominar anonimización o tokenización , según el contexto.

La razón principal para enmascarar datos es proteger la información que se clasifica como información de identificación personal o datos críticos para la misión. Sin embargo, los datos deben seguir siendo utilizables para los fines de realizar ciclos de prueba válidos. También deben parecer reales y parecer consistentes. Es más común aplicar enmascaramiento a datos que están representados fuera de un sistema de producción corporativo. En otras palabras, donde los datos son necesarios para el desarrollo de aplicaciones , la creación de extensiones de programas y la realización de varios ciclos de prueba . Es una práctica común en la informática empresarial tomar datos de los sistemas de producción para completar el componente de datos, requerido para estos entornos que no son de producción. Sin embargo, esta práctica no siempre se limita a entornos que no son de producción. En algunas organizaciones, los datos que aparecen en las pantallas de terminales para los operadores del centro de llamadas pueden tener enmascaramiento aplicado dinámicamente en función de los permisos de seguridad del usuario (por ejemplo, evitando que los operadores del centro de llamadas vean los números de tarjetas de crédito en los sistemas de facturación).

La principal preocupación desde una perspectiva de gobernanza corporativa ^[1] es que el personal que realiza trabajos en estos entornos no productivos no siempre cuenta con la autorización de seguridad necesaria para operar con la información contenida en los datos de producción. Esta práctica representa un agujero de seguridad donde los datos pueden ser copiados por personal no autorizado y las medidas de seguridad asociadas con los controles de nivel de producción estándar pueden ser fácilmente eludidas. Esto representa un punto de acceso para una violación de la seguridad de los datos .

Los datos involucrados en cualquier enmascaramiento u ofuscación de datos deben seguir siendo significativos en varios niveles:

1. Los datos deben seguir siendo significativos para la lógica de la aplicación. Por ejemplo, si se deben ocultar elementos de direcciones y se reemplazan ciudades y suburbios por ciudades o suburbios sustitutos, entonces, si dentro de la aplicación hay una función que valida el código postal o la búsqueda de códigos postales, esa función debe poder funcionar sin errores y como se espera. Lo mismo se aplica a las verificaciones de validación de algoritmos de tarjetas de crédito y las validaciones de números de la Seguridad Social .
2. Los datos deben sufrir suficientes cambios para que no resulte obvio que los datos enmascarados proceden de una fuente de datos de producción. Por ejemplo, puede ser de conocimiento común en una organización que hay 10 altos directivos que ganan más de 300.000 dólares. Si un entorno de prueba del sistema de RR.HH. de la organización también incluye 10 identidades en el mismo tramo de ingresos, se podría combinar otra información para realizar ingeniería inversa de una identidad real. En teoría, si los datos están obviamente enmascarados u ofuscados, sería razonable que alguien que pretenda una vulneración de datos suponga que podría realizar ingeniería inversa de los datos de identidad si tuviera algún grado de conocimiento de las identidades en el conjunto de datos de producción. En consecuencia, la ofuscación o enmascaramiento de datos de un conjunto de datos se aplica de tal manera que se garantice la protección de los registros de identidad y datos sensibles, no solo de los elementos de datos individuales en campos y tablas discretos.
3. Puede ser necesario que los valores enmascarados sean consistentes en varias bases de datos dentro de una organización cuando cada una de las bases de datos contiene el elemento de datos específico que se está enmascarando. Las aplicaciones pueden acceder inicialmente a una base de datos y luego acceder a otra para recuperar información relacionada donde la clave externa ha sido enmascarada (por ejemplo, una aplicación de centro de llamadas primero obtiene datos de una base de datos maestra de clientes y, dependiendo de la situación, posteriormente accede a una de varias otras bases de datos con productos financieros muy diferentes). Esto requiere que el enmascaramiento aplicado sea repetible (el mismo valor de entrada al algoritmo de enmascaramiento siempre produce el mismo valor de salida) pero no se pueda aplicar ingeniería inversa para volver al valor original. También pueden aplicarse restricciones adicionales como las mencionadas en (1) anteriormente, dependiendo del elemento o elementos de datos involucrados. Cuando se utilizan diferentes conjuntos de caracteres en las bases de datos que necesitan conectarse en este escenario, será necesario aplicar un esquema de conversión de los valores originales a una representación común, ya sea por el propio algoritmo de enmascaramiento o antes de invocar dicho algoritmo.

La sustitución es uno de los métodos más eficaces para aplicar el enmascaramiento de datos y poder preservar la apariencia auténtica de los registros de datos.

Permite que el enmascaramiento se realice de tal manera que otro valor de apariencia auténtica pueda sustituir al valor existente. ^[2] Hay varios tipos de campos de datos en los que este enfoque proporciona un beneficio óptimo al disfrazar el subconjunto de datos general en cuanto a si es o no un conjunto de datos enmascarados. Por ejemplo, si se trabaja con datos de origen que contienen registros de clientes, se puede sustituir aleatoriamente el apellido o el nombre de pila reales a partir de un archivo de búsqueda proporcionado o personalizado. Si la primera pasada de la sustitución permite aplicar un nombre de pila masculino a todos los nombres de pila, entonces la segunda pasada debería permitir aplicar un nombre de pila femenino a todos los nombres de pila cuyo género sea igual a "F". Con este enfoque podríamos mantener fácilmente la mezcla de género dentro de la estructura de datos, aplicar anonimato a los registros de datos pero también mantener una base de datos de apariencia realista, que no podría identificarse fácilmente como una base de datos que consta de datos enmascarados.

Este método de sustitución debe aplicarse a muchos de los campos que se encuentran en las estructuras de bases de datos de todo el mundo, como números de teléfono , códigos postales y códigos postales, así como números de tarjetas de crédito y otros tipos de números de tarjetas como números de Seguro Social y números de Medicare , donde estos números en realidad deben ajustarse a una prueba de suma de comprobación del algoritmo de Luhn .

En la mayoría de los casos, los archivos de sustitución deberán ser bastante extensos, por lo que tener grandes conjuntos de datos de sustitución y la capacidad de aplicar conjuntos de sustitución de datos personalizados debería ser un elemento clave de los criterios de evaluación para cualquier solución de enmascaramiento de datos.

El método de barajado es una forma muy común de ofuscación de datos. Es similar al método de sustitución, pero deriva el conjunto de sustitución de la misma columna de datos que se está enmascarando. En términos muy simples, los datos se barajan aleatoriamente dentro de la columna. ^[3] Sin embargo, si se utiliza de forma aislada, cualquiera que tenga algún conocimiento de los datos originales puede aplicar un escenario hipotético al conjunto de datos y luego reconstruir una identidad real. El método de barajado también se puede revertir si se puede descifrar el algoritmo de barajado. ^{[ cita requerida ]}

La mezcla de datos supera las reservas sobre el uso de datos confidenciales perturbados o modificados porque conserva todas las propiedades deseables de la perturbación y al mismo tiempo funciona mejor que otras técnicas de enmascaramiento tanto en la utilidad de los datos como en el riesgo de divulgación. ^[3]

Sin embargo, la redistribución de los datos tiene algunas ventajas reales en ciertas áreas. Por ejemplo, si se trata de las cifras de fin de año de la información financiera en una base de datos de prueba, se pueden ocultar los nombres de los proveedores y luego redistribuir los valores de las cuentas en toda la base de datos enmascarada. Es muy improbable que alguien, incluso alguien con un conocimiento profundo de los datos originales, pueda obtener un registro de datos verdadero que recupere sus valores originales.

El método de variación numérica es muy útil para aplicarlo a campos de información financiera y basada en fechas. En efecto, un método que utilice esta forma de enmascaramiento puede dejar un rango significativo en un conjunto de datos financieros como, por ejemplo, las nóminas. Si la variación aplicada es de alrededor de +/- 10%, sigue siendo un conjunto de datos muy significativo en términos de los rangos de salarios que se pagan a los destinatarios.

Lo mismo se aplica a la información de fecha. Si el conjunto de datos general necesita conservar la integridad de los datos demográficos y actuariales, entonces la aplicación de una variación numérica aleatoria de +/- 120 días a los campos de fecha preservaría la distribución de fecha, pero aún así impediría la trazabilidad hasta una entidad conocida en función de su fecha real o de nacimiento conocida o un valor de fecha conocido para cualquier registro que se esté enmascarando.

El cifrado es a menudo el método más complejo para resolver el problema del enmascaramiento de datos. El algoritmo de cifrado a menudo requiere que se aplique una "clave" para ver los datos en función de los derechos de los usuarios. Esto suele parecer la mejor solución, pero en la práctica la clave puede entregarse a personal que no tenga los derechos adecuados para ver los datos. Esto anula el propósito del ejercicio de enmascaramiento. Las bases de datos antiguas pueden copiarse con las credenciales originales de la clave suministrada y el mismo problema incontrolado persiste.

Recientemente, el problema de cifrar datos preservando las propiedades de las entidades ha ganado reconocimiento y ha despertado un nuevo interés entre los proveedores y el mundo académico. Este nuevo desafío ha dado origen a algoritmos que realizan cifrados que preservan el formato . Estos se basan en el modo algorítmico del Estándar de cifrado avanzado (AES) aceptado y reconocido por el NIST. ^[4]

A veces se adopta un enfoque muy simplista para el enmascaramiento mediante la aplicación de un valor nulo a un campo en particular. El enfoque del valor nulo en realidad solo es útil para evitar la visibilidad del elemento de datos.

En casi todos los casos, esto reduce el grado de integridad de los datos que se mantiene en el conjunto de datos enmascarados. No es un valor realista y, por lo tanto, no superará ninguna validación de lógica de aplicación que se haya aplicado en el software de interfaz que se encuentra en el sistema bajo prueba. También resalta a cualquier persona que desee aplicar ingeniería inversa a cualquiera de los datos de identidad que se ha aplicado enmascaramiento de datos en algún grado en el conjunto de datos.

La codificación o enmascaramiento de caracteres en determinados campos es otro método simple pero muy eficaz para evitar que se vea información confidencial. En realidad, es una extensión del método anterior de anulación, pero se hace mayor hincapié en mantener los datos reales y no enmascarados por completo.

Esto se aplica comúnmente a los datos de tarjetas de crédito en los sistemas de producción. Por ejemplo, un operador de un centro de llamadas puede facturar un artículo a la tarjeta de crédito de un cliente. Luego, cita una referencia de facturación a la tarjeta con los últimos 4 dígitos de XXXX XXXX xxxx 6789. Como operador, solo puede ver los últimos 4 dígitos del número de la tarjeta, pero una vez que el sistema de facturación pasa los detalles del cliente para el cargo, el número completo se revela a los sistemas de pasarela de pago.

Este sistema no es muy eficaz para los sistemas de prueba, pero es muy útil para el escenario de facturación detallado anteriormente. También se lo conoce comúnmente como método de enmascaramiento dinámico de datos. ^{[5] [6]}

También se pueden incluir reglas adicionales en cualquier solución de enmascaramiento, independientemente de cómo se construyan los métodos de enmascaramiento. Los documentos técnicos independientes del producto ^[7] son ​​una buena fuente de información para explorar algunos de los requisitos complejos más comunes para las soluciones de enmascaramiento empresarial, que incluyen reglas de sincronización interna de filas, reglas de sincronización interna de tablas y reglas de sincronización de tablas ^[8] a tablas.

El enmascaramiento de datos está estrechamente vinculado con la creación de datos de prueba. Los dos tipos principales de enmascaramiento de datos son el enmascaramiento de datos estático y el enmascaramiento de datos sobre la marcha.

El enmascaramiento estático de datos se realiza normalmente en la copia maestra de la base de datos, pero también se puede aplicar a valores de otras fuentes, incluidos los archivos. En entornos de bases de datos, los administradores de bases de datos de producción normalmente cargarán copias de seguridad de tablas en un entorno independiente, reducirán el conjunto de datos a un subconjunto que contenga los datos necesarios para una ronda particular de pruebas (una técnica denominada "subconjunto"), aplicarán reglas de enmascaramiento de datos mientras los datos están en estado estático, aplicarán los cambios de código necesarios desde el control de origen y/o enviarán los datos al entorno deseado. ^[9]

El enmascaramiento determinista es el proceso de reemplazar un valor en una columna con el mismo valor, ya sea en la misma fila, la misma tabla, la misma base de datos/esquema y entre instancias/servidores/tipos de base de datos. Ejemplo: Una base de datos tiene varias tablas, cada una con una columna que tiene nombres de pila. Con el enmascaramiento determinista, el nombre de pila siempre se reemplazará con el mismo valor – “Lynne” siempre se convertirá en “Denise” – donde sea que “Lynne” esté en la base de datos. ^[10]

También existen alternativas al enmascaramiento estático de datos que se basan en perturbaciones estocásticas de los datos que preservan algunas de las propiedades estadísticas de los datos originales. Algunos ejemplos de métodos de ofuscación de datos estadísticos son la privacidad diferencial ^[11] y el método DataSifter ^[12] .

El enmascaramiento de datos sobre la marcha ^[13] se produce durante el proceso de transferencia de datos de un entorno a otro sin que los datos toquen el disco en su camino. La misma técnica se aplica al "enmascaramiento dinámico de datos", pero un registro a la vez. Este tipo de enmascaramiento de datos es más útil para entornos que realizan implementaciones continuas, así como para aplicaciones muy integradas. Las organizaciones que emplean prácticas de implementación o entrega continua no tienen el tiempo necesario para crear una copia de seguridad y cargarla en la copia maestra de la base de datos. Por lo tanto, es importante enviar continuamente subconjuntos más pequeños (deltas) de datos de prueba enmascarados desde la producción. En aplicaciones muy integradas, los desarrolladores obtienen feeds de otros sistemas de producción al comienzo mismo del desarrollo y el enmascaramiento de estos feeds se pasa por alto y no se presupuesta hasta más tarde, lo que hace que las organizaciones no cumplan con las normas. Tener implementado el enmascaramiento de datos sobre la marcha se vuelve esencial.

El enmascaramiento dinámico de datos es similar al enmascaramiento sobre la marcha, pero se diferencia en que el enmascaramiento sobre la marcha consiste en copiar datos de una fuente a otra para que esta última pueda compartirse. El enmascaramiento dinámico de datos se realiza en tiempo de ejecución, de forma dinámica y a pedido, de modo que no es necesario que haya una segunda fuente de datos donde almacenar los datos enmascarados de forma dinámica.

El enmascaramiento dinámico de datos permite varios escenarios, muchos de los cuales giran en torno a estrictas regulaciones de privacidad, por ejemplo, la Autoridad Monetaria de Singapur o las regulaciones de privacidad en Europa.

El enmascaramiento dinámico de datos se basa en atributos y está impulsado por políticas. Las políticas incluyen:

• Los médicos pueden ver los registros médicos de los pacientes que les están asignados (filtrado de datos)
• Los médicos no pueden ver el campo SSN dentro de un historial médico (enmascaramiento de datos).

El enmascaramiento dinámico de datos también se puede utilizar para cifrar o descifrar valores sobre la marcha, especialmente cuando se utiliza cifrado que preserva el formato .

En los últimos años han surgido varios estándares para implementar el filtrado y enmascaramiento dinámico de datos. Por ejemplo, las políticas XACML se pueden utilizar para enmascarar datos dentro de bases de datos.

Hay seis tecnologías posibles para aplicar el enmascaramiento dinámico de datos:

1. En la base de datos: la base de datos recibe el SQL y aplica una reescritura al conjunto de resultados enmascarados devueltos. Aplicable para desarrolladores y administradores de bases de datos, pero no para aplicaciones (porque los grupos de conexiones, el almacenamiento en caché de aplicaciones y el bus de datos ocultan la identidad del usuario de la aplicación de la base de datos y también pueden provocar la corrupción de los datos de la aplicación).
2. Proxy de red entre la aplicación y la base de datos: captura el SQL y aplica la reescritura en la solicitud de selección. Es aplicable para desarrolladores y administradores de bases de datos con solicitudes de selección simples, pero no para procedimientos almacenados (en los que el proxy solo identifica al ejecutante) ni para aplicaciones (porque los grupos de conexiones, el almacenamiento en caché de aplicaciones y el bus de datos ocultan la identidad del usuario de la aplicación a la base de datos y también pueden provocar la corrupción de los datos de la aplicación).
3. Proxy de base de datos: es una variación del proxy de red. El proxy de base de datos se implementa generalmente entre las aplicaciones/usuarios y la base de datos. Las aplicaciones y los usuarios se conectan a la base de datos a través del proxy de seguridad de base de datos. No hay cambios en la forma en que las aplicaciones y los usuarios se conectan a la base de datos. Tampoco es necesario instalar un agente en el servidor de base de datos. Las consultas SQL se reescriben, pero cuando se implementa, este tipo de enmascaramiento de datos dinámico también se admite en los procedimientos de almacenamiento y las funciones de base de datos.
4. Proxy de red entre el usuario final y la aplicación: identificación de cadenas de texto y reemplazo de las mismas. Este método no es aplicable para aplicaciones complejas, ya que puede causar fácilmente daños si se aplica el reemplazo de cadena en tiempo real de forma no intencionada.
5. Cambios de código en las aplicaciones y XACML: los cambios de código suelen ser difíciles de realizar, imposibles de mantener y no son aplicables a aplicaciones empaquetadas.
6. En el tiempo de ejecución de la aplicación: al instrumentar el tiempo de ejecución de la aplicación, se definen políticas para reescribir el conjunto de resultados devueltos desde las fuentes de datos, mientras se tiene visibilidad completa para el usuario de la aplicación. Este método es la única forma aplicable de enmascarar dinámicamente aplicaciones complejas, ya que permite controlar la solicitud de datos, el resultado de los datos y el resultado del usuario.
7. Con el apoyo de un complemento del navegador: en el caso de SaaS o aplicaciones web locales, los complementos del navegador se pueden configurar para enmascarar los campos de datos correspondientes a los selectores CSS precisos . Esto se puede lograr marcando los campos sensibles en la aplicación, por ejemplo, mediante una clase HTML , o encontrando los selectores correctos que identifiquen los campos que se van a ofuscar o enmascarar.

En los últimos años, las organizaciones desarrollan sus nuevas aplicaciones en la nube cada vez con más frecuencia, independientemente de si las aplicaciones finales se alojarán en la nube o en las instalaciones. Las soluciones en la nube a partir de ahora permiten a las organizaciones utilizar la infraestructura como servicio , la plataforma como servicio y el software como servicio . Existen varios modos de crear datos de prueba y moverlos desde bases de datos locales a la nube, o entre diferentes entornos dentro de la nube. El enmascaramiento dinámico de datos se vuelve aún más crítico en la nube cuando los clientes necesitan proteger los datos PII mientras confían en los proveedores de la nube para administrar sus bases de datos. El enmascaramiento de datos invariablemente se convierte en parte de estos procesos en el ciclo de vida del desarrollo de sistemas (SDLC), ya que los acuerdos de nivel de servicio (SLA) de los entornos de desarrollo generalmente no son tan estrictos como los SLA de los entornos de producción, independientemente de si la aplicación está alojada en la nube o en las instalaciones.

• Enmascaramiento y desenmascaramiento por parte de las agencias de inteligencia