SQL Server Dynamic Data Masking

 Introducción

Recientemente me invitaron a ofrecer una plática sobre lo que es el Enmascaramiento Dinámico de Datos (Dynamic Data Masking) en Microsoft SQL Server. Este es un documento que trata sobre el tema. Sin embargo, debe indicarse que esta característica esta disponible a partir de la versión de Microsoft SQL Server 2016.
La pregunta inicial en este punto es, ¿qué es mejor Encriptación de Datos o Enmascaramiento de Datos? Antes de contestar, debe indicarse que, cuando se habla de encriptación se establece que el dato original es codificado (dato encriptado intermedio), mostrándose la codificación en lugar del dato original y desde este dato codificado, el dato original puede ser obtenido. Por otro lado, en el caso del enmascaramiento, el dato original es enmascarado/obscurecido, mostrándose la mascara en lugar del dato original y no debe haber ninguna disposición para recuperar los datos originales de los datos oscurecidos o enmascarados.

Dato Encriptado

Un ejemplo de dato encriptado se puede observar en la siguiente imagen:

Se observa que la columna PasswordHash de la imagen, muestra información de forma ininteligible, este dato esta codificado, se requiere de una llave que permita obtener el valor original. Esta condición aplica para todos los usuarios que desean obtener el valor original.

Dato Enmascarado

Un ejemplo de dato enmascarado puede apreciarse en la siguiente imagen:

Se observa que la columna SSN se muestra con un patrón de letras X y guiones, (XXX-XXX-XXX), sin embargo, en este caso el dato original no fue afectado, únicamente se presenta con mascara. Esta condición aplica sólo a los usuarios que no tienen permisos administrativos dentro de la base de datos.

Diferencias

La principal diferencia es que, en el cifrado los datos originales se transforman en datos codificados y los datos originales se pueden recuperar a partir de ellos, por otro lado, en el enmascaramiento no se requiere ninguna transformación, solo se protegen los datos originales.

La propiedad más importante del enmascaramiento es que la metodología de enmascaramiento no es reversible, esto significa que los datos originales no pueden ser recuperados. 

La fuerza de la metodología de enmascaramiento radica en el hecho de que el enmascaramiento debe realizarse de tal manera que no debería haber ninguna forma de recuperar datos originales de datos enmascarados.

Encriptación en Microsoft SQL Server 

Se puede mencionar que el cifrado o encriptado es el proceso de ocultar datos mediante el uso de una clave o contraseña. Sin embargo, este proceso puede hacer que los datos queden inútiles si no se cuenta con la clave o contraseña para poder llevar a cabo el proceso de descifrado o desencriptado. Se sabe que este método mejora la seguridad de los datos limitando la perdida de estos, incluso cuando se omitan los controles de acceso. 

Dentro de SQL Server se puede utilizar el cifrado para las conexiones, los datos y los procedimientos almacenados. Se incluyen los siguientes tópicos:

• Microsoft SQL Server y Llaves de Encriptación de Bases de Datos - Las claves de cifrado incluyen una combinación de claves públicas, privadas y simétricas que se utilizan para proteger datos confidenciales. 
• Encriptación Transparente de Datos (TDE) – Llevando a cabo operaciones para llevar a generar el cifrado de forma transparente.
• Siempre Encriptado (Motor de Base de Datos) – Ayuda a garantizar que los administradores y operadores de bases de datos y otros usuarios con privilegios, no autorizados, no puedan acceder a los datos cifrados.

¿Cómo trabaja el Enmascaramiento Dinámico de Datos?

Se pueden establecer las políticas de enmascaramiento dentro de una institución estableciendo los datos que pueden ser vistos por aquellos usuarios que requieren verlos, así como las restricciones para quienes no tiene acceso a la visibilidad deseos datos.

En términos generales los administradores de las bases de datos tendrán permiso de observar los datos, sin embargo, los datos, establecidos previamente, que no puedan ser vistos por usuarios sin permiso, únicamente verán los datos de forma enmascarada. Según se aprecia en la imagen.

¿Por qué utilizar Enmascaramiento de Datos?

Una de las características de este proceso es que ayuda a prevenir el acceso no autorizado a datos confidenciales.

Este método permite especificar cuántos datos confidenciales se pueden revelar con un impacto mínimo

Finalmente, este proceso es fácil de usar con aplicaciones existentes, ya que las reglas de enmascaramiento se aplican en los resultados de la consulta.

¿Cómo las aplicaciones pueden usar la mascara?

Una política de enmascaramiento de datos central actúa directamente sobre los campos sensibles de la base de datos.

Deben designarse usuarios o roles privilegiados que tengan acceso a los datos confidenciales.

Las instrucciones DDM de SQL presentan funciones para lograr un enmascaramiento total y parcial, y una máscara aleatoria para datos numéricos.

