ℹ️ 👩🏼‍🤝‍👨🏿 🖕🏽 Defectuoso *** s no es solo aleatorización 💧 🚏 🕌

Hay un problema en el banco: los desarrolladores y evaluadores deben tener acceso a la base de datos. Hay muchos datos de clientes que no se pueden usar para revelarlos a los departamentos de desarrollo y pruebas de acuerdo con los requisitos de PCI DSS del Banco Central y las leyes de datos personales.

Parecería que solo cambiar todo a algunos hashes asimétricos es suficiente y todo estará bien.

Entonces, no lo hará.

El hecho es que la base de datos del banco es un conjunto de tablas interconectadas. En algún lugar están conectados por nombre y número de cuenta de cliente. En algún lugar por su identificador único. En algún lugar (aquí comienza el dolor) a través de un procedimiento almacenado que calcula un identificador de transferencia basado en esta y la tabla vecina. Etc.

La situación habitual es que el desarrollador de la primera versión del sistema ya falleció o se fue hace diez años, y los sistemas kernel que se ejecutan en el antiguo hipervisor dentro del nuevo hipervisor (para garantizar la compatibilidad) todavía están en el producto.

Es decir, antes de anonimizar todo esto, primero debe comprender la base de datos.

¿Quién hace la despersonalización y por qué?

Se involucran en la despersonalización o el enmascaramiento porque hay leyes y estándares. Sí, es mucho mejor probar una "instantánea de venta", pero los reguladores pueden revocar una licencia para dicho vuelo. Es decir, encubrir el negocio como tal.

Cualquier despersonalización es una capa bastante cara y torpe entre los sistemas productivos y las pruebas de desarrollo.

El objetivo de los proyectos de anonimización (enmascaramiento) es casi siempre preparar datos de prueba que sean lo más similares posible a los reales almacenados en bases de datos productivas. Es decir, si los datos contienen errores: en lugar de un correo electrónico, el teléfono está obstruido, en lugar del alfabeto cirílico en el apellido latino, etc., entonces los datos disfrazados deben ser de la misma calidad, pero cambiarse más allá del reconocimiento. El segundo objetivo es reducir el volumen de bases de datos que se utilizan en las pruebas y el desarrollo. El volumen completo se deja solo para la prueba de carga, y para el resto de las tareas, un segmento de datos determinado generalmente se realiza de acuerdo con reglas predefinidas: truncamiento de la base de datos. El tercer objetivo es obtener datos relacionados en diferentes bases de datos disfrazadas y truncadas. Esto significa que los datos en diferentes sistemas, en diferentes momentos, deben ser anonimizados de manera uniforme.

En términos de complejidad computacional, la despersonalización es casi lo mismo que algunos archivos de bases de datos con compresión extrema. El algoritmo es más o menos similar. La diferencia es que los algoritmos de archivo se han perfeccionado a lo largo de los años y han alcanzado una eficiencia casi máxima. Y los algoritmos de despersonalización están escritos para que al menos funcionen en la base actual y sean bastante universales. Y el software después de la despersonalización generalmente funcionó. Ese es un excelente resultado: moler 40 TB por noche. Sucede que es más barato para el cliente llevar la base de datos a la despersonalización una vez cada seis meses durante una semana en un servidor débil, también un enfoque.

¿Cómo se reemplazan los datos?

Cada tipo de datos cambia de acuerdo con las reglas que se pueden usar en el código. Por ejemplo, si reemplazamos el nombre con un hash aleatorio con caracteres y números especiales, la primera validación de datos producirá inmediatamente un error en las pruebas reales.

Por lo tanto, primero el sistema de despersonalización debe determinar qué tipo de datos se almacenan en el campo. Dependiendo del proveedor, se utilizan diferentes enfoques, desde el marcado manual hasta los intentos de descubrir la base de datos y detectar automáticamente lo que está almacenado allí. Tenemos la práctica de presentar todas las soluciones principales en el mercado. Analizaremos una de las opciones cuando haya un asistente que intente encontrar datos y "adivine" qué tipo de datos se almacenan allí.

Naturalmente, para trabajar con este software necesita acceso a datos reales (por lo general, esto es una copia de una copia de seguridad reciente de la base de datos). Según la experiencia bancaria, primero firmamos una tonelada de papeles durante dos meses, y luego llegamos al banco, nos desvestimos, registramos y vestimos, luego vamos a una habitación separada llena de una jaula de Faraday, en la que hay dos guardias de seguridad y respiramos cálidamente en la parte posterior de nuestras cabezas.

