Rendimiento del enmascaramiento de datos

Rendimiento del Enmascaramiento de Datos

Aprende más sobre el rendimiento del enmascaramiento de datos, un aspecto crítico de las soluciones actuales.

El enmascaramiento de datos no es una tarea cotidiana, así que ¿por qué es vital tener en cuenta el rendimiento?

Mientras que es de poca importancia si un proceso de enmascaramiento de datos tarda 5 segundos o 5 minutos, es crítico si tarda cinco días o no termina nunca. Los tiempos de ejecución imposiblemente largos no son inusuales y hacen que el producto sea inútil. Muchos proyectos de enmascaramiento fracasan por este motivo.

Aspectos del Rendimiento


Entonces, ¿qué hace que una solución de enmascaramiento de datos funcione rápida o lentamente? Hay tres factores que influyen significativamente en el rendimiento del enmascaramiento:

  • Ajuste de la base de datos
  • Implementación de la solución de enmascaramiento de datos
  • “Triggers”, o disparadores de la base de datos

Implementación

Cuando se ejecuta una solución de enmascaramiento de datos, se actualizan millones de valores de datos en la base de datos. Hay dos aspectos críticos relacionados con la implementación de la solución que pueden hacer que un trabajo se ejecute muy rápido o dolorosamente lento:

  • Tiempo de ejecución de SQL
  • Los viajes de ida y vuelta por la red

Los viajes de ida y vuelta por la red son el aspecto más crítico de la aplicación. El trabajo de enmascaramiento será insoportablemente lento si cada actualización de cada uno de los millones de valores se ejecuta por separado. Cada ejecución es un viaje de ida y vuelta, y un buen viaje de ida y vuelta para aplicaciones LAN es de unos 2-5ms. Eso significa que si se envían actualizaciones durante 24 horas en un bucle, se podría obtener una media de entre 17 y 43 millones de actualizaciones al día. No es tanto como podría parecer si se multiplica el número de filas de la base de datos por el número de columnas que requieren enmascaramiento.

Sin embargo, si el producto de enmascaramiento de datos utiliza la vinculación de matrices (con sentencias preparadas), puede enviar miles de actualizaciones en un solo viaje de ida y vuelta. Al eliminar la mayoría de los viajes de ida y vuelta, el tiempo de ejecución se reducirá de un día a menos de un minuto. Tenga en cuenta que una vez que el round-trip se vuelve insignificante, otros aspectos se convierten en el cuello de botella, por lo que el tiempo de ejecución no suele ser tan corto.

El tiempo de ejecución de SQL también depende de la implementación de la solución de enmascaramiento de datos. Cada base de datos tiene capacidades diferentes, y las implementaciones deben optimizarse para cada base de datos. Además de las sentencias preparadas y la vinculación de matrices mencionadas anteriormente, algunas bases de datos ofrecen un direccionamiento de filas más rápido que los índices. Oracle, por ejemplo, tiene ROWIDs que permiten el acceso directo a las filas. SQL Server tiene SQLBulkOperations. Del mismo modo, cada base de datos requiere una implementación única para maximizar la velocidad.

Triggers

Los “triggers” son fragmentos de código en la base de datos que se ejecutan cada vez que se modifican los datos. Tienen muchas finalidades, como validar datos, ajustar valores, sincronizar datos entre tablas y columnas, etc. La mayoría de las tablas de bases de datos no tienen triggers, pero cuando existen, se consideran parte integrante de la base de datos, vitales para su correcto funcionamiento.

Aunque el tiempo de ejecución de un único trigger suele ser corto, estos intervalos se acumulan cuando se actualizan millones de valores. Dado que el enmascaramiento de datos realiza millones de actualizaciones, los triggers de las tablas que requieren enmascaramiento suelen provocar que el tiempo de ejecución sea imposiblemente largo.

No es sencillo resolver el problema de los triggers, ya que su desactivación puede causar muchos problemas. Resolver el problema de los triggers, por tanto, requiere un mecanismo alternativo para replicar la funcionalidad de los triggers sin triggers. ¿Cómo podemos hacerlo?