Finalmente, los comandos simples de Transact-SQL definen y administran las máscaras.

Limitaciones y restricciones

El enmascaramiento no puede ser usado en columnas cifradas (Always Encrypted), en las columnas de tipo FILESTREAM y en columnas COLUMN_SET o en una columna dispersa que forma parte de un conjunto de columnas. 

Es importante indicar que el enmascaramiento no puede ser definido en columnas calculadas, no obstante, si la columna calculada tiene una dependencia de alguna columna enmascarada, la columna enmascarada devolverá los datos enmascarados.

Finalmente, una columna con enmascaramiento no puede ser usada en una clave de índice FULLTEXT.

Propiedades de los campos a enmascarar

Siempre es importante conocer las características de las columnas o campos que se desea enmascarar, una parte importante es el tamaño de la columna, el formato que se utiliza para la presentación, la mascara que se utiliza para su captura, o las reglas de validación que se utilizan para el mismo. Esto es importante para poder determinar el tipo de mascara que puede ser utilizado. Las características de los campos a enmascarar generalmente están definidas dentro de un diccionario manejado por el administrador de datos, esta información se puede apreciar en la siguiente tabla.

Propiedad	Descripción
Tamaño de campo	Se utiliza para fijar la longitud máxima de un campo de texto que es de 255 caracteres.
Formato	Esto corrige cómo se pueden mostrar los datos, por ejemplo, las fechas se pueden mostrar en muchas formas diferentes, como 13/01/01 o 13 de enero de 01
Mascara de Entrada	Esto establece un patrón para que los datos se ingresen en este campo.
Subtitulo	Esta es la etiqueta de campo en un formulario o informe.
Valor por Omisión	El valor ingresado en el campo cuando se crea el registro. Por lo general, se deja en blanco, pero puede ser muy poderoso.
Regla de Validación	Esto define las reglas de entrada de datos.
Texto de Validación	Este es el mensaje de error si los datos no son válidos.
Requerido	Indica si se debe realizar una entrada o no.
Indizado	Esto permite que los datos se almacenen en el orden de este campo, lo que acelera las búsquedas.

Permite longitud cero

Se utiliza con campos de texto para decidir si los registros de ese campo pueden contener cadenas de texto vacías o de longitud cero

Compresión Unicode

Método de compresión de los datos ingresados en este campo.

Modo IME

Editor de métodos de entrada, que permite la entrada de caracteres especiales.

Modo de sentencia IME

Permite la entrada de caracteres especiales.

Tipos de Mascara Dinámica de Datos

En Microsoft SQL Server se pueden encontrar 4 diferentes tipos de mascara, las cuales se indican en la siguiente tabla:

Función	Descripción
Default	Enmascaramiento completo según los tipos de datos de los campos designados.
Email	Método de enmascaramiento que expone la primera letra de una dirección de correo electrónico y el sufijo constante ".com", en forma de dirección de correo electrónico.
Random	Una función de enmascaramiento aleatorio para usar en cualquier tipo numérico para enmascarar el valor original con un valor aleatorio dentro de un rango especificado.
Custom String	Método de enmascaramiento que expone la primera y la última letra y agrega una cadena de relleno personalizada en el medio. prefijo, [relleno], sufijo.

Es importante indicar que la sintaxis de la sentencia de Transact-SQL que se utiliza en la definición de la mascara utiliza la palabra FUNCTION para indicar que tipo de mascara se ha elegido. 

La mas general es la indicada como default(), esta función al usarse, ya cuenta con mascaras predefinidas, que se utilizaran de acuerdo con el tipo de dato que se utilice. 

• Columnas alfabéticas (que utilizan char, varchar o nvarchar) se usará una mascara consistente de 4 caracteres X, o menos si el campo es mas pequeño; 
• Columnas numéricas, se mostrara el valor 0, como valor; 
• Columnas de tipo fecha (date, time, datetime) utilizara y mostrara siempre el valor 01.01.1900 00:00:00.0000000; 
• Columnas de tipo binario, usara la mascara de utilizar un valor 0.

En el caso de la función email, esta función muestra la columna en la forma aXXX@XXXX.com, donde la primera letra corresponderá a la primera letra del valor real.

Para la función random, se requiere indicar un rango de valores, si el campo tiene el valor 1000, entonces muestra cualquier valor entre el rango indicado.

Finalmente, la función custom, requiere indicar (prefijo, [relleno], sufijo), donde el prefijo indica cuántos caracteres del valor real se deben incluir al principio, el relleno indica la máscara a utilizar y el sufijo indica cuántos caracteres del valor real incluirá al final.

Permisos requeridos

