Para muchas empresas conocer dónde se ubica la información de interés dentro de sus sistemas de datos es una tarea ardua.
Además, es un problema que, en la mayoría de los casos, se agrava por la falta de documentación.
Es muy probable que esto te haya sucedido alguna vez.
Sin embargo, esta barrera inicial no es la única con la que te encontrarás.
En este artículo hablaremos del rol de la información, sus implicaciones y cómo se aplica en el día a día.
¿Quieres saber más?
¡Sigue leyendo!
Una vez especificados los números de identificación fiscal en nuestra base de datos, ¿seríamos capaces de reconocer si pertenecen a un cliente, a un trabajador o a un proveedor en todas las situaciones?
Generalmente la respuesta es negativa, es más, posiblemente habría casos donde pertenecieran a las tres figuras.
Es aquí donde entra en juego el rol de la información.
En la segmentación no solo es importante qué relaciones se establecen entre los datos, sino también, cómo se establecen dichas relaciones.
Ahora bien, pensemos en una relación entre dos tablas a través del NIF, ¿qué ocurriría si en la primera tabla tenemos el NIF del tomador de la póliza y, en la segunda, el NIF de la persona contraria con la que se abre un siniestro de automóvil?
Seguramente estemos trayendo en la estructura del cliente datos que no pertenecen estricta y únicamente a él.
Ahora, imagina un proyecto de segmentación.
Uno de los primeros pasos es identificar los distintos tipos de información a localizar.
Con esta definición se ejecuta el Mapa de Datos.
En este punto, el camino lógico es tratar de identificar las relaciones con los distintos mecanismos y generar así las estructuras de segmentación.
El Mapa de Datos, en ese proceso, podrá aportar información fundamental para el descubrimiento, ya que es información del mismo tipo y, generalmente, está relacionada de algún modo o facilita explorar dichas relaciones.
En cambio, tal y como se ha mostrado con el ejemplo inicial, no puede ser el único punto de información.
Es decir, no es posible establecer una estructura a través de todas las claves de NIF encontradas.
Tampoco podría hacérsela través de todas las cuentas bancarias que afloren en el Mapa de Datos sensibles.
¿Todavía te surgen dudas sobre las implicaciones de la configuración?
Seguir guiándote únicamente por el tipo de información sin tener en cuenta el rol que este juega no puede ser una opción.
Es normal, de hecho, que en determinados escenarios las implicaciones sean muy bajas, incluso insignificantes con respecto al coste que puede conllevar tratar de descubrirlo, pero no te dejes llevar por ello.
A continuación, averigua las principales implicaciones que supones no explorar el rol de la información.
¡Por cierto!
La mayoría de ellas están relacionadas con el ámbito de la información, es decir, con el dominio de datos.
Al perder el dominio del dato si no se atiende al rol de la información, la estructura puede acabar afectando a registros de estructuras externas. Y esto afectará sin duda, a la información de esa estructura secundaria.
Esto podría invalidar la prueba con dicha estructura, borrar datos que se podrían necesitar en el futuro, etc.
Al salir del dominio natural de la información que se desea transferir se puede acabar moviendo un exceso de información.
En consecuencia, los tiempos pueden dispararse y la capacidad del entorno verse afectada.
Generalmente, al no recabar los datos sobre el rol de la información, resulta más complejo ejecutar pruebas atomizadas o pruebas unitarias.
Esto se debe a que se necesita mover toda una estructura que en algún punto acabará por desplazar el dominio del dato que se desea.
El punto principal es la incertidumbre.
No conocer con exactitud qué se está moviendo y qué se ha de mover puede conllevar dudas constantes sobre el proceso. O incluso realizar revisiones periódicas innecesarias y, además, incrementar la dificultad del mantenimiento de dichas estructuras.
¿Todavía no estás completamente convencido?
Continúa leyendo y descubre otra de las grandes implicaciones.
Otro proceso de gran importancia en el que se ven implicadas las estructuras de datos de segmentación es en la gestión de GDPR en entornos productivos, esto es, en el cumplimiento del derecho al olvido, a la portabilidad o al acceso.
En un entorno de pruebas con segmentación acabar fuera del ámbito del dato que se está moviendo tiene implicaciones limitadas.
Por lo general, no pone en riesgo la producción.
¡Excepto en un caso!
Salvo que se esté leyendo de dicho entorno y se acceda a un camino con el que se ejecutan y extraen un alto número de consultas y recursos. En cambio, cuando hablamos de procesos que afectan directamente a la producción, llegando a actualizar y borrar numerosos registros de dichos entornos, es fundamental ser minucioso en la cantidad de consultas que se efectúan y, sobre todo, en el número de registros que se modifican.
En producción no hay margen para afectar a un ámbito externo cuando se trata de este tipo de procesos, pues compromete información de otros clientes, empleados, etc. Esto sucederá en el mejor de los casos y en el peor puede poner en riesgo todo el sistema.
Imagina que una gran parte de los clientes de una empresa referencian una supraorganización. Todos ellos referenciarán al mismo registro.
Si, a partir de dicha referencia, por encontrar un NIF en dicha tabla, de manera recurrente, se relacionan el resto de clientes, podremos estar ante un caso de lectura y anonimización de la lista completa de clientes de dicha empresa.
Todo esto en producción.
Se podría pensar que en ningún caso se llegará traspasar el conocimiento aplicado para la generación de los entornos de pruebas hacía proceso relativos a la anonimización en producción.
Sin embargo, si la importancia de cumplir GDPR es evidente en estos entornos de desarrollo, al menos tan relevante ha de serlo la de cumplirlo en producción.
Por tanto, una vez conocidas las estructuras, dominios de datos y probado todo esto, ¿por qué no continuar con la implantación de herramientas dedicadas al cumplimiento de GDPR en las bases de datos productivas?
De hecho, implementar soluciones de anonimización de datos en producción como icaria GDPR es el siguiente paso lógico una vez se considera estable la segmentación de datos.
La experiencia del equipo en el entorno está ahí, las pruebas ya se han acometido en cierta medida y las dificultades principales ya son conocidas.
Si no quieres repetir procesos tan costosos como la documentación necesitas el configurador de icaria.
Es una excelente herramienta en la que identificar esta información y presentarla al usuario.
Gracias a todo ello podrás reducir costes y mejorar la calidad de tu software de gestión de prueba.
Es importante tener en cuenta que no se trata de obtener el conocimiento absoluto.
Lo verdaderamente relevante es llegar a un término medio, en el que se priorizará el estudio de aquellos tipos de información que forman parte de los campos de las relaciones y los que faciliten conocer el dominio de datos en el que se encuentra una tabla.
Y poner barreras para que, en aquellos casos que escapen del control de la implantación se asegure minimizar el impacto en los entornos usados.
¿Quieres implementar el rol de la información? Contacta ahora con icaria Technology y comienza a mejorar la calidad de tu software de gestión de datos de prueba.
También te puede interesar:
Ley de datos personales y GDPR, ¿cómo gestionar el proceso de cancelación de los datos?
¿Cómo realizar la automatización de pruebas para software de gestión empresarial?
¿Por qué la protección de datos en los entornos de prueba no debería ser una preocupación?
