Principios Básicos del Enmascaramiento Dinámico
Introducción
Este documento describe cómo DataSunrise implementa los principios del Enmascaramiento Dinámico de Datos para 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 los 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 DBMS. DataSunrise modifica una consulta SQL en sí misma donde es posible, y en aquellos DBMS 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 usualmente sucede:
Todo parece suficientemente simple y 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;
Varios 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 manera de ofuscar datos que no se devolvieron 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 clientes ampliamente utilizadas raramente usan consultas aisladas. Usualmente, 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 un caso así, cuando el campo clave está enmascarado, entonces para que la aplicación siga funcionando correctamente, se vuelve necesaria una 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=’masked@email.com’;
SELECT * FROM demotest.customers WHERE email=?; -- ? representa la variable vinculada
Dado que la tabla no contiene tal 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 la aplicación cliente recibió previamente.
En conclusión, puede ver de las situaciones descritas, que es un objetivo complicado (y a veces incluso imposible) proporcionar el método de enmascaramiento de datos que no afectará el proceso de trabajo de una aplicación cliente.
Método de Enmascaramiento Basado en la Modificación de Consultas SQL
En este enfoque, se modifica el texto de la consulta SQL. 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 ser enmascarados no salen de la base de datos. También se resuelven todos los problemas principales de la ofuscación de datos:
Se proporcionan datos ya ofuscados a las funciones:
SELECT anyFunction(‘masked’) FROM customers;
SELECT anyFunction(maskFunction(email)) FROM customers;
La misma forma 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 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 trabajo 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 donde queremos que alguien que trabaje 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 diversa información 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 kitykatty@fugie.com 4024-0071-8423-6700
4,667 Alma Wade Green Lane, Newport NE 21771 almwa@nprt.com 6011-0551-9875-8094
3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com 4024-4392-7160-9980
3 rows selected.
Como puede ver, tenemos 8 columnas. Según nuestro escenario, la columna “card” debería estar enmascarada. Para hacerlo, se creará una regla de enmascaramiento dinámico. En la configuración de la regla de enmascaramiento dinámico, se establecerá en enmascarar la columna “Card” usando el método de enmascaramiento de tarjeta de crédito incorporado. Demos un vistazo rápido a la configuración de la regla. Estas son las secciones de la regla:
Sección principal. Aquí se especifica el nombre de la regla, el tipo de base de datos y la propia base de datos.
Sección de acciones. 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 que 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 kitykatty@fugie.com XXXX-XXXX-XXXX-6700 4,667 Alma Wade Green Lane, Newport NE 21771 almwa@nprt.com XXXX-XXXX-XXXX-8094 3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com XXXX-XXXX-XXXX-9980 3 rows selected.Como puede ver en la captura de pantalla, la columna de la tarjeta se enmascaró según 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 serán enmascaradas.
Algoritmo de Enmascaramiento
Este es el algoritmo que se utilizará para enmascarar la columna. El algoritmo elegido afecta directamente el valor que se devolverá al intentar obtener los valores de las columnas enmascaradas.
Aquí está la lista de ejemplos de algoritmos de enmascaramiento que podrían usarse con DataSunrise (para informarse sobre otros algoritmos de enmascaramiento, por favor consulte nuestro Manual de Usuario p. 148 donde puede encontrar una aclaración detallada sobre esos):
Número de Tarjeta de Crédito – el algoritmo está destinado a enmascarar números de tarjetas de crédito. Muestra los últimos cuatro dígitos de un número de tarjeta de crédito, sustituyendo los otros caracteres por “X”. Por ejemplo: XXXXXXXX-XXXX-1234.
Enmascaramiento de Correo Electrónico – la sección del 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.
El DataSunrise Security Suite también admite funciones personalizadas (funciones especificadas en la base de datos) para ser utilizadas como método de enmascaramiento y scripts LUA que se crean directamente en el entorno DataSunrise WebUI.
Filtrar Sesión
Este parámetro puede especificarse 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 Base de Datos – nombre del usuario de la BD
Host – dirección IP o alias desde donde el usuario o la aplicación se conectan a la base de datos
Usuario del OS – nombre del usuario del sistema operativo
Proxy – proxy de DataSunrise donde debería trabajar la regla en caso de que se configuraran 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 especifica Usuario de la BD Igual a Invitado y la regla de enmascaramiento se activará solo cuando el Usuario Invitado realice consultas a columnas enmascaradas de la tabla.
Mantener Recuento de Filas
Esta opción es responsable de enmascarar los valores utilizados en cláusulas como where, join, etc., de las consultas:
cuando está deshabilitada, los valores de los campos que deben ser enmascarados serán enmascarados incluso si se usan en la cláusula WHERE/JOIN.
cuando está habilitada, el enmascaramiento de valores utilizados en las cláusulas mencionadas se deshabilitará. El conjunto de resultados devuelto contendrá el mismo número de filas que se devolvería si no se aplicara ninguna regla de enmascaramiento. Esta opción ayuda a recibir el mismo recuento de filas incluso si los datos están enmascarados porque sus valores reales pueden ser usados en cláusulas WHERE/JOIN de la consulta.
Para comprender la situación más a fondo, supongamos que sé parte de un número de tarjeta y es 4024. Tenemos dos clientes cuyo número de tarjeta de crédito contiene este número:
Kathy Abrams 4024-0071-8423-6700
Mary Evans 4024-0071-2955-9980
Veamos qué sucede si la opción está deshabilitada:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust WHERE card LIKE '%4024%'; no rows selected.
La consulta no devolverá ningún resultado ya que los resultados están enmascarados y la aplicación no puede encontrar tales campos.
Veamos qué sucede si la opción está habilitada:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card
FROM demotest.democust
WHERE card LIKE '%4024%';
ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD
--------- ---------- --------- --------------------- ----- -------- ------------------- -------------------
1,121 Kathy Abrams High Street, Wheeling MO 132068 kitykatty@fugie.com XXXX-XXXX-XXXX-6700
3,427 Mary Evans 13 The Limes, Leighton OR 10950 evensmary@hitmail.com XXXX-XXXX-XXXX-9980
2 rows selected.
Como puede ver aquí, aunque los resultados están enmascarados, todavía podemos usar 4024 para encontrar tarjetas que contengan esa parte, pero no podemos verlo en el conjunto de resultados.
Enmascarar solo SELECTs
Este parámetro es responsable de la regla para enmascarar los valores de las columnas especificadas SOLO si los datos se obtienen mediante tipos de consulta SELECT. Veamos cómo funciona:
SQL> SELECT card FROM demotest.democust; CARD ------------------- XXXX-XXXX-XXXX-6700 XXXX-XXXX-XXXX-8094 XXXX-XXXX-XXXX-9980 3 rows selected.
Como puede ver aquí, los valores de la tarjeta se obtuvieron usando la instrucción SELECT y según la regla, la columna del número de tarjeta está enmascarada.
Ahora intentemos realizar la siguiente consulta y ver qué sucede:
SQL> UPDATE demotest.democust SET state = card;
3 rows updated.
SQL> SELECT order_id, first_name, last_name, state, zip, card FROM demotest.democust;
ORDER_ID FIRST_NAME LAST_NAME STATE ZIP CARD
--------- ---------- --------- ------------------- -------- -------------------
1,121 Kathy Abrams 4024-0071-8423-6700 132068 XXXX-XXXX-XXXX-6700
4,667 Alma Wade 6011-0551-9875-8094 21771 XXXX-XXXX-XXXX-8094
3,427 Mary Evans 4485-4392-7160-9980 10950 XXXX-XXXX-XXXX-9980
3 rows selected.
Como puede ver, la columna “state” ahora tiene valores reales de la columna “card” enmascarada, porque no se realizó un tipo de consulta SELECT. Sin embargo, si se ejecuta un tipo de consulta SELECT para la columna enmascarada, seguirá estando enmascarada.
Bloquear una Consulta Cuando la Columna Enmascarada Está Relacionada con una Modificación de Datos
El objetivo de este parámetro se explica por su nombre. También es una casilla de verificación que está marcada por defecto al crear una regla de enmascaramiento dinámico. En caso de que una consulta vaya al proxy de DataSunrise y una consulta esté destinada a cambiar el valor en la columna enmascarada, tal consulta será bloqueada. Intentemos realizar una consulta que esté destinada a modificar un número de tarjeta usando la siguiente consulta:
SQL> UPDATE demotest.democust SET card = '1234' WHERE card LIKE '%6700%'; ERROR at line 1: SQL Error [42501]: La consulta está bloqueada
Como resultado, se devuelve “La consulta está bloqueada”.
Conclusión
La función de Enmascaramiento Dinámico es una de las funciones más utilizables de nuestro producto. Esta función ayuda a enmascarar datos sensibles de la base de datos protegida según la configuración de la regla que el usuario haya establecido.
DataSunrise utiliza los enfoques más apropiados de cómo enmascarar datos sensibles al elegir la mejor solución tanto para bases de datos basadas en SQL como para bases de datos NoSQL.
Las reglas de enmascaramiento dinámico tienen muchas opciones que pueden configurarse por un usuario. Las más significativas son:
- Opción Mantener Recuento de Filas es responsable de devolver el mismo número de filas devueltas por una consulta como se devolvería si no hubiera ninguna regla de enmascaramiento configurada. Si esta opción está activa, la parte condicional de una consulta que se utiliza para filtrar datos mediante el uso de where/join/etc. cláusulas no se enmascararán. Esta opción es importante para aquellos que usan aplicaciones clientes y no quieren ver un número diferente de filas devueltas por una consulta cuando la regla de enmascaramiento está activa.
- Enmascarar solo SELECTs opción es responsable de enmascarar solo partes selectas de una consulta. Si esta opción está activa, solo se enmascararán aquellas columnas que se ubiquen después de la instrucción SELECT y estén especificadas en la regla. Esta opción también es importante para aquellos que usan aplicaciones clientes que realizan consultas generadas automáticamente, por ejemplo, sentencias UPDATE TABLE. Porque todas las operaciones con los datos de la tabla enmascarada no se verán afectadas de ninguna manera, pero se verán enmascaradas si se seleccionan datos.
- Bloquear una Consulta Cuando la Columna Enmascarada Está Relacionada con una Modificación de Datos opción es responsable de bloquear cualquier operación que afecte la columna enmascarada de alguna manera. Si una columna enmascarada se menciona en cualquier parte de la consulta en sí, la consulta se bloqueará. Esta opción es importante para aquellos que no quieren perder datos sensibles por accidente o por intento.