Realmente los permisos requeridos para establecer una mascara los tiene por omisión el creador y dueño de la base de datos, así como el administrador de bases de datos, con tener el permiso de CREATE TABLE y ALTER TABLE en el esquema, se puede establecer el enmascaramiento.

Se puede establecer el permiso ALTER ANY MASK en la tabla, para que una persona no administrativa o dueña de la base de datos pueda modificar las mascaras.

De igual forma, se requiere otorgar el permiso a UNMASK para habilitar la recuperación de datos sin máscara, esto es no mostrar el enmascaramiento previamente establecido.

Ejemplos

Se ha creado un usuario para llevar a cabo consultas y se pueda ver el resultado del enmascaramiento, el usuario será identificado como TestUser, creado y asignado a la base de datos MaskingDB, previamente creada, con el role de db_datareader, como se establece a continuación:

USE [master]

GO

/* For security reasons the login is created disabled and with a random password. */

/****** Object:  Login [TestUser]   ******/

CREATE LOGIN [TestUser] WITH PASSWORD=N'nQNze6HGT9PycxneqcT7xIiOJU9DXKuGOHFRsPBWSmE=', 

DEFAULT_DATABASE=[master], 

DEFAULT_LANGUAGE=[us_english], 

CHECK_EXPIRATION=OFF, 

CHECK_POLICY=OFF

GO

USE [MaskingDB]

GO

/****** Object:  User [TestUser]    ******/

CREATE USER [TestUser] FOR LOGIN [TestUser] WITH DEFAULT_SCHEMA=[dbo]

GO

ALTER ROLE [db_datareader] ADD MEMBER [TestUser]

GO

Para este ejemplo se creará una tabla que se denominará Membership, en una base de datos que previamente se haya creado. 

--- Create a Table

CREATE TABLE Membership 

(

MemberID int IDENTITY PRIMARY KEY, 

FirstName varchar(100) NULL, 

LastName varchar(100) NOT NULL, 

Phone varchar(12) NULL, 

Email varchar(100) NULL,

Payment money NULL

); 

GO

Se procede a insertar algunos datos a la tabla previamente creada.

--- Insert new values

INSERT Membership (FirstName, LastName, Phone, Email, Payment) 

VALUES

('Roberto', 'Tamburello', '555.123.4567', 'RTamburello@contoso.com',1000),

('Janice', 'Galvin', '555.123.4568', 'JGalvin@contoso.com.co', 1000),

('Zheng', 'Mu', '555.123.4569', 'ZMu@contoso.net', 1500),

('Rodolfo', 'Gonzalez','536.830.0439','rgonzalez@softown.com.mx', 2000),

('Oliver', 'Blanco','564.998.3032','oblanco@softown.com.mx', 2500);

GO

Para validar que los datos ya están en la tabla indicada, se usa la sentencia general de consulta.

--- Get the table rows using Admin

SELECT * FROM Membership; 

GO

Con los datos ya alimentados en la tabla, se procede a modificar las columnas que se desea enmascarar, la primera columna nombrada FirstName se le establecerá una máscara de tipo custom, indicando que muestre los primeros dos caracteres del nombre, la máscara de 7 letras X y las dos ultimas letras del nombre, quedando como se indica a continuación:

--- ALTER TABLE COLUMNS to be masked (custom mask)

ALTER TABLE Membership

ALTER COLUMN FirstName ADD MASKED WITH (FUNCTION = 'partial(2,"XXXXXXX",2)');

GO

La siguiente columna que se desea enmascarar es la que tiene el nombre Phone, en este caso se solicitara una mascara de tipo default, que mostrara los valores como un patrón de 4 letras X.

--- Alter Table Column to be masked with default mask

ALTER TABLE Membership

ALTER COLUMN Phone ADD MASKED WITH (FUNCTION = 'default()');

GO

De igual forma, se modificará la columna con nombre Email, para establecer una máscara de tipo email, que mostrará los valores cómo aXXX@XXXX.com, de la siguiente forma.

--- Alter table column to be masked with email mask

ALTER TABLE Membership

ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

GO

Finalmente, en la columna Payment, se establecerá una máscara de tipo random, indicando un rango entre 1 y 12, como se indica a continuación.

-- Alter table column to be masked with random mask

ALTER TABLE Membership

ALTER COLUMN Payment ADD MASKED WITH (FUNCTION = 'random(1, 12)');

GO

Para validar que las columnas están enmascaradas. Se ejecutará una consulta, indicando un usuario con permisos no administrativos sobre la base de datos, que previamente se ha creado, y se comparará con la obtenida con el uso de la misma consulta ejecutándose con el usuario administrador.

--- Execute as TestUser to get table rows

EXECUTE AS USER = 'TestUser';  

SELECT * FROM Membership;  

REVERT;  

--Execute as Admin users

SELECT * FROM Membership;