Los triggers funcionan fila a fila. Esto tiene sentido para el código que se ejecuta cada vez que cambia un único valor. Sin embargo, las bases de datos pueden realizar actualizaciones verticales y cambiar todas las filas de la tabla con un único SQL. Convertir los triggers en un procedimiento con actualizaciones verticales le permitirá desactivar temporalmente los disparadores durante el enmascaramiento y mantener la funcionalidad del trigger ejecutando ese procedimiento.

Recodificar los triggers como actualizaciones verticales es un proceso manual. Sin embargo, el principal reto suele ser identificar todos aquellos que se disparan y el código que ejecutan. Core Audit, nuestra solución de auditoría de bases de datos, le muestra cualquier SQL que se ejecute en la base de datos, incluidos los SQL que se ejecutan dentro de los triggers. Es la solución perfecta para identificarlos, y a menudo la utilizamos durante las instalaciones de enmascaramiento con este fin.

Sintonización

El último aspecto del rendimiento del enmascaramiento es el ajuste de la base de datos. Con soluciones bien implementadas como Core Masking, no suele ser necesario. Sin embargo, es posible mejorar aún más.

La mayoría de las bases de datos hacen un uso intensivo de la lectura y se ajustan en función del rendimiento de lectura. La consulta de datos es, con diferencia, la actividad más habitual en las bases de datos. Sin embargo, el enmascaramiento de datos es una operación de escritura intensiva y se beneficiará de un ajuste diseñado para mejorar la velocidad de escritura.

Los administradores de bases de datos están bien equipados para ajustar una base de datos para que escriba más rápido, pero aquí hay un par de sugerencias que pueden ayudar:

  • Eliminación de índices en columnas enmascaradas. El objetivo de los índices es mejorar las consultas, pero cada cambio en una columna indexada requiere una actualización del índice. Eliminar los índices antes de enmascarar y volver a crearlos después es mucho más rápido.
  • Rehacer registros y archivar registros. Sólo enmascaramos las bases de datos que no son de producción, por lo que nunca es necesario recuperarlas en caso de fallo. Los registros de repetición y los registros de archivo son funciones de la base de datos que trabajan duro durante la actividad de escritura para garantizar que una base de datos pueda recuperarse. Deshabilitar o limitar esta funcionalidad de la base de datos durante el enmascaramiento mejorará significativamente el rendimiento de escritura.

Las bases de datos tienen muchos otros parámetros ajustables que pueden ayudar a mejorar el rendimiento, pero, como se mencionó anteriormente, rara vez es necesario ajustar la base de datos para el enmascaramiento.

El cambio de la base de datos a y desde una configuración de escritura intensiva puede automatizarse con acciones previas y posteriores al enmascaramiento. Éstas pueden eliminar índices o cambiar la configuración de la base de datos, volviendo a la configuración de lectura intensiva una vez finalizado el proceso de enmascaramiento.

Consejos

Entonces, ¿cómo deben abordar los clientes un proyecto de enmascaramiento?

Si ya dispone de una solución, intente identificar los cuellos de botella de rendimiento y solucionarlos. También puede considerar servicios profesionales como los que ofrecen nuestros socios. Otra posibilidad es adquirir una solución diferente, como Core Masking.

Si aún no ha adquirido una solución, tenga en cuenta las sugerencias siguientes. Sin embargo, el aspecto más importante a la hora de adquirir una solución de enmascaramiento de datos es asegurarse de contar con un proveedor y un socio que respalden sus soluciones y garanticen que todo funciona. Ninguna evaluación puede sustituir las capacidades que los proveedores pueden esgrimir para resolver problemas si se preocupan lo suficiente por usted como cliente.

Evaluación teórica

Es bueno evaluar la base teórica de una solución de enmascaramiento. Por ejemplo, los algoritmos de coherencia, las metodologías admitidas, los pros y los contras para la seguridad y la usabilidad de los datos, etc. La evaluación teórica y la comparación entre soluciones pueden revelar debilidades tecnológicas difíciles de identificar mediante pruebas. Estos puntos débiles rara vez se resuelven mediante actualizaciones o parches y es probable que permanezcan durante el resto de la vida útil del producto.

Evaluación práctica

Muchas evaluaciones de enmascaramiento dan rodeos. Intentan asegurarse de que algo funciona, pero no son inflexibles a la hora de analizar todos los casos de uso de principio a fin.