Entonces, supongamos que, después de todo esto, vemos una tabla en la que hay un campo "Nombre". El asistente ya lo ha marcado para nosotros como un nombre, y solo podemos confirmar y elegir el tipo de despersonalización. Wizard ofrece un reemplazo aleatorio para nombres eslavos (hay bases para diferentes regiones). Estamos de acuerdo y obtenemos reemplazos como Ivan Ivanov Petrenko - Joseph Albertovich Chingachguk. Si esto es importante, se preserva el género; de lo contrario, los reemplazos se distribuyen por la base de datos de nombres.

Ejemplos de reemplazos:

. ->
->
->
->
-> -

El siguiente campo es la fecha en Unixtime. El asistente también determinó esto, pero debemos elegir la función de despersonalización. Por lo general, las fechas se usan para controlar la secuencia de eventos, y la situación en la que un cliente realizó una transferencia por primera vez en un banco y luego abrió una cuenta, nadie realmente necesita hacer una prueba. Por lo tanto, establecemos un pequeño delta, de manera predeterminada, dentro de los 30 días. Todavía habrá errores, pero si esto es crítico, puede configurar reglas más complejas agregando su script al proceso de anonimización.

La dirección debe validarse, por lo que se utiliza la base de datos de direcciones rusas. El número de tarjeta debe corresponder a los números reales y ser validado por ellos. A veces, la tarea es "hacer todas las Mastercards de Visas al azar", esto también es factible con un par de clics.
Debajo del capó del mago está el perfil. La creación de perfiles es una búsqueda de datos en una base de datos de acuerdo con reglas predefinidas (atributos, dominios). De hecho, leemos cada celda de la base de datos del cliente, aplicamos un conjunto de expresiones regulares a cada celda, comparamos los valores en esta celda con los diccionarios, etc. Como resultado, tenemos un conjunto de reglas activadas en las columnas de las tablas de la base de datos. Podemos configurar la creación de perfiles, no podemos leer todas las tablas de la base de datos, solo podemos tomar un cierto número de filas de la tabla o un cierto porcentaje de filas.

¿Qué está pasando adentro?

Para cada entrada en la base de datos, se aplican las reglas de despersonalización que hemos elegido. En este caso, se crean tablas temporales para la duración del proceso, donde se escriben los reemplazos. Cada registro posterior en la base de datos se ejecuta de acuerdo con estas tablas de correspondencia de reemplazo, y si hay una correspondencia allí, se reemplaza de la misma manera que antes. En realidad, todo es un poco más complicado dependiendo de las secuencias de comandos y las reglas de coincidencia de patrones (puede haber un reemplazo inexacto, por ejemplo, para el parto o para reemplazar las fechas almacenadas en un formato diferente), pero la idea general es esa.

Si hay correspondencias marcadas "el nombre es cirílico - el nombre es latino", entonces deben estar claramente indicadas en la etapa de desarrollo, y luego en la tabla de sustitución se corresponderán entre sí. Es decir, el nombre se anonimizará en cirílico, y luego esta entrada anonimizada se convertirá al alfabeto latino, por ejemplo. En este punto, nos estamos alejando del enfoque de "no mejorar la calidad de los datos en el sistema", pero este es uno de los compromisos que tiene que hacer en aras de algún tipo de rendimiento del sistema. La práctica muestra que si las pruebas estresantes y funcionales no notan un compromiso en su trabajo, entonces no hubo nada. Y aquí viene el punto importante de que la despersonalización en su conjunto no es cifrado. Si tiene un par de yardas de entradas en la tabla, y en diez de ellas el TIN no ha cambiado, ¿entonces qué? Nada, estos diez registros no se pueden encontrar.

Después del final del proceso, las tablas de conversión permanecen en la base de datos protegida del servidor de despersonalización. La base se corta (trunca) y se pasa a prueba sin tablas de conversión, por lo tanto, para el probador, la despersonalización se vuelve irreversible.

La base de datos anónima completa se pasa a los probadores para pruebas de estrés.

Esto significa que mientras se trabaja con la base de datos, la tabla de conversión "se hincha" (la cantidad exacta depende de la elección de las sustituciones y su tipo), pero la base de trabajo sigue siendo el tamaño original.

¿Cómo se ve el proceso en la interfaz del operador?

Vista general del IDE utilizando uno de los proveedores como ejemplo:

Depurador:

Iniciando una transformación desde el IDE:

Configurando una expresión para buscar datos sensibles en el generador de perfiles:

Página con un conjunto de reglas para el generador de perfiles:

El resultado del generador de perfiles, página web con búsqueda de datos:

¿Están enmascarados todos los datos de la base de datos?

No. Por lo general, la lista de datos para la despersonalización está regulada por las leyes y estándares de la esfera, además el cliente tiene sugerencias para campos específicos que nadie debería conocer.

La lógica es que si enmascaramos el nombre del paciente en el hospital, puede enmascarar o no el diagnóstico, aún así nadie sabrá de quién es. Tuvimos un caso cuando las notas de una transacción en un banco simplemente se enmascararon en letras aleatorias. Había notas del nivel: "El préstamo fue rechazado, porque el cliente se emborrachó, vomitó en el bar". Desde el punto de vista de depuración, es solo una cadena de caracteres. Bueno, déjala quedarse.

Estrategias de ejemplo:

Una tabla semilla dinámica es una tabla de transcodificación en la que agregamos la recodificación que ya ha sucedido. El hash puede ser muy diferente y, en el caso del mismo TIN, con mayor frecuencia se genera un nuevo TIN aleatorio con los primeros caracteres almacenados, con dígitos de verificación.

¿Es posible cambiar datos usando el DBMS mismo?

Si. Al despersonalizar los datos, hay dos enfoques principales: cambiar los datos en la base de datos utilizando la propia base de datos u organizar un proceso ETL y cambiar los datos utilizando un software de terceros.

La ventaja principal del primer enfoque es que no necesita extraer datos de la base de datos en ninguna parte, no hay costos de red y se utilizan herramientas de base de datos rápidas y optimizadas. La clave menos es un desarrollo separado para cada sistema, la falta de tablas de conversión comunes para diferentes sistemas. Las tablas de conversión son necesarias para la reproducibilidad de la despersonalización, una mayor integración de datos entre sistemas.

La ventaja adicional del segundo enfoque: no importa qué base de datos, sistema, archivo o interfaz web tenga, una vez que implemente una regla, puede usarla en todas partes. La clave negativa es que necesita leer los datos de la base de datos, procesarlos con una aplicación separada y escribirlos nuevamente en la base de datos.

La práctica muestra que si el cliente tiene un conjunto de varios sistemas que requieren una mayor integración, solo se puede implementar el segundo enfoque por el costo final en dinero, así como por tiempos de desarrollo aceptables.

Es decir, podemos hacer lo que queramos, pero el enfoque ETL ha demostrado ser muy bueno en el sector bancario.

¿Y por qué los datos simplemente no se estropean manualmente?

Esto se puede hacer una vez. Alguien se sentará durante tres días, despersonalizará un montón de datos y preparará una base de datos de 500-1000 registros. La dificultad es que el proceso debe repetirse regularmente (con cada cambio en la estructura de la base de datos y la aparición de nuevos campos y tablas) y en grandes volúmenes (para diferentes tipos de pruebas). Una solicitud común es despersonalizar los primeros 10-50 GB de la base de datos para que esta cantidad caiga en cada tabla de manera uniforme.

¿Qué hacer si los escaneos de documentos se almacenan en la base de datos?

Si un documento se puede reducir a XML y volver a convertir (por ejemplo, documentos de oficina), también puede despersonalizarlos. Pero a veces hay archivos binarios como escaneos de pasaportes en PDF / JPG / TIFF / BMP. En este caso, la práctica generalmente aceptada es proporcionar documentos similares con un script de terceros y reemplazar los reales con muestras de la base de los generados aleatoriamente. Lo más difícil es con fotografías, pero hay servicios como este que resuelven el problema aproximadamente de la misma manera.

¿Quién es responsable de qué?

Al actualizar después de cambiar el software o "ponerse al día", los procesos son más simples.

Pero, ¿qué pasa si algo sale mal en las pruebas?

Esto suele suceder. Primero, los probadores, después de la primera ejecución de despersonalización, formulan con mayor precisión los requisitos para la base de datos. Podemos cambiar las reglas de despersonalización o rechazar registros como "aquí las acciones deben ir en orden cronológico y no en forma caótica". En segundo lugar, dependiendo de la implementación, apoyamos la despersonalización a medida que cambia la base de datos, o dejamos toda la documentación, descripciones de la estructura de la base de datos y los tipos de procesamiento, transferimos el código de procesamiento completo (reglas en xml / sql) y capacitamos a los especialistas del cliente.

¿Cómo ver una demostración?

La forma más fácil es enviarme un correo electrónico a PSemenov@technoserv.com.

Defectuoso *** s no es solo aleatorización