GO

Un usuario sin permiso de ver los valores reales tendrá la siguiente vista:

El usuario con permiso de ver los valores reales tendrá la siguiente vista:

Para determinar que columnas de las tablas de la base de datos tienen establecida una mascara y el tipo de mascara que se utiliza, se puede ejecutar la siguiente consulta:

--- Querying for Masked Columns information

SELECT c.name, tbl.name as table_name, c.is_masked, c.masking_function  

FROM sys.masked_columns AS c  

JOIN sys.tables AS tbl   

    ON c.[object_id] = tbl.[object_id]  

WHERE is_masked = 1;

GO

Se puede llevar a cabo la definición de las columnas con la indicación del enmascaramiento deseado, de tal forma que, para el ejemplo, se borrará la tabla previamente creada, se volverá a crear utilizando las sentencias de enmascarado y se volverán a cargar los datos anteriores.

--- New Table including Masked properties

DROP TABLE IF EXISTS Membership;

GO

CREATE TABLE Membership _

(

MemberID int IDENTITY PRIMARY KEY,

FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') NULL,

LastName varchar(100) NOT NULL,

Phone varchar(12) MASKED WITH (FUNCTION = 'default()') NULL,

Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL,

Payment money MASKED WITH (FUNCTION = 'random(1, 10)') NULL

); 

GO

--- Insert new values

INSERT Membership (FirstName, LastName, Phone, Email, Payment) 

VALUES_

('Roberto', 'Tamburello', '555.123.4567', 'RTamburello@contoso.com',1000),_

('Janice', 'Galvin', '555.123.4568', 'JGalvin@contoso.com.co', 1000),_

('Zheng', 'Mu', '555.123.4569', 'ZMu@contoso.net', 1500),

('Rodolfo', 'Gonzalez','536.830.0439','rgonzalez@softown.com.mx', 2000),

('Oliver', 'Blanco','564.998.3032','oblanco@softown.com.mx', 2500);

GO

Nuevamente, para validar que las columnas están enmascaradas. Se ejecutará una consulta, indicando un usuario con permisos no administrativos sobre la base de datos y se comparará con la obtenida con el uso de la misma consulta ejecutándose con el usuario administrador.

--- Execute as TestUser to get table rows

EXECUTE AS USER = 'TestUser';  

SELECT * FROM Membership;  

REVERT;  

--Excute as Admin users

SELECT * FROM Membership;

GO

Esta ejecución mostrara la misma vista que cuando se llevo a cabo la modificación de las columnas, previamente mostrada.

Para quitar el enmascaramiento se utilizará la sentencia correspondiente, de tal forma que se pueda volver visible por el usuario sin privilegios.

--- ALTER TABLE COLUMNS drop masked 

ALTER TABLE Membership

ALTER COLUMN FirstName DROP MASKED;

ALTER TABLE Membership

ALTER COLUMN Phone DROP MASKED;

ALTER TABLE Membership

ALTER COLUMN Email DROP MASKED;

ALTER TABLE Membership

ALTER COLUMN Payment DROP MASKED;

GO

Revisar que las columnas ya no están enmascaradas.

--- Execute as TestUser to get table rows

EXECUTE AS USER = 'TestUser';  

SELECT * FROM Membership;  

REVERT;  

SELECT * FROM Membership;

GO

Con esta ejecución, ambos usuarios verán los datos originales, ya que se han eliminado las mascaras.

Mejores Prácticas

Es importante indicar que la creación de una máscara en una columna no evita las actualizaciones de esa columna. La columna puede cambiar de valor, si el usuario cuenta con los permisos para hacerlo.

El uso de sentencias SELECT INTO o INSERT INTO para copiar datos de una columna enmascarada a otra tabla da como resultado datos enmascarados en la tabla de destino. Esto significa que, si algún usuario que solo ve la mascara, pretende crear una copia de los datos en alguna otra tabla, entonces la mascara será establecida en la tabla objetivo, para evitar que los datos puedan ser vistos.

Finalmente, el enmascaramiento se aplica al ejecutar la importación y exportación de datos de Microsoft SQL Server.

Conclusión

Hay que recordar que el enmascaramiento aplica para la presentación de la información, para las personas que no tiene permiso de ver los datos. Como se ha indicado, la creación de una vista que utiliza una tabla que tenga una o más columnas enmascaradas, los datos de esa columna se presentara, también, enmascarada. Como se ha visto, el enmascaramiento de datos puede ayudar a las empresas para cuando se llevan a cabo desarrollos que utilizan datos reales, importados de ambientes productivos, para desarrollo de nuevas funcionalidades de las aplicaciones nuevas o existentes, de esta forma, los desarrolladores, cuando lleven a cabo consultas, obtengan los datos sensibles de forma enmascarada.