Por falta de tiempo, los clientes tienden a posponer la cuestión del desencadenante a la implementación posterior a la compra. Esto tiene cierta lógica, ya que los disparadores no son un problema en el software de enmascaramiento. Sin embargo, su capacidad para resolverlo es un requisito para utilizar el software. Así que, tanto si puede resolverlo usted mismo como si necesita que el proveedor o el socio le ayuden, es valioso realizar el ejercicio durante la evaluación.

A veces, las evaluaciones ni siquiera enmascaran las tablas por completo. Es simplemente una cuestión de tiempo, porque puede llevar demasiado tiempo. Pero así es como el rendimiento acaba siendo un problema sólo después de la compra. Además, las evaluaciones suelen probar los datos enmascarados comparando unas pocas filas. Sin embargo, nunca validan que todas las filas de la tabla estaban enmascaradas. Aunque no es un ejercicio trivial, tampoco es tan difícil.

En resumen, las evaluaciones prácticas son vitales, y los clientes deben ser inflexibles a la hora de repasar sus casos de uso de principio a fin. Hay que asegurarse de que el enmascaramiento termina en un tiempo aceptable y de que todos los datos están bien enmascarados.

Identifica tus necesidades

Toda selección de productos debe empezar por identificar las necesidades actuales y futuras. Esto es especialmente importante en el enmascaramiento de datos, ya que las posibilidades de los datos que se quieren enmascarar y las posibles aplicaciones de los datos enmascarados son infinitas. Cada producto tiene diferentes puntos fuertes, pero sus puntos débiles serán debilitantes para determinados casos de uso.

Sin embargo, los requisitos son algo que la mayoría de los clientes no tienen. Eso hace que la compra sea un juego de adivinanzas mientras se siguen las recomendaciones del proveedor. Le recomendamos que identifique algunos casos de uso difíciles y pida a los proveedores que los cumplan de principio a fin. Los proveedores pueden distinguirse por su capacidad para superar estos retos y no ofrecer soluciones uniformes.

Incluye a las partes interesadas

Muchas evaluaciones de enmascaramiento son realizadas por administradores de bases de datos. Es lógico, ya que el enmascaramiento es un producto de base de datos. Sin embargo, puede ser útil incluir a representantes de otros dos equipos. Una persona del equipo de seguridad para garantizar un enmascaramiento adecuado. Y lo que es más importante, al menos una persona de los usuarios destinatarios de los datos enmascarados. En otras palabras, representantes de los equipos de control de calidad o desarrollo previstos que puedan validar que los datos enmascarados les son útiles.

La razón de estas inclusiones es que si los clientes de los datos no han validado su utilidad, es probable que los rechacen y sigan utilizando datos sin enmascarar.

Incluir a varias partes interesadas de distintos equipos puede complicar el proceso de evaluación. Así que hay que intentar identificar a las personas adecuadas que puedan trabajar juntas, cooperar y hacer las cosas con rapidez.

Conclusión

El enmascaramiento de datos es, en muchos sentidos, un proceso sencillo, y la mayoría de los clientes lo consideran una compra sencilla. Aunque es sencillo, no es trivial, y saltarse algunos detalles puede suponer malgastar dinero en un software inútil.

Muchos proveedores de enmascaramiento de datos ven el enmascaramiento de datos de la misma manera que los clientes: un producto sencillo y menor sin barreras tecnológicas significativas. De nuevo, esto no es del todo falso, pero esta actitud da lugar a soluciones que sólo funcionan en algunos casos de uso y son inutilizables en otros. Esto ocurre tanto en los grandes vendedores como en los pequeños. Los grandes proveedores descuidan los productos más pequeños de la cartera, y los pequeños reducen costes recurriendo a desarrolladores baratos en países del Tercer Mundo.

Nuestro consejo es que pruebe a fondo la solución que pretende comprar y se asegure de que trabaja con un socio y un proveedor que resolverá sus problemas posteriores a la compra y hará que todo funcione.

Muchos proyectos de enmascaramiento fracasan. Trabaje con nosotros y le garantizaremos el éxito.

Webinar

Si deseás inscribirte a nuestro seminario sobre enmascaramiento de datos, por favor completá el siguiente formulario: