Principios Básicos del Enmascaramiento Dinámico
Introducción
Este documento describe cómo DataSunrise enmascara datos sensibles en tiempo real y cómo se realiza el enmascaramiento para tipos de bases de datos SQL y NoSQL.
Principios del Enmascaramiento de Datos
Comencemos desde el principio y familiaricémonos con dos principios básicos del enmascaramiento de datos en la base de datos:
- Método de enmascaramiento basado en la modificación de conjuntos de resultados de consultas
- Método de enmascaramiento basado en la modificación de consultas SQL
DataSunrise utiliza ambos enfoques para diferentes tipos de SGBD. DataSunrise modifica una consulta SQL donde es posible, y en esos SGBD que tienen pocas características de lenguaje (por ejemplo, bases de datos NoSQL), se utiliza la modificación del conjunto de resultados.
Veamos las ventajas y desventajas de ambos métodos de enmascaramiento.
Método de Enmascaramiento Basado en la Modificación de Conjuntos de Resultados de Consultas
Usando este enfoque, la base de datos recibe la consulta original y devuelve los datos como suele suceder:
Todo parece simple y lo suficientemente lógico. Ahora veamos los detalles de este enfoque:
¿Cómo procesar los datos devueltos por la función? Ejemplo de caso:
SELECT anyFunction(email) FROM customers;
Diversos métodos de modificación de cadenas como la concatenación o la conversión de una cadena a minúsculas/mayúsculas, obtener una subcadena, etc. también están relacionados con este caso.
No hay forma de ofuscar datos que no fueron devueltos a la aplicación cliente. Por ejemplo:
CREATE TABLE demotest.democust AS SELECT * FROM demotest.customers;
o
INSERT INTO demotest.democust SELECT * FROM demotest.customers;
en estas consultas, los datos fuente se guardarán en las tablas creadas, lo que provoca una fuga de datos.
Las aplicaciones cliente ampliamente utilizadas rara vez usan consultas aisladas. Por lo general, las consultas se ejecutan una tras otra y el conjunto de resultados de la primera consulta se usa en una segunda consulta y así sucesivamente. Si consideramos tal caso cuando el campo clave está enmascarado, entonces para que la aplicación siga funcionando correctamente, se vuelve necesaria la modificación de la consulta. Por ejemplo, una aplicación recibe una lista de direcciones de correo electrónico enmascaradas que se usa como condición para obtener datos:
SELECT * FROM demotest.customers WHERE email=’[email protected]’;
SELECT * FROM demotest.customers WHERE email=?; -- ? significa variable vinculada
Dado que la tabla no contiene dicho valor de correo electrónico, la lógica de la aplicación cliente se romperá. Porque una aplicación cliente estará esperando la información por el valor clave que una aplicación cliente recibió previamente.
Como conclusión, se puede ver a partir de las situaciones descritas, que es un objetivo complicado (y a veces incluso imposible) proporcionar el método de enmascaramiento de datos que no afecte el proceso de trabajo de una aplicación cliente.
Método de Enmascaramiento Basado en la Modificación de Consultas SQL
En este enfoque, el texto de la consulta SQL se modifica. Se construyen estructuras especiales en la consulta que evitan la extracción de datos sensibles de la base de datos:
En el caso simple, la conversión se ve así:
SELECT email FROM customers -> SELECT ‘masked’ FROM customers;
Por lo tanto, los datos sensibles que deben enmascararse no salen de la base de datos. También soluciona todos los problemas principales de la ofuscación de datos:
Ya se proporcionan datos ofuscados a las funciones:
SELECT anyFunction(‘masked’) FROM customers;
SELECT anyFunction(maskFunction(email)) FROM customers;
El mismo método de ofuscación de datos es posible para las operaciones que se realizan internamente en la base de datos:
CREATE TABLE customers2 AS SELECT maskFunction(email) FROM customers;
También existe la posibilidad de enmascarar las columnas que se especificaron no solo en la parte de select de la consulta sino también en la parte condicional de la consulta, por ejemplo, where/join. Por lo tanto, la lógica de funcionamiento de la aplicación cliente no se verá afectada.
Secciones Principales de la Regla de Enmascaramiento Dinámico de Datos
En esta sección proporcionaremos ejemplos de capturas de pantalla de cómo estos parámetros afectan el proceso de trabajo con la base de datos cuando la regla de enmascaramiento dinámico está activa.
Imaginemos la situación en la que queremos que alguien que trabaja con la base de datos y la tabla de clientes no vea los datos de la tarjeta de crédito contenidos en la tabla.
Para llevar a cabo tal escenario, utilizaremos nuestra tabla de prueba que contiene información diversa sobre los clientes:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust;
ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD
--------- ---------- --------- --------------------- ----- -------- ------------------- -------------------
1,121 Kathy Abrams High Street, Wheeling MO 132068 [email protected] 4024-0071-8423-6700
4,667 Alma Wade Green Lane, Newport NE 21771 [email protected] 6011-0551-9875-8094
3,427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] 4024-4392-7160-9980
3 rows selected.
Como puede ver, tenemos 8 columnas. Según nuestro escenario, la columna “card” debe estar enmascarada. Para hacerlo, se creará una regla de Enmascaramiento Dinámico. En la configuración de la regla de enmascaramiento dinámico, se configurará para enmascarar la columna Card utilizando el método de enmascaramiento de tarjeta de crédito incorporado. Echemos un vistazo rápido a la configuración de la regla. Hay secciones de la regla:
Sección principal. Aquí se especifican el nombre de la regla, el tipo de base de datos y la base de datos misma.
Sección de acción. Esta sección contiene opciones que se mencionaron en la lista. Iremos cambiando estas opciones a medida que avancemos en el escenario y rastrearemos cómo los cambios afectarán los resultados y el rendimiento de las consultas a la tabla de clientes. Al principio, todas las opciones se dejarán como predeterminadas.
Sección de filtro de sesión y configuraciones de enmascaramiento. Si se especifican filtros, la regla se activará solo si la condición cumple con los requisitos. En cualquier otro caso, la regla no se activará. Dado que no hemos especificado ningún filtro, la regla siempre funcionará, en cualquier consulta dirigida a la tabla de clientes.
Además, se elige el método de enmascaramiento de tarjetas de crédito para la columna de la tabla de clientes.
Ahora, cuando la regla está configurada, intentemos realizar la misma consulta para seleccionar todas las columnas de la tabla de clientes:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust; ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD --------- ---------- --------- --------------------- ----- -------- ------------------- ------------------- 1,121 Kathy Abrams High Street, Wheeling MO 132068 [email protected] XXXX-XXXX-XXXX-6700 4,667 Alma Wade Green Lane, Newport NE 21771 [email protected] XXXX-XXXX-XXXX-8094 3,427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] XXXX-XXXX-XXXX-9980 3 rows selected.Como puede ver en la captura de pantalla, la columna Card se enmascaró de acuerdo con la configuración de la regla.
Opciones Principales de la Regla de Enmascaramiento Dinámico de Datos
Columnas para Enmascarar
Es simple, este parámetro es responsable de las columnas que se enmascararán.
Algoritmo de Enmascaramiento
Este es el algoritmo que se usará en el enmascaramiento de columnas. El algoritmo elegido afecta directamente el valor que se devolverá al intentar obtener los valores de las columnas enmascaradas.
Aquí hay una lista de ejemplo de algoritmos de enmascaramiento que se pueden usar con DataSunrise (para obtener información sobre otros algoritmos de enmascaramiento, consulte nuestra Guía del Usuario p. 148 donde puede encontrar una explicación detallada sobre ellos):
Número de Tarjeta de Crédito – el algoritmo está orientado a enmascarar números de tarjeta de crédito. Muestra los últimos cuatro dígitos de un número de tarjeta de crédito, los otros caracteres se reemplazan con “X”. Por ejemplo: XXXXXXXX-XXXX-1234.
Enmascaramiento de E-mail – la sección de nombre de usuario y dominio de las direcciones de correo electrónico se reemplaza con “*”, excepto el primero y el último en una fila. Por ejemplo: a***@**.**m.
Cadena Fija – los valores de tipo STRING se reemplazan con una cadena predefinida por el usuario.
La Suite de Seguridad de DataSunrise también admite funciones personalizadas (funciones especificadas en la base de datos) que se utilizarán como método de enmascaramiento y scripts LUA que se crean directamente en el entorno de la WebUI de DataSunrise.
Filtro de Sesión
Este parámetro se puede especificar para configurar el comportamiento de la regla de Enmascaramiento Dinámico según diferentes condiciones. Aquí está la lista de parámetros de condición:
Aplicación – nombre de la aplicación cliente
Usuario de la Aplicación – nombre del usuario de la aplicación
Usuario de la BD – nombre del usuario de la BD
Host – dirección IP o alias desde donde el usuario o la aplicación se está conectando a la base de datos
Usuario del SO – nombre del usuario del Sistema Operativo
Proxy – proxy de DataSunrise donde la regla debería funcionar en caso de que se hayan configurado muchos proxies
Por ejemplo, desea enmascarar datos para el Usuario Invitado de la BD y no desea enmascarar datos para el Usuario Administrador de la BD, lo cual es comprensible. En este caso, simplemente especifique BD Usuario Igual Invitado y la regla de enmascaramiento solo se activará cuando el Usuario Invitado esté ejecutando consultas a las columnas enmascaradas de la tabla.
Mantener Cuenta de Filas
Esta opción es responsable del enmascaramiento de valores utilizados en cláusulas where, join, etc. de las consultas:
cuando desactivado, los valores de los campos que deben enmas